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.
^^^^^^^^^^^^^^^
...............
The syntax of message/rfc822 does not include utf-8 in headers. Usefor does. As
such, they are not compatible. And this means that usefor messages are not
compatible with the message/rfc822 media type.
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).
Strict conformance is not a requirement, but restriction of the headers
to US-ASCII is most certainly a requirement. See the third paragraph
of the section.
You are engaging in sophistry here, and it will not fly.
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.
There are at least two issues here. First, section 6.21.2.2 of the news format
document explicitly calls for this use of the media type message/rfc822 to
label news messages that contain utf-8 in their headers. This violates the
definition of message/rfc822 given in RFC 2046, a draft standard, and hence is
simply unacceptable. There are sure to be media type handlers out there that
expect message/rfc822 to only contain US-ASCII headers.
Second, to the extent that the article format is extended to allow utf-8 in
headers, you have to explain how the many gateways of the world between netnews
and email, gateways which are good faith implementation of various RFCs, are
going to be able to accomodate the changes you have made and not cause damage
to the infrastructure when they are presented with something they do not
expect. If you cannot come up with a satisfactory explanation of how this
damage will be minimized past history indicates that you will not be allowed to
make such changes in an RFC.
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.
The question you need to be asking is whether or not coming up with something
that is extremely unlikely to ever be approved as-is and which it is very
likely will have to be completely redesigned is a useful way for the WG to
spend its time.
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.
More sophistry. While it is true the document doesn't have standard status in
the IETF, its title is "Standard for the interchange of USENET messages".
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).
Perhaps, but in most ways RFC 1036 was a subset, not a superset, of the
messaging standards. RFC 2046 only found it necessary to loosen a couple of
rules on RFC 822 to allow for netnews articles. What you are now proposing is a
very significant and incompatible extension.
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.
You need to look in to a lot more than that.
Ned