Subject: Re: empty quoted strings and other oddities
From: Russ Allbery <[email-masked]>
To: [email-masked]
Date: Mon, 30 Sep 2002 21:27:51 -0700
List-Id: <ietf-822.imc.org>

Bruce Lilly <[email-masked]> writes:

> RFC 2822 permits (as did 822) a quoted string which
> consists solely of a pair of DQUOTE characters.  It's
> not clear what the semantics of that are or ought to be.

> Likewise, a domain literal can consist solely of the
> square brackets.

> The combination of the two means that the following is
> syntactically valid as an angle-addr or msg-id:

> <""@[]>

> Perhaps these empty contructs could be relegated to obs-
>   status in the next revision, with the generate syntax
> changed to use 1* instead of * for the content within a
> quoted-string and domain-literal.

qmail makes use of this to prevent internal double-bounces from bouncing
again.  Whether that use is worthwhile or not is possible debatable.

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

Date: Mon, 30 Sep 2002 23:49:10 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: empty quoted strings and other oddities
Sender: [email-masked]

RFC 2822 permits (as did 822) a quoted string which
consists solely of a pair of DQUOTE characters.  It's
not clear what the semantics of that are or ought to be.

Likewise, a domain literal can consist solely of the
square brackets.

The combination of the two means that the following is
syntactically valid as an angle-addr or msg-id:

<""@[]>

Perhaps these empty contructs could be relegated to obs-
  status in the next revision, with the generate syntax
changed to use 1* instead of * for the content within a
quoted-string and domain-literal.

Date: Tue, 17 Sep 2002 09:40:39 +0200
To: Russ Allbery <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: radical suggestion
Cc: [email-masked]
Sender: [email-masked]

At 13:14 -0700 02-09-14, Russ Allbery wrote:
>It's really frustrating to try to code to an amended standard.  The W3C
>does this from time to time, and I find it almost impossible to keep track
>of what the *real* standard is without actually printing out the original
>standard and then going through the amendments and noting them on the
>printout by hand.

This is a problem with the way IETF standards are
published - as RFCs which cannot be modified except
by publication of a new RFC. And then the new RFC
does not really cause any change in the text of
the amended RFC.

Note that the RFC index sometimes includes phrases
like (Obsoletes RFC2543), (Updated by RFC3265) or
(Status: Historic).

Perhaps this text in the RFC index should also
be copied into the heading of the RFC itself?

Does the heading of an RFC really contain
for example "Status: Draft standard" for a document
which is in reality "Historic"? If so, is this
right? If not, then the original text of an RFC
can in reality be changed after publication!
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Mon, 16 Sep 2002 20:11:16 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Keith Moore wrote:
>>An analysis of 9419 recent
>>email meesages shows 109 with such offsets, all in the range
>>-1500 to -1900 (and all of those messages are spam).
> 
> 
> yet another telltale spam clue (for now).
> 
> Keith

I have found (and others have independently found) that
Spam often has fouled-up Date headers (another common
foul-up in the zone of spam is a long zone name such as
"Eastern Standard Time").

And message-ids are often also fouled-up, because spammers
tend to send some random garbage in HELO (or EHLO), which
many MTAs simply copy as the "domain" part of the message-id
(when generating one and if the message already lacks a
Message-ID header).

It's not uncommon for fields with addresses (To, From,
Reply-To, etc.) to have bad syntax in spam.

From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: drums2? 
Date: Mon, 16 Sep 2002 15:52:28 -0400
Sender: [email-masked]

> An analysis of 9419 recent
> email meesages shows 109 with such offsets, all in the range
> -1500 to -1900 (and all of those messages are spam).

yet another telltale spam clue (for now).

Keith

Date: Mon, 16 Sep 2002 15:07:48 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Keith Moore wrote:
>>I've seen things like -0801 (where upon inquiry, the responsible
>>party said it was intended to account for a leap second -- how
>> 1 second was magnified into 1 minute is baffling).
> 
> 
> even more baffling is the leap second affecting the time zone _offset_.
> 
> (actually I am hard pressed to see how anyone could make that kind of
> coding mistake, much less come  up with such a lame justification)

I believe it was a case of system [mis-]configuration (and not
limited to a single system, BTW) rather than coding per se.
Here's an actual header:

Received: from Menudo.UH.EDU by Sony.COM (5.65+/1.34)
         id AA01465; Fri, 10 Jan 92 13:32:47 -0801

I haven't seen -0801 recently (but I haven't looked hard).
There are still numeric offsets used which do not
correspond to any time zone. An analysis of 9419 recent
email meesages shows 109 with such offsets, all in the range
-1500 to -1900 (and all of those messages are spam).

Date: Mon, 16 Sep 2002 09:18:23 +0100
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: drums2? (timezones)
Sender: [email-masked]

FWIW, RFC3339 allows timezones in the range +/- 23:59, with minutes in the 
range 0-59.  This was not, not my awareness, the result of any deep 
consideration, but the way the syntax happens to come out.

[[
    date-fullyear   = 4DIGIT
    date-month      = 2DIGIT  ; 01-12
    date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                              ; month/year
    time-hour       = 2DIGIT  ; 00-23
    time-minute     = 2DIGIT  ; 00-59
    time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                              ; rules
    time-secfrac    = "." 1*DIGIT
    time-numoffset  = ("+" / "-") time-hour ":" time-minute
    time-offset     = "Z" / time-numoffset

    partial-time    = time-hour ":" time-minute ":" time-second
                      [time-secfrac]
    full-date       = date-fullyear "-" date-month "-" date-mday
    full-time       = partial-time time-offset

    date-time       = full-date "T" full-time
]]

#g

At 12:07 PM 9/14/02 -0400, Keith Moore wrote:

> > I believe it suffices to require:
> > 1. that the offset specified correspond to some established
> >     time zone in effect at the specified date-time, leaving
> >     the range subject as it is to the whims of politicians
> > 2. that the "minutes" part be in the range 00 through 59
> >     (2822 seems to permit +9899, for example).
>
>seems reasonable.
>
>(has this actually been a problem in practice?)
>
>Keith

-------------------
Graham Klyne
<[email-masked]>

To: [email-masked]
Xref: clerew local.mime:1850
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: drums2?
Date: Mon, 16 Sep 2002 10:01:04 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>It seems safe to assume, then, that the range of time zones will remain
>greater than 24 hours in the near future. 199 hours (the range supported
>by 2822) is much bigger than the current requirement of 27 hours, but what
>should the limit be? 28? 30? 48? 49?

Clearly plus or minus 12 hours is insufficient.

The next obvious "break point" would be plus or minus 24 hours. That
accomodates everything that could be conceivably needed (and way beyond),
but anything greater that 24 would be an order of magnitude more weird
than 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

Date: Mon, 16 Sep 2002 09:34:58 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Russ Allbery <[email-masked]>, <[email-masked]>
Subject: Re: radical suggestion 
Sender: [email-masked]

On Sun, 15 Sep 2002, Keith Moore wrote:

> change bars are useful, but they only show you the new text - not
> the text it replaces.

True. Something that did both would be better.

> my point was that I think we'd be more productive if we discussed
> and reviewed specific text changes instead of discussing and
> reviewing the entire document with some less clear set of changes.

Totally agree.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: drums2? 
Date: Sun, 15 Sep 2002 17:29:31 -0400
Sender: [email-masked]

> I've seen things like -0801 (where upon inquiry, the responsible
> party said it was intended to account for a leap second -- how
>  1 second was magnified into 1 minute is baffling).

even more baffling is the leap second affecting the time zone _offset_.

(actually I am hard pressed to see how anyone could make that kind of
coding mistake, much less come  up with such a lame justification)

From: Keith Moore <[email-masked]>
To: Philip Hazel <[email-masked]>
cc: Keith Moore <[email-masked]>, Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: radical suggestion 
Date: Sun, 15 Sep 2002 17:22:40 -0400
Sender: [email-masked]

> > note that the amendments can still be useful in their own right, for
> > people who are very familiar with the current spec - those people want
> > to know the diffs from the previous version.
> 
> Surely the technology can deal with that? Way back in the 1970s IBM
> used to use "change bars" on the right hand side to mark changed text in
> its printed reference manuals. I still do this in the Exim manual, but I
> haven't seen it commonly elsewhere. It's easy for text processors to do,
> and it's visually very easy to spot when flicking through a text, either
> on paper or on a screen. And it's easy to remove afterwards.

change bars are useful, but they only show you the new text - not
the text it replaces.  

my point was that I think we'd be more productive if we discussed
and reviewed specific text changes instead of discussing and
reviewing the entire document with some less clear set of changes.

Date: Sun, 15 Sep 2002 19:54:17 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Russ Allbery <[email-masked]>, <[email-masked]>
Subject: Re: radical suggestion 
Sender: [email-masked]

On Sat, 14 Sep 2002, Keith Moore wrote:

> note that the amendments can still be useful in their own right, for
> people who are very familiar with the current spec - those people want
> to know the diffs from the previous version.

Surely the technology can deal with that? Way back in the 1970s IBM
used to use "change bars" on the right hand side to mark changed text in
its printed reference manuals. I still do this in the Exim manual, but I
haven't seen it commonly elsewhere. It's easy for text processors to do,
and it's visually very easy to spot when flicking through a text, either
on paper or on a screen. And it's easy to remove afterwards.

When DRUMS was actually active, I used to use "diff" on the different
drafts as the only easy way of finding out what had changed.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Sat, 14 Sep 2002 22:36:04 -0400
From: Tony Hansen <[email-masked]>
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: radical suggestion
Sender: [email-masked]

How about issuing both the updated 2821/2822 AND a pair of amendments 
documents as I-Ds. That way, we have the advantage of being able to 
discuss each amendment individually, as well as seeing the resulting 
text that comes about from applying those amendments.

	Tony

Keith Moore wrote:
>>One can always limit the scope of the work to only considering specific
>>changes with the basic assumption that RFC 2822 will remain almost
>>entirely unchanged.
> 
> well, maybe the thing to do is to _discuss_ amendments rather than
> a revised document, with the understanding that the amendments won't
> be incorporated into the document until (just before) last call.
> 
> note that the amendments can still be useful in their own right, for
> people who are very familiar with the current spec - those people want
> to know the diffs from the previous version.
> 
> Keith
> 

Date: Sat, 14 Sep 2002 19:39:21 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: radical suggestion
Sender: [email-masked]

Keith Moore wrote:

> well, maybe the thing to do is to _discuss_ amendments rather than
> a revised document, with the understanding that the amendments won't
> be incorporated into the document until (just before) last call.
> 
> note that the amendments can still be useful in their own right, for
> people who are very familiar with the current spec - those people want
> to know the diffs from the previous version.

Some memos incorporate such a list of changes as an appendix, and
that is indeed useful to those familiar with the previous document.
Perhaps the thing to do would be to first compile a list of potential
changes, then revise that list based on discussion.  Changes could
be folded in (with items from the list placed in an appendix) as
consensus is reached, which makes reviewing the draft for internal
consistency easier than dealing with document + changes; alternatively
that could be postponed until the end.

The thing to avoid would be the situation which 2821/2822 sought to
address, namely that 821/822 were modified by so many other documents
that it was nearly impossible for an implementor to build according
to specification.

Date: Sat, 14 Sep 2002 19:26:01 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Keith Moore wrote:

> (has this actually been a problem in practice?)

I've seen things like -0801 (where upon inquiry, the responsible
party said it was intended to account for a leap second -- how
1 second was magnified into 1 minute is baffling).  Such things
don't cause insurmountable difficulties, but it seems rather
pointless to include an offset that doesn't reflect reality.

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: radical suggestion 
Date: Sat, 14 Sep 2002 17:18:06 -0400
Sender: [email-masked]

> One can always limit the scope of the work to only considering specific
> changes with the basic assumption that RFC 2822 will remain almost
> entirely unchanged.

well, maybe the thing to do is to _discuss_ amendments rather than
a revised document, with the understanding that the amendments won't
be incorporated into the document until (just before) last call.

note that the amendments can still be useful in their own right, for
people who are very familiar with the current spec - those people want
to know the diffs from the previous version.

Keith

To: [email-masked]
Subject: Re: radical suggestion
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 14 Sep 2002 13:14:29 -0700
Lines: 30
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> instead of revising the drums document, how about (at least initially)
> producing a separate document with amendments and advancing the pair of
> those documents to draft standard, with a clear indication that the
> draft standard consists of the first document as amended by the second?

It's really frustrating to try to code to an amended standard.  The W3C
does this from time to time, and I find it almost impossible to keep track
of what the *real* standard is without actually printing out the original
standard and then going through the amendments and noting them on the
printout by hand.

I wonder how many people completely ignore TC1 to C99 because it's
published as errata that essentially requires that you do this in order to
get any sense of what changed.

Publishing a standard document plus errata always struck me as a relic
from the days before electronic documents.  We have the ability to
incorporate errata directly into the original document and publish a
revised version, which is then just radically easier for everyone involved
to use and make sense of, so I think we should use it, even if it's a bit
more work in the preparation.

One can always limit the scope of the work to only considering specific
changes with the basic assumption that RFC 2822 will remain almost
entirely unchanged.

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

To: [email-masked]
Subject: radical suggestion
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Sat, 14 Sep 2002 14:51:48 -0400
Sender: [email-masked]

instead of revising the drums document, how about (at least initially)
producing a separate document with amendments and advancing the 
pair of those documents to draft standard, with a clear indication
that the draft standard consists of the first document as amended
by the second?

Seems like it's much easier to just concentrate on a list of amendments
than to have to look over the entire text of 2821bis/2822bis.

And nothing prevents the amendments from being folded into the main
text at a later date.  Especially if they cite very specific portions 
of the earlier documents to indicate exactly which things are subject
to amendment.

Keith

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: drums2?
Cc: Bruce Lilly <[email-masked]>
Date: Sat, 14 Sep 2002 20:13:57 +0200
Sender: [email-masked]

These requirements make a lot of sense to me as well.

--Arnt

From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: drums2? 
Date: Sat, 14 Sep 2002 12:07:02 -0400
Sender: [email-masked]

> I believe it suffices to require:
> 1. that the offset specified correspond to some established
>     time zone in effect at the specified date-time, leaving
>     the range subject as it is to the whims of politicians
> 2. that the "minutes" part be in the range 00 through 59
>     (2822 seems to permit +9899, for example).

seems reasonable.

(has this actually been a problem in practice?)

Keith

Date: Sat, 14 Sep 2002 10:50:49 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> It seems safe to assume, then, that the range of time zones will remain
> greater than 24 hours in the near future. 199 hours (the range supported
> by 2822) is much bigger than the current requirement of 27 hours, but what
> should the limit be? 28? 30? 48? 49?

Slightly greater than 24 hours; see the comments in the file
"australasia" from the tar archive mentioned earlier,
particularly at the end of that file -- 26 hours currently,
27 if one includes zones in effect back to 1973.

I believe it suffices to require:
1. that the offset specified correspond to some established
    time zone in effect at the specified date-time, leaving
    the range subject as it is to the whims of politicians
2. that the "minutes" part be in the range 00 through 59
    (2822 seems to permit +9899, for example).

At least such requirements would preclude nonsense that
can't be correlated to a real time zone.  Frankly, I don't
think the offset conveys much useful information, anyway

Date: Sat, 14 Sep 2002 14:48:23 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

It seems safe to assume, then, that the range of time zones will remain
greater than 24 hours in the near future. 199 hours (the range supported
by 2822) is much bigger than the current requirement of 27 hours, but what
should the limit be? 28? 30? 48? 49?

--Arnt

Date: Sat, 14 Sep 2002 07:42:10 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> So what should the correct limit be? What's the current range in use, 
> anyway - GMT-14 to GMT+15, or something like that?

Current range is (in 2822 notation) -1100 to +1400, according
to ftp://elsie.nci.nih.gov/pub/tzdata2002c.tar, with no offset
which is not a multiple of 15 minutes (that range and offset
characteristic has been true since 1980; the last -1130, -1200
and -1040 (not a multiple of 15 min.) were discontinued during
1979).  Since 1973 (when RFC 561 introduced Date:), -1200 to
+1400, with no offset which is not a multiple of either 10 or
15 minutes. Historically, prior to 1973 there were some with
offsets specified to the second, which the HHMM numeric offset
cannot handle.  The last such zone was in Liberia with an
offset of -0:44:30 and went out of use during 1972.

It would seem reasonable to support the offsets in effect
since RFC 561, which would be compatible with the HHMM offset
w/o introducing HHMMSS, and the normative text could require
that specified offsets correspond to some valid time zone as
of the specified date-time, much as is the case in 2822
section 3.3 w.r.t. valid time range (no 25:00), day vs. number
of days in the specified month (no 30 Feb), and correct
day-of-week.

Date: Sat, 14 Sep 2002 06:48:45 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Keith Moore wrote:
>>So we can expect time zone offsets like +9959 to
>>disappear when 2822 moves to Draft?
> 
> 
> sure, and while we're at it we'll update the grammar to 
> outlaw 25:00, 30 Feb, incorrect days-of-the-week, 
> all nonexistent email addresses, and subject lines that
> are inconsistent with the message text.  
> 
> oh yes, and we'll make spam syntactically invalid too.
> 
> Keith

The justification given for +9959 etc. was
"people could imagine some wild-eyed uses for them in the future"
which seems to clearly fall into the category
of attempting to "predict the future" rather than
"documents current practice".

From: Arnt Gulbrandsen <[email-masked]>
To: Bruce Lilly <[email-masked]>
Subject: Re: drums2?
Cc: [email-masked]
Date: Sat, 14 Sep 2002 10:37:08 +0200
Sender: [email-masked]

So what should the correct limit be? What's the current range in use, 
anyway - GMT-14 to GMT+15, or something like that?

--Arnt?

From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: drums2? 
Date: Fri, 13 Sep 2002 19:08:33 -0400
Sender: [email-masked]

> So we can expect time zone offsets like +9959 to
> disappear when 2822 moves to Draft?

sure, and while we're at it we'll update the grammar to 
outlaw 25:00, 30 Feb, incorrect days-of-the-week, 
all nonexistent email addresses, and subject lines that
are inconsistent with the message text.  

oh yes, and we'll make spam syntactically invalid too.

Keith

Date: Fri, 13 Sep 2002 18:13:45 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: [email-masked]
Subject: Re: drums2?
Sender: [email-masked]

Pete Resnick wrote:

> The IETF documents current practice. We don't predict the future. 
> Certainly not in Draft Standards.

So we can expect time zone offsets like +9959 to
disappear when 2822 moves to Draft?

Date: Thu, 05 Sep 2002 09:18:23 -0400
From: Ken Hirsch <[email-masked]>
To: IETF-822 <[email-masked]>
Subject: format=flowed update
Sender: [email-masked]

Back in May, I noted that "While it does take the opportunity to nicely 
mark quoted messages, it doesn't actually reflow paragraphs!"

I just noticed that Hotmail now sends messages out with format=flowed 
and that they reflow messages received with format=flowed.

Does anybody at Microsoft know when Outlook and Outlook Express are 
going to support it?  I actually like OE quite a bit, but this is one of 
the small annoyances that make it not optimal for use with mailing 
lists.  (The next one on my list would be the ability to sort messages 
by arbitrary headers, e.g. "return-path" or "x-mailing-list", etc.)

My wife uses Outlook (XP, I think).  It has a feature where it tries to 
fix up line breaks in replies, with a notice over the headers that says 
"Extra line breaks in this message were removed.  To restore, click 
here." It seems to do a reasonable job of it.  Interestingly, it doesn't 
do this with "format=flowed" messages.

If anybody on the list has pull with any of the other major MUAs like 
AOL or Yahoo, please ask them to support this.  It's very simple to do 
and would make life easier.

Ken Hirsch