Subject: #1022: USEFOR 2.1 obs-phrase: Should dot be permitted in phrases?

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

I have filed ticket #1022 to cover this issue.

At the moment, section 2.1 of USEFOR-04 says:

 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 makes generation of obs-phrase (which allows unquoted dots in 
"phrase") forbidden.

I have failed to find a consistent message that someone is arguing that we 
should change this. I think Charles is arguing for a change, but I'm not 
sure   - either whether he really wants to change it, or what particular 
change he'd propose.

My instinct is "don't mess with other standards" and leave it as it is. Is 
someone arguing strongly that we should change it?

                       Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 3 Jun 2005 12:17:19 GMT

> productions of such syntax.

Actually, that is not quite right, because there is also an exception for
a part of <obs-zone> in section 3.1.2. 

You MUST accept "UT" and "GMT".
You SHOULD NOT generate "UT" and "GMT".
You MUST NOT generate "EST" or any of the other things in <obs-zone>.
You MAY accept "EST" or any of the other things in <obs-zone> (because of
that "MAY" in 2.1).

So that paragraph in 2.1 could more helpfully say:

 News articles MUST conform to the syntax specified in Section 3 of
 [RFC2822]. The obsolete syntax specified in Section 4 of [RFC2822] is
 excluded (except for some special use of <obs-zone> in section 3.1.2
 below [and any other exceptions we choose to make ....]); Netnews agents
 MAY accept that obsolete syntax but MUST NOT generate productions of it.

>sure   - either whether he really wants to change it, or what particular 

What I would like to see is <obs-phrase> (possibly renamed as
<extended-phrase>) treated as a special case with similar status to "UT"
and "GMT". I.e. MUST accept it, but SHOULD/MUST/whatever NOT generate it.
That aligns us with the way RFC 2822 is leading us. I would prefer SHOULD
NOT to MUST NOT generate, but that is a secondary issue.

Note that this exception was already included, years ago, in our 'article'
series of drafts, so I cannot understand why it was not automatically
carried forward into USEFOR.

2.1 would be the place to say it (see the "....." carefully left in my
syggested text), and there should be a pointer to that paragraph in RFC
2822 to explain the purpose of the exception.

>someone arguing strongly that we should change it?

I am trying not to "mess". Just to adopt a piece if RFC 2822 that we have
not adopted so far.

-- 
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: Bruce Lilly <[email-masked]>
Date: Fri, 3 Jun 2005 11:31:13 -0400

> You MUST accept "UT" and "GMT".

RFC 2822 already says that. No "exception" here.

> You SHOULD NOT generate "UT" and "GMT".

There has never been any convincing argument that there should be a
deviation from RFC 2822 (and RFC 1123) here.  Ancient implementations
might well be non-conforming to what we specify for requirements on
new generation, and no argument has been presented as to why that
should differ from 2822 (viz. use numeric offsets only for generation).
I.e., while this does represent an "exception", there has been no
justification for such.

> You MUST NOT generate "EST" or any of the other things in <obs-zone>.

Already covered by 2822.

> You MAY accept "EST" or any of the other things in <obs-zone> (because of

2822 says (in effect) MUST accept.  Again, no justification for a
difference, particularly as practice is and existing documents specify
acceptance.  Especially, there is no justification for simultaneously
being more restrictive (MUST accept -> MAY accept) for some alphabetic
zones and less restrictive (MUST NOT generate -> SHOULD NOT generate)
for one particular zone (purely coincidental that that happens to be
a Document Editor's zone, and that said Editor's mail to this mailing
list remains non-compliant with 2822 while the vast majority of
messages are compliant... :-).
  
>  MAY accept that obsolete syntax but MUST NOT generate productions of it.

Making it longer and more convoluted isn't "helpful".  Eliding it in
favor of "[RFC2822]" would be helpful.  A note explaining that legacy
UAs might be non-compliant with *this* specification could be argued
as either being a clarification or as being redundant.  My opinion is
the latter; at most a statement to the effect that non-conforming
implementations are non-conforming should be relegated to an Appendix.
"At most". 

> and "GMT".

As noted above, there seems to be no justification for the deviations;
it appears to be a personal prejudice.

> I.e. MUST accept it, but SHOULD/MUST/whatever NOT generate it. 

SHOULD NOT implies that generation is officially allowed, and would
adversely affect backward compatibility unless you can conclusively
show that no deployed parsers will experience difficulties (note that
the 2822 change was specifically to address such observed difficulties).
Lacking such a detailed analysis and in the absence of a convincing
argument in favor of a deviation, again "[RFC2822]" should suffice.

> I am trying not to "mess". Just to adopt a piece if RFC 2822 that we have

Then what precisely are the justifications for the deviations (BCP 14
keyword changes in date-time related issues and in your suggested
MUST NOT -> SHOULD NOT for obs-phrase)?

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 6 Jun 2005 16:36:14 GMT

>RFC 2822 already says that. No "exception" here.

Sigh! But we have already excluded that bit of RFC 2822 (so this is an
"exception" to that "exclusion").

>deviation from RFC 2822 (and RFC 1123) here.

>  Ancient implementations

There is substantial existing usage of UT and GMT. Therefore it _has_ to
be a MUST accept. It is, morevoer, important to get it right because the
News protocols _require_ <date-time>s to be compared for earlier/later (a
requirement that never arises in Email AFAIAW).

>Already covered by 2822.

Indeed, but worth reiterating because it would actually break the
protocols. BTW, please will someone remind me the name of that timezone in
Australia (wherever) that is abbreviated as "EST").

>....  Especially, there is no justification for simultaneously
>for one particular zone ...

It has said SHOULD NOT generate UT and GMT in our drafts for many years,
and nobody has complained before. I could easily be persuaded to promote
it to MUST NOT if someone asks for it. Are you formally proposing that?

> ... (purely coincidental that that happens to be

I do not find your smiley amusing, since you have made this snide remark
before. As I have explained to you previously, I read this mailing list in
a local newsgroup, and I have better things to do that spend time
upgrading my News software while this WG is still debating what News is
supposed to look like. As for the gateway from my news-server to this
list, there seemed little point in changing that "GMT", because it is a
MUST accept for Email.

>favor of "[RFC2822]" would be helpful.

That would be a technical change to the standard we are proposing. You are
usually the first to complain when editors make technical changes that the
WG has not discussed.

This WG decided. more years ago than I care to remember, that it was
ludicrous to REQUIRE all News software to be upgraded to accept
constructes that had Never Ever been seen in Netnews. They "MAY" accept
them, of course, and agents that are intended for joint Email/News use
likely will.

That decision have never been challenged since then. Why are you raising
it now?

>it appears to be a personal prejudice.

IIRC, it was you who asked for <obs-zone> to be brought within our
standard.

---

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

Charles Lindsey <[email-masked]> writes:

> There is substantial existing usage of UT and GMT.  Therefore it _has_
> to be a MUST accept.

There is substantial existing usage of PST/MST/EST too.  (And a quibble:
there is substantial existing usage of GMT.  I don't recall any usage of
UT at all.)

> protocols. BTW, please will someone remind me the name of that timezone
> in Australia (wherever) that is abbreviated as "EST").

Eastern Standard Time.  :)

However, in the Date header, EST has a protocol-defined meaning.

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Jun 2005 01:36:13 +0200

Charles Lindsey wrote:

> BTW, please will someone remind me the name of that timezone
> in Australia (wherever) that is abbreviated as "EST"

See <http://mid.gmane.org/[email-masked]> for
an opinion, but the whole thread is funny - Mark Davis meets
Clive Feather to discuss strange beasts like "BDT" = "British
Daylight saving Time"... ;-)  Apparently the NNTP "last call"
goes well, and LTRU is also almost ready with 3066bis.  Bye.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 7 Jun 2005 11:16:42 -0400

On Mon June 6 2005 12:36, Charles Lindsey wrote:

> protocols.

Precisely how would "PDT" "break the protocols" in a way that "UT"
would not?

> and nobody has complained before.

This is not the first time the issue has come up.  In any event, your
argument is a misplaced "appeal to tradition" fallacy.

> I could easily be persuaded to promote 

I have said about as clearly as possible that I feel that we should
conform to RFC 2822 format as closely as possible.  Since 2822 clearly
says MUST NOT generate for alphabetic zone indication, yes, that is
what I have proposed.  Specifically, I propose no deviations from
RFC 2822 regarding date-time format.
 
> constructes that had Never Ever been seen in Netnews.

You are mistaken in your implied assertion that handling of the standard
alphabetic zones for parsing would would be "constructes [sic] that had
Never [sic] Ever [sic] been seen in Netnews".  RFC 850:

   2.1.4  Date  The Date line (formerly   "Posted")   is  the
   date,  in  a  format  that  must be acceptable both to the
   ARPANET and to the getdate routine,

RFC 1036:

    The "Date" line (formerly "Posted") is the date that the message was
    originally posted to the network.  Its format must be acceptable
    both in RFC-822 and to the getdate(3) routine that is provided with
    the Usenet software.

I can of course dig up the aforementioned getdate routine source and
demonstrate that it accepts all of the standard RFC 2822 (deprecated
for new generation, required for parsing) alphabetic zone abbreviations
plus a slew of others.

As Russ has noted, there is *substantial* existing usage of alphabetic
zone abbreviations.

> That decision have never been challenged since then. Why are you raising

Again, this has been discussed before.

> IIRC, it was you who asked for <obs-zone> to be brought within our

References, please.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 7 Jun 2005 11:26:58 -0400

On Mon June 6 2005 19:08, Russ Allbery wrote:
> I don't recall any usage of
> UT at all.

Well, there's substantial use of "UTC", though that is not
and never has been a valid standard zone abbreviation in
date-time in the message format.  It's a violation of RFCs
561, 724, 733, 822, 850, 1036, and 2822.  Fortunately, nobody
has proposed accepting it as if it were valid.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 7 Jun 2005 13:11:33 GMT

>There is substantial existing usage of PST/MST/EST too.

Well I have never seen one, whereas when I last looked something like 20%
of articles in my news spool used GMT (and they weren't all from people
who lived in Greenwich :-) ).

>  (And a quibble:

That is true. UT just got dragged into the draft alongside GMT. It could
be omitted without loss.

>However, in the Date header, EST has a protocol-defined meaning.

Only in an obs- part of RFC 2822 which we have chosen to exclude (though
agents MAY use that interpretation if they want, and I suppose any
Australians who use it will be in breach of something, and their articles
will be discarded as 'stale', and they will put it down to some dastardly
pommie plot :-( ).

---

From: Russ Allbery <[email-masked]>
Date: Tue, 07 Jun 2005 10:39:35 -0700

>> I don't recall any usage of UT at all.

> Well, there's substantial use of "UTC", though that is not and never has
> been a valid standard zone abbreviation in date-time in the message
> format.  It's a violation of RFCs 561, 724, 733, 822, 850, 1036, and
> 2822.  Fortunately, nobody has proposed accepting it as if it were
> valid.

I was curious, so here are some actual numbers.

% cd spool/overview
% find -name \*.DAT -print > /tmp/files
% xargs cut -f 4 < /tmp/files | sed 's/ (.*)$//' > /tmp/dates
% wc -l /tmp/dates
3632585 /tmp/dates
% foreach zone ( GMT UT UTC EDT MDT CDT PDT )
foreach? echo -n "${zone}: "
foreach? grep $zone'$' /tmp/dates | wc -l
foreach? end
GMT:  780813
UT:       13
UTC:    3756
EDT:   30721
MDT:       1
CDT:      21
PDT:     216

Which is more than I thought.  MDT, CDT, and PDT are a lot less than I
thought.  Apparently someone does actually use UT, but maybe only one
person.  :)

---

From: Russ Allbery <[email-masked]>
Date: Tue, 07 Jun 2005 10:45:10 -0700

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

> Only in an obs- part of RFC 2822 which we have chosen to exclude

Our draft isn't actually published.  Given the best available *published*
protocol information that people currently have to work with, EST has a
protocol-defined meaning and UTC doesn't.

INN's date parser parses the full obs RFC 2822 syntax, plus some other
random junk, primarily missing leading zeros in time components and dates
without any time zone at all, but also including UTC and, well, all this
crap:

    { "CUT",    0 },                 /* Coordinated Universal */
    { "WET",    0 },                 /* Western European */
    { "BST",    1 * 60 * 60 },       /* British Summer */
    { "NDT",  (-2 * 60 + 30) * 60 }, /* Newfoundland Daylight */
    { "NST",  (-3 * 60 + 30) * 60 }, /* Newfoundland Standard */
    { "ADT",   -3 * 60 * 60 },       /* Atlantic Daylight */
    { "AST",   -4 * 60 * 60 },       /* Atlantic Standard */
    { "YDT",   -8 * 60 * 60 },       /* Yukon Daylight */
    { "YST",   -9 * 60 * 60 },       /* Yukon Standard */
    { "AKDT",  -8 * 60 * 60 },       /* Alaska Daylight */
    { "AKST",  -9 * 60 * 60 },       /* Alaska Standard */
    { "HADT",  -9 * 60 * 60 },       /* Hawaii-Aleutian Daylight */
    { "HAST", -10 * 60 * 60 },       /* Hawaii-Aleutian Standard */
    { "HST",  -10 * 60 * 60 },       /* Hawaii Standard */
    { "CES",    2 * 60 * 60 },       /* Central European Summer */
    { "CEST",   2 * 60 * 60 },       /* Central European Summer */
    { "MEZ",    1 * 60 * 60 },       /* Middle European */
    { "MEZT",   2 * 60 * 60 },       /* Middle European Summer */
    { "CET",    1 * 60 * 60 },       /* Central European */
    { "MET",    1 * 60 * 60 },       /* Middle European */
    { "EET",    2 * 60 * 60 },       /* Eastern European */
    { "MSK",    3 * 60 * 60 },       /* Moscow Winter */
    { "MSD",    4 * 60 * 60 },       /* Moscow Summer */
    { "WAST",   8 * 60 * 60 },       /* Western Australian Standard */
    { "WADT",   9 * 60 * 60 },       /* Western Australian Daylight */
    { "HKT",    8 * 60 * 60 },       /* Hong Kong */
    { "CCT",    8 * 60 * 60 },       /* China Coast */
    { "JST",    9 * 60 * 60 },       /* Japan Standard */
    { "KST",    9 * 60 * 60 },       /* Korean Standard */
    { "KDT",    9 * 60 * 60 },       /* Korean Daylight (no change?) */
    { "CAST",  (9 * 60 + 30) * 60 }, /* Central Australian Standard */
    { "CADT", (10 * 60 + 30) * 60 }, /* Central Australian Daylight */
    { "EAST",  10 * 60 * 60 },       /* Eastern Australian Standard */
    { "EADT",  11 * 60 * 60 },       /* Eastern Australian Daylight */
    { "NZST",  12 * 60 * 60 },       /* New Zealand Standard */
    { "NZST",  13 * 60 * 60 },       /* New Zealand Daylight */

I tried to get rid of some of it, but I got pushback from people who
didn't want existing dates to suddenly stop parsing, and finally gave up
and just tossed the whole time zone list from parsedate in when I rewrote
the date parser.

As I recall, something in the range of 10% of that list was actually in
use when I checked.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 05:08:41 +0200

Russ Allbery wrote:

> well, all this crap:

> { "CUT",    0 },                 /* Coordinated Universal */

Utter dubious, is that the 822 UT ?

> { "WET",    0 },                 /* Western European */

Utter dubious, where's GMT ?

> { "NDT",  (-2 * 60 + 30) * 60 }, /* Newfoundland Daylight */

Crap, skipping more crap...

> { "MEZT",   2 * 60 * 60 },       /* Middle European Summer */

Completely bogus, MESZ is "MittelEurpaeische SommerZeit"
 
> { "EAST",  10 * 60 * 60 },  /* Eastern Australian Standard */

That's the ambiguous EST beast.  Better delete this crap, it's
far beyond ridiculous, it's plain wrong.  What a headache, bye.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 07 Jun 2005 20:20:37 -0700

Frank Ellermann <[email-masked]> writes:

> far beyond ridiculous, it's plain wrong.

Except, see, it's not, because people use some of this nonsense in real
articles and the time zone they mean is, surprisingly enough, those.
Furthermore, Usenet software has interpreted those time zones as having
those meanings for something like fifteen years now, at least, so people
expect it.

Here's the question:  How do you plan on getting rid of this sort of thing
on Usenet?  I can tell you as a Usenet software author that whenever I try
to tighten date parsing, I get pushback from my users who want everything
that currently works to just keep working.  If I require that all times be
given properly zero-padded, for instance, it breaks some random Mac
off-line reader.  I then get asked "why do you have to do that, what
really breaks?"  I don't have a good answer for that question other than
"standards purity," which personally I'm down with, but which isn't a very
persuasive argument.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 08:05:56 +0200

Russ Allbery wrote:

> people use some of this nonsense in real articles

For sure not MEZT, the worst would be MESZ <shudder />

> Usenet software has interpreted those time zones as
> having those meanings for something like fifteen
> years now, at least, so people expect it.

I can understand the 822 and 1036 timezones, and I'm
not at all surprised that you got a lot of EDT in
your sample, IIRC EST / EDT used to be the default.

The other (undocumented) names are as you said crap.

> Here's the question:  How do you plan on getting
> rid of this sort of thing on Usenet?

For the 822 / 1036 stuff I can live with whatever
you, Bruce, Henry, and Charles say.  And if you say
"delete the 2822 obs-stuff" I'd be happy with it.

> I can tell you as a Usenet software author that
> whenever I try to tighten date parsing, I get
> pushback from my users who want everything that
> currently works to just keep working.

And here I was thinking that I'm the most conservative
"backwards compatibility" extremist of the world using
an ersatz-newsreader built 1996.

> I don't have a good answer for that question other
> than "standards purity,"

Tell them where the source is and where they'd find a
compiler.  Really, MEZT _is_ plain nonsense.  And MEZ
is CET, nobody uses the German abreviations outside of
Germany.  Not in the Internet...  okay, in Usenet you
get all the worst cases, and "deusenet" is Usenet as
it was 1995, but it's still state of the art s-o-1036:

| time     = hh ":" mm [ ":" ss ] space timezone
| timezone = "UT" / "GMT"
|          / ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]

See, no MEZ, MESZ, "MEZT", the worst case is a comment.

                    Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 8 Jun 2005 14:47:36 GMT

>thought.  Apparently someone does actually use UT, but maybe only one

But the clear prepondenance of GMT (21% of the total) is notable. But
where is the notorious "EST"?

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 8 Jun 2005 14:42:02 GMT

>Precisely how would "PDT" "break the protocols" in a way that "UT"

I am not aware what other zones use "PDT", but it is wll known that "EST"
in Australia means something at least 6 hours different from what it means
in America, and I also understand that it means something different again
in Estonia, where it will likely be six hours in error the other way.

It is just not realistic to suppose that servers in Australia will
interpret "EST" according to RFC 2822 (they will probably just hand the
zone off to the OS, and for sure that will take an Australian view of
time zones).

The proper operation of the News protocols requires date-times to be
accurate. They have to be compared, and articles get
accepted/rejected/expired on the basis of those comparisons. If an article
fails to get stored because its date-time is misinterpreted, that is bad.
But if the error is the other way round and it gets stored when it should
have been rejected as stale, then that is far worse because it can result
in looping (example of this were discussed at the time we were introducing
the Injection-Date header some months back).

>RFC 2822 regarding date-time format.

Then you have failed to answer the question I asked, which was in relation
to "UT" only.

"GMT" and "UT" are safe, in that _everybody_ understands them and
interprets them correctly. But if you follow RFC 2822 and say MUST accept
"EST" and the rest, then you cause actual harm (see above) and you force
some existing injecting agents which (quite correctly) refuse such zones
to be downgraded from a safe behaviour to an unsafe behaviour. We ought to
be moving in the opposite direction to that.

"GMT" is a special case, insofar as it is not ambiguous and is widely
used. So we MUST accept it for the time being.

>Never [sic] Ever [sic] been seen in Netnews".

Again, you avoid the issue by changing the question. We decided that
obs-syntax in general was a Bad Thing, and it would be an imposition to
demand that news agents should accept it all regardless (a point you
yourself once made, as you will doubtless recall).

There may be a few exceptions to that, and they need to be considered on
their merits (but GMT and obs-phrase are the only ones that have been
excepted to date).

>    both in RFC-822 and to the getdate(3) routine that is provided with

So what? There may well have been articles with strange zones in the past;
there are even a few even now. But nobody is going to reinject old
articles into the news transport system again (and I doubt any user agent
would refuse to display them anyway). It is the news transport where the
harm arises, and there is nothing gained by prolonging the agony.

>As Russ has noted, there is *substantial* existing usage of alphabetic

No, he has not noted that. Usage of GMT is indeed "substantial", but not
the others.

>Again, this has been discussed before.

References please.

>References, please.

www.imc.org/ietf-usefor/2003/Feb/0221.html

---

From: Richard Clayton <[email-masked]>
Date: Wed, 8 Jun 2005 16:37:35 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>where is the notorious "EST"?

it's summer in New York, Boston &c... so it's EDT at the moment :)

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 8 Jun 2005 13:16:28 -0400 (EDT)

"Charles Lindsey" <[email-masked]> wrote:

> But the clear prepondenance of GMT (21% of the total) is
> notable. But where is the notorious "EST"?

It's Daylight Saving Time in the US, so EST is EDT (the second most
common in the list).  (That also says something about the frequency
of Australia's EST, since it's their winter now.)

Seth

---

From: Russ Allbery <[email-masked]>
Date: Wed, 08 Jun 2005 11:50:18 -0700

> of Australia's EST, since it's their winter now.)

I didn't even check for EST.  Since I have a fairly long expire for some
groups (forever for a few), it won't tell you anything certain, though,
even if I did check.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 8 Jun 2005 20:40:18 -0400

On Wed June 8 2005 10:42, Charles Lindsey wrote:

> I am not aware what other zones use "PDT", but [...]

Charles, stop trying to evade the issue.  You made a claim with no
supporting evidence or reasoning, and you have been politely asked
to produce such evidence or reasoning.  Instead, you have tried to
evade the issue.  Will you kindly either provide a supporting line
of reasoning for your stated claim about PDT ("any of the other
things in <obs-zone>"), or failing that, retract your claim.

Your changing the subject to avoid addressing the issue is a waste
of time, which is a scarce resource.  Nevertheless, to put this
to bed...
> zone off to the OS, and for sure that will take an Australian view of

No, as Russ has already pointed out to you, the zones specified
in RFCs 561, 724, 733, 822 (as amended by 1123) and 2822 have a
specific protocol-defined meaning in date-time.  They do not, and
never have had, semantics of "just hand the zone off to the OS". As
John os fond of pointing out, software that does such things is just
plain broken and is therefore irrelevant to our standards work.

> Then you have failed to answer the question I asked, which was in relation

Do you see a special exception anywhere in RFC 2822 for "UT" vis-a-vis
MUST NOT generate?  Exactly which part of the word "yes" do you fail to
grasp?
 
> "GMT" and "UT" are safe, in that _everybody_ understands them
[...]
> used.

Last time I checked, there were at least a dozen well-known places named
Greenwich.  To use your (fallacious) argument, a (broken) news server
could presume that GMT meant the time at some local "Greenwich".

> Again, you avoid the issue by changing the question.

I have not changed anything, including the typos.

> We decided that 

I do not recall any such thing (*illegal* syntax is another matter,
and a requirement for parsing coupled with a prohibition against
generation in a document produced by a body that has no enforcement
arm cannot constitute a "demand").
 
[quotes from RFCs 850 and 1036 noting that date fields must conform to
RFC 822]
> So what? There may well have been articles with strange zones in the past;

We're not talking about "strange zones", we're discussing (now deprecated)
standard alphabetic zone abbreviations.  The relevant news article format
specification RFCs have always incorporated those -- there are in date-time
no "constructes [sic] that had Never [sic] Ever [sic] been seen in Netnews"
as you claimed.  Your accusation that I am "changing the question" is out
of place -- you are again trying to change the subject instead of either
defending or retracting your earlier claim.  No dice.  Stick to the subject.
Either substantiate your claim that using RFC 2822 date-time verbatim
would "REQUIRE all News software to be upgraded to accept constructes [sic]
that had Never [sic] Ever [sic] been seen in Netnews" or retract that
claim.  You may start with any particular category of "all News software"
and proceed to the others in any order of your choosing.

> No, he has not noted that. Usage of GMT is indeed "substantial", but not

Quote from <[email-masked]>:

You have called me a liar.  I have substantiated my claim.  Are you
also calling Russ a liar?

> >Again, this has been discussed before.

---------------------------------------------------
Message-ID: <[email-masked]>
Date: Tue, 19 Aug 1997 00:18:48 +0100
From: Ian Davis <[email-masked]>
Resent-Message-ID: <"COQv_2.0.0F3.rWD-p"@ambient>
Resent-From: [email-masked]

Here's my first cut at a draft for the Date header. I have taken two
liberties with the format of the time zone the implications of which
will need examining. Both of these are with a view to bringing the date
format closer to the ISO 8601 date and time standard and also to the
latest drums draft. They are: removing the space between the time and
the timezone and removing UT and GMT and other timezone names. I am
fairly confident that these changes are backwards compatible
[...]
---------------------------------------------------
Date: Tue, 15 May 2001 21:47:44 -0700
From: Brad Templeton <[email-masked]>
Subject: Re: RFC 2822 consequentials
Message-ID: <[email-masked]>

[...]
> Charles Lindsey <[email-masked]> writes:
> 
> > [There are just a few tidyings up in that syntax; nothing significant.
> > Observe that we rely on RFC 2822 for the syntaxt of date-time, excluding
> > their obs-syntax. This means we do not allow 2-digit years (and rightly
> > so) but we also do not allow ancient timezones such as GMT (it all has
> > to be +0100 now).  Do we want to relax that a little?]
[...]

Well, since lots of people are generating timezones like this, it would
have to be a rule to accept them, but not generate them.
---------------------------------------------------
Message-ID: <[email-masked]>
Date: Wed, 11 Sep 2002 02:39:27 -0400
From: Bruce Lilly <[email-masked]>
Subject: More draft 8 issues

[...]
    Also, 2.4.2's description of the 2822 obsolete
    syntax is somewhat puzzling; 2822 clearly states that the obs-
    forms MUST NOT be used in generation of new text messages, but
    MUST be recognized (so as to enable parsing of old messages).
    2.4.2 claims that the draft excludes the obsolete syntax, then
    says that it MAY be recognized, and then there are instances
    where obsolete syntax is *mandated* by the draft (e.g. "UT" and
    "GMT" for zone in 5.1).
[...]
---------------------------------------------------
Subject: Re: draft-kohn-news-article-01a.txt
From: Russ Allbery <[email-masked]>
Date: Mon, 10 Mar 2003 09:42:21 -0800
Message-ID: <[email-masked]>

[...]
> Section 3.3:

> Singling out "GMT" seems odd; other 822 alphabetic zones are also in
> common use.  It would perhaps be both simpler and better to say 2822's
> obs-zone MUST be recognized (but MUST NOT be generated).

I think you're probably right here.  There was extensive discussion of
this a while back in the USEFOR archives, including quite a few real
numbers on the Date headers seen on the wire.
[...]
---------------------------------------------------
That's a sample of discussions of the same date-time, obs-zone
issue spanning six *YEARS* (not including the current discussion).

> www.imc.org/ietf-usefor/2003/Feb/0221.html

That message has nothing whatsoever to do with obs-zone (the term is
nowhere mentioned in that message, nor is the subject matter).

---

From: Russ Allbery <[email-masked]>
Date: Wed, 08 Jun 2005 17:50:36 -0700

> zone off to the OS, and for sure that will take an Australian view of

I have never seen any news software that does this, and furthermore, given
that there is no OS facility short of changing TZ for the process that
could make head or tails of "EST" on Unix at least, I disbelieve in the
existence of software that takes this approach.

Software uses a hard-coded table listing time zone abbreviations and the
corresonding offsets.  That's the way all news (and e-mail, for that
matter) software I've ever seen has done this.  It's possible that there's
something out there that doesn't do things this way, but I'm still very
dubious that any sort of fallback to some OS facility is involved.

Furthermore, if you set TZ to EST in Australia, you most likely get the
same US zone as you would get anywhere else, since OS manufacturers are
not in the habit of modifying POSIX time zones depending on your locale.
For actual time zone configuration, nearly everyone switched to the Olson
approach a long time ago (which means you use things like
America/New_York, not EST).

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 9 Jun 2005 18:04:10 GMT

>existence of software that takes this approach.

Yes, I agree that particular scenario is unlikely, though it is quite easy
to hack the TZ tables in Unix to make EST mean whatever you like, and I
have no doubt that many Australian sysadmins will have done so.

But there are two more realistic scenarios.

1. It is also easy to hack the news software (indeed, the CNews sources
already contain the necesary line of code - and for Easter Island and East
Brazil too - just proteced by an "#if 0 .... #endif"). I worry that some
Australian newsadmin will have succumbed to the temptation.

2. Individual users may have configured their user agents with such
timezones (indeed, I suspect that is how the non-GMT examples arose in
your test). Guess what individual Australian users are likely to do.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 9 Jun 2005 18:37:54 GMT

>Charles, stop trying to evade the issue.

Whether or not "PDT" has clones is beside the point, unless you intend to
single out and permit the "safe" zones and deprecate the others. Which
would be most unwise IMO.

Here, for your general amusement, are the clones I have picked out of the
Cnews sources. I strongly suspect this list is but the tip of the real
iceberg :-( .

/*   text           token   lexval */
    "adt",          DTZ,    PACK(-180),     /* Atlantic DT */
    "adt",          DTZ,    PACK(-240),     /* Acre DT */
    "adt",          DTZ,    PACK(0),        /* Azores DT */
    "ast",          TZ,     PACK(-240),     /* Atlantic ST (Canada) */
    "ast",          TZ,     PACK(-300),     /* Acre ST */
    "ast",          TZ,     PACK(-60),      /* Azores ST */
    "bst",          DTZ,    PACK(60),       /* British Summer Time */
    "bst",          TZ,     PACK(-180),     /* Brazil ST */
    "cdt",          DTZ,    PACK(-180),     /* Chile DT */
    "cdt",          DTZ,    PACK(-240),     /* Cuba DT */
    "cdt",          DTZ,    PACK(-300),     /* Central DT */
    "cdt",          DTZ,    PACK(540),      /* China DT */
    "cst",          TZ,     PACK(-240),     /* Chile ST */
    "cst",          TZ,     PACK(-300),     /* Cuba ST */
    "cst",          TZ,     PACK(-360),     /* Central ST */
    "cst",          TZ,     PACK(480),      /* China ST */
    "edt",          DTZ,    PACK(-120),     /* East Brazil DT */
    "edt",          DTZ,    PACK(-240),     /* Eastern DT */
    "edt",          DTZ,    PACK(-300),     /* Easter Island DT */
    "edt",          DTZ,    PACK(660),      /* Australian Eastern DT */
    "est",          TZ,     PACK(-180),     /* East Brazil ST */
    "est",          TZ,     PACK(-300),     /* Eastern ST */
    "est",          TZ,     PACK(-360),     /* Easter Island ST */
    "est",          TZ,     PACK(600),      /* Australian Eastern ST */
    "fst",          DTZ,    PACK(120),      /* French Summer Time */
    "fst",          TZ,     PACK(-120),     /* Fernando de Noronha ST */
    "ist",          TZ,     PACK(120),      /* Israel */
    "ist",          TZ,     PACK(330),      /* Indian ST */
    "sst",          DTZ,    PACK(120),      /* Swedish Summer Time */
    "sst",          TZ,     PACK(-660),     /* Samoa ST */
    "sst",          TZ,     PACK(480),      /* Singapore ST */
    "wet",          TZ,     PACK(0),        /* Western Europe */
    "wet",          TZ,     PACK(60),       /* Western European Time */
    "wst",          TZ,     PACK(-240),     /* Western Brazil ST */
    "wst",          TZ,     PACK(480),      /* West Australian ST */

>I do not recall any such thing

No, you wouldn't. It must have been decided in 1997 or 1998, and has not
been challenged since, apart from the two exceptions for obs-zone and
obs-phrase which were also discussed agreed (in 2001 and 2003 respectively).

That is how the decisions made by the WG stand at the moment. By all means
propose further changes in this area, but do not pretend that those former
decisions were never made.

>nowhere mentioned in that message, nor is the subject matter).

Yes, I was confusing the <obs-zone> discussion with the <obs-phrase>
discussion. My apologies for that.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 09 Jun 2005 13:05:34 -0700

Charles Lindsey <[email-masked]> writes:

> Yes, I agree that particular scenario is unlikely, though it is quite
> easy to hack the TZ tables in Unix to make EST mean whatever you like,
> and I have no doubt that many Australian sysadmins will have done so.

I find this incredibly unlikely.  Why on earth would they do that rather
than just configuring the system to be in Australia/Sydney?

> already contain the necesary line of code - and for Easter Island and
> East Brazil too - just proteced by an "#if 0 .... #endif"). I worry that
> some Australian newsadmin will have succumbed to the temptation.

Also extremely unlikely; the comment says explicitly why not to do that.

> your test). Guess what individual Australian users are likely to do.

This is not the sort of thing that's likely to be a user-configurable
option in a news reader.  I've never seen a news reader that could be
configured that way.  The bogus time zones are probably due to bad choices
in writing the code, likely code that was written in the US and therefore
always used RFC 822-approved time zones in that context being run
elsewhere in the world.

I think your objections are on grounds that are very unlikely, and that
none of them warrant a diversion from RFC 2822.  EST has a well-defined
meaning as a time zone, for better or for worse, and news software has
been giving it that meaning for at least fifteen years.  I really do not
see how this could suddenly become some sort of huge interoperability
problem.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 9 Jun 2005 16:42:48 -0400

On Thu June 9 2005 14:37, Charles Lindsey wrote:
> Whether or not "PDT" has clones is beside the point

Then its rather telling that you keep changing the subject to that when
you are asked to substantiate your claims, viz.:

  You MUST NOT generate "EST" or any of the other things in <obs-zone>
  because it would actually break the protocols
and that it would
  REQUIRE all News software to be upgraded to accept constructes that
  had Never Ever been seen in Netnews

The simple fact is that the specific alphabetic zones listed in RFC
2822 parse grammar also appeared in RFC 822 (cited as the definitive
reference for date-time by RFCs 850 and 1036) and are in fact handled
by news software past (including B news) and present.  There is nothing
that "would actually break the protocols" as you claimed; obviously,
since those abbreviations have been in use for decades without
breakage (illegal cruft not in 822 is another matter).

For the purpose of specifying the date-time field component semantics
and syntax, I see absolutely no reason to deviate from RFC 2822 and
several very good reasons to defer the matter to 2822.

For protocol purposes, we can address handling of obs-zone by injection
and transport agents in the protocol document, which is a separate matter.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 04:31:50 +0200

Russ Allbery wrote:

>> Guess what individual Australian users are likely to do.
 
> This is not the sort of thing that's likely to be a
> user-configurable option in a news reader.

How about taking TZ as is ?  On my box I'd get this creature:

SET TZ=CET-1DST,3,-1,0,7200,10,-1,0,10800,3600

The CET would survive your table, but the "DST" is completely
bogus, I use it because IIRC MS C 6.0 wanted 3 letters.  Can't
check it at the moment, the C library sources are on an almost
dead disk (disabled until I find the place for the last "read"
attempt).

Don't worry, AFAIK nothing on my box uses "DST" for anything,
but in theory a very strange UA could try it.  And in theory I
could live in Eastern Australia and then, who knows.

The obs- timezone crap is as you said above all crap ;-)  Bye.

---

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

> The obs- timezone crap is as you said above all crap ;-)  Bye.

TZ has not, for many years now and perhaps ever, been bidirectionally
equivalent to the time zone abbreviation.  Some time zone abbreviations
are *also* valid TZ settings, but for instance the most common TZ setting
in my part of the US (prior to switching to the Olson scheme) would be
PST8PDT, which has never been valid as a zone abbreviation.

I doubt any software would use it that way.

What software *does* do is use the time zone abbreviation generated by the
system time zone libraries; most time zones do have assigned (often
ambiguous) abbreviations.  Heck, INN does this.  It just does it in a
*comment*, which is the right way to do it.  The comment is valuable
information (well, insofar as any human-readable time zone information is
valuable at least), since it lets you distinguish between, say, PDT and
MST without knowing the daylight saving date.

That abbreviation is unrelated to the TZ string, however.