Re: #1053 USEFOR 2.1 Relationship to RFC 2822 (NEW: blanket statements vs. the law of unintended consequences, also Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.

[Bruce Lilly <blilly@xxxxxxxxx>]

On Fri July 1 2005 07:27, Harald Tveit Alvestrand wrote:
> 
> Bruce,
> 
> as I've said about your previous attempts to raise general issues (#1030, 
> #1031), a statement of an issue that is so unclear that it's impossible to 
> tell whether or not we agree on its meaning is not good for forward 
> progress.
> 
> I'm assigning this as ticket #1053 with title "Relationship to RFC 2822", 
> in the belief that the actionable part of your message is that you want it 
> made clear:
> 
> > While the 2.1 text says "MAY" it doesn't specifically say that it
> > overrides 2822, so it's not 100% clear.  It's unclear what the order
> > of precedence is in interpreting 2822 vs. 2.1 vs. the presumably
> > agreed-upon obs-phrase text, etc.

No, I said:
  I propose eliminating the blanket
  statement in section 2.1 (i.e. the second sentence of the first paragraph),
  with the understanding that that does not preclude adding limited-scope
  relaxation of specific parts of 2822 obs-syntax parsing requirements
  where appropriate and where justifiable.

What you quoted was background information, not a proposal.  The hint
is the words, "I propose", which was perhaps too subtle; I apologize
for any confusion such subtlety might have caused.

Harald, as I've said before, if you believe something is unclear, just
ask a question, on-list or off-list, and I'll do my best to clarify.

More background explanation:
The text and proposed text for the 2.1 MUST means MAY except when is means
MUST is far too convoluted and (IMO) hasn't been thought through carefully.
As a result, there are all sorts of unexpected problems that will cause
trouble for unsuspecting implementers, e.g. the phrases in obs-references
in existing messages.  To recap that for those who haven't been following:
o it has been conjectured that a comment in a References field, e.g.
    References: <a@xxxxxxxxxxx> (EDT) <b@xxxxxxxxxxx>
  would spell doom for the Internet by causing interoperability problems
  because some hypothetical UA wouldn't be able to figure out what to do
  with the comment "(EDT)".  That in turn, if true, would warrant MUST NOT
  language regarding comments.
o Apparently however, by some mysterious mechanism yet to be explained,
  only comments in *new* messages would cause trouble; those in existing
  messages would apparently somehow be benign.
o because MUST means MAY except when it means MUST, UAs would not be required
  to be able to correctly parse obs-references, which permits a phrase,
  even though that was part of RFC 822 syntax and remains required for
  parsing the Internet Message Format (RFC 2822)
o there exist messages such as
  http://article.gmane.org/gmane.ietf.usenet.format/9644/raw
  (that example contains:
  References: Seth Breidbart's message of "Thu, 11 Jun 1998 22:20:30 -0400  (EDT)" <199806120220.WAA22874@xxxxxxxxxxxxxxxx> <l03110701b1a6dd2075a3@[206.222.209.12]>
  ).  Although somehow (it's not clear *exactly* how) the presence of
  an "(EDT)" comment free-standing is supposed to wreak havoc, it seems
  to be conjectured that somehow a phrase containing exactly the same
  characters (as well as others) will be completely benign.  That
  stretches credulity beyond the breaking point.

It is my considered opinion that no amount of convolution is going to
be able to deal with all of the complexities and still remain comprehensible
to readers of the specification and its normative references.  I also
believe that we haven't the time to go through all of RFC 2822 and all
of USEFOR and USEPRO (which are incomplete) to find all places where a
blanket statement would lead to problems (and would therefore require
more convolution to make an exception to the exception to the exception).
It is my further opinion that the most practical way to deal with the
situation is to start from the position that our primary normative
reference, viz. RFC 2822, applies in full, and that we make specific,
limited-scope exceptions such as may be necessary, after due deliberation
to ensure that the exception is not harmful.  And so I have proposed.