In <01KQPSV8ZVPS009OMN(_at_)mauve(_dot_)mrochek(_dot_)com>
ned+ietf-822(_at_)mrochek(_dot_)com writes:
In
<432743812(_dot_)1041338048(_at_)majormajor(_dot_)rem(_dot_)cmu(_dot_)edu>
Lawrence Greenfield <leg+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
The draft proposes identifying MIME parts with message/rfc822 that do not
conform to RFC [2]822.
So? There is no requirement for message/rfc822 to conform to RFC [2]822,
as I showed. So please explain your problem more clearly.
Sure there is. See RFC 2046 section 5.2.1.
Yes, I have read section 5.2.1. Indeed I posted a large chunk of it here a
couple of days back. Here it is again:
A media type of "message/rfc822" indicates that the body contains an
encapsulated message, with the syntax of an RFC 822 message.
^^^^^^^^^^^^^^^
...............
It should be noted that, despite the use of the numbers "822", a
"message/rfc822" entity isn't restricted to material in strict conformance
to RFC822, nor are the semantics of "message/rfc822" objects restricted to
the semantics defined in RFC822. More specifically, a "message/rfc822"
message could well be a News article or a MIME message.
Clearly, strict RFC [2]822 compliance is not a requirement, and use for
News articles is explicitly encouraged (which is why Usefor makes it the
official way to encapsulate News).
The only requirement is that the syntax should agree with RFC [2]822, and
I have no problem with that since the proposed Usefor wording for gateways
that we are discussing explicitly requires that it should be so on the
Email side of the gateway, and tells you what transformations are
necessary to ensure it. So I still do not see what Larry's problem is.
It seems USEFOR is in need of a reality check. The IETF process doesn't consist
of "WG reaches consensus, standards track RFC is published, done". There are
also the pesky matters of AD review, IETF last call, and IESG review. And a
document that makes incompatible changes to any number of standards, changes
that break implementations done in good faith to those standards, is extremely
unlikely to pass all those steps, regardless of whether or not it wins
enthusiastic approval in the WG itself.
Yes, I know all that. But WG consensus comes first. Then what the WG
produces has to be sold to the wider community, and then maybe the IESG
asks for reconsideration of some issues.
Like it or not, one of the things RFC 1036 standardizes is the interoperability
of and ability to gateway between netnews and email. And this capability has
been used to advantage in IETF protocols like IMAP4, which has facilities
explicitly intended to accomodate netnews. This has led to countless
implementations of news<-->email gatways and IMAP4 servers that can access
news. It matters not at all if the USEFOR group unanimously dislikes such
things and thinks they are of no value. They exist in abundance and are based
on IETF standards, and therefore cannot simply be dismissed as irrelevant.
Actually, RFC 1036 does not standardize anything, because it is not a
standard. But, it never was the case, either in theory or in practice,
that RFC 1036 objects were fully compatible with RFC 822 objects. In fact,
Usefor is much closer to the mail standards than RFC 1036 ever was (for
example, comments were never a part of RFC 1036 headers, except for a few
specific cases, and much current Netnews software will barf when it sees
them).
You point about IMAP4 may need attention though. We were aware that some
IMAP servers attempted to provide a news capability, but not that there
were any such requirements in the IMAP standards. I need to look into
that.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5