Subject: #1028 Usefor 3.1.2 Timezones: Suggested text

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Jun 2005 09:44:51 +0200

Trying to get a simple one settled.....

Reviewing the discussion on #1028, I suggest the following modification:

OLD:

3.1.2 Date

 The Date header is the same as that specified in Sections 3.3 and
 3.6.1 of [RFC2822] with the added restrictions detailed in
 Section 2.2. However, the use of "UT" and "GMT" as time zones
(part
 of <obs-zone>), although deprecated, is widespread in news articles
 today. Therefore, agents MUST accept <date-time> constructs which
 include the updated <zone> construct below.

 orig-date = "Date:" SP date-time CRLF

 zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"

 Note that agents SHOULD NOT generate <date-time> constructs which
 include either "UT" or "GMT" and MUST NOT generate <date-time>
 constructs which include any other zone names defined by
<obs-zone>,
 some of which have ambiguous interpretations and would have adverse
 effects on the Netnews protocols.

NEW:

3.1.2 Date

 The Date header is the same as that specified in Sections 3.3 and
 3.6.1 of [RFC2822] with the added restrictions detailed in
 Section 2.2. However, the use of "GMT" as time zone
(part
 of <obs-zone>), although deprecated, is widespread in news articles
 today. Therefore, agents MUST accept <date-time> constructs which
 include the updated <zone> construct below.

 orig-date = "Date:" SP date-time CRLF

 zone = (( "+" / "-" ) 4DIGIT) / "GMT"

 Note that agents SHOULD NOT generate <date-time> constructs which
 include either "UT" or "GMT" and MUST NOT generate <date-time>
 constructs which include any other zone names defined by
<obs-zone>.

 Relaying agents SHOULD treat unparsed timezones as "GMT".
 Posting agents MAY reject articles with unparsed timezones.

(the last part may belong in USEPRO. But as Russ argues in another 
context... it affects the way you want to write your article parser....)

---

From: Henry Spencer <[email-masked]>
Date: Mon, 20 Jun 2005 10:46:43 -0400 (EDT)

> Reviewing the discussion on #1028, I suggest the following modification:

Looks reasonable... except that you've got one remaining mention of "UT"
(in the "SHOULD NOT generate") which is probably best removed -- without
the earlier context, it's pretty cryptic and probably unnecessary. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Russ Allbery <[email-masked]>
Date: Mon, 20 Jun 2005 08:25:46 -0700

>  The Date header is the same as that specified in Sections 3.3 and 3.6.1
>  of [RFC2822] with the added restrictions detailed in Section
>  2.2. However, the use of "GMT" as time zone (part of <obs-zone>),
>  although deprecated, is widespread in news articles today. Therefore,
>  agents MUST accept <date-time> constructs which include the updated
>  <zone> construct below.

>  constructs which include any other zone names defined by <obs-zone>.

> context... it affects the way you want to write your article parser....)

The first sentence of the last paragraph is a format issue.  The second
sentence is somewhat borderline, I agree, particularly since (unless I'm
mistaken) the format document hasn't really defined what rejecting an
article means.  But the common-sense definition is applicable, so it's not
a huge deal.

I do wonder whether that last sentence is even necessary, though, or
perhaps if it shouldn't instead be phrased as a caveat to the previous
sentence.  Maybe something like:

    Software that accepts dates with unknown timezones SHOULD treat such
    timezones as equivalent to "GMT".

The rule isn't specific to relaying agents, after all, and that sentence
leaves open the possibility that software may decide to not deal with such
timezones at all.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 20 Jun 2005 13:31:26 -0400 (EDT)

>    timezones as equivalent to "GMT".

Since GMT is a "SHOULD NOT" I'd prefer not to bless it.  Is there any
reason not to write '... equivalent to "+0000".'?

Seth

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 20 Jun 2005 21:57:16 +0200

Henry Spencer wrote:
 
> you've got one remaining mention of "UT" (in the "SHOULD NOT
> generate") which is probably best removed

#1028 => resolved

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 21 Jun 2005 09:04:15 +0200

> reason not to write '... equivalent to "+0000".'?

None that I can see. Good catch!

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 21 Jun 2005 10:39:23 GMT

>>  Relaying agents SHOULD treat unparsed timezones as "GMT".
                                 ^^^^^^^^
				 unparseable

>    timezones as equivalent to "GMT".

Yes, I prefer that, but I also accept Seth's point that it should be
equivalent to "+0000".

But is "EST" to be considered "unknown" for this purpose (I would have no
problem with that). Actually, it is not clear from Harald's text either.
Perhaps s/SHOULD/MAY/ if you want to be excessively liberal.

BTW, we don't say that "GMT" is to be interpreted as "+0000". OTOH, RFC
2822 says it for us, and we have mentioned that our "GMT" is a relic of
that <obs-zone>, so it _ought_ to be clear. Is everybody happy to leave
it at that?

-- 
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: Russ Allbery <[email-masked]>
Date: Tue, 21 Jun 2005 06:56:00 -0700

Charles Lindsey <[email-masked]> writes:

> problem with that).

I hope not; it's documented in RFC 2822.

> that <obs-zone>, so it _ought_ to be clear. Is everybody happy to leave

I am.  I don't want to duplicate information already in RFC 2822.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Jun 2005 18:34:05 +0200

Russ Allbery wrote:
 
>> But is "EST" to be considered "unknown" for this purpose (I
>> would have no problem with that).
 
> I hope not; it's documented in RFC 2822.

Harald's text was:

| zone = (( "+" / "-" ) 4DIGIT) / "GMT"

GMT is the only obs-zone you MUST accept.  By a general rule
elsewhere you MAY accept all 2822 obs- syntax incl. EST.

>> we don't say that "GMT" is to be interpreted as "+0000".
>> OTOH, RFC 2822 says it for us, and we have mentioned that
>> our "GMT" is a relic of that <obs-zone>, so it _ought_ to
>> be clear.

Yes.  Somebody fixed the "treat unparsed timezones as "GMT",
it became "treat unparsed timezones as +0000".  Later Charles
replaced "unparsed" by "unparseable".  I'd use "-0000" for
this problem, and putting it all together we would get:

| ...treat unparseable timezones as -0000.

Charles proposed to remove the "Posting agents MAY reject".
I'm not sure what Harald meant here, but "posting agents"
make no sense, it probably should be "injecting agents":

| Injecting agents MAY reject articles with unparseable
| timezones.

>> Is everybody happy to leave it at that?

Somehow we're now talking about slightly different texts and
interpretations, my "1028 => resolved" was wrong... ;-)  Bye.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Tue, 21 Jun 2005 12:58:10 -0400

> this problem, and putting it all together we would get:

Charles offered no explanation for that change.

Changing "unparsed" to "unparseable" is a complete change
in meaning.   "Unparseable" means that there is no possible way
to parse.

"Unparsed" seems correct to me, based on the "MAY accept other timezones"
language.

Charles?

---

From: Ken Murchison <[email-masked]>
Date: Tue, 21 Jun 2005 13:10:09 -0400

Since the ticket system doesn't appear to be able to CC to the list, I'm 
reposting here.

Based in the discussion of this ticket, here's what I currently have in
the document.  I removed the reference to "UT" and used Russ' text 
regarding unknown/unparsed zones:

The Date header is the same as that specified in Sections 3.3 and
3.6.1 of [RFC2822] with the added restrictions detailed in
Section 2.2. 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 include
the updated <zone> construct below.

Note that agents SHOULD NOT generate <date-time> constructs which
include "GMT" and MUST NOT generate <date-time> constructs which
include any other zone names defined by <obs-zone>.

Software that accepts dates with unknown timezones SHOULD treat such
timezones as equivalent to "+0000".

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Russ Allbery <[email-masked]>
Date: Tue, 21 Jun 2005 10:29:40 -0700

> Changing "unparsed" to "unparseable" is a complete change in meaning.
> "Unparseable" means that there is no possible way to parse.

> "Unparsed" seems correct to me, based on the "MAY accept other
> timezones" language.

I think he was copying a change I made in the wording.  "unparsed" doesn't
make any sense to me -- I'm not sure, reading the word, what it's supposed
to mean.

The idea, however it should be expressed, is that if you don't recognize
the time zone, you have to treat it as +0000 (or -0000, whatever).  Maybe
unrecognized would be a better word?

---

From: Russ Allbery <[email-masked]>
Date: Tue, 21 Jun 2005 10:30:36 -0700

> timezones as equivalent to "+0000".

This looks great to me.

---

From: Henry Spencer <[email-masked]>
Date: Tue, 21 Jun 2005 13:53:08 -0400 (EDT)

On Tue, 21 Jun 2005, Ken Murchison wrote:
> the document...

Looks good, with one minor caveat...

> timezones as equivalent to "+0000".

I go along with the earlier suggestion that this should be "-0000", which
is RFC2822ese for "treat as GMT but actual timezone uncertain".  In reader
agents, in particular, the distinction might be useful. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Jun 2005 20:05:42 +0200

Ken Murchison wrote:

> Software that accepts dates with unknown timezones SHOULD
> treat such timezones as equivalent to "+0000".

I'd say "-0000", the conventional "unknown whatever" notation.

If my guess what Harald meant was correct you've lost the MAY:

 Injecting agents MAY reject articles with unrecognized
 timezones.

But maybe that's not important, or I guessed wrong, bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 21 Jun 2005 22:20:33 -0400

> the updated <zone> construct below.

The "MUST accept" is no change from 2822.

> include any other zone names defined by <obs-zone>.

I really wish people would stop trying to impose such things on ABNF
grammar which is defined in documents outside of the scope of this WG.
Such attempts violate several principles which we've agreed on:
1. stay as close to 2822+MIME as possible.
   In this case, there's no need for a deviation; 2822 requires
   accepting "UT" and the standard 3-letter abbreviations.
2. where we have good cause to deviate, the article format is more
   restrictive.
   Allowing generation of something which is prohibited for generation
   by 2822 is clearly not more restrictive
3. backwards compatibility (see our charter).  Differences cause problems
   not only for UAs and gateways, but for messaging protocols (e.g. IMAP).
4. RFC 2822, MIME, IMAP, etc. are outside of our bailiwick; we have no
   authority to change them.
   orig-date and zone are part of 2822.

> timezones as equivalent to "+0000".

Aside from the issue of - rather than +, the more important issue is
that acceptance of broken date-time (illegal or missing zones) violates
all of the principles listed above.  Standard zones (in archived messages
or generated by 1036/822-compliant legacy software) really should be
treated as the equivalent standard offsets (as per 822/2822).  As the
1-letter zones were long ago botched and effectively convey no
information (RFC 1123), it would be reasonable to treat those as
equivalent to -0000, and indeed that is what 2822 recommends.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 22 Jun 2005 18:50:28 GMT

>   accepting "UT" and the standard 3-letter abbreviations.

We have agreed that all the 3-letter abbreviations are a Bad Thing and
should disappear from active use ASAP. To this end, we forbid their
generation within News, we do NOT REQUIRE acceptance except for GMT, but
you MAY accept them if you wish (as with all obs-syntax).

>   by 2822 is clearly not more restrictive

I agree. s/SHOULD NOT generate/MUST NOT generate/ in Ken's text (and
simplify wording further).

>   not only for UAs and gateways, but for messaging protocols (e.g. IMAP).

I see nothing in the proposal that will cause problems for other such
agents.

>all of the principles listed above.

True if you intend to propagate it further, but not if you are just trying
to decide whether to reject an article as "stale".

So if some particular injecting agent decides that "EST" is "unknown",
then it either swallows its pride and passes it on, or else it physically
replaces it by -0000 (I could write that into USEPRO if people wish).

If some particular relaying agent decides that "EST" is "unknown", (and
does not reject it as stale), then it either swallows its pride and passes
it on, or else it drops it on the floor.

Likewise a serving agent either stores it or doesn't.

So here is a suggested replacement:

Software MAY interpret an unknown timezone as "-0000" for the purpose of
comparing one <date-time> with another.

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 22 Jun 2005 18:26:25 -0400 (EDT)

> comparing one <date-time> with another.

How else is it allowed to treat it?  If it's not going to just drop it
on the floor for having an unknown zone, it's supposed to do a
comparison.  Are we specifying that software is allowed to treat EST
as +4600 if it wants?

Seth

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Jun 2005 22:08:55 +0200

Bruce,

>    accepting "UT" and the standard 3-letter abbreviations.

Section 2.1 of usefor-04 is very clear:

   News articles MUST conform to the syntax specified in Section 3 of
   [RFC2822].  Netnews agents MAY also accept the obsolete syntax
   specified in Section 4 of [RFC2822], but they MUST NOT generate
   productions of such syntax.

This is a deviation from RFC 2822, which says "MUST accept the obsolete 
syntax". Since this apparently had a previous consensus of the WG, I don't 
see that you can say that we have agreement on the principle.

>    by 2822 is clearly not more restrictive

Makes sense to me; others may have other opinions.
Are you suggesting (specific text change) that the doc says that systems 
MUST NOT generate GMT?

>    not only for UAs and gateways, but for messaging protocols (e.g. IMAP).

Are you referring to this charter text?

>The Goal of this working group is to publish a standards-track
>successor to RFC 1036 that with particular attention to backward
>compatibility, formalizes best current practice and best proposed practice.

>    orig-date and zone are part of 2822.

Are you proposing that we delete the ABNF description?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Jun 2005 22:08:55 +0200

Bruce,

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 23 Jun 2005 13:17:03 +0200

> agents, in particular, the distinction might be useful.

In the interest of civil list behaviour, I'll just say that my opinion on 
the usefulness of -0000 hasn't changed since this was proposed by Dan 
Bernstein in DRUMS.

Note that the following times:

12:00:00 +0000
12:00:00 -0000
08:00:00 -0400

are all equal according to RFC 2822. -0000 means "I'm not telling you my 
local timezone", not "I'm uncertain about the time".
The text proposed says that the following timezone:

12:00:00 NONSENSE

can also be considered equal to the above, if one chooses to accept it at 
all.

                           Harald

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 08:58:44 -0400

> should disappear from active use ASAP.

I do not recall any such agreement on such a wide-sweeping statement.
Can you supply a reference to support your assertion?

> To this end, we forbid their 

A UA which does not handle the standard "UT" and 3-letter abbreviations
is going to be unable to handle Date fields in archived articles; such
abbreviations were legal under RFCs 850 and 1036, and as recently noted
continue to be in use.

Now if you want to re-introduce separate syntax for Injection-Date (note
that we had that discussion years ago and decided to use date-time
*because* parsers for it already exist in news software), (to use your
own words) "then please ask Alexey to raise a USEPRO ticket for it".
 
> I see nothing in the proposal that will cause problems for other such

The Date field is used in all applications using the Internet Message
Format (mail, news, voice messaging, EDI, fax) and date-time is used in
a number of fields other than Date.  Changing the definitions of "zone"
and "orig-date" causes problems for combined news/mail UAs as well as
protocols that handle messages largely independently of specific
applications.

Again, if you want to make a special case for Injection-Date which is
proposed for news use only, that's a separate matter.
 
> to decide whether to reject an article as "stale".

The author's or authors' origination date has nothing to do with "staleness",
which in any event is a protocol issue, not a syntax issue.
 
> So if some particular injecting agent decides that "EST" is "unknown",

Clarification is needed (unless we simply use RFC 2822 by reference). "EST"
has always been a standard "known" zone abbreviation with a specific
equivalent offset (-0500).

> replaces it by -0000 (I could write that into USEPRO if people wish).

This person certainly does not wish so.  I believe that we have a principle
that message content should not be modified (except of course for Path and
similar trace fields).  Feel free to suggest a new ticket, but kindly do
not make arbitrary changes w/o WG discussion and Chair-declared consensus.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 09:50:15 -0400

> see that you can say that we have agreement on the principle.

I'm not convinced that there was any consensus on such a sweeping
statement.  With the exception of unquoted dot in obs-phrase, the
2822 obs-syntax covers deprecated constructs which were legal in 822.
In particular, "Netnews" user "agents" are going to need to be able
to handle the legal zone abbreviations which appear in archived
articles and which are still in current use.  It might be reasonable
to make specific allowances for *transport* agents...

> Are you suggesting (specific text change) that the doc says that systems 

I'm suggesting that for the purpose of the syntax & semantics document
(USEFOR) we simply use RFC 2822 date-time by reference.  Protocol-related
(e.g. transport) restrictions on use of format provisions in transport-
related fields can be specified in USEPRO, subject of course to discussion
and WG consensus.

> >compatibility, formalizes best current practice and best proposed practice.

Yes.  N.B. "with particular attention to backward compatibility".
 
> Are you proposing that we delete the ABNF description?

For orig-date and zone (both defined in RFC 2822), yes.

---

From: Henry Spencer <[email-masked]>
Date: Thu, 23 Jun 2005 10:11:59 -0400 (EDT)

On Thu, 23 Jun 2005, Harald Tveit Alvestrand wrote:
> > is RFC2822ese for "treat as GMT but actual zone uncertain".  In reader
> are all equal according to RFC 2822.

In the sense that they represent the same time, yes.  But there is extra
information there, *beyond* just the time, and in that respect they are
three different values.  To a reader agent, the first means "this guy is
on GMT", the third means "this guy is on EDT", and the second means "the
time is expressed in GMT but that might not be his real time zone". 

> -0000 means "I'm not telling you my 

I was speaking of the meaning to the *reader*, which is the relevant one
here, since we're talking about how to handle unknown zone indications. 
To a reader, -0000 means simply "sender's time zone is uncertain". 

Even a sender doesn't *necessarily* use -0000 to mean "I know but I'm not
telling".  It's conceivable for a system with users from multiple zones to
put that in because it isn't sure of the *user's* correct zone. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 10:22:37 -0400

> Note that the following times:

Yes.

> local timezone", not "I'm uncertain about the time".

The actual 2822 text is:
   Though "-0000" also indicates Universal Time, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than Universal Time and therefore
   indicates that the date-time contains no information about the local
   time zone.

> can also be considered equal to the above, if one chooses to accept it at 

2822, in discussion of obs-zone, says:

   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.

Aside from "+" vs. "-", do you believe that there is some difference in the
meaning of the text from the above 2822 quote?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 23 Jun 2005 17:12:44 +0200

--On torsdag, juni 23, 2005 10:22:37 -0400 Bruce Lilly <[email-masked]> 
wrote:

> Aside from "+" vs. "-", do you believe that there is some difference in
> the meaning of the text from the above 2822 quote?

I didn't remember that particular piece of 2822. Now that I read it - no, I 
don't think there is a difference.

Since Dan Bernstein's "-0000" got accepted to the degree that it is used 
here, I think pointing to this section (2822 section 4.3) is a perfectly 
reasonable thing to do.

>  timezones as equivalent to "+0000".

To:

Software that accepts dates with unknown timezones SHOULD treat such
 timezones as equivalent to "-0000", as specified in RFC 2822 section 4.3.

It may have some value pointing out that we're not changing anything.... 
shortening it to just "SHOULD be handled as 2822 4.3 says" makes the 
document harder to read.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Jun 2005 16:10:06 GMT

>comparison.  Are we specifying that software is allowed to treat EST

As USEFOR stands, the software MAY choose not to accept things in
<obs-zone> (except for GMT) or it MAY choose to accept (some or all) of
them.

1. If it has chosen to accept EST from the <obs-zone>, then it will interpret
it as the offset given in RFC 2822 and, if it is a relaying or serving
agent, pass it on and/or store it as received (for an injecting agent, I
accept also the possibility that it might try to fix it).

2. The case that the sentence under dicussion has to cover is where it has
chosen not to "accept <obs-zone>". So what does it do when "EST" (or even
"XYZ") turns up?

2a. Clearly, dropping it on the floor immediately is one possibility, in which
case that is the end of the matter.

2b. So we are down to the case where the software is written to be as liberal
as possible. In that case, it will try to pass it on/store it (leaving it
to the next agent in line to make its own mind up about
accepting/rejecting it). But first it wants to do a staleness check, and
for that purpose the porposed sentence says it MAY interpret either EST or
XYZ as -0000.

I think #1, #2a and #2b cover all the scenarios we want to envisage. If
you can think of a different scenario, then let's hear it.

---

From: Henry Spencer <[email-masked]>
Date: Thu, 23 Jun 2005 12:44:24 -0400 (EDT)

On Thu, 23 Jun 2005, Harald Tveit Alvestrand wrote:
> So maybe we can change [to]:

That seems sensible.

> shortening it to just "SHOULD be handled as 2822 4.3 says" makes the 

Agreed.  It may be more elegant in some sense never to say anything that
2822 already says, but in practice, it's terribly bad document design to
force people to flip back and forth (and search for the relevant sentence
of 2822; 4.3 is a page and a half long) even for small points. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 23 Jun 2005 13:19:50 -0400

> for that purpose the porposed sentence says it MAY interpret either EST or

All of those things are protocol issues.  I propose that we defer detailed
discussion of them to discussion of USEPRO.

date-time appears in precisely three fields: Date, Expires, and
Injection-Date.

Date and Expires are legacy fields, and will need to be interpreted per
long-standing rules.  RFC 2822 rules are perfectly suited to that.  RFC
2822 generation rules mean that those agents still using alphabetic
abbreviations won't be conforming to the specification.  Good reason
for them to be updated.  Nothing breaks whether or not they're updated.
Of course, only conforming implementations can truthfully be claimed as
conforming, but there's no enforcement...

Injection-Date is a new field; rules could be anything we want -- there
are few backward compatibility issues (the only one I can think of is
really an implementation issue (conversion of software which currently
uses the Date field)).  We could:
1. simply use the same RFC 2822 date-time syntax which is already
   specified for the field in -04
2. devise something different

As separately mentioned, we already discussed the syntax issue (earlier
syntax was specified in human-unfriendly, somewhat vague form).

We do need to decide on Injection-Date syntax for the USEFOR document.
Charles appears to be proposing something somehow different from 2822
date-time, although it's not clear exactly what.

I propose that we use RFC 2822 date-time as it stands, for the following
reasons:
1. compatible with existing parsers (same reason for the earlier syntax
   discussion for Injection-Date)
2. compatible with the legacy Expires field (practical server expiration
   and history will likely be a combination of local policy, article
   Expires field, and receipt date, possibly Injection-Date field).
3. Human-readable (for tracing purposes)

Discussion details re. injection and transport can be deferred to USEPRO,
however for purposes of making a syntax decision for Injection-Date, I
note that:
o Injection-Date is a new field.  If we use RFC 2822 as-is, that means that
  conforming implementations will only generate signed 4DIGIT numeric
  offsets and (for that field and conforming implementations) the issue of
  zone abbreviations arises only for the case on non-conforming generators.
  I now yield further discussion of the treatment of such non-articles to
  John Stanley.
o Given the new nature of that specific field, a simple note that the
  date-time-related obs- constructs do not apply to it precisely because
  it is not a legacy field could appear in some document (but I think
  that would be redundant).
o We could, in the USEPRO document, give special leave to agents to use
  a simplified parser for that field, one which does not handle the
  alphabetic zone abbreviations (because it is not a legacy field).
  Frankly I doubt that anybody will go through the trouble to write a
  special-purpose parser given the ready availability of efficient and
  tested date-time parsers.

Regarding specific text changes to Injection-Date draft text, I propose
no change (other than what might be required to the sentence/paragraph
beginning "see the" due to other issues).  I do not know specifically
what Charles proposes.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 24 Jun 2005 09:35:36 +0200

I have created ticket #1048 for this issue, with a "Discussion:" field of 
"Proposed no change", since that's what I ended up parsing Bruce's comment 
as.

This may be uncontroversial......

                 Harald

--On 23. juni 2005 13:19 -0400 Bruce Lilly <[email-masked]> wrote:

>> 1. If it has chosen to accept EST from the <obs-zone>, then it will
>> interpret it as the offset given in RFC 2822 and, if it is a relaying or
>> serving agent, pass it on and/or store it as received (for an injecting
>> agent, I accept also the possibility that it might try to fix it).
>>
>> 2. The case that the sentence under dicussion has to cover is where it
>> has chosen not to "accept <obs-zone>". So what does it do when "EST" (or
>> even "XYZ") turns up?
>>
>> 2a. Clearly, dropping it on the floor immediately is one possibility, in
>> which case that is the end of the matter.
>>
>> 2b. So we are down to the case where the software is written to be as
>> liberal as possible. In that case, it will try to pass it on/store it
>> (leaving it to the next agent in line to make its own mind up about
>> for that purpose the porposed sentence says it MAY interpret either EST
>> or XYZ as -0000.
>
> o Injection-Date is a new field.  If we use RFC 2822 as-is, that means
> that   conforming implementations will only generate signed 4DIGIT numeric
>   zone abbreviations arises only for the case on non-conforming
> generators.   I now yield further discussion of the treatment of such
> non-articles to   John Stanley.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 24 Jun 2005 15:43:02 GMT

> timezones as equivalent to "-0000", as specified in RFC 2822 section 4.3.

Yes, it seems we have been discussing something tht RFC 2822 had already
resolved.

As regards the wording you just proposed above, I would still prefer it to
be like:

    Software MAY accept dates with unknown timezones and SHOULD treat ...

Of course, whether some particular timezone is "unknown" is still
dependent upon whether or not you chose to accept all of the <obs-zone>.

As for the syntax and the rest of the text, I am happy with what Harald
proposed at the start of this thread, namely removing UT and just leaving
GMT as the only MUST accept / MUST NOT generate item.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 25 Jun 2005 11:56:26 -0400

> GMT as the only MUST accept / MUST NOT generate item.

Your comments seem to have been focused on use in the Injection-Date
field rather than on the legacy fields Date and Expires, which UAs
will need to be able to recognize, including the still-used alphabetic
abbreviations, which of course also appear in archives.

A ticket has been opened so that you can make a specific suggestion that
would address your concerns w.r.t. that specific new field without
adversely affecting the legacy fields.  Feel free to take advantage of
that opportunity.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Jun 2005 18:32:14 GMT

>                 Harald

Yes. I think the last thing we want is different syntax for the various
headers that use <date-time>. By all means, if sites want to use whatever
"MAY accept" discretion we give them differently for different headers,
then that is their choice.

AFAICS, the only two options open to us are to leave the syntax as Harald
recently proposed it, with just "GMT" on its own. Or else to replace that
"GMT" with the whole of <obs-zone>. Oh, and the generation of GMT or
<obs-zone) should be MUST NOT rather than the SHOULD NOT that is there at
the moment. Apart from that, the general "MAY accept obs-syntax" gives
everything else that is required.

I still prefer GMT on its own, and I think that was the consensus view as
Harald determined it when he opened this ticket. But it is Harald's call.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 28 Jun 2005 04:42:22 +0200

Charles Lindsey wrote:

> I still prefer GMT on its own

Add me, but without s/SHOULD NOT/MUST NOT/ please,
GMT is neither critical nor harmful.  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 28 Jun 2005 18:03:47 GMT

>GMT is neither critical nor harmful.

But our requirements would then no longer be a subset of RFC 2822's
requirements. As Bruce has pointed out, we should not be permitting
things that RFC 2822 forbids.

Yes, sites that still generate GMT will be non-compliant, and it will take
a while for the usage to fade away. There are a lot of things in our
drafts that are like that.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 05:24:13 +0200

> But our requirements would then no longer be a subset
> of RFC 2822's requirements.

Yes, that's exactly the idea of explicity mentioning GMT with
a SHOULD NOT, because Russ found it in way too many articles
for a decree to forbid it.

> As Bruce has pointed out, we should not be permitting

First Bruce proposed his new concept of a "SHOULD" as a "mere
recommendation", now you add a "SHOULD NOT" as a "permission".
Why don't you take 2119 as it is ?

| SHOULD NOT
| This phrase, or the phrase "NOT RECOMMENDED" mean that there
| may exist valid reasons in particular circumstances when the
| particular behavior is acceptable or even useful, but the
| full implications should be understood and the case carefully
| weighed before implementing any behavior described with this
| label.

"Valid resons in particular circumstances" include "old UA was
implemented before some mad IETFers invented new fancy rules"

| MUST NOT
| This phrase, or the phrase "SHALL NOT", mean that the
| definition is an absolute prohibition of the specification.
...................^^^^^^^^^^^^^^^^^^^^
MUST NOT means crashes, law suits, net abuse, harm, shoot on
sight, verboten.

 [2119 keywords]
| they MUST only be used where it is actually required for
| interoperation or to limit behavior which has potential for
| causing harm (e.g., limiting retransmisssions)  For example,
| they must not be used to try to impose a particular method
| on implementors where the method is not required for
| interoperability.

GMT _cannot_ cause harm, and that's the point of explicitly
mentioning it as a SHOULD NOT.  With the same MUST NOT as in
2822 that point would be moot.

> sites that still generate GMT will be non-compliant, and it
> will take a while for the usage to fade away. There are a
> lot of things in our drafts that are like that.

All these things, if they are very much like GMT, have to be
checked, MUST and MUST NOT aren't suited for wishful thinking,
they are about real trouble and harmful misbehaviour.  Bye