[X4U] Why do some images not go through on Apple Mail?

[Ed Gould]

On Apr 28, 2008, at 4:14 PM, Dave B wrote:

> But doesn't that require the assumption that the RFC (Request For  
> Comment) is going to be adopted as a standard? Maybe I'm being  
> naive, but wouldn't it be prudent to write code that is standards  
> compliant? Writing code to meet RFC's is going to (almost  
> certainly) lead to it being invalid. Why else are there standards?
>
> To use your analogy, RFC's are the 'floating target'. Standards are  
> the stationary target.
>
> I'm not a developer, and don't claim to understand the intricacies  
> of that industry. However, I was under the impression that well  
> written code that adheres to standards could evolve to meet new  
> standards as they are implemented.
>
> Regards,
> Dave
>

I *USED*  to do programming 40 or so years ago. At that time spec's  
were cast in stone, if you varied from the spec's you were written up  
for doing so.  I *assume* its no different today. If a field that  
suppose to start say HTTP:// (example) and it doesn't then your  
program is either to say it can't find the HTTP:// or it is written  
to assume its there. The blue "highlighting" may or may not be enough  
to pass the string to the browser (I don't know if there is more  
checking done before it is or not). The trick comes in what do you  
pass the browser the entire string until a non alphanumeric character  
is hit or what? Line continuation gets sticky (what is the line end  
indicator?) EOL (end of line or what) There is (at least in my mind)  
no standard way saying end of line. There may be on some OS's but not  
on others. This is just one of the issues on how to treat items to be  
passed to (in this case) another application(the browser). There has  
to be accepted standards on how to treat this "special" case. In this  
case either the URL is broken by either the email app or the LISTSERV  
app. (AND) any server that the message passes through and that is  
includes the receiving email app or email server. A LOT of people can  
break the rules either by accident(bug) or interpreting any RFC's  
another in another way that was not intended.
In other words it is hard to say who broke the "RFC". Since some  
email servers (notably MS) decided to write to MS standards not to  
RFC's it is up to MS to correct the code. The problem comes in what  
if MS says "NO" (as they often do) and refuse to update their code  
(it might be for a valid reason for all I know as it might break a  
LOT of MS code). Then it gets into a finger pointing exercise as to  
who is correct. The vendor might refuse to fix their code as it  
follows their spec. Unfortunately  no one is going to bow to MS. I am  
not picking on MS it really could be *ANY* vendor. I thought RFC's  
were supposed to be "law" but as one can say I will interpret the law  
my way and you interpret it your way. that way leads to chaos but  
that is what happens when a vendor does his own thing. Throw into  
this mash 5 or 10 vendors all it takes is one to go his own way and  
what should happen is that vendor should not be allowed to go his own  
way but it does happen. Because one vendor thinks he is boss he snubs  
his nose at every one else and then we have what happens now a broken  
code.

Ed