From: Bruce Lilly (blilly@erols.com)
Date: Wed Apr 14 2004 - 21:22:57 CDT
Henry Spencer wrote:
> (Re-sent after being bounced by the list outage. Original cc'ed to Graham
> Klyne <GK-IETF@ninebynine.org> but there's no reason to send it to him
> again.)
>
> On Fri, 2 Apr 2004, Bruce Lilly wrote:
>
>>>And as has been pointed out to you before, you read far too much into
>>>that title, especially since the first paragraph of 2822 says explicitly
>>>that it is for messages sent as electronic mail.
>>
>>And as has been pointed out to you before, the sentence to which you
>>refer has been copied verbatim since RFC 733...
>
>
> Correct. One might assume there was a *reason* why it was copied, i.e.
> the belief that it is still applicable.
The full text of that sentence is
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of "electronic mail"
messages.
Indeed that is the "framework", which dates back at least as far as
RFC 385 (1972), which predates all non-mail Internet electronic
messaging applications by a wide gap. Nowhere does RFC 2822 state that
it is applicable *only* to email, nor does it preclude the applicability
of the Internet Message Format to other applications.
Indeed, the specification of the message format has historically
(RFCs 561, 724, 733, 822, 2822) been separate from the mail protocol
specifications (RFCs 385, 524, ... 765, 772, 780, 788, 821, 976, 1204,
2033, 2476, 2821). If the format had been intended solely for use
with mail, it would have been specified with the mail protocols.
>>RFC 2822 defines a message format, and that format is used by mail
>>(RFC 2821) as well as fax, EDI, voice messaging, and other applications.
>
>
> Many of which are primarily meant to be layered on top of mail. And in
> any case, the fact that it is used unmodified by some other applications
> merely illustrates that this is possible, not that it is mandatory.
Applications use the message format (and in come cases transport protocols)
because that message format is widely implemented and highly successful
(likewise for the protocols). Indeed, both RFC 850 and RFC 1036 make
exactly that point (section 2 in each document) as the reason for use of
the established message format in preference to earlier Usenet formats.
It is of course possible for applications to use other formats. An example
would be the Paging application specified in RFC 1861 (q.v.; it contains
some discussion about the fact that established protocols had been suggested
and rejected by the author).
The reality in 2004 is that there are multiple combined mail/news user agents,
many gateways between mail and news, access to mail and news messages via
the Standards Track IMAP protocol (multiple server implementations operating
at many installations, several of which have large user populations), all of
which are dependent on a compatible format.
Certainly an alternative "Usenet" could be established which uses an
incompatible format. That would necessarily lose the advantages accrued
to Usenet through widespread support for the message format originally
developed for the "framework of electronic mail" and used now by many
applications -- common user agents, gateways, access via IMAP.
Continued use of a common message format by news and mail in that context
requires common definitions for critical common components including
message header fields, as has been the case from RFC 850 through RFC 1036.
Even if a completely separate format is developed for an alternative "Usenet",
it is desirable that common field names (assuming the format has something
identifiable as header fields) be used for compatible purposes -- among the
benefits expected from the registry are:
o discouraging multiple definitions of a header field name for
different purposes;
o encouraging convergence of header field name usage across multiple
applications and protocols.
It is difficult to imagine how such benefits might be achieved if multiple
applications provide multiple conflicting definitions for header fields with
a given name. That is diametrically opposed to the stated intent.