Subject: Ticket status, March 24

From: Harald Alvestrand <[email-masked]>
Date: Fri, 24 Mar 2006 11:31:21 -0600

The last ticket status update was from March 3. Time for another round.
I believe we're close; if all's well, we should have -08 ready real 
soon, and send out a WG Last Call.

1032 USEFOR general: Document changes from RFC 1036
Incorporated in -07. Closing ticket.

1047 USEFOR 3.1.6: Path field delimiters and components
Poll showed a clear preference for moving the keywords to USEPRO.
Some adjustment of the text needed; this will be done in -08.

Status: "Text proposed".

1156 USEFOR Appendix: IANA registration form for headers.

Haven't seen more discussion of this after -07 came out.

Status: "Text accepted"

1157: USEFOR 3.2.5 Control: can't use "value" construct

Closing this ticket. No comment on the -07 version seen.

1158: USEFOR 3.2.14: Need better ABNF for host-value

Closing this ticket. No comment on the -07 version seen.

1159: USEFOR 3.2.14: Advice on sender vs posting-account

Status: "Text proposed" - poll concluded that "sender" is gone and 
"posting-account" is kept.
Needs some work on the text.

1177: USEFOR 3.2.12 Archive ABNF + 3.2.14 Injection-info ABNF

Closing this ticket. No comment on the -07 version seen.

1178: USEFOR 3.1.6: Whitespace in headers with newsgroup names (renamed 
from Whitespace in Path header)

I believe there's consensus for SHOULD NOT generate, MUST accept - just 
like we've done some other places.
Will propose text.

1179: USEFOR general: [FWS] that should be *WSP

Incorporated in -07, no more comments. Closing ticket.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Mar 2006 11:40:20 GMT

>Incorporated in -07, no more comments. Closing ticket.

Not so. The NOTE covering this in section 2.2 is in error. I pointed this
out and proposed alternative text on March 6th.

-- 
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: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Mar 2006 00:45:34 +0200

Please resend your March 6 note with the correct subject line, then.

(and please drop that "Newsgroups: local.usefor" in your headers. 
Thunderbird doesn't like it.)

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 28 Mar 2006 10:57:43 GMT

>Please resend your March 6 note with the correct subject line, then.

Yes, the whole thread of six articles, or which my note was the last, had
the wrong issue# in the Subject.

>Thunderbird doesn't like it.)

If Thunderbird cannot accept an email gatewayed from a newgroup, then
there is something wrong with it. However, I have put a bit of extra 'sed'
in my script, so you should not see it now.

Here is the repeat of mt March 6th message.

 
>>>>    NOTE: It would be hard to enforce this restriction generally in the
>>>>    syntax.  Nevertheless, the opportunity has been to do so in a few easy
>>>>    cases by the use of *FWS rather than [FWS].
.....
>>
>>To account for a different style than RFC 2822, and to make sure noone
>>goes looking for subtle effects of this different style (there are none,
>>of course).
>>
>>  
>>
>That makes sense. In that case, the NOTE should say:
 
>NOTE: The RFC 2822 specification uses <[WSP]> at the beginning of ABNF
>for header field content. This specification uses *WSP. This is done for 
>consistency with the restriction described here, but the restriction 
>applies to all header fields, not just those where ABNF is defined in 
>this document.
 
No, that is not correct (RFC 2822 does not contain "[WSP]" anywhere, and
tends to use [CFWS] at the beginning _and_end_ of header field bodies,
except for <unstructured>, where it is of course [FWS]).
 
So what you would need to say is:
 
NOTE: The [RFC 2822] specification uses, directly or indirectly, [CFWS]
(occasionally [FWS]) at the beginning and end of the ABNF for header field
bodies. In contexts where <comment>s are disallowed, this specification
uses *WSP rather than [FWS]. This is done for consistency with the
restriction described above, but that restriction applies to all header
fields, not just those where *WSP is used in this document.
 
You might be able to prune that a little.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Mar 2006 14:32:29 +0200

>You might be able to prune that a little.
What went into -07 section 2.2 was:

         NOTE: The [RFC2822] specification uses [FWS] at the beginning
         of ABNF for header field content.  This specification uses
         *WSP.  This is done for consistency with the restriction
         described here, but the restriction applies to all header
         fields, not just those where ABNF is defined in this document.

So the bug you pointed out ([WSP]) was fixed, but not the generic claim 
that RFC2822 uses FWS.

Replacing [CFWS] with *WSP removes the possibility of starting a header 
field with a comment, so it's a change that goes beyond the "no line of 
a header field body can be empty" restriction.

So my questions:

1) Have we replaced [CFWS] with *WSP anywhere?
2) Do we need to change the word "uses", and if so, to what?

                          Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Mar 2006 15:05:11 +0200

>in my script, so you should not see it now.
This is actually somewhat relevant to this WG, since it's ticket #1078 
resurfacing (it's closed as "no change needed", and I think this is an 
appropriate status, but....)

The text you suggested then said:

The Newsgroups header specifies the newsgroup(s) to which a News
article has been posted. It MAY be used in an Email message to
indicate that it was also posted as an article to those newsgroups,
but SHOULD NOT be used in Email for any other purpose (such as an
email-only reply to a News article).

The ticket is closed with "We may return to the issue in USEAGE".

If that was what you inteded with the Newsgroups: header you sent out, 
my interpretation is that in order to reach all recipients of the 
original message (reply-all), I also have to post to the local.usefor 
newsgroup.

And of course I can't do that, for a number of reasons:

1) I don't have a working usenet account
2) local.usefor isn't available outside your local scope (where I 
*certainly* don't have an account).

And of course, I don't have to do that, because it wasn't "also" posted 
to a newsgroup, it was posted to the newsgroup only, which had the side 
effect of posting it to the mailing list, and sending to the mailing 
list gets the message to all the participants in the discussion.

Before, I didn't care about these headers in practice, because I was 
using a mail client that didn't think of itself as a news client.

Now, I do.

                           Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Mar 2006 11:40:06 GMT

>The ticket is closed with "We may return to the issue in USEAGE".

Indeed. I think this is a USEAGE matter.

>original message (reply-all), I also have to post to the local.usefor 

Gatewaying can be a complex process. There exist gateways from mailing
lists to newsgroups and from newsgroups to mailing lists, and some
gateways that purport to work both ways. And when you get crossposting and
multiple gateways life gets even more complicated. There is text in USEPRO
which covers the various pitfalls, but absolute perfection is
unachievable.

In particular, there is no sure way to tell, from the headers, whether a
given mailing list or newsgroup is gatewayed, and if so exactly how,
though the presence of both a "To:" header and a "Newsgroups:" header
gives a pretty strong clue.

So any user agent that imagines it can detect the difference is deluding
itself.

The only safe rule is "if it arrived by email, then reply by email, and if
it arrived by news then reply by news". That leaves it to such gateways as
may exist to "do the right thing", whatever the "right thing" might be.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Mar 2006 11:14:11 GMT

>So the bug you pointed out ([WSP]) was fixed, but not the generic claim 

Ah! I had not spotted that small change in the actual draft-07 text.

>1) Have we replaced [CFWS] with *WSP anywhere?

No.

>2) Do we need to change the word "uses", and if so, to what?

I had two concerns with the present text.
a) It does not make it clear that it leaves the common case of [CFWS]
untouched;
b) It applies at the end as well as the beginning of the affected rules.

The text I suggested (see above) tells the truth, but is a little verbose.
Let me try something a little shorter:

   NOTE: Where some ABNF rule forbids <comment>s at the beginning or end
   of a header field content, this specification uses *WSP rather than
   [FWS] {as used in [RFC 2822]}. This is done for consistency with the
   restriction described above, but that restriction is still needed for
   the cases where [CFWS] appears.

The bit in {...} could be omitted. I think <unstructured> in the only
actual example in 2822

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Mar 2006 09:07:54 +0200

>which covers the various pitfalls, but absolute perfection is
indeed... back in the 90s there used to be a quote attributed to me:

"Alvestrand's equality: Gateways = pain".

'nuff said.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 31 Mar 2006 13:11:47 +0200

Charles Lindsey wrote:

> I think <unstructured> in the only actual example in 2822

JFTR, that's _any_ header field not explicitly known to be
structured,  The "Date:" has a leading [FWS], anything else
as far as it's structured has leading and trailing [CFWS}.

                          Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1179 not closed? Re: Ticket status, March 24
Date:  Fri, 31 Mar 2006 13:11:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Charles Lindsey wrote:

> I think <unstructured> in the only actual example in 2822

JFTR, that's _any_ header field not explicitly known to be
structured,  The "Date:" has a leading [FWS], anything else
as far as it's structured has leading and trailing [CFWS}.

                          Bye, Frank

Date: Thu, 30 Mar 2006 09:07:54 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1078 Newsgroups: header in email
Sender: [email-masked]

'nuff said.

To: [email-masked]
Xref: clerew local.usefor:23209
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1179 not closed? Re: Ticket status, March 24
Date: Wed, 29 Mar 2006 11:14:11 GMT
Lines: 73
Sender: [email-masked]

No.

To: [email-masked]
Xref: clerew local.usefor:23210
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1078 Newsgroups: header in email
Date: Wed, 29 Mar 2006 11:40:06 GMT
Lines: 58
Sender: [email-masked]

Date: Tue, 28 Mar 2006 22:34:27 +0200
From: Harald Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>
Cc: [email-masked]
Subject: Re: #1078 Newsgroups: header in email
Sender: [email-masked]

John Stanley wrote:
>
>
> Harald Alvestrand <harald@xxxxxxxxxxxxx>:
>
> A Newsgroups header field in email does NOT always indicate that a 
> message was also posted as an article to news. If we say that is what 
> it means, we will be wrong.
We don't say it - that's what Charles suggested we should say, but the 
WG consensus was to not add it.
> Some of us care about getting it right even if we don't personally use 
> a client that contains a feature (or a bug).
Before, I did not care what Charles sent to this mailing list, because 
it had no practical consequences for me, and did not affect the 
development of the document.
Now, the fact that he was not doing what he suggested the WG mandate has 
caused me extra work, so I commented on it.
I did not intend to reopen the issue; I don't see that any new evidence 
has been put forward that is likely to change the consensus of the WG.
>
> Are you officially reopening a section of the draft that is patently 
> incorrect so it can be fixed, or just using your position as chair to 
> comment on something whilst we cannot? Have we received a special 
> dispensation from the Pope of IETF to leap across into email and 
> define headers for email, or are we still limited to news?
No.
The draft is currently "correct" - it says nothing.

Date: Tue, 28 Mar 2006 09:35:22 -0800 (PST)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re:   #1078 Newsgroups: header in email
Sender: [email-masked]

>indicate that it was also posted as an article to those newsgroups,

A Newsgroups header field in email does NOT always indicate that a message 
was also posted as an article to news. If we say that is what it means, we 
will be wrong.

>Before, I didn't care about these headers in practice, because I was using 
>a mail client that didn't think of itself as a news client.

Some of us care about getting it right even if we don't personally use a 
client that contains a feature (or a bug).

Are you officially reopening a section of the draft that is patently 
incorrect so it can be fixed, or just using your position as chair to 
comment on something whilst we cannot? Have we received a special 
dispensation from the Pope of IETF to leap across into email and define 
headers for email, or are we still limited to news?

Date: Tue, 28 Mar 2006 15:05:11 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: #1078 Newsgroups: header in email
Sender: [email-masked]

Now, I do.

                           Harald

Date: Tue, 28 Mar 2006 14:32:29 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1179 not closed? Re: Ticket status, March 24
Sender: [email-masked]

So my questions:

                          Harald

To: [email-masked]
Xref: clerew local.usefor:23204
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1179 not closed? Re: Ticket status, March 24
Date: Tue, 28 Mar 2006 10:57:43 GMT
Lines: 65
Sender: [email-masked]

 
 
.....

 

Date: Tue, 28 Mar 2006 00:45:34 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: #1179 not closed? Re: Ticket status, March 24
Sender: [email-masked]

> out and proposed alternative text on March 6th.

To: [email-masked]
Xref: clerew local.usefor:23202
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Ticket status, March 24
Date: Mon, 27 Mar 2006 11:40:20 GMT
Lines: 20
Sender: [email-masked]

Date: Fri, 24 Mar 2006 11:37:48 -0600
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Closing tickets #1032, #1157, #1158, #1177, #1179
Sender: [email-masked]

Just to make sure everyone notices:

I'm closing the five tickets mentioned in the subject line, since I 
believe that what's in -07 reflects WG consensus on the issues raised.

See the ticket status summary for ticket names and comments.

There are now 4 open tickets on USEFOR.

                    Harald

Date: Fri, 24 Mar 2006 11:31:21 -0600
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Ticket status, March 24
Sender: [email-masked]

Status: "Text proposed".

Status: "Text accepted"

Date: Sun, 19 Mar 2006 11:29:30 -0600
From: Harald Alvestrand <[email-masked]>
To: Ralph Babel <[email-masked]>
Cc: [email-masked]
Subject: Re: #1032 Document changes: "text accepted"
Sender: [email-masked]

Ralph Babel wrote:
> Charles Lindsey wrote:
>
>   
>> Either of USEFOR or USEPRO on its own is useless.
>>     
>
> That uncompromising all-or-nothing attitude of yours
> probably accounts for most of the delays in the last
> ... let's see ... nine years!?
>
> Good grief. Is that an IETF record already?
I think we've got a while to go.... PKINIT took 12 years from draft to 
publication, says Aaron.....

Date: Sun, 19 Mar 2006 18:06:38 +0100
From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: #1032 Document changes: "text accepted"
Sender: [email-masked]

Charles Lindsey wrote:

> Either of USEFOR or USEPRO on its own is useless.

That uncompromising all-or-nothing attitude of yours
probably accounts for most of the delays in the last
... let's see ... nine years!?

Good grief. Is that an IETF record already?

To: [email-masked]
Xref: clerew local.usefor:23196
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Poll result - Diagnostics fixed or flexible - CONSENSUS
Date: Thu, 16 Mar 2006 12:52:18 GMT
Lines: 153
Sender: [email-masked]

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

>B) List of keywords is not fixed in USEFOR

>path-diagnostic = diag-match / diag-other / diag-deprecated

>diag-match      = "!"                     ; another "!"
>diag-deprecated = "!" IPv4address         ; (see below)
>diag-other      = "!." diag-keyword [ "." diag-identity ]

>diag-keyword    = 1*ALPHA                 ; see USEPRO

>I declare consensus for syntax B, and request that this be inserted into 
>usefor-08.

OK, but there are still some syntactic niggles, and consequential changes
to the rest of the text. Here is the full section as it would now appear,
with the further changes that I believe are required.

3.1.6.  Path
 
   The Path header field 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
                                                ^^^^^^^^^^
                                             <path-identity>s
   header field body.  This is primarily to enable news servers 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
   statistics.
 
   path            =  "Path:" SP *WSP path-list tail-entry *WSP CRLF
 
   path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )

[Observe that this allows [FWS] before each delimiter, but not after. If
anyone wants this to be changed, then please speak up. Also, it does not
permit [FWS] after a <path-diagnostic> ( and hence not before some "!"s).
See my fixes below.]
 
   path-diagnostic = diag-match / diag-other / diag-deprecated

   diag-match      = "!"                     ; another "!"
 
   diag-deprecated = "!" IPv4address         ; (see below)
                                     ^^^^^
                                     [FWS]

   diag-other      = "!." diag-keyword [ "." diag-identity ]
                                                             ^^^^^
                                                             [FWS]
 
   diag-keyword    = 1*ALPHA                 ; see USEPRO 

   diag-identity   =  path-identity / IPv4address / IPv6address
 
   tail-entry      =  path-nodot
                      ; recommended to be "not-for-mail"
                        ^^^^^^^^^^^^^^^^^
                            often
[to agree with existing NOTE below]

   path-identity   =  ( 1*( label "." ) toplabel ) / path-nodot
[I would much prefer that the <diag-deprecated> be included within
<path-identity> in the form of a <path-deprecated>.]

   path-nodot      =  1*( alphanum / "-" / "_" ) ; legacy names
                                                 ^^^^^^^^^^^^^^
                                                     OMIT
[there was no decision for forbid future use of <path-nodot>s (aka
<bareword>s), though USEPRO makes it clear that they are deprecated unless
there is a really good reason and the risks are understood.]

   label           =  alphanum [ *( alphanum / "-" ) alphanum ]

   toplabel        =  ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
                      ( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
                      ( label 1*( "-" ) label )

   alphanum        =  ALPHA / DIGIT        ; compare RFC3696

   A <path-identity> is a name identifying a site.  It takes the form of
   a domain name having one or more components separated by dots.
                                                                ^
                 or of a name without dots but possibly including a "_"

   Each <path-identity> in the <path-list> (excluding the one in the
                                            ^^^^^^^^^^^^^^^^^^^^
                                             which excludes
   <tail-entry>) indicates, from right to left, the successive agents
   through which the article has passed.  
                                          The <path-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
   verified the identity of the agent to its right before accepting the
   article (whereas the <path-delimiter> "!" implies no such claim).
   The <path-keyword> "MISMATCH" indicates that the agent to its right
   failed to be so verified.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                          A <diag-other> allows for
   assertions, identified by a <diag-keyword> according to conventions
   described in [USEPRO], concerning the source from which the article
   was received. A <diag-match> (which effectively replaces the usual
   "!" delimiter by "!!") asserts that the source from which the article
   was received has been verified to agree with the following
   <path-identity>.

      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-
                                                           <diag-
      keyword>s "POSTED" and "MISMATCH" should be in upper case, to
                ^^^^^^^^^^^^^^^^^^^^^^
                       OMIT
      distinguish them from the <path-identity>s which are traditionally
      in lower case.

   A <path-diagnostic> is an item inserted into the Path header for
   purposes other than to indicate the name of a site.  One commonly
   observed usage is to insert an IP address.  The colon (":") is
   permitted in order to allow IPv6 addresses to be inserted; note that
   this will cause interoperability problems at older sites that regard
   ":" as a <path-delimiter> and have neighbors whose names have 4 or
   fewer characters, and where all the characters are valid HEX digits.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      NOTE: Observe that IP addresses are not permitted as
      <path-identity>s.  Although they have occasionally been used in
      the past (usually with a diagnostic intent), their continued use
      is deprecated (though it is still acceptable in the form of the
      <diag-deprecated>).

      NOTE: An <IPv6address> is permitted within a <diag-identity>.
      Since an <IPv6address> can contain a colon (":") there is a small
      risk of interoperability problems at older sites that regard ":"
      as a delimiter (in place of the "!") if some neighbour identifies
      itself with a <path-nodot> composed of 4 or fewer characters which
      are all valid HEX digits.

To: [email-masked]
Xref: clerew local.usefor:23197
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 POLL RESULT - posting-account etcetera
Date: Thu, 16 Mar 2006 13:51:13 GMT
Lines: 32
Sender: [email-masked]

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

>New text:

>The "posting-account" <parameter> identifies the source from which
> that news server received the article, in a notation that can be
> interpreted by the news server admin. This notation can include any
> info the admin deems pertinent, such as the authorized and/or
> authenticated identity of the poster. In order to limit the exposure
> of personal data, it can be given in a form that can't be interpreted
> by other sites, but two messages posted from the same account SHOULD
> have the same value of "posting-account".

> It is a matter of local policy whether to include the "posting-account"
> <parameter>.

May I suggest, for that last sentence:

  It is a matter of local policy which of the various <parameter>s to
  include.  Some of them have privacy implications which are discussed
  further in [USEAGE].

Date: Mon, 13 Mar 2006 10:22:40 -0800 (PST)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - (was POLL ...)
Sender: [email-masked]

D) Remove both sender and posting-account from the spec

In <4408616E.8020905@xxxxxxxxxxxxx> Harald Alvestrand 
<harald@xxxxxxxxxxxxx> writes:

>After reviewing discussion again....

> a NEW proposed alternate text:

>  The "posting-account" <parameter> identifies the source from which
>  that news server received the article, in a notation that can be
>  interpreted by the news server admin. This notation can include any
>  info the admin deems pertinent, such as the authorized and/or
>  authenticated identity of the poster.

Distributing authenticated identities about the net is not a smart thing 
to do, and we ought not promote the idea. It is not just a privacy issue 
as some have claimed. A cracker holding a validated identity and the 
system upon which it is valid has two pieces of information out of the 
three he needs to break in.

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>It is, in any case, a matter for the poster and the admin to sort out
>between them,

What complete nonsense.

Where I "read news" (which has been broken for almost a month now), the 
"admin" has nothing to do with the news server. They outsource. The admin
at the outsource company basically says "bugger off" when the users 
contact him directly. Who is it that I'm supposed to "sort out" this 
problem with, again?

>>  It is a matter of local policy whether to include the "posting-account"
>>  <parameter>, the "sender" <parameter>, both, or neither.

It is both a privacy and a security issue and we should clearly state such
and prohibit it.

Forrest J. Cavalier III wrote:

> "I can't waste 100 bytes per message on my local logs
> so I'll waste 100 bytes of SPOOL ON EVERY SITE that stores
> articles injected here. Oh, if you want me to store your
> X-Trace headers for you, I guess so...."

Spot on.

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>The Path header in news serves a similar purpose to the Received header in
>email.

Wrong. The Received header field(s) in email document full information 
about the processing of an email message, including time of arrival and
agent data. It is not unusual for there to be more than one Received 
header field from one host.

The other obvious difference is that the Received header fields appear 
ONCE in ONE COPY of a message, while the Path header appears in each and 
every copy of the tens of thousands that appear on the net. Every byte 
added to a Path header field is duplicated untold numbers of times, while
a byte added to a Received header field is duplicated only in the one copy 
sent forward.

>What this shows is that the need for diagnostic information tends to grow,
>but that the syntax of the Received header was far too restrictive to
>accomodate what turned out to be needed.

Surly you cannot be serious.

>But it costs us nothing to allow for future extension should it be 
>needed.

"I cannot afford to store 100 bytes of logging info on my own system to 
keep track of my own users, so I will have everyone else store a copy of 
those 100 bytes on their systems for me."

Date: Mon, 13 Mar 2006 16:47:52 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1159 POLL RESULT - posting-account etcetera
Sender: [email-masked]

The March 3 poll I sent out was:

> After reviewing discussion again....
>
> a NEW proposed alternate text:
>
>  The "posting-account" <parameter> identifies the source from which
>  that news server received the article, in a notation that can be
>  interpreted by the news server admin. This notation can include any
>  info the admin deems pertinent, such as the authorized and/or
>  authenticated identity of the poster. In order to limit the exposure
>  of personal data, it SHOULD be given in a form that can't be interpreted
>  by other sites, but two messages posted from the same account SHOULD
>  have the same value of "posting-account".
>
>  The "sender" <parameter> identifies a mailbox that the news server
>  configuration shows as one that can be used to reach the user posting 
> the article. There is
>  no implied relationship between the "sender" parameter and the "From"
>  or "Sender" header fields of the article.
>
>  It is a matter of local policy whether to include the "posting-account"
>  <parameter>, the "sender" <parameter>, both, or neither.
>
> I'm asking Ken to include this text in -07; I believe it's clearer 
> than what's there now.
>
> The change from the previous version is that the constancy of 
> "posting-account" has been noted. But the discussion did not show any 
> consistent support for keeping any of these parameters, so I'm making 
> this another poll....
>
> A) Accept text above - keep posting-account and sender parameters
>
> B) Remove posting-account from the spec, keep sender
>
> C) Remove sender from the spec, keep posting-account
>
> D) Remove both sender and posting-account from the spec
>
> E) I have another opinion
>
> The text above will be adjusted accordingly if anything is removed; if 
> you want to suggest specific modifications to the text, please REMOVE 
> the word "POLL" from this subject line.

The result:

A)
Charles Lindsey (vote for)
B)
C)
Russ Allbery
Charles Lindsey (could live with)
Frank Ellermann
Richard Clayton
D)
E)
Richard Clayton (questions the value of SHOULD)

I declare rough consensus that the sender will be removed from the spec, 
and posting-account will be kept. Richard Clayton's comment seems to be 
reasonable - but I think it applies to the first SHOULD, not the second.

New text:

The "posting-account" <parameter> identifies the source from which
 that news server received the article, in a notation that can be
 interpreted by the news server admin. This notation can include any
 info the admin deems pertinent, such as the authorized and/or
 authenticated identity of the poster. In order to limit the exposure
 of personal data, it can be given in a form that can't be interpreted
 by other sites, but two messages posted from the same account SHOULD
 have the same value of "posting-account".

 It is a matter of local policy whether to include the "posting-account"
 <parameter>.

              Harald

Date: Mon, 13 Mar 2006 16:39:09 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1047 Poll result - Diagnostics fixed or flexible - CONSENSUS
Sender: [email-masked]

The poll text:

In the dialogue between Frank and Charles, I have seen two possible 
grammars for diagnostic proposed:

A) List of keywords is fixed in USEFOR

path-diagnostic =  diag-match / diag-mismatch / diag-seen /
                  diag-posted / diag-deprecated

diag-match      =  "!"                           ; an additional "!"
diag-seen       =  "!.SEEN."           diag-identity
diag-mismatch   =  "!.MISMATCH."       diag-identity
diag-posted     =  "!.POSTED"    [ "." diag-identity ]
diag-deprecated =  "!" 1*( path-nodot "." ) path-nodot

B) List of keywords is not fixed in USEFOR

path-diagnostic = diag-match / diag-other / diag-deprecated

diag-match      = "!"                     ; another "!"
diag-deprecated = "!" IPv4address         ; (see below)
diag-other      = "!." diag-keyword [ "." diag-identity ]

diag-keyword    = 1*ALPHA                 ; see USEPRO

The result:

- Syntax A:

- Syntax B:
Ruud H. G. van Tol
Russ Allbery (mild preference)
Charles Lindsey
Richard Clayton

I declare consensus for syntax B, and request that this be inserted into 
usefor-08.

To: [email-masked]
Xref: clerew local.usefor:23192
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - POLL for Proposed resolution, posting-account etcetera
Date: Fri, 10 Mar 2006 12:11:54 GMT
Lines: 23
Sender: [email-masked]

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

>I'm still a bit (E) in that I don't see that the privacy issue is a
>SHOULD rather than a MAY. Usenet is a public medium and many sites treat
>it as such -- I don't see that they need to go against a SHOULD if they
>wish to continue to do so

Yes, I agree with that to the extent that we should not be using any
SHOULD wording with regard to which <parameter>s in the Injection-Info
header to use (whatever set of parameters we finally have). USEAGE is the
proper place to discuss that, though a pointer to USEAGE would be
perfectly in order.

Date: Fri, 10 Mar 2006 00:05:09 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - POLL for Proposed resolution, posting-account etcetera
Sender: [email-masked]

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

>A) Accept text above - keep posting-account and sender parameters
>
>B) Remove posting-account from the spec, keep sender
>
>C) Remove sender from the spec, keep posting-account
>
>D) Remove both sender and posting-account from the spec
>
>E) I have another opinion

once again, apologies for being slow

I prefer (C) ... a posting account corresponds to current practice.

The "sender" concept is fundamentally flawed because people just won't
want to see a working email address there (they'll be paranoid about
spam) so it will either end up obfuscated or rubbish. Anyone using it to
try and contact a poster will need their head examined :(

I'm still a bit (E) in that I don't see that the privacy issue is a
SHOULD rather than a MAY. Usenet is a public medium and many sites treat
it as such -- I don't see that they need to go against a SHOULD if they
wish to continue to do so

- -- 
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, 9 Mar 2006 23:56:31 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1047 poll - outstanding item: diagnostics fixed or flexible
Sender: [email-masked]

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

>A) List of keywords is fixed in USEFOR
>
>path-diagnostic =  diag-match / diag-mismatch / diag-seen /
>                  diag-posted / diag-deprecated
>
>diag-match      =  "!"                           ; an additional "!"
>diag-seen       =  "!.SEEN."           diag-identity
>diag-mismatch   =  "!.MISMATCH."       diag-identity
>diag-posted     =  "!.POSTED"    [ "." diag-identity ]
>diag-deprecated =  "!" 1*( path-nodot "." ) path-nodot
>
>B) List of keywords is not fixed in USEFOR
>
>path-diagnostic = diag-match / diag-other / diag-deprecated
>
>diag-match      = "!"                     ; another "!"
>diag-deprecated = "!" IPv4address         ; (see below)
>diag-other      = "!." diag-keyword [ "." diag-identity ]
>
>diag-keyword    = 1*ALPHA                 ; see USEPRO
>
>
>I don't want to call consensus on this question (which I hope is the 
>last outstanding item for #1047) based on two people with opposite 
>viewpoints + my own opinion.
>
>Please send back a note to the list saying:
>
>- I support syntax A
>- I support syntax B
>- I have a different opinion

apologies for slow response ...

I support B -- it seems silly to have multiple documents and not use
that flexibility.  However, I don't feel very strongly on this and could
live with either

- -- 
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:23187
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1178 Whitespace in Path header
Date: Wed, 8 Mar 2006 13:58:59 GMT
Lines: 26
Sender: [email-masked]

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

>Pilot error. I was searching for a ticket to capture the issue on 
>whether to have folding whitespace in the Path: header before the !, 
>after the !, between the !!, neither, or all, and it seems that I messed 
>up the coupling between the article I quoted from and the issue - this 
>should be two tickets, not one.

I think we are agreed that we need to allow [FWS] at least _before_ every
"!" or "!!" (but not inside a "!!). I think that is what all the recently
proposed grammars do.

One might also allow it _after_ AS WELL. I do not hear much pressure for
that, and the ABNF would get a bit more complicated, but it could be done
if people want it so.

Date: Wed, 08 Mar 2006 09:47:10 -0500
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1032 Document changes: "text accepted"
Sender: [email-masked]

Charles Lindsey wrote:

> In <[email-masked]> Frank Ellermann <[email-masked]> writes:
> 
> 
>>Yes.  It only explains the harm for poor users getting an
>>obscure error message,  USEFOR is for ordinary users, and
>>USEPRO more for admins / implementors / gateway operators.
> 
> 
> I don't see it that way. Either of USEFOR or USEPRO on its own is useless.
> You need both in order to understand the whole system.
> 
> You could, in theory, manage without USEAGE, but you might invent some
> rather useless implementations that way.
> 

Seems to me that people have been managing in practice without USEFOR, USEPRO,
and USEAGE.

Is it August 2005 yet?  Isn't that the current deadline to finish before
we dissolve?  Let's synchronize our watches again.

Date: Tue, 7 Mar 2006 19:29:31 +0100
From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> "I can't waste 100 bytes per message on my local logs
> so I'll waste 100 bytes of SPOOL ON EVERY SITE that stores
> articles injected here. Oh, if you want me to store your
> X-Trace headers for you, I guess so...."

Well put.

To: [email-masked]
Xref: clerew local.usefor:23184
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1032 Document changes: "text accepted"
Date: Tue, 7 Mar 2006 15:10:52 GMT
Lines: 22
Sender: [email-masked]

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

>Yes.  It only explains the harm for poor users getting an
>obscure error message,  USEFOR is for ordinary users, and
>USEPRO more for admins / implementors / gateway operators.

I don't see it that way. Either of USEFOR or USEPRO on its own is useless.
You need both in order to understand the whole system.

You could, in theory, manage without USEAGE, but you might invent some
rather useless implementations that way.

Date: Tue, 07 Mar 2006 17:44:58 +0100
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1178 Whitespace in Path header
Sender: [email-masked]

Pilot error. I was searching for a ticket to capture the issue on 
whether to have folding whitespace in the Path: header before the !, 
after the !, between the !!, neither, or all, and it seems that I messed 
up the coupling between the article I quoted from and the issue - this 
should be two tickets, not one.

I'll change the subject header on this one.

Frank Ellermann wrote:
> Harald Alvestrand wrote:
>  
>   
>> Does anyone wish to attempt to present a possible consensus
>> text?
>>     
>
> Already posted in <[email-masked]> or
> <news://news.gmane.org/[email-masked]>
>
> ~~~ cut ~~~
>   
>> 1178: USEFOR 3.1.6: Whitespace in Path header
>>     
>
>   
>>   Consensus is not clear to me.
>>     
>
> Oops, that's a misleading title.  The issue is WSP in all of
> Newsgroups, FollowupsTo, and Distribution:
>
> Newsgroups: one, two, three
>
> That doesn't work as expected on many servers, the blank after
> the comma (any FWS).  USEPRO offers a note about this issue to
> be moved to USEFOR.  For FollowupsTo and Disribution it's the
> same issue, they only need a pointer to SHOULD NOT (or whatever
> it is) for Newsgroups.
>
> Or rather FollowupsTo is clear as soon as Newgroups is clear -
> it's the same syntax.  So only Distribution needs a pointer.
>
> ~~~ end ~~~
>                        Bye, Frank
>
>
>
>   

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1178 Whitespace in Path header
Date:  Mon, 06 Mar 2006 19:30:48 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 30
Sender: [email-masked]

Harald Alvestrand wrote:
 
> Does anyone wish to attempt to present a possible consensus
> text?

Already posted in <[email-masked]> or
<news://news.gmane.org/[email-masked]>

~~~ cut ~~~
> 1178: USEFOR 3.1.6: Whitespace in Path header

>   Consensus is not clear to me.

Oops, that's a misleading title.  The issue is WSP in all of
Newsgroups, FollowupsTo, and Distribution:

Newsgroups: one, two, three

That doesn't work as expected on many servers, the blank after
the comma (any FWS).  USEPRO offers a note about this issue to
be moved to USEFOR.  For FollowupsTo and Disribution it's the
same issue, they only need a pointer to SHOULD NOT (or whatever
it is) for Newsgroups.

Or rather FollowupsTo is clear as soon as Newgroups is clear -
it's the same syntax.  So only Distribution needs a pointer.

~~~ end ~~~
                       Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1032 Document changes: "text accepted"
Date:  Mon, 06 Mar 2006 19:48:10 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Charles Lindsey wrote:

> if it makes Frank happy it does no harm.

Yes.  It only explains the harm for poor users getting an
obscure error message,  USEFOR is for ordinary users, and
USEPRO more for admins / implementors / gateway operators.

                         Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1159 USEFOR 3.2.14 - POLL for Proposed resolution, posting-account etcetera
Date:  Mon, 06 Mar 2006 19:34:49 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 8
Sender: [email-masked]

Russ Allbery wrote:

>> C) Remove sender from the spec, keep posting-account
 
> I vote for C.

Dito  {{ adding the usual disclaimer about "voting"... ;-) }}

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usefor-07.txt 
Date: Mon, 06 Mar 2006 15:50:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Netnews Article Format
	Author(s)	: C. Lindsey, et al.
	Filename	: draft-ietf-usefor-usefor-07.txt
	Pages		: 46
	Date		: 2006-3-6
	
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-07.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-07.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-07.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-07.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Xref: clerew local.usefor:23179
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1178 Whitespace in Path header
Date: Mon, 6 Mar 2006 13:22:34 GMT
Lines: 72
Sender: [email-masked]

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

>There has been no discussion on this ticket (that I remember) since my 
>last summary, where my status note was "Consensus is not clear to me".

>Does anyone wish to attempt to present a possible consensus text?

Hmmmmmm! How did this issue come to be associated with the Path header?
The text mentioned in the ticket, which currently sits in USEPRO, related
to the Newsgroups header. But actually, the matter arises with Newsgroups,
Distribution and Path.

The text currently written for Newsgroups (3.1.5) is misleading, as I am
sure I have pointed out before.

Currently, it says:

   Folding the Newsgroups header field over several lines has been shown
   to harm propagation significantly.  Folded Newsgroups header fields
   SHOULD NOT be generated, but MUST be accepted.

Which does not make it clear that this folding is newly introduced, and
moreover the effects of introducing it suddenly would be far worse than
"harming propagation significantly".

So what it needs in 3.1.5 is something like:

   The possibility to fold this header field is newly introduced by this
   standard, and would have a severe impact on propagation if introduced
   prematurely. Therefore, although FWS MUST be accepted where required by
   the syntax above, it SHOULD NOT be generated at the present time. This
   restriction may well be removed in a future version of this standard.

The effects of introducing it in the Distribution and Path headers are
much less severe (even benign in the Path case). Moreover, it was arguably
permitted by RFC 1036 in the Path case. So the wording there need not be
so harsh.

So in 3.2.7 (Distribution) you could write:

   Folding of this header field may result in <dist-name>s being ignored
   in the folded lines by some current news servers. Therefore, although
   FWS MUST be accepted where required by the syntax above, it SHOULD NOT
   be generated at the present time. This restriction may well be removed
   in a future version of this standard.

And similarly in 3.1.6 (Path):

   Folding of this header field may result in <whatever-we-call-them>s
   being ignored in the folded lines by some current news servers.
   Therefore, although FWS MUST be accepted where required by the syntax
   above, it SHOULD NOT be generated at the present time. This restriction
   may well be removed in a future version of this standard.

Actually, that last one may still be too strong. USEPRO currently
encourages you to fold the Path header, and Frank's comment in the ticket
seems to want to retain that. So we need to decide it now so that USEPRO
can be made to fit later. One might even remove all mention of it in
USEFOR (recall that the worst that can happen if a Path gets folded at the
present time is that some article may get sent to a server that already
has it.

To: [email-masked]
Xref: clerew local.usefor:23178
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 -  (was POLL ...)
Date: Mon, 6 Mar 2006 12:26:42 GMT
Lines: 45
Sender: [email-masked]

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

>After reviewing discussion again....

> a NEW proposed alternate text:

>  The "posting-account" <parameter> identifies the source from which
>  that news server received the article, in a notation that can be
>  interpreted by the news server admin. This notation can include any
>  info the admin deems pertinent, such as the authorized and/or
>  authenticated identity of the poster. In order to limit the exposure
>  of personal data, it SHOULD be given in a form that can't be interpreted
>  by other sites, but two messages posted from the same account SHOULD
>  have the same value of "posting-account".

Yes, that is better, but I still detect a slight inconsistency. If the
authenticated identity of the poster (presumably some text agreed between
the poster and the admin) has some obvious relation to the name/identity
of the poster (e.g. it is his email address, as is sometimes the case),
then clearly other sites will be able to interpret it. IOW that 1st
"SHOULD" is a bit too strong. Perhaps some text involving "should
preferably" would work better.

It is, in any case, a matter for the poster and the admin to sort out
between them, and the most our text should be doing is to draw attention
to something they should be bearing in mind. And, of course, USEAGE may
well say more.

>  It is a matter of local policy whether to include the "posting-account"
>  <parameter>, the "sender" <parameter>, both, or neither.

A more general sentence incorporating all the various parameters would be
better, possibly with a pointer to USEAGE for further discussion.

To: [email-masked]
Xref: clerew local.usefor:23177
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - POLL for Proposed resolution, posting-account etcetera
Date: Mon, 6 Mar 2006 12:13:10 GMT
Lines: 26
Sender: [email-masked]

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

>A) Accept text above - keep posting-account and sender parameters

>B) Remove posting-account from the spec, keep sender

>C) Remove sender from the spec, keep posting-account

>D) Remove both sender and posting-account from the spec

>E) I have another opinion

I vote for A.

But I could live with C.

To: [email-masked]
Xref: clerew local.usefor:23174
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1177 FWS -> *WSP (Re: Ticket status, February 20, 2006)
Date: Mon, 6 Mar 2006 12:00:34 GMT
Lines: 48
Sender: [email-masked]

.....

To: [email-masked]
Xref: clerew local.usefor:23176
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 poll - outstanding item: diagnostics fixed or flexible
Date: Mon, 6 Mar 2006 12:09:44 GMT
Lines: 22
Sender: [email-masked]

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

>- I support syntax A
>- I support syntax B
>- I have a different opinion

I support syntax B

I have also some niggles regarding <diag-deprecated>, but these are
orthogonal to the question being asked, and are in any case 2nd order
issues.

To: [email-masked]
Xref: clerew local.usefor:23175
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1032 Document changes: "text accepted"
Date: Mon, 6 Mar 2006 12:04:40 GMT
Lines: 25
Sender: [email-masked]

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

>Suggested addition to appendix B:

>   The convention to interpret subjects starting
>   with the word "cmsg" as control message was removed.

I still don't understand this, but if it makes Frank happy it does no harm.

There is absolutely nothing in the text of USEFOR which relates to this
change, or would have been different if we had not made the change.

There is, of course, a substantial chunk of text in USEPRO which addresses
this change.

Date: 05 Mar 2006 20:25:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: path-legacy (bareword) and toplabel in A ~ B
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 16.01.06 in <[email-masked]>:

> --On mandag, januar 16, 2006 14:40:42 +0100 Frank Ellermann
> <[email-masked]> wrote:
>
> > Your 2822 optional-field example is interesting.  So we _can_
> > have some "catch-all" rules and similar ambiguities, as long
> > as they come after all matching more specific alternatives.
>
> I think ABNF is actually silent on the subject; the running code seems to
> be "ambiguous grammars are OK, you have to look at the text to figure out
> how to resolve them".
>
> Ugly....

The obvious way to do this is to say if it matches a more specific rule  
and a more general rule, interpret it as matching the more specific rule.  
It certainly is *NOT* to rely on what comes first in the text.

Rule A is more specific than rule B if rule B matches everything that rule  
A does, but rule A does *not* match everything that rule B does. Example:  
A = *digit; B = *alphanum; A is more specific than B because every digit  
sequence is an alphanum sequence but not the other way around, and 123 is  
A and not B under this interpretation.

If it matches two rules where one is not more specific than the other,  
either it needs text explaining what it means, or it's a grammar bug. Or  
maybe we'd need an exception for syntactic sugar without inherent semantic  
meaning, where the semantic comes out the same no matter which alternative  
it's taken to match (such as FWS, commas, or the like, being grouped to  
the right or to the left)?

See it as similar to the idea to go for the longest possible match.

MfG Kai

Date: 05 Mar 2006 22:17:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
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] (Russ Allbery)  wrote on 23.02.06 in <[email-masked]>:

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

> > Apparently not there, they had some privacy trouble with the unencoded
> > X-Trace, they wouldn't stick to it if it's redundant.
>
> You're rather optimistic there.  :)

Well ... they *did* run a text-only newsserver, and have a team of people  
actually talking to their users in their internal newsgroups, and doing  
their best to teach them netiquette. (For all I know, they might still do  
so - I'm no longer a customer.) Hey, they often knew more about DSL  
outages than the DSL handling departments of T-Online!

MfG Kai

Date: Sun, 05 Mar 2006 18:47:28 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: draft-ietf-usefor-usefor-07
Sender: [email-masked]

I just submitted version 07 of the format draft.  The full text can be 
obtained here:

http://www.contrib.andrew.cmu.edu/~murch/draft-ietf-usefor-usefor-07.txt

The diffs from version 06 can be obtained here:

http://tinyurl.com/nafm2

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - POLL for Proposed resolution, posting-account etcetera
Organization: The Eyrie
Date: Fri, 03 Mar 2006 11:01:39 -0800
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> The change from the previous version is that the constancy of
> "posting-account" has been noted. But the discussion did not show any
> consistent support for keeping any of these parameters, so I'm making
> this another poll....

> A) Accept text above - keep posting-account and sender parameters
> B) Remove posting-account from the spec, keep sender
> C) Remove sender from the spec, keep posting-account
> D) Remove both sender and posting-account from the spec
> E) I have another opinion

I vote for C.

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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1047 poll - outstanding item: diagnostics fixed or flexible
Organization: The Eyrie
Date: Fri, 03 Mar 2006 10:42:53 -0800
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> Please send back a note to the list saying:

> - I support syntax A
> - I support syntax B
> - I have a different opinion

I think I have a mild preference for B, although either is fine with me.

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

Date: Fri, 03 Mar 2006 16:52:47 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Ticket status, March 3, 2006
Sender: [email-masked]

The last ticket status update was from Feb 20. Time for another round.

 Comments from Charles Lindsey and Frank Ellermann that the convention
 of putting "cmsg" in the subject is no longer valid.

 Suggested addition to appendix B:

   The convention to interpret subjects starting
   with the word "cmsg" as control message was removed.

 Status: "Text accepted".

Discussion has not clarified whether keywords are in USEFOR or USEPRO.
Poll sent out on March 3.

Otherwise, syntax seems to have converged.

Status: "Text proposed".

 Seems uncontroversial, once the rules have been made clear.
 Editor has added registration templates to forthcoming -07, and posted 
deltas to the list.

 Some controversy over the choice of reference for some headers; leaving 
open for now.

 Status: "Text proposed"

 Status: "Text proposed", no comment on list since last time. 
Incorporated in -07.

 Status: "Text proposed" - seems uncontroversial. Incorporated (with 
example) in -07.

 Status: "Text proposed" - also a poll in progress on keeping vs 
deleting the fields

 "Text accepted", including note (recorded in tracker March 3)

1178: USEFOR 3.1.6: Whitespace in Path header

 Consensus is STILL not clear to me.

 (Discussed on the list with subject line containing #1177)

 I think Frank's suggested changes are now accepted, with the NOTE I 
suggested in section 2.2 giving adequate warning. But since this text is 
new:

 Status: "Text proposed".

That's all folks....

Date: Fri, 03 Mar 2006 16:51:56 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1178 Whitespace in Path header
Sender: [email-masked]

There has been no discussion on this ticket (that I remember) since my 
last summary, where my status note was "Consensus is not clear to me".

Does anyone wish to attempt to present a possible consensus text?

                  Harald

Date: Fri, 03 Mar 2006 16:31:58 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1159 USEFOR 3.2.14 - POLL for Proposed resolution, posting-account etcetera
Sender: [email-masked]

After reviewing discussion again....

 a NEW proposed alternate text:

  The "posting-account" <parameter> identifies the source from which
  that news server received the article, in a notation that can be
  interpreted by the news server admin. This notation can include any
  info the admin deems pertinent, such as the authorized and/or
  authenticated identity of the poster. In order to limit the exposure
  of personal data, it SHOULD be given in a form that can't be interpreted
  by other sites, but two messages posted from the same account SHOULD
  have the same value of "posting-account".

  The "sender" <parameter> identifies a mailbox that the news server
  configuration shows as one that can be used to reach the user posting 
the article. There is
  no implied relationship between the "sender" parameter and the "From"
  or "Sender" header fields of the article.

  It is a matter of local policy whether to include the "posting-account"
  <parameter>, the "sender" <parameter>, both, or neither.

I'm asking Ken to include this text in -07; I believe it's clearer than 
what's there now.

The change from the previous version is that the constancy of 
"posting-account" has been noted. But the discussion did not show any 
consistent support for keeping any of these parameters, so I'm making 
this another poll....

A) Accept text above - keep posting-account and sender parameters

B) Remove posting-account from the spec, keep sender

C) Remove sender from the spec, keep posting-account

D) Remove both sender and posting-account from the spec

E) I have another opinion

The text above will be adjusted accordingly if anything is removed; if 
you want to suggest specific modifications to the text, please REMOVE 
the word "POLL" from this subject line.

                  Harald

From: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Subject: Re: #1047 poll - outstanding item: diagnostics fixed or flexible
Date: Fri, 3 Mar 2006 16:26:49 +0100
Organization: Chaos rules.
Sender: [email-masked]

Harald Alvestrand schreef:

> - I support syntax B

-- 
Grtz, Ruud

Date: Fri, 03 Mar 2006 15:56:36 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1155 "ABNF imports" closed
Sender: [email-masked]

FTR: I have closed ticket #1155 ABNF imports.

Date: Fri, 03 Mar 2006 15:45:53 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1047 poll - outstanding item: diagnostics fixed or flexible
Sender: [email-masked]

In the dialogue between Frank and Charles, I have seen two possible 
grammars for diagnostic proposed:

A) List of keywords is fixed in USEFOR

path-diagnostic =  diag-match / diag-mismatch / diag-seen /
                   diag-posted / diag-deprecated

diag-match      =  "!"                           ; an additional "!"
diag-seen       =  "!.SEEN."           diag-identity
diag-mismatch   =  "!.MISMATCH."       diag-identity
diag-posted     =  "!.POSTED"    [ "." diag-identity ]
diag-deprecated =  "!" 1*( path-nodot "." ) path-nodot

B) List of keywords is not fixed in USEFOR

path-diagnostic = diag-match / diag-other / diag-deprecated

 diag-match      = "!"                     ; another "!"
 diag-deprecated = "!" IPv4address         ; (see below)
 diag-other      = "!." diag-keyword [ "." diag-identity ]

 diag-keyword    = 1*ALPHA                 ; see USEPRO

I don't want to call consensus on this question (which I hope is the 
last outstanding item for #1047) based on two people with opposite 
viewpoints + my own opinion.

Please send back a note to the list saying:

- I support syntax A
- I support syntax B
- I have a different opinion

This poll will last until March 10 (one week from today).

Since that is after the posting deadline for drafts before the IETF, 
I've instructed Ken to include the first syntax in the next version of 
the draft; this should not be taken as biasing the poll either way.

                 Harald

Date: Fri, 03 Mar 2006 15:19:41 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1032 Document changes: "text accepted"
Sender: [email-masked]

No reactions to the "text proposed" in the Feb 20 ticket update.

I'm moving this to "text accepted".

The text in question was:

Suggested addition to appendix B:

   The convention to interpret subjects starting
   with the word "cmsg" as control message was removed.

Date: Fri, 03 Mar 2006 14:45:07 +0100
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1177 FWS -> *WSP (Re: Ticket status, February 20, 2006)
Sender: [email-masked]

Charles Lindsey wrote:

>In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:
>
>  
>
>>--On mandag, februar 27, 2006 11:25:46 +0000 Charles Lindsey 
>><[email-masked]> wrote:
>>    
>>
>
>  
>
>>>In that case, please can we have a NOTE such as the following after the
>>>2nd bullet in 2.2:
>>>
>>I don't see the need for such a note. Harmless, but why?
>>    
>>
>

Generally, a sentence containing the word "generally" should, as a 
general rule, be reworded :-)

To: [email-masked]
Xref: clerew local.usefor:23160
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1177 FWS -> *WSP (Re: Ticket status, February 20, 2006)
Date: Thu, 2 Mar 2006 15:09:25 GMT
Lines: 36
Sender: [email-masked]

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

>--On mandag, februar 27, 2006 11:25:46 +0000 Charles Lindsey 
><[email-masked]> wrote:

>> In that case, please can we have a NOTE such as the following after the
>> 2nd bullet in 2.2:
>>

>I don't see the need for such a note. Harmless, but why?

>(in general, ABNF has to allow everything the text allows, but ABNF can't 
>possibly disallow everything the text disallows)

Indeed. But NOTEs are still useful "for the less than omniscient reader",
as Henry Spencer said, to explain things which may not be obvious at first
(or even second) sight.