[Top] [All Lists]

Re: Revisiting RFC 2822 grammar

2004-01-19 05:12:44

In <p06100910bc2d18902e44(_at_)[216(_dot_)43(_dot_)25(_dot_)67]> Pete Resnick 
<presnick(_at_)qualcomm(_dot_)com> writes:

On 1/15/04 at 9:59 PM +0000, Charles Lindsey wrote:

Now we come to the obs- syntax, where there are still many 
ambiguities. As things stand, sometimes the obs- syntax allows 
something that is already in the regular syntax (that is ambiguous). 
OTOH, sometimes it does not, and sometimes it allows only a part of 
what is in the regular syntax, all of which can be very confusing to 
the reader who tries to work out exactly how the obs- syntax differs 
from the regular.

I disagree completely. I think it's much easier for the reader to 
have some complete pieces in the obs- syntax even if there is 
redundancy. For example, I think the horrible hoop you have to jump 
through below for obs-local-part:

Yes, that syntax was pretty ugly, but most of them come out reasonably clean.

But I think the real point is that you need to be consistent. Either the
obs- version of a rule should consistenly include the regular version of
the same rule, or they should be consistently disjoint. Problem is that at
the moment you have neither of these situation.

But whatever is done, I think the text needs to make it clear what policy
has been followed.

obs-phrase      =       word *(word / ("." [CFWS]))

OK, but that is not "obsolete". It is intended as an extension to be 
allowed sometime in the future on a "MUST accept, SHOULD NOT 
generate yet" basis. So please can we rename it as 'extended-phrase' 
(which is what I have currently put in Usefor).

I am not convinced this is worth it. It's explained perfectly well in the text.

Yes, but it is too easily missed if it is hidden away in the obsolete
stuff, which is how I cam to miss it when constructing the Usefor syntax
until Bruce pointed it out.

It is an extension to the preceding standards. It should be in a section
entitled "extensions", or some such.

Currently, RFC2822 requires:

1. Return-Path
2. 1*Received
3. *Resent-xxx
4. Other headers

No, it doesn't. Look at the parens and the repeats. It requires:


Here is another example (a real one this time, which some readers of may recognize):

Received:  from (localhost [])
 by (8.11.7+Sun/8.11.7) with ESMTP id i05HCjF01021
 for <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk>; Mon, 5 Jan 2004 17:12:45 
Delivered-To: postmaster(_at_)A
Received:  (qmail 81124 invoked by uid 800); 5 Jan 2004 12:54:22 -0000

You're right, that's not allowed, and I think that is a bug that 
needs to be fixed.

Now there are all sorts of perfectly genuine "tracing headers" in 
there, all added in transit, and all useful.

So, likely we need optional-field to appear in trace. I think that's 
the logical answer.

OK. But I still think that the syntax is the wrong place to enforce this.
The number of way of including tracing information is going to increase
(see separate thread currently running), so you need to allow maximum
flexibility for future developments.

Also, my example included a Reply-To header inserted my a mailing list
expander in the midst of the tracings. Was that right or wrong?

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web:
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, 
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5