Subject: eMail address variation contra mail-spam - thanks for the replies....
From: [email-masked] (Juergen Helbing)
To: [email-masked]
Date: Thu, 28 Nov 2002 11:27:33 GMT
List-Id: <ietf-822.imc.org>

I want to thank everybody for your replies (also those by mail).

The 'TMDA' approach is unusable for average or newbie users.
The use of 'subadresses' seems to be already what I am looking for -
and as their seems to be a decade of experience I'll investigate more
into this direction by private mail.

In case of success you'll see a conclusion of my efforts here.

'Til then: CU

-- 
Juergen

Date: Tue, 26 Nov 2002 19:27:18 +0000
To: [email-masked] (Juergen Helbing)
From: Graham Klyne <[email-masked]>
Subject: Re: Newbie question:  eMail address variation contra mail-spam ?
Cc: [email-masked]
Sender: [email-masked]

There was a paper published (I think) in Communications of ACM some time 
ago using this basic idea, though I can't find the exact reference, from a 
group at Bell Labs.

#g
--

At 04:42 PM 11/26/02 +0000, Juergen Helbing wrote:

>I hope this is not too far away from the topic of this list:
>
>The amount of eMail spam has been reaching new levels so I want to
>find a solution at least for myself - and my small company.
>
>
>Did anybody already discuss/try/has experiences with "variable eMail
>addresses" as a weapon for the 'enduser' ?
>I am having meanwhile very good experiences with using
>"one-time-mail-accounts" (on a tiny selfmade SMTP demon) - so I'd like
>to know whether there is work in progress to give the user more
>"power". (before I invent the wheel again :-)
>
>This might not be directly a "message format issue" as long as the
>From: header is valid.
>
>But making changes to SMTP/POP3/mailreaders/msgformats seems to be an
>impossible job nowadays - so perhaps 'bypassing' is a short-term
>solution for specific applications.
>Especially frequent Usenet visitors (as myself) need something before
>eMail becomes finally unusable. (My mailbox today: 350 eMails, 10%
>serious, 90% spam).
>
>
>Some details:
>
>I've been fooling around already with a large set of complete own
>mailboxes - but this is impractical for daily use. So I'm now tending
>to add "value" to the eMail addresses I'm using:
>
>If I'm using:   [email-masked]
>then this address is only valid for 30 days - and the incoming
>messages are still placed in the mailbox "archiver".
>
>For a reply to an unknown person I would use:
>     [email-masked]
>So the mail-address is already a 'password' for the recipient (which
>is only valid for seven days  ;-)
>
>Something as "[email-masked]" might be used to remove such
>an account from the mail-server.
>
>
>If all this is nonsense - or if there are already bad experiences with
>such methods, then please tell me and apologize my intrusion.
>
>
>TIA
>--
>Juergen

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

Date: Tue, 26 Nov 2002 10:41:47 -0800 (PST)
From: [email-masked]
Subject: Re: Newbie question: eMail address variation contra mail-spam ?
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > Did anybody already discuss/try/has experiences with "variable eMail
> > addresses" as a weapon for the 'enduser' ?

> I've been using subaddresses for this purpose for nearly a decade.

I have as well, for about the same amount of time.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked] (Juergen Helbing)
cc: [email-masked]
Subject: Re: Newbie question: eMail address variation contra mail-spam ? 
Date: Tue, 26 Nov 2002 12:25:00 -0500
Sender: [email-masked]

> Did anybody already discuss/try/has experiences with "variable eMail
> addresses" as a weapon for the 'enduser' ?

I've been using subaddresses for this purpose for nearly a decade.

Date: Tue, 26 Nov 2002 09:14:12 -0800
From: Michael Elkins <[email-masked]>
To: [email-masked]
Subject: Re: Newbie question:  eMail address variation contra mail-spam ?
Sender: [email-masked]

On 2002-11-26, Juergen Helbing <[email-masked]> wrote:
> Did anybody already discuss/try/has experiences with "variable eMail
> addresses" as a weapon for the 'enduser' ?   

There are a couple of projects out there of this ilk.  The one I've
heard most about is TMDA (tmda.net).

me

From: [email-masked] (Juergen Helbing)
To: [email-masked]
Subject: Newbie question:  eMail address variation contra mail-spam ?
Date: Tue, 26 Nov 2002 16:42:58 GMT
Sender: [email-masked]

I hope this is not too far away from the topic of this list:

The amount of eMail spam has been reaching new levels so I want to
find a solution at least for myself - and my small company.

Did anybody already discuss/try/has experiences with "variable eMail
addresses" as a weapon for the 'enduser' ?   
I am having meanwhile very good experiences with using
"one-time-mail-accounts" (on a tiny selfmade SMTP demon) - so I'd like
to know whether there is work in progress to give the user more
"power". (before I invent the wheel again :-)

This might not be directly a "message format issue" as long as the
From: header is valid.

But making changes to SMTP/POP3/mailreaders/msgformats seems to be an
impossible job nowadays - so perhaps 'bypassing' is a short-term
solution for specific applications.
Especially frequent Usenet visitors (as myself) need something before
eMail becomes finally unusable. (My mailbox today: 350 eMails, 10%
serious, 90% spam).

Some details:

I've been fooling around already with a large set of complete own
mailboxes - but this is impractical for daily use. So I'm now tending
to add "value" to the eMail addresses I'm using:

If I'm using:   [email-masked]
then this address is only valid for 30 days - and the incoming
messages are still placed in the mailbox "archiver".

For a reply to an unknown person I would use:
    [email-masked]
So the mail-address is already a 'password' for the recipient (which
is only valid for seven days  ;-)

Something as "[email-masked]" might be used to remove such
an account from the mail-server.

If all this is nonsense - or if there are already bad experiences with
such methods, then please tell me and apologize my intrusion. 

TIA
-- 
Juergen

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: RFC2231 encoding in parameters.
Cc: [email-masked]
Date: Mon, 18 Nov 2002 16:45:40 +0100
Sender: [email-masked]

[email-masked] writes:
> 1) Are any MUAs "in the wild" currently actually using the 2047-style 
> encoding in parameters rather than the 2231 syntax? If so, who are 
> they, and who wants to send the authors a note? ;)

I did a little bit of grepping in my mail archives and see that pine, 
evolution, outlook and mutt may all at one time have generated 
2047-style syntax. Of those four, the only one I can test is mutt, 
which generates 2331-style syntax (in version 1.3.23).

I would have sent people mail, but quite frankly I find it difficult to 
speak up for 2331-style syntax...

--Arnt

Date: Sun, 17 Nov 2002 09:02:14 -0800 (PST)
From: [email-masked]
Subject: Re: Fwd: Last Call: Registration procedures for message header  fields to BCP
To: Graham Klyne <[email-masked]>
Cc: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>, [email-masked]
Sender: [email-masked]

> At 03:09 PM 11/12/02 -0500, Keith Moore wrote:
> >actually I'd say that for standards-track documents (for which change
> >control rests with IETF) then the "change controller" should be IETF,
> >not the author of the latest document that specified that field.

> I agree ... that was (at some point) my intent, but I seem to have
> forgotten that bit.

> Any suggestions for an email address to use.  (I think I currently use
> [email-masked] in some places.)

That's probably the right one to use.

				Ned

Date: Sun, 17 Nov 2002 08:01:46 -0800 (PST)
From: [email-masked]
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> At 14:16 +0000 02-11-14, Graham Klyne wrote:
> >>If the registry, as maintained by IANA, is in a web format, then quoting
> >>just the RFC numbers visibly, with the URL hidden behind it for clicking
> >>purposes, would be fine. No clutter to confuse the viewer.
> >
> >Yes - easily arranged.
> >
> >>If the registry is to be available in printed form, then again the RFC
> >>numbers should appear at those points, and the full titles, URLs, etc
> >>should be listed in a References section at the end.
> >
> >That sounds like a good plan.  Though we do have the issue
> >that the change controller is not necessarily the
> >specification document author.

> Would not the registry itself be using some data base
> system. And this discussion then is about the user
> interface to this data base. There could be both an
> interactive web interface, possibly with a search facility,
> a print-on-paper interface, and possibly an interface
> producing just ASCII text for those who want that. An
> interface using HTML tables is useful, because there are
> software to convert HTML tables to most formats the
> recipient wants to have the information converted to.

> Or does IANA prefer to store everything
> in text files, and not use data base systems?

This is entirely up to IANA. We specify what goes in the registry and how. It
is up to IANA to decide how to implement that.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: RFC2231 encoding in parameters. 
Date: Sat, 16 Nov 2002 10:35:55 -0500
Sender: [email-masked]

the filename parameter is advisory. the receiving MUA can do whatever it wants
with it, including choosing whether to translate the characters from one charset
to another.

Date: Fri, 15 Nov 2002 21:53:52 +0000
To: "Charles Lindsey" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Cc: [email-masked]
Sender: [email-masked]

At 12:13 PM 11/15/02 +0000, Charles Lindsey wrote:
>Well if you look at draft-klyne-msghdr-registry-05.txt, which will be an
>RFC very soon if the IESG are willing, you will see that the Change
>Controller must be the IETF for standards track stuff. So the point is
>already covered.

Yeah... I just didn't carry through properly into the initial registrations.

>There is no suggestion that the contents of the registry form an RFC at
>any stage, though we do have various drafts (some of them with the status
>of internet-drafts, but that is only a convenience) as to what its initial
>contents should be.

Well, an RFC for initial registrations (as well as the -registry- doc) is 
what I was thinking of, though that document isn't currently in last 
call.  I think it's reasonable to discuss the form of such a document, 
since it gives some substance to the registry proposal that is being called.

>I would presume that Graham will work with IANA to feed that information
>to them in some agreed format.

That is my intent.

#g

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

To: [email-masked]
Subject: RFC2231 encoding in parameters.
From: [email-masked]
Date: Sat, 16 Nov 2002 00:23:31 -0500
Sender: [email-masked]

--==_Exmh_-1340586927P
Content-Type: text/plain; charset=us-ascii

Tonight, somebody posted a patch for the Exmh MUA, described as follows:

> This patch for mime.tcl attempts to separate the header decoding from
> the header display, so that Mime_SavePiece can use the decode routines
> to handle stuff like:

> Content-Disposition: attachment; filename="=?iso-8859-1?Q?JVM=5FTask.c?="

> It is not perfect yet because the character set specification is
> silently ignored.

I voted against the patch on the grounds that RFC2231 specifies a different
syntax, and said a 2231-style patch would be encouraged.  But it still
left me with a queasy feeling on two points:

1) Are any MUAs "in the wild" currently actually using the 2047-style encoding
in parameters rather than the 2231 syntax?  If so, who are they, and who wants
to send the authors a note? ;)

2) RFC2183 assumes that a "filename" parameter is us-ascii, since RFC2045
didn't define an extension.  RFC2231 added the syntax, making it legal to
specify a charset/language for a filename.  However, I admit being totally
befuddled regarding the *semantics* of such a specification.  On many
filesystems, the charset/lang don't matter, as long as the octets are
decoded to the originally intended binary stream.  However, it's not
obvious what to do if, for instance, your system is UTF-8 or one of the
systems that has multiple IBM-nnn codepage locals, and the header shows up
as iso-2022-jp.  Should the MUA attempt conversion, or leave it as an octet
stream?

Converting works better at the user-visible level - if the sender wanted
kanji in the filename, then a case can be made that converting to a
representation that displays the kanji (although at a different codepoint)
would benefit the user.  On the other hand, it will totally hose any
automated 'manifest checkers' that go looking for a specific filename.

I'm sure there's other issues I've missed here...

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-1340586927P
Content-Type: application/pgp-signature

--==_Exmh_-1340586927P--

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Fri, 15 Nov 2002 18:42:37 -0500
Sender: [email-masked]

> My personal preference is that displaying agents should leave the received
> folding alone if it will fit into whatever windows it is using, just in
> case it retains some useful structuring put there by the author.

well, that's sort of why I suggested refolding only the ones that have
encoded-words as a 'conservative' policy -  because it's so often necessary 
for user agents to add additional line breaks to them anyway.

but I actually think it's reasonable for a receiving MUA to refold 
any field.

in my experience careful refolding can dramatically improve the 
quality of presentation.  so smart UA implementors will probably do it,
perhaps with a "show original format" option for purists.

Keith

To: [email-masked]
Xref: clerew local.mime:1940
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Date: Fri, 15 Nov 2002 12:21:38 GMT
Lines: 29
Sender: [email-masked]

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

>I think all of this hinges on whether we think of header fields, like
>Subject, as being under user format control, like the body, or whether we
>view them as being "structured" meta-information.  Typically, no one gets
>upset when structured information is re-formatted.  In fact it is usually
>considered to be a benefit.

>I prefer the meta-information model for all headers.

OTOH, fields like Subject are explicitly defines as "unstructured".

My personal preference is that displaying agents should leave the received
folding alone if it will fit into whatever windows it is using, just in
case it retains some useful structuring put there by the author.

Generally speaking, Gatesian User Agents that try to be "smart" do more
harm than good :-( .

-- 
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:1939
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Date: Fri, 15 Nov 2002 12:17:20 GMT
Lines: 28
Sender: [email-masked]

In <[email-masked]> "Dan Kohn" <[email-masked]> writes:

>Graham, given that RFC 1700 was obsoleted by RFC 3232, I question the
>whole need for an archival RFC, that is by definition almost instantly
>out of date.

Eh? That is not what is proposed.

What we have (at IETF Last Call stage) in an RFC that creates the registry.

There is no suggestion that the contents of the registry form an RFC at
any stage, though we do have various drafts (some of them with the status
of internet-drafts, but that is only a convenience) as to what its initial
contents should be.

I would presume that Graham will work with IANA to feed that information
to them in some agreed format.

-- 
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:1938
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Date: Fri, 15 Nov 2002 12:13:38 GMT
Lines: 30
Sender: [email-masked]

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

>At 03:09 PM 11/12/02 -0500, Keith Moore wrote:
>>actually I'd say that for standards-track documents (for which change
>>control rests with IETF) then the "change controller" should be IETF,
>>not the author of the latest document that specified that field.

>I agree ... that was (at some point) my intent, but I seem to have 
>forgotten that bit.

Well if you look at draft-klyne-msghdr-registry-05.txt, which will be an
RFC very soon if the IESG are willing, you will see that the Change
Controller must be the IETF for standards track stuff. So the point is
already covered.

>Any suggestions for an email address to use.  (I think I currently use 
>[email-masked] in some places.)

Does one actually need to include 1 for such an obvious case?

-- 
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: Thu, 14 Nov 2002 15:18:39 -0600
To: "Dan Kohn" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: Problem with MIME and line length in Subject headers
Cc: <[email-masked]>
Sender: [email-masked]

On 11/14/02 at 12:54 PM -0800, Dan Kohn wrote:

>and suggest that a new paragraph should be added to the end of RFC 
>2822, Section 2.2.3:
>
>Mail User Agents SHOULD unfold headers that are displayed to the 
>end-user (such as Subject, To, and Cc), since line breaks in headers 
>do not have semantic content (unlike in message bodies, where they 
>often denote paragraph or list breaks).

I cannot express how strongly I feel that this does not belong in RFC 
2822. I would *consider* putting in a "Note:" which says that often 
it is nice for user agents to unfold Subjects for presentation to the 
user, but there is no way that this comes remotely close to an RFC 
2119 "SHOULD". It is certainly not normative.

If someone wants to write an informational RFC on "What MUAs ought to 
do", more power to you. But nothing like this belongs in 2822.

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

From: Keith Moore <[email-masked]>
To: "Dan Kohn" <[email-masked]>
cc: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Thu, 14 Nov 2002 16:14:57 -0500
Sender: [email-masked]

> Mail User Agents SHOULD unfold headers that are displayed to the

NO NO NO.  

It's fine to state that line breaks in headers have no semantic content
and are not expected to be preserved end-to-end, and that user agents
MAY alter or ignore them in presentation.  It's not fine to say how
MUAs should present them.  

Keith

Date: Thu, 14 Nov 2002 21:52:09 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header   fields to BCP
Sender: [email-masked]

At 14:16 +0000 02-11-14, Graham Klyne wrote:
>>If the registry, as maintained by IANA, is in a web format, then quoting
>>just the RFC numbers visibly, with the URL hidden behind it for clicking
>>purposes, would be fine. No clutter to confuse the viewer.
>
>Yes - easily arranged.
>
>>If the registry is to be available in printed form, then again the RFC
>>numbers should appear at those points, and the full titles, URLs, etc
>>should be listed in a References section at the end.
>
>That sounds like a good plan.  Though we do have the issue 
>that the change controller is not necessarily the 
>specification document author.

Would not the registry itself be using some data base
system. And this discussion then is about the user
interface to this data base. There could be both an
interactive web interface, possibly with a search facility,
a print-on-paper interface, and possibly an interface
producing just ASCII text for those who want that. An
interface using HTML tables is useful, because there are
software to convert HTML tables to most formats the
recipient wants to have the information converted to.

Or does IANA prefer to store everything
in text files, and not use data base systems?
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

content-class: urn:content-classes:message
Subject: RE: Problem with MIME and line length in Subject headers
Date: Thu, 14 Nov 2002 12:54:56 -0800
From: "Dan Kohn" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I would second Dave's suggestion, and suggest that a new paragraph
should be added to the end of RFC 2822, Section 2.2.3:

Mail User Agents SHOULD unfold headers that are displayed to the
end-user (such as Subject, To, and Cc), since line breaks in headers do
not have semantic content (unlike in message bodies, where they often
denote paragraph or list breaks).

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>  

  Randomly generated quote:
If you're a winner, you don't go to the government. You're too busy. You
have too many customers. It's the people with no customers who end up
besieging the government.... The dog technologies run to Washington,
decked out like poodles. The politician is always the dog's best friend.
- George Gilder

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Thursday, November 14, 2002 11:59
To: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers

Pete,

Thursday, November 14, 2002, 11:23:11 AM, you wrote:
Pete>  Whether it should be
Pete> changed to unfold a header field that is received is a trickier 
Pete> business. My feeling is yes, but it's at least an interesting 
Pete> question.

I think all of this hinges on whether we think of header fields, like
Subject, as being under user format control, like the body, or whether
we
view them as being "structured" meta-information.  Typically, no one
gets
upset when structured information is re-formatted.  In fact it is
usually
considered to be a benefit.

I prefer the meta-information model for all headers.

d/
-- 
 Dave Crocker  <mailto:[email-masked]>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850

Date: Thu, 14 Nov 2002 11:58:55 -0800
From: Dave Crocker <[email-masked]>
Organization: TribalWise
To: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers
Sender: [email-masked]

Pete,

Thursday, November 14, 2002, 11:23:11 AM, you wrote:
Pete>  Whether it should be
Pete> changed to unfold a header field that is received is a trickier 
Pete> business. My feeling is yes, but it's at least an interesting 
Pete> question.

I think all of this hinges on whether we think of header fields, like
Subject, as being under user format control, like the body, or whether we
view them as being "structured" meta-information.  Typically, no one gets
upset when structured information is re-formatted.  In fact it is usually
considered to be a benefit.

I prefer the meta-information model for all headers.

d/
-- 
 Dave Crocker  <mailto:[email-masked]>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, "Charles Lindsey" <[email-masked]>, [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Thu, 14 Nov 2002 14:36:18 -0500
Sender: [email-masked]

> >uh, no.  RFC 2822 is concerned with the user agent protocol, and it
> >does  place a few requirements on user agents.  RFC 2821 is
> >concerned with the mail transport protocol, so it places
> >requirements on MTAs.
> 
> Well, that's true, but the rest of Charles's message was exactly
> right: RFC 2822 does not require (or even recommend) that user agents
> unfold folded headers for any reason. 

That's right, it doesn't.  And that's what I meant about 2822 not being
clear (though I didn't say it that well) - it talks about how folding
affects semantics of fields, but not about whether CRLFs within folded 
fields can be assumed to be significant.

> But I think 2822 is *very* clear on the semantics of folding. What it
> doesn't say is what (if anything) a UA should do as far as unfolding
> goes for presentation to the user.

Normally we wouldn't say much about presentation anyway.  What we could 
say is that there is no expectation that CRLFs within header fields 
are as intended by the sender.

> >but longstanding practice is that both UAs and MTAs can change the
> >folding from that supplied by the sender.
> 
> "Can change"? Of course. But that wasn't the question that was being
> asked here. The question is "Should folding be changed?" 

My point is that a receiving MUA should not assume that any CRLFs
present in a header field were intended to be there by the sender.
Therefore there is no obligation to preserve those CRLFs in presentation, 
and MUAs are free to re-fold fields for the purpose of presentation
as they deem appropriate.

Keith

Date: Thu, 14 Nov 2002 18:44:01 +0000
To: "Dan Kohn" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: Fwd: Last Call: Registration procedures for message header fields to BCP
Cc: <[email-masked]>
Sender: [email-masked]

This is a fair observation.  I would certainly agree to the extent that it 
would be more productive to focus efforts on improving the registry pages 
presentation.

I had been proceeding on the basis that the *formal* document to IANA to 
create the initial registrations would be an RFC, and that we would work 
with IANA "behind the scenes" to get that information into the initial 
registry set up in a way that IANA are comfortable with 
maintaining.  Ultimately, I think the appropriate course is to do what is 
best for IANA.

#g
--

At 09:47 AM 11/14/02 -0800, Dan Kohn wrote:
>Graham, given that RFC 1700 was obsoleted by RFC 3232, I question the
>whole need for an archival RFC, that is by definition almost instantly
>out of date.
>
>I think your time would be much better spent improving the HTML-based
>reference [1] that could then handed over to IANA.  Of course, you would
>probably want to get IANA's permission/agreement before you got too far
>along, to make sure it's in a form they would be willing to administer
>going forward.  Specifically, is IANA going to want to use the same
>underlying database you do and then compile the HTML, or do they just
>want the HTML and will make changes manually?
>
>However, I can never imagine a situation in which I would check the RFC
>rather than the up-to-date IANA registry, so I would skip the former
>entirely.
>
>[1]
>http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanent
>Registry.html
>
>           - dan
>--
>Dan Kohn <mailto:[email-masked]>
><http://www.dankohn.com/>  <tel:+1-650-327-2600>
>
>   Randomly generated quote:
>If you're afraid of criticism, don't say anything, don't do anything,
>and don't be anything.  - Marian Wright Edelman
>
>
>-----Original Message-----
>From: Graham Klyne [mailto:[email-masked]]
>Sent: Wednesday, November 13, 2002 06:21
>To: Charles Lindsey
>Cc: [email-masked]
>Subject: Re: Fwd: Last Call: Registration procedures for message header
>fields to BCP
>
>
>
>OK, I see your point. (-01 is not really different in this respect.)
>
>I'll look into updating the tools in some way.  I think it calls for
>rethinking the overall form of presentation:  cross-referencing from one
>
>entry to another is likely to get messy.
>
>I'll note that I don't expect the registration document to be used as a
>common reference, rather that it contains some information that goes
>into a
>registry.  For an online registry, I think the duplication is not a
>problem
>(there is a summary table of
>header fields, each linked to a registry page).  Though, if it's felt to
>be
>a significant improvement, I could look into separating the change
>controller information and linking through to it.  (Needless to say, the
>
>duplication doesn't occur in the original source data!)
>
>As for draft-palme-mailext-headers-08.txt, I've been in touch with
>Jacob.  I just haven't found time to follow through, yet.
>
>#g
>--
>
>At 11:45 AM 11/12/02 +0000, Charles Lindsey wrote:
>
> >In <[email-masked]> Graham Klyne
> ><[email-masked]> writes:
> >
> > >I assume you refer to [1] [2].  See also [3] for an example of
>possible
> > >registry data on the Web.
> >
> >
> > >[1]
>http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-01.txt
> > >     (whose content is set to be updated, with input from Jacob
>Palme)
> >
> > >[2]
>http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http-00.txt
> >
> > >[3]
> >
> >http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanen
>tR
> > egistry.html
> > >
> >
>http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderProvision
>alRegistry.html
> >
> >The last one I saw was draft-klyne-hdrreg-mail-00.txt, so I need to
>look
> >at the others. But here is an example from that document:
> >
> >2.1.3 Sender: header
> >
> >    Header name:
> >       Sender
> >
> >    Description:
> >       Mailbox of message sender
> >
> >    Applicable protocol:
> >       mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
> >
> >    Status:
> >       standards-track
> >
> >    Author/change controller:
> >       Peter W.  Resnick  (mailto:[email-masked])
> >       QUALCOMM Incorporated, 5775 Morehouse Drive,
> >       San Diego, CA 92121-1714, USA.
> >       Tel: +1 858 651 4478
> >       Fax: +1 858 651 1102
> >
> >    Specification document(s):
> >       http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
> >
> >    Related information:
> >       Specifies the mailbox of the agent responsible for the actual
> >       transmission of the message.
> >
> >
> >2.1.4 Reply-To: header
> >
> >    Header name:
> >       Reply-To
> >
> >    Description:
> >       Mailbox for replies to message
> >
> >    Applicable protocol:
> >       mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
> >
> >    Status:
> >       standards-track
> >
> >    Author/change controller:
> >       Peter W.  Resnick  (mailto:[email-masked])
> >       QUALCOMM Incorporated, 5775 Morehouse Drive,
> >       San Diego, CA 92121-1714, USA.
> >       Tel: +1 858 651 4478
> >       Fax: +1 858 651 1102
> >
> >    Specification document(s):
> >       http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
> >
> >    Related information:
> >       When the R"eply-To: "field is present, it indicates the
> >       mailbox(es) to which the author of the message suggests that
> >       replies be sent.
> >
> >
> >All in all, Peter Resnick's full address appears 22 times in that
> >document. It shouldn't require any rocket science to include it once,
>with
> >suitable pointers when required. Indeed, when there is an RFC mentioned
> >(as there usually is), then it should suffice to assume that the RFC
> >author is the responsible controller, except in special cases where he
> >isn't.
> >
> >Again, it should not be necessary to give a full URL for an RFC. They
>are
> >well known documents (and that URL is not the only place from which
>they
> >can be retrieved). It should suffice for a preamble to the Registry to
> >explain the notation and how to obtain RFCs. And maybe a separate
> >references section containing the usual Bibliographic details for all
>RFCs
> >mentioned in the registry.
> >
> >But as it stands, there is so much wood that it is difficult to discern
> >the trees.
> >
> >BTW, please note that there is now a new draft of Jacob Palme's list of
> >headers as draft-palme-mailext-headers-08.txt.
> >
> >--
> >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
>
>-------------------
>Graham Klyne
><[email-masked]>

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

Date: Thu, 14 Nov 2002 13:23:11 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Cc: "Charles Lindsey" <[email-masked]>, [email-masked]
Sender: [email-masked]

On 11/14/02 at 12:50 PM -0500, Keith Moore wrote:

>uh, no.  RFC 2822 is concerned with the user agent protocol, and it 
>does  place a few requirements on user agents.  RFC 2821 is 
>concerned with the mail transport protocol, so it places 
>requirements on MTAs.

Well, that's true, but the rest of Charles's message was exactly 
right: RFC 2822 does not require (or even recommend) that user agents 
unfold folded headers for any reason. It simply says that for 
syntactic or semantic evaluation, they should be treated as if they 
were unfolded (e.g., if you compare to Subjects for identity, compare 
the unfolded form).

>I don't think either 822 or 2822 is clear about the semantics of 
>folding of header fields.

If you've got problems with 2.2.3, I'm open to suggestions. But I 
think 2822 is *very* clear on the semantics of folding. What it 
doesn't say is what (if anything) a UA should do as far as unfolding 
goes for presentation to the user.

>but longstanding practice is that both UAs and MTAs can change the 
>folding from that supplied by the sender.

"Can change"? Of course. But that wasn't the question that was being 
asked here. The question is "Should folding be changed?" It certainly 
shouldn't by MTAs (the "don't touch the contents of the message" 
maxim). It should be changed by UAs if the user has requested a very 
long header field that needs to be folded. Whether it should be 
changed to unfold a header field that is received is a trickier 
business. My feeling is yes, but it's at least an interesting 
question.

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

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Thu, 14 Nov 2002 12:50:35 -0500
Sender: [email-masked]

> That is because it is not the function of RFC 2822 to specify requirements
> placed on Agents, that being left to other documents (notably RFC 2821).

uh, no.  RFC 2822 is concerned with the user agent protocol, and it does 
place a few requirements on user agents.  RFC 2821 is concerned with 
the mail transport protocol, so it places requirements on MTAs.

historically we're reluctant to impose many requirements on user agents
because user requirements and programming environments have always
varied widely, and have also changed considerably over time.

I don't think either 822 or 2822 is clear about the semantics of folding
of header fields.  but longstanding practice is that both UAs and MTAs 
can change the folding from that supplied by the sender.

Keith

content-class: urn:content-classes:message
Subject: RE: Fwd: Last Call: Registration procedures for message header  fields to BCP
Date: Thu, 14 Nov 2002 09:47:37 -0800
From: "Dan Kohn" <[email-masked]>
To: "Graham Klyne" <[email-masked]>, "Charles Lindsey" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Graham, given that RFC 1700 was obsoleted by RFC 3232, I question the
whole need for an archival RFC, that is by definition almost instantly
out of date.

I think your time would be much better spent improving the HTML-based
reference [1] that could then handed over to IANA.  Of course, you would
probably want to get IANA's permission/agreement before you got too far
along, to make sure it's in a form they would be willing to administer
going forward.  Specifically, is IANA going to want to use the same
underlying database you do and then compile the HTML, or do they just
want the HTML and will make changes manually?

However, I can never imagine a situation in which I would check the RFC
rather than the up-to-date IANA registry, so I would skip the former
entirely. 

[1]
http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanent
Registry.html

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>  

  Randomly generated quote:
If you're afraid of criticism, don't say anything, don't do anything,
and don't be anything.  - Marian Wright Edelman

-----Original Message-----
From: Graham Klyne [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2002 06:21
To: Charles Lindsey
Cc: [email-masked]
Subject: Re: Fwd: Last Call: Registration procedures for message header
fields to BCP

OK, I see your point. (-01 is not really different in this respect.)

I'll look into updating the tools in some way.  I think it calls for 
rethinking the overall form of presentation:  cross-referencing from one

entry to another is likely to get messy.

I'll note that I don't expect the registration document to be used as a 
common reference, rather that it contains some information that goes
into a 
registry.  For an online registry, I think the duplication is not a
problem 
(there is a summary table of
header fields, each linked to a registry page).  Though, if it's felt to
be 
a significant improvement, I could look into separating the change 
controller information and linking through to it.  (Needless to say, the

duplication doesn't occur in the original source data!)

As for draft-palme-mailext-headers-08.txt, I've been in touch with 
Jacob.  I just haven't found time to follow through, yet.

#g
--

At 11:45 AM 11/12/02 +0000, Charles Lindsey wrote:

>In <[email-masked]> Graham Klyne 
><[email-masked]> writes:
>
> >I assume you refer to [1] [2].  See also [3] for an example of
possible
> >registry data on the Web.
>
>
> >[1]
http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-01.txt
> >     (whose content is set to be updated, with input from Jacob
Palme)
>
> >[2]
http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http-00.txt
>
> >[3]
>
>http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanen
tR 
> egistry.html
> > 
>
http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderProvision
alRegistry.html
>
>The last one I saw was draft-klyne-hdrreg-mail-00.txt, so I need to
look
>at the others. But here is an example from that document:
>
>2.1.3 Sender: header
>
>    Header name:
>       Sender
>
>    Description:
>       Mailbox of message sender
>
>    Applicable protocol:
>       mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
>
>    Status:
>       standards-track
>
>    Author/change controller:
>       Peter W.  Resnick  (mailto:[email-masked])
>       QUALCOMM Incorporated, 5775 Morehouse Drive,
>       San Diego, CA 92121-1714, USA.
>       Tel: +1 858 651 4478
>       Fax: +1 858 651 1102
>
>    Specification document(s):
>       http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
>
>    Related information:
>       Specifies the mailbox of the agent responsible for the actual
>       transmission of the message.
>
>
>2.1.4 Reply-To: header
>
>    Header name:
>       Reply-To
>
>    Description:
>       Mailbox for replies to message
>
>    Applicable protocol:
>       mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
>
>    Status:
>       standards-track
>
>    Author/change controller:
>       Peter W.  Resnick  (mailto:[email-masked])
>       QUALCOMM Incorporated, 5775 Morehouse Drive,
>       San Diego, CA 92121-1714, USA.
>       Tel: +1 858 651 4478
>       Fax: +1 858 651 1102
>
>    Specification document(s):
>       http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
>
>    Related information:
>       When the R"eply-To: "field is present, it indicates the
>       mailbox(es) to which the author of the message suggests that
>       replies be sent.
>
>
>All in all, Peter Resnick's full address appears 22 times in that
>document. It shouldn't require any rocket science to include it once,
with
>suitable pointers when required. Indeed, when there is an RFC mentioned
>(as there usually is), then it should suffice to assume that the RFC
>author is the responsible controller, except in special cases where he
>isn't.
>
>Again, it should not be necessary to give a full URL for an RFC. They
are
>well known documents (and that URL is not the only place from which
they
>can be retrieved). It should suffice for a preamble to the Registry to
>explain the notation and how to obtain RFCs. And maybe a separate
>references section containing the usual Bibliographic details for all
RFCs
>mentioned in the registry.
>
>But as it stands, there is so much wood that it is difficult to discern
>the trees.
>
>BTW, please note that there is now a new draft of Jacob Palme's list of
>headers as draft-palme-mailext-headers-08.txt.
>
>--
>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

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

To: [email-masked]
Xref: clerew local.mime:1924
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Date: Thu, 14 Nov 2002 12:24:53 GMT
Lines: 37
Sender: [email-masked]

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

>RFC 2822 Sections 2.2.1 and 2.2.3 clearly say that all unstructure 
>headers, including Subject headers, can be folded and unfolded, and how 
>to do so.

No, it does not say that.

It says that a syntactically correct Internet Message can contain headers
folded according to certain rules, and that the semantic meaning of any
such header is the same as the semantic meaning of that header when fully
unfolded.

It does not anywhere say that Agents may (or may not for that matter)
change the folding for arbitrary reason either en route or on display.
That is because RFC 2822 is completely silent upon what any Agent is
required to do (beyond accepting and transmitting well-formed messages).
That is because it is not the function of RFC 2822 to specify requirements
placed on Agents, that being left to other documents (notably RFC 2821).

So in fact there is nothing said anywhere about when or whether refolding
is permitted, which is perhaps unfortunate since everybody then feels that
they can do whatever they like. I would accept that it is fine for User
Agents to do whatever they think best when displaying messages, but I
think it is disastrous for anything else in the system to be changing
anything (except maybe CTE - and even that leads to assorted woes).

-- 
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: Thu, 14 Nov 2002 14:16:27 +0000
To: "Charles Lindsey" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Cc: [email-masked]
Sender: [email-masked]

At 11:14 AM 11/13/02 +0000, Charles Lindsey wrote:

>In <[email-masked]> Dave Crocker 
><[email-masked]> writes:
>
> >Charles> Again, it should not be necessary to give a full URL for an RFC.
>
> >including the url makes an online copy of the document quite a bit more 
> convenient.
>
>In the end, it is up to IANA how they format the registry, but we should
>be giving them good examples of the kind of thing we would like to see.

Of course.

>If the registry, as maintained by IANA, is in a web format, then quoting
>just the RFC numbers visibly, with the URL hidden behind it for clicking
>purposes, would be fine. No clutter to confuse the viewer.

Yes - easily arranged.

>If the registry is to be available in printed form, then again the RFC
>numbers should appear at those points, and the full titles, URLs, etc
>should be listed in a References section at the end.

That sounds like a good plan.  Though we do have the issue that the change 
controller is not necessarily the specification document author.

>To take another example. The draft specifies just three protocols to which
>this registry is to apply, mail, news and HTTP. Each header is to have
>one or more of these listed against it.
>
>So the word 'mail' is going to occur in hundreds of places. Fine. But we
>don't want a full visible URL for RFC 2822 at every one of those.

OK, fair suggestion.

#g

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

Date: Wed, 13 Nov 2002 14:23:26 +0000
To: Keith Moore <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP 
Cc: "Charles Lindsey" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 03:09 PM 11/12/02 -0500, Keith Moore wrote:
>actually I'd say that for standards-track documents (for which change
>control rests with IETF) then the "change controller" should be IETF,
>not the author of the latest document that specified that field.

I agree ... that was (at some point) my intent, but I seem to have 
forgotten that bit.

Any suggestions for an email address to use.  (I think I currently use 
[email-masked] in some places.)

#g

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

Date: Wed, 13 Nov 2002 14:21:22 +0000
To: "Charles Lindsey" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Cc: [email-masked]
Sender: [email-masked]

OK, I see your point. (-01 is not really different in this respect.)

I'll look into updating the tools in some way.  I think it calls for 
rethinking the overall form of presentation:  cross-referencing from one 
entry to another is likely to get messy.

I'll note that I don't expect the registration document to be used as a 
common reference, rather that it contains some information that goes into a 
registry.  For an online registry, I think the duplication is not a problem 
(there is a summary table of
header fields, each linked to a registry page).  Though, if it's felt to be 
a significant improvement, I could look into separating the change 
controller information and linking through to it.  (Needless to say, the 
duplication doesn't occur in the original source data!)

As for draft-palme-mailext-headers-08.txt, I've been in touch with 
Jacob.  I just haven't found time to follow through, yet.

#g
--

At 11:45 AM 11/12/02 +0000, Charles Lindsey wrote:

>In <[email-masked]> Graham Klyne 
><[email-masked]> writes:
>
> >I assume you refer to [1] [2].  See also [3] for an example of possible
> >registry data on the Web.
>
>
> >[1] http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-01.txt
> >     (whose content is set to be updated, with input from Jacob Palme)
>
> >[2] http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http-00.txt
>
> >[3]
> >http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanentR 
> egistry.html
> > 
> http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderProvisionalRegistry.html
>
>The last one I saw was draft-klyne-hdrreg-mail-00.txt, so I need to look
>at the others. But here is an example from that document:
>
>2.1.3 Sender: header
>
>    Header name:
>       Sender
>
>    Description:
>       Mailbox of message sender
>
>    Applicable protocol:
>       mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
>
>    Status:
>       standards-track
>
>    Author/change controller:
>       Peter W.  Resnick  (mailto:[email-masked])
>       QUALCOMM Incorporated, 5775 Morehouse Drive,
>       San Diego, CA 92121-1714, USA.
>       Tel: +1 858 651 4478
>       Fax: +1 858 651 1102
>
>    Specification document(s):
>       http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
>
>    Related information:
>       Specifies the mailbox of the agent responsible for the actual
>       transmission of the message.
>
>
>2.1.4 Reply-To: header
>
>    Header name:
>       Reply-To
>
>    Description:
>       Mailbox for replies to message
>
>    Applicable protocol:
>       mail (http://www.rfc-editor.org/rfc/rfc2822.txt)
>
>    Status:
>       standards-track
>
>    Author/change controller:
>       Peter W.  Resnick  (mailto:[email-masked])
>       QUALCOMM Incorporated, 5775 Morehouse Drive,
>       San Diego, CA 92121-1714, USA.
>       Tel: +1 858 651 4478
>       Fax: +1 858 651 1102
>
>    Specification document(s):
>       http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)
>
>    Related information:
>       When the R"eply-To: "field is present, it indicates the
>       mailbox(es) to which the author of the message suggests that
>       replies be sent.
>
>
>All in all, Peter Resnick's full address appears 22 times in that
>document. It shouldn't require any rocket science to include it once, with
>suitable pointers when required. Indeed, when there is an RFC mentioned
>(as there usually is), then it should suffice to assume that the RFC
>author is the responsible controller, except in special cases where he
>isn't.
>
>Again, it should not be necessary to give a full URL for an RFC. They are
>well known documents (and that URL is not the only place from which they
>can be retrieved). It should suffice for a preamble to the Registry to
>explain the notation and how to obtain RFCs. And maybe a separate
>references section containing the usual Bibliographic details for all RFCs
>mentioned in the registry.
>
>But as it stands, there is so much wood that it is difficult to discern
>the trees.
>
>BTW, please note that there is now a new draft of Jacob Palme's list of
>headers as draft-palme-mailext-headers-08.txt.
>
>--
>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

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

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Wed, 13 Nov 2002 15:03:25 -0500
Sender: [email-masked]

> >I don't see how that helps.   you're just going to get irregular line
> >breaks.  and the sending agent isn't really any better at wrapping
> >for presentation than the receiving agent.
> 
> The line breaks would be irregular when viewed as naked undecoded RFC
> 2047. But they would look exactly correct when viewed after decoding,
> which is how they are intended to be viewed.

you can't be sure that all of the encoded-words will be decoded and
presented by the destination.  nor can you be sure about the width of 
the characters if/when they are presented.

Keith

To: [email-masked]
Xref: clerew local.mime:1916
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Date: Wed, 13 Nov 2002 11:14:17 GMT
Lines: 34
Sender: [email-masked]

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

>Charles> Again, it should not be necessary to give a full URL for an RFC.

>including the url makes an online copy of the document quite a bit more convenient.

In the end, it is up to IANA how they format the registry, but we should
be giving them good examples of the kind of thing we would like to see.

If the registry, as maintained by IANA, is in a web format, then quoting
just the RFC numbers visibly, with the URL hidden behind it for clicking
purposes, would be fine. No clutter to confuse the viewer.

If the registry is to be available in printed form, then again the RFC
numbers should appear at those points, and the full titles, URLs, etc
should be listed in a References section at the end.

To take another example. The draft specifies just three protocols to which
this registry is to apply, mail, news and HTTP. Each header is to have
one or more of these listed against it.

So the word 'mail' is going to occur in hundreds of places. Fine. But we
don't want a full visible URL for RFC 2822 at every one of those.

-- 
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:1915
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Date: Wed, 13 Nov 2002 11:06:21 GMT
Lines: 23
Sender: [email-masked]

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

>> It would be even more reasonable for the original composing agent to do
>> line splitting for 78 characters _before_ doing the RFC 2047 encoding

>I don't see how that helps.   you're just going to get irregular line
>breaks.  and the sending agent isn't really any better at wrapping
>for presentation than the receiving agent.

The line breaks would be irregular when viewed as naked undecoded RFC
2047. But they would look exactly correct when viewed after decoding,
which is how they are intended to be viewed.

-- 
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, 13 Nov 2002 08:24:06 -0800 (PST)
From: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers
To: Keith Moore <[email-masked]>
Cc: Charles Lindsey <[email-masked]>, [email-masked]
Sender: [email-masked]

> >  Surely the content of the Subject is up to the author?

> it's a mistake for the author to assume that the Subject field preserves
> line breaks.  this hasn't been a valid assumption in the last ~20 years.

Bingo. Like it or not, this has always been allowed, and it is used to
advantage by numerous implementations.

				Ned

Date: Wed, 13 Nov 2002 15:24:52 +0100
From: Marc Mutz <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Organization: KDE
Sender: [email-masked]

--Boundary-02=_+Cm09OHLjRfVkNv
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Description: signed data
Content-Disposition: inline

On Wednesday 13 November 2002 14:57, Keith Moore wrote:
> > Refolding a field is ok as long as you know the sematics of it. Ie.
> > you can and should refold Subject or Organization header fields,
> > but assume a MUA doesn't know the Content-Features (rfc2912) field.
> > Then it will interpret it as unstructured as it shoud, but it
> > should probably _not_ try to refold.
>
> wouldn't it be safe to fold at white-space anyway?
<snip>

Not if the unknown field is structured and it allows quoted-string 
somewhere. I don't exactly remember the rules for folding in quoted 
strings, but there was a possiblity to express linebreaks with 
quoted-strings - ah, no that was with the \CRLF construct.

So yes, you're right, folding at whitespace should then be save.

Marc

-- 
It's good fortune for the government that the masses don't think.
                                                         -- Adolf Hitler

--Boundary-02=_+Cm09OHLjRfVkNv
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_+Cm09OHLjRfVkNv--

Date: Wed, 13 Nov 2002 09:04:32 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers
Sender: [email-masked]

RFC 2822 Sections 2.2.1 and 2.2.3 clearly say that all unstructure 
headers, including Subject headers, can be folded and unfolded, and how 
to do so.

Following those rules, the subject line shown below can legitimately be 
unfolded to this, and then refolded in another fashion.

Subject: Discussions concerning foo, bar and baz.        Part I. Foo.

That is, a header field that consists of multiple lines is, by 
definition, a folded field. Section 2.2.3 says explicitly:

    Each header field is logically a single line of characters comprising
    the field name, the colon, and the field body.

I don't think it can get clearer than this.

	Tony Hansen
	[email-masked]

Charles Lindsey wrote:

> In  Jacob Palme  writes:
>
>
> >I think it is very reasonable to assume that a Subject cannot
> >contain any line breaks, and thus that any line breaks in
> >Subject are removed, and that there should be not more than
> >a single space where the line break occurred.
>
>
> Why would you assume that? Surely the content of the Subject is up to the
> author?
>
> Subject: Discussions concerning foo, bar and baz.
>          Part I. Foo.
>
> If some "smart" receiving agent reformats that, it might appear as
>
> Subject: Discussions concerning foo, bar and baz. Part
>  I. Foo.
>
> For sure, the transport system should not change any folding. If the
> recipient is foolish enough to buy such an "oversmart" agent, then that is
> his misfortune.
>

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Wed, 13 Nov 2002 08:59:35 -0500
Sender: [email-masked]

>  Surely the content of the Subject is up to the author?

it's a mistake for the author to assume that the Subject field preserves
line breaks.  this hasn't been a valid assumption in the last ~20 years.

Keith

From: Keith Moore <[email-masked]>
To: Marc Mutz <[email-masked]>
cc: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Wed, 13 Nov 2002 08:57:51 -0500
Sender: [email-masked]

> Refolding a field is ok as long as you know the sematics of it. Ie. you
> can and should refold Subject or Organization header fields, but assume
> a MUA doesn't know the Content-Features (rfc2912) field. Then it will
> interpret it as unstructured as it shoud, but it should probably _not_
> try to refold.

wouldn't it be safe to fold at white-space anyway?

Keith

To: [email-masked]
Xref: clerew local.mime:1914
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Date: Wed, 13 Nov 2002 11:04:21 GMT
Lines: 32
Sender: [email-masked]

In <p05100304b9f69017587e@[192.168.100.103]> Jacob Palme <[email-masked]> writes:

>I think it is very reasonable to assume that a Subject cannot
>contain any line breaks, and thus that any line breaks in
>Subject are removed, and that there should be not more than
>a single space where the line break occurred.

Why would you assume that? Surely the content of the Subject is up to the
author?

Subject: Discussions concerning foo, bar and baz.
         Part I. Foo.

If some "smart" receiving agent reformats that, it might appear as

Subject: Discussions concerning foo, bar and baz. Part
 I. Foo.

For sure, the transport system should not change any folding. If the
recipient is foolish enough to buy such an "oversmart" agent, then that is
his misfortune.

-- 
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, 12 Nov 2002 19:31:17 +0100
From: Marc Mutz <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
To: [email-masked]
Organization: KDE
Sender: [email-masked]

--Boundary-02=_3jU09o2fBzHBSDT
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Description: signed data
Content-Disposition: inline

On Tuesday 12 November 2002 16:58, Keith Moore wrote:
<snip>
> But refolding a structured field seems  okay as long as you don't
> fold in the middle of an atom or quoted string, and refolding an
> unstructured field also seems  okay if you only fold at white space.
<snip>

Refolding a field is ok as long as you know the sematics of it. Ie. you 
can and should refold Subject or Organization header fields, but assume 
a MUA doesn't know the Content-Features (rfc2912) field. Then it will 
interpret it as unstructured as it shoud, but it should probably _not_ 
try to refold.

Marc

-- 
Ein Grundrecht auf Sicherheit steht bewusst nicht in der Verfassung.
  -- Sabine Leutheusser-Schnarrenberger (ehem. Bundesjustizministerin)

--Boundary-02=_3jU09o2fBzHBSDT
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_3jU09o2fBzHBSDT--

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP 
Date: Tue, 12 Nov 2002 15:09:02 -0500
Sender: [email-masked]

> All in all, Peter Resnick's full address appears 22 times in that
> document. It shouldn't require any rocket science to include it once, with
> suitable pointers when required. 

actually I'd say that for standards-track documents (for which change
control rests with IETF) then the "change controller" should be IETF,
not the author of the latest document that specified that field.

Keith

Date: Tue, 12 Nov 2002 09:50:32 -0800
From: Dave Crocker <[email-masked]>
Organization: TribalWise
To: "Charles Lindsey" <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Sender: [email-masked]

Charles,

Tuesday, November 12, 2002, 3:45:49 AM, you wrote:

Charles> In <[email-masked]> Graham Klyne <[email-masked]> writes:

Charles> All in all, Peter Resnick's full address appears 22 times in that
Charles> document. It shouldn't require any rocket science to include it once, with
Charles> suitable pointers when required.

good idea.

Charles> Again, it should not be necessary to give a full URL for an RFC.

including the url makes an online copy of the document quite a bit more convenient.

d/
-- 
 Dave Crocker  <mailto:[email-masked]>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850

To: [email-masked]
Xref: clerew local.mime:1908
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Date: Tue, 12 Nov 2002 11:45:49 GMT
Lines: 107
Sender: [email-masked]

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

>I assume you refer to [1] [2].  See also [3] for an example of possible 
>registry data on the Web.

>[1] http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-01.txt
>     (whose content is set to be updated, with input from Jacob Palme)

>[2] http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http-00.txt

>[3] 
>http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanentRegistry.html
>     http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderProvisionalRegistry.html

The last one I saw was draft-klyne-hdrreg-mail-00.txt, so I need to look
at the others. But here is an example from that document:

2.1.3 Sender: header
 
   Header name:
      Sender
 
   Description:
      Mailbox of message sender

   Applicable protocol:
      mail (http://www.rfc-editor.org/rfc/rfc2822.txt)

   Status:
      standards-track

   Author/change controller:
      Peter W.  Resnick  (mailto:[email-masked])
      QUALCOMM Incorporated, 5775 Morehouse Drive,
      San Diego, CA 92121-1714, USA.
      Tel: +1 858 651 4478
      Fax: +1 858 651 1102

   Specification document(s):
      http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)

   Related information:
      Specifies the mailbox of the agent responsible for the actual
      transmission of the message.

2.1.4 Reply-To: header

   Header name:
      Reply-To

   Description:
      Mailbox for replies to message

   Applicable protocol:
      mail (http://www.rfc-editor.org/rfc/rfc2822.txt)

   Status:
      standards-track

   Author/change controller:
      Peter W.  Resnick  (mailto:[email-masked])
      QUALCOMM Incorporated, 5775 Morehouse Drive,
      San Diego, CA 92121-1714, USA.
      Tel: +1 858 651 4478
      Fax: +1 858 651 1102

   Specification document(s):
      http://www.rfc-editor.org/rfc/rfc2822.txt (section 3.6.2)

   Related information:
      When the R"eply-To: "field is present, it indicates the
      mailbox(es) to which the author of the message suggests that
      replies be sent.

All in all, Peter Resnick's full address appears 22 times in that
document. It shouldn't require any rocket science to include it once, with
suitable pointers when required. Indeed, when there is an RFC mentioned
(as there usually is), then it should suffice to assume that the RFC
author is the responsible controller, except in special cases where he
isn't.

Again, it should not be necessary to give a full URL for an RFC. They are
well known documents (and that URL is not the only place from which they
can be retrieved). It should suffice for a preamble to the Registry to
explain the notation and how to obtain RFCs. And maybe a separate
references section containing the usual Bibliographic details for all RFCs
mentioned in the registry.

But as it stands, there is so much wood that it is difficult to discern
the trees.

BTW, please note that there is now a new draft of Jacob Palme's list of
headers as draft-palme-mailext-headers-08.txt.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Tue, 12 Nov 2002 10:58:30 -0500
Sender: [email-masked]

> It would be even more reasonable for the original composing agent to do
> line splitting for 78 characters _before_ doing the RFC 2047 encoding

I don't see how that helps.   you're just going to get irregular line
breaks.  and the sending agent isn't really any better at wrapping
for presentation than the receiving agent.

I've generally found it useful for the receiving MUA to rewrap anyway,
in order to hide the brain damage generated by some mailers.  e.g.

From: "[email-masked]'" <[email-masked]>

my MUA looks at each address in the header, removes the parts that
are redundant, decodes 2047, and rewraps the results to make them
presentable (putting the phrase and the address on the same line)

> OTOH, I dislike displaying agents that tinker with what was received.
> Sometime people have good reasons to use long headers (long URLs for
> example), and it is not up to displaying agents to second guess the user's
> intent.

in general theory I agree, in this specific instance of practice I disagree.
I certainly don't like things that break lines in the middle of URLs.
But refolding a structured field seems  okay as long as you don't
fold in the middle of an atom or quoted string, and refolding an 
unstructured field also seems  okay if you only fold at white space.

people who put unencoded white space inside URLs deserve to lose anyway.

Keith

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], Daniel Pargman <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Tue, 12 Nov 2002 09:08:10 -0500
Sender: [email-masked]

> I think it is very reasonable to assume that a Subject cannot
> contain any line breaks, and thus that any line breaks in
> Subject are removed, and that there should be not more than
> a single space where the line break occurred.

personally I've always assumed that any header field could be
re-wrapped, and that line breaks in header fields were not
significant for display.

To: [email-masked]
Xref: clerew local.mime:1907
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Date: Tue, 12 Nov 2002 11:25:15 GMT
Lines: 30
Sender: [email-masked]

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

>I think it would be reasonable for a displaying user agent to
>re-wrap any continued header field that contained encoded-words.

It would be even more reasonable for the original composing agent to do
line splitting for 78 characters _before_ doing the RFC 2047 encoding
(however, it has to watch the 75 limit in RFC 2047). Thar might appear to
break the "SHOULD be less than 78" limit in RFC 2047, but that limit was
provided for the benefit of humans. The hard limit is 998 characters, and
the examples are well inside that.

OTOH, I dislike displaying agents that tinker with what was received.
Sometime people have good reasons to use long headers (long URLs for
example), and it is not up to displaying agents to second guess the user's
intent.

So although Jacob's original example did not breach RFC 2822 in the
letter, it did breach it in the spirit.

-- 
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, 12 Nov 2002 12:04:56 +0100
To: Keith Moore <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Cc: [email-masked], Daniel Pargman <[email-masked]>
Sender: [email-masked]

At 17:34 -0500 02-11-11, Keith Moore wrote:
>I think it would be reasonable for a displaying user agent to
>re-wrap any continued header field that contained encoded-words.

Should this be added, in future versions of either RFC 2048 or
RFC 2822, if they ever get revised? Since obviously there are
existing mailers which do not do this.

I think it is very reasonable to assume that a Subject cannot
contain any line breaks, and thus that any line breaks in
Subject are removed, and that there should be not more than
a single space where the line break occurred.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked], Daniel Pargman <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers 
Date: Mon, 11 Nov 2002 17:34:14 -0500
Sender: [email-masked]

I think it would be reasonable for a displaying user agent to
re-wrap any continued header field that contained encoded-words.

Date: Mon, 11 Nov 2002 19:58:03 +0000
To: "Charles Lindsey" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Cc: [email-masked]
Sender: [email-masked]

I assume you refer to [1] [2].  See also [3] for an example of possible 
registry data on the Web.

Some of the verbosity is in response to comments on the registry proposal 
draft.

Based on the data we have assembled, the registration data is quite easily 
presented in different forms.  Do you have any specific suggestions?

#g
--

[1] http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-01.txt
     (whose content is set to be updated, with input from Jacob Palme)

[2] http://www.ietf.org/internet-drafts/draft-nottingham-hdrreg-http-00.txt

[3] 
http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderPermanentRegistry.html
     http://www.ninebynine.org/IETF/Messaging/HdrRegistry/MailHeaderProvisionalRegistry.html

At 10:18 AM 11/5/02 +0000, Charles Lindsey wrote:

>In <p05200e26b9ecc4e303e9@[165.227.249.18]> Paul Hoffman / IMC 
><[email-masked]> writes:
>
> >>The IESG has received a request to consider Registration procedures for
> >>message header fields <draft-klyne-msghdr-registry-05.txt> as a BCP.
> >>This has been reviewed in the IETF but is not the product of an IETF
> >>Working Group.
>
>I think we were all happy with the final draft, but there is still the
>question of the initial registry. Yes, there was a draft published, and I
>ought to have commented earlier. My only problem with it was that the
>format was too verbose and repetitive (the same URL appearing many times,
>once for each header introduced by a particular RFC).
>
>--
>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

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

Date: Mon, 11 Nov 2002 10:43:10 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Problem with MIME and line length in Subject headers
Sender: [email-masked]

inline

Jacob Palme wrote:

> When I send a message via e-mail with the following subject:
> Subject: "Der Führer" was originally the German word for "The leader"
>
> It gets by my mail program converted to:
>
> Subject: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally the German 
> word for "The leader"
>
> My mail program then notes that this line is longer than 60
> characters and splits it as follows:
> Subject: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally the
>  German word for "The leader"

Your mail program erroneously inserted an additional space when it 
folded the line. See 2822 section 2.2.3, on folding and unfolding header 
fields.

> The recipient of my e-mail then gets the following subject:
>
> Subject: "Der Führer" was originally the
>  German word for "The leader"
>
> When someone using the same mail program writes a reply to
> this message, the mailer will first convert the Subject to
>
> Subject: Re: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally the
> German word for "The leader"

Your mail program again erroneously inserted extra blanks between "the" 
and "German" that should not be there, if the rules for unfolding were 
to be followed properly. See 2822 section 2.2.3.

> Then the mailer finds that the first line again is longer
> than 60 characters, and splits the Subject to be sent as
> follows
>
> Subject: Re: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally
>  the   German word for "The leader"

Again, your program erroneously inserted another extra blank that 
shouldn't be there.

> This means that the final recipient will receive reply
> looking as follows:
>
> Subject: Re: "Der Führer" was originally
>  the   German word for "The leader"
>
> Not very nice! Note that increasing the limit from 60 to 78
> characters will not solve the problem, just reduce how often
> it occurs a little.
>
> An even worse case occurs for a message with the following Subject:
>
> Subject: My attempt at German: Öffentlig ist über und Non-Öffentlig is 
> unter
>
> Will in a reply be shown to the human recipient as
> Subject: Re: My attempt at German: Öffentlig ist
>     über und
>  Non-Öffentlig is unter
>
> The encoded format of the above is:
> Subject: Re: My attempt at German: =?iso-8859-1?Q?=D6ffentlig?= is
>     =?iso-8859-1?Q?=FCber?= und
>  =?iso-8859-1?Q?Non=2D=D6ffentlig?= is unter
>
> Question 1: Is this correct behaviour of a standards-compliant
> mailer?

no, it doesn't follow 2822 section 2.2.3 properly.

	Tony Hansen
	[email-masked]

> Question 2: If the answer to question 1 is "yes", then is there
> something wrong with the standards? Should the next edition
> of MIME include something for headers similar to "=" at the
> end of the line in Quoted-Printable lines to indicate soft
> linebreaks?
>
> A detail: Note that my mailer converts the doubleblip character
> to =22 in a word containing a non-ascii character, but not in
> a word not containing a non-ascii character. This is a detail
> and not related to the main problem. And note that the problem
> gets worsended because every word with non-ascii characters
> will get its own =?iso-8859-1?Q?, is this needed, would it
> not be enough to just have one =?iso-8859-1?Q? at the beginning
> of the subject and one ?= at the end? Not that this would
> solve the main problem presented by this e-mail, just a note.

From: Arnt Gulbrandsen <[email-masked]>
To: Jacob Palme <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Cc: [email-masked], Daniel Pargman <[email-masked]>
Date: Mon, 11 Nov 2002 16:09:28 +0100
Sender: [email-masked]

> At 13:52 +0100 02-11-11, Arnt Gulbrandsen wrote:
>> A standard that is widely either misunderstood or incorrectly 
>> implemented certainly has a problem. IMHO, in this case a textual 
>> clarification is the best way to deal with it.
>
> RFC 2822 says:
>
>    There are two limits that this standard places on the number of 
>    characters in a line. Each line of characters MUST be no more than 
>    998 characters, and SHOULD be no more than 78 characters, 
>    excluding the CRLF.
>
> With 78 characters, and MIME encoding, this means that the actual 
> allowable length of a subject line using non-ASCII characters is 
> smaller at least 16, maybe more than 16 less than 78. Many people 
> will then get their subjects broken.

Agreed. (For the last thousand messages in my inbox, I see that almost 
10% of the subject fields are wrapped into multiple 
seventysome-character lines.)

> By adding that an "=" sign at the end of a subject indicates a soft 
> line break, in the same way as in Quoted-Printable, this can be 
> solved. But this requires a change in the MIME standard for encoding 
> of unstructured text in headers.

It also creates a large compatibility break, since there's software that 
treats _today's_ line breaks as soft, and even more than displays all 
nonwhitespace.

It sounds easier to get more people to implement today's soft line 
breaks (FWS) correctly than to invent a new soft line break and then 
get everyone to implement that.

--Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: Jacob Palme <[email-masked]>
Subject: Re: Problem with MIME and line length in Subject headers
Cc: [email-masked], Daniel Pargman <[email-masked]>
Date: Mon, 11 Nov 2002 13:52:56 +0100
Sender: [email-masked]

...
> It gets by my mail program converted to:
> ...

That's German ;)

> Question 1: Is this correct behaviour of a standards-compliant mailer?

The subject field is unstructured, which means that it contains 
nonwhitespace and folding whitespace. By my reading of 2822, a MUA 
should therefore treat all sequences of white space as equivalent to a 
single ASCII 32.

> Question 2: If the answer to question 1 is "yes", then is there 
> something wrong with the standards? Should the next edition of MIME 
> include something for headers similar to "=" at the end of the line 
> in Quoted-Printable lines to indicate soft linebreaks?

A standard that is widely either misunderstood or incorrectly 
implemented certainly has a problem. IMHO, in this case a textual 
clarification is the best way to deal with it.

--Arnt

Date: Mon, 11 Nov 2002 11:17:47 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Problem with MIME and line length in Subject headers
Cc: Daniel Pargman <[email-masked]>
Sender: [email-masked]

When I send a message via e-mail with the following subject:
Subject: "Der Führer" was originally the German word for "The leader"

It gets by my mail program converted to:

Subject: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally the German word for "The leader"

My mail program then notes that this line is longer than 60 
characters and splits it as follows:
Subject: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally the 
 German word for "The leader"

The recipient of my e-mail then gets the following subject:

Subject: "Der Führer" was originally the 
 German word for "The leader"

When someone using the same mail program writes a reply to 
this message, the mailer will first convert the Subject to

Subject: Re: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally the   
German word for "The leader"

Then the mailer finds that the first line again is longer 
than 60 characters, and splits the Subject to be sent as 
follows

Subject: Re: =?iso-8859-1?Q?=22Der_F=FChrer=22?= was originally 
 the   German word for "The leader"

This means that the final recipient will receive reply
looking as follows:

Subject: Re: "Der Führer" was originally 
 the   German word for "The leader"

Not very nice! Note that increasing the limit from 60 to 78
characters will not solve the problem, just reduce how often
it occurs a little.

An even worse case occurs for a message with the following Subject:

Subject: My attempt at German: Öffentlig ist über und Non-Öffentlig is unter

Will in a reply be shown to the human recipient as
Subject: Re: My attempt at German: Öffentlig ist
    über und   
 Non-Öffentlig is unter

The encoded format of the above is:
Subject: Re: My attempt at German: =?iso-8859-1?Q?=D6ffentlig?= is
    =?iso-8859-1?Q?=FCber?= und   
 =?iso-8859-1?Q?Non=2D=D6ffentlig?= is unter

Question 1: Is this correct behaviour of a standards-compliant
mailer?

Question 2: If the answer to question 1 is "yes", then is there
something wrong with the standards? Should the next edition
of MIME include something for headers similar to "=" at the
end of the line in Quoted-Printable lines to indicate soft
linebreaks?

A detail: Note that my mailer converts the doubleblip character
to =22 in a word containing a non-ascii character, but not in
a word not containing a non-ascii character. This is a detail
and not related to the main problem. And note that the problem
gets worsended because every word with non-ascii characters
will get its own =?iso-8859-1?Q?, is this needed, would it
not be enough to just have one =?iso-8859-1?Q? at the beginning
of the subject and one ?= at the end? Not that this would
solve the main problem presented by this e-mail, just a note.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Tue, 5 Nov 2002 14:49:31 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re:
Cc: [email-masked]
Sender: [email-masked]

At 15:58 +0100 02-10-10, Charles Lindsey wrote:
>2. If someone is writing a standards-track document (whether for news or
>email) and wishes to introduce some new header-fields that can make use
>of RFC 2047, what does he have to say?

Note that the MHTML standard, RFC 2557, says that RFC2047
should be used for encoding of URIs in Content-Location
headers.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Xref: clerew local.mime:1900
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: Last Call: Registration procedures for message header fields to BCP
Date: Tue, 5 Nov 2002 10:18:21 GMT
Lines: 23
Sender: [email-masked]

In <p05200e26b9ecc4e303e9@[165.227.249.18]> Paul Hoffman / IMC <[email-masked]> writes:

>>The IESG has received a request to consider Registration procedures for
>>message header fields <draft-klyne-msghdr-registry-05.txt> as a BCP. 
>>This has been reviewed in the IETF but is not the product of an IETF
>>Working Group.

I think we were all happy with the final draft, but there is still the
question of the initial registry. Yes, there was a draft published, and I
ought to have commented earlier. My only problem with it was that the
format was too verbose and repetitive (the same URL appearing many times,
once for each header introduced by a particular RFC).

-- 
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 Nov 2002 16:44:28 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: Last Call: Registration procedures for message header fields to  	   BCP
Sender: [email-masked]

>To: IETF-Announce: ;
>From: The IESG <[email-masked]>
>SUBJECT: Last Call: Registration procedures for message header fields to
>	   BCP
>Reply-to: [email-masked]
>Date: Mon, 04 Nov 2002 12:39:55 -0500
>Sender: [email-masked]
>
>
>The IESG has received a request to consider Registration procedures for
>message header fields <draft-klyne-msghdr-registry-05.txt> as a BCP. 
>This has been reviewed in the IETF but is not the product of an IETF
>Working Group.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2002-12-4.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-05.txt