[Top] [All Lists]

Re: Putting alternate character sets in headers.

1991-08-24 11:59:25

3. If any agent decides to explicitly add the implied "Content-type: usascii"
header to a message that previously had no Content-type header then it must
change all the free-text parts of headers by changing & to && and fixing any
resulting line-length problem.

I want to keep pushing on this because I think it is important, at least
until we all acknowledge the problem and decide it is ok to ignore it
and trust to fate. 

The above rule applies to an RFC-XXXX conforming agent (whatever that
means, given that we are presumably talking about transport here) and to
RFC-ZZZZ(rev) conforming agents.  How about if I've got a RFC821/822
conforming agent, and I just like the sound of the phrase "Content-type:
usascii".  And, knowing that RFC822 implies "ascii of the X3.4
persuasion", I put that into every single message I touch and have been
doing so for the last two or three years. 

(i) How are you going to tell that this header is bogus and that the 
message doesn't really contain mnemonic?

(ii) What are you going to do about it, given that declaring an existing 
and conforming implementation non-conforming (retroactively "broken") is 
a no-no?

4. Because the message may wander back into realms where Content-type is not
understood, the rules for determining what can go in free-text parts of headers
without being quoted are the rfc-822 rules. E.g. &"a is three characters for
the purposes of this determination not a single a-diaresis.
   I'm not certain what you mean here, but the example &"a is 
interesting since, if it really appears in an rfc-822 conforming header, 
it presumably needs to appear as something like
   "&""a"   or    &\"a
Is that true, or have I forgotten an important piece of RFC-822?  If it 
is true, then, one again, you need to know unambiguously whether you are 
dealing with RFC-XXXX/Content-type: mnemonic or with RFC822, and there 
is _no way to know for sure_.
  In this particular case, it isn't that the RFC-XXXX-capable receiving
system has to be certain (which has dominated my thinking) but that the 
sender has to know whether the receiver is going to interpret the 
headers as RFC-822 or RFC-XXXX.   Gee, something else to get nervous 
about :-)

<Prev in Thread] Current Thread [Next in Thread>