On Sat April 9 2005 11:42, Tony Finch wrote:
i.e. a queue ID not the value of the Message-ID field.
Yes, a different ID with the same syntax (msg-id). I.e. an example
of multiple identifiers for the same message, which was the point made
w.r.t. the architecture draft.
RFC 821 has a much more detailed specification of the syntax, which
disagrees with the syntax in RFC 822 about what appears after id in a
Received: field. The only example of a Received: field in either document
is
Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
id M12345 for Smith(_at_)PDQ(_dot_)ARPA ; 22 OCT 81
09:23:59 PDT
Yes, there is an incompatibility between 821 and 822. RFC 1123
compounded the problem by stating that the explicit syntax clearly and
precisely specified by RFC 822 EBNF was merely "suggested".
RFCs 2821 and 2822 fix the syntax confusion by making 2822 specify just
the name/value item metasyntax and leaving the details of ordering and
which names and values are valid to 2821. The latter says:
- The ID field MAY contain an "@" as suggested in RFC 822, but this
is not required.
That repeats the problem compounded by 1123 by copying the same text.
ID = "ID" FWS String / msg-id CFWS
No, it's not (yet) fixed; there are still 2821/2822 discrepancies. The
2821 and 2822 editors are aware of the discrepancies, but no errata
have been issued for the problems, and I have reason to believe that
that won't happen any time soon. There is currently no cognizant IETF
WG working on advancing either document to Draft status, and while a
bit more than a year ago there was some talk about advancing both
documents, not much seems to have happened with either one.
The specific issue w.r.t. 2821/2822 Received field "id" component
discrepancies is that 2821 "String" corresponds to 2822 "atom" or
"quoted-string", whereas 2822 does not permit a "quoted-string" for
any Received field component "item-value".
The problem with both 821/822 and 2821/2822 discrepancies is that the
SMTP document specifies message content (in the form of a Received
field component) which does not conform to the specified Message Format
syntax.