Subject: #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.

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 13:27:48 +0200

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.

I have no idea how to turn the following into actionable text:

> So MUST means MAY except where (e.g. obs-phrase) MAY means MUST. Unless
> of course MUST means MAY again.

So I'm going to ignore it.

                    Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 13:38:12 +0200

--On torsdag, juni 30, 2005 11:59:18 -0400 Bruce Lilly <[email-masked]> 
wrote:

>> My reading of the text and the discussion is that the group wishes to
>> allow  a parser to NOT recognize "EST" as anything more valid than "ABC".
>> (Otherwise, the whole fuss about requiring handling of "GMT" would be
>> completely meaningless.)
>
> The WG discussion has been focused on comparisons of date-time in
> Injection-Date, whereas blanket statements about zone abbreviations
> affect legacy Date and Expires fields as well as any RFC 2822 and
> extension fields which may arrive via gateways.

I fail to see the support for this assertion....
Last 2 months' postings:

injection-date: mentioned in 14 messages
zone: mentioned in 93 messages

If this period is anything to go by, the discussion has been about date in 
general, not injection-date.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 1 Jul 2005 08:41:14 -0400

> > 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: <[email-masked]> (EDT) <[email-masked]>
  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)" <[email-masked]> <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.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 16:28:47 +0200

--On fredag, juli 01, 2005 08:41:14 -0400 Bruce Lilly <[email-masked]> 
wrote:

>   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.
>

I copied your whole message into the ticket. I was commenting on your 
"background information", which, to me, seems to state the issue you want 
solved rather than how to solve it, which is why I chose to quote that.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 1 Jul 2005 11:08:32 -0400

> general, not injection-date.

Harald, the discussion has been about comparisons for the purpose of
rejecting "stale" articles, which is the purpose served by the
Injection-Date field, whether or not it is mentioned by name in
the discussions.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Jul 2005 18:46:24 GMT

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>I'm mostly with Bruce.  I object to specific text mentioning allowing GMT to be
>treated as -0000, because in fact RFC2822 says to treat it as +0000 already.
>Why clutter the draft by repeating what RFC2822 says?

Hold on! I didn't see any text allowing GMT to be treated as -0000.

I did see text allowing ABC to be treated as -0000, and even for EST to be
treated as -0000 if you had not availed yourself of the "MAY accept"
applicable to the rest of <obs-zone>.

>I object to any phrasing "unknown timezone."  It's ambiguous.

"unrecognized timezone" would be better.

-- 
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: [email-masked]      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

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Jul 2005 20:17:37 GMT

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Frank Ellermann <[email-masked]> writes:
>> Russ Allbery wrote:

>The military time zones were deprecated by RFC 1123, and more tellingly,
>they also don't appear in practice.  I have no problem getting rid of them
>except insofar as it adds wording complexity.  But I *do* have a problem
>going straight from RFC 1036 to allowing servers to not even parse the
>North American time zones, which are still in use (albeit not heavily).

I think the likely harm is pretty minimal. User agents might present
articles in a funny order if some dates were interpreted 5 hours out, but
then the majority of user agents are also mail agents, so they are still
bound by RFC 2822.

And if some articles get considered as "stale" 5 hours too early, it is
not a huge deal.

I think the principles to establish are that:

1. We don't distinguish between Injection-Date and the other headers in
what we write.

2. The only options available to us are:

2a. As Harald's wording (only GMT is MUST accept)
2b. Accept all of <obs-zone> (probably apart from the military ones).

Whilst I still prefer 2a, I grant you there is an arguable case for 2b.

As regards IMAP, which Bruce raised, if an IMAP implementation sees "EST",
it should do whatever the IMAP standards say. That is not our concern.

---

From: Graham Drabble <[email-masked]>
Date: Mon, 04 Jul 2005 22:52:08 +0100

On 30 Jun 2005 "Forrest J. Cavalier III" <[email-masked]>
wrote in news:[email-masked]: 

> 
> I say that implementing an RFC2822-compliant date parser is "good
> enough" to reuse in netnews.  I disagree with forcing implementors
> should have to read this draft, and then wonder "gee, now that I
> read this tortured usefor-usefor-04 prose with references and
> modifications to RFC2822, do I have to do anything different, or
> can I just reuse my RFC2822 parsedate?" 

An RFC2822 date parser would be compatible with what I proposed. I 
suggested that they MAY implement the obs-zones and an RFC2822 parser 
will do so.

-- 
Graham Drabble
http://www.drabble.me.uk/

---

From: Graham Drabble <[email-masked]>
Date: Mon, 04 Jul 2005 23:00:11 +0100

On 01 Jul 2005 Bruce Lilly <[email-masked]> wrote in
news:[email-masked]: 

> On Thu June 30 2005 18:01, Graham Drabble wrote:
> 
>> FWIW I'm quite happy to allow them to do so. Nothing critical is
>> likely to break because something has the time +-12hrs so making
>> people code exceptions for things that were declared obsolete
>> (and MUST NOT generate) four years a go seems silly.
> 
> A few points to bear in mind:
> o if we paid due attention to backward compatibility, existing
> software 
>   will be largely conforming, and we're not making people code
>   exceptions because the 822 2- and 3-letter zone abbreviations
>   have long been required

New implementations would have to code exceptions to cater for 
something that everyone has been told they MUST NOT generate for four 
years. Existing parsing software would not need to change.

The changes are that existing generating software MUST stop generating 
the zone abreviations (which is in line with what 2822 told them), new 
parseing sofware can be simpler and people are told what to do with 
zones they don't recognise.

> o there exist archived messages (e.g. Frank's favorite non-Netnews
> but news-like mailing list interface gmane).  Many are more than
> four years old

The worst that happens is that something thinks they are 12 hours older 
/ younger than they are. In a old archive that is unlikely to matter.

> o FAQs and other old material may be periodically reposted with a
> new 
>   Injection-Date field, but with a Date field corresponding to the
>   last change.  That applies to things like a response to "can
>   somebody please post a copy of..." requests also.

That comes under the MUST NOT generate from 2822 which I haven't seen 
anyone arguing against.

> o combined mail/news UAs (the norm; Communicator, Thunderbird,
> Outlook 
>   Express, pine, etc.) need to deal with standard 2822 semantics
>   for the standard 2- and 3-letter zone abbreviations.

Such a beast would be conformant with what I proposed.

> o of course, "GMT" was also declared obsolete four years ago...

If you read my proposal carefully I don't mention GMT at all. However 
anyone not recognising it would still treat it correctly as they are 
told to assume -0000 (which is close enough to +0000 for it to not 
matter). Given that the only reason to special case it would be the 
amount that it is used and that it is in the middle of what can occur 
that seems reasonable to me.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 14:44:44 -0400

On Mon July 4 2005 18:00, Graham Drabble wrote:

> years.

Not quite.  Compliance with RFC 2822, or any other RFC is voluntary.
Obviously there is a great deal of software (ca. 23% according to
Russ' analysis) that have not yet chosen to conform to RFC 2822.

> Existing parsing software would not need to change. 

And so why exactly would somebody try coding a parser from scratch
rather than using an existing, tested parser?
 
> zones they don't recognise.

Let me get this straight.  You seem to think that handling some
46 valid offsets from -1200 to +1400 plus the special case exception
"GMT" is somehow simpler than handling those plus the 9 cases UT
and [ECMP][SD]T?   A hash table implementation can handle all of
those very simply and quickly, probably more so than any other
implementation; and such a hash table implementation already
exists as open source software.  So your argument, if I understand
what you seem to be asserting, simply doesn't hold water.

> That comes under the MUST NOT generate from 2822

No, it's not generated as new, just posted anew.