Subject: Re: User-Agent

From: Gunnar Ritter <[email-masked]>
Date: Sun, 06 Feb 2005 17:19:23 +0100

Bruce Lilly <[email-masked]> wrote (on July 6, 2004):

> There are some issues with User-Agent: [...]
> 2. the syntax doesn't seem to be well-received by implementors:
>
> > Date: Sun, 02 May 2004 18:56:38 +0200
> > Sender: [email-masked]
> > From: Gunnar Ritter <[email-masked]>
> > Organization: Privat.
> > To: [email-masked]
> > Subject: Re: Nail and User-Agent
> > Message-ID: <[email-masked]>
> > References: <[email-masked]>
> > In-Reply-To: <[email-masked]>
> > User-Agent: nail 10.8pre 4/14/04
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> > X-Junkmail-Status: score=0/65, host=mr12.mrf.mail.rcn.net
> > 
> > Bruce Lilly <[email-masked]> wrote:
> > 
> >> Nail appears to insert header fields such as
> >>   User-Agent: nail 10.5 4/27/03
> >>
> >> The only specification for a User-Agent field that I am aware
> >> of is in draft-ietf-usefor-article-12.txt, section 6.18: [...]
> >>
> >> Note that the use of multiple '/' characters in the content
> >> generated by nail conflicts with the specified syntax.
> > 
> > Maybe, but other MUAs do the same (look at the header of your
> > own email) so it can be called current practice. And well,
> > nobody really cares about the UseFor group anyway.
> > 
> > 	Gunnar
> > 
> > -- 
> > http://omnibus.ruf.uni-freiburg.de/~gritter

It has recently come to my attention that Mr. Lilly has published
that piece of our private communication, so although it is a bit
late now, it may be useful to give some clarification here.

First, the way how Mr. Lilly is interpreting the relation of the
various standards and drafts just because they contain the string
"User-Agent" is weird. RFC 2822 allows to insert just about any
implementor-defined field name in 3.6.8 "Optional fields". Other
documents do just not apply to mail. So since there is no
"User-Agent" field defined in RFC 2822 or any normative supplement
to it, mail implementors are free to insert one in (nearly) any
form they like.

Second, his statement "the syntax doesn't seem to be well-received
by implementors" does not apply to my case. I did not receive the
syntax definition in the respective usefor draft at all until Mr.
Lilly forwarded it to me, and I did not bother to read it thoroughly
even then. This is just because I will not waste my time by running
after the current state of various changing drafts that do not have
any normative significance for mail. Should a new Usenet news RFC
ever be published, I will certainly have a closer look at it since
I do care about practical interoperability between mail and news,
though. (That is, unless the Usenet has already sunken into oblivion
at that time.) These remarks should also suffice to clarify the
intention behind the last sentence of my message to Mr. Lilly above.

Third, I do not care much about the actual syntax. The string in the
User-Agent field produced by my implementation just comes from the
version control system. I will not alter that mechanism for now since
it is convenient for me as is, but I will do it once it is demanded by
some standard or quasi-standard that is applicable to mail or that at
least has some close relationship to it.

So in short, as far as I am concerned, define whatever you like here,
but do not expect me to care about it until it appears in a future
news RFC.

	Gunnar

(As it should be clear from the above, I am not normally on the list
so cc me in case you want me to read your answer.)

---

From: Charles Lindsey <[email-masked]>
Date: Mon, 14 Feb 2005 15:34:28 GMT

>> >> of is in draft-ietf-usefor-article-12.txt, section 6.18: [...]

The specification of User-Agent in the various Usefor drafts is taken from
the definition in RFC 2616 (since we saw no reason to invent anything
different). There is a slight difference in that <token> is defined
slightly differently in HTTP than in Mail.

>to it, mail implementors are free to insert one in (nearly) any

I believe the "Optional fields" were defined into RFC 2822 in order to
allow for other fields to be defined as extensions in other standards, and
not with the intent of allowing them to be used freely by implementors who
thought they looked good. There was also an intention, I believe, for
headers beginning with "X-" to be legitimized as "optional fields", but
this was not stated explicitly in RFC 2822, which I think is a pity, but
there it is.

But since then we now have RFC 3864 for registering new fields, and
hopefully this will introduce some order into the process of inventing new
headers.

>least has some close relationship to it.

That seems OK to me.

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

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 23 Feb 2005 13:52:02 -0500

> slightly differently in HTTP than in Mail.

HTTP is unrelated to the Internet Message Format as used by
our work.  There are indeed differences between HTTP and the
MIME (RFC 2045) definitions of "token"; the RFC 2045
definition contains an error, which I have brought to the
attention of its authors (ca. May 2004).  As of today, there
is still no erratum published (the RFC Editor's errata page
having last been updated 2004-10-28, so it says).

So this is still an outstanding issue, but one that is
contingent upon an erratum for RFC 2045 before we can look
in detail at the syntax differences/issues.

---

From: Henry Spencer <[email-masked]>
Date: Wed, 23 Feb 2005 14:03:12 -0500 (EST)

On Wed, 23 Feb 2005, Bruce Lilly wrote:
> our work.

"Messages are passed in a format similar to that used by Internet mail [9]
as defined by the Multipurpose Internet Mail Extensions (MIME) [7]." 
(Reference 9 is RFC 822, 7 is RFC 2045.)
					-- RFC 2616, section 1.1

Hardly "unrelated".  Different, perhaps, yes, but still potentially
a useful source for existing definitions.

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 24 Feb 2005 15:35:22 GMT

>HTTP is unrelated to the Internet Message Format as used by

HTTP has explicitly and deliberately adopted many of the features of mail
headers for use in its own headers. It even uses some of the MIME headers
without change. The similarities are such that the recent RFC 3864 chose
to cover headers for all of Email, Netnews and HTTP under the same
scheme.

It is therefore perfectly sensible (though not obligatory) to follow the
lead of HTTP when defining a header with the same name and purpose as the
existing HTTP header. This group took the decision to do so many years
back.

>  There are indeed differences between HTTP and the

Could you please be more explicit about your "error". The syntax of
tokens, and more particularly that of <tspecial>s has been in RFC 2045 for
a long time, and appears in many other standards with exactly the same
syntax.

Until such time as I see a published errata, I shall presume that RFC 2045
means exactly what it says. Is it not possible that the lack of a
published erratum indicates that the authors of RFC 2045 do not believe
there is any error?

---

From: [email-masked]
Date: Thu, 24 Feb 2005 11:23:07 -0800 (PST)

> published erratum indicates that the authors of RFC 2045 do not believe

AFAIK the only error in RFC 2045 in this general area, which Bruce
pointed out back in July 2004, is that there's a missing slash in the
ABNF for tspecials:

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="

should be:

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <"> /
                   "/" / "[" / "]" / "?" / "="

In other words, it's a simple typo. I thought I forward it to the RFC Editor
at the time but I guess I didn't. I have done so now.

				Ned

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 24 Feb 2005 20:19:46 -0500

> a long time, and appears in many other standards with exactly the same

The specification of tspecial ABNF has an error; there is a
possibility that one or more characters are missing from the
list of tspecials.

> published erratum indicates that the authors of RFC 2045 do not believe

No.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 25 Feb 2005 17:45:46 GMT

>at the time but I guess I didn't. I have done so now.

Yes, that looks pretty harmless, and I doubt any implementor has been misled.

But the syntax of tspecials in RFC 2616 defines s different list:

       token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

the essential difference being that "{" and "}" are not permitted in HTTP
tokens. The syntax we have proposed for the User-Agent header follows the
tokens as defined in RFC 2045 (modulo the typo), and therefore it differs
marginally from the User-Agent header in HTTP (and there is a comment in
the Usefor draft mentioning that). I doubt if it will ever turn out to be
an issue in the Real World.

To: [email-masked]
Xref: clerew local.usefor:20627
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: User-Agent = an outstanding issue
Date: Fri, 25 Feb 2005 17:45:46 GMT
Lines: 62
Sender: [email-masked]

>at the time but I guess I didn't. I have done so now.

Yes, that looks pretty harmless, and I doubt any implementor has been misled.

But the syntax of tspecials in RFC 2616 defines s different list:

       token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

the essential difference being that "{" and "}" are not permitted in HTTP
tokens. The syntax we have proposed for the User-Agent header follows the
tokens as defined in RFC 2045 (modulo the typo), and therefore it differs
marginally from the User-Agent header in HTTP (and there is a comment in
the Usefor draft mentioning that). I doubt if it will ever turn out to be
an issue in the Real World.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: mdomain vs. id-right again
Date: Fri, 25 Feb 2005 09:41:32 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Charles Lindsey wrote:

> Anyay, you have asked the Chair. I suggest we halt discussion
> of this issue until he has responded.

LOL, I hope that Alexey can handle our slightly different forms
of humour.  We should certainly halt the discussion until a new
draft is published, there are only so many ways to repeat the
same arguments again and again.

But I forgot one important argument so far:  "My" vanity host
is also a catch-all mailbox.  I'm used to get spam to very old
Message-IDs like <[email-masked]>, but I won't
tolerate it if anybody else publishs other @xyzzy.claranet.de
Message-IDs where stupid address harvesters could find them.
My RHS is my RHS even in a Message-ID.

                           Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: "Charles Lindsey" <[email-masked]>
Subject: Re: User-Agent = an outstanding issue
Date: Thu, 24 Feb 2005 20:19:46 -0500
Cc: [email-masked]
Sender: [email-masked]

No. 

Cc: [email-masked]
Date: Thu, 24 Feb 2005 11:23:07 -0800 (PST)
From: [email-masked]
Subject: Re: User-Agent = an outstanding issue
To: Charles Lindsey <[email-masked]>
Sender: [email-masked]

should be:

				Ned

To: [email-masked]
Xref: clerew local.usefor:20623
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: User-Agent = an outstanding issue
Date: Thu, 24 Feb 2005 15:35:22 GMT
Lines: 50
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:20622
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: mdomain vs. id-right again
Date: Thu, 24 Feb 2005 15:23:33 GMT
Lines: 43
Sender: [email-masked]

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

>> The present instructions from our Chair are that Usefor is to
>> be written by taking everything in RFC 2822 that is relevant,
>> and only mentioning the things that have changed.

>I call bullshit.  Alexey didn't say that you must take the "["
>and the "FWS]" out of a 2822 "[CFWS]" if you really mean *WSP.

>And the "msg-domain" syntax is different from "id-right", like
>"msg-local" is different from "id-left".  It's a proper subset
>with completely new rules to catch the must-quote cases, to get
>rid of NO-WS-CTL, and with a total length limit not found in
>RfC 2822.  This is a new "msg-id" justifying new names for its
>LHS and RHS.  OTOH it's still the same <msg-local@msg-domain>
>concept as it always was, before and after RfC 2822.

>> If you don't like it, complain to the Chair, not to me.

>"Hi Alexey, the UsePro editor wants me to complain about some
> bad names for syntax rules in a future UseFor draft I haven't
> seen written by an unknown stranger claiming that this is all
> your fault."

Well, actually the "bad names" that you do not like are already in the
present Usefor draft, so there is no need to wait for a future Usefor
draft.

Anyay, you have asked the Chair. I suggest we halt discussion of this
issue until he has responded.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: mdomain vs. id-right again
Date: Wed, 23 Feb 2005 23:58:05 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 144
Sender: [email-masked]

Charles Lindsey wrote:

>> you MUST NOT use @xyzzy.claranet.de in your message IDs
>> without the permission of claranet,de

> There is no such MUST NOT in RFC 2822, nor in Usefor, nor is
> there any proposal to make it so.

It's unnecessary in all cases where it's clear that the RHS of
an address or Message-ID is a "domain" as specified in the
_relevant_ texts incl. domain literals and other creatures like
the SHOULD NOT hostname.uucp in 1036bis.

I would propose to add an explicit MUST NOT to anything which
isn't obviously a kind of "domain" as in the _relevant_ texts,
i.e. in STD 11, RfC 1036, and 1036bis.

> I agree is is bad practice, and maybe even a SHOULD NOT.

It's not only "bad practice", it's several pages of "security
considerations" if you keep the misleading name "id-right".
With all the fun-stuff like hip-crime and preemptive cancels.

> We are not using "domain" for the same reason that RFC 2822
> did not use "domain".

2822 split the old "domain" of STD 11 into a new "domain" for
the RHS of addresses, and a more restricted variant "id-right"
for Message-IDs.  The authors of 1036 and s-o-1036 had no time
machine allowing them to foresee this confusion, they simply
said "full_domain_name" and "domain" resp.

We don't need a time machine to see why "id-right" was a poor
choice, we have several dozens of messages here.  You have a
correct syntax for this beast, it's different from 2822, you
know the intended semantics, it's the same as in the _relevant_
texts, all you need is a good name to reflect this situation.

<id-left@id-right> is not good enough to reflect the complete
intended semantics, the _relevant_ texts did a better job.

> We are perfectly entitled to say that, for the purpose of
> Usefor, we define "id-right" to be different, so that the
> difference automatically applies to all places in RFC 2822
> where "id-right" was used.

You're planning to use that trick for the complete msg-id, you
don't need it again and again for all details.  RfC 2822 uses
the word "id-right" exactly twice:  In its definition, and for
"msg-id".  Same picture for the word "id-left".  Looking for
strings instead of words I get three additional 2822 lines incl.

| obs-id-left     =       local-part
| obs-id-right    =       domain

"id-left" and "id-right" were just poor choices, and there's no
reason to keep them in the new "real" msg-id defined by UseFor.
Just pick one:
  msg-id = "<" id-local "@" id-domain ">"
  msg-id = "<" msg-local "@" msg-domain ">"
  msg-id = "<" unique "@" mdomain ">"

The msg-* stuff is somehow in the spirit of similar names in
the UseFor drafts and 2822.

> RFC 2822 did not exist at the time that charter was written,
> or at the time that RfC 1036 and s-o-1036 were written

Then please stop to abuse it as an excuse for vague syntax like
[FWS] instead of *WSP, or for unclear semantics like "id-right"
instead of "msg-domain".

> The present instructions from our Chair are that Usefor is to
> be written by taking everything in RFC 2822 that is relevant,
> and only mentioning the things that have changed.

I call bullshit.  Alexey didn't say that you must take the "["
and the "FWS]" out of a 2822 "[CFWS]" if you really mean *WSP.

And the "msg-domain" syntax is different from "id-right", like
"msg-local" is different from "id-left".  It's a proper subset
with completely new rules to catch the must-quote cases, to get
rid of NO-WS-CTL, and with a total length limit not found in
RfC 2822.  This is a new "msg-id" justifying new names for its
LHS and RHS.  OTOH it's still the same <msg-local@msg-domain>
concept as it always was, before and after RfC 2822.

> If you don't like it, complain to the Chair, not to me.

"Hi Alexey, the UsePro editor wants me to complain about some
 bad names for syntax rules in a future UseFor draft I haven't
 seen written by an unknown stranger claiming that this is all
 your fault."

Is that a play by Kafka, and if yes, why does nobody pay us ?

>> Protocols, where articles with <[email-masked]>
>> are not propagated, because somebody else abused it before
>> me.

> That does not apply if the person who misuses your domain
> takes care to use a different <unique> from what you use, or
> are likely to use.

Unless s/h/it's clairvoyant s/h/it cannot judge this.  What I
"likely" use or don't use is strictly my business.  Some days
ago I used <421788F9.66E8?isindex=[email-masked]> -
see also <URL:http://article.gmane.org/gmane.test:2092:raw> or
<news://news.gmane.org/[email-masked]>

It was a test for your news-URI draft.  I only discuss it with
you and interested parties, but not with clairvoyant strangers.

Maybe I change my UA, I have slrn and Netscape 4.61 on my box.
Maybe I hack an article with telnet -p 119.  Nobody else has my
permission to create any @xyzzy.claranet.de Message-ID.

> He would indeed be in breach of Usefor/RFC2822 if he did not.
> But even such a misuse does not amount to a protocol which
> involves extracting a domain out of a message-id and looking
> it up in the DNS, which is what you postulated

I postulated that you can contact the owner of a domain found
in the RHS of addresses or Message-IDs, if different entities
disagree who is entitled to use this domain.  You might need a
nslookup -q=ns xyzzy.claranet.de to get rid of the vanity host,
or a nslookup -q=mx claranet.de, or something similar.  And if
you're feeling lucky ask [email-masked] who has the
right to use @xyzzy.claranet.de, maybe I'll answer it.

Same idea as for a forged From: address in a cancel message,
the owner of this address is defined to be the person who gets
any questions sent to this address.

> normal practice amongst the 'professional' spam cancellers
> is for the Message-ID of the cancel message to be
> <cancel-unique@domain>
..........^^^^^^.^^^^^^ See ?

Yes, he followed all cancel conventions, it only was no spam.
The Skirvin-FAQ says that you have ONE chance to get it right.

                          Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Wed, 23 Feb 2005 20:54:05 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 54
Sender: [email-masked]

Charles Lindsey wrote:

 [FWS] %d112.111.115.116.101.114 [FWS]
> It is no more erroneous for "poster" than it is for the many
> other places where CFWS of FWS occurs in at the beginning,
> middle or end of some rule.

I didn't know that there are different degrees of erroneousness
in RfCs.  Apparently "poster" would be too erroneous, and that
forces you to say %d112.111.115.116.101.114 in the ABNF.

OTOH [FWS] belongs to the "less erroneous" class, and it's even
"better" than a correct *WSP, where the definition of "better"
is apparently unrelated to "complete number of ABNF characters".

> specifying the same think normatively more than once is
> generally considered bad practice, since it may lead to
> unintended and unexpected consequences

If RfC 2234 somewhere says that the "best common practice" are
vague ABNF syntax rules for all details specified elsewhere,
then I didn't know this.  Maybe you should delete...

| Although the keyword "poster" is case-sensitive, followup
| agents MAY choose to recognize case-insensitive forms such
| as "Poster".

...to avoid any "unintended and unexpected consequences" of
this over-specification.  Or say "poster" and add an explicit
"SHOULD be lower case" in the text.  It's a real challenge if
you insist on an ABNF which does not exactly reflect the text.

>> JFTR, where and when did Alexey say that an erroneous syntax
>> in the "style" of RfC 2822 is better than the correct syntax ?

> There is nothng "erroneous" about the way RFC 2822 handles
> this matter

I'm not talking about RfC 2822 and how they solved their [CFWS]
problem with a MUST NOT.  It's different from the [FWS] problem
in the Usefor text, where clear, correct, simple, and obvious
solutions exist.  I'm a KISS extremist, and I hate vague ABNF
syntax allowing trivially invalid cases.  If Bruce did not see
it immediately we have a huge chance that many implementors and
many gateways get it wrong.

> I hear nothing like a consensus, nor even a majority, for
> changing it.

The consensus is that all odd numbers are prime, because that's
the way to avoid MicroSoft's new "nine IsNot prime" pat. pend.
<http://tinyurl.com/6d4wf>
                             Bye. Frank

Date: Wed, 23 Feb 2005 14:03:12 -0500 (EST)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: User-Agent = an outstanding issue
Sender: [email-masked]

                                                          Henry Spencer
                                                       [email-masked]

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
Subject: User-Agent = an outstanding issue
Date: Wed, 23 Feb 2005 13:52:02 -0500
Cc: [email-masked]
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:20616
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Wed, 23 Feb 2005 13:58:01 GMT
Lines: 59
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> Whether it is [CFWS] or [FWS] at the beginning of some rule
>> makes not a blind bit of difference to that problem.

>Whether it is [CFWS] or *WSP at the beginning of some rule
>makes a difference to that problem.  The latter is correct,
>and RfC 2822 has neither [FWS] nor *WSP in that place.

>You also won't say "poster" because it includes the correct
>poster-text, you say [FWS] %d112.111.115.116.101.114 [FWS].

>This excludes some incorrect forms like "PoStEr", but still
>allows an incorrect CRLF WSP "poster" CRLF WSP.  To get this
>always right you need *WSP %d112.111.115.116.101.114 *WSP

>Anything else is an erroneous syntax for poster-text.

It is no more erroneous for "poster" than it is for the many other places
where CFWS of FWS occurs in at the beginning, middle or end of some rule.
All such cases are already covered (and forbidden) by the special wording
provided for the purpose, both in RFC 2822 and in USEFOR. Since it is
already forbidden, nothing is gained by forbidding it again. Indeed,
specifying the same think normatively more than once is generally
considered bad practice, since it may lead to unintended and unexpected
consequences.

>> What you do do is to tempt the reader to thoink that there
>> is some extra magic going on

>> I am just following the directions I have been given from the
>> Chair to follow RFC 2822, both in content and style, unless
>> there is a technical reason not to do so.

>JFTR, where and when did Alexey say that an erroneous syntax
>in the "style" of RfC 2822 is better than the correct syntax ?

There is nothng "erroneous" about the way RFC 2822 handles this matter (or
its slightly different version of this matter). Therefore there is
nothing "erroneous" for us to handle it in the same way.

>IIRC he had "FWS" as one of the issues outstanding.  Bye, Frank

He agreed that it could be discussed. We are discussing it. I hear nothing
like a consensus, nor even a majority, for changing it.

To: [email-masked]
Xref: clerew local.usefor:20615
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: mdomain vs. id-right again
Date: Wed, 23 Feb 2005 13:45:39 GMT
Lines: 94
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> It is not absolutely forbidden to put other unique texts in
>> there, but you better have a good reason.

>The essential point is that you MUST NOT use @xyzzy.claranet.de
>in your message IDs without the permission of claranet,de

There is no such MUST NOT in RFC 2822, nor in Usefor, nor is there any
proposal to make it so. I agree is is bad practice, and maybe even a
SHOULD NOT.

>If you use a domain literal, some AlterNIC domain, a s-o-1036
>.uucp or .bitnet "domain", then that's your problem, but it's
>still meant to be a "domain" in some way.

"Meant" is not a term with any well defined meaning. "RECOMMENDED", which
is the actual term used in RFC 2822, is defined in RFC 2119.

>Exactly.  Even RfC 2822 explains that the RHS of a Message-ID
>is essentially the same as the RHS of an address, a "domain"
>minus CFWS and other syntax oddities allowed in addresses.

>> but it chose different names for the syntax items. We are
>> supposed to be following RFC 2822.

>We're not supposed to use the same name "id-right" where the
>syntax is different, and the semantics is "domain".  There's
>not one string "2822" on the Web page with the UseFor charter.

We are not using "domain" for the same reason that RFC 2822 did not use
"domain". We are perfectly entitled to say that, for the purpose of
Usefor, we define "id-right" to be different, so that the difference
automatically applies to all places in RFC 2822 where "id-right" was used.
Exactly the same as we did for "unstructured".

>The UseFor charter mentions RfC 822, RfC 1036, and s-o-1036.
>These texts all manage to say "domain" if they mean "domain".

RFC 2822 did not exist at the time that charter was written, or at the
time that RfC 1036 and s-o-1036 were written (otherwise those documents
would certainly have been written differently). The present instructions
from our Chair are that Usefor is to be written by taking everything in
RFC 2822 that is relevant, and only mentioning the things that have
changed. You or I may not like that, but that is the contraint under which
we are working. If you don't like it, complain to the Chair, not to me.

>> What protocol instructs you to take a domain out of a
>> message-id

>Protocols, where articles with <[email-masked]> are
>not propagated, because somebody else abused it before me.

That does not apply if the person who misuses your domain takes care to
use a different <unique> from what you use, or are likely to use. He would
indeed be in breach of Usefor/RFC2822 if he did not. But even such a
misuse does not amount to a protocol which involves extracting a domain
out of a message-id and looking it up in the DNS, which is what you
postulated and which I asked you to substantiate.

>> I doubt you would succeed in getting him thrown off by his
>> ISP in the same way as if he had used that domain in his
>> From, Sender or Approved header, or in the envelope FROM of
>> some email.

>So far the worst with "my" domain was a broken cancel-bot, and
>while he wasn't shot, his provider, the relevant Tech-C, the
>Admin-C, and some other interested parties all "helped" him to
>fix his cancel-bot a.s.a.p.

Actually, the normal practice amongst the 'professional' spam cancellers
is for the Message-ID of the cancel message to be <cancel-unique@domain>
where <unique@domain> was the Message-ID of the cancelled message. This is
known as the $alz convention, and it is to ensure that cancels for the
same article issued by different cancellers do not propagate in
competition with each other.

It is, come to think of it, an excellent example of a situation in which
it is perfectly reasonable and correct to violate a SHOULD/RECOMMENDED.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Tue, 22 Feb 2005 18:57:41 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 36
Sender: [email-masked]

Charles Lindsey wrote:

> Whether it is [CFWS] or [FWS] at the beginning of some rule
> makes not a blind bit of difference to that problem.

Whether it is [CFWS] or *WSP at the beginning of some rule
makes a difference to that problem.  The latter is correct,
and RfC 2822 has neither [FWS] nor *WSP in that place.

You also won't say "poster" because it includes the correct
poster-text, you say [FWS] %d112.111.115.116.101.114 [FWS].

This excludes some incorrect forms like "PoStEr", but still
allows an incorrect CRLF WSP "poster" CRLF WSP.  To get this
always right you need *WSP %d112.111.115.116.101.114 *WSP

Anything else is an erroneous syntax for poster-text.

> What you do do is to tempt the reader to thoink that there
> is some extra magic going on

I don't see extra magic in *WSP %d112.111.115.116.101.114 *WSP

It covers exactly all correct forms of a poster-text.  Unlike
[FWS] %d112.111.115.116.101.114 [FWS], or [FWS] "poster" [FWS],
or *WSP "poster" *WSP, which include some incorrect forms.

> I am just following the directions I have been given from the
> Chair to follow RFC 2822, both in content and style, unless
> there is a technical reason not to do so.

JFTR, where and when did Alexey say that an erroneous syntax
in the "style" of RfC 2822 is better than the correct syntax ?

IIRC he had "FWS" as one of the issues outstanding.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: mdomain vs. id-right again
Date: Tue, 22 Feb 2005 18:11:13 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 68
Sender: [email-masked]

Charles Lindsey wrote:

> It is not absolutely forbidden to put other unique texts in
> there, but you better have a good reason.

The essential point is that you MUST NOT use @xyzzy.claranet.de
in your message IDs without the permission of claranet,de

If you use a domain literal, some AlterNIC domain, a s-o-1036
.uucp or .bitnet "domain", then that's your problem, but it's
still meant to be a "domain" in some way.

>> [STD 11]
>> [RfC 1036]
>> [s-o-1036]

Exactly.  Even RfC 2822 explains that the RHS of a Message-ID
is essentially the same as the RHS of an address, a "domain"
minus CFWS and other syntax oddities allowed in addresses.

> but it chose different names for the syntax items. We are
> supposed to be following RFC 2822.

We're not supposed to use the same name "id-right" where the
syntax is different, and the semantics is "domain".  There's
not one string "2822" on the Web page with the UseFor charter.

The UseFor charter mentions RfC 822, RfC 1036, and s-o-1036.
These texts all manage to say "domain" if they mean "domain".

> I hope (but have no way of guaranteeing) that RFC 2822 bis
> will fix up <msg-id>s to eliminate the problems we have
> found. But I don't expect it to cease using the terms
> <id-left> and <id-right>.

If the future authors read old threads here, and survive the
following psychological research because they didn't commit net
suicide like all other readers, they'll copy the UseFor syntax
as is.  It's important to get at least the Message-ID right.

> What protocol instructs you to take a domain out of a
> message-id

Protocols, where articles with <[email-masked]> are
not propagated, because somebody else abused it before me.  Or
where articles written by me are replaced in a public archive,
because somebody else abused the same Message-IDs much later.
Or cancel messages for my Message-IDs by 3rd parties.

That's net abuse, like forged From addresses.  I can judge this
if it's "my" domain, and others can verify it by contacting the
owner of this domain.

> I doubt you would succeed in getting him thrown off by his
> ISP in the same way as if he had used that domain in his
> From, Sender or Approved header, or in the envelope FROM of
> some email.

So far the worst with "my" domain was a broken cancel-bot, and
while he wasn't shot, his provider, the relevant Tech-C, the
Admin-C, and some other interested parties all "helped" him to
fix his cancel-bot a.s.a.p.  Then they fixed their systems as
far as I found reasons to have them listed as "RfC-ignorants",
and while nobody said it explicitly I'm sure that we're now all
trying to avoid any similar situation.

                            Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20612
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: mdomain vs. id-right again (was: To do)
Date: Tue, 22 Feb 2005 12:10:12 GMT
Lines: 69
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> The purpose of putting a domain in there is that it is a very
>> effective way of helping to ensure that the message-id is
>> globally unique.

>It's not there as one of many ways to create a name space, it's
>THE way to create a name space.  It only offers domain literals
>for the rare cases where a domain is unavailable.

Not quite. It is the RECOMMENDED (RFC 2119) way to create a name space. It
is not absolutely forbidden to put other unique texts in there, but you
better have a good reason.

> [STD 11]
> [RfC 1036]
> [s-o-1036]
>| message-id  = "<" local-part "@" domain ">"
>[...]
>| The domain in the message ID SHOULD be the full Internet
>| domain name of the posting agent's host.

>They all want "domain" whereever possible.  If that's the case
>the best way to say so is <unique@mdomain> with the new syntax.

And [RFC 2822] also, but it chose different names for the syntax items. We
are supposed to be following RFC 2822.

>The "<" id-left "@" id-right "> syntax details in 2822 will be
>obsoleted by the better Usefor syntax.  The id-right semantics
>is what it always was, a domain covering the exceptional case
>of a domain literal (aka "domain-ref" in STD 11).

I hope (but have no way of guaranteeing) that RFC 2822 bis will fix up
<msg-id>s to eliminate the problems we have found. But I don't expect it to
cease using the terms <id-left> and <id-right>.

>> Not quite. Nobody has any business extracting any supposed
>> domain from a message-id and looking it up in the DNS.

>That's not what many Usenet users incl. me think how it works.
>It's also not what STD 11, 1036, and s-o-1036 clearly say.

Eh? What protocol instructs you to take a domain out of a message-id and
to look it up in the DNS? Certainly not STD 11, 1036, or s-o-1036.

>If some dork abuses "my" name space @xyzzy.claranet.de then I
>do not care whether the LHS algorithm is different from my UA,
>which could be good enough for your interpretation.  It's not
>for "my" interpretation.

You have every right to be annoyed if some dork uses
<[email-masked]> in his Message-ID. But I doubt you would
succeed in getting him thrown off by his ISP in the same way as if he had
used that domain in his From, Sender or Approved header, or in the
envelope FROM of some email.

To: [email-masked]
Xref: clerew local.usefor:20611
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Tue, 22 Feb 2005 11:55:57 GMT
Lines: 76
Sender: [email-masked]

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

>Charles Lindsey wrote:

>>> 2822 has no...
>>> "name:" [FWS] "body" [FWS] CRLF

>> But it will still be clearer to people familiar with RFC 2822
>> that this header is still essentially similar to all the
>> other usual headers

>Exactly that's the point, "2822 minus comments plus SP" allows
>"name:" SP CRLF WSP "body" CRLF 
>as identified by Bruce, but it's illegal in news (usefor-02).

And "2822 with comments plus SP" also allows "name:" SP CRLF WSP "body" CRLF.

Whether it is [CFWS] or [FWS] at the beginning of some rule makes not a
blind bit of difference to that problem. Either way needs the extra
wording to forbid the illegal cases (both in email and news). So you gain
nothing by trying to fix one syntactically without fixing the other. What
you do do is to tempt the reader to thoink that there is some extra magic
going on, beyond the fact that all you have done id to forbid comments in
one of the cases.

>> If you can convince Ken, then he can put it in.

>So far that's apparently a fictitious alter-ego of Alexey ;-)

>> you have no way convinced me.

>You're IMHO a bit paranoid about 2822.

No, I am just following the directions I have been given from the Chair to
follow RFC 2822, both in content and style, unless there is a technical
reason not to do so.

>Either "name:" SP *WSP "body" *WSP CRLF is what we want, or
>it's not.  Maybe that's the real question, and a mandatory FWS
>instead of the mandatory SP would be better for news + 2822bis.

>>> I'd like the two "Alternative-2".
>> Last week IIRC you preferred Alternative-1.

>Last week the alternatives were different:

>| 1. A followup is a response, and MUST have a References
>|    header. A part of a multi-part FAQ (or anything similar)
>|    is not a followup, but it MAY nevertheless have a
>|    References header.
>| 2. A followup is a response, or a part of a multi-part FAQ
>|    (or anything similar). A followup MUST have a References
>|    header, and anything else MUST NOT have one.

>In the now published protocol-03 you have:

But that is only half the text. When you see the other half of the text
that will go in the next Usefor under the semantics of the References
header, you will see that it is the same. The wording I gave last week was
but a short summary of the situation, not a wording that would stand up in
an official document.

But the other half of the text is waiting for somebody's alter ego, or
whatever :-( .

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: mdomain vs. id-right again (was: To do)
Date: Mon, 21 Feb 2005 19:04:36 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 71
Sender: [email-masked]

Charles Lindsey wrote:

 <URL:http://www.imc.org/ietf-822/mail-archive/msg04969.html>
>>| Nobody gives a damn whether an <id-right> is a domain or not

>> That's not true.

> Yes it is. Once the message-id has been written, how it was
> contructed is no longer of any interest.

In fact I do not care how somebody else but me constructed a
Message-ID with RHS @xyzzy.claranet.de:  I cancel it, or report
is as abuse, or worse.  With a strong tendency towards "worse"
including all kinds of retaliation I can think of before I cool
down or hell freezes, whatever happens first.

It's "my" RHS as long as claranet.de allows me to use it, and
as long as DENIC allows clara.net to manage claranet.de.

The RfC 2822 "id-right" was a very bad idea.  You need higher
text interpretation skills to find out that they really meant
<unique@mdomain> as it was since Message-IDs were invented in
news or STD 11, but certainly not in 2822.

> The purpose of putting a domain in there is that it is a very
> effective way of helping to ensure that the message-id is
> globally unique.

It's not there as one of many ways to create a name space, it's
THE way to create a name space.  It only offers domain literals
for the rare cases where a domain is unavailable.

 [STD 11]
| msg-id      =  "<" addr-spec ">"      ; Unique message id
[...]
| addr-spec   =  local-part "@" domain  ; global address

 [RfC 1036]
|          <unique@full_domain_name>
| where full_domain_name is the full name of the host at which
| the message entered the network, including a domain that host
| is in

 [s-o-1036]
| message-id  = "<" local-part "@" domain ">"
[...]
| The domain in the message ID SHOULD be the full Internet
| domain name of the posting agent's host.

They all want "domain" whereever possible.  If that's the case
the best way to say so is <unique@mdomain> with the new syntax.

The "<" id-left "@" id-right "> syntax details in 2822 will be
obsoleted by the better Usefor syntax.  The id-right semantics
is what it always was, a domain covering the exceptional case
of a domain literal (aka "domain-ref" in STD 11).

>> Nobody plans to use DNS to compare Message-IDs.

> Not quite. Nobody has any business extracting any supposed
> domain from a message-id and looking it up in the DNS.

That's not what many Usenet users incl. me think how it works.
It's also not what STD 11, 1036, and s-o-1036 clearly say.

If some dork abuses "my" name space @xyzzy.claranet.de then I
do not care whether the LHS algorithm is different from my UA,
which could be good enough for your interpretation.  It's not
for "my" interpretation.
                        Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20608
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Mon, 21 Feb 2005 11:08:06 GMT
Lines: 81
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>  [<http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt>]
>>> Another vote for <unique@mdomain> instead of <id-left@id-right>

>> No, that draft was written over two years vefore RFC 2822
>> came out

>BTW, the author is also mentioned in chapter 8 of RfC 2822.
> 
>> there could exist some machine somewhere with an IP address
>> and no domain-name to go with it.

>Sure, sometimes domain literals are necessary.  And generally
>FQDNs are better.  Maybe you hate "domain", because you needed
>an argument in your flame-war with Bruce about "case sensitive
>Message-IDs", but IMHO that's incorrect / unnecessary:

><unique@example> and <unique@Example> are two Message-IDs of
>the same domain.  Bruce mentioned some of your articles in a 
>"last call" yesterday (I saw it in ietf.general list):

> <URL:http://www.imc.org/ietf-822/mail-archive/msg04969.html>
>| Nobody gives a damn whether an <id-right> is a domain or not

>That's not true.

Yes it is. Once the message-id has been written, how it was contructed is
no longer of any interest. All that matters is that it accompanies the
message without munging and can be matched against other occurrences of
itself that may turn up (e.g. in References headers).

The purpose of putting a domain in there is that it is a very effective
way of helping to ensure that the message-id is globally unique. So
effective, in fact, that RFC 2822 RECOMMENDS that it be done that way (and
we inherit that RECOMMEND).

>  In fact I'd insist on a domain

We do insist on a domain (at least to the extent of that RECOMMENDATION,
which is equivalent to a SHOULD).

>, because it's
>an essential part of the concept.  If Bruce really thinks that
><unique@example> and <unique@Example> are the same Message-ID,
>then he's wrong.  But the problem is not that the <id-right> is
>no domain (incl. domain literals).

Assuming that Bruce meant example.com and Example.Com, then they are
different message-ids evidently derived from the same domain, in
accordance with that RECOMMENDATION.

>Obviously <id-left> and <id-right> were bad choices in RfC 2822

They were perfeclty good choices so far as they went. They could usefully
have made the relationship to domains clearer, and their exact syntax is a
mess as we have now discovered (hence the changes made to it in USEFOR).

>There won't be a problem with the proposed "Domain Name System
>(DNS) Case Insensitivity Clarification".  Nobody plans to use
>DNS to compare Message-IDs.

Not quite. Nobody has any business extracting any supposed domain from a
message-id and looking it up in the DNS. That is not part of any protocol
(hence the reason why nobody should give any damn). Though it might
occasionally be useful to do so for diagnostic	 purposes (spam chasing,
and so on).

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Mon, 21 Feb 2005 13:01:49 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 63
Sender: [email-masked]

Charles Lindsey wrote:

>> 2822 has no...
>> "name:" [FWS] "body" [FWS] CRLF

> But it will still be clearer to people familiar with RFC 2822
> that this header is still essentially similar to all the
> other usual headers

Exactly that's the point, "2822 minus comments plus SP" allows
"name:" SP CRLF WSP "body" CRLF 
as identified by Bruce, but it's illegal in news (usefor-02).

> If you can convince Ken, then he can put it in.

So far that's apparently a fictitious alter-ego of Alexey ;-)

> you have no way convinced me.

You're IMHO a bit paranoid about 2822.  A clear difference is
better than an artificial similarity.  We (tinw) shouldn't try
to smuggle some obscured "features" through a future last call.

Either "name:" SP *WSP "body" *WSP CRLF is what we want, or
it's not.  Maybe that's the real question, and a mandatory FWS
instead of the mandatory SP would be better for news + 2822bis.

>> I'd like the two "Alternative-2".
> Last week IIRC you preferred Alternative-1.

Last week the alternatives were different:

| 1. A followup is a response, and MUST have a References
|    header. A part of a multi-part FAQ (or anything similar)
|    is not a followup, but it MAY nevertheless have a
|    References header.
| 2. A followup is a response, or a part of a multi-part FAQ
|    (or anything similar). A followup MUST have a References
|    header, and anything else MUST NOT have one.

In the now published protocol-03 you have:

 [Alternative-1.]
| A "followup" is an article containing a response to the
| contents of an earlier article.  
| An article is a "precursor" of some later article which is a
| followup to it, or which is otherwise intended to be grouped
| with it for purposes of display (e.g. as a part of a
| multipart posting such as a FAQ).

 [Alternative-2.]
| A "followup" to an earlier article (its "precursor") is one
| intended to be grouped with that article for purposes of
| display (e.g. because it is a response to its contents or is
| a part of a multipart posting such as a FAQ).

Last week I actually wanted a short statement "a follow-up is
a response and has a References header".  But if you insist on
mentioning a multipart posting, then the new [Alternative-2] is
IMHO fine and minimally better than the new [Alternative-1].

                        Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20607
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Mon, 21 Feb 2005 10:44:05 GMT
Lines: 54
Sender: [email-masked]

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

>A natural compromise is to keep the pattern...

>"name:" SP [CFWS} "body" [CFWS] CRLF

>...because it corresponds to the very similar 2822 pattern...

>"name:" [CFWS] "body" [CFWS] CRLF

>...and because 2822 hat its own peculiar "MUST NOT" about empty
>lines as a side-effect of folded comments, which is almost the
>same idea as in your MUST.

>But in the cases where you have [FWS] instead of [CFWS] there's
>no excuse to stick to the 2822 syntax pattern.  2822 has no...

>"name:" [FWS] "body" [FWS] CRLF

But it will still be clearer to people familiar with RFC 2822 that this
header is still essentially similar to all the pother usual headers,
except only that FWS is used in place ot CFWS.

>"name:" SP *WSP "body" *WSP CRLF

>...is just better.  And it's no big editorial problem, see my
>earlier proposal for the seven (? IIRC) affected [FWS]-headers.

If you can convince Ken, then he can put it in. But you have no way
convinced me.

>Something completely different, I've just found the new
><http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-03.txt>

>Minus some synchronizations with [ARTICLE] it's almost ready,
>isn't it ? 

No, there is still a lot to be done.

 I'd like the two "Alternative-2".

Last week IIRC you preferred Alternative-1.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Fri, 04 Feb 2005 09:54:37 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 43
Sender: [email-masked]

Charles Lindsey wrote:
 
  [<http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt>]
>> Another vote for <unique@mdomain> instead of <id-left@id-right>

> No, that draft was written over two years vefore RFC 2822
> came out

BTW, the author is also mentioned in chapter 8 of RfC 2822.
 
> there could exist some machine somewhere with an IP address
> and no domain-name to go with it.

Sure, sometimes domain literals are necessary.  And generally
FQDNs are better.  Maybe you hate "domain", because you needed
an argument in your flame-war with Bruce about "case sensitive
Message-IDs", but IMHO that's incorrect / unnecessary:

<unique@example> and <unique@Example> are two Message-IDs of
the same domain.  Bruce mentioned some of your articles in a 
"last call" yesterday (I saw it in ietf.general list):

 <URL:http://www.imc.org/ietf-822/mail-archive/msg04969.html>
| Nobody gives a damn whether an <id-right> is a domain or not

That's not true.  In fact I'd insist on a domain, because it's
an essential part of the concept.  If Bruce really thinks that
<unique@example> and <unique@Example> are the same Message-ID,
then he's wrong.  But the problem is not that the <id-right> is
no domain (incl. domain literals).

Obviously <id-left> and <id-right> were bad choices in RfC 2822
creating a lot of unnecessary confusion (between you and Bruce,
nobody else has this problem), let's use <unique> and <mdomain>
in Usefor.  After all the syntax will be different, that's a
good reason to replace these misleading 2822 terms.

There won't be a problem with the proposed "Domain Name System
(DNS) Case Insensitivity Clarification".  Nobody plans to use
DNS to compare Message-IDs.

                         Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Fri, 18 Feb 2005 08:05:41 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 54
Sender: [email-masked]

Charles Lindsey wrote:

> 1. There are some cases for which no feasible syntactic
> soluition exists,

Yes, but they are restricted to [CFWS] cases (see below).

> you still need the MUST wording to cover them

Yes, keeping the MUST in the text is okay.  I'm not trying to
replace it by some convoluted syntax.  I only want the draft
to be as clear as possible for readers.  Some of them could be
UA implementors or gateway operators.

> 2. It is generally undesirable to depart from the RFC 2822
> syntax and conventions except in case of absolute technical
> necessity.

A natural compromise is to keep the pattern...

"name:" SP [CFWS} "body" [CFWS] CRLF

...because it corresponds to the very similar 2822 pattern...

"name:" [CFWS] "body" [CFWS] CRLF

...and because 2822 hat its own peculiar "MUST NOT" about empty
lines as a side-effect of folded comments, which is almost the
same idea as in your MUST.

But in the cases where you have [FWS] instead of [CFWS] there's
no excuse to stick to the 2822 syntax pattern.  2822 has no...

"name:" [FWS] "body" [FWS] CRLF

...at all.  Your reasons for the [CFWS]-cases don't work for...

"name:" SP [FWS] "body" [FWS] CRLF

...headers without 2822-counterparts.  The correct pattern...

"name:" SP *WSP "body" *WSP CRLF

...is just better.  And it's no big editorial problem, see my
earlier proposal for the seven (? IIRC) affected [FWS]-headers.

Something completely different, I've just found the new
<http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-03.txt>

Minus some synchronizations with [ARTICLE] it's almost ready,
isn't it ?  I'd like the two "Alternative-2".

                         Bye, Frank

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usepro-03.txt
Date: Thu, 17 Feb 2005 10:06:45 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: News Article Architecture and Protocols
	Author(s)	: C. Lindsey
	Filename	: draft-ietf-usefor-usepro-03.txt
	Pages		: 54
	Date		: 2005-2-16
	
This Draft, together with its companion draft [USEFOR], are
   intended as standards track documents, together obsoleting RFC
   1036, which itself dates from 1987.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-usefor-usepro-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usepro-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Xref: clerew local.usefor:20601
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Thu, 17 Feb 2005 10:20:30 GMT
Lines: 42
Sender: [email-masked]

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

>Charles Lindsey wrote:

>>| o  The header contents of every header line (including the
>>|    first and any that are subsequently folded) MUST contain
>>|    at least one non-whitespace character.
> 
>> That seems to forbid your example.

>Yes, that's the point.  The general ABNF for all header fields
>has either the form "name:" SP [FWS] "body" [FWS] CRLF or it's
>the same pattern with CFWS instead of FWS.

>The general 2822-pattern is "name:" [CFWS] "body" [CFWS] CRLF.

>Of course Bruce and other readers are misled to believe that
>"name:" SP CRLF WSP "body" CRLF is okay, unless they find this
>MUST in the text and understand "header content" "first line".

Yes, but there are two problems with trying to attack this syntactically.

1. There are some cases for which no feasible syntactic soluition exists,
and so you still need the MUST wording to cover them, in which case Bruce
and other readers will still be misled. In paticular, all the headers from
RFC 2822 or from other mail extensions that we do not use, but can still
turn up in News (and even some that we do use, like Content-*), could not
be covered syntactically in our draft.

2. It is generally undesirable to depart from the RFC 2822 syntax and
conventions except in case of absolute technical necessity.

Date: Wed, 16 Feb 2005 10:45:49 -0800 (PST)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Issues outstanding
Sender: [email-masked]

Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:

>"Mailed-And-Posted: yes" is like "Killfile-Me: yes" for me,
>if the sender does not explicitly mention this in the body.
>If he mentions it explicitly, what's the point of the header ?

You just said it in your first sentence. It is very much easier to
killfile (or do any automated processing) on a standardized header than on
the entire body of a message with free-form text.

The intent was so that people could kill email that was posted and mailed.
It would appear in email. And people could kill news articles that were 
posted and mailed, for whatever reason you feel like you want to do it.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Wed, 16 Feb 2005 19:04:02 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 21
Sender: [email-masked]

Charles Lindsey wrote:

>| o  The header contents of every header line (including the
>|    first and any that are subsequently folded) MUST contain
>|    at least one non-whitespace character.
 
> That seems to forbid your example.

Yes, that's the point.  The general ABNF for all header fields
has either the form "name:" SP [FWS] "body" [FWS] CRLF or it's
the same pattern with CFWS instead of FWS.

The general 2822-pattern is "name:" [CFWS] "body" [CFWS] CRLF.

Of course Bruce and other readers are misled to believe that
"name:" SP CRLF WSP "body" CRLF is okay, unless they find this
MUST in the text and understand "header content" "first line".

With "name:" SP *WSP "body" *WSP CRLF they would probably see
that it's not the same as in 2822 minus comments,  Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20597
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Wed, 16 Feb 2005 12:20:27 GMT
Lines: 37
Sender: [email-masked]

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

>Charles Lindsey wrote:

>>> Bruce found an interpretation of the [FWS]-syntax,
>>> which is not allowed by an explicit MUST in the text.

>> Can you remind me of what that was?

>It was the case "name:" SP CRLF WSP "body" CRLF
>with a trailing space in the first line.  Bye, Frank

Sorry, you have still got me lost. I presume "body" in the above was
intended to represent the content of the header.

In draft-ietf-usefor-usefor-02.txt we find:

   o  All agents MUST generate headers so that at least one space
      immediately follows the ':' separating the header name and the
      header contents (for compatibility with deployed software).  News
      agents MAY accept headers which do not contain the required space.
   o  The header contents of every header line (including the first and
      any that are subsequently folded) MUST contain at least one
      non-whitespace character.

That seems to forbid your example.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: Issues outstanding
Date: Tue, 15 Feb 2005 23:17:49 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 46
Sender: [email-masked]

Charles Lindsey wrote:
 
> Posted-And-Mailed would work fine with mailing lists.

If it works for mailing lists and news (with some UAs), a
separate draft should introduce it officially for both mail
and news.  I don't see the point in a news-only solution.

"Mailed-And-Posted: yes" is like "Killfile-Me: yes" for me,
if the sender does not explicitly mention this in the body.
If he mentions it explicitly, what's the point of the header ?

> I have to remember, for each mailing list I am on, whether
> to use "Reply" or "Reply-To-All", with dire consequences if
> I use the wrong one

Of course I've seen your discussions with Keith, and therefore
I'd send a courtesy copy to him, but he's the one exception in
this universe as far as I'm concerned.   Bruce never asked me
why I don't send any courtesy copies, I never asked him why he
does, so we can apparently manage this "netiquette difference"
without an additional header.  <shrug />

 [FWS-issue, but also relevant for id-left "@" id-right]
> A difference in syntax (or a difference in syntactic style)
> is still a difference, even if the eventual outcome is the
> same.

That's true.  But you want the same syntatic style as in 2822
with a different outcome.  That's cheating.  If it really is
different from 2822, then using an apparently identical syntax
is confusing for readers.
  
Unless it's intentional, as planned for the term "msg-id" (and
the production is obviously different from 2822, no artificial
similarity, only the same name "msg-id")

It's not the same as id-left "@" id-right, where I really want
unique "@" mdomain, because that's what it is, and it is also
very different from the 2822 syntax for id-left "@" id-right.

msg-id = "<" id-left "@" id-right ">" would be cheating again,
it's apparently the same line as in 2822, but many details are
"different".  Or rather "better" (towards "correct"), the 2822
concept with its NO-WS-CTL etc. wasn't good enough.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Tue, 15 Feb 2005 22:16:58 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Charles Lindsey wrote:

>> Bruce found an interpretation of the [FWS]-syntax,
>> which is not allowed by an explicit MUST in the text.

> Can you remind me of what that was?

It was the case "name:" SP CRLF WSP "body" CRLF
with a trailing space in the first line.  Bye, Frank

Date: Tue, 15 Feb 2005 10:17:23 -0800 (PST)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Issues outstanding
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Of the small number of people on this group who had the patience to read
>through your interminable rants, 

Knock it off, Charles. The fact that you did not agree does not make
my arguments "interminable", nor were they "rants".

> ...ALL agreed that there was no technical difference involved.

And forty million Frenchmen weren't wrong about the Maginot line, either.

You can count the raised hands all you like, Charles, but the facts
remain: there is a significant difference between the two cases. I'd
repeat the differences again, but you'd call them 'interminable rants' in
your typical dissmissive style. I notice that YOU repeat YOUR arguments,
what few you have, again below, so if the label applies to me, it 
certainly applies to you.

>That part of this matter is CLOSED, unless you can persuade our Chair to 
>reopen it.

Since the Chair did not close it, and you are not in a position to do so,
I do not need the Chair to reopen it. You are usurping authority here, 
Charles, and I'm tired of it. 

This deal of sharing the editor's job that was put in place as a
compromise simply isn't working, Chair. Fix it.

>The choice between the two alternatives is now purely a matter of 
>preference.

This is a TECHNICAL standard, and the choice betweeen correct and 
incorrect is not supposed to be a "matter of preference". CHANGING the 
text, as you did, ought to require some justification. Do you have any 
justification for making the References header useless?

>>I keep pointing out the difference. If a non-followup MAY have a 
>>References header, you lose the ability to identify followups.

>There are two different definitions of 'followup' involved. 

Charles, it does not matter HOW you define followup for the difference
to exist. Once you say that "non-followups may have References headers" 
you remove the ability to determine what is and is not a followup. Define 
followup to be "Charles propensity for insulting those he doesn't agree 
with" if you like, it doesn't matter. Substitute "pomegranate" if you 
like. When the only way a reader can identify what is and is not a 
"pomegranate" is by the existance or lack of a References header, then 
allowing "non pomegranates" to have a References header means he can no 
longer do that. Changing from "able to identify pomegranates" to "cannot 
identify pomegranates" is a significant change, Charles, whether you are 
able to understand that or not.

I don't know any other way to say this. It's pretty simple stuff. It's a 
significant change that you have never been able to justify. And it is not
just MY opinion it is significant. If the header merited RFC2119 mandates 
up until you decided it didn't, then it is a significant change. Something 
that was considered by everyone here to be an interoperability issue 
suddenly is not. What changed?

>You persist in
>applying the definition of one alternative to the consequences which arise
>in the other alternative, and so it is no wonder you land up with
>nonsense.

You are wrong. The "consequences" of watering down the References header
has NOTHING to do with the definition of followup. You can keep pretending 
it does, but that does not make it so. 

To: [email-masked]
Xref: clerew local.usefor:20591
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Mon, 14 Feb 2005 16:20:54 GMT
Lines: 44
Sender: [email-masked]

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

>Okay, maybe add two IPv6 examples and a pointer to RfC 3513.

>For BBBB:CCCC:DDDD:EEEE:FFFF:0000:1234:5678 the path identities
>...!BBBB:CCCC:DDDD:EEEE:FFFF::1234:5678!... and
>...!BBBB:CCCC:DDDD:EEEE:FFFF:0000:18.52.86.120!... are actually
>the same, aren't they ?

I don't know. If some site uses sometimes the one and somtimes the other
in the Paths of articles that pass through it, then it has only itself to
blame if it fails to recognise its own articles when they come around
again.

>> If some ancient system misparses that

>Modern systems also have an excellent chance to get this wrong.

The only systems where this matters are the ones responsible for ensuring
that articles that have passed through the site with that IPv6 address
don't get sent those articles again. Those sites had better get it right.

>> I doubt Ken will want to adopt the *WSP syntax.

>Then he could state his reasons to stick to [FWS] instead of
>*WSP here.

Indeed he could.

>  Bruce found an interpretation of the [FWS]-syntax,
>which is not allowed by an explicit MUST in the text.

Can you remind me of what that was?

To: [email-masked]
Xref: clerew local.usefor:20590
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Issues outstanding
Date: Mon, 14 Feb 2005 16:13:28 GMT
Lines: 33
Sender: [email-masked]

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

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>It has been established that there is no technical difference between
>>these formulations. 

>Established by whom? Certainly not by anyone in this group. 

Of the small number of people on this group who had the patience to read
through your interminable rants, ALL agreed that there was no technical
difference involved. That part of this matter is CLOSED, unless you can
persuade our Chair to reopen it. The choice between the two alternatives
is now purely a matter of preference.

>I keep pointing out the difference. If a non-followup MAY have a 
>References header, you lose the ability to identify followups.

There are two different definitions of 'followup' involved. You persist in
applying the definition of one alternative to the consequences which arise
in the other alternative, and so it is no wonder you land up with
nonsense.

Date: Mon, 14 Feb 2005 15:34:28 GMT
From: Charles Lindsey <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: User-Agent
Newsgroups: local.usefor
Sender: [email-masked]

That seems OK to me.

To: [email-masked]
Xref: clerew local.usefor:20589
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Issues outstanding
Date: Mon, 14 Feb 2005 16:06:42 GMT
Lines: 81
Sender: [email-masked]

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

>Charles Lindsey wrote:

> [Posted-And-Mailed]
>> I gather our Chair prefers #2 (a or b), but he has made no
>> definitive pronouncement.

>Add me and my ersatz-newsreader.  Obscure news-only headers to
>"solve" netiquette-problems make no sense, they should at least
>also work for mailing lists.

Actually, Posted-And-Mailed would work fine with mailing lists.

Mail-Copies-To might not, and if the email people were to agree on some
more general solution, then that would be fine. But last time they tried,
they just went round and round in circles. Most of them would have been
happy to use Mail-Followups-To, but a certain Mr Moore and a certain Mr
Lilly were vehemently opposed (for completely opposite reasons), and so
nothing happened and the dilemma remains (I have to remember, for each
mailing list I am on, whether to use "Reply" or "Reply-To-All", with dire
consequences if I use the wrong one).

Mail-Copies-To is moderately widely implemented in the News world and
Mail-Followups-To is moderately widely implemented in the Mail world, and
neither is suitable, as it stands, for use in the other medium.

> [Followup]
>> It has been established that there is no technical difference
>> between these formulations. It is just a matter of wording

>ACK.  Let's use your 1st definition and get rid of the "MUST":

Yes, that is my preference.

But the wording given was just a summary of the two positions, and not a
wording for the draft. Indeed, the definition in Usepro contains no RFC
2119 wording.

> [folding]

>> I argued that there was no point in changing only those cases
>> where it would work, thereby introducing differences from RFC
>> 2822.

>Yes, the same issue for [CFWS] before or after the field body
>is messy.  But that doesn't "introduce" differences from 2822.

A difference in syntax (or a difference in syntactic style) is still a
difference, even if the eventual outcome is the same.

>Maybe you find a better way to make the difference from 2822
>clear for gateways operators and UA implementors ?  IMO a real
>solution could be "name:" FWS "body" CRLF for mail _and_ news
>in a future 2822bis, but unfortunately we can't fix this here.

We discussed this a while back, and the conclusion was that we had to
forbid it becaue there were too many broken sites that would remove
trailing whitespace, and we needed that obligatory SP after the ':' to
survive all transports.

> [msg-id]

>...  And there were three problems with
>dots in a quoted <unique> (cases not covered by dot-atom-text).

Yes, I had forgotten about that. It is now back on my list.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usepro-02.txt
Date: Mon, 07 Feb 2005 15:47:09 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: News Article Architecture and Protocols
	Author(s)	: C. Lindsey
	Filename	: draft-ietf-usefor-usepro-02.txt
	Pages		: 53
	Date		: 2005-2-7
	
This Draft, together with its companion draft [USEFOR], are
   intended as standards track documents, together obsoleting RFC
   1036, which itself dates from 1987.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-usefor-usepro-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usepro-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 7 Feb 2005 12:23:36 -0800 (PST)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Issues outstanding
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>It has been established that there is no technical difference between
>these formulations. 

Established by whom? Certainly not by anyone in this group. 

I keep pointing out the difference. If a non-followup MAY have a 
References header, you lose the ability to identify followups. Until
you can answer this question with the same certainty under both 
"formulations", you cannot say that there is no technical difference:

"Article A has a References header that points to article B. Is it a 
followup to B?"

It used to be considered important to be able to identify followups, to 
the point that RFC2119 language was used in a place where it would 
otherwise be impermissible, and prior to that, language equivalent to 
RFC2119 was used. I'll point out to the peanut gallery that this language 
predated my participation in this process by quite a bit of time.

If followups are no longer important, than lets get rid of the header
whose sole function is to identify what follows up to what. If they are
still important, then don't eviscerate the only header that can identify
them. 

Date: Sun, 06 Feb 2005 17:19:23 +0100
From: Gunnar Ritter <[email-masked]>
Organization: Privat.
To: [email-masked]
Subject: Re: User-Agent
Sender: [email-masked]

	Gunnar

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: Issues outstanding
Date: Sun, 06 Feb 2005 13:17:29 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 74
Sender: [email-masked]

Charles Lindsey wrote:

 [Posted-And-Mailed]
> I gather our Chair prefers #2 (a or b), but he has made no
> definitive pronouncement.

Add me and my ersatz-newsreader.  Obscure news-only headers to
"solve" netiquette-problems make no sense, they should at least
also work for mailing lists.

> It is still not clear (to me) what the objection to keeping
> them is

See above.  Some users want / send courtesy copies, other users
hate it.  A news-only "solution" doesn't help, it increases the
confusion (new vs. old UAs + news vs. mailing lists).

 [Followup]
> It has been established that there is no technical difference
> between these formulations. It is just a matter of wording

ACK.  Let's use your 1st definition and get rid of the "MUST":

| A followup is a response, and has a References header.

No details about the parts of a multi-part FAQs, they are only
confusing.  And IMHO no 2119 keywords for definitions, if A is
defined by B, then it's unnecessary to say that A MUST be B.

You also wouldn't say that "green MUST be a colour", it _is_ a
colour.  Adding "one of 9 or 18 parts of golf" doesn't help ;-)

 [folding]
> Frank was very keen to introduce *FWS rather than *CFWS or
> *FWS in various headers

JFTR, SP *WSP instead of SP [FWS] after the colon, and also
*WSP CRLF instead of [FWS] CRLF.

Actually I'd prefer FWS instead of SP [FWS], but you told me
that some news implementations insist on SP after the colon.

And I don't want to "introduce" a SP *WSP instead of SP [FWS],
or *WSP CRLF instead of [FWS] CRLF, this reflects an explicit
MUST in the text.

> I argued that there was no point in changing only those cases
> where it would work, thereby introducing differences from RFC
> 2822.

Yes, the same issue for [CFWS] before or after the field body
is messy.  But that doesn't "introduce" differences from 2822.

Usefor-02 doesn't allow "name:" SP CRLF WSP "body" CRLF for a
folded "name: body" header field.  A PITA for mail2news gateway
operators.

> Note that this issue involves no technical change - just the
> method of description.

Maybe you find a better way to make the difference from 2822
clear for gateways operators and UA implementors ?  IMO a real
solution could be "name:" FWS "body" CRLF for mail _and_ news
in a future 2822bis, but unfortunately we can't fix this here.

 [msg-id]
> I think this is CLOSED.

I'd like to see it.  If it mentions an <id-left> or <id-right>,
then it's probably not ok.  And there were three problems with
dots in a quoted <unique> (cases not covered by dot-atom-text).

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Sun, 06 Feb 2005 11:01:11 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 35
Sender: [email-masked]

Charles Lindsey wrote:

> @cbosgd.ATT.COM,@mjuxj.ATT.COM,@mhuxt.ATT.COM

Thanks, clearly two adjacent delimiters, your ...!!... syntax
should work with 1036-servers.  It's a good compromise between
options 2C and 2D in the "outstanding issues".

> Our draft makes it clear that ':' is henceforth to be part of
> the path-identity and not a delimiter. Hence ap IPv6 address
> would appear as ...!x:x:x:x:x:x:d.d.d.d!...

Okay, maybe add two IPv6 examples and a pointer to RfC 3513.

For BBBB:CCCC:DDDD:EEEE:FFFF:0000:1234:5678 the path identities
...!BBBB:CCCC:DDDD:EEEE:FFFF::1234:5678!... and
...!BBBB:CCCC:DDDD:EEEE:FFFF:0000:18.52.86.120!... are actually
the same, aren't they ?

For implementors these examples make it clear, that something
starting with a letter is not necessarily a FQDN, and that
(apparently) different path identities can be the same IP.

> If some ancient system misparses that

Modern systems also have an excellent chance to get this wrong.

> I doubt Ken will want to adopt the *WSP syntax.

Then he could state his reasons to stick to [FWS] instead of
*WSP here.  Bruce found an interpretation of the [FWS]-syntax,
which is not allowed by an explicit MUST in the text.

                        Bye, Frank

Date: Sat, 05 Feb 2005 20:44:12 -0000
From: "Charles Lindsey" <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: draft-ietf-usefor-usepro-02.txt
Cc: "Alexey Melnikov" <[email-masked]>
Sender: [email-masked]

I submitted draft-ietf-usefor-usepro-02.txt to the drafts editor last  
December (and we have been discussing it since then on the basis of the  
copy on our website).

Frank pointed out last week that it had still not appeared on the official  
drafts sites, so I sent it again.

I received the usual auto-acknowledgements both times, but nothing else.

So finally I escalated to the next stage up, and received the following  
response:

"We sent you twice messages saying that your draft did not have required
statements in it. PLease fix the problem with your draft and resubmit."

Well, they may have sent them, but I never received them (and I have  
carefully examined my trash file, which has not been pruned of late, and  
they are certainly not there). Moreover, they carefully did not explain  
which required statements they were concerned about, which was not overly  
helpful.

Anyway, I have now studied their website and RFCs 3667 and 3668 and fixed  
such problems as I could find and resubmitted. So we shall see. Draft-03  
is now almost ready, and will be submitted in about a week's time (I am  
away until then), assuming draft-02 finally makes it.

And, in spite of their protestations, I see that drafts with incorrect  
texts were still being accepted in January, including one by a certain Mr  
Lilly :-( .

To: [email-masked]
Xref: clerew local.usefor:20583
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Issues outstanding
Date: Fri, 4 Feb 2005 21:38:05 GMT
Lines: 177
Sender: [email-masked]

Some while back I posted a list of issues (and our Chair added some more).
We have now reached the point where we cannot continue working on our
drafts until these are resolved.

So here is the list again, with my comments on where we are at on each
one. SO PLEASE CAN WE HAVE INPUT ON THESE, especially on the ones which
still appear to be OPEN?

>We are coming to the point where there is little more that can be done on
>the documents we are supposed to be producing without deciding how various
>outstanding issues are to be resolved.

1. Complaints-To

>I published a list of 4 options (and invited other options) in
>http://www.imc.org/ietf-usefor/mail-archive/msg00151.html. Only three
>people have expressed any preference amongst them. I think #4 is dead, and
>#2 is the one most people could live with (but on such a small sample,
>that is hardly meaningful).

>#2 was to do it in Injection-Info rather than in a Complaints-To header,
>and to provide only a mail-complaints-to parameter (which would leave open
>the option to provide a separate url-complaints parameter as a future
>extension).

I think the conclusion we reached on this was to have a
'mail-complaints-to' parameter in the Injection-Info header with an
<address-list> for its parameter. And we decided not to have any provision
for URLs at this time, though a url-complaints-to parameter could be added
as a future extension if there was a demand for it.

If that is agreed, then this issue is CLOSED, except for deciding whether
multiple <address>s meant you were supposed to reply to ALL of them, or to
ANY ONE of them. Input on this is still needed.

2. Path header delimiters

>.See http://www.imc.org/ietf-usefor/mail-archive/msg00123.html.
>
>I offered 4 schemes A, B, C and D with different ways of indicating:
>    #1 the injecting site
>    #2 identity of previous site verified
>    #3 identity of previous site not verified
>    #4 identity of previous site not checked
>
>A. (draft-13) Uses '%' for #1, '/' for #2, '?' for #3 amd '!' for #4
>
>B. (Henry)    Uses '@' for #1, ',' for #2, ' ' for #3 amd '!' for #4
>
>C. (Diablo)   !foo.example.POSTED! for #1
>              !bar.example.MISMATCH! for #3
>              !baz.example! for #2 and #4 which are not distinguished
>
>D. (CHL)      !foo.example!POSTED! for #1
>              !baz.example!M! (or !baz.example!!) for #2
>              !bar.example!MISMATCH! for #3
>              !baz.example! for #4
>
>But that's just a summary. Please follow the URL for all the pros and
>cons.

Not that the alternative "!baz.example!!" in D relies on some examples in
RFC 1036 which apparently make it OK to have two <delimiter>s in
succession.

THIS ISSUE IS THE MAIN ITEM HOLDING UP FURTHER PROGRESS, but there was
zilch discussion of it, except for some recent comments by Frank who
seemed to support option D in the "!baz.example!!" form.

Would that solution be acceptable to everyone else. If so, I could soon
propose some texts (both within USEFOR and USEPRO). But, in the
meantime, this one is still OPEN.

3. Mail-Copies-To and Posted-And Mailed

>Available options appear to be:
>
>1.  Include them as in draft-13
>2a. Defer them to a future document (standards-track)
>2b. Defer them to a future document (experimental)
>3.  Drop them entirely

>Earlier discussions were inconclusive. I gather our Chair prefers #2 (a or
>b), but he has made no definitive pronouncement.

I think all that the discussion established was that it was as much effort to
remove them (from USEPRO) as to add them (to USEFOR). It is still not clear
(to me) what the objection to keeping them is, and I see no merit at all in
#2b (since these headers are in moderately common use, and the "experiment"
has, in effect, been done).

So this issue is still OPEN.

4.  Terminology for followups.

>1. A followup is a response, and MUST have a References header. A part of
>   a multi-part FAQ (or anything similar) is not a followup, but it MAY
>   nevertheless have a References header.
>
>2. A followup is a response, or a part of a multi-part FAQ (or anything
>   similar). A followup MUST have a References header, and anything else
>   MUST NOT have one.
>
>It has been established that there is no technical difference between
>these formulations. It is just a matter of wording, so a simple majority
>for one of the other should settle the matter.
>
>There are alternative definitions in USEPRO, but no corresponding wordings
>for the References header in USEFOR yet, so maybe we should wait until
>there are.

This one is still OPEN. There are two alternative texts in USEPRO, but the
matching alternative texts for USEFOR are not in place yet (I hope Ken is
working on them). So I am happy to let this one be for now. There is no
technical issue involved - just a question of how to define things.

5. Review Injection-Info syntax (this might be related to Complaints-To)

I invited proposals from anyone who wanted to pursue this. I received none, so
I think this one is CLOSED.

We all agree that RFC 2231 is ugly, but most of it is quite unnecessary in
Netnews. I would be happy for this to be pointed out in USEFOR with suitably
discouraging wording.

6. Remove filename parameter from the Archive header.

I think we concluded that the filename-parameter (and perhaps other
parameters) might well be useful in the future, but there was no need to
define them now. Therefore, we should just keep provision for MIME-style
parameters in this header (so software would be required to ignore such
parameters for now), but leave the definition of any actual parameters for
future extensions.

7. FWS issue in headers.

Frank was very keen to introduce *FWS rather than *CFWS or *FWS in various
headers to cope with the rule that folding should not result in empty lines,
or even in lines with empty content. It was established, however, that the
present verbiage covering this issue would still be needed because it was not
possible to solve all such cases syntactically. I argued that there was no
point in changing only those cases where it would work, thereby introducing
differences from RFC 2822. Note that this issue involves no technical change -
just the method of description.

Frank received no other support, and I propose to do nothing. If Ken wants to
make these changes to USEFOR, then so be it. I regard this one as CLOSED.

8. Define a Message-ID compatible with NNTP, get rid of NO-WS-CTL.

We agreed to get rid of NO-WS-CTL (it would have been incompatible with
the new NNTP draft), but our Chair rules that further departures from RFC
2822 were not to be allowed. So I think this is CLOSED.

So could people who disagree with the ones I have marked CLOSED please
speak up, and otherwise will our Chair please confirm that they are
CLOSED.

And please may we have discussion of the ones still OPEN, especially the
Path header one.

To: [email-masked]
Xref: clerew local.usefor:20582
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Thu, 3 Feb 2005 12:09:48 GMT
Lines: 33
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> should now be fixed

>Thanks.

>> http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt

>Another vote for <unique@mdomain> instead of <id-left@id-right>

No, that draft was written over two years vefore RFC 2822 came out, and
before the id-left and id-right stuff had appeared in the DRUMS drafts.

>if I got this right... ;->  It even says that using IPs is now
>(= 1998) obsolete, and it mentions the problem with dynamic IPs.

That was its opinion. But there could exist some machine somewhere with an
IP address and no domain-name to go with it. Agreed, the practice should
be deprecated, and RFC 2822 does so (though USEFOR should probably apply a
little reinforcement).

To: [email-masked]
Xref: clerew local.usefor:20581
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: To do
Date: Thu, 3 Feb 2005 12:05:41 GMT
Lines: 65
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> There are examples in RFC 1036 of two <path-delimiter>s
>> adjacent, so presumably it was intended to be OK.

>I haven't found it looking for "!" or "path:".  If that's
>the case it should be good enough for your ...!!... idea.

The example in RFC 1036 is:

	cbosgd!mhuxj!mhuxt
	cbosgd, mhuxj, mhuxt
	@cbosgd.ATT.COM,@mjuxj.ATT.COM,@mhuxt.ATT.COM
	teklabs, zehntel, sri-unix@cca!decvax

There are several examples of ', ' there (SP is a delimiter, and those
examples plus RFC 822, are sufficient to establish that long Path lines
can be folded).

The 3rd line contains two examples of ',@' i.e. two delimiters immediately
together. There is also an example of '@' on its own to confirm that it is a
delimiter. There is also the interesting case of an '@' on its own at the
start of a line. By RFC 1036 standards, that is pretty convincing stuff.

>You snipped my question about IPv6 path identities, how's
>that supposed to work ?  RfC 1036 says:

>| Letters, digits, periods and hyphens are considered part
>| of host names; other punctuation, including blanks, are
>| considered separators.

>One of the RfC 3513 formats is x:x:x:x:x:x:d.d.d.d, and
>that IPv6 is generally not the same as an IPv4 d.d.d.d

>> It was all in the old draft-13

Our draft makes it clear that ':' is henceforth to be part of the
path-identity and not a delimiter. Hence ap IPv6 address would appear as
...!x:x:x:x:x:x:d.d.d.d!...

If some ancient system misparses that as 7 successive path-identities,
then no harm will arise unless it is itself the system which owns that
IPv6 address, in which case it will fail to recognize itself in the Path,
but then has only itself to blame :-( .

>> I am waiting for Ken to move them into USEFOR

>Okay, let's wait for usefor-03 and an "official" usepro-02,
>I'd like to see the new msg-id and *WSP syntax.  Bye, Frank

I doubt Ken will want to adopt the *WSP syntax.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Wed, 02 Feb 2005 10:26:21 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 30
Sender: [email-masked]

Charles Lindsey wrote:

> There are examples in RFC 1036 of two <path-delimiter>s
> adjacent, so presumably it was intended to be OK.

I haven't found it looking for "!" or "path:".  If that's
the case it should be good enough for your ...!!... idea.

You snipped my question about IPv6 path identities, how's
that supposed to work ?  RfC 1036 says:

| Letters, digits, periods and hyphens are considered part
| of host names; other punctuation, including blanks, are
| considered separators.

One of the RfC 3513 formats is x:x:x:x:x:x:d.d.d.d, and
that IPv6 is generally not the same as an IPv4 d.d.d.d

> It was all in the old draft-13

That explains why you added ":", but not that it may not work
with the RfC 1036 idea of "punctuation".  We really need that
"THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED" note in
STD 10.

> I am waiting for Ken to move them into USEFOR

Okay, let's wait for usefor-03 and an "official" usepro-02,
I'd like to see the new msg-id and *WSP syntax.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: To do
Date: Wed, 02 Feb 2005 09:40:43 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Charles Lindsey wrote:

> should now be fixed

Thanks.

> http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt

Another vote for <unique@mdomain> instead of <id-left@id-right>
if I got this right... ;->  It even says that using IPs is now
(= 1998) obsolete, and it mentions the problem with dynamic IPs.

                          Bye, Frank