Re: Robert Ullman's "8-bit draft"

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

Since I, and at least of few of the others who have felt most strongly 
about this, will not be in St. Louis, let me reiterate a position, 
stated as simply as possible:

Any proposal, including this one, that changes the "7 bit" rule to an "8 
bit" rule by simply declaring the 7 bit implementations obsolete and 
expecting all systems to accept (and presumably send) 8 bit characters 
is not acceptable.  If 8 bit characters are to be sent without encoding, 
the receiver must explicitly agree to accept them.
  While I acknowledge Prime's experience that few problems have been
encountered, the fact remains that others of us have experienced 
problems and that there is a difference of opinion about where the 
boundary between "acceptable but not quite right" and "broken" behavior 
falls.
  More important, at the present stage in the maturity and development 
of the Internet, it seems to be an extremely poor idea, on technical, 
interoperability, and moral grounds, to invalidate any implementation 
that now conforms to the protocols, especially for the purpose of
retroactively validate a nonconforming implementation.  
  If nothing else, it sets a rotten precedent, encouraging people to 
ignore the protocols and do what they feel like, then come in and say 
"well, it works for us and does not cause more damage than *we* are 
willing to accept, why don't the rest of you folks make it the rule".  
While exceptions are conceivable,  I don't think it is wise to appear to 
encourage that type of behavior under any circumstances.
  I can imagine situations, such as the introduction of the DNS, that
are sufficiently important to justify a strategy that invalidates 
previously-conformant implementations, but, even there, the transition
plan did not subject an implementation that had not yet conformed to the
new rules to a sudden onslaught of unsolicited and possibly
incomprehensible information. 


Minor, by comparison, issues, commented on in the event that some of the 
rest of the text here is used...

>The octets CR and LF must not occur within the line; that is, not as
>part of a CR LF sequence.  A CR or LF appearing erroneously within a
>line may be interpreted as the end of a text line by some mailers. This
>may be a side-effect of storage in, and retrieval from, the host's
>"native" text file format. Internet mailers may recognize "lines"
>terminated by (only) LF or by CR not followed by LF, but must send only
>lines properly terminated with CR and LF.

This breaks conforming implementations, and changes the standard to 
adapt to non-conforming ones at the expense of implementations that are 
doing something that has historically been reasonable.  Again, I think 
that represents terrible policy, and almost as bad strategy.  The 
correct rule would be
  - lines terminate in CR LF.  Nothing else terminates a line.  CR and 
LF appearing "bare" within a line are much like HT, VT,  and "other
control characters": senders should be aware that receivers may not
interpret them the way the senders intend.  It is not acceptable to make
an implementation invalid because it uses CR to imply "return to left 
margin on same line" or LF to imply "index to same position on next 
line".

>Internet mailers must pass all octets with values 9 (TAB), 32 to 126,
>129 (HOP), 153 (SGCI), and 160 to 255 unmodified; they should pass all
>other values ("control characters") unmodified wherever possible.
  This restriction must be expanded to included CR and LF to be 
meaningful.  More important, a restriction-proposal must either include 
ESC, or must prohibit explicitly prohibit the use of ESC-based 7bit
sequences in lieu of HOP and SGCI. 

You also should include two additional statements in your "line" 
definition:
 (i) any character switching controls (e.g., HOP and SGCI sequences) 
count in the 1000 octet limit, not just graphic characters.  I know you 
intend this, but, given some prior experiences, it should be made 
extremely clear.
 (ii) similarly, CRLF.CRLF terminating "DATA" means just exactly 
that--no HOP or SGCI sequences an appear on that line, especially before 
the ".".  Again, I know that is what you intend, but a final document
should be tediously clear about this. 

   john

















Ullmann                                                         [Page 4]
***END-OF-MESSAGE***
-------