ietf-822
[Top] [All Lists]

Re: Interpretation of RFC 2047

2002-12-19 10:34:50

Keith Moore wrote:
That includes RFC 1894 Original-Envelope-ID,
Reporting-MTA, DSN-Gateway, Received-From-MTA, Remote-MTA,
Original-Recipient, Final-Recipient; RFC 2298 Diagnostic-Code,
MDN-Gateway, and probably Reporting-UA (there is an ambiguity in the
Reporting-UA ABNF, but that does not affect this issue).


these are not message header fields; they are part of specific
content-types.  surely you don't think that the 822 syntax should
be applied to message bodies also?

RFC 822 does give a syntax for message bodies, though not as succinctly
as 2822 section 3.5.  But that's not the point, and I suspect wasn't
what your question was addressing.

MDNs and DSNs are rather unusual MIME multipart messages. The fields
(N.B. they are described as fields in those RFCs) are in fact defined
using RFC 822 syntax (both RFCs predate RFC 2822):

1894:

   The body of a message/delivery-status consists of one or more
   "fields" formatted according to the ABNF of RFC 822 header "fields"
   (see [6]).

2298:

   The body of a message/disposition-notification consists of one or
   more "fields" formatted according to the ABNF of RFC 822 header
   "fields" (see [2]).

So the short answer is that in the specific case of MDN and DSN
content in the second part of the multipart/report (viz. the
message/delivery-status or message/disposition notification), RFC
822 syntax is applicable[*].  Given a hypothetical parser capable
of parsing RFC 822 headers, that parser could be capable of parsing
those MDN and DSN fields (excepting the Reporting-UA ambiguity).

Regarding the issue of identifying comments, the 822 rules for
comments would be applicable -- clearly one can't have a comment per
se in the parts of those fields which are specified as *text, but
comments might appear next to parts defined as atom, for example.

The problem with the Reporting-UA specification in 2298 and drafts
of its successor is that the specification

     reporting-ua-field = "Reporting-UA" ":" ua-name
                          [ ";" ua-product ]

     ua-name = *text

     ua-product = *text

is ambiguous, as it is impossible to determine whether

  Reporting-UA: foo ; bar ; baz

does or does not have the optional ua-product, and if so, which
of the semicolons delimits its start. That is because *text does not
exclude semicolons, so those might be part of the ua-name. The
issue could be resolved by redefining

  ua-name = domain / phrase

which provides for the usage recommended in the text of 2298 (via domain)
and also provides for any special characters which might be used
under the current specification, provided that they are quoted as
required for a phrase. [actually, the "domain" part of the proposed
redefinition would become superfluous at such time that 2822 is revised
to formalize '.' in a phrase as suggested in 2822 section 4]

The use of phrase could be interpreted as permitting 2047 encoded-words.
It might even be desirable to redefine ua-product as phrase, as it is
not inconcievable that a product name might need to be encoded and/or
specify charset or language. Likewise for many of the other MDN and
DSN field parts currently defined as *text, as well as the Usefor
draft's proposed User-Agent header field.

-----------
* that is the case because the MDN and DSN fields explicitly specify use
of 822 header field sysntax. It would not apply to the "fields" in a
text/directory media type, for example, since those so-called "fields"
are not defined in accordance with RFC 822 header field syntax.