Subject: Re: #1008 USEFOR 1.5 "followup": summary so far
From: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Date: Wed, 1 Jun 2005 08:21:23 +0200
List-Id: <ietf-usefor.imc.org>

John Stanley:
> Richard Clayton:

>> I suspect (guessing here of course) that most of the people who went
>> for #2 would agree that readers often thread on Subject since that's
>> the reality -- but we'd all (another guess) would like to make it
>> far less necessary to do so
> 
> There is never a necessity to sort by Subject (not "thread", since
> Subject isn't a threadable header.). If it isn't ever necessary, we
> cannot make it "far less necessary".

To thread on Subject, doesn't mean that only the value of the 
Subject: header is used. Other information that can be used is 
the Date and the attributions (and further whatever the author 
of the news client chooses as feasible).

Threading on Subject, is also used to explain why some users see a 
new thread when others don't. In that case the change in Subject 
overrules the References.

-- 
Grtz, Ruud

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Differences between RFC 2822 and Usefor
Date:  Wed, 01 Jun 2005 02:00:25 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 119
Sender: [email-masked]

Charles Lindsey wrote:
 
>> As soon as Harald had enough fun with the References we're
>> IMHO ready to tackle the last details.

> No Way! There is a lot to be done yet

Not in USEFOR and from my POV.  The ticket system lists four
open tickets, two about the References.

> The WG has been in continuous existence since it was formed.
> It does not have "previous incarnations".

Here's what I consider as the end of a "previous incarnation":
<http://article.gmane.org/gmane.ietf.usenet.format/21194>

> when mail comes to its senses and decides not to have a line
> length limit in bodies anymore, "they" won't be able to say
> "you can't change that because it will break news".

Yes, the "they" listing Alexey, you, Claus, Dave, Harald, John,
John, Kai, Keith, Ned, Paul, Randy, and many many others. <eg>

Even yEnc 2002 didn't believe in lines longer than 998 char.s:
| <linevalue> :=
|        unsigned integer. (Range: 63-998)
|        // Lines have this size

> And if you look closely, s-o-1036 also had unlimited body
> lines (as a SHOULD).

Okay, the bible trumps a MUST in a proposed standard, and news
might support unencoded binaries <shudder />.

>> At the moment this isn't specified in USEFOR.
[...]
> I would like to see advice in USEFOR to treat the 998 limit
> in bodies with liberality.

We could add it in 2.3

| User agents MUST meet the definition of MIME-conformance in
| [RFC2049] and MUST also support [RFC2231].
................^^^^
Omigod, with a MUST it _is_ "normative" and a security risk :-(

It's the beauty of MIME that user agents not supporting it have
no serious problems.  That's USEAGE, not USEFOR, and a SHOULD,
not a MUST.  

Anyway, we could add unlimited body lines at the end of 2.3:

: Depending on the Content-Type and Content-Transfer-Encoding
: lines in the body may be limited to 998 or less characters,
: compare [RFC2045] 7bit and 8bit data.  Binary parts without
: "lines" MAY in fact allow arbitrary line lengths.  The body
: of a Netnews article MUST NOT be empty, note that one empty
: line is allowed.

> the world is moving, and we should not hold it back.

Depends on the direction.  Periods in the <display-name> could
be still used for a negative score, so it's not that bad.

>> My Subject;<sp><crlf><sp>tests failed miserably with two
>> news servers...

> If the injecting agent of your server rejected it, then that
> is quite proper.
[...]
>> "but SHOULD accept" weakens this simple and clear position.
 
> No, just liberality of acceptance, which is a well-established
> internet principle.

Now what, proper or liberal ?  In standards I'd prefer "clear".

> Read RFC 2822 again:
>|    The more conservative 78 character recommendation
[...]
I'm very happy with the 78 in 2822, let's just don't touch it
in USEFOR.

> It arises because the default width of terminals/windows/etc
> for editors, command interpreters, etc is usually 80
> characters (you can thank IBM for that), but you can't set
> the limit at 80 because too many such terminals/windows/etc
> have a habit of wrapping the line if column 80 is used

Yes, and if they are ported to a CRLF system they do strange
things in column 79, because 79 + CRLF is greater than 80.  No
argument with this, I rarely use columns 73..80, because that
is where I'm planning to punch the serial card number later ;-)

> we now have an IESG AD as our co-chair

IETF Chair emeritus.  But a MUST mentioning a proposed standard
is of course "normative", so we need "Security Considerations"
with a Caveat about the MIME boundary parameter.  What a mess.

>> (2) in Harald's list is perfectly compatible with 2822.
 
> It is compatible with RFC 2822, but imposes a stricter
> REQUIREMENT than RFC 2822.

A mere definition of "followup" is no REQUIREMENT.  We had the
discussion about "green => colour", after that you can't say
"green MUST be a colour".  And you also can't say that this is
a difference from "green => color" because of MUST and the "u".

> The differences from 1036 are currently detailed in USEPRO,
> though they should probably be moved to USEFOR at some
> convenient moment.

It would be convenient before this WG is closed, but if it's
in USEPRO it's fine.  Is there anything else for a usefor-05 ?

                      Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Misc. ABNF nits
Date:  Tue, 31 May 2005 23:44:57 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Henry Spencer wrote:
 
> Underscores were indeed in use in UUCP names... but there has
> also been some use of them in domain names, even though it is
> technically against the rules.

Only for "mailable FQDN".  Maybe the real problem is the MUST
in USEPRO and not the underline in USEFOR ?  I like this MUST,
but if we allow "unmailable" underlines we need a SHOULD.  Bye.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Differences between RFC 2822 and Usefor
Date:  Tue, 31 May 2005 23:13:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

Harald Tveit Alvestrand wrote:
 
> hey - where did that come from??????

Checking, oh, you're also listed as "guilty" in the credits.
Whereever it came from, I've ideas where it shouldn't go to.

>| In the future, period may appear in the regular syntax of
>| phrase.

New terminology part for "obs-":  obsolete, obscure, obscene, 
obstacle, obstinate, obstructive, obsession.  Admittedly I've
no software that crashes with these periods in a display name.
 
> Illustrates the danger of future-looking statements in
> standards that we're arguing based on this text 4 years
> later.....

Hiding this in "miscellaneous obsolete tokens" in the chapter
"obsolete syntax" is more odd than dangerous.  No showstopper
for USEFOR, we could just redefine the RfC 2822 display-name:

{2822]
| display-name    =       phrase
| phrase          =       1*word / obs-phrase
| obs-phrase      =       word *(word / "." / CFWS)

[USEFOR]
  display-name    =       word *(word / "." / CFWS)

This syntax would still disallow obscene keywords.  Bye, Frank

Date: Tue, 31 May 2005 17:17:39 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Misc. ABNF nits
Sender: [email-masked]

On Tue, 31 May 2005, Frank Ellermann wrote:
> Our copies of STD 10 and RfC 2821 are different, RfC 2821 says...
> No underline, straight back to STD 13 and STD 10.  If Henry had
> a good reason to allow it in s-o-1036 it's related UUCP, not to
> your "mailable FQDN" concept.

Underscores were indeed in use in UUCP names... but there has also been
some use of them in domain names, even though it is technically against
the rules. 

                                                          Henry Spencer
                                                       [email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Misc. ABNF nits
Date:  Tue, 31 May 2005 22:30:24 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Charles Lindsey wrote:

>> [email-masked] cannot work.  An under_line.test!...
>> path-identity is invalid, an ...!under_line.test tail-entry
>> is allowed.
 
> [email-masked] is syntactically allowed

Our copies of STD 10 and RfC 2821 are different, RfC 2821 says:

| Domain     = (sub-domain 1*("." sub-domain)) / address-literal
| sub-domain = Let-dig [Ldh-str]
| Let-dig    = ALPHA / DIGIT
| Ldh-str    = *( ALPHA / DIGIT / "-" ) Let-dig

No underline, straight back to STD 13 and STD 10.  If Henry had
a good reason to allow it in s-o-1036 it's related UUCP, not to
your "mailable FQDN" concept.
                             Bye, Frank

Date: Tue, 31 May 2005 11:25:58 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: #1008 USEFOR 1.5 "followup": summary so far
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>John, I have problems parsing your message - RFC 2822 does not use the 
>word "followup" anywhere, so it can't possibly have a definition for the 
>term that USEFOR can be in conflict with.

>Before drawing conclusions, I'd like to see if I have categorized people's 
>positions correctly. Comments?

What is really confusing about your mixmaster approach to this is that 
when you say:

1) All "followups" have a References: header.

I don't know if you mean "current standards say", "our draft says", "we 
want to say", or what. Clearly we don't think that all followups have a 
references header, or even apparently want to say that, since our work 
product clearly says otherwise. And just as clearly you aren't limiting 
the discussion to "what we think USEFOR ought to say", because you just 
asked me about something it CURRENTLY says.

Who said that USEFOR conflicts with RFC2822? Our draft clearly says that 
it DEFERS to RFC2822 for the definition of the References header, so it 
certainly does NOT conflict with RFC2822. 

As for RFC2822 not using the specific term "followup": been there, covered
that. It uses the generic term "replies". Every reply posted as news is a
"followup".  Every one. Each time someone replies, in a news context, they
are posting an article that is "a response to another". If you can find a
single person here who would call an article I post, in response to
another, which says "you are wrong when you say X because..." NOT a
followup, please trot them out. I don't believe they exist. And if they 
think it is not a reply, then they are clearly deluded.

Since EVERY reply is a followup (in newsland), and References is OPTIONAL
in replies, then it follows that References is optional in followups -- at
least that vast majority of followups that are "replies". I.e. those
posted 'in response to another article'. The only kind of followup that
isn't covered by RFC2822 is the kind that isn't a "reply". Perhaps one can
stretch things so that a second part of a FAQ isn't 'in response to' the
first part (even though it clearly IS 'as a result of'), so perhaps we can
say that References is mandatory in just 2nd etc. parts of a multi-part
FAQ, but to do so would be just stupid.

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>I suspect (guessing here of course) that most of the people who went for
>#2 would agree that readers often thread on Subject since that's the
>reality -- but we'd all (another guess) would like to make it far less
>necessary to do so

There is never a necessity to sort by Subject (not "thread", since Subject 
isn't a threadable header.). If it isn't ever necessary, we cannot make it 
"far less necessary".

"Forrest J. Cavalier III" <mibsoft@xxxxxxxxxxxxxxx>:

>There seems to be a consensus around your option #2, because people
>want to allow multi-parts to have references headers, but not call
>them followups. 

That's what I do not understand. People, today, treat them as followups
when they post them, but we* do not want to call them "followups" for some
unknown reason, even when it is trivial to modify the definition of
followup to include them, and by opening up References use to
non-followups we destroy the ability to detect followups altogether.

* for some subset of everyone here.

 kaih@xxxxxxxxxxxxxxxxx (Kai Henningsen):

> This is what I consider the ideal.

WHY is this ideal? Why is it ideal to remove the ability to detect 
followups? Why does there need to be a References header in something that 
isn't a followup?

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Actually, some people actually _prefer_ threading on Subject alone.

Subject is not a threadable header. There is no defined relationship 
between two articles with the same subject, only a similarity in the 
subject. E.g., "Subject: Re: Help" appearing in two different articles 
implies nothing about the similarity of parentage.

>And for every threading algorithm there exists a bunch of articles in the
>real world which it threads exceedingly badly :-( .

Except for the References header. Of course if you use non-threadable
headers you get poop for results. If you use References, you don't.  
Unless, of course, the References header is defective, but then, you said
"articles" and not "junkable non-articles", so I assume you meant
"articles" and not "non-articles".

To: [email-masked]
Xref: clerew local.usefor:20968
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Differences between RFC 2822 and Usefor
Date: Tue, 31 May 2005 14:34:58 GMT
Lines: 232
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>> What message are you replying to? It must be very ancient.

>2005-04-09 <http://mid.gmane.org/[email-masked]>

>As soon as Harald had enough fun with the References we're IMHO
>ready to tackle the last details.

No Way! There is a lot to be done yet, even to catch up with where the
draft-13 had left us.

>>>> However, all agents SHOULD, and relaying agents MUST,
>>>> process lines of arbitrary length.

>>> Never heard of this one.
> 
>> Decided by the WG right at the start. Such arbitrary limits
>> were seen as a Bad Thing, with no technical necessity
>> (clearly you need a 998 limit for headers).

>Some prior incarnation of the WG wanted a difference from 2822
>that's not allowed for SMTP ?

The WG has been in continuous existence since it was formed. It does not
have "previous incarnations".

>  But we want to replace Henry's
>message/news by message/rfc822 to forward news by mail, are
>"unlimited" body lines a feature of (I'm guessing) 8BITMIME ?

Quite possibly so in actual implementations. But, more importantly, all
known news transports can handle lines of arbitrary length (and the new
NNTP spec confirms that for NNTP). Yes, it seems that at least a lone CRLF
at the end of the article is required. We want to keep it that way so
that, when mail comes to its senses and decides not to have a line length
limit in bodies anymore, "they" won't be able to say "you can't change
that because it will break news".

And if you look closely, s-o-1036 also had unlimited body lines (as a
SHOULD).

>At the moment this isn't specified in USEFOR.

It was specified in draft-13, and I see that I made a note to myself to
fix it for Relaying agents in USEPRO, which I have now done by adding and
extra bulleted paragraph at the end of 7.3:

   Relaying agents MUST NOT alter, delete or rearrange any part of an
   article except for headers designated as variant (2.3).  In
   particular
............
     o they MUST transmit lines of arbitrary length and articles of
       arbitrary size.

(or they can always drop them on the floor if site policy so decides).

And I would like to see advice in USEFOR to treat the 998 limit in bodies
with liberality.

> [dot or comma in an unquoted "display-name"]
>> It is widely agreed that calling it "obs-" was a mistake,

>When s-o-1036 said 1994 that it's not allowed, then I strongly
>disagree with this assumption.

Read RFC 2822:
   Note: The "period" (or "full stop") character (".") in obs-phrase is
   not a form that was allowed in earlier versions of this or any other
   standard.  Period (nor any other character from specials) was not
   allowed in phrase because it introduced a parsing difficulty
   distinguishing between phrases and portions of an addr-spec (see
   section 4.4).  It appears here because the period character is
   currently used in many messages in the display-name portion of
   addresses, especially for initials in names, and therefore must be
   interpreted properly.  In the future, period may appear in the
   regular syntax of phrase.

That was written long after s-o-1036 was written. It is clearly the way
the world is moving, and we should not hold it back.

>> Bruce Lilly asked us to put it in (and for once he was right)

And it was put into draft-13 accordingly. It should go into USEFOR (but as
<extended-phrase>, not as <obs-phrase>, because that is now recognized as
having been a mistake).

>It's incompatible with s-o-1036.  And it would be the first
>exception from our "get rid of all obs-2822 stuff" strategy.

Not, it would be the second (because we have already accepted GMT and UT
in Dates).

>Nobody in the world cares about middle initials or abbreviated
>titles.  Let them quote their names or titles if they insist on
>it.

On the contrary, a lot of people care (myself included). Many user agents
allow it, and either pass it on as is, or automatically enclose it within
a quoted-string.

>If you'd modify <phrase> it would also affect the <keywords>,
>not only the <display-name>.  And the <display-name> is buried
>deep within pure 2822-territory.  The best way to fix this is
>in an 2822bis, not in an USEFOR <hacked-phrase>.

It is not for 2822bis, because it is already in 2822.

>>>> The content of the first line of a header MUST NOT consist
>>>> of WSP only (though such SHOULD be accepted).

>My Subject;<sp><crlf><sp>tests failed miserably with two news
>servers...  

If the injecting agent of your server rejected it, then that is quite
proper. I would be most upset if some relaying agent refused it if ever it
did manage to get past some injector.

>> Where does USEPRO say "MUST reject"?

> [7.2.2 (duties of an injecting agent) point 4]
>| It MUST reject any article that
>[...]
>| contains any header that does not have legal contents.

And quite right. Injecting agents are supposed to test articles for
standards conformity rather thoroughly.

>The real message of the text is that it's different from 2822.
>Any "but SHOULD accept" weakens this simple and clear position.

No, just liberality of acceptance, which is a well-established internet
principle.

>> The strange thing about the '78' in RFC 2822 is that not even
>> the author of the document could explain where that number
>> came from

>80-2 = 78, same idea as in 1000-2 = 998.  I have one of these
>ugly plain text viewers, where limit 79 won't work as expected.

Then your text viewer is broken, or is interpreting some rule too harshly.
Read RFC 2822 again:
   The more conservative 78 character recommendation is to accommodate
   the many implementations of user interfaces that display these
   messages which may truncate, or disastrously wrap, the display of
   more than 78 characters per line, in spite of the fact that such
   implementations are non-conformant to the intent of this
   specification (and that of [RFC2821] if they actually cause
   information to be lost). Again, even though this limitation is put on
   messages, it is encumbant upon implementations which display messages
   to handle an arbitrarily large number of characters in a line
   (certainly at least up to the 998 character limit) for the sake of
   robustness.

The reason for setting the (advisory) limit at 79 is nothing to do with
the number of characters in "CRLF". It arises because the default width of
terminals/windows/etc for editors, command interpreters, etc is usually 80
characters (you can thank IBM for that), but you can't set the limit at 80
because too many such terminals/windows/etc have a habit of wrapping the
line if column 80 is used, which leaves ugly blank lines in the displayed
text. Note that there is nothing inherently wrong with wrapping as a means
to avoid losing information, though horizontal scroll bars would be
preferable.

>> The WG decided long ago that any such limit was for purely
>> human convenience, and hence was for USEAGE.

>> Keywords is definitely different from RFC 2822.

>If your point 2.6 was only about the Keywords it's okay.  I've
>confused "in particular" with "for example".  Is that a bug in
>2822 ? 

Yes, I think it probably was.

 What's the idea of more than one Keywords header field
>instead of one long and possibly folded Keywords header ?

>>> is SHOULD NOT what we want ?
>> Some news software is known to break on empty bodies. That is
>> why the restriction is there.

>That's also why I asked, how about "MUST NOT" ?

It was SHOULD NOT in s-o-1036. I guess nobody ever asked for it to be
changed.

>> But it will be an uphill task to get any such proposal past
>> the IESG.

>If somebody in the IESG really considers listing 2231 "only" as
>"informative" as a blasphemy, then it's the person to discuss
>its status "proposed standard" and the two mentioned bugs with.

Well we now have an IESG AD as our co-chair, so he is in a better position
than either or us to declares whether it is blasphemous or not.
> 
>>> All followups have References by definition, no MUSTard, no
>>> essential differences from 2822.  JFTR as discussed elsewhere.

>> Whichever way it is defined in our documents, it is still a
>> difference from RFC 2822.

>Option (2) in Harald's list is perfectly compatible with 2822.

It is compatible with RFC 2822, but imposes a stricter REQUIREMENT than
RFC 2822. So it is a difference which has to be documented as such.

>That part is too long, it's the purpose of USEFOR to enumerate
>all differences.  Enumerating them twice is useless.  It would
>be more interesting to list differences from 1036 and s-o-1036.

The differences from 1036 are currently detailed in USEPRO, though they
should probably be moved to USEFOR at some convenient moment.

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

To: [email-masked]
Xref: clerew local.usefor:20967
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Misc. ABNF nits
Date: Tue, 31 May 2005 12:06:20 GMT
Lines: 66
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>> There is absolutely no point in making the syntax of the
>> tail-entry any different from the path-identity.

>The point is the semantical difference from a path-identity:

The only semantical difference with the tail-entry is that it is to be
disregarded by relaying agents which are trying to avoid sending the
article back to places that have already seen it. And, on looking at
USEPRO section 7.3, I see that that provision has got lost somewhere in
recent changes, so I have reworded it as follows:

   In order to avoid unnecessary relaying, an article SHOULD NOT be
   relayed if the <path-identity> of the receiving agent (or some known
   alias thereof) appears as a <path-identity> (excluding within the
   <tail-entry>) in its Path header.

NOTE to Ken:

For the removal of all doubt, please can we change the syntax un USEFOR
3.1.6 from

   path-identity   =  ( ALPHA / DIGIT )
                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
   ...
   tail-entry      =  path-identity

to

   path-identity   =  ( ALPHA / DIGIT )
                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
   ...
   tail-entry      =  ( ALPHA / DIGIT )
                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )

Or something else which makes it clear that the <tail-entry> does not have
a <path-identity> hidden inside it. I could then simplify my USEPRO
wording above slightly.

>> where you want to be able to stick 'news@' or 'usenet@'
>> or 'abuse@' in front of it and send mail to it.

>[email-masked] cannot work.  An under_line.test!...
>path-identity is invalid, an ...!under_line.test tail-entry
>is allowed.

[email-masked] is syntactically allowed, but there was text in 5.6.2
of the old-draft-13 to forbid it in the case of the injecting agent. That
text was included in my recent suggested text for the Path header, but
Alexey asked me to put it in USEPRO rather than USEFOR. It will shortly
appear in USEPRO.

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

Date: Mon, 30 May 2005 22:32:09 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Differences between RFC 2822 and Usefor
Sender: [email-masked]

--On 30. mai 2005 13:45 +0000 Charles Lindsey <[email-masked]> wrote:

>>> 1.8.2**The (mis-named) "obsolete" syntax for phrase from RFC
>>>      2822, which allows for 'John D. Smith' to remain
>>>      unquoted, is retained (but renamed as extended-phrase).
>
>> Sigh, is that still necessary ?  s-o-1036 didn't allow it 1994:
>
> It was a newly introduced "feature" of RFC 2822, on a MUST accept but do
> not generate yet basis. It is widely agreed that calling it "obs-" was a
> mistake, because it was very much intended for future use. Many agents
> accept it already. Bruce Lilly asked us to put it in (and for once he was
> right).

hey - where did that come from??????

the text in RFC 2822 section 4.1 is:

>    Note: The "period" (or "full stop") character (".") in obs-phrase is
>    not a form that was allowed in earlier versions of this or any other
>    standard.  Period (nor any other character from specials) was not
>    allowed in phrase because it introduced a parsing difficulty
>    distinguishing between phrases and portions of an addr-spec (see
>    section 4.4).  It appears here because the period character is
>    currently used in many messages in the display-name portion of
>    addresses, especially for initials in names, and therefore must be
>    interpreted properly.  In the future, period may appear in the
>    regular syntax of phrase.

The way I remember the discussions (after 4-10 years, I'm not that sure any 
more...), people observed that this period was used quite widely, so 
parsers that refused to handle it were not terribly useful, but the WG 
refused to recommend it as part of existing syntax.

Illustrates the danger of future-looking statements in standards that we're 
arguing based on this text 4 years later.....

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Differences between RFC 2822 and Usefor
Date:  Tue, 31 May 2005 00:46:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 169
Sender: [email-masked]

Charles Lindsey wrote:
 
> What message are you replying to? It must be very ancient.

2005-04-09 <http://mid.gmane.org/[email-masked]>

As soon as Harald had enough fun with the References we're IMHO
ready to tackle the last details.

>>> However, all agents SHOULD, and relaying agents MUST,
>>> process lines of arbitrary length.

>> Never heard of this one.
 
> Decided by the WG right at the start. Such arbitrary limits
> were seen as a Bad Thing, with no technical necessity
> (clearly you need a 998 limit for headers).

Some prior incarnation of the WG wanted a difference from 2822
that's not allowed for SMTP ?  But we want to replace Henry's
message/news by message/rfc822 to forward news by mail, are
"unlimited" body lines a feature of (I'm guessing) 8BITMIME ?

At the moment this isn't specified in USEFOR.  I'd prefer to
stay away from it if that's possible.  I know nothing about
binary groups, maybe it's not possible, but then we have to say
so in USEFOR.

 [dot or comma in an unquoted "display-name"]
> It is widely agreed that calling it "obs-" was a mistake,

When s-o-1036 said 1994 that it's not allowed, then I strongly
disagree with this assumption.

> Bruce Lilly asked us to put it in (and for once he was right)

It's incompatible with s-o-1036.  And it would be the first
exception from our "get rid of all obs-2822 stuff" strategy.

Nobody in the world cares about middle initials or abbreviated
titles.  Let them quote their names or titles if they insist on
it.

If you'd modify <phrase> it would also affect the <keywords>,
not only the <display-name>.  And the <display-name> is buried
deep within pure 2822-territory.  The best way to fix this is
in an 2822bis, not in an USEFOR <hacked-phrase>.

>>> The content of the first line of a header MUST NOT consist
>>> of WSP only (though such SHOULD be accepted).
[...]
>> I see no such "SHOULD", I see only a "MUST reject" in USEPRO

> I think it said "SHOULD accept" in the
> draft-ietf-usefor-article series of drafts.

My Subject;<sp><crlf><sp>tests failed miserably with two news
servers...  

> It is a matter of being liberal.

...I did't ask them for their political preferences, they just
rejected my test article.

> Where does USEPRO say "MUST reject"?

 [7.2.2 (duties of an injecting agent) point 4]
| It MUST reject any article that
[...]
| contains any header that does not have legal contents.

Only *WSP after the colon is illegal.  Confirmed by two tests,
whatever that means.  It's confusing if the syntax and tons of
text try to establish some "MUST NOT create but SHOULD accept"
rules, where a simple "don't" is much clearer and good enough.

The real message of the text is that it's different from 2822.
Any "but SHOULD accept" weakens this simple and clear position.

> The strange thing about the '78' in RFC 2822 is that not even
> the author of the document could explain where that number
> came from

80-2 = 78, same idea as in 1000-2 = 998.  I have one of these
ugly plain text viewers, where limit 79 won't work as expected.

> The WG decided long ago that any such limit was for purely
> human convenience, and hence was for USEAGE.

Sure. let's just inherit whatever 2822 or a future 2922bis say,
and not invent our own "better" rules in USEFOR.  This should
be no difference from 2822.

> Keywords is definitely different from RFC 2822.

If your point 2.6 was only about the Keywords it's okay.  I've
confused "in particular" with "for example".  Is that a bug in
2822 ?  What's the idea of more than one Keywords header field
instead of one long and possibly folded Keywords header ?

>> is SHOULD NOT what we want ?
> Some news software is known to break on empty bodies. That is
> why the restriction is there.

That's also why I asked, how about "MUST NOT" ?

 [2331] 
> Agreed, but politically incorrect :-(

Security consideration trumps political correctness.

>> Just move RfC 2231 to the "informative references"
>> section, it will never be a "draft standard",
 
> If you are serious, then you should start a new thread to
> discuss this.

We already had this discussion with Bruce and Ned, and IIRC we
agreed that it can't be fixed by two "2231 errata" like these:

1st - kids, don't try this with a boundary parameter
2nd - BTW, this means all MIME paramters are unique

The second "bug" is only an undocumented "feature", submitting
it as an error would be dubious.  It's incompatible with legal
interpretations of 2045 / 2049.  Not our problem as long as we
stick to the 2331-idea of unique parameters. 
 
> But it will be an uphill task to get any such proposal past
> the IESG.

If somebody in the IESG really considers listing 2231 "only" as
"informative" as a blasphemy, then it's the person to discuss
its status "proposed standard" and the two mentioned bugs with.
 
>> All followups have References by definition, no MUSTard, no
>> essential differences from 2822.  JFTR as discussed elsewhere.

> Whichever way it is defined in our documents, it is still a
> difference from RFC 2822.

Option (2) in Harald's list is perfectly compatible with 2822.

I read most mail lists as newsgroups on GMaNe.  GMaNe has some
magic for the Message-IDs / Newsgroups, but it has absolutely 
nothing to do for the References.  My UA just does the same
thing for mail replies and news followups, it even allows me
to do both at the same time.  Okay, my UA is older than 2822.

The threading is identical in all newsgroups and mail folders.
There's just no difference from 2822 for the References header.

> You never "need" helpful explanatory material in Appendices

That part is too long, it's the purpose of USEFOR to enumerate
all differences.  Enumerating them twice is useless.  It would
be more interesting to list differences from 1036 and s-o-1036.

 [collected ABNF]
> Mere corroborative detail, to give artictic verisimilitude
> to an otherwise bald and unconvincing narrative :-)

Found it, <http://www.quotationspage.com/quote/29432.html>
I'm lost with "quote unquote".  It's only a few years since a
serious error in a German translation convinced to prefer the
originals, another part of this equation was of course amazon.

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Misc. ABNF nits
Date:  Mon, 30 May 2005 21:44:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 41
Sender: [email-masked]

Charles Lindsey wrote:
 
> There is absolutely no point in making the syntax of the
> tail-entry any different from the path-identity.

The point is the semantical difference from a path-identity:

> where you want to be able to stick 'news@' or 'usenet@'
> or 'abuse@' in front of it and send mail to it.

[email-masked] cannot work.  An under_line.test!...
path-identity is invalid, an ...!under_line.test tail-entry
is allowed.

>> IIRC it's @4ax.net or similar, and not a random id-domain.
> it's about as random as they come

Not the id-domain, only the id-local is a random value.  It's
4ax.com, not 4ax.net.

> none of whom has any agreement with any other for the
> purpose of avoiding duplicate message-ids.

4ax.com was especially registered for this purpose.  If they
have a problem with this scheme it's "their" problem, they
don't abuse foreign name spaces:

whois -h whois.networksolutions.com 4ax.com

Registrant:
Forte Internet Software, Inc.
[...]

It's of course still an obscure idea, an attacker could try
to generate numerous [email-masked] Message-IDs.  But the
domain has an owner, this owner has the right to say "abuse".

For [email-masked] there would be no owner, and invalid
Message-IDs are fair game.
                             Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20962
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Differences between RFC 2822 and Usefor
Date: Mon, 30 May 2005 13:45:09 GMT
Lines: 185
Sender: [email-masked]

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

>Charles Lindsey wrote:

What message are you replying to? It must be very ancient.

>> 1.5**Body lines are restricted to 998 characters plus CRLF

>Inherited from 2045 and 2822.  No difference => delete.

>> However, all agents SHOULD, and relaying agents MUST, process
>> lines of arbitrary length.

>Never heard of this one.

Decided by the WG right at the start. Such arbitrary limits were seen as
a Bad Thing, with no technical necessity (clearly you need a 998 limit for
headers).

>> 1.8.2**The (mis-named) "obsolete" syntax for phrase from RFC
>>      2822, which allows for 'John D. Smith' to remain
>>      unquoted, is retained (but renamed as extended-phrase).

>Sigh, is that still necessary ?  s-o-1036 didn't allow it 1994:

It was a newly introduced "feature" of RFC 2822, on a MUST accept but do
not generate yet basis. It is widely agreed that calling it "obs-" was a
mistake, because it was very much intended for future use. Many agents
accept it already. Bruce Lilly asked us to put it in (and for once he was
right).

>In other words s-o-1036 says "delete whatever extended-phrase".

>> 2.1.2**Extended-phrases (see 1.8.2 above).

>See-Also: <[email-masked]>

>> 2.2  The content of the first line of a header MUST NOT consist of WSP
>>      only (though such SHOULD be accepted). Observe that continuation
>>      lines of headers also MUST NOT consist of WSP only, as in RFC 2822.

Ah! I see now what you are quoting from. It is the list of differences
from RFC 2822, which you will find on www.imc.org/usefor.

>I see no such "SHOULD", I see only a "MUST reject" in USEPRO.

I think it said "SHOULD accept" in the draft-ietf-usefor-article series of
drafts. It is a matter of being liberal. Where does USEPRO say "MUST
reject"? "MUST NOT generate", maybe.

>> 2.3  Headers with empty content are deprecated (but if
>>      present that SP after the ':" is still required).

>They are _verboten_ by MUSTard everywhere.  And that's good.

"Deprecate" is a polite way of saying "MUST NOT" in some people's
vocabulary :-) .

>> 2.4  All agents MUST support header lines up to 998 octets,
>>      but there is no RECOMENDED limit of 78 characters as in
>>      RFC 2822.

>I found neither 78 nor 79 in USEPRO (except from the BCPs ;-)
>There's nothing wrong with the 78 in RfC 2822.

The strange thing about the '78' in RFC 2822 is that not even the author
of the document could explain where that number came from (I know exactly
where '79' comes from). The WG decided long ago that any such limit was
for purely human convenience, and hence was for USEAGE. It is certainly
verboten for later agents to modify any header in transit just for that
reason.

>> There is mention of a purely advisory limit of 79 (with a
>> reference to USEAGE).

>79 + CRLF causes odd effects with some *NIX software ported to
>other operating systems (they "think" that it's more than 80
>for a critical nanosecond).  The 78 in RfC 2822 is just fine.

Never heard that argument before. But it's still a USEAGE matter.

>> 2.6  There must not be more than one header with a given
>>      header-name, except where explicitly sanctioned by the
>>      appropriate standard. In particular, there MUST NOT be
>>      more than one Keywords-header.

>That's a difference from 2822, e.g. more than one Message-ID ?
>Should we move RfC 2822 to "historic" while we are at it ?

Eh? Keywords is definitely different from RFC 2822. The rest of the
headers are the same.

>> 2.8**The body of an article SHOULD NOT be empty.

>s-0-1036 apparently allows for an "almost emtpy" body as in
>last-header-field: content<CRLF><CRLF><CRLF>

Exactly. "almost empty" is not "empty". We agree with s-o-1036.

>RfC 2822 removed the third <CRLF>, is SHOULD NOT what we want ?

Some news software is known to break on empty bodies. That is why the
restriction is there.

>> 2.9  (was 1.6) RFC 2047 and RFC 2231 are fully integrated
>>      into the Netnews.

>RfC 2231 should not be integrated into anything with less than
>ten pages of "security considerations" about boundary= values.

Agreed, but politically incorrect :-( .

>We only need it for some params, and not implementing RfC 2231
>is a RECOMMENDED best common practice in my parallel universe.

>2822 is silent about 2231, let's stick to this excellent plan.
>"Full integration of 2231" is a recipe for havoc.

>We have no business to "fully integrate" an eight years old
>"proposed standard", that is known to be potentially harmful,
>and that introduced obscure restrictions for MIME parameters.

>Just move RfC 2231 to the "informative references" section, it
>will never be a "draft standard", let alone a "full standard".

If you are serious, then you should start a new thread to discuss this.
But it will be an uphill task to get any such proposal past the IESG.
Unless Harald can tell us otherwise.

>As long as we are compatible with this beast it's good enough.

>> 2.11 A References header MUST be provided for followups (as
>>      opposed to SHOULD be provided for replies in RFC 2822).

>All followups have References by definition, no MUSTard, no
>essential differences from 2822.  JFTR as discussed elsewhere.

Whichever way it is defined in our documents, it is still a difference
from RFC 2822.

>> 3.2  Comments (but not FWS) are forbidden in the Newsgroups-,
>>      Distribution- Path- and Followup-To-headers (also see
>>      1.11.1 above for Message-ID).

>As expected USEFOR is somewhat different from RfC 2822, in fact
>the _complete_ text is about differences.  Therefore we don't
>need this long list repeating almost all points of the text in
>an appendix.

You never "need" helpful explanatory material in Appendices, but it is an
excellent way or preventing people from misunderstanding your document.

>> 3.3**WSP and folding in Newsgroup- and Followup-To-headers
>>      MUST be accepted, but SHOULD NOT be generated (yet).

>After 11 years of a warning in s-o-1036 ?  Maybe we should
>also say something about the components "all" or "ctl"... :-(
>But not in USEFOR please.

Yes. INN has only implemented that feature within the last 12 months
AFAIK, and I don't know of any other server that accepts it yet.

>3.2 and 3.3 are no real _differences_ from RfC 2822, they are
>just ordinary news header fields normally not found in mail =>
>also not in 2822.  It's obvious as far as I'm concerned.

Yes, they are actually differences from RFC 1036 if anything, and should
probably be described as such.

>But a "collected ABNF" appendix could be very nice.

Mere corroborative detail, to give artictic verisimilitude to an otherwise
bald and unconvincing narrative :-) .

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

To: [email-masked]
Xref: clerew local.usefor:20961
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Misc. ABNF nits (was: I-D ACTION:draft-ietf-usefor-usefor-04.txt)
Date: Mon, 30 May 2005 12:58:29 GMT
Lines: 47
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
> [USEPRO and underlines in a mailable path-identity]
>> it will be covered.

>Is this oddity reserved for a tail-entry ?  Then we could also
>fix it in USEFOR:

>| path-identity = ( ALPHA / DIGIT )
>|                 *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
>| tail-entry    =  path-identity

>  path-identity = ( ALPHA / DIGIT ) *path-char
>  tail-entry    = ( ALPHA / DIGIT ) *( path-char / "_" )
>  path-char     = ( ALPHA / DIGIT / "-" / "." / ":" )

There is absolutely no point in making the syntax of the tail-entry any
different from the path-identity. It plays no formal part in the
protocols. It just sits there, and if people like to write nice things in
there (e.g. their userid), then let them.

Note that "mailable path-identity" refers, especially, to the
path-identity inserted by the injecting agent, where you want to be able
to stick 'news@' or 'usenet@' or 'abuse@' in front of it and send mail to
it.

>> Agent seems to get away with that technique

>IIRC it's @4ax.net or similar, and not a random id-domain.

it's about as random as they come, given that it is used by maybe 100,000
sites worldwide, none of whom has any agreement with any other for the
purpose of avoiding duplicate message-ids. But it ain't broks ...

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

To: [email-masked]
Xref: clerew local.usefor:20963
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1008 USEFOR 1.5 "followup": summary so far
Date: Mon, 30 May 2005 13:51:11 GMT
Lines: 32
Sender: [email-masked]

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

>In message <[email-masked]>,
>Harald Tveit Alvestrand <[email-masked]> writes

>>- Ruud H.G. van Tol: "Since readers can often also thread on Subject..."

>I suspect (guessing here of course) that most of the people who went for
>#2 would agree that readers often thread on Subject since that's the
>reality -- but we'd all (another guess) would like to make it far less
>necessary to do so

Actually, some people actually _prefer_ threading on Subject alone. But it
is a matter for user agent implementors to argue out with their customers,
or prefereably to provide configurable options.

The very best threading algorithms (e.g. Zawinski's algorithm) take note of
all of References, Subject and Date.

And for every threading algorithm there exists a bunch of articles in the
real world which it threads exceedingly badly :-( .

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

Date: Mon, 30 May 2005 19:31:14 +0100 (BST)
To: [email-masked]
Xref: clerew local.usefor:20964
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1008 USEFOR 1.5 "followup": summary so far
Sender: [email-masked]

<[email-masked]>
Date: Mon, 30 May 2005 13:56:09 GMT
Lines: 30
MIME-Version: 1.0

In <[email-masked]> "Forrest J. Cavalier III"
<[email-masked]> writes:

>There seems to be a consensus around your option #2, because people
>want to allow multi-parts to have references headers, but not call
>them followups.

>Well, perhaps someone can show me where the current documents (usefor
>or Rfc2822) indicate the use of a References header for things
>that are not "followups" as defined in usefor-04.  I believe they
>do not, so option #2 is still objectionable.

What we are discussing is a _change_ from the previous standards (which,
by our charter, we are allowed to do).

Unlike many other changes from previous standards, it has two interesting
properties:

1. It is already in current use.
2. It requires NO change in any existing software.

-- 
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: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: he
Date: Mon, 30 May 2005 10:51:50 +0200
Organization: Chaos rules.
Sender: [email-masked]

Kai Henningsen schreef:
> Harald Tveit Alvestrand:

>> 2) All "followups" have a References: header.
>>    There exist articles that have References:, but are not
>> "followups" 
> 
> This is what I consider the ideal.
> 
>> 4) There exist "followups" with no References: header.
>>    There exist articles that have References:, but are not
>> "followups" 

> This would be a description of the imperfect current real world,
> though I'd argue that the difference is mainly broken software 
> (and a little bit of broken behaviour by users) - that is, those 
> followups without references really ought to have had references, 
> all of them, without exception, no matter how they managed to not 
> have them.

The main difference I see between my position and Kai's is the 
interpretation of the term 'followup'. I take it not only as 
'response' but also more general, as 'successor, result, coming 
after, follower'. In my world, anything with a (proper) References: 
header can be called a followup, because something or somebody did 
the effort to define a (n often ordering) relationship.

-- 
Grtz, Ruud

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Differences between RFC 2822 and Usefor
Date:  Sun, 29 May 2005 19:08:33 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 134
Sender: [email-masked]

Charles Lindsey wrote:

> 1.1  There is a REQUIRED SP (not even WSP) after the ':' in
>      each header (even if the header has no content).

Empty content is _verboten_ by the second bullet in 2.2.  The
worst legal case is NO-WS-CTL.  The worst practical case is an
empty Bcc: hitting a mail2news gateway (USEPRO 7.2.2 step four
"MUST reject" etc.)

> 1.5**Body lines are restricted to 998 characters plus CRLF

Inherited from 2045 and 2822.  No difference => delete.

> However, all agents SHOULD, and relaying agents MUST, process
> lines of arbitrary length.

Never heard of this one.

> 1.8.2**The (mis-named) "obsolete" syntax for phrase from RFC
>      2822, which allows for 'John D. Smith' to remain
>      unquoted, is retained (but renamed as extended-phrase).

Sigh, is that still necessary ?  s-o-1036 didn't allow it 1994:

| unquoted-char = <ASCII printable character except !()<>@,;:\".[]>

| NOTE: Also, the characters "." and ",", not infre-
| quently  found  in names (e.g., "John W. Campbell,
| Jr."), are NOT, repeat NOT, allowed in an unquoted
| word.   A  From header like the following MUST not
| be written without the quotation marks:
|
| From: "John W. Campbell, Jr." <[email-masked]>

In other words s-o-1036 says "delete whatever extended-phrase".

> 2.1.2**Extended-phrases (see 1.8.2 above).

See-Also: <[email-masked]>

> 2.2  The content of the first line of a header MUST NOT consist of WSP
>      only (though such SHOULD be accepted). Observe that continuation
>      lines of headers also MUST NOT consist of WSP only, as in RFC 2822.

I see no such "SHOULD", I see only a "MUST reject" in USEPRO.

> 2.3  Headers with empty content are deprecated (but if
>      present that SP after the ':" is still required).

They are _verboten_ by MUSTard everywhere.  And that's good.

> 2.4  All agents MUST support header lines up to 998 octets,
>      but there is no RECOMENDED limit of 78 characters as in
>      RFC 2822.

I found neither 78 nor 79 in USEPRO (except from the BCPs ;-)
There's nothing wrong with the 78 in RfC 2822.

> There is mention of a purely advisory limit of 79 (with a
> reference to USEAGE).

79 + CRLF causes odd effects with some *NIX software ported to
other operating systems (they "think" that it's more than 80
for a critical nanosecond).  The 78 in RfC 2822 is just fine.

> 2.6  There must not be more than one header with a given
>      header-name, except where explicitly sanctioned by the
>      appropriate standard. In particular, there MUST NOT be
>      more than one Keywords-header.

That's a difference from 2822, e.g. more than one Message-ID ?
Should we move RfC 2822 to "historic" while we are at it ?

> 2.8**The body of an article SHOULD NOT be empty.

s-0-1036 apparently allows for an "almost emtpy" body as in
last-header-field: content<CRLF><CRLF><CRLF>

RfC 2822 removed the third <CRLF>, is SHOULD NOT what we want ?

> 2.9  (was 1.6) RFC 2047 and RFC 2231 are fully integrated
>      into the Netnews.

RfC 2231 should not be integrated into anything with less than
ten pages of "security considerations" about boundary= values.

We only need it for some params, and not implementing RfC 2231
is a RECOMMENDED best common practice in my parallel universe.

2822 is silent about 2231, let's stick to this excellent plan.
"Full integration of 2231" is a recipe for havoc.

We have no business to "fully integrate" an eight years old
"proposed standard", that is known to be potentially harmful,
and that introduced obscure restrictions for MIME parameters.

Just move RfC 2231 to the "informative references" section, it
will never be a "draft standard", let alone a "full standard".

As long as we are compatible with this beast it's good enough.

> 2.11 A References header MUST be provided for followups (as
>      opposed to SHOULD be provided for replies in RFC 2822).

All followups have References by definition, no MUSTard, no
essential differences from 2822.  JFTR as discussed elsewhere.

> 3.2  Comments (but not FWS) are forbidden in the Newsgroups-,
>      Distribution- Path- and Followup-To-headers (also see
>      1.11.1 above for Message-ID).

As expected USEFOR is somewhat different from RfC 2822, in fact
the _complete_ text is about differences.  Therefore we don't
need this long list repeating almost all points of the text in
an appendix.

> 3.3**WSP and folding in Newsgroup- and Followup-To-headers
>      MUST be accepted, but SHOULD NOT be generated (yet).

After 11 years of a warning in s-o-1036 ?  Maybe we should
also say something about the components "all" or "ctl"... :-(
But not in USEFOR please.

3.2 and 3.3 are no real _differences_ from RfC 2822, they are
just ordinary news header fields normally not found in mail =>
also not in 2822.  It's obvious as far as I'm concerned.

Or did you add all differences from 2822 plus differences from
s-o-1036 ?  It's good to have / read / maintain this long list,
but adding it to the draft is IMHO dubious.

But a "collected ABNF" appendix could be very nice.  Bye, Frank

Date: 29 May 2005 14:45:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: he
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Harald Tveit Alvestrand)  wrote on 26.05.05 in <[email-masked]>:

> 2) All "followups" have a References: header.
>    There exist articles that have References:, but are not "followups"

This is what I consider the ideal.

> 4) There exist "followups" with no References: header.
>    There exist articles that have References:, but are not "followups"

This would be a description of the imperfect current real world, though  
I'd argue that the difference is mainly broken software (and a little bit  
of broken behaviour by users) - that is, those followups without  
references really ought to have had references, all of them, without  
exception, no matter how they managed to not have them.

Which means the document(s) should use (2).

Which also means that "followup" is not something one should look at on  
the wire, or in a reading agent. It describes what users do, and can be  
used to describe how a posting agent should behave when a user wishes to  
create a followup.

Apart from this, only users reading the results should even acknowledge  
the difference between a followup and another article with References:.

On the other hand, the rules for handling References: are all derived from  
the concept of a followup - that is, they are all meant to be optimal for  
followups. Followups, in other words, are what drives the requirements  
here, and other Reference:-carrying articles just take advantage of the  
results.

I hope this makes it clear what I would like the docs to achieve.

MfG Kai

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Misc. ABNF nits (was: I-D ACTION:draft-ietf-usefor-usefor-04.txt)
Date:  Sun, 29 May 2005 15:42:35 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 63
Sender: [email-masked]

Charles Lindsey wrote:
 
> I don't think we should be scared of Bruce's review tool.

Let's agree to disagree about this point, if I'd see a...

      [x] Incompatible with the Internet Architecture

...I want to be very sure that it's only about the NO-WS-CTL
in a msg-id, or maybe some cases of [FWS] which MUST be *WSP.

In the latter case I'd better stay away from defending [FWS],
because "this is only for visual similarity with [CFWS] in
RfC 2822, of course we mean *WSP" isn't very convincing.  <eg>

> it is marvellous what can be achieved if hundreds of people
> warn you and quote the standard against you.

Yes, I just have similar arguments on the SPF list.  In one
case I tried to defend a "prefix" production in the syntax,
because that's simply as it always was.  (Ouch)

But the opponent convinced me that the names of terms should
reflect the semantical role (in that case "sign", "qualifier",
"result", or similar) and not the syntactical role "prefix".

Thinking about "id-right" vs. "id-domain" I surrendered.  And
the "prefix" will be replaced in the next SPF draft.

 [USEPRO and underlines in a mailable path-identity]
> it will be covered.

Is this oddity reserved for a tail-entry ?  Then we could also
fix it in USEFOR:

| path-identity = ( ALPHA / DIGIT )
|                 *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
| tail-entry    =  path-identity

  path-identity = ( ALPHA / DIGIT ) *path-char
  tail-entry    = ( ALPHA / DIGIT ) *( path-char / "_" )
  path-char     = ( ALPHA / DIGIT / "-" / "." / ":" )

Now I tried to check this in a 13 years old Grizzly book, but
when I found something about "up to six lower case letters"
it was getting a bit too old-fashioned for my tastes today :-(

Apparently the NNTPext folks expect us to do "the right thing",
whatever that migt be.  And s-o-1036 said "underline is okay".

 [id-domain] 
> As always, he who generates the msg-id takes responsibility
> for its uniqueness. In that particular example, if all those
> characters are chosen randomly the odds against an unintended
> match are astronomical

That's clear.  But the costs/effects of unintended or intended
collisions are hard to predict.

> Agent seems to get away with that technique

IIRC it's @4ax.net or similar, and not a random id-domain.  Bye

Date: Fri, 27 May 2005 16:05:56 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1008 USEFOR 1.5 "followup": summary so far
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> Forrest, I failed to see what you would want instead of the alternatives 
> proposed. Could you clarify?

I want something that is unambiguous for generating and interpreting
articles that includes and does not obsolete wide-spread existing useful
practice and uses RFC2119 language only when called for.

That goes for every part of this document, not just the References:
header.  It seems to me that is the MINIMUM standard of acceptability
of a proposed specification for protocols, software, or data formats.

There seems to be a consensus around your option #2, because people
want to allow multi-parts to have references headers, but not call
them followups.

Well, perhaps someone can show me where the current documents (usefor
or Rfc2822) indicate the use of a References header for things
that are not "followups" as defined in usefor-04.  I believe they
do not, so option #2 is still objectionable.

Date: Fri, 27 May 2005 19:50:28 +0100
To: Harald Tveit Alvestrand <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1008 USEFOR 1.5 "followup": summary so far
Sender: [email-masked]

In message <[email-masked]>,
Harald Tveit Alvestrand <[email-masked]> writes

>As far as I can tell:
>
>3) There exist "followups" with no References: header.
>  All articles with References: headers are "followups".
>
>- Ruud H.G. van Tol: "Since readers can often also thread on Subject..."

I suspect (guessing here of course) that most of the people who went for
#2 would agree that readers often thread on Subject since that's the
reality -- but we'd all (another guess) would like to make it far less
necessary to do so

The problem is that there were once broken clients that didn't bother
with References (better perhaps than the ones that got them the wrong
way around!) and so it was essential to cope with articles that arrived
like that. Hence one wrote software that threaded on Subject (or indeed
by examining the body for "In message <> fred wrote" info, didn't tin do
that?). If one was very clever one even ensured that one threaded on
"most" of a Subject because some clients truncated them after 80
characters :(  For this, BTW (another tediously long discussion here) a
key heuristic was to look for a Subject that started with  "Re:"  :)

My memory (and we're going back to 1993 or so here, so it may be faulty)
is that AOL's software was the main offender here. Of course they fixed
it long ago, but software-memory doesn't really deal with change !

However, just because we used to have to thread on Subject doesn't mean
that we wouldn't like to throw this code away in the future -- and
unless there's crystal clear instructions about how it absolutely
essential to put in References: then the minimalists (and the people who
think you can write full-function Usenet clients in JavaScript and all
sorts of other nuisances) will fail to put them in. guaranteed.  And
that's going to mess up thread display for everyone else. Won't break
the servers, won't stop the articles being on the screen, WILL stop them
being at the right place in the conversation.

So I'd suggest that if you consider "what sort of broken-ness do people
put up with today" then you can get almost everyone to endorse every
position.... but I didn't think that was the question and that's why I
plumped for #2.  It's how the world ought to be :)

>Before drawing conclusions, I'd like to see if I have categorized people's 
>positions correctly. Comments?

apologies for the length, rushed as ever and no time to trim :(

- -- 
richard                                              Richard Clayton

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

Date: Fri, 27 May 2005 19:57:51 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1008 USEFOR 1.5 "followup": summary so far
Sender: [email-masked]

With the set of alternatives I presented, I thought I'd covered the space 
of possible relationships between the term "followup" as defined in 
USEFOR-04 and the References: header. But since 2 people disagreed with the 
question, it seems I did not.

As far as I can tell:

1) All "followups" have a References: header.
   All articles with References: header are "followups".
- Eivind Tagseth: "Because I view... multi-part..special type of followup"

2) All "followups" have a References: header.
   There exist articles that have References:, but are not "followups"
- Henry Spencer: "Existing practice"
- Richard Clayton: "captures my perception of useful current practice"
- Seth Breidbarth: "current reality"
- Russ Albery: "but would be content with 1)"
- Frank Ellermann

3) There exist "followups" with no References: header.
   All articles with References: headers are "followups".

- Ruud H.G. van Tol: "Since readers can often also thread on Subject..."

4) There exist "followups" with no References: header.
   There exist articles that have References:, but are not "followups"

Disagreed with the set of alternatives:

- Forrest J. Cavalier III (2 is ambiguous, 3 and 4 specify nothing)
- John Stanley (discusses relationship with 2822)

This is 9 responses so far.

John, I have problems parsing your message - RFC 2822 does not use the word 
"followup" anywhere, so it can't possibly have a definition for the term 
that USEFOR can be in conflict with.

Forrest, I failed to see what you would want instead of the alternatives 
proposed. Could you clarify?

Before drawing conclusions, I'd like to see if I have categorized people's 
positions correctly. Comments?

                         Harald

To: [email-masked]
Xref: clerew local.usefor:20951
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-usefor-usefor-04.txt
Date: Fri, 27 May 2005 14:15:58 GMT
Lines: 70
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>>> Is deprecating X- headers allowed ?
> 
>> I don't see why not, if you are providing a standard header
>> to fulfil the same role.

>Examples could include "X-NoArchive: yes, (c) 2005 by xyzzy"
>or "X-ComplaintsTo: not me".  The "same role" is unclear for
>X- header fields.  

>Not an important point, but if it helps to avoid a warning
>from Bruce's review tool I'd just delete the last statement
>"These headers are thus deprecated." - the intended effect of
>the complainto-param is obvious without it.

I don't think we should be scared of Bruce's review tool. If there is some
earlier usage that we want to discourage/deprecate/whatever, then we
should say so. We can't prevent people from doing it, of course, but it is
marvellous what can be achieved if hundreds of people warn you and quote
the standard against you.

We should all be top posting now if it wern't for all the flame wars
against it :-) .

>>> "FQDN mailable" path-identity with "_" is dubious.
> 
>> But not all path-identities need to be mailable.

>It's not exactly obvious to find this subtlety in Usepro-03,
>where you say "MUST" for all _added_ path-identities.  Or in
>other words, either something outside of (before ?) Usepro-03
>could preload the path with underline-path-identities, or the
>underline is only relevant for the tail-entry.

There is text in my Path-suggested-text document that explains all this. I
had intended that text for USEFOR, but Alexey has asked me to put it in
USEPRO (and that is actually top of my list of things to do). So it will
be covered.

>> you have raised all these before, but nobody supported you
>> and our Chair said to leave it be.

>Sure, Harald doesn't know this part of "the making of msg-id",
>unless he read our rather long thread(s) about it.

>The <527065CFBE71B58750EA0678@B50854F0A9192E8EC6CDA126> wasn't
>only a joke, it illustrates a point:  B50854F0A9192E8EC6CDA126
>is only syntactically an id-domain, not semantically, and it's
>unclear who tries to guarantee the uniqueness of this msg-id.

As always, he who generates the msg-id takes responsibility for its
uniqueness. In that particular example, if all those characters are chosen
randomly the odds against an unintended match are astronomical (more than
astronomical, I should think - how many particles are there in the
universe?). I could live with that, and Agent seems to get away with that
technique using a much shorter field.

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

To: [email-masked]
Xref: clerew local.usefor:20952
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Date: Fri, 27 May 2005 14:22:46 GMT
Lines: 33
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

> A "followup" is an article containing a response to the contents of
> an earlier article (the followup's "precursor" indicated in the
> "References" header).

Given that definition (which to me indicates that a multi-part FAQ does
not involve "followups"),

Then the position I support is:

>2) All "followups" have a References: header.
>   There exist articles that have References:, but are not "followups"

Note that a recipient UA cannot tell whether an article it receives, which
contains a References header, is a "followup" or not (a human could surely
tell from the context and content, or course).

Therefore I expect the UA to do whatever threading it normally does based
on the presence and contents of the References, whether it is really a
"followup" or not.

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

To: [email-masked]
Xref: clerew local.usefor:20953
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Date: Fri, 27 May 2005 14:29:19 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>I think we get the proper effect of John's (5) with something like:

>    "Users generally expect User Agents to treat articles with a
>    References: header as followups."

USEPRO 7.7 currently contains:

   [A reading agent] MAY present lists of articles available for display,
   and MAY structure those lists so as to show the relationships between
   the articles, as determined by the References, Subject, Date and other
   headers (see [USEAGE] for some usual methods of doing this).

which comes close to what you are suggesting.

It also makes it clear that References, Subject and Date header have to be
constructed correctly in order for reading agents to do the "right thing"
with them.

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

Date: Thu, 26 May 2005 23:26:06 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Sender: [email-masked]

> (5) would require some justification, which I'm hopeful someone comes up
> with, because I'd like to see References continue its useful life. We were 
> well along slipping the mandate in as historical, but since we've removed 
> it, it's going to take a good reason to put back.

I don't see a justification for MUST/MUST NOT language, either (or even
any RFC2119 SHOULDs, for that matter.)

I think we get the proper effect of John's (5) with something like:

    "Users generally expect User Agents to treat articles with a
    References: header as followups."

or
    A References header indicates the previously posted context in which
    the article was created.

These two wordings do not mandate any behavior, but make it crystal
clear that including or omitting the References: header is going to have
an effect.

The document is just words.  As an implementor, I'd rather have
clarity than a complex conjunction with RFC2119 mandates for
no justifiable reason.

Date: Thu, 26 May 2005 17:51:35 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: #1008 USEFOR 1.5: relation between a followup and a References: header?
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

> ... what USEFOR should say about this issue:

>1) All "followups" have a References: header.
>  All articles with References: header are "followups".

No. There is no justification for a mandate to be inserted into our draft,
so sentence 1 is incorrect. The second sentence is an attempt at defining
followups by the presense of a Reference header. They are not currently
defined that way, nor is that how current practice defines them. 

>2) All "followups" have a References: header.
>  There exist articles that have References:, but are not "followups"

Same problem with sentence 1. Sentence 2 is wrong because removing the
ability to detect followups is a mistake. There was a reason the
References header was created; there was a reason RFC1036 says
"required/prohibited"; there was a reason our drafts, until recently, said
"MUST/MUST NOT". However, they no longer do, for a reason that we all know
and love. 

>3) There exist "followups" with no References: header.
>  All articles with References: headers are "followups".

No. This combines the worst of both worlds. Not only is this removing the 
ability to detect followups, it tries to define followups by the presense 
of the header, again. Not acceptable.

>4) There exist "followups" with no References: header.
>  There exist articles that have References:, but are not "followups"

No. Removes the ability to detect followups. 

By tossing the discussion into a blender, you've managed to come up with
four unacceptable options. Using the same abbreviated style, here are
two more options:

5) USEFOR differs from RFC2822 in that References headers MUST appear in 
    followups.
   References headers MUST NOT appear in any other article.

6) USEFOR adopts the definition of References header as found in RFC2822 
    (i.e., References is optional in all articles.)

(5) assumes a definition of followups that is not simply the circular 
"whatever contains a References header" that Charles keeps pretending I've 
proposed. "Posted in response to or as a result of another article" covers
current practice, even the isochronous posting of multi-part FAQs, since 
as has already been pointed out, parts 2 .. n would not be posted without 
part 1, and if part 1 is not posted, there is no message id to refer to 
anyway. 

There is nothing chronological inherent in "as a result of", especially if
one person is doing all the acting. Even with two. If I ask someone to go
with me to lunch who normally skips lunch, then when he goes out it is as
a result of my going out, even though we both go at the same time. Heck, I 
could even ask him to go ahead of me to reserve a table, so his "as a 
result of" lunch actually happens before what it is a result of.

(5) would require some justification, which I'm hopeful someone comes up
with, because I'd like to see References continue its useful life. We were 
well along slipping the mandate in as historical, but since we've removed 
it, it's going to take a good reason to put back.

(6) is a less preferable but still acceptable alternative because it
results in internally consistent standards and matches the current
demonstrated consensus regarding the need for References headers and the
resultant mandates allowed.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: New Resource: Cross-linked sections with diffs
Date:  Thu, 26 May 2005 23:49:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> links to all previous versions of references, all the way
> back to RFC1036.

Great.  I just tracked the history of msg-id, and how the
NO-WS-CTL bug jumped from [MESSFOR] draft 4 disguised as an
innocent strict-qtext into [USEFOR].

> http://mibsoftware.com/userkt/usefor/usefor-usefor-04/index.html
[...]
> I hope you find it useful.

It's fascinating, thanks.  I completely forgot that draft -07
was 2002, not 2003.  If you ever need a manually created HTML
version of draft -07 with links to all pages and sections see
<http://purl.net/xyzzy/usefor07.htm> (336 KB)

                          Tnx & bye, Frank

Date: Thu, 26 May 2005 23:28:28 +0200
From: Eivind Tagseth <[email-masked]>
To: [email-masked]
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Mail-Followup-To: Eivind Tagseth <[email-masked]>, [email-masked]
Sender: [email-masked]

* Harald Tveit Alvestrand <[email-masked]> [2005-05-26 16:38:21 +0200]:

> 1) All "followups" have a References: header.
>   All articles with References: header are "followups".

This one.  Becuase I view things like multi-part faqs as a special type
of followup.

Eivind

Date: Thu, 26 May 2005 16:40:17 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: New Resource: Cross-linked sections with diffs
Sender: [email-masked]

A couple of perl and shell scripts later, I have split up the 22
documents related to usefor, cross linked them, and appended
diffs to previous versions.

Each section has its own page, with links to older and
newer revisions of the section (as well as NEXT/PREV)

For example, the page with the section on "References"

    http://mibsoftware.com/userkt/usefor/usefor-usefor-04/References.htm

links to all previous versions of references, all the way back to
RFC1036.

The two current drafts are good starting points for navigation:

    http://mibsoftware.com/userkt/usefor/usefor-usefor-04/index.html

    http://mibsoftware.com/userkt/usefor/usefor-usepro-03/index.html

I hope you find it useful.  At this point I have no intention of using a
different URL scheme, so it would be appropriate to link to individual pages
for the purposes of discussion.

I split the following 22 documents, into almost 2000 separate pages.  Let me
know if you find problems with something you want to use.  The PERL code
to depaginate, and find section headers, isn't as robust and fail-safe as
it could be.  (I do not have time to inspect all the pages that got
generated.)

rfc1036
s-o-1036
rfc2822
usefor-article-03
usefor-article-04
usefor-article-05
usefor-article-06
usefor-article-07
usefor-article-08
usefor-article-09
usefor-article-10
usefor-article-11
usefor-article-12
usefor-article-13
usefor-usefor-01
usefor-usefor-02
usefor-usefor-03
usefor-usefor-04
usefor-usepro-00
usefor-usepro-01
usefor-usepro-02
usefor-usepro-03

From: "Scott Hollenbeck" <[email-masked]>
To: "'Charles Lindsey'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-ietf-usefor-usefor-04.txt
Date: Thu, 26 May 2005 14:54:16 -0400
Sender: [email-masked]

> >2234 => 2234bis
> 
> Yes, I gather 2234bis is in Last Call now.

No, it's been approved by the IESG and is in the RFC Editor's queue.

-Scott-

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-ietf-usefor-usefor-04.txt
Date:  Thu, 26 May 2005 19:35:51 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 81
Sender: [email-masked]

Charles Lindsey wrote:
 
> I gather 2234bis is in Last Call now.

It's already in the in-queue, Dave can still fix some typos
found by Bruce, nothing serious from my POV:

<http://www.rfc-editor.org/queue.html#crocker-abnf-rfc2234bis>
<http://mid.gmane.org/[email-masked]>
<http://article.gmane.org/gmane.ietf.ltru/620>
---------------
>> Is deprecating X- headers allowed ?
 
> I don't see why not, if you are providing a standard header
> to fulfil the same role.

Examples could include "X-NoArchive: yes, (c) 2005 by xyzzy"
or "X-ComplaintsTo: not me".  The "same role" is unclear for
X- header fields.  

Not an important point, but if it helps to avoid a warning
from Bruce's review tool I'd just delete the last statement
"These headers are thus deprecated." - the intended effect of
the complainto-param is obvious without it.
---------------
> There is still work to be done on specifying <parameter>s so
> that all the intended features of RFC 1045/2231 get attached
> to them.

;; At most one of "post-host-param",
;; "post-acct-param", "sender-param",
;; "logging-param" or "complainto-param"
;; is allowed.

This way it's at least not incompatible with RfC 2231, and the
address-list allow more than complainto address.  Not that I
suddenly like 2231, it's still a PITA and a potential security
loophole in the weird case of a multiline boundary= parameter.

OTOH it's not our problem as long as all parameters are unique.
---------------
> '(' because we no longer allow comments (aka CFWS) in there,
> and ';' because we got rid of MIME-style parameters some
> while back.
 
>>  article-locator = 1*VCHAR

Fine, VCHAR is the same as in s-o-1036
---------------
>> "FQDN mailable" path-identity with "_" is dubious.
 
> But not all path-identities need to be mailable.

It's not exactly obvious to find this subtlety in Usepro-03,
where you say "MUST" for all _added_ path-identities.  Or in
other words, either something outside of (before ?) Usepro-03
could preload the path with underline-path-identities, or the
underline is only relevant for the tail-entry.

If it's only the latter the tail-entry ABNF could be improved.
---------------
>> s/mqtext/*mqtext/
> Yes.
 
[...] 
> you have raised all these before, but nobody supported you
> and our Chair said to leave it be.

Sure, Harald doesn't know this part of "the making of msg-id",
unless he read our rather long thread(s) about it.

The <527065CFBE71B58750EA0678@B50854F0A9192E8EC6CDA126> wasn't
only a joke, it illustrates a point:  B50854F0A9192E8EC6CDA126
is only syntactically an id-domain, not semantically, and it's
unclear who tries to guarantee the uniqueness of this msg-id.

Collisions could have undesirable side-effects, articles not
propagated, archives storing only one incarnation, cancel
messages hitting the wrong incarnation, complaints to admins,
nobody able to find out what went wrong, etc.  Bye, Frank

Date: Thu, 26 May 2005 18:06:16 +0100
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Suggested References texts
Sender: [email-masked]

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

>In <[email-masked]> Richard Clayton <[email-masked]> 
>writes:
>
>>Turnpike (www.turnpike.com) posts multi-part binaries with References
>>that point at the first part.  This means that it is very likely that
>>they will be threaded together by readers ... which means they won't
>>have to chase all over the newsgroup to find the separate parts of the
>>"attachment" to decode it.
>
>Actually, it would be more in keeping with the way References are normally
>used for each part to refer to all its predecessors.

shows how long it is since I last looked at this feature (which dates
back about a decade)... that is indeed exactly what Turnpike does

> That way, a threaded
>reader should show them in the correct order, and it is more likely to do
>something sensible if one of more of the parts is missing.
>
>In RFC 2046, message/partial recommends that each part refers to its
>immediate predecessor only, which is the Wrong Thing for much the same
>reasons.

:-)

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

To: [email-masked]
Xref: clerew local.usefor:20931
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-usefor-usefor-04.txt
Date: Thu, 26 May 2005 13:52:53 GMT
Lines: 95
Sender: [email-masked]

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

>[email-masked] wrote:

>> http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-04.txt

>Thanks, some observations in no particular order:

>2234 => 2234bis

Yes, I gather 2234bis is in Last Call now.

>2366 => 3851
>---------------
>2373 => 3513 (missing in the references)

>3513 has no IPv4address / IPv6address ABNF, therefore let's
>replace 2373 by 3986 (STD 66).

I agree. There are all sorts of RFCs that purport to give syntax for
IPv4address / IPv6address, and I originally chose RFC 2373 because it
seemed the cleanest. The forms given in RFC 3986 seem as good as any.

>----------------
>Is deprecating X- headers allowed ?

I don't see why not, if you are providing a standard header to fulfil the
same role.

>----------------
>          parameter = <TBD>

There is still work to be done on specifying <parameter>s so that all the
intended features of RFC 1045/2231 get attached to them.

>----------------
>          token = <as defined in RfC 2045>
>----------------
>| article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
>|                   ; US-ASCII printable characters
>|                   ; except '(' and ';'

>These exceptions are probably not more necessary:

Yes. '(' because we no longer allow comments (aka CFWS) in there, and ';'
because we got rid of MIME-style parameters some while back.

>  article-locator = 1*VCHAR
>-----------------
>"FQDN mailable" path-identity with "_" is dubious.

But not all path-identities need to be mailable. If you want to use one
that is, then you must restrict your path-identity accordingly. 

>-----------------
>| no-fold-quote   =  DQUOTE
>|                    ( "." mqtext /
>|                      *mqtext "." /
>|                      *mqtext mqspecial *mqtext )
>|                    DQUOTE

>s/mqtext/*mqtext/

Yes.

>The msg-id = id-left "@" id-right style of syntax is ugly and
>doesn't indicate the intended semantics id-local "@" id-domain

>Overloading 2822 no-fold-quote by something else is confusing.
>a simple ( DQUOTE id-quote DQuOTE ) is clearer.

>Overloading 2822 no-fold-literal by something else is ugly, a
>simple id-literal is clearer

Yes, you have raised all these before, but nobody supported you and our
Chair said to leave it be.

>The terms mqtext, mqspecial, and mdtext are cryptic (mq means
>"something in msg-id no-fold-quote", the d in md probably means
>"domain-literal").

mqtext and mdtext are our replacements for the qtext and dtext used in the
corresponding syntax in RFC 2822. mqspecial is a subset of
specials as defined in RFC 2822.

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

To: [email-masked]
Xref: clerew local.usefor:20932
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Thu, 26 May 2005 13:58:32 GMT
Lines: 27
Sender: [email-masked]

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

>Turnpike (www.turnpike.com) posts multi-part binaries with References
>that point at the first part.  This means that it is very likely that
>they will be threaded together by readers ... which means they won't
>have to chase all over the newsgroup to find the separate parts of the
>"attachment" to decode it.

Actually, it would be more in keeping with the way References are normally
used for each part to refer to all its predecessors. That way, a threaded
reader should show them in the correct order, and it is more likely to do
something sensible if one of more of the parts is missing.

In RFC 2046, message/partial recommends that each part refers to its
immediate predecessor only, which is the Wrong Thing for much the same
reasons.

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

To: [email-masked]
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 26 May 2005 09:08:37 -0700
Sender: [email-masked]

Harald Tveit Alvestrand <[email-masked]> writes:

> I'd like to have the 11 or so people who have spoken up on the issue (and
> anyone who cares to speak up otherwise) identify themselves as having one
> of four positions on what USEFOR should say about this issue:

> 2) All "followups" have a References: header.
>    There exist articles that have References:, but are not "followups"

This one.

I think redefining followups to mean anything with a References header,
even if making our lives easier in writing the document, really muddy the
waters for people trying to understand the document and compare it to
existing Usenet practice, since that's just not how the term is used right
now.  That leaves us with two choices, as near as I can tell:  forbid
existing practice of using References occasionally to tie together
articles that don't have a parent/followup relationship logically, or
relax the definition of followup so that it isn't as tightly tied to
References.  Of those two alternatives, I think the second one is more
useful.

Note that one implication of this is that it means that a followup is not
distinguishable in a protocol sense from articles that are tied together
by References but are not followups.  This arguably makes the word
"followup" not particularly useful from a protocol standpoint, and means
that we need to be careful about language anywhere we discuss threading
issues to not use the term "followup" as synonymous with "has a References
header pointing to another article."

That being said, this isn't a strong opinion, and I'd be content with:

> 1) All "followups" have a References: header.
>    All articles with References: header are "followups".

and just redefining those other uses of the References header as also
being followups, even though I think it muddies things.

3 and 4, however, I don't like at all.  All followups should have a
References header.

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

From: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Date: Thu, 26 May 2005 18:05:47 +0200
Organization: Chaos rules.
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

To me, the purpose of the References: header is to improve the 
quality of the experience of the user of the newsreader.

> 3) There exist "followups" with no References: header.
>    All articles with References: headers are "followups".

Since readers can often also thread on Subject (maybe 
combined with Date) I have to choose #3.

I have seen a lot of followups lately that were completely 
lose from their parent messages:
news:[email-masked]
Such things happen again and again.

I can live with #1, but then it would be a problem when a 
See-Also or In-Reply-To: or other similar header is around 
with a Message-ID that is not in the References.

The problem with #2 is that their exist followups that have 
no (proper) References: header.

To me, a message is a followup on, or to, all the messages 
of which the Message-IDs are in its References: and in all 
other external-Message-ID-carrying headers: Replace, 
Supersede, Invalidate, Cancel, etc.

-- 
Grtz, Ruud

Date: Thu, 26 May 2005 11:39:46 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Sender: [email-masked]

> 2) All "followups" have a References: header.
>    There exist articles that have References:, but are not "followups"

That's my position.  It corresponds with current reality (except for
broken clients that lose, mangle, or misconstruct the References
header) and does the right thing with multi-part faqs and the like.

Seth

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1008 USEFOR 1.5: relation between a followup and a References:header?
Date:  Thu, 26 May 2005 17:19:38 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Hi, I found the following in an article from Harald, I think
it deserves a new thread instead of a mere reply (!= "Re: ")

| 2) All "followups" have a References: header.
|    There exist articles that have References:, but are not
|    "followups"

References set to an unrelated context known only by Harald.
Strange msg-id, BTW.
                     Bye, Frank

Date: Thu, 26 May 2005 11:19:29 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

Eivind Tagseth <[email-masked]> wrote:
> * Sebastian Brocks <[email-masked]> [2005-05-26 01:21:46 +0200]:
>> John Stanley schrieb:

>> > Another example of current practice indicating that "followups" are "in 
>> > response to or as a result of another article". 
>> 
>> Wrong. The second part of a multipart FAQ is not posted as a response to
>> or as a result of another article, they are usually posted _at the same
>> time_.
>
> But still, the second part clearly follows up on the first part.  Posting
> only the second part without posting the first would not make sense.

That's why it makes sense for the later parts of multipart faqs to
have References headers that point to the first (or all earlier)
parts:  for the convenience of the reader.  But they don't fit the
definition of "followup" that John's message contained.  So if we want
to preserve that definition, we can either specify doing the wrong
thing (no References header) and write a standard that will be
ignored, or we can allow non-followups that are otherwise-related to
have References headers.

Seth

Date: Thu, 26 May 2005 16:08:20 +0100
To: Harald Tveit Alvestrand <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Sender: [email-masked]

In message <[email-masked]>,
Harald Tveit Alvestrand <[email-masked]> writes

>A "followup" is an article containing a response to the contents of
>an earlier article (the followup's "precursor" indicated in the
>"References" header).

hence they are part of the same discussion (or fight) and almost always
people will deal with them the same way, read, kill, mark for later
cogitation etc

>I'd like to have the 11 or so people who have spoken up on the issue (and 
>anyone who cares to speak up otherwise) identify themselves as having one 
>of four positions on what USEFOR should say about this issue:
>
>1) All "followups" have a References: header.

yes indeed -- because reading software looks at this and constructs
trees of articles accordingly. Trees work well at an HCI level and there
hasn't really been any improvements on this that have caught on.

The large number of article IDs in the References provide robustness for
the tree-building, especially when some articles are delayed in
propagation or were in other newsgroups that are not currently to hand

>  All articles with References: header are "followups".

no

The concept "I know that a lot of people will see this as a single tree"
is terribly useful (for multi-part things that are posted in one session
but are just "one thing" really)  This happens today...

so forcing you to even pretend to be creating a "response" is
shoehorning current useful activity into a strange verbal prison

>2) All "followups" have a References: header.
>  There exist articles that have References:, but are not "followups"

... which means that this, #2, captures my perception of useful current
practice that a standard would do well to accommodate.

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

Date: Thu, 26 May 2005 11:09:08 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Sender: [email-masked]

A specification allows unambiguous generation and processing, and
we are chartered to document existing practice.

You have not redefined followup. I find all of your choices unsuitable,
for the following reasons:

> 
> 1) All "followups" have a References: header.
>   All articles with References: header are "followups".

To cover existing usage, this requires the definition of "followup" to
include multi-part.  But a multi-part is not a "response" to an article,
so the definition fails to cover existing uses.  Unsuitable.

> 
> 2) All "followups" have a References: header.
>   There exist articles that have References:, but are not "followups"

Ambiguous, so not a specification.  Is the receiving end required
to treat it like a followup when it has no way of determining
it is not?

> 
> 3) There exist "followups" with no References: header.
>   All articles with References: headers are "followups".

This specifies nothing.  A "followup" could have or not
have a References: header.  It says nothing about why a
non-followup couldn't have a References: header

> 
> 4) There exist "followups" with no References: header.
>   There exist articles that have References:, but are not "followups"

This also specifies nothing.

Date: Thu, 26 May 2005 11:05:43 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: #1008 USEFOR 1.5: relation between a followup and a References: header?
Sender: [email-masked]

On Thu, 26 May 2005, Harald Tveit Alvestrand wrote:
> 2) All "followups" have a References: header.
>    There exist articles that have References:, but are not "followups"

Justification:  this is existing practice, and in this matter I think
recognizing it will work and attempting to change it won't.

                                                          Henry Spencer
                                                       [email-masked]

Date: Thu, 26 May 2005 10:47:18 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Suggested References texts
Sender: [email-masked]

On Wed, 25 May 2005, Eivind Tagseth wrote:
> > No, the purpose of a References header is to identify related articles. 
> 
> This is very imprecise.

Purposely so.  The debate is *about* how narrow the precise definition
should be. 

> Your old proposed header See-Also was intended
> to identify related articles.

Correct.  It was a failed attempt to separate two existing usages of
References.

> The References header is meant to identify
> the articles that this article follows.

That was the original intent, but that is not the only way it is used
today.  The question is whether existing broader usage should be declared
legitimate, or forbidden... bearing in mind that it will not stop just
because we declare it illicit, especially if we don't provide an
alternative. 

                                                          Henry Spencer
                                                       [email-masked]

Date: Thu, 26 May 2005 16:38:21 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1008 USEFOR 1.5: relation between a followup and a References: header?
Sender: [email-masked]

I have now read through the 37 messages posted over the last month or so on 
this issue. I cannot tell what has consensus, or indeed what people want as 
the text in USEFOR.

I've filed the following ticket (#1008):
--------------------------------------------------------------------
Subject: USEFOR 1.5: relation between a followup and a References: header?

USEFOR version -04 states:

 A "followup" is an article containing a response to the contents of
 an earlier article (the followup's "precursor" indicated in the
 "References" header).

 Discussion has revealed two possibilities:
- All "followup"s (as defined here) have a References: header.
- There can be articles that are a "followup" that do not have
"References:" headers

The other half of the problem is whether there can be articles that
have References: headers which are not "followups".
---------------------------------------------------------------------
I'd like to have the 11 or so people who have spoken up on the issue (and 
anyone who cares to speak up otherwise) identify themselves as having one 
of four positions on what USEFOR should say about this issue:

1) All "followups" have a References: header.
   All articles with References: header are "followups".

2) All "followups" have a References: header.
   There exist articles that have References:, but are not "followups"

3) There exist "followups" with no References: header.
   All articles with References: headers are "followups".

4) There exist "followups" with no References: header.
   There exist articles that have References:, but are not "followups"

You may choose to include a justification for your position, but please do 
NOT comment on what other people's opinion or the group's opinion is on 
this issue is at this time.

Note: This is not an opinion poll. It is the kind of question I ask when I 
can't tell what people are trying to achieve.

                         Harald

From: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Subject: Re: Suggested References texts
Date: Thu, 26 May 2005 09:54:15 +0200
Organization: Chaos rules.
Sender: [email-masked]

Eivind Tagseth:
> Sebastian Brocks:
>> John Stanley:
>>> Richard Clayton:

>>>> Turnpike (www.turnpike.com) posts multi-part binaries with
>>>> References that point at the first part.

>>> Another example of current practice indicating that "followups" are
>>> "in response to or as a result of another article".

>> Wrong. The second part of a multipart FAQ is not posted as a
>> response to or as a result of another article, they are usually
>> posted _at the same time_.

> But still, the second part clearly follows up on the first part. 
> Posting only the second part without posting the first would not make
> sense.  The fact that the articles are posted at the same time is a
> technicality.  And one that really doesn't matter to anyone, the
> articles may arrive at newsservers in any order anyway.

Yes, let's please get rid of the limited notion that a 'followup' 
is a reaction on something.

I post responses, I post reactions, I even post replies. But I 
also post thread-starters, which are anchors for generated 
messages. I do this stateless: I post the thread-starter with 
every generated message.

The message-id of the thread-starter is derived from the year + 
month + daynumber-group (A:1-10, B:11-20, C:21-31), so there is 
at most one thread-starter about every 10 days. The message gets 
rejected by the server if it was sent before, so it is not really 
stateless. :)

The 'real' messages, generated from the data entered on a web form,
get the message-id of the thread-starter in the References header. 
So the first completed form in any of those daygroups (A, B or C), 
and in my particular timezone, results in 2 postings on the server. 

Each posting is about problems with some other newserver. These 
postings are independent, but are seen as far less annoying by 
people that are not interested, exactly because they are threaded 
in such a very organised way and so can easily be filtered and 
ignored.

In a similar way one could create categories in a newsgroup. If 
there would be an eternal thread-starter (with a predictable 
message-id, and maybe with the Subject [C]) in a general programming 
newsgroup, then people with postings about C could put the message-id 
of that thread-starter in the References of their posting.

-- 
Grtz, Ruud

Date: Wed, 25 May 2005 22:16:01 +0200
From: Eivind Tagseth <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Mail-Followup-To: Eivind Tagseth <[email-masked]>, [email-masked]
Sender: [email-masked]

* Seth Breidbart <[email-masked]> [2005-05-25 14:57:31 -0400]:

> John Stanley <[email-masked]> wrote:

> > Current standards say that non-followups
> > are prohibited from having a References header.
> 
> And in the cases of things like multipart faqs, those standards are
> widely ignored.  I think reality is doing the right thing, and the
> standards are specifying the wrong thing.  I think the new standard
> (the one we're writing) should specify the right thing.

You arguments assume your limited view of what a followup is.  If
the parts of a multipart faq is seen as followups to the first part
(or the ToC), then there would be no problems.  Then, a followup would
require a references header, and articles with references headers would
all be followups.  And then the standard would be clean and nice, a
followup could be created by a news agent, and it could be read back by
a news agent and it would know that it was a followup.

I really don't see why a multipart faq doesn't fit with the followup
term.  As a non-native english speaker, I may be very wrong here, but
e.g. merriam-webster defines the verb "follow up" as:

	transitive senses
	1 : to follow with something similar, related, or supplementary <following up his convictions with action -- G. P. Merrill>
	2 : to maintain contact with (a person) so as to monitor the effects of earlier activities or treatments
	3 : to pursue in an effort to take further action <the police follow up leads>
	intransitive senses : to take appropriate action <follow up on complaints>

Clearly, multipart faqs fit nicely with definition 1?

Eivind

Date: Wed, 25 May 2005 22:01:41 +0200
From: Eivind Tagseth <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Suggested References texts
Mail-Followup-To: Usefor Mailing List <[email-masked]>
Sender: [email-masked]

* Henry Spencer <[email-masked]> [2005-05-25 14:01:39 -0400]:

> 
> On Wed, 25 May 2005, John Stanley wrote:
> > >The plain fact is that there is no technical reason why anyone needs to
> > >know whether or not an article is a "followup".
> > 
> > Since the only purpose for a References header is to identify what 
> > articles are followups (and what ones are NOT)...
> 
> No, the purpose of a References header is to identify related articles. 
> That's why it contains message IDs, instead of just being something like
> "Is-Followup: yes".

This is very imprecise.  Your old proposed header See-Also was intended
to identify related articles.  The References header is meant to identify
the articles that this article follows.  It is meant to identify a
parent-child relationship, in fact, it is meant to identify an original
article and _all_ articles that "followed" until this article's "parent"
(truncated only if necessary).

The references header identifies all articles that the current article
"follows", in order.  In my eyes, that makes an article a follow-up.

Current practice for most clients is to display this special "follow"-relation
as a thread/tree.  It would not make sense to indicate other kinds of
relations (e.g. See-Also) in the same manner.  If one were to add a references
header for other types of relations (i.e. articles that doesn't naturally
"follow" each other), then both people and newsreaders would be confused.

The current definition of a followup is kind of useless.  It is more a
definition of what should happen when a user presses the "Reply"/"Followup"
button than a description of a special type of article.  For an implementor
of a newsreader it is of no use (except for handling the "Followup"-button-
press), and he/she will need another term for describing articles that
should be organized in threads.  I find this confusing;  you can post a
"followup", but you can never read one.

Eivind

Date: Thu, 26 May 2005 08:36:05 +0200
From: Eivind Tagseth <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Mail-Followup-To: Eivind Tagseth <[email-masked]>, [email-masked]
Sender: [email-masked]

* Sebastian Brocks <[email-masked]> [2005-05-26 01:21:46 +0200]:

> 
> John Stanley schrieb:

> > Richard Clayton <richard@xxxxxxxxxxxxxx>:

> >>Turnpike (www.turnpike.com) posts multi-part binaries with References
> >>that point at the first part.
> > 
> > Another example of current practice indicating that "followups" are "in 
> > response to or as a result of another article". 
> 
> Wrong. The second part of a multipart FAQ is not posted as a response to
> or as a result of another article, they are usually posted _at the same
> time_.

But still, the second part clearly follows up on the first part.  Posting
only the second part without posting the first would not make sense.  The
fact that the articles are posted at the same time is a technicality.  And
one that really doesn't matter to anyone, the articles may arrive at
newsservers in any order anyway.

Eivind

Date: Thu, 26 May 2005 01:21:46 +0200
From: Sebastian Brocks <[email-masked]>
To: John Stanley <[email-masked]>
CC: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

John Stanley schrieb:

> 
> Richard Clayton <richard@xxxxxxxxxxxxxx>:
> 
>>Turnpike (www.turnpike.com) posts multi-part binaries with References
>>that point at the first part.
> 
> Another example of current practice indicating that "followups" are "in 
> response to or as a result of another article". 

Wrong. The second part of a multipart FAQ is not posted as a response to
or as a result of another article, they are usually posted _at the same
time_.

Date: Wed, 25 May 2005 16:14:28 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

Henry Spencer <henry@xxxxxxxxxxxxx>:

>No, the purpose of a References header is to identify related articles. 
>That's why it contains message IDs, instead of just being something like
>"Is-Followup: yes".

You've just repeated what I said, almost. The References header identifies
a followup and to what article it is a followup. Of course if all you
wanted was "is this a followup" then "is-followup: yes" is the right way
to go. But that's not all it does. Like I've said.

It does not deal with "related" articles. The standard for news says:

>    If the message is submitted in
>    response to another message (e.g., is a follow-up) the default
>    subject should begin with the four characters "Re:", and the
>    "References" line is required. 

Further:

>    It is required for all follow-up
>    messages, and forbidden when a new subject is raised.

It does not say "if the message is related to another". It uses the term 
"followup". The purpose of the header cannot be what it does not even 
mention once.

>> ...then you've just admitted 
>> that there is no technical reason for that header, and thus no possible 
>> interoperability issue if it does not exist...

>And you complain about *Charles* putting words in *your* mouth?

Yes, because he does. Show me the quotes where I quoted him saying
something he did not, or where I claimed that he said something he did
not. He said what I quoted, and what he said is an admission that there is
no interoperability issue, since it is impossible for something that has
no technical need to be an interoperability issue.  An interoperability
issue is the basis for a technical need. No need means there is no
underlying issue, since the existance of the issue creates the need.

>John, if you made your points politely and concisely,

I've made my points politely and concisely, and in return I get Charles
telling everyone that I've said things that I clearly have not,
repeatedly, and after being told to stop doing so, repeatedly. If you
don't like the profanity, well, I'm sorry you don't like it, but at this
point, I'm trying to express a STRONG DISLIKE for what Charles keeps
doing, and if profanity is what it takes, so be it. It woke you up, I
notice. Unfortunately, you don't seem upset that Charles repeatedly 
misquotes me, only that I yelled at him for doing so. 

Don't be dishonest and pretend that profanity is the reason you don't read
what I have written. And don't be dishonest and pretend that I do it all
the time; the last time I resorted to such language I deliberately sent
the message ONLY to the chair, with an explanation that this behaviour of
Charles was causing a problem and something needed to be done about it,
and that I did not want to say things like that in the group. I did not
get even the courtesy of a reply telling me to, well, any reply at all.
Now I'm saying it in public, because it solves nothing to say it in
private. Maybe it solves nothing in public, either.

> ...refrained from distorting what other people say, 

That's rich, given the message that you are responding to, and your 
distorted next statement.

> avoided arguments that boil down to "I'm right, therefore I'm right", 

Yeah, I know, you have all sorts of excuses for not considering viewpoints
that differ from yours, even to the extent that you'll distort arguments
by saying they "boil down to" whatever you can dismiss offhand. "The RFC
says" is not "I'm right, therefore I'm right" and you know better. At
least you ought to know better.

>and were willing to admit defeat rather
>than coming back with the exact same arguments again and again, everyone
>would read your postings. 

It's the same problem again and again, so the same arguments apply again
and again. When "the exact same arguments" prove that I am not wrong, why
should I admit defeat? Do you expect me to "admit defeat" just because YOU
have no convincing counter-arguments? Isn't that the "I'm right because
I'm right" argument that you just condemned me for making?

Seth Breidbart <sethb@xxxxxxxxx>:

>In my extremely ego-centric viewpoint, the purpose of a References
>header included by someone else is that he wanted me to see his
>article threaded at a particular point in the threading tree my
>newsreader shows me.

The exact same arguments. Admit defeat, Seth. Henry would want you to.
Oh, wait. That applies only to me, I suspect.

Sarcasm aside: your view is incorrect. The standards do not mention 
display of articles when they define the use of the References header. 
They say, well, what I've already quoted. Further, it is, I believe, 
commonly accepted that "display issues" are outside the scope of the 
standard. The news standard does not define how articles are displayed. 
The poster has NO control over the display of his article, and pretending 
that he has such control is simply ridiculous. He might want large green 
flashing letters, but he has no header to indicate that, either. What he 
HAS is the ability to say "this is a followup to X", and that's the 
References header. 

>> You've just admitted that they are NOT needed.

>Only if one believes _your_ claim about their purpose.  I don't.  Many
>others (apparently including most of this group) don't.

Yes, many people do not believe the standards have any meaning, but that
does not make their view correct. RFC1036 is the current standard. It
defines the References header in news. "Display me this way" is not part
of the definition. "This is a followup to X" is.

>The MUST be present in order that threaded newsreaders be able to sort
>the article properly.

The same old argument. Admit defeat. Henry would expect you to.

Sorry. This is not an interoperability issue. It does not merit RFC2119
mandates. A single newsreader doing something that a single newsreader has
complete control over is not an interoperability issue. We cannot tell a
newsreader how to display articles, so the fact that it doesn't do it the
way the poster thinks should be done is, well, sad for the poster, but
completely irrelevant to this group.

You could apply your same argument to ANY header. "A Summary header MUST 
be present to convey the summary information to the reader". Well, ok, 
yes, but MUST implies an interoperability issue ... "A Keywords header 
MUST ..." Same problem. "A References header MUST..." Same problem.

>I disagree.  Multipart faqs are my favority counterexample.

Multi-part FAQs fit into the "in response to or as a result of" 
definition of "followup". They aren't a counter-example.

>> Since the only purpose it serves is to identify followups

>Arguing from your conclusion is not convincing.

You mean arguing from the standards isn't convincing you. It's not the 
conclusion that their function is to identify followups, that the starting 
point. That's the only purpose they can have, since they have no other 
function. "This is a followup to X" is what they say. Period. Not a peep 
about "display me this way" or "pick up the laundry after work". What you 
WANT them to say is irrelevant; what they DO say is the issue.

>Displaying the parts of a multipart faq threaded as followups is not
>seen as "confusing and incorrect" by anybody except maybe you.

I didn't say it was. Please stick to trying to refute things I actually 
say.

>I think the new standard
>(the one we're writing) should specify the right thing.

So do I. When I proposed the change to make it say the right thing, it was 
dissmissed, twisted, lied about, and called "smoke and mirrors". Or do you 
disagree that a followup could be defined as I proposed and that would 
reflect current practice? And would still allow the identification of 
followups from non-followups (assuming the mandate/prohibition language
was replaced?)

>> Either the multi-part FAQs that have References headers ARE
>> followups or they are invalid articles and they are required to be
>> dropped. I pick the former, the people who post them pick the
>> former,

>Do they?  Have you asked them?  

Don't be silly. If they thought they were invalid articles that should be
dropped instead of transported, why would they go to the effort of posting
them?  No, the fact that they DID post them implies they thought they were
valid articles, and the only way for an article that contains a References
header to be valid is if it is a "followup", however that word is defined.
That's "the former", and it is clear that they did pick that choice, even
if they did it unknowingly.

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>Turnpike (www.turnpike.com) posts multi-part binaries with References
>that point at the first part.

Another example of current practice indicating that "followups" are "in 
response to or as a result of another article". 

>Nevertheless, I think it could still
>be a useful trick to leave in the spec as being possible.

Using the definition I proposed a long time ago -- not Charles fictional
version, the actual proposed definition -- it would be possible. And still
possible to identify followups.

As the draft stands, it is possible, since there is no prohibition at all 
on the use of References headers in any article. Reference away at will.

As I've already said, I'm happy either way, as long as we are consistent. 
Currently, we are not. That's a problem. But saying so politely doesn't 
seem to interest Henry. 

Date: Wed, 25 May 2005 23:39:30 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Subject: Administrativia (Re: Suggested References texts)
Sender: [email-masked]

John,

two reminders:

- Despite history, profanity and accusations of lying on the public mailing 
list are not an useful form of dialogue. They make it harder, not easier, 
to tell what is being discussed or agreed. If you want to complain about 
inappropriate behaviour from another participant, do it privately.

- Charles is NOT "the editor". He is currently the editor of USEPRO. He is 
NOT the editor of USEFOR, which is the document with the definition we're 
talking about. When he speaks about USEFOR, he's got no more power than any 
other participant. Ken Murchison edits USEFOR.

--On 25. mai 2005 10:26 -0700 John Stanley <[email-masked]> wrote:

> Alexey, Harald, somebody in charge here, will you PLEASE do something
> about this repeated crap from the editor? He's doing it because he knows
> he can get away with it and because he knows it annoys the hell out of
> me.  He's doing it because he doesn't want to discuss the issue honestly.
> He's  doing it because he knows some people have stopped reading what I
> write  and he thinks he can spoon-feed them lies about what I am saying
> to keep  them from reading it.

Date: Wed, 25 May 2005 20:25:48 +0100
To: Seth Breidbart <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Suggested References texts
Sender: [email-masked]

In message <[email-masked]>, Seth Breidbart
<[email-masked]> writes

>>>2. Other cases where it is sensible to use a References header.
>>
>> There are no other cases where it is sensible to use that header.
>
>I disagree.  Multipart faqs are my favority counterexample.

Turnpike (www.turnpike.com) posts multi-part binaries with References
that point at the first part.  This means that it is very likely that
they will be threaded together by readers ... which means they won't
have to chase all over the newsgroup to find the separate parts of the
"attachment" to decode it.

Of course many reading agents are clever about binaries anyway these
days, and there's less objection to posting megabyte articles than there
used to be; Australia no longer discards everything over 64K at its
borders :)  so times have moved on. Nevertheless, I think it could still
be a useful trick to leave in the spec as being possible.

- -- 
richard                                              Richard Clayton

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

Date: Wed, 25 May 2005 14:57:31 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

John Stanley <[email-masked]> wrote:
> "Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>The plain fact is that there is no technical reason why anyone needs
>>to know whether or not an article is a "followup".
>
> Since the only purpose for a References header is to identify what 
> articles are followups (and what ones are NOT),

In my extremely ego-centric viewpoint, the purpose of a References
header included by someone else is that he wanted me to see his
article threaded at a particular point in the threading tree my
newsreader shows me.

My purpose in including References headers is to make it more likely
other people's newsreaders will show my article in an appropriate
point in the threading tree.

Note carefully that "is a followup" is not necessarily part of such
purposes, albeit it is something that correlates highly (and NOT
perfectly) with them.

>>References headers are needed in two cases:
>
> You've just admitted that they are NOT needed.

Only if one believes _your_ claim about their purpose.  I don't.  Many
others (apparently including most of this group) don't.

>>1. Followups (as currently defined), in which case they MUST be present.
>
> So says Charles, and thus endeth the debate. Why MUST they be present if 
> there is no technical reason for identifying followups? 

The MUST be present in order that threaded newsreaders be able to sort
the article properly.

>>2. Other cases where it is sensible to use a References header.
>
> There are no other cases where it is sensible to use that header.

I disagree.  Multipart faqs are my favority counterexample.

> Since the only purpose it serves is to identify followups

Arguing from your conclusion is not convincing.

>>and nobody has
>>come up with a reason why you should ever _want_ to tell which is which.
>
> If you deliberately misrepresent the discussion, someone will call you on 
> it. Yes, Charles, lots of people have come up with reasons why you want to 
> know the difference between followups and not-followups. Display of 
> threads is the main reason. Putting a References header in a not-followup 
> implies that it is a followup to the article referred to, and displaying 
> it as if it is a followup is confusing and incorrect.

Displaying the parts of a multipart faq threaded as followups is not
seen as "confusing and incorrect" by anybody except maybe you.

> Current standards say that non-followups
> are prohibited from having a References header.

And in the cases of things like multipart faqs, those standards are
widely ignored.  I think reality is doing the right thing, and the
standards are specifying the wrong thing.  I think the new standard
(the one we're writing) should specify the right thing.

> Either the multi-part FAQs that have References headers ARE
> followups or they are invalid articles and they are required to be
> dropped. I pick the former, the people who post them pick the
> former,

Do they?  Have you asked them?  (The one I share responsibility for
went obsolete a long time ago, but that was never the case for it.)

Seth

Date: Wed, 25 May 2005 14:01:39 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Suggested References texts
Sender: [email-masked]

On Wed, 25 May 2005, John Stanley wrote:
> >The plain fact is that there is no technical reason why anyone needs to
> >know whether or not an article is a "followup".
> 
> Since the only purpose for a References header is to identify what 
> articles are followups (and what ones are NOT)...

No, the purpose of a References header is to identify related articles. 
That's why it contains message IDs, instead of just being something like
"Is-Followup: yes".

It *would* be nicer if References only identified precursors, and
something else was used for related-but-non-precursor articles, such as
the other articles of a multi-part FAQ.  I tried to legislate that in
son-of-1036.  I failed; it was already much too late.  (I suspected so
even at the time, witness the "unresolved issue" comment in son-of-1036.)
That battle's lost.  The reader agents have long since figured out how to
cope.  There's no benefit, now, in commanding the tide not to come in. 

> ...then you've just admitted 
> that there is no technical reason for that header, and thus no possible 
> interoperability issue if it does not exist...

And you complain about *Charles* putting words in *your* mouth?

> [profanity and insults deleted]  ...He's doing
> it because he knows some people have stopped reading what I write...

John, if you made your points politely and concisely, refrained from
distorting what other people say, avoided arguments that boil down to
"I'm right, therefore I'm right", and were willing to admit defeat rather
than coming back with the exact same arguments again and again, everyone
would read your postings. 

                                                          Henry Spencer
                                                       [email-masked]

Date: Wed, 25 May 2005 10:26:28 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>The plain fact is that there is no technical reason why anyone needs to
>know whether or not an article is a "followup".

Since the only purpose for a References header is to identify what 
articles are followups (and what ones are NOT), then you've just admitted 
that there is no technical reason for that header, and thus no possible 
interoperability issue if it does not exist. POOF goes any justification 
for a mandate regarding the References header.

>References headers are needed in two cases:

You've just admitted that they are NOT needed. If there is no need for the 
function they perform, there is no need for them. 

>1. Followups (as currently defined), in which case they MUST be present.

So says Charles, and thus endeth the debate. Why MUST they be present if 
there is no technical reason for identifying followups? 

>2. Other cases where it is sensible to use a References header.

There are no other cases where it is sensible to use that header. Since 
the only purpose it serves is to identify followups (and then what article 
is being followed up to), if the article is NOT a followup, it makes no 
sense to claim it is.

>So if a References header is present, you know that it is either a
>"followup" or a "pseudo-followup". You cannot tell which, 

And yet when I point out that your change to the References mandates
(followup MUST/non-followup MAY) prevents determining what is and is not a
followup, you claim I am dealing in "smoke and mirrors" and I'm too stupid
to understand what you've been explaining to me.  And now you admit that
you cannot tell the difference between followups and not-followups.

>and nobody has
>come up with a reason why you should ever _want_ to tell which is which.

If you deliberately misrepresent the discussion, someone will call you on 
it. Yes, Charles, lots of people have come up with reasons why you want to 
know the difference between followups and not-followups. Display of 
threads is the main reason. Putting a References header in a not-followup 
implies that it is a followup to the article referred to, and displaying 
it as if it is a followup is confusing and incorrect.

>John has suggested (and is still suggesting) redefining the term
>"followup" as "everything that has a references header".

GOD DAMN IT CHARLES STOP PUTTING WORDS IN MY MOUTH. I do not know why you
continue doing this after being told to stop so many times, but I'm
fucking tired of it. If you cannot honestly represent what someone else
has said, then just shut the fuck up.  Your continued lies about what I
have suggested regarding the definition of the term followup is made even
more clear by email I sent just yesterday with a proposed definition for
followup that was nothing like what you keep telling others I have said.  
I'll also point out that what I said yesterday is almost identical to the
proposed definition of "followup" that I made at the very beginning of
this discussion a VERY long time ago, and the only reason I won't say it 
is identical is because I am not going to waste my time looking up the 
exact words I used; the intent and meaning are identical, and are NOT what 
you keep pretending I've said.

Alexey, Harald, somebody in charge here, will you PLEASE do something 
about this repeated crap from the editor? He's doing it because he knows 
he can get away with it and because he knows it annoys the hell out of me. 
He's doing it because he doesn't want to discuss the issue honestly. He's 
doing it because he knows some people have stopped reading what I write 
and he thinks he can spoon-feed them lies about what I am saying to keep 
them from reading it.

Alexey, I pointed out this behaviour a long time ago to you, and you 
ignored it. It isn't going away, it isn't going to "get better", it is 
going to go on as long as Charles can get away with it. The predecessor to 
Alexey asked me to wait patiently while he dealt with the problem, and 
I've been waiting patiently -- and clearly nothing is being done.

>Others (notably Russ) have pointed out that this is not the
>way that the term "followup" is used in the real world, and defining that
>later parts of multi-part FAQS are to be called "followups" would be
>artificial.

It isn't artificial if that is how it is currently being used, and that is
how it is currently being used. Current standards say that non-followups
are prohibited from having a References header. Either the multi-part FAQs
that have References headers ARE followups or they are invalid articles
and they are required to be dropped. I pick the former, the people who
post them pick the former, and the actual definition I have proposed
includes them. It's not "smoke and mirrors" to define something as it is
currently being used. Defining existing practice is one of the missions
for this group.

>I think that is as clear as you are going to get, but if people want to
>propose alternative wordings, then that is fine (I see that Forrest has an
>alternative suggestion, though I don't see that it actually changes
>anything).

I've proposed alternate wordings, but that doesn't seem to be fine with
you, Charles. You seem intent on making things up for me instead of
dealing with what I actually say. As the editor of this working group,
your behaviour is unacceptable. It was unacceptable when you made 
unilateral, undiscussed changes to the drafts, it is unacceptable that you 
lie about what group participants have said.

Date: Wed, 25 May 2005 15:50:04 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-usefor-usefor-04.txt
Sender: [email-masked]

Thanks Frank!

I've tried to use your message to initiate the trouble ticket system for 
USEFOR - to see the tickets, look at this URL:

<https://rt.psg.com/Search/Listing.html?ValueOfStatus=open&ValueOfStatus=new&StatusOp=%3D&QueueOp=%3D&ValueOfQueue=48&RowsPerPage=50&NewSearch=1>

RT claims that you should instead bookmark this horror:

<https://rt.psg.com/Search/Listing.html?Bookmark=FrT%3B%404%7C%256%7C%241%7C1%241%7C2%241%7C3%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2414%7CQueue%20%3D%20usefor%245%7CQueue%241%7C%3D%246%7Cusefor%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2413%7CStatus%20%3D%20open%246%7CStatus%241%7C%3D%244%7Copen%258%7C%2411%7CDESCRIPTION%245%7CFIELD%248%7COPERATOR%245%7CVALUE%2412%7CStatus%20%3D%20new%246%7CStatus%241%7C%3D%243%7Cnew%241%7C4%241%7C0%241%7C0&Tick
etsSortBy=&TicketsSortOrder=&RowsPerPage=50>

Login with user "ietf", password "ietf".

Note: I've tried to make the ticket titles all read "USEFOR <sectionnumber> 
- description" - that makes it VERY easy for someone who's going through 
the document to get the open issues on the document list.

When following up or suggesting resolutions, I'll quote the number of the 
ticket in the subject line - that makes it easy to figure out WHICH open 
issue we're talking about.

The 3 issues I picked out of your message as "need discussion" are 1002, 
1003 and 1004 - I wasn't sure whether you thought the others were strictly 
editorial or needed discussion.

Yours for a tracking of issues....

                 Harald

--On 24. mai 2005 23:23 +0200 Frank Ellermann <[email-masked]> 
wrote:

>
> [email-masked] wrote:
>
>> http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-04.txt
>
> Thanks, some observations in no particular order:
>
> 2234 => 2234bis
> 2366 => 3851
> ---------------
> 2373 => 3513 (missing in the references)
>
> 3513 has no IPv4address / IPv6address ABNF, therefore let's
> replace 2373 by 3986 (STD 66).
> ----------------
> Is deprecating X- headers allowed ?
> ----------------
> Missing <value> definition, my bad, Bill Fenner and Bruce
> explained how to do this:
>
>           value = <as defined in RfC 2045>
>
> The "issue" with the ugly <token> EBNF in 2045 was mainly
> a hallucination on my side (it's really ugly but not our
> problem, except from adding [CFWS] everywhere)
> ----------------
>           parameter = <TBD>
> ----------------
>           token = <as defined in RfC 2045>
> ----------------
>| article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
>|                   ; US-ASCII printable characters
>|                   ; except '(' and ';'
>
> These exceptions are probably not more necessary:
>
>   article-locator = 1*VCHAR
> -----------------
> "FQDN mailable" path-identity with "_" is dubious.
> -----------------
>| no-fold-quote   =  DQUOTE
>|                    ( "." mqtext /
>|                      *mqtext "." /
>|                      *mqtext mqspecial *mqtext )
>|                    DQUOTE
>
> s/mqtext/*mqtext/
>
> The msg-id = id-left "@" id-right style of syntax is ugly and
> doesn't indicate the intended semantics id-local "@" id-domain
>
> Overloading 2822 no-fold-quote by something else is confusing.
> a simple ( DQUOTE id-quote DQuOTE ) is clearer.
>
> Overloading 2822 no-fold-literal by something else is ugly, a
> simple id-literal is clearer
>
> The terms mqtext, mqspecial, and mdtext are cryptic (mq means
> "something in msg-id no-fold-quote", the d in md probably means
> "domain-literal").
>
> id-text, id-special, and id-literal are clearer (stuff needed
> only in a msg-id, no separate no-fold-literal vs. mdtext). See
> also <http://mid.gmane.org/[email-masked]>
>
>                           Bye, Frank
>
>
>
>

To: [email-masked]
Xref: clerew local.usefor:20918
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Wed, 25 May 2005 11:41:22 GMT
Lines: 72
Sender: [email-masked]

In <157593FC09DAF7F7A05E6893@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>When writing the standard, when writing the software, and when executing 
>the software, we cannot know intent on the part of the (human) poster. A 
>mandate in a protocol standard cannot be based on knowing a state of mind; 
>it has to be made based on observing an observable action.

>If we want to mandate anything based on the term "followup", there has to 
>be  some on-the-wire observable difference between "followup" and "not 
>followup" - such as the presence of a "References" header.

John has been flogging this dead horse for months.

The plain fact is that there is no technical reason why anyone needs to
know whether or not an article is a "followup".

References headers are needed in two cases:

1. Followups (as currently defined), in which case they MUST be present.
2. Other cases where it is sensible to use a References header. Let us
call them "pseudo-followups" just for the purposes of this discussion (I
don't intend to define that term in any document).

So if a References header is present, you know that it is either a
"followup" or a "pseudo-followup". You cannot tell which, and nobody has
come up with a reason why you should ever _want_ to tell which is which.

The action to be taken by a user agent which sees a References header is
the same in both cases. If it is in the habit of "threading" articles (not
all UAs provide that service, but many do), then it should go ahead and
include the article in its threads as normal.

There are not many cases where a pseudo-followup is appropriate and they
are not expected to be common, but they do exist and there is a consensus
that they should be allowed to exist. The example usually quoted is
multi-part FAQs, but they also arise in message/partial (and are mentioned
as such in RFC 2046). There are likely a few other sensible uses.

John has suggested (and is still suggesting) redefining the term
"followup" as "everything that has a references header". It is obvious
that such a redefinition cannot achieve any technically observable
difference. Others (notably Russ) have pointed out that this is not the
way that the term "followup" is used in the real world, and defining that
later parts of multi-part FAQS are to be called "followups" would be
artificial.

So, since it achieves nothing, there is no point in doing it.

The text I have currently proposed for USEFOR is

|  The References header is used to refer to earlier articles (e.g.
|  followups refer to their precursors), in order to facilitate the
|  display or retrieval, by reading and other agents, of threads of
|  related articles. It is the same as that specified in Section 3.6.4
|  of [RFC2822] with the added restrictions detailed in Section 2.2 and
|  those listed below:

I think that is as clear as you are going to get, but if people want to
propose alternative wordings, then that is fine (I see that Forrest has an
alternative suggestion, though I don't see that it actually changes
anything).

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-ietf-usefor-usefor-04.txt
Date:  Tue, 24 May 2005 23:23:16 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 66
Sender: [email-masked]

[email-masked] wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-04.txt

Thanks, some observations in no particular order:

2234 => 2234bis
2366 => 3851
---------------
2373 => 3513 (missing in the references)

3513 has no IPv4address / IPv6address ABNF, therefore let's
replace 2373 by 3986 (STD 66).
----------------
Is deprecating X- headers allowed ?
----------------
Missing <value> definition, my bad, Bill Fenner and Bruce
explained how to do this:

          value = <as defined in RfC 2045>

The "issue" with the ugly <token> EBNF in 2045 was mainly
a hallucination on my side (it's really ugly but not our
problem, except from adding [CFWS] everywhere)
----------------
          parameter = <TBD>
----------------
          token = <as defined in RfC 2045>
----------------
| article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
|                   ; US-ASCII printable characters
|                   ; except '(' and ';'

These exceptions are probably not more necessary:

  article-locator = 1*VCHAR
-----------------
"FQDN mailable" path-identity with "_" is dubious.
-----------------
| no-fold-quote   =  DQUOTE
|                    ( "." mqtext /
|                      *mqtext "." /
|                      *mqtext mqspecial *mqtext )
|                    DQUOTE

s/mqtext/*mqtext/

The msg-id = id-left "@" id-right style of syntax is ugly and
doesn't indicate the intended semantics id-local "@" id-domain

Overloading 2822 no-fold-quote by something else is confusing.
a simple ( DQUOTE id-quote DQuOTE ) is clearer.

Overloading 2822 no-fold-literal by something else is ugly, a
simple id-literal is clearer

The terms mqtext, mqspecial, and mdtext are cryptic (mq means
"something in msg-id no-fold-quote", the d in md probably means
"domain-literal").

id-text, id-special, and id-literal are clearer (stuff needed
only in a msg-id, no separate no-fold-literal vs. mdtext). See
also <http://mid.gmane.org/[email-masked]>

                          Bye, Frank

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usefor-04.txt
Date: Tue, 24 May 2005 15:47:48 -0400
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		: Netnews Article Format
	Author(s)	: C. Lindsey, et al.
	Filename	: draft-ietf-usefor-usefor-04.txt
	Pages		: 33
	Date		: 2005-5-24
	
This document specifies the syntax of network news (Netnews) articles
   in the context of the "Internet Message Format" (RFC 2822) and
   "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045).  This
   document supersedes RFC 1036, updating it to reflect current practice
   and incorporating incremental changes specified in other documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-04.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-usefor-04.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-usefor-04.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-usefor-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 24 May 2005 11:29:42 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>When writing the standard, when writing the software, and when executing 
>the software, we cannot know intent on the part of the (human) poster.

Of course we can. "I intend on posting this message instead of mailing." 
Ok, for posting, put in these headers. Do this, do that, etc. You cannot 
pretend that a message showing up at a news injection agent is maybe mail; 
you have to assume the intent was to post news. 

>A mandate in a protocol standard cannot be based on knowing a state of 
>mind; 

This is assuming what needs to be proven. What mandate? Why is a mandate 
necessary if all it does is express this "state of mind" that you admit we 
cannot know? If the only reason for this mandate is so the definitions of 
unknowable states of mind can be produced, then you've just proven that 
the mandate is specious. Specious mandates do not meet the criteria of 
RFC2119.

>If we want to mandate anything based on the term "followup", 
>there has to be some on-the-wire observable difference between "followup" 
>and "not followup" - such as the presence of a "References" header.

Like I said, there is a difference between what something IS and how 
something is DETECTED to be that thing. And since we cannot detect it 
anymore, who cares what it is? 

>I'll take my own advice and stop posting until I can propose a specific 
>text change to the USEFOR document.

The proposal is simple: change the word "MUST" in line 4 of step 4 of 
section 7.6 of USEPRO to "SHOULD". This matches RFC2822 and thus USEFOR.
This is a one-word change that reflects the consensus reflected in USEFOR. 

Either that, or a much more complex set of changes must be made to 
reproduce the alleged consensus for a mandate. An entry in the differences
from RFC2822 must be added to USEFOR, such as:

	x. While the References header is optional under RFC2822, it MUST
	appear in any news article that is a followup, and MUST NOT appear
	otherwise.

Then the definition of followup must be adopted, such as:

	x. A "followup" is an article posted in response to or as the
	result of another.

(Note that this conveniently covers multi-part FAQs, etc. It matches 
current usage better than any other proposal.)

Then USEPRO 7.6 must be changed to make a References header a mandatory
part of the duties of a followup agent. Such as prepending the following
text to the start of step 4:

	A References header MUST be inserted into the proto-article.

Given the number of changes necessary to two different drafts to get to 
what is alleged to be a consensus, versus the one-word change necessary to 
harmonize two drafts and an existing RFC, I would argue that the latter 
situation is closer to the true consensus of this group than the former.

A note for those who still claim that there IS a mandate for a References
header in a "followup": the only "MUST" referring to the References header
under 7.6 "Duties of a Followup Agent" is that a followup to an article
that contains a References header MUST have a References header. We are
told what the content of a References header MUST be for all followups,
but not that it MUST appear in all followups. (Just like we can specify 
the content of a Followup-To header without specifying that one MUST 
appear in any given article.)

I await with great anticipation the justification for putting a mandate 
back into the draft. 

   4. If the precursor did not have a References header (F-3.2.1), the
      content of the followup's References header MUST be inherited from
      that of the Message-ID header of the precursor. A followup to an
      article which already had a References header MUST have a
      References header comprising the precursor's References header
      (subject to trimming as described below) followed by CFWS and the
      Message-ID header content of the precursor.

"Forrest J. Cavalier III" <mibsoft@xxxxxxxxxxxxxxx>:

>Please give some thought to the question of whether RFC2119 guidelines
>for MUST/NOT/SHOULD apply.

USEPRO-03, Feb. '05:

+   Certain words, when capitalized, are used to define the significance
+   of individual requirements. The key words "MUST", "REQUIRED",
+   "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words
+   associated with the word "NOT", are to be interpreted as described in
+   [RFC 2119].

+        NOTE: The use of "MUST" or "SHOULD" implies a requirement that
+        would or could lead to interoperability problems if not
+        followed.

We've aleady decided they apply. Similar, if not identical, language
appears in USEFOR. We deliberately copy the language about
"interoperability issues" from RFC2119, so trying to claim that we can use
MUST without concern that there are any interoperability issues is
specious. We say explicitely that we imply they exist whenever MUST is
used, so saying that we can use MUST when they don't is a lie.

Date: Tue, 24 May 2005 11:02:08 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
CC: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> I actually think you are saying the same thing I'm trying to say, but 
> somewhat more loudly. I'll take my own advice and stop posting until I 
> can propose a specific text change to the USEFOR document.
> 
>                     Harald
> 

Yes, please propose a text change.

Please give some thought to the question of whether RFC2119 guidelines
for MUST/NOT/SHOULD apply.

On 4/28, I suggested this approach:

    A References header indicates the previously posted context in which
    the article was created.

Date: Tue, 24 May 2005 09:24:55 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

--On 23. mai 2005 13:57 -0700 John Stanley <[email-masked]> wrote:

>
> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> If a followup (a term defined for News only) is a message that contains
>> a  References header, then all followups have to contain a References
>> header.
>
> A perfectly circular line of reasoning. A meaningless definition.  And one
> that doesn't match current usage. People today do not say "I'm creating a
> followup because I'm putting a References header in this article", they
> say "I want to respond to this article." I.e., a followup IS not "any
> article with a References header", it IS "an article posted in response to
> another article". That's an intent on the part of the poster. Notice the
> reference to "IS", and notice that most posters of followups wouldn't
> know  a References header if it bit them.

When writing the standard, when writing the software, and when executing 
the software, we cannot know intent on the part of the (human) poster. A 
mandate in a protocol standard cannot be based on knowing a state of mind; 
it has to be made based on observing an observable action.

If we want to mandate anything based on the term "followup", there has to 
be  some on-the-wire observable difference between "followup" and "not 
followup" - such as the presence of a "References" header.

I actually think you are saying the same thing I'm trying to say, but 
somewhat more loudly. I'll take my own advice and stop posting until I can 
propose a specific text change to the USEFOR document.

                     Harald

To: [email-masked]
Xref: clerew local.usefor:20908
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Mon, 23 May 2005 16:19:44 GMT
Lines: 115
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> you want me to use the term "parent article"? Yes, that
>> might be a way out of it.  Other people happy with that?

>It wasn't my favourite option, because that forces you to
>change many uses of "precursor", even the "precursor" in
>the definition of followup.

No, it puts the definition of "precursor" back exactly how you want it.
A "precursor" is thus one particular example of a "parent".

>Why can't you just say msg-id in the two (?) places where
>you have any precursor != parent article at the moment ?

Because that would make grammatical nonsense.

Here is a revision on the whole text. The references header in USEFOR is
now about as short as it can be (it defers entirely to USEPRO for
constructing it, and you have to work out what it means from the way it is
constructed).

Definitions (for inclusion in USEFOR or USEPRO as appropriate).

   A "followup" is an article containing a response to the contents of an
   earlier article, its "precursor". It will always include a References
   header pointing to that "precursor".

   A "followup agent" is a combination of reading agent and posting
   agent that aids in the preparation and posting of a followup.

Within USEFOR:

3.2.1  References 

|  The References header is used to refer to earlier articles (e.g.
|  followups refer to their precursors), in order to facilitate the
|  display or retrieval, by reading and other agents, of threads of
|  related articles. It is the same as that specified in Section 3.6.4
|  of [RFC2822] with the added restrictions detailed in Section 2.2 and
|  those listed below:

   o  The updated <msg-id> construct defined in Section 3.1.3 MUST
      be used.

   o  Message identifiers MUST be separated with CFWS.

   o  Comments in CFWS between message identifiers can cause
      interoperability problems, so comments SHOULD NOT be generated,
      but MUST be accepted.

|  references      =  "References:" SP [CFWS] msg-id *(CFWS msg-id )
|                     [CFWS] CRLF

|  The process of generating a References header is set out in [USEPRO].

Within USEPRO:

7.6.  Duties of a Followup Agent

.......

   4. The followup MUST have a References header referring to its
      precursor, constructed in accordance with section 7.6.1 below.
 
        NOTE: That "MUST" ensures compliance with the definition of the
        term "followup". It is to be contrasted with the weaker
        recomendation using "SHOULD" applied, in [RFC 2822], to the
        generation of "replies" in email. Moreover, in Netnews, there is
        no expectation of any In-Reply-To header in a followup.
 
7.6.1.  Construction of the References header

   The following procedure is to be used whenever some earlier article
   (the "parent") is to be referred to in the References header (F-
   3.2.1) of a new article, whether in the course of generating a
   followup or for some other reason (e.g. the later parts of a
   multipart posting such as a FAQ, or the later parts of a
   message/partial as suggested in [RFC 2046]).

   If the parent did not have a References header, the content of the
   new article's References header MUST be inherited from that of the
   Message-ID header of the parent, otherwise (there already was a
   References header) it MUST be comprised of the parent's References
   header (subject to trimming as described below) followed by CFWS and
   the Message-ID header content of the parent.

   If the resulting References header is excessively long it MAY (and if
   its total length, whether folded or not, exceeds 998 chacacters it
   MUST) then be trimmed, but the first and the last two message
   identifiers MUST NOT be removed.

        NOTE: There is no provision in this standard for an article to
        have more than one parent. The essential property of the
        References header, guaranteed by the procedure above and to be
        preserved in any future extension, is that no article can ever
        precede one of its own parents.

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

Date: Mon, 23 May 2005 13:57:48 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>If a followup (a term defined for News only) is a message that contains a 
>References header, then all followups have to contain a References header.

A perfectly circular line of reasoning. A meaningless definition.  And one
that doesn't match current usage. People today do not say "I'm creating a
followup because I'm putting a References header in this article", they
say "I want to respond to this article." I.e., a followup IS not "any
article with a References header", it IS "an article posted in response to
another article". That's an intent on the part of the poster. Notice the
reference to "IS", and notice that most posters of followups wouldn't know 
a References header if it bit them.

Prior to the latest versions of the draft, you could DETECT a followup by
seeing the References header, but that, alas, is gone. DETECT is not IS. 
The two are different. But, if you lose the ability to DETECT, then who 
cares what IS? You may have said "I intend this TO BE a followup", but if 
I cannot look at your article and DETECT that intent, so what? You may 
have INTENDED that your article be displayed in large, green flashing 
letters, but without a header that conveys that intent, so what? 

>So it's mandatory, but it's kind of saying that all persons named Smith 
>have to have the name "Smith" - true, but not a terribly interesting 
>statement.

Yes, that's true. And it results in the argument that we are permitted to
apply an RFC2119 "MUST" to it because that's the only way to make the
definition true. If we define it to be mandatory, then obviously we have
to say it is mandatory, even if there is no other reason for being
mandatory than "we say it is." A poor definition leads to an abuse of the
mandates of RFC2119.  "We say it is" is not one of the justifications
RFC2119 supports.

>A point I expect to repeat a LOT over the next weeks:
>If you want to change the text in a draft, please state:

I'm quite happy with a non-mandatory References header, as long as our
drafts are consistent with that position. They aren't. USEFOR is fine the
way it is; USEPRO should be written to match it. All that takes is 
removing the MUST being proposed regarding the use of the header in 
"followups", whatever those might be.

However, those who want to return a mandate to the use of the header
SHOULD be the ones providing proposed changes to the text that would
support that mandate, including justification for an RFC2119 mandate. It
was removed from the official drafts sent to the IETF, so putting it back
is more than just an "oops we forgot" kind of thing. It's supposed to be a
reflection of group consensus at that point, and since we apparently
agreed it wasn't mandatory anymore, it will take some considerable
convincing to change that status.  I look forward to reading these
proposals.

>I think that's more likely to achieve a testable consensus......

If you think we need a "testable consensus" about whether RFC2822 means
what it says when it says "optional", or instead we can interpret it the
way we want it to be, then there is a problem larger than just an editor
who deliberately misrepresents the positions of group participants. And if 
the drafts submitted as official working drafts from this group do NOT 
reflect consensus, after this many years, then is there any hope of them 
ever doing so?

Date: Mon, 23 May 2005 19:20:16 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

Easy folks.....

--On 23. mai 2005 10:02 -0700 John Stanley <[email-masked]> wrote:

>>> Oops, no we haven't. Which is it? Optional or mandatory?
>
>> Mandatory in followups.
>
> Please read RFC2822. Sometime before you send the next draft out, ok?

If a followup (a term defined for News only) is a message that contains a 
References header, then all followups have to contain a References header.

So it's mandatory, but it's kind of saying that all persons named Smith 
have to have the name "Smith" - true, but not a terribly interesting 
statement.
---------------------- mantra -----------------------------
A point I expect to repeat a LOT over the next weeks:
If you want to change the text in a draft, please state:

- The draft number, the section and the paragraph number
- The old text you want to change
- The new text you want to replace it with.

I think that's more likely to achieve a testable consensus......

                Harald

Date: Mon, 23 May 2005 10:15:55 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Status request: Who's following this group?
Sender: [email-masked]

I would have responded by email directly as requested, but 
<harald@xxxxxxxxxxxxx> is an invalid address.

I'm following this group, read the documents, and am willing to review new 
versions carefully when asked.

Date: Mon, 23 May 2005 10:02:04 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>Which is it?

>Wherever they finish up during the final tidying up operations ...

Since what they say depends on where they are, how do you expect 
discussion on something you won't tell us which document it is going in?

>>Incorrect, for all the same reasons I've pointed out already.

>That, or something pretty close to it, has already been agreed in
>principle by the other members of this WG.

The other members of this working group do not get to change RFC2822 no 
matter how strongly they feel RFC2822 is broken. The best they can do is 
state that our definition of something differs from RFC2822 (if there is 
sufficient reason), and since we have chosen not to do that, then RFC2822 
applies. 

>AIUI, our Chair has already ruled that the SHOULD in RFC 2822 is a
>protocol issue, 

It does not matter. It appears in RFC2822, and we refer explicitely to
RFC2822. In for a penny, in for a pound. Like I said, we don't get to
modify RFC2822, only the drafts regarding news. We have shown that we
clearly DO know how to list differences between our use of References and
that in RFC2822 and have just as clearly NOT listed "mandatory" as one of
them. That's an explicit adoption of the "optional" nature of References. 
I'm fine with that. Just be honest enough to admit it has happened and we 
can move on.

>>Oops, no we haven't. Which is it? Optional or mandatory?

>Mandatory in followups.

Please read RFC2822. Sometime before you send the next draft out, ok?

>>This is a ridiculous excuse for inserting a MUST modifier.

>There might be other ways of expressing it,

You can express it any way you like, but it is still a ridiculous reason 
for claiming RFC2119 language is justified. 

> ... but clearly anything that is mandatory MUST be present. 

You've just exhibited the textbook circular argument. It is mandatory so 
it MUST be present, and it MUST be present cause you say it is mandatory. 
Justify the mandate. Once. Show an interoperability issue.

>We need to define the terms "followup" and "precursor". 

Not if they are meaningless. Since you cannot identify what is and is not 
a followup anymore, that term is useless. Lack of followup identification 
makes identifying precursors just as meaningless.

>We are agreed that
>the definition of "followup" will contain the fact that it always includes
>a References header.

No, we are not agreed on any such thing, since RFC2822 clearly says 
otherwise.

>>Mail replies are no news followups.

>Indeed, and everyone here (except John) agrees with that.

STOP PUTTING FUCKING WORDS IN MY MOUTH, CHARLES. Do NOT pretend to speak 
for me, and do NOT pretend that you have any clue as to what I think, 
since you are so patently and stupidly wrong about it every time you try.
Alexey, I'm tired of this crap. We need a different editor. When do you 
think you might have the courtesy of at least acknowledging my email to 
you about this problem?

MAIL replies are not news anything, and you know I have not said
otherwise. RFC2822 does not limit itself to mail when it speaks about the
References header and replies. Don't be dishonest and try to claim that
RFC2822 is explicitely only for mail, since WE EXPLICITELY REFER to
RFC2822 for the definition of a NEWS header. Either RFC2822 is MAIL ONLY
and we have no business referring to it, or it is for MESSAGES IN GENERAL
and we can refer to it freely. 

>But the world
>out there, especially the email pundits in the IETF and many implementors
>of 2nd rate user agents, still believe that News is just Email with a few
>funny bits tacked on.

And just why do you think they would think differently, when this working
group is saying essentially the same thing by its deference to RFC2822
except for the "funny bits"?

>So we need to make that point, and also to point out
>that we don't do In-Reply-To (otherwise Bruce will be along to tell us
>that RFC 2822 requires it :-( ).

I guess I should be relieved that you are now picking a different target 
for your ventriloquism act.

To: [email-masked]
Xref: clerew local.usefor:20907
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fixed
Date: Mon, 23 May 2005 15:32:30 GMT
Lines: 45
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> o even though commonly derived from <domain-name>s,

>They are domains, domain literals, pseudo-domains (like
>the old UUCP notation for UUCP hosts in s-o-1036), or
>ersatz-subdomains based on real domains.

Sure. And if any of those things are normally handled case-insensitively,
then you had better forget that when it is incorporated in an <id-right>.
By all means, use [email-masked] in your msgid, but once you have made
your choice, that choice is fixed for the rest of eternity (or at least so
long as anybody needs to keep or refer to that article).

>A <domain-name> is not yet defined in 2822 or usefor-03,
>you probably mean <domain>-names.

Good point. Actually, saying just "<domain>s" is enough.

   o even though commonly derived from <domain>s, <id-right>s are 
     case-sensitive (and thus, once created, are not to be altered
     during subsequent transmission or copying).
> 
>> it is only "for the removal of all doubt".

>It's important, this will be the "real" msg-id replacing
>whatever all former RfCs said about it.

OK, you seem to be asking for that text (or something like it) to be
included. I see Henry also wants it in. I would therefore recommend Ken to
include it.

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

Date: Mon, 23 May 2005 08:44:44 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Poll results, membership and commitment
Sender: [email-masked]

So far, about 20 people (out of 49 subcribers) have answered my poll.
Most people gave a "range" for their commitment out of my list, so I'm 
giving "ranges" for how many people are in each category:

1 (glance): 6-3 (pessimist says 6, optimist says 3)
2 (read): 10-8
3 (comment): 4-6
4 (review): 0-3

To me, this indicates that we have a serious risk of a shortage of 
reviewers, but still have some interest..... I hope it's enough to make a 
decent finish for the documents.

              Harald

Date: Sat, 21 May 2005 12:31:57 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Fixed
Sender: [email-masked]

On Fri, 20 May 2005, Charles Lindsey wrote:
> So do we want to include that in USEFOR? It is strictly redundant as I
> said in reply to Harald, so it is only "for the removal of all doubt".

Removal of doubt, especially on issues where historically there has *been*
considerable doubt, is a good thing.  Put it in.

                                                          Henry Spencer
                                                       [email-masked]

Date: Sat, 21 May 2005 11:12:12 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Suggested References texts
Sender: [email-masked]

On Sat, 21 May 2005, Frank Ellermann wrote:
> Looking through s-o-1036 where that's already mentioned I
> stumbled over this brilliant observation:
> 
> | UNRESOLVED ISSUE: Would it be better to just give up
> | and admit that news uses References for both purposes?
> 
> Yes, it's better to give up now...

In hindsight, it was probably better then too.  There was constant tension
in son-of-1036 between pushing for improvements and acknowledging
unfortunate reality, and in this case, I think I came down on the wrong
side of that fence. 

                                                          Henry Spencer
                                                       [email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Suggested References texts
Date:  Sat, 21 May 2005 13:10:31 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 79
Sender: [email-masked]

Charles Lindsey wrote:

> We agreed months ago that it was legitimate to use the
> References header for things that are not followups

Yes.  More like eleven years ago in my s-o-1036 parallel
universe.  As FidoNet user I was entitled to take a draft
as bible, if everybody told me that it _is_ the bible.

> You cannot go back on that now.

I'm not intending to go back.  I only say that it's not
relevant for the _format_ of this beast, and I'm somewhat
tired of the arguments about it here.  It's a troll, you
are feeding a troll.  What do you hope, that it dies from
congestion ?  You tried this for a year, it's still alive.

> I need a term for "the things that are in the msg-id-list
> of this References header"

How about msg-id (excluding the new CFWS for a second) ?

> I proposed to use the term "precursor".

The msg-id of the precursor is added to the msg-id-list in
a followup.  That doesn't guarantee that all msg-ids found
in a msg-id-list are precursors.  It only guarantees what
happens with the last added msg-id in a followup.

>> The followup agent then prepares anything as necessary,
>> and the user is free to change whatever he wants to change.

> I have never heard that suggested before.

It was in one of those endless "Re: / followup" threads.
Looking through s-o-1036 where that's already mentioned I
stumbled over this brilliant observation:

| UNRESOLVED ISSUE: Would it be better to just give up
| and admit that news uses References for both purposes?

Yes, it's better to give up now.  And without "See-Also"
it's also the only exit.

| NOTE: Subject changes are difficult to determine, but
| they are significant as possible beginnings of new threads.

"We" (= some posters here, not necessarily including you)
came to the conclusion, that users are free to remove the
References if they want to enforce a new thread.  IIRC it
was related to Subject: new topic (was: old topic)

> if the user does do that, then what he has written may no
> longer be a proper followup.

It's most definitely no followup, it might be still a sort
of response trying to start a new thread.  Actually it's a
bad idea, most creative uses of References are bad ideas.

> you want me to use the term "parent article"? Yes, that
> might be a way out of it.  Other people happy with that?

It wasn't my favourite option, because that forces you to
change many uses of "precursor", even the "precursor" in
the definition of followup.

Why can't you just say msg-id in the two (?) places where
you have any precursor != parent article at the moment ?

> The ultimate aim is to bring RFC 2822 and News together
> for the headers they share in common.

Okay, let's hope that UAs don't do too stupid things when
they are forced to fold this header.  A really stupid UA
simply copies the msg-id-list as is and adds a msg-id.

Then it waits for me to fix it when it needs trimming.
And I've an idea how that's supposed to work.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fixed
Date:  Sat, 21 May 2005 12:14:03 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Sender: [email-masked]

Charles Lindsey wrote:

> o even though commonly derived from <domain-name>s,

They are domains, domain literals, pseudo-domains (like
the old UUCP notation for UUCP hosts in s-o-1036), or
ersatz-subdomains based on real domains.  Something with
an owner of the name space.  Random garbage would risk
collisions.  Abuse of foreign name spaces is real abuse.

A <domain-name> is not yet defined in 2822 or usefor-03,
you probably mean <domain>-names.
  
> <id-right>s are case-sensitive (and thus, once created,
> are not to be altered during subsequent transmission or
> copying).

Or other uses like various news-nntp-uri I-Ds desperately
trying to get rid of RfC 1738, which says "host".

RfC 1036 says "full_domain_name".  I proposed "id-domain".
 
> it is only "for the removal of all doubt".

It's important, this will be the "real" msg-id replacing
whatever all former RfCs said about it.  Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20898
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Fri, 20 May 2005 19:51:17 GMT
Lines: 93
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> it is not as simple as that. Look at the new section 7.6.1
>> ("Construction of the References header"). It uses the term
>> "precursor" 8 times, with the meaning "the earlier article
>> that is being included in the References header because of
>> some kind of dependency" (not just a followup).

>Always a followup, with the one exception Followup-To: poster
>- and then it's just the 2822 idea of a reply.  It's always
>as simple as that.  Just strike the note speculating about a
>future followup to more than one article.  And that's USEPRO
>territory, unnecessary in USEFOR.

No, that is the whole point. We agreed months ago that it was legitimate
to use the References header for things that are not followups (multipart
FAQs is the example usually quoted, but there are others), and various
people (notable Russ) have recently reaffirmed that position. You cannot
go back on that now.

So I need a term for "the things that are in the msg-id-list of this
References header" and I proposed to use the term "precursor". If you
don't like that, you are welcome to suggest another term. But you are not
free to rewrite the question to suit your own preconceptions.

>> if you want "precursor" to be just the inverse of followup,
>> then please suggest what other term I might use

>See below, what you have is fine, a "precursor" is the article
>where a reader might wish to post a followup or reply by mail.

No it's NOT. That is the whole point. The text I have written applies to
more than followup agents (though they are the principal customers for
it).

>The followup agent then prepares anything as necessary, and
>the user is free to change whatever he wants to change.

I have never heard that suggested before. But if the user does do that,
then what he has written may no longer be a proper followup.

>> But what is wrong with "precursor"?

>Nothing.  Only the msg-id-list is not necessarily a list of
>"precursors" in the sense of "inverse followups".  If you want
>"precursor" to be "any msg-id in a msg-id-list", then you might
>need a separate "parent article" (as in 2822) for a predecessor
>in the followup algorithm.

OK, so you want me to use the term "parent article"? Yes, that might be a
way out of it. Other people happy with that?

> [comments as in <a@b>()<c@d> MUST be accepted]
>> That particular wording has been in USEFOR for quite some
>> time, and was put there explicitly at Russ's request.

>Jumping from "no comments" (1036 and s-o-1036) to a new "MUST"
>strikes me as odd.  If it causes no trouble with folding it's
>fine.  Otherwise a SHOULD is no nonsense, the only excuse would
>be "old news software".

If the syntax says "comments allowed here", then ipso facto you MUST
accept it if you want to claim compliance. That is the usual way to
introduce a new feature by saying "MUST accept; don't generate yet". In a
later standard you can then safely allow generation.

The ultimate aim is to bring RFC 2822 and News together for the headers
they share in common. Indeed it may be many years before it actually
happens.

>> Sometimes we just buy into whatever introductory explanation
>> is provided by RFC 2822, but that just does not work for
>> References

>Of course it does.

No, various people (notably Ken) have finally agreed that it does not.

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

To: [email-masked]
Xref: clerew local.usefor:20900
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fixed
Date: Fri, 20 May 2005 20:06:00 GMT
Lines: 48
Sender: [email-masked]

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

>On Thu, 19 May 2005, Charles Lindsey wrote:

>> There is indeed a NOTE in USEPRO...
>>         NOTE: Some old software may treat message identifiers that
>>         differ only in case within their <id-right> part as equivalent,
>>         and implementors of agents that generate message identifiers
>>         should be aware of this.
>> but I am unsure as to just what those implementors who are made so aware
>> are actually expected to do about it.

>Perhaps "as equivalent, and thus it is unwise to generate message
>identifiers which differ only in case within <id-right>". 

I like it. Done!

>> What we are discussing now is whether to mention the topic in USEFOR as
>> well, alongside the place where we discuss the other problems with msg-ids
>> arising from unnecessary quoted-strings and quoted pairs. The sentence I
>> have suggested for there is
>> 
>>    o even though commonly derived from <domain-name>s, <id-right>s are
>>      not case-insensitive (and thus, once created, are not to be altered
>>      during subsequent transmission or copying).

>This sounds reasonable, although "not case-insensitive" strikes me as
>awkward and I would be tempted to write that as just "case-sensitive".

OK, I have done that:
   o even though commonly derived from <domain-name>s, <id-right>s are
     case-sensitive (and thus, once created, are not to be altered
     during subsequent transmission or copying).

So do we want to include that in USEFOR? It is strictly redundant as I
said in reply to Harald, so it is only "for the removal of all doubt".

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

To: [email-masked]
Xref: clerew local.usefor:20899
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Case sensitivity: Clear enough? (Re: Fixed)
Date: Fri, 20 May 2005 19:57:06 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>Seems to me we've beaten this particular horse to death.

>To me, the results seem to say:

>- Agents creating message-IDs MUST NOT create two message-IDs where the 
>only difference is in the case of the RHS of the message-ID
>- Agents relaying messages with message-IDs MUST NOT change the case of the 
>message-ID

Indeed, USEPRO does say both those things (see also my reply to Henry).

The only problem is that all the other funnies that affect comparison of
message ids are in USEFOR (because we had to write syntax to fix them).
Therefor, that is where people will look to find this infpormation.
Therefore it is proposed to include a brief mention there.

Yes, it is redundant, but sometime a little redundancy helps, especially
where, as in this case, people regularly jump to the wrong conclusion.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Suggested References texts
Date:  Thu, 19 May 2005 23:32:09 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 112
Sender: [email-masked]

Charles Lindsey wrote:

> it is not as simple as that. Look at the new section 7.6.1
> ("Construction of the References header"). It uses the term
> "precursor" 8 times, with the meaning "the earlier article
> that is being included in the References header because of
> some kind of dependency" (not just a followup).

Always a followup, with the one exception Followup-To: poster
- and then it's just the 2822 idea of a reply.  It's always
as simple as that.  Just strike the note speculating about a
future followup to more than one article.  And that's USEPRO
territory, unnecessary in USEFOR.

The Re: / followup issue was discussed here for about one year,
now it's time to move on as far as USEFOR is concerned.

> if you want "precursor" to be just the inverse of followup,
> then please suggest what other term I might use

See below, what you have is fine, a "precursor" is the article
where a reader might wish to post a followup or reply by mail.

The followup agent then prepares anything as necessary, and
the user is free to change whatever he wants to change.  Like
deleting all references (= new thread) or maybe only the last
reference.  The effect of the latter might be a valid followup
to the precursor of the precursor.  It could be also undefined,
if the precursor was no followup.  Nobody cares about all odd
cases as long as reading agents can handle _any_ msg-id-list in
the References.

> But what is wrong with "precursor"?

Nothing.  Only the msg-id-list is not necessarily a list of
"precursors" in the sense of "inverse followups".  If you want
"precursor" to be "any msg-id in a msg-id-list", then you might
need a separate "parent article" (as in 2822) for a predecessor
in the followup algorithm.

Or if you want "precursor" for this predecessor, then you might
need something else for "any msg-id in a msg-id-list".  I'd
prefer the latter, most of the time you need "precursor" in
this sense.

 [comments as in <a@b>()<c@d> MUST be accepted]
> That particular wording has been in USEFOR for quite some
> time, and was put there explicitly at Russ's request.

Jumping from "no comments" (1036 and s-o-1036) to a new "MUST"
strikes me as odd.  If it causes no trouble with folding it's
fine.  Otherwise a SHOULD is no nonsense, the only excuse would
be "old news software".

> Sometimes we just buy into whatever introductory explanation
> is provided by RFC 2822, but that just does not work for
> References

Of course it does.

> One of the things it needs to make clear is that it deals
> with "followups" rather than "replies"

For Followup-To: poster it's a reply (unless the author wants
a followup, etc.), otherwise it's a followup (unless the author
wants a reply, or both, or a new thread, etc.)  It's obvious.
Tons of text won't change it.

> it is sometimes used for articles that are not followups

Therefore msg-id-list plus a pointer to 2822 is good enough.

> A References header indicates the previously posted context
> in which the article was created.

Maybe it doesn't, maybe it's just a list of msg-ids related to
something the poster had in mind  (= a new context created by
the poster).

> B. A semantics paragraph
[...]
> give an algorithm for constructing it

Done in USEPRO and 2822.

> I think that a well-formed References header has to be
> constructed according to USEPRO (or RFC 2822 if it was
> gatewayed from email).

At too many points that's not guaranteed to be the case.

> it might help to say "a well-formed References header" to
> emphasise the point that it needs to be more than
> syntactically correct if it is to be of any use for its
> intended purposes.

Intentionally creating a context like multipart FAQs or other
creative uses can still have a valid purpose, even if it's
not suited for threading.  Or what with followups respecting a
Followup-To: other-NG (or poster) ?  Reading agents might have
some difficulties with threading in these cases.  But they can
still (try to) allow access on each msg-id in the msg-id-list.

>> UAs should survive such "attacks".
> They will survive them, but they might thread them in funny
> ways

Let them just do their best and everybody is happy.  If the
poster gets some flames for creative References it's what he
asked for.
                            Bye, Frank

Date: Thu, 19 May 2005 12:43:40 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Fixed
Sender: [email-masked]

On Thu, 19 May 2005, Charles Lindsey wrote:
> >...generators must avoid generating forms differing only in case, and
> >generators checking for collisions must use case-insensitive comparison,
> >but for all other purposes, comparisons must be case-sensitive.
> 
> But do generators actually need to do such checks?

Sensible ones, no; the intent was to say that if they do such checks for
some strange reason, this is how they must do them.

My overall point is that I think it's unwise to assume that "comparisons" 
are done only at the receiving end -- sufficiently warped software might
do them in the generator as well. 

> There is indeed a NOTE in USEPRO...
>         NOTE: Some old software may treat message identifiers that
>         differ only in case within their <id-right> part as equivalent,
>         and implementors of agents that generate message identifiers
>         should be aware of this.
> but I am unsure as to just what those implementors who are made so aware
> are actually expected to do about it.

Perhaps "as equivalent, and thus it is unwise to generate message
identifiers which differ only in case within <id-right>". 

Actually, at least one piece of old software did case-insensitive
comparison of the *whole* message ID, and if we wanted to use that as
an excuse, it could yield a simplified wording:

        NOTE: Some old software may treat message identifiers that
        differ only in case as equivalent, so message identifiers
        should differ in more than just case.

> What we are discussing now is whether to mention the topic in USEFOR as
> well, alongside the place where we discuss the other problems with msg-ids
> arising from unnecessary quoted-strings and quoted pairs. The sentence I
> have suggested for there is
> 
>    o even though commonly derived from <domain-name>s, <id-right>s are
>      not case-insensitive (and thus, once created, are not to be altered
>      during subsequent transmission or copying).

This sounds reasonable, although "not case-insensitive" strikes me as
awkward and I would be tempted to write that as just "case-sensitive". 

                                                          Henry Spencer
                                                       [email-masked]

To: [email-masked]
Subject: Re: Fixed
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 19 May 2005 09:42:05 -0700
Sender: [email-masked]

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

>> I'm fine with that.  It can just be a difficult thing to change in
>> running software.  (For example, changing INN to use a case-sensitive
>> comparison method for the RHS of message IDs will require a complete
>> history rebuild after an upgrade and the loss of all information about
>> previously rejected messages that had a message ID with a RHS that
>> wasn't all-lowercase.)

> Is that because there really are examples differing only in case in real
> current history files, or is it because what you currently store in
> history files is a hash of the msg-id, and you would have to move to a
> different hashing algorithm? In which case, probably better to leave it
> be.

The latter.  INN doesn't remember the message ID itself, only a hash of
the message ID, and case folding is applied before hashing.  So the
original case of the message IDs has been lost, and can only be
reconstructed for the articles presently in the spool.

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

To: [email-masked]
Xref: clerew local.usefor:20890
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fixed
Date: Thu, 19 May 2005 15:27:50 GMT
Lines: 24
Sender: [email-masked]

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

>I'm fine with that.  It can just be a difficult thing to change in running
>software.  (For example, changing INN to use a case-sensitive comparison
>method for the RHS of message IDs will require a complete history rebuild
>after an upgrade and the loss of all information about previously rejected
>messages that had a message ID with a RHS that wasn't all-lowercase.)

Is that because there really are examples differing only in case in real
current history files, or is it because what you currently store in
history files is a hash of the msg-id, and you would have to move to a
different hashing algorithm? In which case, probably better to leave it
be.

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

To: [email-masked]
Xref: clerew local.usefor:20888
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fixed
Date: Thu, 19 May 2005 15:16:58 GMT
Lines: 64
Sender: [email-masked]

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

>On Wed, 18 May 2005, Seth Breidbart wrote:
>> So we should specify that generators ought to treat them as identical,
>> and comparators ought to treat them as different.

>Right idea, but the first part is confusingly worded.  Better is to say
>that generators must avoid generating forms differing only in case, and
>generators checking for collisions must use case-insensitive comparison,
>but for all other purposes, comparisons must be case-sensitive.

But do generators actually need to do such checks? RFC 2822 recommends
(SHOULD) that the id-right should be a domain-name (or an IP if you are
desperate) which is under your own control, and you then make the id-left
unique amongst all the things you generate. We inherit that recommendation
from RFC 2822. Even if the domain name that you insert is sometimes in UC
and sometimes in LC, they should still be distinguishable via the id-left,
and if not then the people who control that domain have screwed up
horribly.

There is indeed a NOTE in USEPRO (which Frank has drawn attention to) and
which has been in our drafts from time immemorial:

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

but I am unsure as to just what those implementors who are made so aware
are actually expected to do about it.

As to the second part, there is already the following in USEPRO:

        NOTE: Even though commonly derived from the domain name of the
        originating site (and domain names are case-insensitive), a
        message identifier MUST NOT be altered in any way during
        transport, or when copied (as into a References header), and
        thus a simple (case-sensitive) comparison of octets will always
        suffice to recognize that same message identifier wherever it
        subsequently reappears.

What we are discussing now is whether to mention the topic in USEFOR as
well, alongside the place where we discuss the other problems with msg-ids
arising from unnecessary quoted-strings and quoted pairs. The sentence I
have suggested for there is

   o even though commonly derived from <domain-name>s, <id-right>s are
     not case-insensitive (and thus, once created, are not to be altered
     during subsequent transmission or copying).

and I think that is sufficient to make the point (and to do so without
being accused of bringing protocol issues into USEFOR, which our Chair
doesn't like).

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

To: [email-masked]
Xref: clerew local.usefor:20889
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Additional WG chair for the USEFOR working group
Date: Thu, 19 May 2005 15:22:51 GMT
Lines: 27
Sender: [email-masked]

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

>Yes, a "last call USEFOR -05" in May, or rather two weeks after
>all attempts to find some interesting bugs in draft -04 failed.

Not a cat in hell's chance of that. Quite apart from the issues we are
currently discussing (Path, Message-ID and References) there are serious
problems with the Newsgroups and Injection-Info headers which I haven't
even raised yet (because we can't handle too many topics at the same
time).

And even when all the technical issues are properly covered, there is
still the collected syntax, IANA considerations, and documentation of
differences from RFC 2822 to do, plus the changes since RFC 1036, which
are currently sitting in USEPRO, but may well finish up as an appendix in
USEFOR.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Case sensitivity: Clear enough?
Date:  Thu, 19 May 2005 17:14:15 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> beaten this particular horse to death.

Finding a living horse here is unlikely.

> Makes sense?

Yes, two clear MUST NOT are fine.

> this is about behaviour not syntax - does it
> belong in USEPRO?

So far the article syntax / format is in USEFOR, 
the detailed semantics / protocol is in USEPRO.

> X.400(84)...... it's not a new kind of problem..

Don't mention MIXER - Bruce can ride any horse, 
dead or alive.
                      Bye, Frank

Date: Thu, 19 May 2005 16:23:51 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Re: Case sensitivity: Clear enough? (Re: Fixed)
Sender: [email-masked]

--On torsdag, mai 19, 2005 10:08:30 -0400 Bruce Lilly <[email-masked]> 
wrote:

>> Makes sense?
>
> It does not account for gateways, where case may change...

Have you ever seen a gateway causing a case change?

Date: Thu, 19 May 2005 14:23:48 +0100
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: USEFOR ABNF check
Sender: [email-masked]

Frank Ellermann wrote:

>Did anybody try an ABNF checker on usefor-03 ?  (I didn't)
>
I just did and there are couple of errors (in both cases a rule got renamed in one place but not in another).

Date: Thu, 19 May 2005 14:22:22 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Case sensitivity: Clear enough? (Re: Fixed)
Sender: [email-masked]

Seems to me we've beaten this particular horse to death.

To me, the results seem to say:

- Agents creating message-IDs MUST NOT create two message-IDs where the 
only difference is in the case of the RHS of the message-ID
- Agents relaying messages with message-IDs MUST NOT change the case of the 
message-ID
- If the two rules above are followed, agents matching message-IDs can do 
whatever they like (compare with or without case folding) without any 
problem being caused.

Makes sense?
And, since this is about behaviour not syntax - does it belong in USEPRO?

                    Harald

PS: The first time I encountered this kind of language in a standard was in 
X.400(84)...... it's not a new kind of problem..

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fixed
Date:  Thu, 19 May 2005 11:46:23 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> draft-ietf-dnsext-insensitive-05

Yes, I recall its funny "historical note" about "upper case".
That won't help with any obscure id-(domain / right) issues.

"News servers SHOULD compare a msg-id respecting its case,
 but MAY also compare id-(domain / right) case-insensitively,
 and therefore posting agents SHOULD NOT create any msg-id
 differing from another msg-id only in the case of the
 id-(domain / right)."

A headache for USEPRO.  But it might be what s-o-1036 said.
At the moment USEPRO has:

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

Date: Thu, 19 May 2005 08:14:37 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: RT (Re: Additional WG chair for the USEFOR working group)
Sender: [email-masked]

--On torsdag, mai 19, 2005 03:16:19 +0200 Frank Ellermann 
<[email-masked]> wrote:

>> introduce some new tools to the group - namely, formal
>> tracking of unresolved issues using RT (on rt.psg.com)
>
> The RT beast kills attempts for normal discussions with its
> weird subject tags, it probably also kills your time.  I'm
> not exactly happy with it in LTRU.  One thing you could try
> to make it more user friendly is to replace its subjects
> "[ticket number] issue text" by "issue text [ticket number]".

My last experience with RT as an active user was on the IETF list - we did 
not let the robots post to the list there, someone copied the relevant 
pieces of discussion into RT by hand.

Somewhat high workload, but kept the robot subject lines away.

                    Harald

Date: Thu, 19 May 2005 07:50:50 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: Fixed
Sender: [email-masked]

--On torsdag, mai 19, 2005 06:16:12 +0200 Frank Ellermann 
<[email-masked]> wrote:

>> OK, give me a more precise pointer to RFC 3???.
>
> RfC 3467 and RfC 3696 are not what I meant, that leaves about
> 998 3???, if it was only an I-D I'm lost.  Not in card-clarify
> and not in dns-choices, whatever it was, it was last year.  If
> I find it I'll tell you.

Thought I'd heard of this before...

draft-ietf-dnsext-insensitive-05. Was before the IESG at the end of March; 
discussion about implications for future CLASSes prevented it going forward.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fixed
Date:  Thu, 19 May 2005 06:16:12 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Charles Lindsey wrote:

> I have seen Bruce Lilly make exactly this argument with his
> usual vehenence.

And I've seen him claiming that USEFOR is essentially dead, and
that 2234bis is erroneous, so his POV is not *always* the only
possible POV.  In the case of domains in a msg-id I seriously
doubt that you talked about the same issue.

> OK, give me a more precise pointer to RFC 3???.

RfC 3467 and RfC 3696 are not what I meant, that leaves about
998 3???, if it was only an I-D I'm lost.  Not in card-clarify
and not in dns-choices, whatever it was, it was last year.  If
I find it I'll tell you.
                        Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Additional WG chair for the USEFOR working group
Date:  Thu, 19 May 2005 03:16:19 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 31
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> put together some realistic - and hopefully short -
> schedules for finishing the USEFOR and USEPRO documents,

Please don't make it too short for USEPRO.  For USEFOR it's
no problem, e.g. all "open points" about the 2045/2231 ABNF
were in fact hallucinations on my side - I didn't know the
prose-val trick to import ugly syntax for say a "parameter".

> introduce some new tools to the group - namely, formal
> tracking of unresolved issues using RT (on rt.psg.com)

The RT beast kills attempts for normal discussions with its
weird subject tags, it probably also kills your time.  I'm
not exactly happy with it in LTRU.  One thing you could try
to make it more user friendly is to replace its subjects
"[ticket number] issue text" by "issue text [ticket number]".

> RFC 3934.

IMHO no.

> hoping for a positive move forward

Yes, a "last call USEFOR -05" in May, or rather two weeks after
all attempts to find some interesting bugs in draft -04 failed.

                          Bye, Frank

Date: Wed, 18 May 2005 18:36:00 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Fixed
Sender: [email-masked]

On Wed, 18 May 2005, Seth Breidbart wrote:
> So we should specify that generators ought to treat them as identical,
> and comparators ought to treat them as different.

Right idea, but the first part is confusingly worded.  Better is to say
that generators must avoid generating forms differing only in case, and
generators checking for collisions must use case-insensitive comparison,
but for all other purposes, comparisons must be case-sensitive.

                                                          Henry Spencer
                                                       [email-masked]

To: [email-masked]
Subject: Re: Fixed
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 18 May 2005 15:25:11 -0700
Sender: [email-masked]

Seth Breidbart <[email-masked]> writes:
> Russ Allbery <[email-masked]> wrote:

>> I'll warn again like I did on the NNTP mailing list: Existing software
>> does not treat <[email-masked]> and <[email-masked]> as distinct message IDs and anyone
>> relying on software to do so will be very sad.

> I take it you mean _some_ existng software, right?

Right, I tend to use those terms synonymously and add the "all" if I
really mean all existing software, but that's a sloppy practice and I
don't always stick with it uniformly.

> So we should specify that generators ought to treat them as identical,
> and comparators ought to treat them as different.

Right.

> We should (I believe) also state that comparators that treat them as
> identical are broken.  (Generators that treat them as different aren't
> broken per se, they just won't interoperate well with broken
> comparators.)

I'm fine with that.  It can just be a difficult thing to change in running
software.  (For example, changing INN to use a case-sensitive comparison
method for the RHS of message IDs will require a complete history rebuild
after an upgrade and the loss of all information about previously rejected
messages that had a message ID with a RHS that wasn't all-lowercase.)

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

Date: Wed, 18 May 2005 18:05:45 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: Fixed
Sender: [email-masked]

Russ Allbery <[email-masked]> wrote:

> I'll warn again like I did on the NNTP mailing list: Existing
> software does not treat <[email-masked]> and <[email-masked]> as distinct message IDs
> and anyone relying on software to do so will be very sad.

I take it you mean _some_ existng software, right?

So we should specify that generators ought to treat them as identical,
and comparators ought to treat them as different.  We should (I
believe) also state that comparators that treat them as identical are
broken.  (Generators that treat them as different aren't broken per
se, they just won't interoperate well with broken comparators.)

Seth

To: [email-masked]
Subject: Re: Fixed
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 18 May 2005 11:33:28 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Seth Breidbart <[email-masked]> writes:

>> Elsewhere we specify that the _comparison_ is case-sensitive; <[email-masked]>
>> and <[email-masked]> are *different* message IDs.

> Do we? I don't think we do, which is why I want to make sure it is fixed
> here.

I'll warn again like I did on the NNTP mailing list:  Existing software
does not treat <[email-masked]> and <[email-masked]> as distinct message IDs and anyone
relying on software to do so will be very sad.  This is not something that
I see changing sufficiently to start relying on that property within the
next five years.

I have no problem with specifying that case *insensitivity* should *also*
not be relied upon, but giving people the impression that using <[email-masked]>
and <[email-masked]> as distinct message IDs will work is doing them a disservice,
IMO.

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

Date: Wed, 18 May 2005 14:29:13 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Fixed
Sender: [email-masked]

On Wed, 18 May 2005, Charles Lindsey wrote:
> That is dangerous stuff, and has given rise to a widespread belief that,
> as a domain, ExAmPlE.CoM is everywhere interchangeable with example.com or
> EXAMPLE.COM. Why else have some (not all) implementors built that in to
> their msg-id comparisons, in the belief they were doing the "right thing"?
> 
> I still think we need a sentence like the one I gave, just for the removal
> of all doubt. But it is for the WG to agree or disagree with that
> suggestion.

There is long-standing confusion about this.  We definitely need to
address this explicitly and unambiguously. 

                                                          Henry Spencer
                                                       [email-masked]

To: [email-masked]
Xref: clerew local.usefor:20875
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fixed
Date: Wed, 18 May 2005 12:42:18 GMT
Lines: 53
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> someone is going to argue that they should be
>> case-insensitive.

>That's not the case.

Oh yes it is! I have seen Bruce Lilly make exactly this argument with his
usual vehenence.

> Only the _comparison_ of domain names for
>the purposes of DNS is case insensitive.  There's a separate
>RfC 3??? explaining this issue, and it took me some time to get
>this important detail.

OK, give me a more precise pointer to RFC 3???.  

>Actually it's already clear in RfC 1034, I was only too stupid
>to see it there (grep ASCII in RfC 1034).

No, that is not clear enough to be Lilly-safe, though it helps.

>> What does RFC 2822 say on the subject?

>Nothing, ...

It says, with respect to <domain>s,

   ... In the dot-atom form, this is interpreted as an Internet
   domain name (either a host name or a mail exchanger name) as
   described in [STD3, STD13, STD14].

That is dangerous stuff, and has given rise to a widespread belief that,
as a domain, ExAmPlE.CoM is everywhere interchangeable with example.com or
EXAMPLE.COM. Why else have some (not all) implementors built that in to
their msg-id comparisons, in the belief they were doing the "right thing"?

I still think we need a sentence like the one I gave, just for the removal
of all doubt. But it is for the WG to agree or disagree with that
suggestion.

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

To: [email-masked]
Xref: clerew local.usefor:20874
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fixed (was: Broken Message-ID syntax)
Date: Wed, 18 May 2005 12:26:11 GMT
Lines: 40
Sender: [email-masked]

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

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

>> However, if <id-right>s are going to look like domain-names (as RFC
>> 2822 RECOMMENDS and Frank insists), then someone is going to argue
>> that they should be case-insensitive.

>That makes no sense; it isn't a string that's case-insensitive, but a
>comparison.

Doesn't stop the pedants from using that argument :-( .

>>   o even though commonly derived from <domain-name>s, <id-right>s are
>>     NOT case-insensitive (and thus, once created, are not to be altered
>>     during subsequent transmission or copying).

>"MUST NOT be altered" is fine.

Maybe. I avoided RFC 2119 language here because transmission and copying
are USEPRO issues, and our Chair likes to keep them out of USEFOR (hence
also why the remark was in parentheses). But rest assured that USEPRO
_does_ include MUST NOT wording to cover this.

>Elsewhere we specify that the _comparison_ is case-sensitive; <[email-masked]>
>and <[email-masked]> are *different* message IDs.

Do we? I don't think we do, which is why I want to make sure it is fixed
here.

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

To: [email-masked]
Xref: clerew local.usefor:20873
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path header: suggested texts
Date: Wed, 18 May 2005 12:20:09 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> "Scott Hollenbeck" <[email-masked]> writes:

>> There was one request that an IPv6 example should be included in the
>> example in Usepro 7.3.1 (there is already an IPv4 example). 

>See RFC 3849:

Which reserves 2001:DB8::/32 in the same way that TLD example is reserved.

>Something like "2001:DB8:0:0:8:800:200C:417A" (or anything in 2001:DB8::/32)
>could work.

OK, I have now changed the example to use that in place of the existing
IPv4 (or does anybody think that we need examples of both)?

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

Date: Wed, 18 May 2005 15:33:45 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Status request: Who's following this group?
Sender: [email-masked]

As part of "figuring out where we are", I'd like to ask you to say 
"hello"...

if you could all send me a message saying one of:

- I'm following this group, but only glancing at it
- I'm following this group, and reading the messages, but not responding 
much
- I'm following this group, reading, and responding whenever I feel that my 
response can contribute something
- I'm following this group, read the documents, and am willing to review 
new versions carefully when asked

that would be most helpful to give me an idea of what size this group 
actually is, and how much work we can expect people to be willing to 
undertake.
Of course, those who do not read the list won't respond at all :-)

Please respond to me only - no need to clutter up the list!

                 Harald

Date: Wed, 18 May 2005 15:22:07 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Additional WG chair for the USEFOR working group
Sender: [email-masked]

Hello,

Scott Hollenbeck and Alexey have asked me to take a stint as an additional 
working group chair for the USEFOR WG.

As far as I can tell from the documents and discussion, the group is fairly 
close to being able to emit some documents; this is good - but the group 
has also been working on these documents since 1998 (when I was its first 
AD, in fact), without finishing any - which is a VERY long time for an IETF 
working group.

We'll be trying to put together some realistic - and hopefully short - 
schedules for finishing the USEFOR and USEPRO documents, check that the 
group has enough energy to do the finishing work, and introduce some new 
tools to the group - namely, formal tracking of unresolved issues using RT 
(on rt.psg.com) and a stricter enforcement of the list behaviour rules from 
RFC 3934.

This also means that we'll be calling on the document editors to check what 
they think the status of their docs is, and what a realistic schedule for 
completion is.

We'll be sending out a few more "status request" messages pretty soon now, 
to make sure we have a realistic expectation of how and when we can finish 
the group's work.

I don't expect to be WG chair for more than about 3 months - after that, I 
expect that either the group is finished or Alexey will be able to handle 
the rest of the group's work on his own.

Here's hoping for a positive move forward!

                      Harald Alvestrand

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Fixed
Date:  Wed, 18 May 2005 02:42:55 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Charles Lindsey wrote:

> someone is going to argue that they should be
> case-insensitive.

That's not the case.  Only the _comparison_ of domain names for
the purposes of DNS is case insensitive.  There's a separate
RfC 3??? explaining this issue, and it took me some time to get
this important detail.  

Actually it's already clear in RfC 1034, I was only too stupid
to see it there (grep ASCII in RfC 1034).

> What does RFC 2822 say on the subject?

Nothing, it's not concered with comparing Message-IDs.  STD 13
is relevant, never ever touch the case of a domain.  Bye, Frank

Date: Tue, 17 May 2005 17:09:30 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: Fixed (was: Broken Message-ID syntax)
Sender: [email-masked]

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

> However, if <id-right>s are going to look like domain-names (as RFC
> 2822 RECOMMENDS and Frank insists), then someone is going to argue
> that they should be case-insensitive.

That makes no sense; it isn't a string that's case-insensitive, but a
comparison.

>   o even though commonly derived from <domain-name>s, <id-right>s are
>     NOT case-insensitive (and thus, once created, are not to be altered
>     during subsequent transmission or copying).

"MUST NOT be altered" is fine.

Elsewhere we specify that the _comparison_ is case-sensitive; <[email-masked]>
and <[email-masked]> are *different* message IDs.

Seth

To: [email-masked]
Xref: clerew local.usefor:20865
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Tue, 17 May 2005 19:13:35 GMT
Lines: 181
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> there was some concern as to the amount of semantics to be
>> included in Usefor.

>Already resolved:  Absolutely no extra-semantics in USEFOR
>excl. the one addition confirmed by Ken:

>news://news.gmane.org/[email-masked]
>http://mid.gmane.org/[email-masked]

That article only deals with some definitions. It says nothing about what
goes into the section defining the Rererences header. See
<[email-masked]> for where Ken agrees that it needs more than
it has currently got.

>> (for inclusion in USEFOR or USEPRO as appropriate).

>Certainly not in USEFOR.  The terse definitions in USEFOR
>based on a general understanding of 2822 are fine.

We need to define the terms "followup" and "precursor". We are agreed that
the definition of "followup" will contain the fact that it always includes
a References header.

You want "precursor" to be defined as the inverse of "followup", but it is
not as simple as that. Look at the new section 7.6.1 ("Construction of the
References header"). It uses the term "precursor" 8 times, with the
meaning "the earlier article that is being included in the References
header because of some kind of dependency" (not just a followup). I need
some such term, so if you want "precursor" to be just the inverse of
followup, then please suggest what other term I might use, or explain how
to write that section without any special term at all.

But what is wrong with "precursor"? It is availble free of charge, and
does not come with any baggage of widespread usage in the world out there.

>> o  The updated <msg-id-core> construct defined in Section
>>    3.1.3 MUST be used.

>s/msg-id-core/msg-id/g

Yes, that will get fixed when Ken adopts the suggested Message-ID texts.

>> interoperability problems, so comments SHOULD NOT be
>> generated, but MUST be accepted.

>s/, but MUST be accepted//   The "interoperability problem" is
>that this might not work as expected, and a worldwide update
>of servers, UAs, and gateways at a future date X is impossible.
>The best you can get is SHOULD.

It follows the general principle (which has always been in our drafts)
that there are some things which the Netnews world simply must catch up
with in the interests of consistency, and so we make it an issue of full
compliance. Not that we expect existing implementations to become
compliant overnight, but we expect them to do so eventually (and not to
hide behind that "SHOULD NOT generate (yet)" for ever and ever).

That particular wording has been in USEFOR for quite some time, and was
put there explicitly at Russ's request.

Now we come to the "semantics" wording that is to go with USEFOR 3.2.1.
There are two paragraphs that I have suggested, and they serve different
purposes:

A. An introductory paragraph to explain what the header is there for.
Every other header we introduce has such an introduction, as do all the
headers introduced in RFC 2822 (see my article
<[email-masked]> for lots of examples).

Sometimes we just buy into whatever introductory explanation is provided
by RFC 2822, but that just does not work for References, so we need to
roll our own. One of the things it needs to make clear is that it deals
with "followups" rather than "replies", and another is that it is
sometimes used for articles that are not followups (see the discussion
that followed Ken's <[email-masked]>, and in particular my
<[email-masked]>).

It does not have to use the text I have suggested, and for example Forrest
suggested
     A References header indicates the previously posted context in which
     the article was created.
(which is a bit too bare, but it might be worked up into something more
suitable).

B. A semantics paragraph, explaining what this header "means". There are
two ways of doing this; either says what it means, or else give an
algorithm for constructing it (and let people work out from the
construction method what it means). RFC 2822 chose the latter method, and
now that I have written USEPRO 7.6.1 we could do the same (but it is a
long way from USEFOR 3.2.1 to USEPRO 7.6.1). Anyway, the possibility of
removing or simplifying that paragraph does now exist, and so it is open
for discussion.

>> |  The list is composed of message identifiers of precursors

>No, that is not the case.  It's just a msg-id-list, and nobody
>knows all details.  Maybe it was recursively created as defined
>in 2822 and USEPRO, maybe not.

I think that a well-formed References header has to be constructed
according to USEPRO (or RFC 2822 if it was gatewayed from email).

>>| The process of generating a References header by a followup
>>| agent is set out in [USEPRO].

>That's the only addition I might agree with, if you promise
>that it's the final word about this issue in USEFOR.

Yes, that sentence is needed, and it might help to say "a well-formed
References header" to emphasise the point that it needs to be more than
syntactically correct if it is to be of any use for its intended purposes.

> [USEPRO]
>> 4. The followup MUST have a References header referring to
>>    its precursor

>s/MUST have/has/ because otherwise it can't be a followup.

No, look at the rest of USEPRO 7.6. There is a whole succession of SHOULDs
for what is to go in the Newsgroups, Subject and Distribution headers
(which we discussed at length last year, and which we sure don't want to
go over again). It needs to be immediately clear that the requirement for
the References header is stronger than in those cases.

And also we need a MUST word somewhere here in order to point out that it
is more than the SHOULD in RFC 2822. But the wording of the next bit can
be discussed (for example, one might put the 'compliance with definition
stuff' in parentheses after the MUST in the first paragraph, or one might
leave it out altogether).

>> NOTE: That "MUST" ensures compliance with the definition of
>>       the term "followup".

>> It is to be contrasted with the weaker recomendation using
>> "SHOULD" applied, in [RFC 2822], to the generation of
>> "replies" in email.

>Mail replies are no news followups.

Indeed, and everyone here (except John) agrees with that. But the world
out there, especially the email pundits in the IETF and many implementors
of 2nd rate user agents, still believe that News is just Email with a few
funny bits tacked on. So we need to make that point, and also to point out
that we don't do In-Reply-To (otherwise Bruce will be along to tell us
that RFC 2822 requires it :-( ).

>> NOTE: There is no provision in this standard for an article
>> to have more than one precursor.

>Delete.  I can (ab)use References as See-Also or In-Reply-To
>as I see fit.  UAs should survive such "attacks".

They will survive them, but they might thread them in funny ways if they
ignore my "essenntial property" advice. Note that RFC 2822 makes the same
point regarding replying to more than one message, so it is quite in order
for us to do the same (and indeed that wording has been in USEPRO and
ARTICLE before it for a long time - I have just moved it to a more
convenient location).

Actually, when the time for a multi-precursor followup does come, by own
view is that the way to do it with minimum breakage of the existing setup
wold be just to allow more than one References header. But that is a
battle for another day.

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

To: [email-masked]
Xref: clerew local.usefor:20866
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Obsolete vs. obsolescent
Date: Tue, 17 May 2005 19:15:44 GMT
Lines: 21
Sender: [email-masked]

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

>So, how about the following:

>  As a result, this header is to be regarded as obsolescent, and it will
>  be removed entirely in a future version of this standard.
>  Servers and clients SHOULD ignore it, and SHOULD NOT generate it.

OK, but s/it will be removed/it is likely to be removed/. No point in
giving unnecessary hostages to fortune.

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

To: [email-masked]
Xref: clerew local.usefor:20867
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fixed (was: Broken Message-ID syntax)
Date: Tue, 17 May 2005 19:45:14 GMT
Lines: 43
Sender: [email-masked]

I think my suggested Message-ID text is now more or less stabilized, but
there is a point that recently came up on the NNTP list that maybe ought
be be covered.

We are agreed, AIUI, that "a simple comparison of octets will always
suffice to determine the identity of two <msg-id>s" (since we went to a
lot of trouble to eliminate problems with quoted-strings and quoted-pairs
appearing in places where they were not necessary).

However, if <id-right>s are going to look like domain-names (as RFC 2822
RECOMMENDS and Frank insists), then someone is going to argue that they
should be case-insensitive.

Which is of course a complete nonsense (some news servers go to the
trouble of doing a case-insensitive comparison of <id-right>s, but that is
tiemn consuming and unnecessary and, moreover, a whole bunch of other
servers don't).

Question. What does RFC 2822 say on the subject? IMO RFC 2822 is OK
because the object on the right of a msg-id is an <id-right>, and nowhere
does it say that <id-right>s are case insensitive. They may be created
looking like domain names but, once created (whether in UC or LC or even
as "ExAmPlE.CoM") nobody has any business altering them en route (and it
is a MUST NOT in USEPRO). Note that it was NOT so in RFC 822.

However, not everyone shares my view (a certain Mr Lilly, for example).
So, for the removal of all doubt, should we be saying something like

   .....
   o even though commonly derived from <domain-name>s, <id-right>s are
     NOT case-insensitive (and thus, once created, are not to be altered
     during subsequent transmission or copying).

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

Date: Tue, 17 May 2005 10:41:27 -0700
From: Bill Fenner <[email-masked]>
Reply-To: Bill Fenner <[email-masked]>
To: Frank Ellermann <[email-masked]>
Subject: Re: More pretty graphs
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On 5/17/05, Frank Ellermann <[email-masked]> wrote:
> Nice.  I know that I need glasses, but maybe you could arrange
> for bigger figures with a bigger font size ?

Frank,

  I used PDF because most PDF viewers allow zooming and panning.  I've
left graphviz to decide on the layout itself, since for complex groups
(see some of the larger PDF files), there's no way to sensibly
influence the graph layout.

  Bill

Date: Tue, 17 May 2005 18:12:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Path header: suggested texts
Sender: [email-masked]

Charles Lindsey wrote:

>In <[email-masked]> Alexey Melnikov <[email-masked]> writes:
>  
>
>>Charles Lindsey wrote:
>>    
>>
>>>>>| In order to prevent overloading, relaying agents should
>>>>>| not routinely query an external entity (such as a DNS-
>>>>>| server) in order to verify an article (though a local cache
>>>>>| of the required information might usefully be consulted).
>>>>>          
>>>>>
>>>Another Brad Templeton-ism which has been in our drafts since whenever.
>>>Anybody else want to to remove it? I could be easily persuaded.
>>>      
>>>
>>Yes, please.
>>    
>>
>
>OK, it's gone.
>
>There have been few other comments on these Path header texts. Can I take
>it that my text, with the change I out in in response to Frank and the
>above omission is now considered acceptable?
>  
>
I've quickly scanned through the suggestions for USEFOR and they mostly 
looked Ok.
I haven't looked at the USEPRO bits.

>There was one request that an IPv6 example should be included in the
>example in Usepro 7.3.1 (there is already an IPv4 example). Since I have
>never seen an IPv6 in the wild, please could someone suggest a suitably
>plausible example to include (I know nothing about the IPv6 conventions,
>and wouldn't want it to look silly)?
>  
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Charles Lindsey'" <[email-masked]>, [email-masked]
Subject: RE: Path header: suggested texts
Date: Tue, 17 May 2005 12:44:29 -0400
Importance: Normal
Sender: [email-masked]

> There was one request that an IPv6 example should be included in the
> example in Usepro 7.3.1 (there is already an IPv4 example). 
> Since I have
> never seen an IPv6 in the wild, please could someone suggest 
> a suitably
> plausible example to include (I know nothing about the IPv6 
> conventions,
> and wouldn't want it to look silly)?

See RFC 3849:

ftp://ftp.rfc-editor.org/in-notes/rfc3849.txt

Something like "2001:DB8:0:0:8:800:200C:417A" (or anything in 2001:DB8::/32)
could work.

-Scott-

To: [email-masked]
Xref: clerew local.usefor:20864
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Tue, 17 May 2005 14:53:26 GMT
Lines: 74
Sender: [email-masked]

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

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>Definitions (for inclusion in USEFOR or USEPRO as appropriate).

>Which is it?

Wherever they finish up during the final tidying up operations - most
likely USEFOR in these cases. But for the moment the definitions are
included in both, until we see which definitions are actually used in
which document.

>>   A "followup" is an article containing a response to the contents of
>>   an earlier article. It will always include a References header
>>   pointing to that earlier article and other "precursors".

>Incorrect, for all the same reasons I've pointed out already.

That, or something pretty close to it, has already been agreed in
principle by the other members of this WG.

>>Within USEFOR:

>>3.2.1  References 

>None of which are a mandate for its use. It is optional, according to 
>RFC2822. Fine. References is now optional.

AIUI, our Chair has already ruled that the SHOULD in RFC 2822 is a
protocol issue, and that it suffices for us to deal with it in USEPRO. No
doubt Alexey will correct me if I am wrong.

>>7.6.  Duties of a Followup Agent

>>   4. The followup MUST have a References header referring to its
>>      precursor, constructed in accordance with section 7.6.1 below.

>Oops, no we haven't. Which is it? Optional or mandatory?

Mandatory in followups.

>>        NOTE: That "MUST" ensures compliance with the definition of the
>>        term "followup". 

>This is a ridiculous excuse for inserting a MUST modifier.

There might be other ways of expressing it, but clearly anything that is
mandatory MUST be present. But the main reason for that mention in the
NOTE was so that the distinction between the SHOULD for replies in RFC
2822 could be drawn, and I think it is important to make that point.

>>   The following procedure is to be used whenever some precursor article
>>   is to be included in the References header (F-3.2.1) of a new
>>   article,

>There is no way to include a precursor article in the References header. 
>The References header contains only message ids; nothing else. The only 
>part of a precursor that may appear in a References header is the message 
>id content. 

OK, it now says "... whenever the message identifier of some precursor article
is to be included ...".

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

To: [email-masked]
Xref: clerew local.usefor:20863
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path header: suggested texts
Date: Tue, 17 May 2005 14:23:25 GMT
Lines: 40
Sender: [email-masked]

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

>Charles Lindsey wrote:

>>>>| In order to prevent overloading, relaying agents should
>>>>| not routinely query an external entity (such as a DNS-
>>>>| server) in order to verify an article (though a local cache
>>>>| of the required information might usefully be consulted).
>>>>      
>>>>
>>
>>Another Brad Templeton-ism which has been in our drafts since whenever.
>>Anybody else want to to remove it? I could be easily persuaded.
>>  
>>
>Yes, please.

OK, it's gone.

There have been few other comments on these Path header texts. Can I take
it that my text, with the change I out in in response to Frank and the
above omission is now considered acceptable?

There was one request that an IPv6 example should be included in the
example in Usepro 7.3.1 (there is already an IPv4 example). Since I have
never seen an IPv6 in the wild, please could someone suggest a suitably
plausible example to include (I know nothing about the IPv6 conventions,
and wouldn't want it to look silly)?

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: More pretty graphs
Date:  Tue, 17 May 2005 11:05:32 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Cc: [email-masked]
Sender: [email-masked]

Bill Fenner wrote in <ietf.ietf.org>:

> http://rtg.ietf.org/~fenner/ietf/deps/viz/
[...]
> Feedback is welcome.

Nice.  I know that I need glasses, but maybe you could arrange
for bigger figures with a bigger font size ?  I've tested...

<http://rtg.ietf.org/~fenner/ietf/deps/viz/usefor-norm.pdf>

...and there five rows (two for the key, three for USEFOR)
could work.
                            Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Suggested References texts
Date:  Tue, 17 May 2005 09:34:04 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 94
Sender: [email-masked]

Charles Lindsey wrote:

> there was some concern as to the amount of semantics to be
> included in Usefor.

Already resolved:  Absolutely no extra-semantics in USEFOR
excl. the one addition confirmed by Ken:

news://news.gmane.org/[email-masked]
http://mid.gmane.org/[email-masked]

> reduced the amount of text intended for USEFOR slightly

Less than zero additional text makes no sense.  Modulo some
syntax oddities USEFOR is ready.

> (for inclusion in USEFOR or USEPRO as appropriate).

Certainly not in USEFOR.  The terse definitions in USEFOR
based on a general understanding of 2822 are fine.

> o  The updated <msg-id-core> construct defined in Section
>    3.1.3 MUST be used.

s/msg-id-core/msg-id/g

> interoperability problems, so comments SHOULD NOT be
> generated, but MUST be accepted.

s/, but MUST be accepted//   The "interoperability problem" is
that this might not work as expected, and a worldwide update
of servers, UAs, and gateways at a future date X is impossible.
The best you can get is SHOULD.

> |  The list is composed of message identifiers of precursors

No, that is not the case.  It's just a msg-id-list, and nobody
knows all details.  Maybe it was recursively created as defined
in 2822 and USEPRO, maybe not.

The USEFOR section 3.2.1 should not be modified in any way,
excl. the proper syntax:

[...]
| o  The updated <msg-id> construct defined in Section 3.1.3
|    MUST be used.
[...]
|    but SHOULD be accepted.
[...]
| references       =   "References:" SP msg-id-list CRLF
| msg-id-list      =   [CFWS] msg-id *( CFWS msg-id ) [CFWS]

> That is a minimal wording

No, it's not, the minimum is zero and good enough.  USEFOR is
about the article FORmat, and not a lesson in acyclic graphs or
data structures.

>| The process of generating a References header by a followup
>| agent is set out in [USEPRO].

That's the only addition I might agree with, if you promise
that it's the final word about this issue in USEFOR.

 [USEPRO]
> 4. The followup MUST have a References header referring to
>    its precursor

s/MUST have/has/ because otherwise it can't be a followup.

> NOTE: That "MUST" ensures compliance with the definition of
>       the term "followup".

Delete.  IMNSHO RfC 2119 does not justify to abuse MUST for a
mere definition.

> It is to be contrasted with the weaker recomendation using
> "SHOULD" applied, in [RFC 2822], to the generation of
> "replies" in email.

Mail replies are no news followups.  News has no In-Reply-To,
mail has no Followup-To, let alone any "Followup-To: poster".

Essentially what you proposed, but please get rid of the MUST.

> NOTE: There is no provision in this standard for an article
> to have more than one precursor.

Delete.  I can (ab)use References as See-Also or In-Reply-To
as I see fit.  UAs should survive such "attacks".  I have some
doubts about my own UA and articles referencing themselves. :-(

                       Bye, Frank

Date: Mon, 16 May 2005 14:17:47 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Suggested References texts
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Definitions (for inclusion in USEFOR or USEPRO as appropriate).

Which is it?

>   A "followup" is an article containing a response to the contents of
>   an earlier article. It will always include a References header
>   pointing to that earlier article and other "precursors".

Incorrect, for all the same reasons I've pointed out already.

>Within USEFOR:

>3.2.1  References 

>        It is the
>|  same as that specified in Section 3.6.4 of [RFC2822] with the added
>|  restrictions detailed in Section 2.2 and those listed below:

None of which are a mandate for its use. It is optional, according to 
RFC2822. Fine. References is now optional. We've picked a position are are 
going to stick with it, I hope.

>7.6.  Duties of a Followup Agent

>   4. The followup MUST have a References header referring to its
>      precursor, constructed in accordance with section 7.6.1 below.

Oops, no we haven't. Which is it? Optional or mandatory?

>        NOTE: That "MUST" ensures compliance with the definition of the
>        term "followup". 

This is a ridiculous excuse for inserting a MUST modifier. It doesn't even
begin to meet the requirements of RFC2119 for justifying such a mandate.  
If the only reason something MUST be done is to follow some definition,
then there certainly is no interoperability issue and no justification for
a MUST. There is no interoperability issue. None has every been shown to
exist. Drop the MUST and make this section conform to the existing USEFOR
specification.

>                         It is to be contrasted with the weaker
>        recomendation using "SHOULD" applied, in [RFC 2822],

And applied in USEFOR, by referring to RFC2822. 

>   The following procedure is to be used whenever some precursor article
>   is to be included in the References header (F-3.2.1) of a new
>   article,

There is no way to include a precursor article in the References header. 
The References header contains only message ids; nothing else. The only 
part of a precursor that may appear in a References header is the message 
id content. 

I have written a response to your last set of insults and attempted oral
word insertions that I have passed to Alexey. I just wanted you to know
that I did not miss or ignore them. The short version is you can keep your
crap about "smoke and mirrors" and repeated deliberate misinterpretations
of what I have said to yourself. Should you stop putting words in my mouth 
and pretending I've said things I have not, I'll probably stop demanding 
that you be removed as editor. It's your choice.

Date: Mon, 16 May 2005 20:45:29 +0100
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Obsolete vs. obsolescent
Sender: [email-masked]

Frank Ellermann wrote:

>Ken Murchison wrote:   
>
>>Care to craft some text and tell me where you'd like to see
>>it?
>>    
>>
>IMHO all that should be done is to update this statement:
>
>| As a result, this header is to be regarded as obsolete, and
>| it will likely be removed entirely in a future version of
>| this standard.
>
>  As a result, this header is to be regarded as obsolescent.
>  Servers and UAs MUST accept but SHOULD ignore it, and SHOULD
>  NOT generate it.
>
MUST accept (i.e. doesn't break) is implied by RFC 2822, as message 
format is extensible.

So, how about the following:

  As a result, this header is to be regarded as obsolescent, and it will
  be removed entirely in a future version of this standard.
  Servers and clients SHOULD ignore it, and SHOULD NOT generate it.

>For the obsolete headers in 3.3 you already have a definition:
>
>| Articles containing these headers MUST NOT be generated.
>| Persons writing new agents SHOULD ignore any former meanings
>| these headers.
>  
>

To: [email-masked]
Xref: clerew local.usefor:20858
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Suggested References texts
Date: Mon, 16 May 2005 16:42:12 GMT
Lines: 126
Sender: [email-masked]

When I posted the previous suggestions for the References header texts,
there was some concern as to the amount of semantics to be included in
Usefor. I suggested, in reply, that it might be better for USEPRO to include
a general section describing how to generate a proper References header,
applicable to more than followups, and to invoke that section when
describing the duties of a followup agent. I have now done this, and have
reduced the amount of text intended for USEFOR slightly (if people want it
reducing more, then speak up, but I still think all that remains is useful).

I have also covered the matter of References headers in message/partial
briefly in USEPRO, so that I think they need no longer be mentioned in
USEFOR beyond pointing out, perhaps, that it is not customary to use them
on Usenet.

I have also introduced a MUST requirement for trimming References headers,
as requested by Frank (formerly this was only a matter of USEAGE, but I
know of followup/reply agents that unfold References headers and omit to
refold them afterwards, with consequent breakage).

Share and Enjoy!

Definitions (for inclusion in USEFOR or USEPRO as appropriate).

   A "followup" is an article containing a response to the contents of
   an earlier article. It will always include a References header
   pointing to that earlier article and other "precursors".

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

   A "followup agent" is a combination of reading agent and posting
   agent that aids in the preparation and posting of a followup.

Within USEFOR:

3.2.1  References 

|  The References header is used in followups, and other articles with
|  related precursors, to facilitate the display or retrieval, by
|  reading and other agents, of threads of related articles. It is the
|  same as that specified in Section 3.6.4 of [RFC2822] with the added
|  restrictions detailed in Section 2.2 and those listed below:

   o  The updated <msg-id-core> construct defined in Section 3.1.3 MUST
      be used.

   o  Message identifiers MUST be separated with CFWS.

   o  Comments in CFWS between message identifiers can cause
      interoperability problems, so comments SHOULD NOT be generated,
      but MUST be accepted.

|  references      =  "References:" SP [CFWS] msg-id *(CFWS msg-id )
|                     [CFWS] CRLF

|  The list is composed of message identifiers of precursors of the
|  current article, sorted so that no article precedes any of its own
|  precursors. It SHOULD include both the earliest and the immediate
|  precursors on the current article, even if some of the intermediate
|  ones are omitted.
[That actually defines a partial list. Even though USEPRO makes no
provsision for followups to several articles, people are bound to try to
do it. That is a minimal wording which reduces to the usual linear list
in the case of followups to a single precursor.]
|
|  The process of generating a References header by a followup agent is
|  set out in [USEPRO].

Within USEPRO:

7.6.  Duties of a Followup Agent

.......

   4. The followup MUST have a References header referring to its
      precursor, constructed in accordance with section 7.6.1 below.
 
        NOTE: That "MUST" ensures compliance with the definition of the
        term "followup". It is to be contrasted with the weaker
        recomendation using "SHOULD" applied, in [RFC 2822], to the
        generation of "replies" in email. Moreover, in Netnews, there is
        no expectation of any In-Reply-To header in a followup.
 
7.6.1.  Construction of the References header

   The following procedure is to be used whenever some precursor article
   is to be included in the References header (F-3.2.1) of a new
   article, whether in the course of generating a followup or for some
   other reason (e.g. the later parts of a multipart posting such as a
   FAQ, or the later parts of a message/partial as suggested in [RFC
   2046]).

   If the precursor did not have a References header, the content of the
   new article's References header MUST be inherited from that of the
   Message-ID header of the precursor, otherwise (the precursor already
   had a References header) it MUST be comprised of the precursor's
   References header (subject to trimming as described below) followed
   by CFWS and the Message-ID header content of the precursor.

   If the resulting References header is excessively long it MAY (and if
   its total length, whether folded or not, exceeds 998 chacacters it
   MUST) then be trimmed, but the first and the last two message
   identifiers MUST NOT be removed.

        NOTE: There is no provision in this standard for an article to
        have more than one precursor. The essential property of the
        References header, guaranteed by the procedure above and to be
        preserved in any future extension, is that no article can ever
        precede one of its own precursors.

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

Date: Sun, 15 May 2005 23:23:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Path header: suggested texts
Sender: [email-masked]

Charles Lindsey wrote:

>>>| In order to prevent overloading, relaying agents should
>>>| not routinely query an external entity (such as a DNS-
>>>| server) in order to verify an article (though a local cache
>>>| of the required information might usefully be consulted).
>>>      
>>>
>
>Another Brad Templeton-ism which has been in our drafts since whenever.
>Anybody else want to to remove it? I could be easily persuaded.
>  
>
Yes, please.

>>IMHO you could delete this note, DNS is not that vulnerable,
>>and we don't want an excessively long Usepro.  But I'm still
>>curious about this FQDN mailable underline, it's odd.
>>    
>>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: CFWS
Date:  Tue, 10 May 2005 08:44:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Charles Lindsey wrote:

> I thought that IS what Frank wanted.

It's tricky, you're both right ;-)  We all don't want adjacent
msg-ids as in <a@b><c@d> because it's not allowed in s-o-1036.

We want <a@b> <c@d> or in other words msg-ids separated by
FWS.  You want CFWS, your [CFWS] was a typo.  A simple parser
looking for LWSP separated "words" cannot handle what you
want, which allows <a@b>(bad)<c@d>

But enforcing <a@b> (good) <c@d> in ABNF is so difficult that
we used CFWS as a somewhat foul compromise.  And you're again
forced to add tons of verbose text explaining why there is a
CFWS in the ABNF, and that nobody should use it unless he's
suicidal or lives in the 22nd century when all UAs know how
to parse <a@b>(bad><c@d> correctly, e.g. if they wish to fold
very long References correctly.

                     Sigh, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2045 ABNF
Date:  Tue, 10 May 2005 08:19:48 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 44
Sender: [email-masked]

Charles Lindsey wrote:
 
>> mail-complaint-to=(\")"\"omigod\"\@example.com"(\") ?
 
> No, because '(\")"\"omigod\"\@example.com"(\")' is not a
> token.

True, but I thought - maybe I'm wrong - that (\") is a CFWS,
and that "\"omigod\"\@example.com" is a token.

> Indeed, but Ned claims it was an omission. We could say it
> explicitly in our Injection-Info text if you think it
> necessary.

Explicitly say _what_ ?  If it's a parameter compatible with
RfC 2231, you can't have more than one mail-complaint-to=

That's again this logic thing, if we want zero or more of
these beasts, they can't be RfC 2231 parameters, and they
also can't be RfC 2045 parameters as amended by RfC 2231.

The MIME term "parameter" is strictly out if we insist on
zero or more, but we're free to define say "param" copying
the RfC 2045 syntax (after a transformation to ABNF).

That has nothing to do with Ned, it was Bruce who detected
this 2231 effect when we discussed it here the first time:

<http://mid.gmane.org/[email-masked]>
 
> I don't think we want other than "at most one
> complaints-to-parameter", but that parameter can currently
> contain one or more mail addresses

That's a new idea, an address-list as value.  Your example...

mail-complaints-to = "\"Abuse Department\" <[email-masked]>"

...is apparently even a mailbox list.  Are we talking about...

mct = "\"abuse \\\"LART\\\" team\" <\"\\\"LART\\\"\"@example>"

...and is this defined in any RfC ?  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Path header: suggested texts
Date:  Tue, 10 May 2005 07:36:15 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 39
Sender: [email-masked]

Charles Lindsey wrote:

 [underline in path identity]
> Seems harmless.

Not when you talk about a "mailable FQDN" later.  I don't say
that it should go, after all it's in s-o-1036, but I try to
understand why it's there in the first place.

> people expect to be able to use '_' in most places where
> ALPHA is allowed.

Not if they want a host name for SMTP, "ldh" has no underline.

>> It also doesn't allow the normal [ip] style of domain
>> literals.

> Why not?

Because you don't have "[" and "]" in your subset.  Sorry, it
wasn't clear what I mean.

>>| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

> Actually it is quite common in Paths. Many relaying agents
> are special purpose machine which have no need of a
> domain-name.

If they have no name or don't know how to find their name it's
a perfect excuse to violate a "SHOULD FQDN".  My mail provider
won't let me send a complaint to say news@[127.34.56.78]  With
dyn. IPs it starts to get really ugly, and for IPv6 literals
I'd be completely lost.

>> the examples should also show an IPv6 domain literal.
> Maybe. I have made a note to look at it.

See RfC 3849 for the details, e.g. 2001:DB8::CD30  Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20851
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CMsg in Subject headers
Date: Mon, 9 May 2005 20:40:45 GMT
Lines: 48
Sender: [email-masked]

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

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

>>> It's okay (and indeed must be okay) to use Subject: cmsg in conjunction
>>> with a Control header, but the Subject following "cmsg" and the
>>> contents of the Control header MUST (SHOULD?  I'd lean towards MUST,
>>> though.)  match.

>> But is there any existing software that will act on the "cmsg" in the
>> Subject when a genuine Control header is present. If, as I suspect, not,
>> then than rather messy check will give no extra protection.

>I can't point you at a specific piece of software, but allowing them to be
>two different things feels like a problem just waiting to happen.  I don't
>like that; it's the sort of thing that makes me very nervous.

Well the present Usenet has not fallen apart yet on that account, so the
problem cannot be that serious. And if the whole concept of 'obeying' a
"cmsg" is to be deprecated, I doubt any upgrade to existing software will
suddenly start to cause it to happen.

I doubt also that implementors will want to implement, since matching two
<control-command>s in the face of allowed syntactic variations is messy,
and to what gain?

>> It seems that there is now a slight majority to include some provision
>> (easily outweighed by the silent majority who have said nothing :-( ). I
>> suspect that it would be better to make such provision in USEPRO, at the
>> same place as the current "cmsg" stuff so as to keep the whole topic in
>> one place. Would the following cover the situation?

>I'd rather add the check above, but other than that, the additional text
>seems to cover the issue.

OK, let that text stand for now.

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

To: [email-masked]
Xref: clerew local.usefor:20849
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path header: suggested texts
Date: Mon, 9 May 2005 20:14:16 GMT
Lines: 69
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>> path-identity   =  ( ALPHA / DIGIT )
>>                   *( ALPHA / DIGIT / "-" / "." / ":" / "_" )

>That last "_" is funny, I found no reason for it in s-o-1036.

Well it's been in all our drafts since article-03. Seems harmless. And
people expect to be able to use '_' in most places where ALPHA is allowed.
A quick search failed to find any in my newsspool, but that does not prove
much.

>It also doesn't allow the normal [ip] style of domain literals.

Why not?

>S-o-1036 stresses that path identities are "case sensitive",
>but I don't get this idea.  Are underline and case sensitive
>only a side-effect of "tail-entry", because it's essentially
>what we'd call a local part today ?

Actually, our previous 'article' drafts have always warned that some
agents treat paths case sensitively and some case insensitively, but I
omitted to include that in my suggested text. It is nothing to do with the
tail-entry. There are agents which do it both ways right through. So I
have augmented my suggested text as follows:

|    NOTE: Although case-insensitive, it is intended that the
|    <path-keyword>s "POSTED" and "MISMATCH" should be in upper case, to
|    distinguish them from the <path-identity>s which are traditionally
|    in lower case. However, that cannot be relied on, and sites should
|    be aware that existing agents may treat <path-identity>s either
|    case sensitively or insensitively. 

>>| In order to prevent overloading, relaying agents should
>>| not routinely query an external entity (such as a DNS-
>>| server) in order to verify an article (though a local cache
>>| of the required information might usefully be consulted).

Another Brad Templeton-ism which has been in our drafts since whenever.
Anybody else want to to remove it? I could be easily persuaded.

>IMHO you could delete this note, DNS is not that vulnerable,
>and we don't want an excessively long Usepro.  But I'm still
>curious about this FQDN mailable underline, it's odd.

>As always I want the STD 11...

>| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

Actually it is quite common in Paths. Many relaying agents are special
purpose machine which have no need of a domain-name.

>...and the examples should also show an IPv6 domain literal.

Maybe. I have made a note to look at it.

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

To: [email-masked]
Xref: clerew local.usefor:20850
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CFWS
Date: Mon, 9 May 2005 20:34:16 GMT
Lines: 37
Sender: [email-masked]

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

>Kai Henningsen wrote:

>> Note that using CFWS there allows <a@b>(nice)<c@d> ... I
>> gather that's not what you wanted.

Actually. I thought that IS what Frank wanted. And when I summarized the
situation as it currently stands (which includes that 'feature') Russ
expressed himself happy with it as a long term aim, so long as it was made
clear it was "do not generate yet".

><a@b>CrLfSp<c@d> should be okay, FWS as separator is fine.

Sure. Never any problem with that.

>FWS [CFWS] FWS is not okay, at least one SP too much, and
>CFWS has its own leading / trailing FWS.  A fresh attempt:

>   msg-id-list = [msg-sep] msg-id *( msg-sep msg-id ) [msg-sep]
>   msg-sep     = FWS [ comment *( [FWS] comment ) FWS ]

>Maybe that's "correct", but it's not "KISS".

Indeed, and it's not what our previous drafts have said, and it is not
what is currently proposed for USEFOR.

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

To: [email-masked]
Xref: clerew local.usefor:20852
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2045 ABNF
Date: Mon, 9 May 2005 20:52:04 GMT
Lines: 66
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> RFC 2231 "Updates 2045"

>Proposed standard, eight years old.  In its current form it
>can't advance to draft standard.  All proposed standards with
>a normative reference to 2231 are stuck -  I've not read the
>39xx RfC trying to get around this issue, maybe it's not that
>bad.  And of course I love RfC 3834.

There are lots of things that will need to be fixed in the Email world
before they can proceed to Draft standard, but that is not our problem.

A lot of them will need to be fixed before Usefor/pro can proceed to Draft
Standard, but that is the least of out worries at the moment :-( .

>>| NOTE: Although the provisions of RFC 2231 for Non-ASCII
>[...]
>It's okay, but actually I'm more interested in the ABNF.

>> 3. There is a uniform procedure for including the <value>
>>    in a quoted-string if it is not a token

>>     mail-complaints-to = "[email-masked]"
>> the quotes round the mail address are obligatory

Because '@' is a tspecial.

>How about mail-complaint-to=(\")"\"omigod\"\@example.com"(\") ?

No, because '(\")"\"omigod\"\@example.com"(\")' is not a token. But you
will need
       mail-complaints-to = "\"Abuse Department\" <[email-masked]>"

>> 4. There can be any number of parameters (but Ned claims
>>    the same token cannot appear more than once).

>That was 2231 logic retrofitted onto 2045.  I claim that this
>is _not_ specified in 2045, and in my parallel universe 2231
>has status "historic".

Indeed, but Ned claims it was an omission. We could say it explicitly in
our Injection-Info text if you think it necessary.

>And we want either zero or more mail-complaints-to, or at most
>one with an address-list (TBD, address-list as value is messy).

>IIRC we already have consensus for "zero or more", and that's
>incompatile with the 2231 idea of a parameter.

I don't think we want other than "at most one complaints-to-parameter", but
that parameter can currently contain one or more mail addresses (just like
a To: header).

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2045 ABNF
Date:  Sun, 08 May 2005 11:54:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 65
Sender: [email-masked]

Charles Lindsey wrote:

>> Ned promised (?) to fix it.
> Did he? Where?

<http://www.imc.org/ietf-usefor/mail-archive/msg00210.html>

He didn't buy my masterplan to "kill" RfC 2231 with its very
own MIME version number, so don't hold your breath.  But if
I stumble over this RfC in two out of two IETF WGs, then it
could be a real problem, not only the normal "PEBKAC".

The boundary*1= etc. trick is IMHO really dangerous.  We only
need one major UA supporting it and the rest of the world
(notably virus scanners) ignoring it.

> RFC 2231 "Updates 2045"

Proposed standard, eight years old.  In its current form it
can't advance to draft standard.  All proposed standards with
a normative reference to 2231 are stuck -  I've not read the
39xx RfC trying to get around this issue, maybe it's not that
bad.  And of course I love RfC 3834.

>| NOTE: Although the provisions of RFC 2231 for Non-ASCII
[...]
It's okay, but actually I'm more interested in the ABNF.

> 3. There is a uniform procedure for including the <value>
>    in a quoted-string if it is not a token

Unclear.  I needed hours to find out that a quoted-pair isn't
allowed in a boundary.  It's also confusing that specials and
tspecials are not the same sets.

>     mail-complaints-to = "[email-masked]"
> the quotes round the mail address are obligatory

How about mail-complaint-to=(\")"\"omigod\"\@example.com"(\") ?

> 4. There can be any number of parameters (but Ned claims
>    the same token cannot appear more than once).

That was 2231 logic retrofitted onto 2045.  I claim that this
is _not_ specified in 2045, and in my parallel universe 2231
has status "historic".  Ned explained that he wanted something
like the "environment" concept, but he didn't say so in 2045.

And we want either zero or more mail-complaints-to, or at most
one with an address-list (TBD, address-list as value is messy).

IIRC we already have consensus for "zero or more", and that's
incompatile with the 2231 idea of a parameter.  Therefore we
can't use the 2231 parameter, and need a shrink to fit variant
of the original 2045 parameter.

> But the benefits of a uniform package like that are lost if
> standards try to pick and choose which bits of it they will
> allow.

Point.  OTOH I'd refuse to implement something as complex as a
compiler if all I want is say the next MIME part.  Or in your
example the complaint address.
                              Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Path header: suggested texts
Date:  Sun, 08 May 2005 10:40:20 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Sender: [email-masked]

Charles Lindsey wrote:
 
> path-identity   =  ( ALPHA / DIGIT )
>                   *( ALPHA / DIGIT / "-" / "." / ":" / "_" )

That last "_" is funny, I found no reason for it in s-o-1036.
 
>| Observe that the syntax does not allow comments within the
>| Path header; this is to simplify processing by relaying and
>| serving agents which have a requirement to process this
>| header extremely rapidly.

It also doesn't allow the normal [ip] style of domain literals.

S-o-1036 stresses that path identities are "case sensitive",
but I don't get this idea.  Are underline and case sensitive
only a side-effect of "tail-entry", because it's essentially
what we'd call a local part today ?

>| In order to prevent overloading, relaying agents should
>| not routinely query an external entity (such as a DNS-
>| server) in order to verify an article (though a local cache
>| of the required information might usefully be consulted).

IMHO you could delete this note, DNS is not that vulnerable,
and we don't want an excessively long Usepro.  But I'm still
curious about this FQDN mailable underline, it's odd.

As always I want the STD 11...

| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

...and the examples should also show an IPv6 domain literal.
And maybe one of these mysterious underlines (not if it's
only for the tail-entry, that would be boring).  Tnx & bye

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: CFWS
Date:  Sat, 07 May 2005 07:10:07 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Kai Henningsen wrote:

> Note that using CFWS there allows <a@b>(nice)<c@d> ... I
> gather that's not what you wanted.

Yes, I know, some months ago (?) in the FWS-thread I found
another syntax with a leading or trailing WSP, but it was
ugly beyond recognition, a decomposed CFWS.

<a@b>CrLfSp<c@d> should be okay, FWS as separator is fine.

FWS [CFWS] FWS is not okay, at least one SP too much, and
CFWS has its own leading / trailing FWS.  A fresh attempt:

   msg-id-list = [msg-sep] msg-id *( msg-sep msg-id ) [msg-sep]
   msg-sep     = FWS [ comment *( [FWS] comment ) FWS ]

Maybe that's "correct", but it's not "KISS".  Bye, Frank

Date: 06 May 2005 13:33:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: CFWS
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Frank Ellermann)  wrote on 04.05.05 in <[email-masked]>:

> Charles Lindsey wrote:

> ACK.  Maybe my idea to enforce at least a FWS as separator,
> the [CFWS] => CFWS modification in msg-id-list, was stupid ?
>
> Or we hope that this is something a future 2822bis would also
> do, because <a@b> <c@d> instead of <a@b><c@d> just is common
> practice, no matter what the proposed standard 2822 proposed.
>
> > Note that USEFOR is taking a stronger line on insisting of
> > at least a SP to separate the references than it is taking
> > on excluding comments.
>
> Yes, see above...
>
> > I think this is because that SP was explicit in RFC 1036
>
> ...and because I wanted it.  But if that's a silly compromise
> we could drop it and let UAs confronted with the proposed 2822
> syntax crash as they see fit.

Note that using CFWS there allows <a@b>(nice)<c@d> ... I gather that's not  
what you wanted.

MfG Kai

To: [email-masked]
Subject: Re: CMsg in Subject headers
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 06 May 2005 10:04:25 -0700
Sender: [email-masked]

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

>> It's okay (and indeed must be okay) to use Subject: cmsg in conjunction
>> with a Control header, but the Subject following "cmsg" and the
>> contents of the Control header MUST (SHOULD?  I'd lean towards MUST,
>> though.)  match.

> But is there any existing software that will act on the "cmsg" in the
> Subject when a genuine Control header is present. If, as I suspect, not,
> then than rather messy check will give no extra protection.

I can't point you at a specific piece of software, but allowing them to be
two different things feels like a problem just waiting to happen.  I don't
like that; it's the sort of thing that makes me very nervous.

> It seems that there is now a slight majority to include some provision
> (easily outweighed by the silent majority who have said nothing :-( ). I
> suspect that it would be better to make such provision in USEPRO, at the
> same place as the current "cmsg" stuff so as to keep the whole topic in
> one place. Would the following cover the situation?

I'd rather add the check above, but other than that, the additional text
seems to cover the issue.

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

To: [email-masked]
Xref: clerew local.usefor:20839
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CMsg in Subject headers
Date: Fri, 6 May 2005 13:15:10 GMT
Lines: 17
Sender: [email-masked]

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

>...  Some posting agents use Subject: cmsg with
>a corresponding Control: cancel, that's common practice.

Sure, but it is not proposed to forbid those.

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

To: [email-masked]
Xref: clerew local.usefor:20840
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CMsg in Subject headers
Date: Fri, 6 May 2005 13:45:59 GMT
Lines: 59
Sender: [email-masked]

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

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

>> I'm actually unsure, but what you have in Usepro is IMHO
>> not yet good enough.  Do we want gateways to do something ?
>> Should "injecting agents" do something ?  Or should they
>> do nothing ?  Some posting agents use Subject: cmsg with
>> a corresponding Control: cancel, that's common practice.

>It's okay (and indeed must be okay) to use Subject: cmsg in conjunction
>with a Control header, but the Subject following "cmsg" and the contents
>of the Control header MUST (SHOULD?  I'd lean towards MUST, though.)
>match.

But is there any existing software that will act on the "cmsg" in the
Subject when a genuine Control header is present. If, as I suspect, not,
then than rather messy check will give no extra protection.

It seems that there is now a slight majority to include some provision
(easily outweighed by the silent majority who have said nothing :-( ). I
suspect that it would be better to make such provision in USEPRO, at the
same place as the current "cmsg" stuff so as to keep the whole topic in
one place. Would the following cover the situation?

   The presence of a Subject header whose content starts with the string
   "cmsg " followed by a <control-command> was construed under [RFC
   1036] as a request to perform that control action (even if no genuine
   Control header was present). Indeed, some implementations went
   further and added the implied Control header before injecting.
   Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the
   Newsgroups header caused the Subject header content (not starting
   with "cmsg" in this case) to be interpreted as a <control-command>.
 
   All these practices are now declared to be Obsolete, and Subject
   headers MUST NOT now be interpreted as <control-command>s under any
   circumstances.
 
[Possible addtional text:]
 
   In order to prevent continuing interpretation of Subject headers in
   this way by existing agents, posting and injecting agents SHOULD
   detect and decline to post articles in which the Subject header
   starts with the word "cmsg" and in which there is no Control header.

The phrase 'the word "cmsg"' is intended to imply that the "cmsg" needs to
be followed by some non-alpha, so "Subject: cmsgrhubarb" would not trigger
the effect.

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

To: [email-masked]
Xref: clerew local.usefor:20841
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2045 ABNF
Date: Fri, 6 May 2005 15:34:23 GMT
Lines: 93
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> we have not agreed to outlaw RFC 2231, mush as we dislike it

>Sure, it's not our business, and Ned promised (?) to fix it.

Did he? Where?

>Why do you want to get into a battle about it, when it's
>easier to ignore it, like RfC 2822 did ?  The 2231 intro
>talks about MIME media types and 2183 disposition values,
>but not everything with an equalsign "=" in its syntax.

RFC 2822 described the format of Email without MIME, though it did point
strongly to RFC 2045 (it is indeed odd that it did not mention RFC 2231
explicitly, but since RFC 2231 "Updates 2045", that hardly matters). At
the time RFC 2231 was written, 2045 and 2183 were the only other standards
using <parameter>s.

>> I have suggested that wording to Ken previously, but he
>> has not incorporated it thus far.

>It's dangerous to say "SHOULD NOT implement another RfC",
>I'd use _any_ other exit if there is another way at all.

OK, How about:

     NOTE: Although the provisions of RFC 2231 for Non-ASCII characters in
     <value>s of <parameter>s provide useful additional functionality,
     those for splitting <value>s over multiple lines offer no additional
     benefit, since the only length limit on header lines specified by
     this standard is an overall 998 octets. That latter mechanism is,
     moreover, somewhat gibbous, and as RFC 2231 itself rrecommends its
     use only where a real need exists, it is better avoided within
     Netnews.

>> the <inj-info-params> were really all parameters, and
>> inherited all the appropriate baggage

>The 2231 baggage isn't appropriate, it's a security loophole.

The "baggage" that comes with all MIME-style parameters, whether in
Content-* headers, or in the Auto-Submitted header, or in our own Archive
and Injection-Info, is as follows:

1. All parameters share the same underlying syntax, so that the same code can
be used to parse them in all headers.

2. [CFWS] is permitted in all of them, in the places as explained
previously.

3. There is a uniform procedure for including the <value> in a quoted-string
if it is not a token (so, for example, in
    mail-complaints-to = "[email-masked]"
the quotes round the mail address are obligatory, which is one of the
things not clear from the current USEFOR draft).

4. There can be any number of parameters (but Ned claims the same token
cannot appear more than once).

5. The order of parameters is insignificant.

6. Parameters with tokens not yet defined by any standard may appear, and
should ne ignored. Thus extensions to the standard may freeely define new
parameters without fear of impacting existing implementations.

7. In particular, parameters with x-tokens may be used freely, whether for
reasons of vanity, for human understanding, or for communication between
consenting parties. How about
    Injection-Info: news.example.com;
          posting-host = dialup.123.456.789.321.example.com;
          x-radius-id = "0123 456 7890"

8. You can use the charset and lang codes from RFC 2231.

9. You can use the multi-line features from RFC 2231.

But the benefits of a uniform package like that are lost if standards try
to pick and choose which bits of it they will allow.

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

To: [email-masked]
Xref: clerew local.usefor:20843
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Path header: suggested texts
Date: Fri, 6 May 2005 16:33:51 GMT
Lines: 216
Sender: [email-masked]

I believe we reached consensus on how to proceed on the Path header. Ny
suggested texts follow.

In Usefor, the text includes:

1. Introduction, as in current Usefor draft

2. Syntax changes to effect the agreed changes.

3. Semantics, to explain the meaning of the various forms of <delimiter>
and <path-keyword>. This corresponds to the much longer text in section
5.6.4 of the old draft-13.

4. Well-formedness rules, taken from the first half of section 5.6.2 of
the old draft-13.

In Usepro, the bulk of the text was already present, and has simply been
updated to reflect the revised provisions. It was based on the second half
of section 5.6.2 and section 5.6.5 of the old draft-13.

So the great bulk of Brad Templeton's original verbose texts has finally
been whittled away.

Share and Enjoy!

In USEFOR

3.1.6  Path 

   The Path header indicates the route taken by an article since its
   injection into the Netnews system.  Each agent that processes an
   article is required to prepend one (or more) identities to this
   header.  This is primarily to enable relaying agents to avoid sending
   articles to sites already known to have them, in particular the site
   they came from, and additionally to permit tracing the route articles
   take in moving over the network, and for gathering Usenet statistics.

   path            =  "Path:" SP path-list CRLF

   path-list       =  [FWS]
|                     *( ( path-identity / path-keyword ) [FWS]
|                        path-delimiter [FWS] ) tail-entry [FWS]

   path-identity   =  ( ALPHA / DIGIT )
                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )

|  path-keyword    = "POSTED" / "MISMATCH"

   tail-entry      =  path-identity

|  path-delimiter  =  "!" / "!!"

|     NOTE: Observe that the syntax does not allow comments within the
|     Path header; this is to simplify processing by relaying and
|     serving agents which have a requirement to process this header
|     extremely rapidly.
[Cf. wording in Newsgroups header. Alternatively, a generic form of this
wording somewhere in section 2, expecially if we extend the class of
headers where comments are excluded.]

|  Each <path-identity> in the <path-list> (excluding the one in the
|  <tail-entry>) indicates, from right to left, the successive agents
|  through which the article has passed. The <keyword> "POSTED"
|  indicates that the agent to its left injected the article. The use of
|  the <path-delimiter> "!!" indicates that the agent to its left claims
|  that the agent to its right was the verified source of the article
|  (whereas the <path-delimiter> "!" implies no such claim). The
|  <keyword> "MISMATCH" indicates that the agent to its right failed to
|  be so verified. The full procedure for constructing a Path header is
|  set out in [USEPRO].

|    NOTE: Historically, the <tail-entry> indicated the name of the
|    sender. If not used for this purpose, the string "not-for-mail" is
|    often used instead (since at one time the whole path could be used
|    as a mail address for the sender).

|    NOTE: Although case-insensitive, it is intended that the
|    <path-keyword>s "POSTED" and "MISMATCH" should be in upper case, to
|    distinguish them from the <path-identity>s which are traditionally
|    in lower case.

|  To ensure that a <path-identity> provides a unique identity for the
|  agent concerned, it SHOULD be one of:
|
|  1. A fully qualified domain name (FQDN) associated with an A record
|     [RFC 1034], which SHOULD identify the actual machine prepending
|     this <path-identity> and, ideally, should also be "mailable" (see
|     below).
|
|  2. A fully qualified domain name (FQDN) associated with an MX record,
|     which MUST be "mailable".
|
|  3. An arbitrary name believed to be unique and registered at least
|     with all sites receiving articles directly from the given site.
|
|  4. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
|     2373] (the requirement to be able to use an <IPv6address> is the
|     reason for including ':' as an allowed character within a <path-
|     identity>).
|
|  The FQDN of an agent is "mailable" if the administrators of that
|  agent can be reached by email using both of the forms "usenet@<FQDN>"
|  and "news@<FQDN>", in conformity with [RFC 2142].
|
|  For an injecting agent, the <path-identity> MUST be option 1 or 2 and
|  the FQDN MUST be mailable, and if the agent offers its services to
|  the general public the form "abuse@<FQDN>" MUST also be available,
|  unless a more specific complaints address has been provided in a
|  <complainto-param> of an Injection-Info header (3.2.13). For other
|  agents, options 1 through 3 are to be preferred.
|

In USEPRO

7.2.1.  Proto-articles

        NOTE: An article that is offered for reinjection has, by
        definition, already been injected once, and is not therefore to
        be considered as a proto-article.  Hence a genuine proto-article
|       will not contain any Injection-Date header nor any "POSTED" in
|       its Path header, though that header MAY contain <path-identity>s
|       corresponding to machines traversed between the posting agent
|       and the injecting agent proper.

7.2.  Duties of an Injecting Agent

   10.It MUST then prepend the <path-identity> of the injecting agent,
|     followed by a '!', the <path-keyword> "POSTED" and a further "!"
|     (or "!!" if appropriate) to the content of the Path header; this
|     SHOULD then be followed by CRLF and WSP if it would otherwise
|     result in a line longer than 79 characters.  The prepended
|     <path-identity> MUST be an FQDN mailable address (F-3.1.6).
 
|       NOTE: This could result in more that one "POSTED" <path-keyword>
        in the case of reinjection.

7.3.  Duties of a Relaying Agent

   1. It MUST establish the trusted identity of the source of the
      article and compare it with the leftmost <path-identity> of the
      Path header's content. If it matches it MUST then prepend its own
|     <path-identity> and a '!!' <path-delimiter> to that content. If
|     it does not match then it prepends instead two entries to that
|     content; firstly the true established <path-identity> of the
|     source followed by a '!', the <path-keyword> "MISMATCH" and a
|     further '!', and then, to the left of that, its own <path-
|     identity> followed by a '!!' <path-delimiter> as usual. This
|     prepending of two entries SHOULD NOT be done if the provided and
|     established identities match. All such prepended material SHOULD
|     be followed by CRLF and WSP if it would otherwise result in a line
|     longer than 79 characters.
 
        NOTE: In order to prevent overloading, relaying agents should
        not routinely query an external entity (such as a DNS-server) in
        order to verify an article (though a local cache of the required
        information might usefully be consulted).

7.3.1.  Path-Header Example

|     Path: foo.isp.example!!foo-server!!
|        bar.isp.example!MISMATCH!10.123.12.2!!old.site.example!barbaz!!
|        baz.isp.example!POSTED!!dialup123.baz.isp.example!not-for-mail
 
        NOTE: That article was injected into the news stream by
|       baz.isp.example, as indicated ny the <path-keyword> "POSTED"
        (complaints may be addressed to [email-masked]). The
|       injector has chosen to record that it got it from
        dialup123.baz.isp.example. "not-for-mail" is a dummy <tail-
        entry>, though sometimes a real userid is put there.

        The article was relayed, perhaps by UUCP, to the machine known,
        at least to old.site.example, as "barbaz".

        Barbaz relayed it to old.site.example, which does not yet
        conform to this standard (hence the '!' <path-delimiter). So one
        cannot be sure that it really came from barbaz.

        Old.site.example relayed it to a site claiming to have the IP
|       address [10.123.12.2], and claiming (by using the '!!' <path-
        delimiter>) to have verified that it came from old.site.example.

        [10.123.12.2] relayed it to "foo-server" which, not being
|       convinced that it truly came from [10.123.12.2], inserted the
|       <path-keyword> "MISMATCH" and then did a reverse lookup on the
        actual source and concluded it was known as bar.isp.example
        (that is not to say that [10.123.12.2] was not a correct IP
        address for bar.isp.example, but simply that that connection
        could not be substantiated by foo-server).  Observe that foo-
        server has now added two entries to the Path.

        "foo-server" is a locally significant name within the complex
        site of many machines run by foo.isp.example, so the latter
|       should have no problem recognizing foo-server and using a '!!'
        <path-delimiter>.  Presumably foo.isp.example then delivered the
        article to its direct clients.

|       It appears that foo-server and barbaz decided to fold the line,
        on the grounds that it seemed to be getting a little too long.

And also several minor consequential changes.

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

To: [email-masked]
Xref: clerew local.usefor:20842
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CFWS
Date: Fri, 6 May 2005 16:12:55 GMT
Lines: 72
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>It is good that you are keeping track.

>Seeing what gets called consensus in this group is always comical.

>Opinions from people who actually know how news works, who have
>actually maintained production software should carry more weight.
>But somehow Usefor is some kind of one-man one-vote come-one come-all
>forum.

That is the way the IETF process is defined to work :-( .

But yes, I do tend to take more note of contributors, such as Russ and
Henry, who have actually been at the sharp end of writing news software,
than I do of some others (names omitted to protect the guilty) who
contribute to this group.

>While I'm here, since I was the person that did the patch set for INN 1.7,
>I get the feeling I should apologize that INN 1.7 remains useful
>so many years later, because it seems to be an impediment to retiring
>and replacing those servers.  Sorry.  I thought I was doing something
>optimally useful at the time.

>In my opinion, current INN 2.x in some applications is as stable as INN 1.7.
>Russ is doing a great job prioritizing INN maintenance, and knows how
>news servers need to interoperate.

Changes we are introducing which impact servers can be divided into three
classes:

1. Features which people would like to use ASAP, but which cannot be
safely used until a substantial number of servers accept them. These
include the folding of Newsgroups headers and the 'mvgroup' control
message.

2. Features whose introduction is useful, but does not break anything when
they start to appear. Examples are the Injection-Date and Injection-Info
headers and the enhancements to the Path header.

3. Features introduced to achieve greater uniformity and consistency,
especially with email. Examples are the introduction of comments in
headers where they were not recognized before (but where there is no great
pressure from people wanting to use them).

I would like to see #1 implemented ASAP (and even hopefully retrofitted to
INN 1.7*). INN 2.n has already done the folding of Newsgroups headers.
Treating 'mvgroup' as a synonym for 'newgroup' is minimally conformant and
will allow it to be used; providing its additional (and desirable) bells
and whistles is then for class #2, and will happen if/when there is
pressure to do so. I would also like any remaining treatment of 'cmsg' as
a Control message clobbered ASAP (presumably that is just a matter of
disabling the relevant code).

Class #2 features can be introduced as convenient, or as popular pressure
demands.

Class #3 features are clearly at the back of the queue, and if only Russ
would say "not in my foreseeable future" rather than "never", that would
be fine by 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

To: [email-masked]
Subject: Re: CMsg in Subject headers
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 05 May 2005 17:47:42 -0700
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:

> I'm actually unsure, but what you have in Usepro is IMHO
> not yet good enough.  Do we want gateways to do something ?
> Should "injecting agents" do something ?  Or should they
> do nothing ?  Some posting agents use Subject: cmsg with
> a corresponding Control: cancel, that's common practice.

It's okay (and indeed must be okay) to use Subject: cmsg in conjunction
with a Control header, but the Subject following "cmsg" and the contents
of the Control header MUST (SHOULD?  I'd lean towards MUST, though.)
match.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: CMsg in Subject headers
Date:  Fri, 06 May 2005 02:09:24 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Sender: [email-masked]

Charles Lindsey wrote:

> I believe Frank is opposed

I'm actually unsure, but what you have in Usepro is IMHO
not yet good enough.  Do we want gateways to do something ?
Should "injecting agents" do something ?  Or should they
do nothing ?  Some posting agents use Subject: cmsg with
a corresponding Control: cancel, that's common practice.

                         Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2045 ABNF
Date:  Fri, 06 May 2005 01:50:42 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 56
Sender: [email-masked]

Charles Lindsey wrote:

> we have not agreed to outlaw RFC 2231, mush as we dislike it

Sure, it's not our business, and Ned promised (?) to fix it.

> Its provisions for charset and language tags could even be
> useful.

That's why I proposed to copy attribute-char from 2231 in the
longer ABNF variant - automagically compatible with a future
2231bis ABNF, and any RfC introducing an actual archiv-param.

But at the moment that's all theory and unnecessary.  We need
a valid ABNF for archiv-param, or to get rid of it.

>| RFC 2232 makes provision for <value>s within <parameters>
>| to contain Non-ASCII characters

Yes, and nobody plans to implement it for the hypothetical
archiv-param, therefore it's unnecessary to mention these
features in Usefor-04, like RfC 2822 doesn't mention them.

>| news agents SHOULD NOT do so.

Why do you want to get into a battle about it, when it's
easier to ignore it, like RfC 2822 did ?  The 2231 intro
talks about MIME media types and 2183 disposition values,
but not everything with an equalsign "=" in its syntax.

> I have suggested that wording to Ken previously, but he
> has not incorporated it thus far.

It's dangerous to say "SHOULD NOT implement another RfC",
I'd use _any_ other exit if there is another way at all.

> those [FWS] should be [CFWS]

Comments _within_ a token = value parameter, sigh.  Yes, at
least for quoted-string you're right, it goes straight back
to STD 11.  Then let's add the missing C to [FWS].

> I think a better approach would be to define, in one place,
> that a parameter looked like

But not as term "parameter", that's (re)defined in RfC 2231.
We're not planning to update RfC 2231, it has more serious
problems.

> the <inj-info-params> were really all parameters, and
> inherited all the appropriate baggage

The 2231 baggage isn't appropriate, it's a security loophole.

                       Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: CFWS
Date:  Fri, 06 May 2005 00:16:17 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 6
Sender: [email-masked]

Charles Lindsey wrote:

> I think you are the only one pressing for a change in Lines.

Yes, but it's not critical, unlike the "id-right" stuff.  Bye.

To: <[email-masked]>
Subject: Re: Cmsg
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 05 May 2005 10:30:53 -0700
Sender: [email-masked]

Ruud H G van Tol <[email-masked]> writes:

> I would like to get rid of any interpretation of the Subject-field. But
> I am not aware of any software that acts on "cmsg " at the start of a
> Subject-header. I expect control messages to have a Control-header.

Certainly for new software, you're correct.  INN 2.2 and earlier and other
software of similar vintage will still treat articles with Subject headers
starting with "cmsg " as control messages.

> A message with a Date-field like `3 May 05 11:06:06 GMT' or even `Tue,
> 03 May 05 14:43:07 GMT' is likely to not arrive, is what I assume.

Actually, I think most news software uses a sufficiently lax date parser
to allow it, although it's not something to rely on.

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

From: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Subject: Re: Cmsg
Date: Thu, 5 May 2005 19:23:38 +0200
Organization: Chaos rules.
Sender: [email-masked]

Charles Lindsey:
> Ruud H.G. van Tol:

>> [RFC 1036 said:]
>> Also for upward compatibility, if the first 4 characters of the
>> "Subject:" line are "cmsg", the rest of the "Subject:" line should
>> be interpreted as a control message.

> No! No! We agreed long ago that practice from RFC 1036 should be
> declared obsolete. We want to see it stop, and to assist that 
> process Russ wants posting and injecting agents to forcibly 
> prevent any articles with Subjects starting with "cmsg " 
> (which is an overkill IMO).

I haven't written any public usenet software yet, so please 
ignore my preferences.

I would like to get rid of any interpretation of the Subject-
field. But I am not aware of any software that acts on "cmsg " 
at the start of a Subject-header. I expect control messages 
to have a Control-header.

I favor basic rules like that there can be no white space 
before the initial colon of a header line, and that there 
must be a %20 following that colon, and that a non-empty 
Subject-header is required, because such rules both honor 
expectations, and allow ignorants to make basic mistakes, 
making their messages easy to lose.

A message with a Date-field like `3 May 05 11:06:06 GMT' 
or even `Tue, 03 May 05 14:43:07 GMT' is likely to not 
arrive, is what I assume.

-- 
Grtz, Ruud

To: [email-masked]
Subject: Re: CFWS
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 05 May 2005 10:18:48 -0700
Sender: [email-masked]

Forrest J Cavalier <[email-masked]> writes:

> In my opinion, current INN 2.x in some applications is as stable as INN
> 1.7.  Russ is doing a great job prioritizing INN maintenance, and knows
> how news servers need to interoperate.

The largest problem, right now, is that almost no one is working on INN.
I'm not sure if Diablo is any better off (I keep meaning to join the
mailing list for it and keep not doing so), but judging from the release
times, probably not a lot.

At this point, the only person doing serious development on INN,
integrating patches and doing major structural changes and so forth, is
me, and I only have time to do it as a hobby.  In practical terms, that
means that I can devote about one weekend per month to it.  Given the
things that need work, that means that purely cosmetic matters are likely
to never be fixed, particularly if they don't scratch some personal itch
of mine and I don't find them attractive to implement for some reason.

All the standards documentation in the world isn't going to change the
fact that not a lot of people are currently working on news servers, and
therefore unimportant changes are very unlikely to happen quickly, if at
all.

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

Date: Thu, 05 May 2005 10:57:38 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: CFWS
Sender: [email-masked]

Charles Lindsey wrote:

> OK, so we have you and Russ (and possibly Forrest) calling for FWS-only in
> Control, Supersedes and Xref, with me disagreeing (except for Xref).
> Anyone else want to chip in before we try to discern consensus?

It is good that you are keeping track.

Seeing what gets called consensus in this group is always comical.

Opinions from people who actually know how news works, who have
actually maintained production software should carry more weight.
But somehow Usefor is some kind of one-man one-vote come-one come-all
forum.

Democracy used to mean everyone voted for what was best for everyone
in the long term.  It is regrettable that 100 years of people being
urged to vote in blatant self-interest in real world politics gets
accepted as the norm in Usefor too.

Well, sorry, engineering requires a compromise between wish-list and
what will work.  Usefor is driven by wish-list, and a lot of features will have
little or no value to end-users.  (How many users really care to put comments
into headers, where they will not be read 99% of the time, for example?)

There is a reason that the IETF requires actual implementations.  It is
because the software developers won't implement bad and marginally
useful ideas, or if they do, they won't be permanent.

It's appalling that it takes Russ making "end-the-discussion" statements of "that's
never going to get into INN" before someone considers there is a problem with
some fanciful feature.

In case you haven't noticed, the people who do engineering are dropping
out of participating in Usefor.  I stopped last September, but thought
it was time to try again last month.  I'll be going silent again.  Maybe
I'll keep reading.

I don't mind not participating, because I'm confident that USEFOR is not
going impact production news implementations.

While I'm here, since I was the person that did the patch set for INN 1.7,
I get the feeling I should apologize that INN 1.7 remains useful
so many years later, because it seems to be an impediment to retiring
and replacing those servers.  Sorry.  I thought I was doing something
optimally useful at the time.

In my opinion, current INN 2.x in some applications is as stable as INN 1.7.
Russ is doing a great job prioritizing INN maintenance, and knows how
news servers need to interoperate.

To: [email-masked]
Subject: Re: CFWS
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 05 May 2005 07:46:09 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> Anyway, the proposal currently on the table is to include obligatory
> CFWS in the syntax, but to say

>    o  Comments in CFWS between message identifiers can cause
>       interoperability problems, so comments SHOULD NOT be generated,
>       but MUST be accepted.

> (same words as in Usefor-03).

> Does anybody seriously want to change that?

I don't.  I'm content with that; I agree that adding comments to the
syntax where feasible is a good idea for headers that we share with mail.

>> Crashing unhappy 1036-servers or befuddling a deprecated Lines won't
>> gain us new friends.

> I think you are the only one pressing for a change in Lines. Since
> nobody is seriously trying to parse Lines for any purpose, I think it
> can safely be left as it has been in all previous drafts, just for
> consistency with the way RFC 2822 (and even 822) likes things to be.

RFC 2822 and 822 obviously have nothing to say about Lines in particular,
so I think that's a weak argument.  The header is obsolete, which means
that we should do nothing other than documenting the existing syntax.  The
existing syntax doesn't allow comments.  I therefore don't understand the
point of including comments.

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

Date: Thu, 5 May 2005 10:19:27 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: CMsg in Subject headers (was Obsolete vs. obsolescent)
Sender: [email-masked]

On Thu, 5 May 2005, Charles Lindsey wrote:
> >I believe that posting agents should refuse to generate them...
> >and injecting agents should reject them.  I don't have a strong 
> >opinion on what relaying and serving agents should do...  Going
> >ahead and serving or relaying them probably does the least harm.
> 
> OK, so considering the proposal on the table to be your first sentence
> (interpreting "should" as "SHOULD")...
> So we need to hear more opinions.

I am (mildly) in favor of Russ's position:  it's worth making a real effort
to keep them off the net.

(Once they're on, well, I wouldn't weep if relayers and servers declined
to pass them on, but I suspect it's best not to require/recommend that.)

                                                          Henry Spencer
                                                       [email-masked]

To: [email-masked]
Xref: clerew local.usefor:20828
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2045 ABNF
Date: Thu, 5 May 2005 11:09:06 GMT
Lines: 62
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>>> "Smart copying", just stay away from the 2231 parameter
>>> syntax.

>> Not clear what you mean by that.

>Just don't say archiv-param = parameter if what you want is a
>2045 parameter, but not a 2231 parameter.  You could e.g. say

But we have not agreed to outlaw RFC 2231, mush as we dislike it. Its
provisions for charset and language tags could even be useful.

For sure, we heartily dislike its multi-line provisions, and I could
accept a wording such as the following:

   RFC 2232 makes provision for <value>s within <parameters> to contain
   Non-ASCII characters, and also for <value>s of excessive length to be
   split over several lines. Since the only length limit on header lines
   specified by this standard is an overall 998 octets, it is never
   necessary to utilize that latter facility in Netnews, and news agents
   SHOULD NOT do so. However, such split parameters may occasionally be
   seen in articles gatewayed from Email.

I have suggested that wording to Ken previously, but he has not
incorporated it thus far.

I think it would accord with the general opinion of this WG, but I don't
think we have any agreement to go beyond that.

>archive-param  = attribute [FWS] "=" [FWS] value
>attribute      = 1*attribute-char
>attribute-char = ; ABNF of the ASCII subset defined by 2231
>value          = token / quoted-string
>token          = 1*( attribute-char / "*" / "'" / "%" )

>Ugly like hell, a more friendly variant:

Well those [FWS] should be [CFWS], and you haven't got enough of them, and
there is already one present in <quoted-string>.

And archive-param is not the only place affected, because there are all
the params defined in Injection-Info, to which it would all apply.

I think a better approach would be to define, in one place, that a
parameter looked like (either with explicit syntax or verbiage to adapt
1045/2231/822), and then to say, with further verbiage, that the
<inj-info-params> were really all parameters, and inherited all the
appropriate baggage (which is what I actually did in the old draft-13).

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

To: [email-masked]
Xref: clerew local.usefor:20825
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CFWS
Date: Thu, 5 May 2005 10:38:38 GMT
Lines: 63
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> It was reported here by Russ that comments in Reference
>> headers most certainly would confuse existing user agents

>If a confused UA has minor problems with the threading it's
>no big deal.  But if we'd want mail2news gateways worldwide
>to "translate" 2822-References to grandson References it's
>ugly.

As I said, if mail2news gateways do not both to check, the likely
consequences are fairly minimal in practice.

Anyway, the proposal currently on the table is to include obligatory CFWS
in the syntax, but to say

   o  Comments in CFWS between message identifiers can cause
      interoperability problems, so comments SHOULD NOT be generated,
      but MUST be accepted.

(same words as in Usefor-03).

Does anybody seriously want to change that?

>Or we hope that this is something a future 2822bis would also
>do, because <a@b> <c@d> instead of <a@b><c@d> just is common
>practice, no matter what the proposed standard 2822 proposed.

I agree there, but that is not our call.

>> Russ was pressing for exclusion of comments from Control,
>> Supersedes and Xref. You are agreeing with him as regards
>> Control and Supersedes.

>I simply forgot Xref in your list, it should be as Russ said.

OK, so we have you and Russ (and possibly Forrest) calling for FWS-only in
Control, Supersedes and Xref, with me disagreeing (except for Xref).
Anyone else want to chip in before we try to discern consensus?

>Crashing unhappy 1036-servers or befuddling a deprecated Lines
>won't gain us new friends.

I think you are the only one pressing for a change in Lines. Since nobody
is seriously trying to parse Lines for any purpose, I think it can safely
be left as it has been in all previous drafts, just for consistency with
the way RFC 2822 (and even 822) likes things to be.

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

To: [email-masked]
Xref: clerew local.usefor:20827
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Cmsg (was Obsolete vs. obsolescent)
Date: Thu, 5 May 2005 10:52:12 GMT
Lines: 21
Sender: [email-masked]

In <[email-masked]> "Ruud H.G. van Tol" <[email-masked]> writes:

>Also for upward compatibility, if the first 4 characters of the
>"Subject:" line are "cmsg", the rest of the "Subject:" line should
>be interpreted as a control message.

No! No! We agreed long ago that practice from RFC 1036 should be declared
obsolete. We want to see it stop, and to assist that process Russ wants
posting and injecting agents to forcibly prevent any articles with
Subjects starting with "cmsg " (which is an overkill IMO).

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

To: [email-masked]
Xref: clerew local.usefor:20826
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: CMsg in Subject headers (was Obsolete vs. obsolescent)
Date: Thu, 5 May 2005 10:44:26 GMT
Lines: 28
Sender: [email-masked]

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

>I believe that posting agents should refuse to generate them (a 0th item
>on your list that's already implemented by many) and injecting agents
>should reject them.  I don't have a strong opinion on what relaying and
>serving agents should do with them after they've already happened.  Going
>ahead and serving or relaying them probably does the least harm.  I'm not
>sure it's worth specifically requiring some particular behavior there.

OK, so considering the proposal on the table to be your first sentence
(interpreting "should" as "SHOULD")

You are in favour (obviously)
I am opposed
I believe Frank is opposed

So we need to hear more opinions.

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

Date: Wed, 4 May 2005 15:30:29 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Obsolete vs. obsolescent
Sender: [email-masked]

On Wed, 4 May 2005, Ruud H.G. van Tol wrote:
> > any Subject header beginning with "cmsg "
> 
> I always thought just "cmsg", so no space required.

That's what RFC 1036 said, but most (all?) real implementations insisted
on the trailing space... to the extent that they paid any attention to
"cmsg" at all.

                                                          Henry Spencer
                                                       [email-masked]

From: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Subject: Re: Obsolete vs. obsolescent
Date: Wed, 4 May 2005 21:25:41 +0200
Organization: Chaos rules.
Sender: [email-masked]

Russ Allbery:

> any Subject header beginning with "cmsg "

I always thought just "cmsg", so no space required.

>From RFC 1036:

Also for upward compatibility, if the first 4 characters of the
"Subject:" line are "cmsg", the rest of the "Subject:" line should
be interpreted as a control message.

-- 
Grtz, Ruud

To: [email-masked]
Subject: Re: Obsolete vs. obsolescent
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 04 May 2005 12:00:47 -0700
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:

> Maybe a poor "modern" server surrounded by "broken" servers or
> a news2mail in a similar position would never see the article
> if the "broken" servers refuse to accept obscure Subject: cmsg
> articles.

> IIRC you proposed a =?us-ascii?Q?cmsg?= kludge for mail2news,
> but that's common sense or Usepro-xx, not Usefor-04.

Agreed.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Obsolete vs. obsolescent
Date:  Wed, 04 May 2005 20:01:03 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Russ Allbery wrote:

>> Even if that "breakage" is only apparent on "broken" servers?

> Yes.  They're fully-compliant RFC 1036 servers.

Maybe a poor "modern" server surrounded by "broken" servers or
a news2mail in a similar position would never see the article
if the "broken" servers refuse to accept obscure Subject: cmsg
articles.

IIRC you proposed a =?us-ascii?Q?cmsg?= kludge for mail2news,
but that's common sense or Usepro-xx, not Usefor-04.

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: CFWS
Date:  Wed, 04 May 2005 20:41:26 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 64
Sender: [email-masked]

Charles Lindsey wrote:

> It was reported here by Russ that comments in Reference
> headers most certainly would confuse existing user agents

If a confused UA has minor problems with the threading it's
no big deal.  But if we'd want mail2news gateways worldwide
to "translate" 2822-References to grandson References it's
ugly.

> News really ought to catch up eventually (hence the CFWS is
> still in our draft, though deprecated for now).

ACK.  Maybe my idea to enforce at least a FWS as separator,
the [CFWS] => CFWS modification in msg-id-list, was stupid ?

Or we hope that this is something a future 2822bis would also
do, because <a@b> <c@d> instead of <a@b><c@d> just is common
practice, no matter what the proposed standard 2822 proposed.

> Note that USEFOR is taking a stronger line on insisting of
> at least a SP to separate the references than it is taking
> on excluding comments.

Yes, see above...

> I think this is because that SP was explicit in RFC 1036

...and because I wanted it.  But if that's a silly compromise
we could drop it and let UAs confronted with the proposed 2822
syntax crash as they see fit.

> Russ was pressing for exclusion of comments from Control,
> Supersedes and Xref. You are agreeing with him as regards
> Control and Supersedes.

I simply forgot Xref in your list, it should be as Russ said.

> Control: cancel <[email-masked]> (unapproved article in
> moderated group)

A cancel etc. ignored by many news servers doesn't help,
please get rid of all CFWS in Xref, Control, Supersedes, and
Lines.  They don't need or want to be "mail-compatible", it's
much more important to be s-o-1036 compatible.

> There are still people high up who think that News is just an
> offshoot of mail :-(

If they don't understand it they won't talk about it.  We have
a clear mission statement, a proper subset of message/rfc822:
No comments at some places _is_ still a valid message/rfc822.

> We will have more chance of influencing RFC 2822bis if we are
> seen to be cooperating on issues which are less critical for
> our purposes.

Crashing unhappy 1036-servers or befuddling a deprecated Lines
won't gain us new friends.  If a future 2822bis doesn't adopt
our msg-id without compulsive reasons it would be pointless -
the most liberal syntax already exists in the form of RfC 2822
minus its obs-cenities.
                        Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2045 ABNF
Date:  Wed, 04 May 2005 19:44:51 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 38
Sender: [email-masked]

Charles Lindsey wrote:
 
>> "Smart copying", just stay away from the 2231 parameter
>> syntax.

> Not clear what you mean by that.

Just don't say archiv-param = parameter if what you want is a
2045 parameter, but not a 2231 parameter.  You could e.g. say

archive-param  = attribute [FWS] "=" [FWS] value
attribute      = 1*attribute-char
attribute-char = ; ABNF of the ASCII subset defined by 2231
value          = token / quoted-string
token          = 1*( attribute-char / "*" / "'" / "%" )

Ugly like hell, a more friendly variant:

archive-param  = archive-attr [FWS] "=" [FWS] value
archive-attr   = token
value          = token / quoted-string
token          = ; string TBD based on 2045 / STD 11

As long as you don't try to "redefine" (= reuse) any 2231 term
there should be no serious problem.

>> Is there anything else that needs to be discussed for
>> Usefor-04 ?
 
> Yes lots. I still haven't gotten around to doing the Path
> stuff that I promised, for a start.

That doesn't need any further discussion before Usefor-04.  I
want a first RfC in the next five weeks, they have this fatal
tendency to close WGs with zero RfCs, something I didn't know
before MARID (all I knew was USEFOR).
                                      Bye, Frank

To: [email-masked]
Subject: Re: Obsolete vs. obsolescent
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 04 May 2005 10:21:39 -0700
Sender: [email-masked]

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

>> News reader authors will have warning, the standard will explain why
>> they're rejected, and the rejection from at least some servers will be
>> immediate and won't be silent, rather than having the article appear on
>> one's local server and then not seen by anyone else.

> Please can I be clear which of the following you are proposing:

> 1. That injecting agents should return these articles to the sender
>    noisily.
> 2. That relaying agents should drop them silently.
> 3. That serving agents should fail to store them, silently.

I believe that posting agents should refuse to generate them (a 0th item
on your list that's already implemented by many) and injecting agents
should reject them.  I don't have a strong opinion on what relaying and
serving agents should do with them after they've already happened.  Going
ahead and serving or relaying them probably does the least harm.  I'm not
sure it's worth specifically requiring some particular behavior there.

> And is it to apply to

>     Subject: cmsg: considered harmful

> or only to ones that might be parsed as a genuine control message?

Neither.  It would apply to any Subject header beginning with "cmsg " (no
colon), since that's what the interoperability problem applies to.

> Even if that "breakage" is only apparent on "broken" servers?

Yes.  They're fully-compliant RFC 1036 servers.

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

To: [email-masked]
Xref: clerew local.usefor:20815
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ***SPAM-3*** Re: CFWS
Date: Wed, 4 May 2005 11:20:59 GMT
Lines: 93
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> and also
>>     Message-ID
>> which we decided to make FWS-only, even though it is not a
>> news-only-header, but not References (though we say "must
>> not generate yet").

>Is that so ?  A puzzle for mail2news gateways, do they have to
>replace comments by a space ?  Comments in References should
>not confuse news servers, no matter how old, so I don't care
>much about this bit.  If gateways are expeted to do something
>it has to be stated in USEPRO.

It was reported here by Russ that comments in Reference headers most
certainly would confuse existing user agents, as would total omission of
that FWS (I agree that servers are unlikely to care). OTOH, they are
allowed in RFC 2822 (though I don't know whether MUAs that attempt to
thread email actually tolerate them in practice), so News really ought to
catch up eventually (hence the CFWS is still in our draft, though
deprecated for now).

As for gateways, USEPRO requires them to produce valid News articles, so
strictly speaking they should do as you say. But I would be sympathetic to
a gateway that did not bother to make the check on the grounds that these
things never appeared in practice (have you ever seen one?).

Note that USEFOR is taking a stronger line on insisting of at least a SP
to separate the references than it is taking on excluding comments. I
think this is because that SP was explicit in RFC 1036, and RFC 2822
really ought to have retained it (and RFC 2822bis should be made to do
so).

> [before]
>> plus:
>>     Expires
>>     Approved
>>     Control
>>     Supersedes
>>     Xref
>>     Lines
> [...]

>Supersedes is news-only server territory => no comments.  Dito
>Control.

Russ was pressing for exclusion of comments from Control, Supersedes and
Xref. You are agreeing with him as regards Control and Supersedes.

I agree as regards Xref (it is not intended to be generated by humans
ever, and no automaton is going to put comments in).

I would prefer to leave them in Control and Supersedes (though deprecated
until "yet" happens), for general consistency with email and because
people will surely try to use them, as in

Control: cancel <[email-masked]> (unapproved article in moderated group)

> Lines is "obsolescent" => no need to add comments to
>its grave.

And no need not to either. Leave it be.

>A date-time is the one 2822 case with only a trailing CFWS and
>otherwise FWS => keep it as it is (= same syntax as 2822 Date).

Yes. Russ has already said that software that tries to parse a date just
stops looking as soon as it has seen enough.

>> they would all be "MUST accept, but do not generate yet"

>I hate this doublebind approach.  If we don't want CFWS let's
>just say so in the syntax for Supersedes, Control, and Lines.

It is a Good Thing to be seen to be trying to adopt an approach consistent
with what email has defined. There are still people high up who think that
News is just an offshoot of mail :-( . We will have more chance of
influencing RFC 2822bis if we are seen to be cooperating on issues which
are less critical for our purposes.

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

To: [email-masked]
Xref: clerew local.usefor:20817
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Obsolete vs. obsolescent
Date: Wed, 4 May 2005 11:30:57 GMT
Lines: 37
Sender: [email-masked]

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

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

>News reader authors will have warning, the standard will explain why
>they're rejected, and the rejection from at least some servers will be
>immediate and won't be silent, rather than having the article appear on
>one's local server and then not seen by anyone else.

Please can I be clear which of the following you are proposing:

1. That injecting agents should return these articles to the sender noisily.
2. That relaying agents should drop them silently.
3. That serving agents should fail to store them, silently.

And is it to apply to

    Subject: cmsg: considered harmful

or only to ones that might be parsed as a genuine control message?

>Furthermore, it's one of the purposes of a standard to warn about doing
>things that will cause breakage in practice, *particularly* if that
>breakage can't be easily detected.

Even if that "breakage" is only apparent on "broken" servers?

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

To: [email-masked]
Xref: clerew local.usefor:20816
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ***SPAM-3*** Re: 2045 ABNF
Date: Wed, 4 May 2005 11:23:52 GMT
Lines: 33
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> Currently, it is unclear in USEPRO, and it needs to be fixed
>> for use in Archive and Injection-Info. I do not care whether
>> the fix is by 'inventing' that syntax, or by suitable hand
>> waving, provided it gets done.

>"Smart copying", just stay away from the 2231 parameter syntax.

Not clear what you mean by that.
> 
>> [There are also some further nits in Injection-Info that need
>> to be fixed, but I shall deal with these later - best not to
>> have too many topics on the go at one time.]

>Okay, let's delay the 2045-problem for a Usefor-05.  Is there
>anything else that needs to be discussed for Usefor-04 ?

Yes lots. I still haven't gotten around to doing the Path stuff that I
promised, for a start.

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

To: [email-masked]
Subject: Re: Obsolete vs. obsolescent
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 03 May 2005 08:35:40 -0700
Sender: [email-masked]

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

>> That's not the real issue.  The issue is that such articles disappear,
>> sometimes silently, sometimes noisily.  That is the very definition of
>> an interoperability problem.

> If they are disappearing because servers are filtering out Subjects with
> "cmsg:" in them, they I cannot see how the situation will be improved by
> making such filters mandatory.

News reader authors will have warning, the standard will explain why
they're rejected, and the rejection from at least some servers will be
immediate and won't be silent, rather than having the article appear on
one's local server and then not seen by anyone else.

Furthermore, it's one of the purposes of a standard to warn about doing
things that will cause breakage in practice, *particularly* if that
breakage can't be easily detected.

> May I suggest that a final revision/patch for the INN 1.7 series to
> attend to the most urgent changes brought about by our standard (clearly
> stopping these ancient practices is one of them) would be a good idea.

Releasing a new version of an otherwise extremely stable software package
to fix things that aren't broken, just in compliance with an older
standard that's still widely followed, isn't something that strikes me as
a good idea.  It's certainly not something that I personally will be
doing.

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

To: [email-masked]
Subject: Re: CFWS
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 03 May 2005 08:30:35 -0700
Sender: [email-masked]

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

>> Supersedes with comments just will fail to work on some (probably many)
>> servers.

> They may fail to cancel the old article, but I doubt they would fail to
> carry the new.

Right.

>> As a server implementor, I have no current plans to add comment
>> stripping for Control or Supersedes regardless of what the draft says;
>> it strikes me as futile makework, and there are considerably more
>> pressing things I could do with my time that actually matter.

> That is fair enough. I would expect those particular upgrades to be at
> the back of your queue of jobs to be done, and might remain there for a
> long time. But I hope that would not mean 'never'.

In practice, that means never.  There isn't exactly a surfeit of news
server developers right now.

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

To: [email-masked]
Xref: clerew local.usefor:20810
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Obsolete vs. obsolescent
Date: Tue, 3 May 2005 12:36:45 GMT
Lines: 48
Sender: [email-masked]

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

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

>> I hope to, and I am older than you are :-) . If, on an occasional
>> server, some group gets wrongly created/removed or some article gets
>> cancelled, I can live with that.

>That's not the real issue.  The issue is that such articles disappear,
>sometimes silently, sometimes noisily.  That is the very definition of an
>interoperability problem.

If they are disappearing because servers are filtering out Subjects with
"cmsg:" in them, they I cannot see how the situation will be improved by
making such filters mandatory.

But if they were genuine attempts to inject control messages, and they
fail in whatever manner (preferably noisily), then surely that is what we
want.

>Haven't we done this multiple times before?  I feel like I'm repeating
>myself.  I could have sworn that we'd reached consensus on this repeatedly
>in the past, and yet, here we go again.

I am not convinced that we achieved any consensus last time, except that
any special treatment of such messages that would cause them to be obeyed
as control messages should cease ASAP.

>INN 1.7 is still widely deployed and even recommended for new
>installations by, e.g., Debian because it's simple.  Many existing filters
>look for "Subject: cmsg" when making filtering decisions as well as
>looking at Control headers, so as not to miss articles sneaking in via
>older interpretations of the standard.

May I suggest that a final revision/patch for the INN 1.7 series to attend
to the most urgent changes brought about by our standard (clearly stopping
these ancient practices is one of them) would be a good idea.

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

To: [email-masked]
Xref: clerew local.usefor:20809
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CFWS
Date: Tue, 3 May 2005 10:07:34 GMT
Lines: 54
Sender: [email-masked]

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

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

>>     Control
>>     Supersedes
>>     Xref

>As you mention, these are the only ones that matter where we haven't
>already decided to disallow comments.

Then let us hear some opinions and come to a decision.

>Control and Xref will break the most stuff.  Comments in Xref will, I
>expect, break almost everything that uses it.  I highly doubt that most
>clients will ever bother handling comments in Xref.

Which is a good argument. Our whole strategy was based on the idea that
the number of servers in the world was much less than the number of user
agents, and they tended to be operated with somewhat more clue than user
agents. Therefore there was a realistic possibility that the great
majority of them could be brought in to line within a reasonable time
scale, allowing new the functionality to be introduced (clearly, some
stragglers will always remain and will get routed around; it will be up to
their clients to apply pressure to upgrade). OTOH, ancient user agents
will be around for a much longer time, but there is nothing in our drafts
that will make them stop working, though they may not see the full
benefits.

>Supersedes with comments just will fail to work on some (probably many)
>servers.

They may fail to cancel the old article, but I doubt they would fail to
carry the new.

>As a server implementor, I have no current plans to add comment stripping
>for Control or Supersedes regardless of what the draft says; it strikes me
>as futile makework, and there are considerably more pressing things I
>could do with my time that actually matter.

That is fair enough. I would expect those particular upgrades to be at the
back of your queue of jobs to be done, and might remain there for a long
time. But I hope that would not mean 'never'. 

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2045 ABNF
Date:  Tue, 03 May 2005 07:30:38 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Charles Lindsey wrote:

> Currently, it is unclear in USEPRO, and it needs to be fixed
> for use in Archive and Injection-Info. I do not care whether
> the fix is by 'inventing' that syntax, or by suitable hand
> waving, provided it gets done.

"Smart copying", just stay away from the 2231 parameter syntax.
 
> [There are also some further nits in Injection-Info that need
> to be fixed, but I shall deal with these later - best not to
> have too many topics on the go at one time.]

Okay, let's delay the 2045-problem for a Usefor-05.  Is there
anything else that needs to be discussed for Usefor-04 ?  If
not we could now go to biweekly drafts, "internal last call"
end of May, an IETF "last call" before IETF 62 would be nice.

                          Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Again broken
Date:  Tue, 03 May 2005 06:53:07 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 66
Sender: [email-masked]

Charles Lindsey wrote:

> Changing the names of things can drop hints, but it
> can never change a normative definition.

A clear hint is better than normative gibberish like
a SHOULD instead of a definition.

>>| Note: id-right is a domain, and no-fold-literal is the
>>| special case of a domain-literal (a.k.a. address-literal,
>>| see RfC 2821)

> I don't think USEFOR should be relying on RFC 2821 (RFC
> 2822 is fine, of course).

RfC 2822 relies heavily on 2821, especially in this context:

| The domain portion identifies the point to which the mail is
| delivered. In the dot-atom form, this is interpreted as an
| Internet domain name (either a host name or a mail exchanger
| name) as described in [STD3, STD13, STD14].  In the
| domain-literal form, the domain is interpreted as the literal
| Internet address of the particular host.  In both cases, how
| addressing is used and how messages are transported to a
| particular host is covered in the mail transport document
| [RFC2821].  These mechanisms are outside of the scope of this
| document.

> By all means say that <no-fold-literal> is to be treated in
> some sense like a <domain-literal>.

If you don't like the "(a.k.a. address-literal, see RfC 2821)"
how about this:

  Note: id-right is a domain, and no-fold-literal is the
  special case of a domain-literal (for details see STD 10,
  STD 11, and RfC 2822).

> But that is precisely what my text was trying to do, but you
> objected to my text :-(. Just to remind you, my exact words
> were:

> | "... any <dot-atom-text> or <no-fold-literal> used for the
> | <id-right> are to be interpreted as <domain>s as described
> | in section 3.4.1 of [RFC 2822].

Your quote started with the bogus "It is RECOMMENDED in [RfC
2822]" from this "proposed standard", RfC 2822 is not even a
"draft standard".

It has nothing relevant to say about Usenet Message-IDs, we've
fixed its dubious msg-id syntax, and for the real semantics the
true sources are 1036 and STD 11.  It's *not* only RECOMMENDED,
it's by definition a domain.

For idiots we'd say MUST, because we know that RHS abuse causes
harm and interoperability problems for Usenet.  OTOH an obvious
MUST would be a bad MUST.  But replacing it by a SHOULD is *no*
option.

We still need the STD 11 note for the same technical reasons:

| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: CFWS
Date:  Tue, 03 May 2005 06:05:31 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 68
Sender: [email-masked]

Charles Lindsey wrote:

> The headers affected would be:
>     Newsgroups
>     Distribution
>     Followup-To
> which we have already decided to make FWS-only.

Okay, then these are ready.  I've already said what I have to
say about an [FWS] that's actually only a *WSP by an explicit
MUST.  May Bruce and the IESG be liberal in what they accept.

 [later]
> and also
>     Message-ID
> which we decided to make FWS-only, even though it is not a
> news-only-header, but not References (though we say "must
> not generate yet").

Is that so ?  A puzzle for mail2news gateways, do they have to
replace comments by a space ?  Comments in References should
not confuse news servers, no matter how old, so I don't care
much about this bit.  If gateways are expeted to do something
it has to be stated in USEPRO.

 [before]
> plus:
>     Expires
>     Approved
>     Control
>     Supersedes
>     Xref
>     Lines
 [...]

Supersedes is news-only server territory => no comments.  Dito
Control.  Lines is "obsolescent" => no need to add comments to
its grave.

> But it would be bizarre to forbid comments in Expires (which
> has the same syntax as Date)

A date-time is the one 2822 case with only a trailing CFWS and
otherwise FWS => keep it as it is (= same syntax as 2822 Date).

> or in Approved (which has the same syntax as From and other
> address headers).

Yes, keep it as it is.  It's another special case, comments in
a mailbox-list were always allowed, it's no "new" 2822 feature,
it's STD 11 and s-o-1036 minus some obs-cenitities.

> I doubt anybody cares either way about Lines.

I did some weeks ago, same argument as above:  If we deprecate
it, then that's not the moment to add new features like CFWS.

> they would all be "MUST accept, but do not generate yet"

I hate this doublebind approach.  If we don't want CFWS let's
just say so in the syntax for Supersedes, Control, and Lines.

For the References we lose whatever we do.  I'd go with 2822
instead of torturing poor mail2news operators - it shouldn't
break too many UAs, 2822 is already more than four years old.

                         Bye, Frank

To: [email-masked]
Subject: Re: CFWS
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 02 May 2005 19:57:54 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

>     Control
>     Supersedes
>     Xref

As you mention, these are the only ones that matter where we haven't
already decided to disallow comments.

Control and Xref will break the most stuff.  Comments in Xref will, I
expect, break almost everything that uses it.  I highly doubt that most
clients will ever bother handling comments in Xref.

Supersedes with comments just will fail to work on some (probably many)
servers.

As a server implementor, I have no current plans to add comment stripping
for Control or Supersedes regardless of what the draft says; it strikes me
as futile makework, and there are considerably more pressing things I
could do with my time that actually matter.  (Xref is server-generated,
and for obvious reasons I will never generate an Xref header that contains
comments.)  I used to be more willing to consider changes along these
lines, but have found less and less interest in or patience for them over
time.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Suggested References texts
Date:  Tue, 03 May 2005 04:36:41 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 63
Sender: [email-masked]

Charles Lindsey wrote:

> Hence why I want to say, in USEFOR, what a well-formed
> References header looks like,

It look likes a msg-id-list.  That's all about its form,
and that's all for USEFOR, the same look and feel as the
RfC 2822 References.

> and what it means

If has no clear meaning, we're only sure that an article
without References is no "followup".  By elementary logic
we found that a "followup" has References.

> A. By stating what properties a well-formed References
>    header should possess.

It should possess the property of a msg-id-list.  If you
want to go into details state that a msg-id should not
occur more than once, and that the Message-ID: msg-id
should not be listed in this msg-id-list.  But better
keep it as simple and stupid as it is => no details.

> B. By setting forth an algorithm for generating it.

Yes, that's what you have in USEPRO, and similar in 2822.
"Reply" in 2822 is a simpler construct than a "followup" -
no Followup-To: in RfC 2822 - but essentially the same.

With a "modern" UA (written after 2045 or s-o-1036) I'd
expect that it creates the same References: header field
for both Followup-To: NG(s) and Followup-To: poster.

> RFC 2822 takes appraoch B.

You do it, too, in USEPRO, it's fine, and also good eough.

> the present text in USEPRO doesn't do it (because it
> does not address cases other than followups).

The other cases are irrelevant.  In theory you could post
multipart FAQs part by part, each part n+1 as a "followup"
of part n, and the 1st part is no "followup".  And if what
you do in practice has the same effect, then nobody cares
how you really did it.

> I suppose I could write a general algorithm on how to
> construct a Referances header given a chain of precursors

You've already done this in USEPRO, by induction.  What you
have explains how to create (n+1), given n old References
and 1 old msg-id.  It works for all n, even for n=0.

> Would that suit you better?

I don't have any problems with what USEFOR and USEPRO say
about the References.  I only don't want you to add tons of
text to USEFOR, with all these strange and irrelevant cases
where the References are _not_ built by the known procedure.

                         Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:20806
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: CFWS (was: Again broken)
Date: Mon, 2 May 2005 16:37:01 GMT
Lines: 51
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> it ought to be discussed

>Kill all CFWS in pre-2045 news-only-headers where it doesn't
>contradict 2045 / 2822.  For new headers like User-Agent or
>Injection-Info adopt common practice or 2045 / 2822 style.

>I know that it's not what the WG once wanted, but you asked.

OK, that's a viable point of view, which the WG might accept.

The headers affected would be:
    Newsgroups
    Distribution
    Followup-To
which we have already decided to make FWS-only. plus:
    Expires
    Approved
    Control
    Supersedes
    Xref
    Lines
and also
    Message-ID
which we decided to make FWS-only, even though it is not a
news-only-header, but not References (though we say "must not generate
yet").

But it would be bizarre to forbid comments in Expires (which has the same
syntax as Date) or in Approved (which has the same syntax as From and
other address headers). I doubt anybody cares either way about Lines.

So I don't think a blanket rule like you suggest is the right thing, but
Control, Supersedes and Xref are worth discussing. But bear in mind that
they would all be "MUST accept, but do not generate yet", imlying that
implementors ought to be makng the necessary changes in order to comply
100%.

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

To: [email-masked]
Subject: Re: Obsolete vs. obsolescent
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 02 May 2005 09:38:55 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> I hope to, and I am older than you are :-) . If, on an occasional
> server, some group gets wrongly created/removed or some article gets
> cancelled, I can live with that.

That's not the real issue.  The issue is that such articles disappear,
sometimes silently, sometimes noisily.  That is the very definition of an
interoperability problem.

> _Some_ servers decline to propagate them. Some don't. Can you quote
> examples that have actually happener to justify that "huge
> interoperability problems" claim?

Haven't we done this multiple times before?  I feel like I'm repeating
myself.  I could have sworn that we'd reached consensus on this repeatedly
in the past, and yet, here we go again.

INN 1.7 is still widely deployed and even recommended for new
installations by, e.g., Debian because it's simple.  Many existing filters
look for "Subject: cmsg" when making filtering decisions as well as
looking at Control headers, so as not to miss articles sneaking in via
older interpretations of the standard.  The change in INN was made in 2.3,
so even for people who want to run INN 2.x, it was made as part of a
significant upgrade that requires a complete overview rebuild, and a fair
number of people have not bothered.

And that's just in the INN world, let alone all of the other news servers
out there.

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

To: [email-masked]
Xref: clerew local.usefor:20803
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Obsolete vs. obsolescent
Date: Mon, 2 May 2005 11:30:24 GMT
Lines: 48
Sender: [email-masked]

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

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

>> But evidently Frank doesn't want that to be said (he is complaining
>> about current systems that object when you try to do it), and I don't
>> think I want to do it either. Better just to let the usage die away
>> (which USEPRO requires).

>That isn't going to actually happen in any sort of reasonable time frame.

>> Otherwise we shall find new software coming on stream that objects to
>> 'cmsg' in Subjects (just to comply with the new USEFOR) just as the last
>> remaining servers that might have interpreted that 'cmsg' are being
>> withdrawn.

>I wonder if any of us will live long enough to see the last remaining
>servers that interpreted cmsg be withdrawn.

I hope to, and I am older than you are :-) . If, on an occasional server,
some group gets wrongly created/removed or some article gets cancelled, I
can live with that. It happens all the time, and the effect would not
propagate outside of that server. That hardly amounts to "huge
interoperability problems at the present time".

>> How much of a problem are such headers causing at the present time?

>They aren't propagated.  They have huge interoperability problems at the
>present time.

_Some_ servers decline to propagate them. Some don't. Can you quote
examples that have actually happener to justify that "huge
interoperability problems" claim?

OK. We need to hear more WG opinions on whether Subjects starting with
"cmsg:" in non-control-messages should be deprecated/forbidden/whatever.

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

To: [email-masked]
Xref: clerew local.usefor:20804
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Again broken
Date: Mon, 2 May 2005 11:49:24 GMT
Lines: 52
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>Charles Lindsey wrote:
>> If the WG wants this change, then it ought to be discussed first.

>There you go again.

>Charles, the only meaning of "change" that makes sense is a change
>from current published standards and practice. I believe you have once
>again used it to mean "an edit to the draft."  Please stop it.

The "change" I am talking about is a change from previous WG decisions.

The WG decided years and years and years ago (long before I became editor)
to allow comments in headers (subject to "do not generate yet"). Later on,
it decided to exempt certain headers from this on performance grounds. The
list included Newsgroups, Path, Followup-To, Distribution and Message-ID,
but _never_ Control. All this was reflected in our drafts up to draft-13.

>If something appeared in the draft that was never discussed in the WG,
>it ought to be removed.

Any that is exactly what I am complaining about. The new USEFOR drafts
have changed the syntax of the Control header, contrary to what had been
discussed and incorporated in the earlier drafts, and without any WG
decision to do so.

If the WG now wishes to reopen and discuss this case again, then fine. But
without such discussion, it should remain as it always has been.

>Removing such things do not need to be discussed first, because removing
>them is not a change, having them in is a change.

>The draft is fluid, it isn't a big deal to delete and edit words.

>Modifying servers to parse comments in control headers is a big
>deal.

Not that big, and with no performance issues. It is covered adequately by
some "do not generate yet" wording, such as we have regularly used
elsewhere in similar cases.

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

To: [email-masked]
Xref: clerew local.usefor:20801
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Mon, 2 May 2005 11:14:57 GMT
Lines: 58
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> suppose you are a multipart FAQ writer trying to use
>> References to refer back to the earlier parts, how do
>> you know what you can do?

>There are many possible and correct ways to do this, and
>they are all obvious.  It's 2005.  If somebody posts a
>multipart FAQ in an NG where I don't like it I'm tempted
>to report it as net abuse.

Yes, all that you say is true. "Everone" (TINE) "knows" how the References
header is supposed to work. That is, by definition, how "folklore" works.
But Usenet has been running on folklore ever since RFC 1036 was written,
and the whole purpose of our drafts is to codify it properly, because in
many cases different people have understood the folklore in different
ways. The whole purpose of having standards is to prevent that sort of
thing from happening.

Therefore, USEFOR and USEPRO between them MUST document how the References
header is supposed to work (I think we are now agreed that it differs
sufficiently from References in RFC 2822 that we cannot rely on RFC 2822
to any great extent).

Hence why I want to say, in USEFOR, what a well-formed References header
looks like, and what it means (being careful to say no more than is
necessary for current practice, so as not to prejudice future
developments, e.g. for multiple precursors).

There are, essentially, two ways to say this:

A. By stating what properties a well-formed References header should
possess.

B. By setting forth an algorithm for generating it.

I was trying to follow approach A (the algorithm given for followup agents
in USEPRO is in fact consistent with what I proposed).

RFC 2822 takes appraoch B. If you want that approach, then I suppose it
could be done, but the present text in USEPRO doesn't do it (because it
does not address cases other than followups). I suppose I could write a
general algorithm on how to construct a Referances header given a chain of
precursors, and then invoke that algorithm for the particular case of
followup agents. Would that suit you better?

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

To: [email-masked]
Xref: clerew local.usefor:20805
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Again broken
Date: Mon, 2 May 2005 12:03:30 GMT
Lines: 42
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> OK, if you don't want it fixed, let it go.

>I've proposed many ways to fix it, e.g. by clear names for
>the msg-id productions, or the last proposal was this note:

Changing the names of things can drop hints, but it can never change a
normative definition.

>| Note: id-right is a domain, and no-fold-literal is the
>| special case of a domain-literal (a.k.a. address-literal,
>| see RfC 2821)

I don't think USEFOR should be relying on RFC 2821 (RFC 2822 is fine, of
course).

By all means say that <no-fold-literal> is to be treated in some sense
like a <domain-literal>. But that is precisely what my text was trying to
do, but you objected to my text :-( . Just to remind you, my exact words
were:

|    "... any <dot-atom-text> or
|    <no-fold-literal> used for the <id-right> are to be interpreted as
|    <domain>s as described in section 3.4.1 of [RFC 2822].

That covers all you have been asking for, and ensures that the
RECOMMENDATION in RFC 2822 applies fully to USEFOR (whreas, due to bad
wording, it does not actually apply to RFC 2822 :-( ).

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

To: [email-masked]
Xref: clerew local.usefor:20802
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Mon, 2 May 2005 11:18:19 GMT
Lines: 26
Sender: [email-masked]

In <[email-masked]> "Ruud H.G. van Tol" <[email-masked]> writes:

>Charles Lindsey:

>>    references      =  "References:" SP [CFWS] msg-id 1*(CFWS msg-id )
>>                       [CFWS] CRLF

>I suppose that was meant as

>   references      =  "References:" SP [CFWS] msg-id *( CFWS msg-id )
>                      [CFWS] CRLF

>(changed the '1*' into '*'; inserted a space)

Oops!

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

To: [email-masked]
Xref: clerew local.usefor:20799
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2045 ABNF (was: Again broken)
Date: Mon, 2 May 2005 10:48:23 GMT
Lines: 87
Sender: [email-masked]

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

>Charles Lindsey wrote:

>>> So far I didn't know that usefor-03 implicitly includes
>>> all 2045 terms.  I only knew that it includes 2822 minus
>>> obs, and of course 2234bis.

>> It needs to be stated somewhere.

>It is, I was blind.

Not in the current USEFOR AFAICS.

>  But we cannot use this pseudo-ABNF, it has
>to be fixed for the three (?) 2045 terms needed in usefor-xx:

>value, token, parameter, anything else ?

>> It even appeared (but not normatively) in my old draft-13.

>Yes, the "collected ABNF" was nice,

Actually, it was section 2.4.2 of the old draft-13 I was referring to.

>1) value = token / quoted-string

>2) parameter = attribute "=" value

>2a) attribute = token

>Same problem as with "parameter", but you only (?) need it
>indirectly for "archive-param".  In theory it's very easy to
>translate the 2231 gibberish to proper ABNF:

>  attribute      = 1*attribute-char
>  attribute-char = <any (US-ASCII) CHAR except SPACE, CTLs,
>                     "*", "'", "%", or tspecials>

>3) token = 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>                 or tspecials>

>Okay, that's the same as attribute-char plus "*", "'", "%".

Yes, because those characters have special meaning in RFC 2231. But let us
leave RFC 2231 out of the discussion to keep things simple. It can be put
back in when the basic strategy is agreed.

>> parameter = [CFWS] token [CFWS] "=" value
>> value     = [CFWS] token [CFWS] / quoted-string

>Where have you found these [CFWS] ?  Because 2045 mentions 822
>and its comments, and 2822 claims to update 822 ?

Yes. If you read the way that comments, folding and whitespace are handled
in RFC 822, then it is clear that RFC 2045 is to be interpreted with
[CFWS] in those places. I got Keith Moore to confirm that interpretation
before I wrote that RFC 2822-ized version for our 'article' drafts.

>> But I was forbidden from having that stuff incorporated into
>> USEFOR.

>Do you have a Message-ID for this obscure decree ?

It was part of the instructions given by our Chair when the old 'article'
drafts were split into USEFOR and USEPRO.

Currently, it is unclear in USEPRO, and it needs to be fixed for use in
Archive and Injection-Info. I do not care whether the fix is by
'inventing' that syntax, or by suitable hand waving, provided it gets
done.

[There are also some further nits in Injection-Info that need to be fixed,
but I shall deal with these later - best not to have too many topics on
the go at one time.]

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

To: [email-masked]
Xref: clerew local.usefor:20800
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Suggested References texts
Date: Mon, 2 May 2005 10:49:49 GMT
Lines: 28
Sender: [email-masked]

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

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

>>> I *don't* want to give the impression, even in USEFOR, that all the
>>> rules in RFC 2822 for replies apply unmodified to followups.  Replies
>>> and followups *aren't* the same thing, and I think it's worth making
>>> that clear.  Among other things, correctly constructing a followup
>>> requires dealing with fields that aren't in RFC 2822 at all.

>> Eh? Which fields might those be?

>Followup-To and Newsgroups.

Ah! My bad. I was thinking just of the References header, not of the other
things a followup agent has to get right.

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