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

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 29 Jun 2005 13:21:38 +0200

Based on comments to Ken Murchison's text, I currently have the following 
as resolution:

 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 use the
 "GMT" zone.

 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.

The main change is deleting the ABNF (unneccesary) and doing the import of 
unknown timezones in a NOTE rather than in normative text.

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

Makes sense?

                     Harald

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 14:32:33 +0200

Harald Tveit Alvestrand wrote:

> The main change is deleting the ABNF (unneccesary) and doing
> the import of unknown timezones in a NOTE rather than in
> normative text.

Okay.  The first statement in the note is dubious, I'd prefer
s/any/other/ resulting in:

  this specification does not change [RFC2822], which says
  that agents MUST NOT generate <date-time> constructs which
  include other zone names defined by <obs-zone>.

You already said that GMT is deprecated and MUST be accepted.
MUST NOT generate and MUST accept is a general 2822 obs-rule.
MUST NOT generate and MAY  accept is the usefor-0x  obs-rule.

If you change the latter to 2822-style for GMT it's better if
you only say "deprecated",  Besides "other zone names" can be
read as "unknown zone names", then the next statement below
your 'Note' is clearer:

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

We don't want "-0000" for GMT, after s/any/other/ the "+0000"
for GMT is more obvious.

About #1022, you proposed:

| 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], and
| MUST accept the "UTC" timezone (see section 3.1.2) and the
| obs-phrase construct (see [RFC2822] section 4.1) but they
| MUST NOT generate productions of such syntax.

s/"UTC"/deprecated "GMT"/ and delete "but they MUST NOT" etc.

> Trying to revoke RFC 2822's prohibition against generating
> them is, to my mind, not something we should be doing in
> this WG.

Just don't talk about it, combining MUST accept with MUST NOT
generate is odd, I prefer "SHOULD NOT generate" in such cases.

                          Bye, Frank

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 29 Jun 2005 11:43:47 -0400 (EDT)

> generate is odd, I prefer "SHOULD NOT generate" in such cases.

I agree it's odd.  I still think we should do it.  "MUST accept"
because there's a lot of software that generates it and will continue
to, so failure on that point affects interoperability.  "MUST NOT
generate" because there's no reason to allow generation (there are
better equivalents) and allowing more than FRC 2822 (it says "MUST NOT
generate") is something we ought to do only with very good reason;
oddness of wording isn't such a reason.

Seth

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 18:47:07 +0200

Seth Breidbart wrote:
 
> I agree it's odd.  I still think we should do it.
[...]
> "MUST NOT generate" because there's no reason to allow
> generation

Yesterday Charles wrote something in the direction of
SHOULD NOT => permission, and now you apparently propose
SHOULD NOT => allowed.  Do all here think that a SHOULD
(NOT) is something like "please (not)", or worse that
SHOULD NOT is just a shorthand for "of course you can" ?

There is a reason to allow generation, legacy software.

Russ found mumble (more than 10% IIRC) GMT timestamps,
and unlike the also popular EDT / EST a GMT is harmless.

> allowing more than FRC 2822 (it says "MUST NOT
> generate") is something we ought to do only with very
> good reason; oddness of wording isn't such a reason.

Decreeing that legacy software is non-conformant without
good reason is also a dubious idea.  And in my parallel
universe it's not allowed to implement any new software
generating GMT if the specification says "SHOULD NOT" -
legacy software is the only possible excuse in this case.

                       Bye, Frank

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 29 Jun 2005 13:09:35 -0400 (EDT)

> SHOULD NOT is just a shorthand for "of course you can" ?

I think that SHOULD NOT is more permissive than MUST NOT.

"MUST NOT" = don't do it.  Period.

"SHOULD NOT" = don't do it unless you have a good reason.

> There is a reason to allow generation, legacy software.

That's a reason to require acceptance (which we all agree should be
done).

> good reason is also a dubious idea.

So the question is which is worse: being _more permissive_ than RFC
2822 (which we aren't anywhere else, are we?) or decreeing that legacy
software is non-conformant with a new spec?

>  And in my parallel universe it's not allowed to implement any new
> software generating GMT if the specification says "SHOULD NOT" -

Unfortunately, some implementors won't agree with you.  They'll find
other reasons that are good enough for them.  (At least, that's my
guess.)

> legacy software is the only possible excuse in this case.

I suspect people are more ingenious at coming up with excuses than you
believe.

Seth

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Wed, 29 Jun 2005 13:29:48 -0400

> SHOULD NOT is just a shorthand for "of course you can" ?

"All" here?  Please don't be ridiculous!

We need not care about people who cannot read and
correctly understand RFC2119 language.   We can ignore
that they exist when writing.

That leaves us with the ability to use RFC2119 terms
as defined.  So "SHOULD NOT" means "do it this way
only if you have no good alternative in full awareness
and consideration of the pain you cause yourself or
others."

> legacy software is the only possible excuse in this case.

There are N different ways that legacy software will not
conform to these drafts.  To me, that means that making
legacy software non-conformant is not a serious factor
in making a choice over one wording or another, with timezones or
anything else.

BTW, does RFC2822 use the "MUST NOT" language for this?  Instead
I think it says "zone MUST be within the range -9959 through +9959"
That is subtly different.

A "MUST NOT" is taken to mean that something breaks, so a MUST NOT
GENERATE/MUST ACCEPT may be correct, but I agree is kind of weird.
I like the RFC2822 "MUST generate/MUST accept" instead.  (...which we
need not repeat.)

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 08:59:34 -0400

On Wed June 29 2005 07:21, Harald Tveit Alvestrand wrote:
>  [...] However, the use of "GMT" as a time zone (part of <obs-

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

> the uppercase MUST and SHOULD in a NOTE - usually, it doesn't).

Quoting is OK; paraphrasing can lead to misinterpretations.

2005-06-30:1

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 30 Jun 2005 16:19:23 +0200

> not the intent of RFC 2822).

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

This requires permitting the interpretation of "EST" as "unknown", which is 
not the intent of RFC 2822, but is (in my interpretation) the intent of 
this working group.

If anyone but Bruce wants to argue in favour of recognizing *all* timezones 
mentioned in RFC 2822, which is the logical consequence of Bruce's 
argument, please speak up now.
If there is none, I'll declare this issue closed.

                            Harald

---

From: Russ Allbery <[email-masked]>
Date: Thu, 30 Jun 2005 07:32:20 -0700

Harald Tveit Alvestrand <[email-masked]> writes:

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

I think this is a very iffy decision to make.  I can see not caring about
any time zone other than the RFC 2822 ones, but really, I don't see a lot
of excuse for not parsing all of the traditional textual time zones.

> If anyone but Bruce wants to argue in favour of recognizing *all*
> timezones mentioned in RFC 2822, which is the logical consequence of
> Bruce's argument, please speak up now.

I'll argue in favor of that, since otherwise we would be going from
blessing use if reluctantly (RFC 1036) to allowing parsers to disregard
them without any intervening deprecation period.

It would surprise me if there are any existing Usenet date parsers that
don't handle all of the RFC 2822 zones with the exception of the badly
specified and almost never seen military zones.

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

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 11:59:18 -0400

> (Otherwise, the whole fuss about requiring handling of "GMT" would be 

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.

> not the intent of RFC 2822, but is (in my interpretation) the intent of 

My interpretation is that some WG members might favor that for
Injection-Date specifically (although no text has been proposed
even though there is an open ticket for that purpose), but I see
no discussion that explicitly supports interpreting "EST" as unknown
in the legacy fields.

I have made a constructive comment on the specific text proposed,
which was somewhat vague (as previously discussed on-list by others).
If you believe that some clear wording specifically addressing EST
appearing in *any* date-time in *any* field is the WG consensus,
then by all means counter-counter-propose some text that says so
clearly rather than by providing a vague back door, and we can
debate that along with your original proposal and my two counter-
proposals.  I believe it was you who said that specific text change
proposals followed by debate on the open list was the simplest way to
decide consensus.

You proposed specific text; I carefully reviewed it and commented,
making two alternative counter-proposals addressing a specific
(vagueness) issue:
1. Simply refer to 2822 section 4.3
2. Repeat verbatim the relevant 2822 text (which I quoted so that
   it can be seen as a *specific* text change)

I'll also paraphrase what I wrote before: some people here are
reluctant to suggest specific text because of tendencies to:
o twist around what is suggested
o reject such suggestions by fiat
o nitpick
none of which are conducive to open debate (yes, I have changed
the order of "debate" and "open", and not accidentally).  I'll
leave it to individual readers to decide whether or not that is
an accurate characterization of past WG activity and its
consequences, and whether or not it continues to be a problem.

> argument[...]

No, I have not argued in favor of recognizing the 1-letter zone
abbreviations -- in fact I have gone to some effort to make that
clear by specifically mentioning them.  Nor have I argued in favor
of recognizing the "Other multi-character (usually between 3 and
5) alphabetic time zones" mentioned in RFC 2822, and I have also
made that clear by specific mention.

If you have a question about what I mean, by all means ask for a
clarification (on-list or off) and I'll do my best to provide one,
but please don't put words in my mouth.

2003-06-30:a (responding to specific issues)

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Jun 2005 18:02:34 +0200

Russ Allbery wrote:

>> If anyone but Bruce wants to argue in favour of recognizing
>> *all* timezones mentioned in RFC 2822, which is the logical
>> consequence of Bruce's argument, please speak up now.

> I'll argue in favor of that, since otherwise we would be
> going from blessing use if reluctantly (RFC 1036) to allowing
> parsers to disregard them without any intervening deprecation
> period.

Sigh.  That's the point of this thread.  It's a general design
principle of USEFOR to replace 2822 "MUST accept obs-ceneties"
by a "MAY accept" keeping the 2822 "MUST NOT generate".

So when Bruce wrote...

| that text is redundant and unnecessarily specific to "GMT"

...it's only his POV because he disregards the general design
principle.  Of course it's necessary to say "MUST accept GMT"
if the general rule is only a "MAY accept".  And of course
this essentially switches GMT back to the obs-2822-MUST-rule.

That's exactly what we want.  And otherwise "you MAY parse it,
else you SHOULD treat it as unknown -0000" is fine.  And as a
bonus we get a GMT => +0000 effect if Harald uses s/any/other/

If Bruce doesn't like "unknown" s/unknown/other/ is perfectly
clear, "anything not covered by numerical 2822-timezones or
the deprecated GMT or whatever you still MAY parse".

> It would surprise me if there are any existing Usenet date
> parsers that don't handle all of the RFC 2822 zones with the
> exception of the badly specified and almost never seen
> military zones.

That's in Bruce's obs-package, we're cherry picking, and IMHO
reducing this to the one cherry GMT is an excellent choice for
new parsers.

If an old / other parser wants more cherries it has a MAY and
a place (2822 obs-) to find them.  And if that has some weird
side effects for an erroneous EDT or EST it's not our fault.

Really, can we close this #1028 now ?  I promise that I won't
mention the utter dubious "MUST NOT generate GMT" anymore if
we stick to the general design priciple "no obs-ceneties excl.
GMT".  And the obs-phrase in Keywords: etc. <shudder />  Bye

---

From: Russ Allbery <[email-masked]>
Date: Thu, 30 Jun 2005 09:19:32 -0700

> Sigh.  That's the point of this thread.  It's a general design principle
> of USEFOR to replace 2822 "MUST accept obs-ceneties" by a "MAY accept"
> keeping the 2822 "MUST NOT generate".

I've clearly missed the point of the thread, and I'm sorry about that.  I
was previously responding to the language about GMT and was also looking
primarily at the generate side.  I had not realized that people were
talking about not accepting the North American time zones.

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 we need one more step between here and there.

> That's exactly what we want.  And otherwise "you MAY parse it, else you
> SHOULD treat it as unknown -0000" is fine.

No, I don't agree that this is fine.

> That's in Bruce's obs-package, we're cherry picking, and IMHO reducing
> this to the one cherry GMT is an excellent choice for new parsers.

I also don't agree with this.

> Really, can we close this #1028 now ?

Apparently not.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 30 Jun 2005 15:57:50 +0200

> text is redundant and unnecessarily specific to "GMT".

Bruce, I have not heard anyone but you arguing that *all* OBS-syntax should 
be accepted. Can you now shut up about this issue, or raise an issue that 
specifically suggests alternate text for 2.1, where we say that OBS-syntax 
is a "MAY" accept, not a "MUST" accept?

Acting as if we had changed 2.1 when we have not is ... not useful.

                          Harald

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 13:22:52 -0400

On Thu June 30 2005 12:02, Frank Ellermann wrote:

> if the general rule is only a "MAY accept".

No, such text and any purported "design principle" were replaced
by the specific text in Harald's proposal, which replaced the specific
text in Ken's proposal, proposed to replace the specific text in
the current draft.

> clear,

I disagree. If the intent is to contradict 2822, which is a
normative reference, then it's necessary to state so unambiguously,
especially where is affects a 2822 field such as Date.  I don't
believe such a contradiction can fly (see below).

> That's in Bruce's obs-package, we're cherry picking

Speak for yourself.  I want no cherry-picking.

IMAP is the Internet Message Access Protocol, which is used to
access mail and news and other messages.  There is a protocol
extension draft, mentioned in this WG several times, which provides
a mechanism for a client (UA) to request the server to collate
message order by factors including the Date field.  The client
and server deal with messages; there is no artificial distinction
between "news" and "mail" and "other".  IMAP is a Standards Track
protocol compliant with RFCs 822, 850, 1036, and 2822, among
others.  Given such a request, how do you propose that such a
server should treat a message in a folder containing the field
  Date: 30 Mar 2001 12:34:56 EST
Three-part question: do you believe that should be treated as
having 822/2822 semantics (equivalent to -0500) or as -0000,
why, and do you believe that you can convince IMAP implementers?

2003-06-30:c

---

From: [email-masked] (Ralph Babel)
Date: Thu, 30 Jun 2005 19:36:38 +0200

Harald Tveit Alvestrand wrote:

> Bruce, I have not heard anyone but you arguing that *all*
> OBS-syntax should be accepted. Can you now shut up about
> this issue, [...]

Just couldn't resist.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Jun 2005 20:34:32 +0200

Bruce Lilly wrote:
 
> any purported "design principle" were replaced by the
> specific text in Harald's proposal

He didn't write "MUST accept GMT" as redundant rule, as you
claimed, but because it's an exception from the "MAY accept",
and because MUST and MAY are different.

And the "MAY accept" is certainly not only "purported".

> If the intent is to contradict 2822, which is a normative
> reference, then it's necessary to state so unambiguously

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

That's unambiguous, and one of the tickets added text for the
two exceptions (MUST accept GMT and obs-phrase) explicitly.

> Speak for yourself.  I want no cherry-picking.

It was in a reply to Russ, and Russ wants the "North-American"
cherries without the military zones.  You may now please stop
telling me what I can write or not, unless I'm plain wrong.

But while we're at it, of course you'd be also cherry-picking
if you'd want some obs-2822-rules but not others.  

And whatever IMAP might do, if it simply ignores "GMT" all is
fine, "GMT" is the same as +0000.  None of our business, we're
not inventing new time zones different from 2822.  Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Thu, 30 Jun 2005 11:57:03 -0700

Frank Ellermann <[email-masked]> writes:

> cherries without the military zones.

Not exactly.  What I'd really like to do is not deviate from RFC 2822 any
more than is absolutely necessary, and I think that treating the North
American time zones as unknown when RFC 1036 said they were fine is an
iffy decision.  What I was trying to say about the military zones is that
I don't *care* about them, and I don't think that the RFC 1036 concern is
applicable there since they were already deprecated by other standards.
However, I would much prefer to adopt RFC 2822 as verbatim as possible
without cherry-picking.

The main thing that's going to get in the way of that is not supporting
time zones, but rather accepting additional junk in the middle of the Date
header.  INN does already handle the full obs syntax of RFC 2822 in the
current development version, but I can understand why other software
authors don't want to be bothered with folding and comments, particularly
since there's no good reason for having either other than consistency with
mail.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 15:02:25 -0400

On Thu June 30 2005 09:57, Harald Tveit Alvestrand wrote:

> be accepted.

Harald, I don't believe that I have have said so, especially not with
that emphasis.  I have said that I believe that we should adhere to
2822 as closely as possible, making specific exceptions where there is
some justification.

[oh, my!]
> raise an issue that  

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

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.

Blanket statements flout the law of unintended consequences and lead to
convoluted rules such as the above.  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.

> Acting as if we had changed 2.1 when we have not is ... not useful.

OK.  Among other not-useful things:
o presenting text in isolation which refers to section 2.2 but not 2.1
  where 2.1 may be applicable

Plenty of blame to go around.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Jun 2005 21:49:44 +0200

> "SHOULD NOT" = don't do it unless you have a good reason.

ACK, and don't use these 2119 keywords where it's unnecessary.
Necessity includes "potential to cause harm".  Or here also
all "differences from 2822".

Based on that I got "don't quote MUST NOT generate GMT", but
it's of course also a matter of taste to a certain degree.

> the question is which is worse: being _more permissive_
> than RFC 2822 (which we aren't anywhere else, are we?) or
> decreeing that legacy software is non-conformant with a
> new spec?

Charles apparently intends to be more permissive about some
length limits (78 and 998), I'm not sure at the moment. 

BTW, it's not that I wanted any explicit "SHOULD NOT generate
GMT", I only didn't like the explicit "MUST NOT generate GMT",
because there's neither a potential harm nor any difference
from 2822.  Maybe that's a bit too shrewd... ;-)

>> in my parallel universe it's not allowed to implement any
>> new software generating GMT if the specification says
>> "SHOULD NOT" -
 
> Unfortunately, some implementors won't agree with you.
> They'll find other reasons that are good enough for them.
> (At least, that's my guess.)

Yes, that's possible.  And Bruce's IMAP "sort-by-date" example
was interesting.  I know nothing about IMAP and trust that Ned
or Bruce would tell us if we're about to screw up.  So far I
don't see a problem, except from "Russ wants some problematic
time zone names as a MUST accept", which would put us back to
square one.  

I'm happy with only GMT, eliminating the complete zone name zoo
is also very tempting.
                         Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Jun 2005 22:28:46 +0200

Russ Allbery wrote:
 
> What I'd really like to do is not deviate from RFC 2822 any
> more than is absolutely necessary

Sounds like you want the complete obs-stuff in and then maybe
exclude some of the worse nightmares explicitly.  In theory
it's possible that we'd arrive at the same subset with this
strategy, but in practice I doubt it

I would want to get rid of the "North-American" zones because
they are known to cause harm (= folks outside of North-America inventing
their own zone names, or new semantics for existing
names, maybe I'd insist on I18N considerations for this stuff,
it's a can of worms combined with ugly ratholes).

> I think that treating the North American time zones as
> unknown when RFC 1036 said they were fine is an iffy
> decision.

Combined with the general "MAY accept obs-stuff" everybody can
pick what he likes best.  With "MAY do this" on one side, and
"SHOULD do that" on the other side, is there still a realistic
chance to get it completely wrong, e.g. reject such articles ?

> I can understand why other software authors don't want to be
> bothered with folding and comments

[CFWS] is only at the end of 2822 <date-time>, ignoring it is
no problem.  The other 2822 [FWS] and FWS should be also okay.

Otherwise your preference of "2822 as verbatim as possible"
has a problem, "obs-zones but no FWS" is IMNSHO no option.

It's in theory possible to copy the 2822 <date-time> ABNF with
its numerous obs-rules, and then delete those that we don't
like.  OTOH we tried that already.  Harald's proposal is the
cleanest solution for me.
                          Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Jun 2005 18:56:08 GMT

>There is a reason to allow generation, legacy software.

No. You misunderstand the intention of our standards.

Legacy software does all sorts of things which we don't want them to do
any more.

Therefore, we write our standard so that those legacy implementations
become non-compliant (because that is a good carrot to encourage them to
be upgraded).

OTOH, of course, we so arrange things (by making transitional/fallback
arrangements where necessary) that the legacy software can continue to
interoperate at least for the medium term (long term, in some future
standard, we may outlaw some such things entirely, but that will be
somebody else's decision to take).

-- 
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: Thu, 30 Jun 2005 18:48:44 GMT

> Therefore, agents MUST accept <date-time> constructs which use the

But you are now giving the same normative rule (MUST accept "GMT") in two
places, which is not usually a good idea. Better to say

  ... hence the reason why section 2.1 REQUIRES its continued
  acceptance (but not generation).

>Makes sense?

Yes.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 30 Jun 2005 17:44:10 -0400

> argument, please speak up now.

Harald, you misinterpreted silence as lack of thought on this issue.  You
are way to quick to declare "no action needed" in this case.

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?

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

Then again, I don't really care if all other timezones are treated -0000
either.   RFC2822 already says the military zones, as if they ever show up
on Usenet!, should be treated as -0000.  (Which is something Russ was
concerned about I think he wrote.)

The list of obs-timezones in RFC2822 is short and unambiguous, just 8
zones, deferring to that text is not going to burden implementors any
more than putting up with all the other RFC2822 baggage.  And I'd rather
8 unambiguous things to implement than interpreting any of the text
that overrides RFC2822 I've seen proposed for this.

Sure, Anyone who writes or maintains date parsers will tell you there is
all sorts of cruft that you see in Date fields.  That's why INN's date parser
is written in yacc, and at 500+ lines it's a nightmare to modify/understand.
Who wants to touch that?  And for what?  So that you can accept some cruft
like H:M:S expressed as 5:6:00 and no zone or swahili time?  Who cares?  It's
a stupid date field, parse invalid dates as 1/1/1970 as far as I care about
fixing problems as stupid as that.

But there is something I do care about.....

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?"

---

From: Russ Allbery <[email-masked]>
Date: Thu, 30 Jun 2005 14:53:51 -0700

Forrest J Cavalier <[email-masked]> writes:

> all sorts of cruft that you see in Date fields.  That's why INN's date
> parser is written in yacc, and at 500+ lines it's a nightmare to
> modify/understand.  Who wants to touch that?

Thankfully, it's not that bad any more.  It's now pure C, and including
the code to parse NNTP dates ("20050630 174410" sorts of things that are
completely different than what we're talking about) and code to generate
the Date header, it's now:

   869   288   |date.c
----------------
   869   288    total lines/statements

   258  lines had comments        29.7 %
    38  comments are inline       -4.4 %
    93  lines were blank          10.7 %
    18  lines for preprocessor     2.1 %
   538  lines containing code     61.9 %
   869  total lines              100.0 %

The yacc stuff couldn't even handle the full RFC 2822 obs syntax, and
allowed all sorts of nonsense that really no one should ever use in a
Usenet Date (and no one does).

---

From: Graham Drabble <[email-masked]>
Date: Thu, 30 Jun 2005 23:01:08 +0100

On 30 Jun 2005 Bruce Lilly <[email-masked]> wrote in
news:[email-masked]: 

> no discussion that explicitly supports interpreting "EST" as
> unknown in the legacy fields.

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. My view would be to go with 
something like:

Agents MAY accept the obs-zone syntax specified in RFC2822 section 4.3 
but MUST NOT generate it. Any zone that the agent is unable to parse 
SHOULD be treated as -0000.

This way even if they don't follow the MAY accept they SHOULD still get 
GMT right.

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

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 19:37:18 -0400

On Thu June 30 2005 18:01, Graham Drabble wrote:

> 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
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
o while an Injection-Date field could not have been generated 4 years ago
  (as it was not then, and is not yet, standardized), that doesn't apply
  to Date, Expires, etc.  There remains the possibility of a special
  exemption for Injection-Date.
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.
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.
o of course, "GMT" was also declared obsolete four years ago...

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Jul 2005 02:10:30 +0200

Bruce Lilly wrote:

> o there exist archived messages

Sure, no reason to consider e.g. the A-News format.

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

Sorting by date, yes, but in that case "MUST accept"
doesn't necessarily imply "interpret correctly".

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

Unlike the rest of this zoo, that was declared obsolete
11 (eleven) years ago:

| timezone   = "UT" / "GMT"
|            / ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]
[...]
| This is a restricted subset of the MAIL date format.
[...]
| The timezone name in parentheses, if present, is a comment;
| software MUST ignore it, except that reading agents might
| wish to display it to the reader.  Timezone names other than
| "UT" and "GMT" MUST appear only in the comment.
|
|  NOTE: Attempts to deal with a full set of timezone names
|  have all foundered on the vast number of such names in use
|  and the duplications (for example,  there  are at least FOUR
|  different timezones called "EST" by somebody).  Even the
|  limited set of North American zone names authorized by MAIL
|  is subject to confusion and misinterpretation.  Hence the
|  flat ban on non-UT timezone names except as comments.
|
|  NOTE: RFC 1036 specified that use of GMT (aka UT, UTC) was 
|  preferred.  However, the local time (in the poster's
|  timezone) is arguably information of possible interest to
|  the reader, and this requires some indication of the
|  poster's timezone.  Numeric offsets  are an unambiguous way
|  of doing this, and their use was indeed sanctioned by RFC
|  1036 (that is, this is a change of preference only).

Now is it already time again to go through the WG Charter,
find s-o-1036 as relevant, etc., the whole drill for every
minor point with a minor difference from RFC 2822 ?  Bye