Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.

[Bruce Lilly <blilly@xxxxxxxxx>]

On Wed June 29 2005 07:21, Harald Tveit Alvestrand wrote:
> 
> Based on comments to Ken Murchison's text, I currently have the following 
> as resolution:
> 
>  [...] However, the use of "GMT" as a time zone (part of <obs-
>  zone>), although deprecated, is widespread in news articles today.
>  Therefore, agents MUST accept <date-time> constructs which use the
>  "GMT" zone.

2822 already requires that parsers accept the obs-zone abbreviations
(with additional remarks about the 1-letter abbreviations), so that
text is redundant and unnecessarily specific to "GMT".
 
>  NOTE: this specification does not change [RFC2822], which says
>   that agents MUST NOT generate <date-time> constructs which
>   include any zone names defined by <obs-zone>.
> 
>   Software that accepts dates with unknown timezones SHOULD treat such
>   timezones as equivalent to "-0000" when comparing dates, as specified
>   in [RFC2822] section 4.3.

There has been some discussion on list about the lack of clarity of
"unknown"; moreover, the suggested text implies that that is what RFC
2822 specifies, whereas the word "unknown" is not present in RFC 2822
at all.  The relevant 2822 text refers specifically to abbreviations
not included in the standardized ones which are in obs-zone for
compatibility with legacy software and archived messages; that text
is:

   Other multi-character (usually between 3 and 5) alphabetic time zones
   have been used in Internet messages.  Any such time zone whose
   meaning is not known SHOULD be considered equivalent to "-0000"
   unless there is out-of-band information confirming their meaning.

That text also refers to out-of-band information which is not mentioned
in the suggested text.

As implementers will need to read the normative RFC 2822 text, a simple
reference to section 4.3 of RFC 2822 should suffice.  Otherwise, the
text should be as close as possible (i.e. identical) to the relevant
2822 text so as to avoid misinterpretation (Charles has said that an
implementation might interpret "EST" as "unknown", which is certainly
not the intent of RFC 2822).

> (Since we're quoting requirements from 2822, I think it makes sense to put 
> the uppercase MUST and SHOULD in a NOTE - usually, it doesn't).

Quoting is OK; paraphrasing can lead to misinterpretations.

2005-06-30:1