Subject: Re: bang-formatted addresses
From: Florian Weimer <[email-masked]>
To: [email-masked] (Kai Henningsen)
Cc: [email-masked]
Date: Tue, 26 Mar 2002 15:20:02 +0100
List-Id: <ietf-822.imc.org>

[email-masked] (Kai Henningsen) writes:

> Well, there *is* RFC 976.

Hmm, the first IETF meeting took place just one month before RFC 976
was published.

Date: 26 Mar 2002 08:35:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: bang-formatted addresses
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Dave Crocker)  wrote on 25.03.02 in <[email-masked]>:

> At 02:00 PM 8/15/2001 -0400, Vince Sabio wrote:
>
> >Question about bangs (exclamation marks) in local-parts of addresses: My
> >reading of the expansion of local-part to dot-atom to atext is that a bang
> >is (1) permitted in the local-part of the address and (2) may appear
> >_anywhere_ in the local-part.
> >
> >Specifically, constructions such as <[email-masked]> and
> ><[email-masked]> are permitted, even though they technically violate
> >parsing rules for bang addresses.
> >
> >Correct?
>
> The bang is legal in the left-hand side (mailbox) of an Internet email
> address.  From the perspective of Internet standards, the mailbox string is
> uninterpreted.
>
>  From the standpoint of an MTA's implementation, precedence between bang at
> at-sign depend upon the needs of the organization that is running the
> MTA.  There are times when either precedence makes sense.
>
> Such considerations are entirely outside the purview of the IETF.

Well, there *is* RFC 976.

MfG Kai

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Vince Sabio <[email-masked]>, [email-masked]
Subject: Re: bang-formatted addresses 
Date: Mon, 25 Mar 2002 17:10:17 -0500
Sender: [email-masked]

> The bang is legal in the left-hand side (mailbox) of an Internet email
> address.  From the perspective of Internet standards, the mailbox string is
> uninterpreted.
> 
>  From the standpoint of an MTA's implementation, precedence between bang at
> at-sign depend upon the needs of the organization that is running the
> MTA.  There are times when either precedence makes sense.

Back when it mattered, I argued that the address needed to be evaluated
using the rules of the network from which the message arrived -
so if a message arrived from SMTP, the @ sign should have precedence; 
if it arrived from UUCP, the ! should have precedence.  I'd still 
argue that these are the right rules for the rare case where it matters.

Fortunately, these days we can generally avoid embedding routes in
addresses, so it doesn't matter very often anymore.

Keith

Date: Mon, 25 Mar 2002 13:01:53 -0800
To: Vince Sabio <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: bang-formatted addresses
Cc: [email-masked]
Sender: [email-masked]

At 02:00 PM 8/15/2001 -0400, Vince Sabio wrote:

>Question about bangs (exclamation marks) in local-parts of addresses: My 
>reading of the expansion of local-part to dot-atom to atext is that a bang 
>is (1) permitted in the local-part of the address and (2) may appear 
>_anywhere_ in the local-part.
>
>Specifically, constructions such as <[email-masked]> and 
><[email-masked]> are permitted, even though they technically violate 
>parsing rules for bang addresses.
>
>Correct?

The bang is legal in the left-hand side (mailbox) of an Internet email 
address.  From the perspective of Internet standards, the mailbox string is 
uninterpreted.

 From the standpoint of an MTA's implementation, precedence between bang at 
at-sign depend upon the needs of the organization that is running the 
MTA.  There are times when either precedence makes sense.

Such considerations are entirely outside the purview of the IETF.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

Date: Mon, 25 Mar 2002 12:26:41 -0800
To: Grant Baillie <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>, [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>, [email-masked]
Sender: [email-masked]

After discussions on this list and in person at the IETF, both (A) 
and (B) seem more problematic than the 'delsp' attribute (which was 
dismissed early on as being too ugly).  Since it avoids the problems 
with the other proposals, there seems to be general agreement that 
it's the way to go (despite the ugliness).

At 11:43 PM -0600 3/20/02, Randall Gellens wrote:
>  we could add a new attribute: delsp, which is either true or false 
> (false by default of course).  When true, the space as well as the 
> CRLF is to be deleted on reception.

Date: Mon, 25 Mar 2002 11:13:20 -0800
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>, [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, [email-masked]
To: Randall Gellens <[email-masked]>
From: Grant Baillie <[email-masked]>
Sender: [email-masked]

On Tuesday, Mar 19, 2002, at 08:03 US/Pacific, Randall Gellens wrote:

> I'm no expert on this, but many languages need to be broken up for 
> display in the same way as languages that use lots of spaces. Clients 
> that deal with these languages already need rules to decide how to do 
> this.
>
> There is no suggestion to add language tags.  There are really only two 
> proposals: (A) keep f=f as it is now, and add text to the spec which 
> says it is OK to delete the space as well as the CRLF under some 
> conditions; and (B) obsolete f=f and introduce f=x where the space is 
> always deleted.

 From my point of view, either proposal would work, although I have a 
preference for (B) because it's more explicit as to what you should do 
on the receiving end.

I'm somewhat concerned that the determination of "under some conditions" 
(a.k.a.  having language-specific rules) may be tricky. It seems to boil 
down to being able to answer the question "Does a space at the given 
position in the text convey any meaning?", which is different from the 
question of line breaking.

Anyway, I don't know enough about non-Euro text to know if that can be 
answered reliably. I'm told that you can usually tell in CJK, based on 
the characters on either side of the space.

--Grant

________________________________________
Grant Baillie - [email-masked]
Mac OS X Mail - Apple Computer, Inc.
________________________________________

Date: Wed, 20 Mar 2002 23:43:49 -0600
To: [email-masked], Pete Resnick <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: Eric Fischer <[email-masked]>, [email-masked], Steve Dorner <[email-masked]>, [email-masked]
Sender: [email-masked]

There is an option that was considered and discarded early on, but 
may be worth reconsidering: we could add a new attribute: delsp, 
which is either true or false (false by default of course).  When 
true, the space as well as the CRLF is to be deleted on reception.

An old f=f client sending to a new f=f client works exactly as it 
does today.  A new f=f client sending to an old one at worst has one 
extra space at the end of soft lines, and thus some words will have 
two spaces between them instead of one.  (If the client sets delsp to 
false then of course there are no extra spaces.)

It's ugly to add Yet Another Parameter, but it minimizes 
compatibility problems and avoids the complexity of trying to explain 
when to delete spaces in a language/charset-dependent manner.  Also, 
nothing gets deprecated, and new clients can set delsp=true only with 
non-US-ASCII to minimize compatibility issues.

Comments?

Date: Wed, 20 Mar 2002 18:56:37 -0800 (PST)
From: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
To: Pete Resnick <[email-masked]>
Cc: Eric Fischer <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> On 3/20/02 at 2:35 PM -0600, Eric Fischer wrote:

> > Please do not deprecate format=flowed or introduce a new format option.
> > There will be no hope of convincing software authors to follow the
> > standards if the standards keep changing.

> OK, then tell us what we should do. The current format=flowed
> document is broken for many charsets. It's unusable. It doesn't work.
> So one way or the other the standard is going to change. The only
> question is whether we should change the current standard (which
> would be harder to implement for some charsets) or introduce a new
> standard and deprecate the old one. Which would you like to choose?

Either change the definition of format=flowed or add a new format=foo
thing without deprecating format=flowed. I don't care which.

While I understand the ongoing cost of supporting format=flowed, I believe
the cost of deprecating format=flowed is much much greater. The previous
interations have been hugely damaging to the credibility of this effort
already. Do it again and you'll be completely marginalized, assuming you
aren't already.

				Ned

Date: Wed, 20 Mar 2002 20:21:33 -0600
To: Eric Fischer <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked]
Sender: [email-masked]

At 5:50 PM -0600 3/20/02, Eric Fischer wrote:

>  If format=flowed doesn't work for some charsets, then OK, it may
>  be necessary to introduce a new format option to deal with the more
>  general case.  But it should be used only in those cases where
>  format=flowed will do the wrong thing.
>
>  For the charsets where format=flowed already works, mailers should
>  continue to send messages using the existing standard so that they
>  can continue to be understood by both new and old software.  And
>  mailers that understand the new format option should continue to
>  understand format=flowed so they will work with both new and old
>  messages.
>
>  Otherwise, people who write software that sends mail will have to
>  choose between sending messages that can be received properly only
>  by new software or only by old software.  This is not a choice they
>  should have to make.  They should be able to continue sending what
>  already works for the many cases where it works well, and do something
>  incompatible only for those cases where it's absolutely necessary.

This approach provides short-term benefit at long-term costs. 
Software needs to be more complex, supporting two different format=x 
specifications, and needs to decide which to support.  I think that 
will cause problems long-term.

It's important to keep in mind that sending either f=f or f-x will 
not cause problems if the receiver doesn't support it (but there is 
of course no benefit).

Date: Wed, 20 Mar 2002 20:15:06 -0600
To: Lawrence Greenfield <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked], [email-masked], Steve Dorner <[email-masked]>, Eric Fischer <[email-masked]>
Sender: [email-masked]

I don't think giving up on plain text is a good thing.  F=F has been 
successful where deployed.

Also, I may not have explained myself properly before.  I'm thinking 
that the Format=Foo specification will obsolete Format=Flowed.  So 
we're not really proliferating formats, we're fixing a problem with 
one.  Yes, it is unfortunate to do this, but I think the simplicity 
will be beneficial in the long run.  It's much simpler than trying to 
come up rules for how to do f=f with other languages/charsets.  The 
complexity of trying to do that will be a bigger impediment to new 
implementations than will a new format=foo, I think.

Date: Wed, 20 Mar 2002 20:43:27 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

It might be a better use of resources to explain how to safely send
and receive HTML mail.  HTML mail allows for as much or as little
markup as we want; if there are security concerns we should fix those,
not perpetuate more plaintext formats.

Larry

   Date: Wed, 20 Mar 2002 13:45:48 -0800 (PST)
   From: [email-masked]
   Cc: [email-masked], [email-masked]

   > Randall Gellens <[email-masked]> writes,

   > > I don't see much benefit in having both f=f and f-x.  If we're going
   > > to introduce f=x, why keep f=f around?

   > Please do not deprecate format=flowed or introduce a new format option.
   > There will be no hope of convincing software authors to follow the
   > standards if the standards keep changing.

   I'm afraid I have to agree with this assessment. text/richtext. text/enriched.
   format=flowed. Time to stop.

				   Ned

Date: Wed, 20 Mar 2002 17:50:19 -0600 (CST)
From: Eric Fischer <[email-masked]>
To: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked]
Sender: [email-masked]

Pete Resnick <[email-masked]> writes,

> >Please do not deprecate format=flowed or introduce a new format option.
> >There will be no hope of convincing software authors to follow the
> >standards if the standards keep changing.
> 
> OK, then tell us what we should do. The current format=flowed 
> document is broken for many charsets. It's unusable. It doesn't work. 

If format=flowed doesn't work for some charsets, then OK, it may
be necessary to introduce a new format option to deal with the more
general case.  But it should be used only in those cases where
format=flowed will do the wrong thing.

For the charsets where format=flowed already works, mailers should
continue to send messages using the existing standard so that they
can continue to be understood by both new and old software.  And
mailers that understand the new format option should continue to
understand format=flowed so they will work with both new and old
messages.

Otherwise, people who write software that sends mail will have to
choose between sending messages that can be received properly only
by new software or only by old software.  This is not a choice they
should have to make.  They should be able to continue sending what
already works for the many cases where it works well, and do something
incompatible only for those cases where it's absolutely necessary.

Eric Fischer

Date: Wed, 20 Mar 2002 15:01:07 -0800
To: Randall Gellens <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: Randall Gellens <[email-masked]>, Eric Fischer <[email-masked]>, [email-masked]
Sender: [email-masked]

At 4:47 PM -0600 3/20/02, Randall Gellens wrote:
>Any new or updated software should support f=x only, that's the 
>point of deprecating f=f; to make life simple.  Support f=x on 
>sending and receiving.  Support f=f on receiving is nice, but not 
>required for software that doesn't already support it.  Everyone 
>knows what to send.

In the sense that you know that whatever you send, practically no one 
will actually get a benefit.  :-)

My point is that the more fractured the audience for f=anything, the 
less motivation there is for anybody to implement The Flowed Flavor 
of the Day.

Date: Wed, 20 Mar 2002 16:47:53 -0600
To: Steve Dorner <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: Eric Fischer <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 2:23 PM -0800 3/20/02, Steve Dorner wrote:

>   If we didn't get many mailers to implement it before, changing it 
> makes me afraid we'll get even fewer.

That's a risk, and an argument in favor of plan (A) [amending the 
spec to give advice on when to discard the space as well as the CRLF, 
subject to the characters on either side of the SP CRLF being 7-bit 
US-ASCII and the folding rules for the language/charset being 
displayed.

However, plan (B) [deprecating f=f in favor of f=x] is much simple to 
implement, and thus may be more likely to be supported over time.

>
>>   and I think the software that supports it will support a new f=x.
>
>  Some will, some won't.  And others will implement f=x only.  And 
> those who want to use f={f,x} won't know what to send.

Any new or updated software should support f=x only, that's the point 
of deprecating f=f; to make life simple.  Support f=x on sending and 
receiving.  Support f=f on receiving is nice, but not required for 
software that doesn't already support it.  Everyone knows what to 
send.

Date: Wed, 20 Mar 2002 14:23:47 -0800
To: Randall Gellens <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: Eric Fischer <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 4:10 PM -0600 3/20/02, Randall Gellens wrote:
>I think it would be bad to introduce a new format=foo and not 
>deprecate format-flowed.  Yes, there are deployed implementations of 
>f=f, but there aren't too many,

Wherein lies my problem with changing the spec.  If we didn't get 
many mailers to implement it before, changing it makes me afraid 
we'll get even fewer.

>  and I think the software that supports it will support a new f=x.

Some will, some won't.  And others will implement f=x only.  And 
those who want to use f={f,x} won't know what to send.

Date: Wed, 20 Mar 2002 16:10:52 -0600
To: Eric Fischer <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked]
Sender: [email-masked]

At 2:35 PM -0600 3/20/02, Eric Fischer wrote:

>  Please do not deprecate format=flowed or introduce a new format option.
>  There will be no hope of convincing software authors to follow the
>  standards if the standards keep changing.

I think it would be bad to introduce a new format=foo and not 
deprecate format-flowed.  Yes, there are deployed implementations of 
f=f, but there aren't too many, and I think the software that 
supports it will support a new f=x.  The intent of Proposed Standard 
is to get operational experience, and if necessary modify the 
specifications based on what we see from early implementations.

Date: Wed, 20 Mar 2002 15:46:35 -0600
To: Eric Fischer <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On 3/20/02 at 2:35 PM -0600, Eric Fischer wrote:

>Please do not deprecate format=flowed or introduce a new format option.
>There will be no hope of convincing software authors to follow the
>standards if the standards keep changing.

OK, then tell us what we should do. The current format=flowed 
document is broken for many charsets. It's unusable. It doesn't work. 
So one way or the other the standard is going to change. The only 
question is whether we should change the current standard (which 
would be harder to implement for some charsets) or introduce a new 
standard and deprecate the old one. Which would you like to choose?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 20 Mar 2002 13:45:48 -0800 (PST)
From: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
To: Eric Fischer <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Randall Gellens <[email-masked]> writes,

> > I don't see much benefit in having both f=f and f-x.  If we're going
> > to introduce f=x, why keep f=f around?

> Please do not deprecate format=flowed or introduce a new format option.
> There will be no hope of convincing software authors to follow the
> standards if the standards keep changing.

I'm afraid I have to agree with this assessment. text/richtext. text/enriched.
format=flowed. Time to stop.

				Ned

Date: Wed, 20 Mar 2002 14:35:08 -0600 (CST)
From: Eric Fischer <[email-masked]>
To: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked]
Sender: [email-masked]

Randall Gellens <[email-masked]> writes,

> I don't see much benefit in having both f=f and f-x.  If we're going 
> to introduce f=x, why keep f=f around?

Please do not deprecate format=flowed or introduce a new format option.
There will be no hope of convincing software authors to follow the
standards if the standards keep changing.

Eric Fischer

Date: Wed, 20 Mar 2002 13:13:43 -0600
To: Ian Bell <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

At 10:28 AM +0000 3/20/02, Ian Bell wrote:

>  What about (C) f=f => leave space and f=x => delete space? Nothing 
> breaks and non-Western charsets can be flowed with the newer 
> standard.

I don't see much benefit in having both f=f and f-x.  If we're going 
to introduce f=x, why keep f=f around?

To: [email-masked]
Xref: clerew local.mime:1171
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Message-IDs - Another Fine Mess
Date: Wed, 20 Mar 2002 14:13:06 GMT
Lines: 27
Sender: [email-masked]

In <[email-masked]> [email-masked] (Kai Henningsen) writes:

>This is how it arrived here:

>U: From: Marc Mutz <[email-masked]>
>U: Organization: KDE
>U: To: [email-masked], [email-masked],
>U:    Charles Lindsay <[email-masked]>
>U: Subject: Re: Message-IDs - Another Fine Mess

>2. The To: line was mutilated at your end - someone can't cope with the  
>wrap.

Yup! My simple-minded mail2news shell script called sed to strip out lines
starting with "To: " :-( .

-- 
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: Wed, 20 Mar 2002 10:28:16 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

On Tue, 19 Mar 2002, Randall Gellens <[email-masked]> wrote:

>There is no suggestion to add language tags.  There are really only two 
>proposals: (A) keep f=f as it is now, and add text to the spec which 
>says it is OK to delete the space as well as the CRLF under some 
>conditions;

My point was that you will have to be careful about those conditions, 
because existing clients may well be sending utf-8 in Western charsets 
where the current rules are fine.

You mustn't end up specifying the conditions such that the display of 
messages from deployed clients breaks just because there is an 8bit 
utf-8 code at the break position.

>and (B) obsolete f=f and introduce f=x where the space is always 
>deleted.

What about (C) f=f => leave space and f=x => delete space? Nothing 
breaks and non-Western charsets can be flowed with the newer standard.

-- 
Ian Bell                                           T U R N P I K E

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Date: Tue, 19 Mar 2002 22:46:28 +0100
Sender: [email-masked]

On Tuesday 19 March 2002 11:11, Charles Lindsey wrote:
<snip>
> But for sure it arose from some manual intervention other than here,
> because neither me nor my software would ever mis-spell my name like
> that
<snip>

I plea guilty for that one ;-)
I copied the display name from the comment and made that mistake...

Marc

- -- 
Marc Mutz <[email-masked]>

Date: 19 Mar 2002 22:25:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Charles Lindsey)  wrote on 19.03.02 in <[email-masked]>:

> Looking again at the source (as opposed to what my system displayed) I see:
>
> X-Sent: 16 Mar 2002 20:25:39 GMT
> From: Marc Mutz <[email-masked]>
> Organization: KDE
>         Charles Lindsay <[email-masked]>
> Subject: Re: Message-IDs - Another Fine Mess
> Date: Fri, 15 Mar 2002 17:13:49 +0100
> X-Mailer: KMail [version 1.4]
> References: <"01KF8JCEOCBS0045PS"@mauve.mrochek.com>
> <[email-masked]! In-Reply-To: <[email-masked]>
> X-PGP-Key: 0xBDBFE838
> MIME-Version: 1.0
> Message-Id: <[email-masked]>
>
> which may give some clue, though as shown it is a perfectly valid folding.
> Also the order of the headers is quite different, so maybe that folded
> line was meant to be a folding of some different header.
>
> But for sure it arose from some manual intervention other than here,
> because neither me nor my software would ever mis-spell my name like that
> :-( .

This is how it arrived here:

U: Return-Path: <[email-masked]>
U: Envelope-To: [email-masked]
U: Delivery-Date: Sat, 16 Mar 2002 21:35:05 +0100
U: Received: from (above.proper.com) [208.184.76.39.59095]
U: 	by khms.westfalen.de with esmtp (Exim 3.33 #1)
U: 	id 16mKtM-0002UE-00 (Debian); Sat, 16 Mar 2002 21:35:05 +0100
U: Received: by above.proper.com (8.11.6/8.11.3) id g2GKQ5q27383
U: 	for ietf-822-bks; Sat, 16 Mar 2002 12:26:05 -0800 (PST)
U: Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64])
U: 	by above.proper.com (8.11.6/8.11.3) with SMTP id g2GKQ3427379
U: 	for <[email-masked]>; Sat, 16 Mar 2002 12:26:03 -0800 (PST)
U: Received: (cpmta 7166 invoked from network); 16 Mar 2002 12:25:39 -0800
U: Received: from 217.225.22.42 (HELO dirichlet.mathematik.uni-bielefeld.de)
U:   by smtp.mutz.com (209.228.32.64) with SMTP; 16 Mar 2002 12:25:39 -0800
U: X-Sent: 16 Mar 2002 20:25:39 GMT
U: Content-Type: text/plain;
U:   charset="us-ascii"
U: From: Marc Mutz <[email-masked]>
U: Organization: KDE
U: To: [email-masked], [email-masked],
U:    Charles Lindsay <[email-masked]>
U: Subject: Re: Message-IDs - Another Fine Mess
U: Date: Fri, 15 Mar 2002 17:13:49 +0100
U: X-Mailer: KMail [version 1.4]
U: References: <"01KF8JCEOCBS0045PS"@mauve.mrochek.com> <[email-masked]>
U: In-Reply-To: <[email-masked]>
U: X-PGP-Key: 0xBDBFE838
U: MIME-Version: 1.0
U: Message-Id: <[email-masked]>
U: Content-Transfer-Encoding: 8bit
U: X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2GKQ3427380
U: Sender: [email-masked]
U: Precedence: bulk
U: List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
U: List-Id: <ietf-822.imc.org>
U: List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

>From which I conclude:

1. The name was mutilated by the sender
2. The To: line was mutilated at your end - someone can't cope with the  
wrap.

MfG Kai

Date: Tue, 19 Mar 2002 18:19:59 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

Pete Resnick <[email-masked]>
> I'm baffled by both Arnt's and Barry's comments. If I'm writing an 
> e-mail client that is in use in Japan, it is completely unacceptable 
> to always send HTML (legacy receiving apps and for all of the other 
> obvious reasons). Still, when the user types their message into my 
> client, the text autowraps, and it autowraps on word (i.e., 
> character) boundaries. It is still desireable to send out that 
> message without irrevocably hard wrapping paragraphs and ridiculous 
> not to allow it in certain character sets because we couldn't get the 
> spec right in the first place.

In school my teachers explained to me again and again that I mustn't leave
out steps in my reasoning. Decades later I still do it all too often ;)
Sorry.

Just to state the obvious first, I think it's highly desirable to show
email the way other text is shown. Good wrapping is part of that.

I'll try to divide the world's languages in four.

1. Languages like English, where classic e-mail is text/plain, c-t-e 7bit,
   and German, where text/plain c-t-e 8bit latin1 used to be the norm. All
   languages that use small alphabets and space-separated words are in
   this group.

   In this group, the existing f=f does just fine.

2. Languages that use _big_ alphabets. Japanese is in this group as
   written today. (I believe that formerly the language was sometimes
   shoehorned into katakana/hiragana, but that today computer users expect
   kanji to be available.)

   As I understand it, these languages usually have more than one encoding
   standard (e.g. EUC-JP, Shift-JIS, Unicode) , so you can't just run "cat
   $MAIL" to read your mail. MUAs must exert themselves a bit.

   If a sending MUA has to declare the character set and can send unicode,
   sending a zero-width space sounds like a simple way to indicate the
   availability of a linebreak opportunity, with excellent backward
   compatibility. It requires the use of quoted-printable to handle the
   overlong "lines", but that's OK, because "cat $MAIL" doesn't work
   anyway.

   I don't know whether other big character sets contain features like
   Unicode's ZWS. I'd expect so.

3. Some languages don't have much e-mail yet. There's effectively nothing
   with which to be compatible. Rongo-rongo is one, I guess.

4. The remaining languages are the ones for which an extended f=f could
   make sense -- if my assumptions and logic above hold.

   These must be written with smallish alphabets (the character sets
   preferred for mail today must be 8-bit), most linebreak opportunities
   must not be at whitespace, and there must be a signficant tradition
   with which to be compatible.

   What languages are actually in this group?

--Arnt

Date: Tue, 19 Mar 2002 11:19:43 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

> problem is, text/html has turned out to be an abomination -
> it introduces security holes via java, javascript, etc., and
> lots of folks I know filter it because the vast majority of text/html
> mail they receive is spam.

Mmm... yeah, that *is* a problem.  Sigh....

Never mind.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 19 Mar 2002 10:03:34 -0600
To: Arnt Gulbrandsen <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked], Alexey Melnikov <[email-masked]>, [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>, Grant Baillie <[email-masked]>, [email-masked]
Sender: [email-masked]

I'm no expert on this, but many languages need to be broken up for 
display in the same way as languages that use lots of spaces. 
Clients that deal with these languages already need rules to decide 
how to do this.

There is no suggestion to add language tags.  There are really only 
two proposals: (A) keep f=f as it is now, and add text to the spec 
which says it is OK to delete the space as well as the CRLF under 
some conditions; and (B) obsolete f=f and introduce f=x where the 
space is always deleted.

From: Keith Moore <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets 
Date: Tue, 19 Mar 2002 11:11:37 -0500
Sender: [email-masked]

> If the current rules/practice for
> f=f doesn't fit your situation, send text/html.  That's what you should
> be doing anyway these days,

problem is, text/html has turned out to be an abomination - 
it introduces security holes via java, javascript, etc., and
lots of folks I know filter it because the vast majority of text/html 
mail they receive is spam.

Date: Tue, 19 Mar 2002 10:05:57 -0600
To: Barry Leiba <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked]
Sender: [email-masked]

On 3/19/02 at 8:31 AM -0500, Barry Leiba wrote:

>>For English I understand the motivation: f=f permits
>>paragraph-oriented text with good backward compatibility and little
>>visual impact.
>...
>>Thinking about it, the set of languages for which a spaceless f=f
>>would be useful seems to be just the languages that:
>
>This discussion shows exactly why I objected to f=f when it was 
>first brought up.  I withdrew my objection because this was simple 
>and (relatively) harmless, and people wanted it.  I'll raise the 
>objection again now:
>
>Leave it simple.  Make no changes.  If the current rules/practice 
>for f=f doesn't fit your situation, send text/html.  That's what you 
>should be doing anyway these days, and f=f is just a *simple* 
>compatibility thing.

I'm baffled by both Arnt's and Barry's comments. If I'm writing an 
e-mail client that is in use in Japan, it is completely unacceptable 
to always send HTML (legacy receiving apps and for all of the other 
obvious reasons). Still, when the user types their message into my 
client, the text autowraps, and it autowraps on word (i.e., 
character) boundaries. It is still desireable to send out that 
message without irrevocably hard wrapping paragraphs and ridiculous 
not to allow it in certain character sets because we couldn't get the 
spec right in the first place.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Tue, 19 Mar 2002 08:31:05 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

> For English I understand the motivation: f=f permits
> paragraph-oriented text with good backward compatibility and little
> visual impact.
...
> Thinking about it, the set of languages for which a spaceless f=f
> would be useful seems to be just the languages that:

This discussion shows exactly why I objected to f=f when it was first 
brought up.  I withdrew my objection because this was simple and 
(relatively) harmless, and people wanted it.  I'll raise the objection 
again now:

Leave it simple.  Make no changes.  If the current rules/practice for 
f=f doesn't fit your situation, send text/html.  That's what you should 
be doing anyway these days, and f=f is just a *simple* compatibility 
thing.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

To: [email-masked]
Xref: clerew local.mime:1159
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Message-IDs - Another Fine Mess
Date: Tue, 19 Mar 2002 10:11:53 GMT
Lines: 58
Sender: [email-masked]

In <[email-masked]> Marc Mutz <[email-masked]> writes:

>On Monday 18 March 2002 11:11, Charles Lindsey wrote:
>> In <[email-masked]> Marc Mutz <[email-masked]> 
>writes:
>> >BTW: While we're nitpicking: You're using a deprecated form of From:
>> >address (putting the display name in a comment) ;-)
>>
>> Well you managed to get MY name (and mis-spelt) into YOUR
>> Organization header :-(  ....
>>
>> 	Organization: KDE Charles Lindsay <[email-masked]>
><snip>

>Um, no. Don't see that here (with context):
>Q> Message-id: <[email-masked]>
>Q> Organization: KDE
>Q> MIME-version: 1.0
>(from KMail's "view source"; the corresponding file in the maildir 
>directory shows the same)

>Anyone else seeing that?
>(Sorry for using this list to solve possible bugs ;-)

Looking again at the source (as opposed to what my system displayed) I see:

X-Sent: 16 Mar 2002 20:25:39 GMT
From: Marc Mutz <[email-masked]>
Organization: KDE
        Charles Lindsay <[email-masked]>
Subject: Re: Message-IDs - Another Fine Mess
Date: Fri, 15 Mar 2002 17:13:49 +0100
X-Mailer: KMail [version 1.4]
References: <"01KF8JCEOCBS0045PS"@mauve.mrochek.com> <[email-masked]!
In-Reply-To: <[email-masked]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Message-Id: <[email-masked]>

which may give some clue, though as shown it is a perfectly valid folding.
Also the order of the headers is quite different, so maybe that folded
line was meant to be a folding of some different header.

But for sure it arose from some manual intervention other than here,
because neither me nor my software would ever mis-spell my name like 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: Tue, 19 Mar 2002 12:51:40 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

Ian Bell <[email-masked]>
> Is the solution just to add a flow-language=parameter for f=f, with the 
> default action to do just what is done now?

No. Multi-language mail is more common than you might think. Two examples:

I got mail from someone in France this morning: The message was in English
but the .sig was in French.

When a fellow Norwegian posts in English on a mailing list and I answer
privately, I might well answer in Norwegian, quoting the English posting.

--Arnt

Date: Tue, 19 Mar 2002 10:07:08 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

On Mon, 18 Mar 2002, Randall Gellens <[email-masked]> wrote:

>If either character is not 7-bit US ASCII, then use  language-specific 
>folding rules to decide if the SP should be deleted or not.  Since the 
>point of f=f is to permit line wrapping, the client needs 
>language-specific rules anyway.  It just needs to now apply them during 
>f=f decoding as well.

Presumably there will be an extra parameter in the Content-Type header 
to specify language and hence what language-specific rules need to be 
applied?

For example, this f=f message will have wrapped at a utf-8 encoded € 
character. Deployed clients will be sending this sort of stuff so it is 
important that any new arrangements take this into account.

Is the solution just to add a flow-language=parameter for f=f, with the 
default action to do just what is done now?

>If there is violent objection to the above, the alternate solution is a 
>new format parameter (content-type=text/plain; format=wrap) with the 
>rule that a SP CRLF is inserted as desired, and deleted on receipt. The 
>current f=f would be depricated.

The worry may be that such a big change will be seen as a good reason 
for those clients which still abuse CT=text/plain, CTE=qp to continue 
what they are doing.

-- 
Ian Bell                                           T U R N P I K E

Date: Tue, 19 Mar 2002 10:09:45 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Randall Gellens <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>, [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <[email-masked]>, Grant Baillie <[email-masked]>, [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

Pardon my na�vete, but what would be the point of using f=f with e.g.
Thai?

For English I understand the motivation: f=f permits paragraph-oriented
text with good backward compatibility and little visual impact.

But for something like Thai (with >400 characters IIRC) it's not like
that.

Thinking about it, the set of languages for which a spaceless f=f would be
useful seems to be just the languages that:

 - fit inside 128 characters
 - have a significant tradition of 8bit text/plain e-mail
 - do not use spaces much

Are there even languages like that?

--Arnt

Date: Mon, 18 Mar 2002 16:30:56 -0600
To: [email-masked], Alexey Melnikov <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Ned Freed <[email-masked]>, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>, Grant Baillie <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

We ended up meeting today.  There seems to be consensus on the following:

Ideally, the existing f=f can continue, with additional 
clarifications: if the character on each side of the SP CRLF sequence 
is 7-bit US ASCII, go ahead and delete the CRLF but leave the space 
(as is done now).  If either character is not 7-bit US ASCII, then 
use  language-specific folding rules to decide if the SP should be 
deleted or not.  Since the point of f=f is to permit line wrapping, 
the client needs language-specific rules anyway.  It just needs to 
now apply them during f=f decoding as well.

If there is violent objection to the above, the alternate solution is 
a new format parameter (content-type=text/plain; format=wrap) with 
the rule that a SP CRLF is inserted as desired, and deleted on 
receipt.  The current f=f would be depricated.

Date: Mon, 18 Mar 2002 12:46:54 -0800 (PST)
From: [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
To: Randall Gellens <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> At 8:48 AM -0700 3/18/02, Alexey Melnikov wrote:

> >   > How about during lunch on Monday or Tuesday?  Or 1300 Monday?
> >
> >  Can we do that on Tuesday 1130-1300?

> Works for me.  Anyone else?

Can't make it on Tuesday; sorry.

				Ned

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Date: Mon, 18 Mar 2002 19:46:17 +0100
Sender: [email-masked]

On Monday 18 March 2002 11:11, Charles Lindsey wrote:
> In <[email-masked]> Marc Mutz <[email-masked]> 
writes:
> >BTW: While we're nitpicking: You're using a deprecated form of From:
> >address (putting the display name in a comment) ;-)
>
> Well you managed to get MY name (and mis-spelt) into YOUR
> Organization header :-(  ....
>
> 	Organization: KDE Charles Lindsay <[email-masked]>
<snip>

Um, no. Don't see that here (with context):
Q> Message-id: <[email-masked]>
Q> Organization: KDE
Q> MIME-version: 1.0
(from KMail's "view source"; the corresponding file in the maildir 
directory shows the same)

Anyone else seeing that?
(Sorry for using this list to solve possible bugs ;-)

Marc

- -- 
Marc Mutz <[email-masked]>

To: [email-masked]
Xref: clerew local.mime:1154
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Message-IDs - Another Fine Mess
Date: Mon, 18 Mar 2002 10:11:19 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> Marc Mutz <[email-masked]> writes:

>BTW: While we're nitpicking: You're using a deprecated form of From: 
>address (putting the display name in a comment) ;-) 

Well you managed to get MY name (and mis-spelt) into YOUR Organization
header :-(  ....

	Organization: KDE Charles Lindsay <[email-masked]>

But yes, my system was set up yonks ago long before such From lines were
not deprecated. Took me quite sometime to track down where that line was
actually constructed.

-- 
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, 18 Mar 2002 10:17:24 -0600
From: Chris Newman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Randall Gellens <[email-masked]>
cc: [email-masked], John Gardiner Myers <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

I have a prior commitment Tuesday lunch.  Let me know what happens if you 
decide to hold it then.

                - Chris

begin  quotation by Alexey Melnikov on 2002/3/18 8:48 -0700:

> Randall Gellens wrote:
>
>> A few of us have discussed the idea of getting together in
>> Minneapolis to work out a solution to using Format=Flowed when spaces
>> are not common (either they aren't used at all, or don't appear very
>> often).
>>
>> How about during lunch on Monday or Tuesday?  Or 1300 Monday?
>
> Can we do that on Tuesday 1130-1300?
>
> Alexey Melnikov
> __________________________________________
> R & D, ACI Worldwide/MessagingDirect
> Richmond, Surrey, UK
> Phone: +44 20 8332 4508
>
> I speak for myself only, not for my employer.
> __________________________________________
>
>

Date: Mon, 18 Mar 2002 10:17:01 -0600
To: Alexey Melnikov <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Cc: [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

At 8:48 AM -0700 3/18/02, Alexey Melnikov wrote:

>   > How about during lunch on Monday or Tuesday?  Or 1300 Monday?
>
>  Can we do that on Tuesday 1130-1300?

Works for me.  Anyone else?

Date: Mon, 18 Mar 2002 08:48:56 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Randall Gellens <[email-masked]>
CC: [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Subject: Re: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

Randall Gellens wrote:

> A few of us have discussed the idea of getting together in
> Minneapolis to work out a solution to using Format=Flowed when spaces
> are not common (either they aren't used at all, or don't appear very
> often).
>
> How about during lunch on Monday or Tuesday?  Or 1300 Monday?

Can we do that on Tuesday 1130-1300?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

To: [email-masked]
Xref: clerew local.mime:1153
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message-IDs - Another Fine Mess
Date: Mon, 18 Mar 2002 09:30:18 GMT
Lines: 30
Sender: [email-masked]

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

>Now, RFC 2822 says that the references field SHOULD be constructed using the
>message-id and references fields. In effect RFC 2822 chose to interpret the
>word "other" in RFC 822 section 4.6.3 (references) as referring to
>correspondence other than the current message.

Well the behaviour now described in RFC 2822 is precisely what Netnews
systems have been doing since time immemorial (which means at least RFC
1036, and maybe earlier).
> 

>Only if you're dealing with software that follows RFC 2822. And even then it is
>only a SHOULD, not a MUST. Like it or not, the bulk of the world's email
>software was written before RFC 2822 was even on the drawing board.

But the bulk of the world's email software treats that SHOULD as a DON'T
BOTHER :-( . It's really only mailing lists and news, where threads tend
to become long, that the feature becomes important.

-- 
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: Sun, 17 Mar 2002 22:51:49 -0600
To: [email-masked], John Gardiner Myers <[email-masked]>, Chris Newman <[email-masked]>, Alexey Melnikov <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: BOF: Format-Flowed and Non-Western Charsets
Sender: [email-masked]

A few of us have discussed the idea of getting together in 
Minneapolis to work out a solution to using Format=Flowed when spaces 
are not common (either they aren't used at all, or don't appear very 
often).

How about during lunch on Monday or Tuesday?  Or 1300 Monday?

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked], [email-masked], Charles Lindsay <[email-masked]>
Subject: Re: Message-IDs - Another Fine Mess
Date: Fri, 15 Mar 2002 17:13:49 +0100
Sender: [email-masked]

On Tuesday 12 March 2002 11:10, Charles Lindsey wrote:
<snip>
> OK, here is an experiment. The Message-ID of your mail was
> <[email-masked]>. I have made the References
> line in this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.
>
> Hands up anybody with a threading mail reader that threaded my reply
> as a followup to yours (and hands down if it didn't).
<snip>

FWIW:
Current KMail from the upcoming KDE3 release doesn't handle this case.
But already an early version of KMime, the upcoming internet mail and 
usenet backend for KMail and KNode (scheduled for inclusion in KDE3.1), 
did.

Marc

BTW: While we're nitpicking: You're using a deprecated form of From: 
address (putting the display name in a comment) ;-)

- -- 
Marc Mutz <[email-masked]>

Date: Fri, 15 Mar 2002 13:05:03 -0800 (PST)
From: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

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

> >[email-masked]

> >In-reply-to: "Your message dated Tue, 12 Mar 2002 10:10:41 +0000 (GMT)"
> >	<[email-masked]>
> >Message-id: <[email-masked]>
> >References: <[email-masked]>

> > Surely that cannot be correct.

The original message had the normalized header fields

References: <[email-masked]>
Message-id: <[email-masked]>

and the software I was using at the time copies in-reply-to and references to
references and message-id to in-reply-to, producing

References: <[email-masked]>
In-reply-to: "Your message dated Tue, 12 Mar 2002 10:10:41 +0000 (GMT)"
 <[email-masked]>

Now, RFC 2822 says that the references field SHOULD be constructed using the
message-id and references fields. In effect RFC 2822 chose to interpret the
word "other" in RFC 822 section 4.6.3 (references) as referring to
correspondence other than the current message.
 
But RFC 2822 was issued more than a decade after this software was written, and
this software interpreted the word "other" in section 4.6.3 as referring to
correspondence other than that what's already listed in section 4.6.2
(in-reply-to). So it doesn't put the message-id field in the references field.

> Yes, I would have expected

> References: <[email-masked]> <[email-masked]>

Only if you're dealing with software that follows RFC 2822. And even then it is
only a SHOULD, not a MUST. Like it or not, the bulk of the world's email
software was written before RFC 2822 was even on the drawing board.

				Ned

To: [email-masked]
Xref: clerew local.mime:1150
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message-IDs - Another Fine Mess
Date: Fri, 15 Mar 2002 09:35:38 GMT
Lines: 26
Sender: [email-masked]

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

>[email-masked]

>In-reply-to: "Your message dated Tue, 12 Mar 2002 10:10:41 +0000 (GMT)"
>	<[email-masked]>
>Message-id: <[email-masked]>
>References: <[email-masked]>

>Surely that cannot be correct.

Yes, I would have expected

References: <[email-masked]> <[email-masked]>

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

To: [email-masked]
Xref: clerew local.mime:1149
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message-IDs - Another Fine Mess
Date: Fri, 15 Mar 2002 09:34:02 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> [email-masked] (Kai Henningsen) writes:

>[email-masked] (Charles Lindsey)  wrote on 12.03.02 in <[email-masked]>:

>> OK, here is an experiment. The Message-ID of your mail was
>> <[email-masked]>. I have made the References line in
>> this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.
>>
>> Hands up anybody with a threading mail reader that threaded my reply as a
>> followup to yours (and hands down if it didn't).

>CrossPoint didn't unquote (no surprise here), but Perl  
>Mail::Address->parse didn't normalize it, either.

So it looks like implementation of this "feature" is pretty patchy.

In the Usefor draft, I have now excluded all un-normalized message-ids
syntactically (compliant software simply must not create them - not that I
suppose anyone short of Hipcrime would want to try). So that is how it
will be unless the folks on the Usefor list decide otherwise.

-- 
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: 14 Mar 2002 21:14:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
cc: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Charles Lindsey)  wrote on 12.03.02 in <[email-masked]>:

> OK, here is an experiment. The Message-ID of your mail was
> <[email-masked]>. I have made the References line in
> this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.
>
> Hands up anybody with a threading mail reader that threaded my reply as a
> followup to yours (and hands down if it didn't).

CrossPoint didn't unquote (no surprise here), but Perl  
Mail::Address->parse didn't normalize it, either.

MfG Kai

Date: Thu, 14 Mar 2002 11:56:06 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Sender: [email-masked]

Hi,

--On Tuesday, March 12, 2002 10:10 AM +0000 Charles Lindsey
<[email-masked]> wrote:

| 
| 
| In <[email-masked]> [email-masked] writes:
| 
| I am still sending this to both lists, with Reply-To to both.
| 
|>> 3. Now I have just found another feature/bug.
| 
|> I can't speak to news, but this is an issue that email software has had
|> to deal with for almost two decades now.
| 
|>> Consider the following three msg-ids, all syntactically correct in RFC
|>> 2822:
| 
|>> A.   <Joe_Doe@[127.0.0.1]>
|>> B.   <"Joe_Doe"@[127.0.0.1]>
|>> C.   <"Joe\_Doe"@[127\.0\.0\.1]>
| 
|>> Question. Are those three semantically the same in RFC 2822?
| 
|> Yes they are.
| 
| So are you saying, for example, that mail readers which do threading based
| on the References line are programmed to take this into account? Seems a
| lot of unnecessary work to me.
| 
| OK, here is an experiment. The Message-ID of your mail was
| <[email-masked]>. I have made the References line in
| this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.
| 
| Hands up anybody with a threading mail reader that threaded my reply as a
| followup to yours (and hands down if it didn't).
| 

Testing this with IMAP servers that implement the IMAP THREAD extension:
one worked, the other did not. I'll send in a report on that. I suspect
there also ought to be an explicit comment in that specification warning
about this issue.

-- 
Cyrus Daboo

Date: 14 Mar 2002 14:24:47 -0000
Mail-Followup-To: [email-masked], [email-masked]
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Sender: [email-masked]

Charles Lindsey writes:
> I have made the References line in
> this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.

My mess822 library, http://cr.yp.to/mess822.html, decodes the string
automatically.

My header-format reference manual specifically recommends against quoted
strings and other user-interface fluff inside message identifiers. See
http://cr.yp.to/immhf/thread.html.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Date: Thu, 14 Mar 2002 11:14:29 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Sender: [email-masked]

[email-masked]
> Mine did. And you'll notice that the quotes are gone in the references line
> used in this reply -- with no action taken on my part.

The header fields I see are:

In-reply-to: "Your message dated Tue, 12 Mar 2002 10:10:41 +0000 (GMT)"
	<[email-masked]>
Message-id: <[email-masked]>
References: <[email-masked]>

Surely that cannot be correct.

--Arnt

To: [email-masked]
Cc: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 13 Mar 2002 23:14:04 -0800
Lines: 17
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> So are you saying, for example, that mail readers which do threading
> based on the References line are programmed to take this into account? 
> Seems a lot of unnecessary work to me.

> OK, here is an experiment. The Message-ID of your mail was
> <[email-masked]>. I have made the References line in
> this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.

> Hands up anybody with a threading mail reader that threaded my reply as
> a followup to yours (and hands down if it didn't).

Gnus did not succeed in threading those messages.

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

Date: Tue, 12 Mar 2002 17:57:43 -0800 (PST)
From: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

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

> I am still sending this to both lists, with Reply-To to both.

> >> 3. Now I have just found another feature/bug.

> >I can't speak to news, but this is an issue that email software has had to
> >deal with for almost two decades now.

> >> Consider the following three msg-ids, all syntactically correct in RFC 2822:

> >> A.   <Joe_Doe@[127.0.0.1]>
> >> B.   <"Joe_Doe"@[127.0.0.1]>
> >> C.   <"Joe\_Doe"@[127\.0\.0\.1]>

> >> Question. Are those three semantically the same in RFC 2822?

> >Yes they are.

> So are you saying, for example, that mail readers which do threading based
> on the References line are programmed to take this into account? Seems a
> lot of unnecessary work to me.

I have no idea what other people's code does. The code I've done normalizes.
And the amount of extra work is negligable. Indeed, given the methodology I use
it would be more work for me not to normalize.

> OK, here is an experiment. The Message-ID of your mail was
> <[email-masked]>. I have made the References line in
> this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.

> Hands up anybody with a threading mail reader that threaded my reply as a
> followup to yours (and hands down if it didn't).

Mine did. And you'll notice that the quotes are gone in the references line
used in this reply -- with no action taken on my part.

				Ned

To: [email-masked]
Xref: clerew local.mime:1142 local.usefor:12778
Newsgroups: local.mime,local.usefor
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Message-IDs - Another Fine Mess
Reply-To: [email-masked], [email-masked]
Date: Tue, 12 Mar 2002 10:10:41 GMT
Lines: 96
Sender: [email-masked]

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

I am still sending this to both lists, with Reply-To to both.

>> 3. Now I have just found another feature/bug.

>I can't speak to news, but this is an issue that email software has had to
>deal with for almost two decades now.

>> Consider the following three msg-ids, all syntactically correct in RFC 2822:

>> A.   <Joe_Doe@[127.0.0.1]>
>> B.   <"Joe_Doe"@[127.0.0.1]>
>> C.   <"Joe\_Doe"@[127\.0\.0\.1]>

>> Question. Are those three semantically the same in RFC 2822?

>Yes they are.

So are you saying, for example, that mail readers which do threading based
on the References line are programmed to take this into account? Seems a
lot of unnecessary work to me.

OK, here is an experiment. The Message-ID of your mail was
<[email-masked]>. I have made the References line in
this message to be <"01KF8JCE\OCBS0045PS"@mauve.mrochek.com>.

Hands up anybody with a threading mail reader that threaded my reply as a
followup to yours (and hands down if it didn't).

>Yes, so A, B, and C are all semantically equivalent. The clear implication,
>then, is that normalization is necessary if you want to perform proper
>semantic comparisons.

>> Now I suspect this is a Bad Thing even in Email (though I am not sure
>> that any of the Email Standards makes any official use of the msg-id).

>I fail to see what's Bad about it. Sure, normalization is a pain, but the clear
>trend is to do more and more of it, not less. Normalization forms for Unicode
>are such a joy...

Indeed so, but the Unicode people have an excellent principle known as
"Early Uniform Normalization", which I find described in
draft-duerst-i18n-norm-04.txt (though there may be a later draft, or even
an RFC, by now).

Essentially, Early Uniform Normalization means that you normalize it
(whatever "it" is) *before* it goes out on the wire, so that all sites
that receive and process it can assume it is already normalized, and so
can skip any re-normalization-before-comparison process.

And indeed, this is exactly what we have done in Usefor in the case of
newsgroup-names. They had better be in Unicode NFKC normal form when they
leave the posting agent, and if they are not they will not get very far.
Indeed, they had better be in that form at newsgroup-creation time.

So, applying that principle to the present case, one would say that
posting/mailing agents MUST only ever put out that msg-id in the form
	<Joe_Doe@[127.0.0.1]>

Well, it is not for me to say what is to happen in mailing agents, but in
the case of posting agents that is essentially the second (syntactic)
solution that I proposed. Essentially, the non-normalized versions are
just not allowed by the syntax.

>> But in Netnews it would lead to GROSS interoperability problems.

>> The rest of this message is concerned with how it might be fixed in
>> Usefor (RFC 2822 now being cast in concrete). The ietf-822 people may
>> stop readin now, but are welcome to continue and comment if they wish
>> :-) .

>> I see two solutions. One is Brute Force (and involves sophistry to
>> boot). The other is syntactic (it just excludes all quoting that is not
>> strictly essential). I am not particularly impressed by either solution,
>> so would welcome suggestions.

>Assuming you feel its necessary to "solve" this "problem", I think a
>syntactic solution is preferable.

In that case, I think we are in agreement.

-- 
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, 11 Mar 2002 14:51:38 -0800 (PST)
From: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
To: Henry Spencer <[email-masked]>
Cc: Usefor Mailing List <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Mon, 11 Mar 2002 [email-masked] wrote:
> > It is only a problem in the sense that there's an operation you need to perform
> > before you can compare id strings. Code I've written to do threading and such
> > as far back as the mid 80's does this...

> However, news software has systematically ignored normalization and done a
> simple string comparison since its beginnings even earlier.  The only nod
> it has ever made to normalization has been some degree of case-insensitive
> comparison, and even that hasn't been entirely consistent.  Compatibility
> with the installed base is an issue that can't be ignored here.

That's why I suggested that banning use of unnecessary syntactic stuff is
the right approach: It works with systems that normalize, and it works
with systems that don't. And while you cannot extend it to email, you can
say that email -> news should normalize.

				Ned

Date: Mon, 11 Mar 2002 17:41:32 -0500 (EST)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
cc: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
Sender: [email-masked]

On Mon, 11 Mar 2002 [email-masked] wrote:
> It is only a problem in the sense that there's an operation you need to perform
> before you can compare id strings. Code I've written to do threading and such
> as far back as the mid 80's does this...

However, news software has systematically ignored normalization and done a
simple string comparison since its beginnings even earlier.  The only nod
it has ever made to normalization has been some degree of case-insensitive
comparison, and even that hasn't been entirely consistent.  Compatibility
with the installed base is an issue that can't be ignored here.

                                                          Henry Spencer
                                                       [email-masked]

Date: Mon, 11 Mar 2002 13:33:13 -0800 (PST)
From: [email-masked]
Subject: Re: Message-IDs - Another Fine Mess
To: Charles Lindsey <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 3. Now I have just found another feature/bug.

I can't speak to news, but this is an issue that email software has had to
deal with for almost two decades now.

> Consider the following three msg-ids, all syntactically correct in RFC 2822:

> A.   <Joe_Doe@[127.0.0.1]>
> B.   <"Joe_Doe"@[127.0.0.1]>
> C.   <"Joe\_Doe"@[127\.0\.0\.1]>

> Question. Are those three semantically the same in RFC 2822?

Yes they are.

> Read 3.2.5:

>    Semantically, neither the optional CFWS outside of the quote
>    characters nor the quote characters themselves are part of the
>    quoted-string; the quoted-string is what is contained between the two
>    quote characters.

> And that clearly makes A and B semantically equivalent (well, you
> _might_ just argue that the syntax of msg-id does not actually mention
> quoted-string, but that is sophistry).

> And now read 3.2.2:

>    Where any quoted-pair appears, it is to be interpreted as the text
>    character alone.  That is to say, the "\" character that appears as
>    part of a quoted-pair is semantically "invisible".

> And that clearly makes B and C semantically equivalent.

Yes, so A, B, and C are all semantically equivalent. The clear implication,
then, is that normalization is necessary if you want to perform proper
semantic comparisons.

> Now I suspect this is a Bad Thing even in Email (though I am not sure
> that any of the Email Standards makes any official use of the msg-id).

I fail to see what's Bad about it. Sure, normalization is a pain, but the clear
trend is to do more and more of it, not less. Normalization forms for Unicode
are such a joy...

> But in Netnews it would lead to GROSS interoperability problems.

> So there is the problem. First of all, could the ietf-822 people please
> confirm that the problem is genuine, even in Email (or else explain why
> it isn't)?

It is only a problem in the sense that there's an operation you need to perform
before you can compare id strings. Code I've written to do threading and such
as far back as the mid 80's does this. Perhaps I've been completely dense all
this time or something and I've done a bit more work then was necessary, but
this has always struck me as an obvious part of both address and message id
handling.

The only time I've seen problems in this area is with multiple spaces and
folding. The rules for how to handle such foldings aren't obvious, and even if
you follow them there's enough variability in the field that it is impossible
to recover from the actions of other agents. Of course anyone who puts
multiple spaces in an address or an id and expects them to work is playing
with fire, but some people seem to like getting burned.

> The rest of this message is concerned with how it might be fixed in
> Usefor (RFC 2822 now being cast in concrete). The ietf-822 people may
> stop readin now, but are welcome to continue and comment if they wish
> :-) .

> Note first of all that the two bits of semantics quoted above from
> RFC 2822 apply also within Usefor. That would have been true in any
> case but, for the removal of all doubt, I have now explicitly written
> them in, mainly because I need to rely on them for the semantics of
> parameters.

> I see two solutions. One is Brute Force (and involves sophistry to
> boot). The other is syntactic (it just excludes all quoting that is not
> strictly essential). I am not particularly impressed by either solution,
> so would welcome suggestions.

Assuming you feel its necessary to "solve" this "problem", I think a
syntactic solution is preferable.

				Ned

Date: Mon, 11 Mar 2002 20:30:10 +0000 (GMT)
From: Charles Lindsey <[email-masked]>
Reply-To: [email-masked], [email-masked]
Subject: Message-IDs - Another Fine Mess
To: [email-masked], [email-masked]
Content-MD5: tljSuzuP0Zn9QFczVB0vyQ==
Sender: [email-masked]

This message is being sent to both the usenet-format and ietf-822 lists,
with Reply-To to both. Please try to keep it on both lists until at
least we understand the problem. Ultimately, the solution is for Usefor,
but I would first of all like to hear confirmation from the ietf-822
people that the problem really exists.

The Story So Far:

1. In the old days, a msg-id was just an angle-addr. Then it was pointed
out that this permitted folding, comments and whitespace within a
msg-id, which was clearly a Bad Thing. After some discussion on DRUMS,
therefore, a special syntax for msg-ids was written, with no CFWS in
sight and special syntax rules for no-fold-quote and no-fold-literal.

2. Then someone in Usefor spotted that the syntax still allowed
whitespace, because you could sneak in a SP or an HTAB by using it in
a quoted-pair, which is itself allowed inside a no-fold-quote or a
no-fold-literal. This is still a Bad Thing (indeed quite intolerable for
Usefor, since most existing software would break on it). However, this
was only spotted in the closing days of DRUMS, so it did not get fixed
for RFC 2822. In Usefor, we cured the problem by Brute Force:

   "A msg-id MUST NOT contain any WSP within any strict-quoted-pair."

3. Now I have just found another feature/bug.

Consider the following three msg-ids, all syntactically correct in RFC 2822:

A.   <Joe_Doe@[127.0.0.1]>
B.   <"Joe_Doe"@[127.0.0.1]>
C.   <"Joe\_Doe"@[127\.0\.0\.1]>

Question. Are those three semantically the same in RFC 2822?

Read 3.2.5:

   Semantically, neither the optional CFWS outside of the quote
   characters nor the quote characters themselves are part of the
   quoted-string; the quoted-string is what is contained between the two
   quote characters.

And that clearly makes A and B semantically equivalent (well, you
_might_ just argue that the syntax of msg-id does not actually mention
quoted-string, but that is sophistry).

And now read 3.2.2:

   Where any quoted-pair appears, it is to be interpreted as the text
   character alone.  That is to say, the "\" character that appears as
   part of a quoted-pair is semantically "invisible".

And that clearly makes B and C semantically equivalent.

Now I suspect this is a Bad Thing even in Email (though I am not sure
that any of the Email Standards makes any official use of the msg-id).

But in Netnews it would lead to GROSS interoperability problems.

So there is the problem. First of all, could the ietf-822 people please
confirm that the problem is genuine, even in Email (or else explain why
it isn't)?

------------------------------------------------------------------------------

The rest of this message is concerned with how it might be fixed in
Usefor (RFC 2822 now being cast in concrete). The ietf-822 people may
stop readin now, but are welcome to continue and comment if they wish
:-) .

Note first of all that the two bits of semantics quoted above from
RFC 2822 apply also within Usefor. That would have been true in any
case but, for the removal of all doubt, I have now explicitly written
them in, mainly because I need to rely on them for the semantics of
parameters.

I see two solutions. One is Brute Force (and involves sophistry to
boot). The other is syntactic (it just excludes all quoting that is not
strictly essential). I am not particularly impressed by either solution,
so would welcome suggestions.

Here now is the complete section on Message-ID as it now stands in Usefor:

5.3.  Message-ID
 
   The Message-ID-header contains the article's message identifier, a
   unique identifier distinguishing the article from every other
   article. The content syntax makes use of syntax defined in [RFC
   2822], subject to the following revised definition of no-fold-quote
   and no-fold-literal.
 
      header             =/ Message-ID-header
      Message-ID-header  = "Message-ID" ":" SP Message-ID-content
                              *( ";" other-parameter )
      Message-ID-content = msg-id
      id-left            = dot-atom-text / no-fold-quote
      id-right           = dot-atom-text / no-fold-literal
      no-fold-quote      = DQUOTE *( strict-qtext / strict-quoted-pair )
                              DQUOTE
      no-fold-literal    = "[" *( dtext / strict-quoted-pair ) "]"

   A msg-id MUST NOT contain any WSP within any strict-quoted-pair.  The
   msg-id MUST NOT be more than 250 octets in length.

        NOTE: The syntax ensures that a msg-id is restricted to pure
        US-ASCII, and is thus a strict subset of that defined by [RFC
        2822]. Moreover, the syntax does not involve any quoted-string
        or quoted pair, and hence the semantic interpretations set out
        in 2.4.2 do not apply. Rather, the semantic value of a msg-id is
        exactly as it is written, so that two msg-ids are different if
        their written forms are different (a property that does not
        apply to the msg-ids defined in [RFC 2822]).

        The exclusion of WSP is to ensure compatibility with existing
        software.  The length restriction ensures that systems which
        accept message identifiers as a parameter when retrieving an
        article (e.g. [NNTP]) can rely on a bounded length. Observe that
        msg-id includes the '<' and '>'.

[Alternative text]

      no-fold-quote      = DQUOTE *( strict-qtext / "\" "\" / "\" DQUOTE )
                              qspecial
                              *( strict-qtext / "\" "\" / "\" DQUOTE ) DQUOTE
      qspecial           = "(" / ")" /        ; same as specials except
                           "<" / ">" /        ; "\" and DQUOTE quoted
                           "[" / "]" /
                           ":" / ";" /
                           "@" / "\" "\" /
                           "," / "." /
                           "\" DQUOTE
      no-fold-literal    = "[" *( dtext / "\" "[" / "\" "]" / "\" "\" ) "]"

   The msg-id MUST NOT be more than 250 octets in length.

        NOTE: The syntax ensures that a msg-id is restricted to pure
        US-ASCII, that no string of characters is quoted unless strictly
        necessary (it must contain at least one qspecial) and no single
        character is prefixed by a "\" in the form of a quoted-pair
        unless strictly necessary, and moreover there is no possibility
        for WSP to occur, whether quoted or not.  These exclusions are
        to ensure compatibility with existing software.  The length
        restriction ensures that systems which accept message
        identifiers as a parameter when retrieving an article (e.g.
        [NNTP]) can rely on a bounded length. Observe that msg-id
        includes the '<' and '>'.

        Consequently, two msg-ids are different if their written forms
        are different (irrespective of whether or not the semantic
        interpretations of quoted-string and quoted-pair (2.4.2) are
        applied, or not). Msg-ids as defined by [RFC 2822] do not share
        this property. Msg-ids as defined here are a strict subset of
        those defined by [RFC 2822].
[end of Alternative text]

   Following the provisions of [RFC 2822], an agent generating an
   article's message identifier MUST ensure that it is unique and that
   it is NEVER reused (either in Netnews or Email). Moreover, even
   though commonly derived from the domain name of the originating site
   (and domain names are case-insensitive), a message identifier MUST
   NOT be altered in any way during transport, or when copied (as into a
   References-header), and thus a simple (case-sensitive) comparison of
   octets will always suffice to recognize that same message identifier
   wherever it subsequently reappears.

        NOTE: some old software may treat message identifiers that
        differ only in case within their id-right part as equivalent,
        and implementors of agents that generate message identifiers
        should be aware of this.

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

To: [email-masked]
Xref: clerew local.mime:1137
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: quoted strings within quoted strings
Date: Tue, 5 Mar 2002 11:01:32 GMT
Lines: 29
Sender: [email-masked]

In <[email-masked]> Marc Mutz <[email-masked]> writes:

>On Monday 04 March 2002 12:39, Charles Lindsey wrote:
><snip>

>> An alternative way would that I am toying with would be to say: 
>> 
>> token = 1*<any (US-ASCII) CHAR except SP, CTLs or tspecials>
>> value = [CFWS] token [CFWS] / quoted-string
>> attribute = [CFWS] token [CFWS]
><snip>

>But that would imply that the CFWS is _part_ of value and attribute, 
>resp. It isn't. CFWS is never semantically relevant.

But if you do it the other way, then CFWS becomes a part of token, which
is even worse.

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

To: [email-masked]
Xref: clerew local.mime:1136
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: quoted strings within quoted strings
Date: Tue, 5 Mar 2002 10:57:47 GMT
Lines: 35
Sender: [email-masked]

In <a05100305b8a94361d6de@[216.43.25.67]> Pete Resnick <[email-masked]> writes:

>On 3/4/02 at 11:39 AM +0000, Charles Lindsey wrote:

>>token = [CFWS] 1*<any (US-ASCII) CHAR except SP, CTLs or tspecials> [CFWS]

>Or if you like:

>ttext = ALPHA / DIGIT / "!" / "#" /
>        "$" / "%" / "&" / "'" / "*" / "+" /
>        "-" / "^" / "_" / "`" / "{" / "|" / "}" / "~"

Yes, but I was trying to stick to the style of RFC 2045 as closely as
possible.

>>Foo-header = "Foo" ":" <Foo specific stuff> [CFWS] *(";" parameter) [CFWS]

>The trailing [CFWS] in Foo-header is unnecessary. The parameter ends 
>with value, which can either be a token or a quoted-string, each of 
>which ends with [CFWS].

Yup, and probably the other one as well if <Foo specific stuff> is written
sensibly.

-- 
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, 4 Mar 2002 09:42:39 -0600
To: [email-masked] (Charles Lindsey)
From: Pete Resnick <[email-masked]>
Subject: Re: quoted strings within quoted strings
Cc: [email-masked]
Sender: [email-masked]

On 3/4/02 at 11:39 AM +0000, Charles Lindsey wrote:

>quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]
>
>token = [CFWS] 1*<any (US-ASCII) CHAR except SP, CTLs or tspecials> [CFWS]

Or if you like:

ttext = ALPHA / DIGIT / "!" / "#" /
        "$" / "%" / "&" / "'" / "*" / "+" /
        "-" / "^" / "_" / "`" / "{" / "|" / "}" / "~"

token = [CFWS] 1*ttext [CFWS]

>value = token / quoted-string
>attribute = token
>parameter = attribute "=" value
>Foo-header = "Foo" ":" <Foo specific stuff> [CFWS] *(";" parameter) [CFWS]

The trailing [CFWS] in Foo-header is unnecessary. The parameter ends 
with value, which can either be a token or a quoted-string, each of 
which ends with [CFWS].

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: quoted strings within quoted strings
Date: Mon, 4 Mar 2002 16:19:04 +0100
Sender: [email-masked]

On Monday 04 March 2002 12:39, Charles Lindsey wrote:
<snip>
> All of which boils down to saying 'you can put CFWS on either side of
> a ";" or on either side of an "="'.
>
> Is that correct?

- From my reading of the rfc's, it is.

> An alternative way would that I am toying with would be to say: 
> 
> token = 1*<any (US-ASCII) CHAR except SP, CTLs or tspecials>
> value = [CFWS] token [CFWS] / quoted-string
> attribute = [CFWS] token [CFWS]
<snip>

But that would imply that the CFWS is _part_ of value and attribute, 
resp. It isn't. CFWS is never semantically relevant.

Marc

- -- 
Marc Mutz <[email-masked]>

To: [email-masked]
Xref: clerew local.mime:1133
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: quoted strings within quoted strings
Date: Mon, 4 Mar 2002 11:39:01 GMT
Lines: 86
Sender: [email-masked]

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

>> So I think I have to write something like

>> sender-parameter = [CFWS] "sender" [CFWS] "=" [CFWS]
>>                       <a quoted-string containing an escaped mailbox> [CFWS]

>> where I have to define "escaped" in the proper (recursive) way, and
>> probably also an "unescaping" operation.

>The MIME specification used to have per-parameter ABNF like this. The problem
>is that this ABNF is inevitably at odds with the more general ABNF and ends up
>being hugely confusing.

OK, the underlying problem is that you want to say that some
mumble-parameter is both a case of a general 'parameter' (as defined by
some syntax), and also has to satisfy some particular syntax of its own.

ABNF does not allow you to say that sort of thing directly, although you
CAN get the effect by saying 
	<a quoted-string containing an escaped mailbox> 
as I did above. I can see some benefit in both approaches, but note your
preference for not doing it that way.

>And there is ample data to support this point. I received numerous queries and
>complaints about the overlapping ABNF in the original MIME specification. Your
>query is the first I've seen about this sort of thing since all this gratuitous
>junk was removed from the MIME documents.

But I think to describe it as "gratuitous junk" is overdoing it :-) .

Anyway, now we are here, let me check whether I am putting the CFWS in the
right places, since in the post-2822 world all that stuff has to be put
explicitly in the syntax, and Usefor has to live in that world.

According to RFC 2822, we have

quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]

so we are stuck with that.

Thus, following that style, we would have

token = [CFWS] 1*<any (US-ASCII) CHAR except SP, CTLs or tspecials> [CFWS]

(ignoring, for the moment, slight complications arising from x-token,
iana-token, etc.)

And then

value = token / quoted-string
attribute = token
parameter = attribute "=" value
Foo-header = "Foo" ":" <Foo specific stuff> [CFWS] *(";" parameter) [CFWS]

All of which boils down to saying 'you can put CFWS on either side of a
";" or on either side of an "="'.

Is that correct? AFAICS that is exactly what you get by reading RFC 2045,
and interpreting it according to the RFC 822 folding rules. Certainly,
that is the assumptions I am building into Usefor.

An alternative way would that I am toying with would be to say:

token = 1*<any (US-ASCII) CHAR except SP, CTLs or tspecials>
value = [CFWS] token [CFWS] / quoted-string
attribute = [CFWS] token [CFWS]

which says the same thing, but makes is easier to say, when introducing
some new parameter, 'the attribute token is "foobar"', or 'the value token
is "yes" or "no" (possibly quoted)', or to say 'IANA should register the
token "foobar"'. It also makes it easier to introduce x-token, iana-token,
etc. in the proper manner.

-- 
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: Fri, 01 Mar 2002 15:03:37 -0800 (PST)
From: [email-masked]
Subject: Re: quoted strings within quoted strings
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> In <[email-masked]> Keith Moore <[email-masked]> writes:

> >> So what is the proper way to do it?
> >> Would it be

> >        sender = "\"John D. Bloggs\" <[email-masked]>"

> >IMHO yes.  and the value encded by that sender parameter is

> >"John D. Bloggs" <[email-masked]>

> OK. So is that behaviour written down anywhere (in RFC 2822 or RFC 2045)?

It is explicitly and formally laid out in the general parameter ABNF. Formal
languages are really good at this sort of thing.

> Or is it already implicit in those documents.

The use of the syntax to represent this sort of value is implicit, but IMO
completely obvious. This is also the approach used in RFC822, RFC2822, and
countless other documents.

> Or, to put it another way,
> does the first person who invents a parameter like that (which look like
> it will be me) have to say anything special to cover that case?

No.

> Well, I
> shall of course draw attention to it in a NOTE, but need I do more than
> that?

Not even a note is required.

> Answer: I think I do. There is special wording of that nature in RFC 2122
> (Multipart/Related) when describing the syntax of related-param.

Just because one specification went out of its way to belabor the obvious
is no reason you have to do so in yours.

> So I think I have to write something like

> sender-parameter = [CFWS] "sender" [CFWS] "=" [CFWS]
>                       <a quoted-string containing an escaped mailbox> [CFWS]

> where I have to define "escaped" in the proper (recursive) way, and
> probably also an "unescaping" operation.

The MIME specification used to have per-parameter ABNF like this. The problem
is that this ABNF is inevitably at odds with the more general ABNF and ends up
being hugely confusing.

And there is ample data to support this point. I received numerous queries and
complaints about the overlapping ABNF in the original MIME specification. Your
query is the first I've seen about this sort of thing since all this gratuitous
junk was removed from the MIME documents.

> Does that sound right?

No.

				Ned

To: [email-masked]
Xref: clerew local.mime:1129
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: quoted strings within quoted strings
Date: Fri, 1 Mar 2002 11:07:30 GMT
Lines: 41
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> So what is the proper way to do it?
>> Would it be

>        sender = "\"John D. Bloggs\" <[email-masked]>"

>IMHO yes.  and the value encded by that sender parameter is

>"John D. Bloggs" <[email-masked]>

OK. So is that behaviour written down anywhere (in RFC 2822 or RFC 2045)?
Or is it already implicit in those documents. Or, to put it another way,
does the first person who invents a parameter like that (which look like
it will be me) have to say anything special to cover that case? Well, I
shall of course draw attention to it in a NOTE, but need I do more than
that?

Answer: I think I do. There is special wording of that nature in RFC 2122
(Multipart/Related) when describing the syntax of related-param. So I
think I have to write something like

sender-parameter = [CFWS] "sender" [CFWS] "=" [CFWS]
                      <a quoted-string containing an escaped mailbox> [CFWS]

where I have to define "escaped" in the proper (recursive) way, and
probably also an "unescaping" operation.

Does that sound right?

-- 
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: Fri, 01 Mar 2002 12:01:55 +0000
To: Keith Moore <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Message Header Field Registry - revised proposal 
Cc: [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

Thanks,  then I agree with Charles.

#g
--

At 08:19 PM 2/28/02 -0500, Keith Moore wrote:

> >  Aren't experimental RFCs last-called?
>
>they don't have to be.  IESG can ask for one, but it's not required.

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

To: [email-masked]
Xref: clerew local.mime:1128
Newsgroups: local.mime
Path: clerew!chl
From: "Charles H. \"Usefor\" Lindsey" <[email-masked]>
Subject: Re: quoted strings within quoted strings
Date: Fri, 1 Mar 2002 10:26:22 GMT
Lines: 35
Sender: [email-masked]

In <2147483647.1014899942@[10.0.1.2]> Cyrus Daboo <[email-masked]> writes:

>sender = "\"John D. \\\"Cool\\\" Bloggs" <[email-masked]>"

That's Cool!

Does anyone know of any software out there that would actually unscramble
that? Or maybe it is the case that no (non-human) application actually has
the need to do so. I suppose the case would arise if the protocol required
you to send mail to the entity identified by the 'sender' parameter.

Anyway, I have tried something of the sort in the From header of this
message which, as I just wrote it, says:
	From: "Charles H. \"Usefor\" Lindsey" <[email-masked]>
Let us see if anything different is seen by anyone anywhere.

Actually, I now recall contructing such an example to test a
canonicalization rule in draft-lindsey-usefor-signed-01.txt.

tO:     "John (the Boss) Smith"  <[email-masked]> ,
   "Bill \"fingers\"
 Sykes" <"#*\"~"@twist.example> (Observe unescaped \( and escaped "
 within quoted strings, and (properly matched) parentheses within
 comments)

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