Message-ID: <oO1PbDAPYBQxQAwG@turnpike.com>
Date: Fri, 8 Mar 1996 11:12:15 +0000
To: drums@cs.utk.edu
From: Paul Overell <paulo@turnpike.com>
Subject: Re: Message format document outline
In-Reply-To: <Pine.LNX.3.91.960306153951.348A-100000@laptop79.ietf.interop.net>
MIME-Version: 1.0

In article <Pine.LNX.3.91.960306153951.348A-100000@laptop79.ietf.interop
.net>, John Gardiner Myers <jgm@cmu.edu> writes
>
>The following is a working outline for the 822 update document.  It 
>is currently heavy on syntax and almost devoid of text.  Right now, I'm 
>looking for comments on the overall structure, ordering, and direction of 
>the document, as well as the ABNF productions.
>
[snip]

>       received        ::=  "Received"    ":"            ; one per relay
>                       ["from" domain]           ; sending host
>                       ["by"   domain]           ; receiving host
>                       ["via"  atom]             ; physical path
>                      *("with" atom)             ; link/mail protocol
>                       ["id"   msg-id]           ; receiver msg id
>                       ["for"  addr-spec]        ; initial form
>                        ";"    date-time         ; time received
>

The RFC822 syntax of the Received: field was modified by RFC1123 5.2.8
but it unfortunately failed to give ABNF for its modifications.
Furthermore RFC821 has its own syntax for the Received: field.  This is
a good opportunity to clarify the syntax.

In particular:

The id part: RFC822 says msg-id, RFC821 says string, RFC1123 suggests
msg-id without the @!  In practice the id is either a message-id or a
string such as JAA23135.

suggestion: "id" (msg-id / atom)

This reflects reality and is probably what RFC1123 meant.


The for part: RFC822 says addr-spec, RFC821 says path, RFC1123 says list
of path (it doesn't say if this list is comma separated or not).  The
use of the for part is problematical because it can undermine Bccs,
however, this should not stop the syntax from being clarified.

suggestion: "for" 1#mailbox

This is compatible with both RFC822 and RFC821 and incorporates the
RFC1123 modification.
 
[snip]
>       group           ::=  phrase ":" [#mailbox] ";"

Surely the [] are redundant here? as #mailbox includes the empty case.

[snip]

>       local-part      ::=  quoted-string
>                            / (atom *("." atom))
>                                               ; uninterpreted
>                                               ; case-preserved

This is an (unmentioned) incompatible change in syntax which would
outlaw  "this".is."legal".under."RFC822"

Why the incompatible change?

the syntax was: local-part = word *("." word)


On a general point:

As an implementor of an RFC822 parser I strongly agree with the view
expressed elsewhere in this thread that any message that is legal under
RFC822 should remain legal under RFC822bis.

This is an excellent opportunity to clarify, resolve ambiguities and
incorporate post RFC822 developements, but any incompatible changes to
the syntax should be kept to an absolute minimum.  

By all means deprecate the use of particular obsolete syntaxes (e.g.
non-numeric timezones or multiple quoted strings in local-parts) but
please don't outlaw existing legal messages.
   
-- 
Paul Overell                                        T U R N P I K E  Ltd