Message-ID: <clDmuHy00WBw8vWkl5@andrew.cmu.edu>
Date: Thu,  7 Mar 1996 13:44:35 -0500 (EST)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: drums@cs.utk.edu
Subject: Re: Message format document outline
In-Reply-To: <19960306234003.15437.qmail@koobera.math.uic.edu>
References: <19960306234003.15437.qmail@koobera.math.uic.edu>

djb@koobera.math.uic.edu (D. J. Bernstein) writes:
> One ambiguity in RFC 822: it's not clear whether
> 
>    To: foo (comment) bar <user@host.domain>
> 
> is allowed.

I intend to fix the ambiguity.  The problem is that the
free-insertion-of-whitespace rules are poorly specified.

The lower-level parser converts "(comment)" into whitespace, then
collapses the resulting three spaces between "foo" and "bar" into a
single space.  The other spaces get removed, so the above header is
equivalent to:

To:"foo bar"<user@host.doman>

> > New requirement: continuation line must contain non-whitespace character
> 
> I hope you're not trying to change the syntax here. Do you mean that
> invisible continuation lines must be recognized but not generated?

Invisible continuation lines must not be generated.  There then
becomes no requirement on how they are recognized or interpreted.
Readers have the choice of treating them as continuation lines or as
the header/body separator.

> >       ;; no free insertion of whitespace
> 
> You seem to be trying to change the rules in RFC 822 section 3.4.2. Has
> this been discussed?

3.1.4 allows free insertion of linear-white-space between lexical
tokens.  I am clarifying in the BNF which nonterminals are lexical
tokens and thus do not permit free insertion of whitespace between
sub-nonterminals.

> > obsolete-zone ::=             ; MUST not be generated
> 
> MUST not? That's excessive.

This is a change from 1123, which has a SHOULD use numeric timezones.

1123 has been out for quite some time and we still get loads of
alphabet soup.  In my opinion, we need to strenghen the directive in
light of current experience.

> I always generate GMT, even though RFC 1123 says I shouldn't. There are
> many more programs that can handle ``GMT'' than ``+0000''.

Which programs can't handle "+0000"?  Given the fact that large
sections of the world can only use numeric timezones to represent
local times, aren't such programs hopelessly broken?

djb@koobera.math.uic.edu (D. J. Bernstein) writes:
> John has suggested that, for something to be ``reasonably considered a
> modern Internet MTA,'' it must store all mail messages in CRLF form.

I don't recall making this statement.  I recall making two entirely
separate statements:

* To be reasonably considered a modern Internet MTA, the SMTP server
needs to support the EHLO command, even if it supports no ESMTP
extensions.

* In order to be capable of handling arbitrary binary content, a mail
system must keep messages in canonical MIME form (including
CRLF-separated text) throughout the entire system.

I have also offered other advantages to queuing messages in canonical
form and advise that newly implemented MTAs strongly consider doing
so.

> 4. John presumably intends to enforce his view by declaring, in the
> RFC 822 update, that a message _is_ a sequence of characters, to be
> interpreted as text lines under the CRLF encoding.

This is the definition that already exists in both RFC 822 and MIME.
The model is not changing.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up