[Top] [All Lists]

Re: another issue: should end-of-line markers remain in RFC XXXX?

1991-11-14 01:37:21
Keith writes...

I realize we're drawing close to Santa Fe, but I want to quickly
bring up one more issue that we might want to discuss: whether
portable end-of-line markers should remain as part of BASE64 and

Interesting discussion.  I have two quick reactions:

(1) It is *vital* to have some way, especially in Base64 -- which I 
think is more important than quoted-printable in this regard -- to have 
a way in which the sender can canonically represent line boundaries and 
immunize them from all of the little disasters (e.g., line wrapping) 
that affect mail.  Parts of the checksum discussion should reinforce 

(2) Since
  (i) the specifications for 8bit transport seem to be a considerable
distance behind RFC-XXXX in terms of "ready to finish up and advance to
the next stage", 
  (ii) binary can't be transported at all under RFC821,
  (iii) neither RFC-ZZZZ nor the Prime proposal make provision for
binary transport.  It is a placeholder in the former at the moment,
along with some arguments for not allowing it (ever), and, if I recall, 
the latter does not address it.
  (iv) Despite some apparent promises at Atlanta, no proposal for 
binary, non-line-oriented transport have appeared on the list, only 
assertions that this is needed.
  (v) It would be possible to define a binary transport model that does 
have effective portable end-of-line markers by the simple expedient of 
requiring that anything that "looked like" CR, LF, or "." be quoted in 
some way, thus providing a sort of hybred between "pure binary" and 
Base64 and using line-and-character-oriented transport.
   perhaps "Content-transfer-encoding: binary" ought to be handled with
the same treatment as mostly-undefined character sets. I.e., put in a
placeholder, provide for a future RFC to be written in the context of a
proposed standard binary transport RFC, and then prohibit its use until 
that is done.

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