In <432743812(_dot_)1041338048(_at_)majormajor(_dot_)rem(_dot_)cmu(_dot_)edu>
Lawrence Greenfield <leg+(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
--On Tuesday, December 31, 2002 4:44 PM +0000 Charles Lindsey
<chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk> wrote:
No, the Usefor text is not recommending violating anything. The text I
posted here is entirely consistent the RFC 2047/2231 as regards all cases
that those RFCs appear to cover (and if it is not, then please tell me -
that is why it was posted here).
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.
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.
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.
Nor does the sometimes heard claim of "you should have participated in the WG
in order to express your opinion, now it is too late to do so" pass muster. The
review steps in the process that lie outside the group itself are there for a
reason. It is a task for the group to gain the support of the community for
what it wants to do, not for the rest of the community to have to partipicate
in the group in order for their opinions to be heard.
USEFOR is not being singled out here. Examples abound of cases where other WGs
have reached consensus on a document only to find out during one or more of
these external steps that the document isn't acceptable in its current form and
that their entire approach has to be reconsidered. Recent examples that come to
mind among my own WGs are the FAX CONNEG proposal, which received substantial
pushback during last call and is now being extensively revised, and the WebDAV
ACL proposal, which got tripped up on security issues during IESG review.
I'm afraid USEFOR needs to reconsider its entire approach in light of what the
reaction of the larger community to their proposal is certain to be.
Ned