Re: email vs. Email

[[e-mail] (Ralph Babel)]

Dan Kohn wrote:

> Ralph Babel wrote:
>
>> Can you think of any other words beginning with
>> a single-letter morpheme that used to be spelled
>> with a hyphen that has now disappeared?
>
> The hyphen in e-commerce is rapidly disappearing.
> Same with e-fax. Another would be m-commerce.

That's pretty much the same category as "e[-]mail".
Something slightly less controversial maybe?





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3UCWdR8042457; Sun, 30 Apr 2006 05:32:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3UCWdgj042456; Sun, 30 Apr 2006 05:32:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from phobos.pfm-mainz.de (phobos.pfm-mainz.de [145.253.109.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3UCWbMv042448 for <[e-mail]>; Sun, 30 Apr 2006 05:32:38 -0700 (MST) (envelope-from [e-mail])
Received: from nemesis.pfm-mainz.de (localhost [127.0.0.1]) by phobos.pfm-mainz.de (Postfix) with ESMTP id 0661810DDC1 for <[e-mail]>; Sun, 30 Apr 2006 14:32:33 +0200 (CEST)
Date: Sun, 30 Apr 2006 14:31:54 +0200
Message-Id: <[e-mail]>
In-Reply-To: <005c01c66c02$17c504c0$0201000a@dankohny2>
From: [e-mail] (Ralph Babel)
To: [e-mail]
Subject: Re: email vs. Email
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Dan Kohn wrote:

> Ralph Babel wrote:
>
>> Can you think of any other words beginning with
>> a single-letter morpheme that used to be spelled
>> with a hyphen that has now disappeared?
>
> The hyphen in e-commerce is rapidly disappearing.
> Same with e-fax. Another would be m-commerce.

That's pretty much the same category as "e[-]mail".
Something slightly less controversial maybe?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3U2xWne089816; Sat, 29 Apr 2006 19:59:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3U2xWpo089815; Sat, 29 Apr 2006 19:59:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k3U2xUWt089809 for <[e-mail]>; Sat, 29 Apr 2006 19:59:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 70671 invoked by uid 0); 30 Apr 2006 02:59:29 -0000
Received: from unknown (HELO dankohny2) (unknown) by unknown with SMTP; 30 Apr 2006 02:59:29 -0000
X-pair-Authenticated: 69.181.82.41
From: "Dan Kohn" <[e-mail]>
To: "'Ralph Babel'" <[e-mail]>, <[e-mail]>
Subject: RE: email vs. Email
Date: Sat, 29 Apr 2006 19:59:25 -0700
Message-ID: <005c01c66c02$17c504c0$0201000a@dankohny2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Thread-Index: AcZrdxocQActwZm3SI2Vgg7Ujtt6lAAiog0g
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

>> I had in mind this little writeup by Donald Knuth:

>Thought so. Can you think of any other words beginning with a single-letter
>morpheme that used to be spelled with a hyphen that has now disappeared?

The hyphen in e-commerce is rapidly disappearing.  Same with e-fax.  Another
would be m-commerce.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3TANE0T052483; Sat, 29 Apr 2006 03:23:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3TANEAW052482; Sat, 29 Apr 2006 03:23:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from phobos.pfm-mainz.de (phobos.pfm-mainz.de [145.253.109.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3TANDUG052475 for <[e-mail]>; Sat, 29 Apr 2006 03:23:14 -0700 (MST) (envelope-from [e-mail])
Received: from nemesis.pfm-mainz.de (localhost [127.0.0.1]) by phobos.pfm-mainz.de (Postfix) with ESMTP id DCCAE10DDBF for <[e-mail]>; Sat, 29 Apr 2006 12:23:06 +0200 (CEST)
Date: Sat, 29 Apr 2006 12:22:50 +0200
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
From: [e-mail] (Ralph Babel)
To: [e-mail]
Subject: Re: email vs. Email
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Dan Kohn wrote:

> I had in mind this little writeup by Donald Knuth:

Thought so. Can you think of any other words beginning
with a single-letter morpheme that used to be spelled
with a hyphen that has now disappeared?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3QHq3uc086648; Wed, 26 Apr 2006 10:52:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3QHq3bm086647; Wed, 26 Apr 2006 10:52:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3QHq1MV086641 for <[e-mail]>; Wed, 26 Apr 2006 10:52:02 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A588F259723; Wed, 26 Apr 2006 19:51:33 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10979-03; Wed, 26 Apr 2006 19:51:29 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8317F259727; Wed, 26 Apr 2006 19:51:29 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 26 Apr 2006 19:51:56 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
Cc: Dan Kohn <[e-mail]>, [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Alexey Melnikov wrote:
>
>> I think the ABNF is stable now. Ken, do you feel like writing one?
>>
>> But this doesn't address the basic question on whether the lines Dan 
>> listed above should continue to be listed in their various sections, 
>> whether they should be in the collected ABNF, whether they should be 
>> dropped altogether, or whether more ABNF for other fields mentioned 
>> (such as the MIME headers) should be added.
>>
>> I can't bring myself to care much one way or the other; their 
>> inclusion or non-inclusion doesn't change the protocol that the 
>> document specifies. Leave them the way they are?
>
> I don't see a strong argument to convince myself one way or another. I 
> tend to agree with Charles that the balance is about right. So just 
> leaving the document the way it is now is fine with me.
>
I think that's a reasonable resolution.
No change.

                 Harald



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3QBMS4s068791; Wed, 26 Apr 2006 04:22:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3QBMSiT068790; Wed, 26 Apr 2006 04:22:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3QBMQb5068781 for <[e-mail]>; Wed, 26 Apr 2006 04:22:27 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 26 Apr 2006 12:22:14 +0100
Message-ID: <[e-mail]>
Date: Wed, 26 Apr 2006 09:50:18 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Harald Alvestrand <[e-mail]>
CC: Dan Kohn <[e-mail]>, [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Alvestrand wrote:

> Alexey Melnikov wrote:
>
>> Harald Alvestrand wrote:
>>
>>>>>>>    The MIME header fields MIME-Version, Content-Type, Content- 
>>>>>>> Transfer-
>>>>>>>    Encoding, Content-Disposition, and Content-Language are used  
>>>>>>> in news
>>>>>>>    articles in the same circumstances and with the same meanings as
>>>>>>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with  
>>>>>>> the added
>>>>>>>    restrictions detailed in Section 2.2.
>>>>>>
>>>>>> It's inconsistent that the ABNF for RFC 2822 headers has been  
>>>>>> repeated throughout the spec (with the addition of : SP), but 
>>>>>> not  these headers.  My first choice would be to remove all ABNF 
>>>>>> from  the spec that only differ in showing the ": SP" (although 
>>>>>> they  might still be included in an appendix).  Alternatively, 
>>>>>> these  headers should be specified.
>>>>>
>>>>> Are there other headers that differ only with the ": SP"? I'm not  
>>>>> sure.
>>>>> Other opinions?
>>>>
>>>> The following header ABNF differ from RFC 2822 only in their use 
>>>> of  ": SP".  I believe all of the following would best be moved to 
>>>> an  appendix:
>>>>
>>>>    from            =  "From:" SP mailbox-list CRLF
>>>>    orig-date       =  "Date:" SP date-time CRLF
>>>>    subject         =  "Subject:" SP unstructured CRLF
>>>>    sender          =  "Sender:" SP mailbox CRLF
>>>>    reply-to        =  "Reply-To:" SP address-list CRLF
>>>>    comments        =  "Comments:" SP unstructured CRLF
>>>>    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF
>>>
>>> Thanks. I don't see that including this ABNF in this document 
>>> contributes much at all - except that it gives the sections a 
>>> consistent look. Other opinions?
>>
>> If I remember correctly Charles has suggested to have collected ABNF 
>> in one place, so that people don't have to track 4 different 
>> documents for different ABNF pieces.
>> If I am to choose between ABNF only or existing sections describing 
>> 2822 header fields, I choose ABNF. But I am fine with leaving 
>> existing sections as is and add ABNF in an appendix.
>
> A collected ABNF of what? All constructs defined in USEFOR, or all 
> constructs from USEFOR and its supporting documents?
>
> I think it would be presumptuous and error-prone to include all of 
> 2822's grammar in an USEFOR appendix

I agree.

> - a collected ABNF for the USEFOR constructs might be a Good Thing;

Yes.

> I think the ABNF is stable now. Ken, do you feel like writing one?
>
> But this doesn't address the basic question on whether the lines Dan 
> listed above should continue to be listed in their various sections, 
> whether they should be in the collected ABNF, whether they should be 
> dropped altogether, or whether more ABNF for other fields mentioned 
> (such as the MIME headers) should be added.
>
> I can't bring myself to care much one way or the other; their 
> inclusion or non-inclusion doesn't change the protocol that the 
> document specifies. Leave them the way they are?

I don't see a strong argument to convince myself one way or another. I 
tend to agree with Charles that the balance is about right. So just 
leaving the document the way it is now is fine with me.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3Q53grV050847; Tue, 25 Apr 2006 22:03:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3Q53ggs050846; Tue, 25 Apr 2006 22:03:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3Q53fK0050840 for <[e-mail]>; Tue, 25 Apr 2006 22:03:41 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id A59EAD4C87D; Wed, 26 Apr 2006 01:03:40 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 26 Apr 2006 01:02:55 -0400
X-Sasl-enc: YroBF1Ajond4QoZT7sokG2R+9GdzZit+QTaHhrQyoQtT 1146027775
Received: from [10.0.1.2] (c-69-181-82-41.hsd1.ca.comcast.net [69.181.82.41]) by frontend3.messagingengine.com (Postfix) with ESMTP id 5CFC73C7B; Wed, 26 Apr 2006 01:02:53 -0400 (EDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: Dan Kohn <[e-mail]>
Subject: Re: email vs. Email
Date: Tue, 25 Apr 2006 22:03:33 -0700
To: Ralph Babel <[e-mail]>
X-Mailer: Apple Mail (2.749.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Apr 25, 2006, at 5:06 AM, Ralph Babel wrote:

> Dan Kohn wrote:
>
>> Some use e-mail, but hyphens are regularly
>> dropped as words become more familiar.
>
> As in "tshirt"?
>
>> By contrast, in Google, NetNews has a variety
>> of capitalizations, including Netnews, and
>> netnews. So, I would use email and Netnews.
>
> Is this a poll?
>
> [x] e-mail <URL:http://m-w.com/cgi-bin/dictionary?va=e-mail>
> [x] netnews

T-shirt is definitely a counterexample (or counter-example).  I had  
in mind this little writeup by Donald Knuth:

http://www-cs-faculty.stanford.edu/~uno/email.html
"Email (let's drop the hyphen): A note on email versus e-mail

Newly coined nonce words of English are often spelled with a hyphen,  
but the hyphen disappears when the words become widely used. For  
example, people used to write ``non-zero'' and ``soft-ware'' instead  
of ``nonzero'' and ``software''; the same trend has occurred for  
hundreds of other words. Thus it's high time for everybody to stop  
using the archaic spelling ``e-mail''. Think of how many keystrokes  
you will save in your lifetime if you stop now! The form ``email''  
has been well established in England for several years, so I am  
amazed to see Americans being overly conservative in this regard. (Of  
course, ``email'' has been a familiar word in France, Germany, and  
the Netherlands much longer than in England --- but for an entirely  
different reason.) "

            - dan
-- 
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com/>  <tel:[phone]>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3PGECud017672; Tue, 25 Apr 2006 09:14:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3PGECbS017671; Tue, 25 Apr 2006 09:14:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3PGEAcO017663 for <[e-mail]>; Tue, 25 Apr 2006 09:14:11 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-65-179.midband.mdip.bt.net ([81.144.65.179]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444e4ad1.13f77.10a for [e-mail]; Tue, 25 Apr 2006 17:14:09 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3PGCPW19848 for [e-mail]; Tue, 25 Apr 2006 17:12:25 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23273
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 25 Apr 2006 14:33:17 GMT
Lines: 58
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>Alexey Melnikov wrote:

>> Harald Alvestrand wrote:
>>
>> If I remember correctly Charles has suggested to have collected ABNF 
>> in one place, so that people don't have to track 4 different documents 
>> for different ABNF pieces.
>> If I am to choose between ABNF only or existing sections describing 
>> 2822 header fields, I choose ABNF. But I am fine with leaving existing 
>> sections as is and add ABNF in an appendix.

>A collected ABNF of what? All constructs defined in USEFOR, or all 
>constructs from USEFOR and its supporting documents?

>I think it would be presumptuous and error-prone to include all of 
>2822's grammar in an USEFOR appendix - a collected ABNF for the USEFOR 
>constructs might be a Good Thing; I think the ABNF is stable now. Ken, 
>do you feel like writing one?

I would certainly like to see a collected ABNF at least of what is in our
document.

In the original "article" drafts we went further and included, in an
appendix, all the ABNF that we relied on from in other documents, all
carefully annotated so you could see where each rule came from and whether
it had been changed. But of course it was all non-normative (though AFAIK
it was all transcribed correctly).

So there are the two extremes - doubtless intermediate states are
possible. I think it is really up to Ken, but a study of the old article
draft-13 would show what is possible. OTOH, we really ought to be getting
on with USEPRO now, so any work on Appendices ought to proceed in parallel
with that (such work would introduce no technical changes, though it might
uncover a few bugs).

>But this doesn't address the basic question on whether the lines Dan 
>listed above should continue to be listed in their various sections, 
>whether they should be in the collected ABNF, whether they should be 
>dropped altogether, or whether more ABNF for other fields mentioned 
>(such as the MIME headers) should be added.

Whatever we do is a compromise. My view is that Ken got it about right,
and that we should leave it as it is (just so long as it is clear that the
SP requirement applies to ALL headers appearing in Netnews articles,
wherever their original ABNF is defined).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3PGEARc017662; Tue, 25 Apr 2006 09:14:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3PGEAEf017661; Tue, 25 Apr 2006 09:14:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3PGE9C7017635 for <[e-mail]>; Tue, 25 Apr 2006 09:14:09 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-65-179.midband.mdip.bt.net ([81.144.65.179]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444e4acf.13f77.108 for [e-mail]; Tue, 25 Apr 2006 17:14:07 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3PGCDd19842 for [e-mail]; Tue, 25 Apr 2006 17:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23272
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: End of issues
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 25 Apr 2006 14:18:45 GMT
Lines: 35
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>Charles Lindsey wrote:

>>But I would be quite happy for the agreed USEFOR draft to be put into a
>>"frozen" state, with all further change (certainly technical change)
>>forbidden except with the express authority of the Chair.
>>
>>It might even allow time for someone to write Dan's examples :-) .
>>  
>>
>Experience with the IETF Last Call and IESG review process shows that it 
>just about *always* catches some things that the WG on its own did not 
>think of.

But then again, it will also catch some things we forgot in USEPRO, and
more importantly some unsuspected interactions between the two.

>I think it would be good for the WG to have that part done with while we 
>still have this document in our active memory.

>I'll make that a separate question when we send out the WG Last Call.

Fair enough.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3PC8Dgt006644; Tue, 25 Apr 2006 05:08:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3PC8D28006643; Tue, 25 Apr 2006 05:08:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from phobos.pfm-mainz.de (phobos.pfm-mainz.de [145.253.109.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3PC8B5b006635 for <[e-mail]>; Tue, 25 Apr 2006 05:08:12 -0700 (MST) (envelope-from [e-mail])
Received: from nemesis.pfm-mainz.de (localhost [127.0.0.1]) by phobos.pfm-mainz.de (Postfix) with ESMTP id C963610DDBF for <[e-mail]>; Tue, 25 Apr 2006 14:08:04 +0200 (CEST)
Date: Tue, 25 Apr 2006 14:06:43 +0200
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
From: [e-mail] (Ralph Babel)
To: [e-mail]
Subject: Re: email vs. Email
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Dan Kohn wrote:

> Some use e-mail, but hyphens are regularly
> dropped as words become more familiar.

As in "tshirt"?

> By contrast, in Google, NetNews has a variety
> of capitalizations, including Netnews, and
> netnews. So, I would use email and Netnews.

Is this a poll?

[x] e-mail <URL:http://m-w.com/cgi-bin/dictionary?va=e-mail>
[x] netnews



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3P8R9HB096780; Tue, 25 Apr 2006 01:27:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3P8R9H2096779; Tue, 25 Apr 2006 01:27:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3P8R8OV096773 for <[e-mail]>; Tue, 25 Apr 2006 01:27:09 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4A3B2596EB; Tue, 25 Apr 2006 10:26:41 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21846-04; Tue, 25 Apr 2006 10:26:32 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F7CD2596E5; Tue, 25 Apr 2006 10:26:32 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 25 Apr 2006 10:26:58 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: Re: End of issues
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>
>  
>
>>I believe that I have now suggested resolutions for all four open issues 
>>listed on the April 11 issues list.
>>    
>>
>
>  
>
>>With that, I'd like to ask the editor to produce an -08 version that 
>>includes those resolutions, and make WG Last Call on that when it is ready.
>>    
>>
>
>I think I should make it clear that, although we need to review and draw a
>line under USEFOR, I would be totally opposed to submitting it to the IESG
>until there is a USEPRO ready to accompany it. There is just too great a
>risk that the USEPRO work will through up some gross incompatibility which
>will just _have_ to be fixed (not to mention that there are references to
>USEPRO from within USEFOR).
>
>But I would be quite happy for the agreed USEFOR draft to be put into a
>"frozen" state, with all further change (certainly technical change)
>forbidden except with the express authority of the Chair.
>
>It might even allow time for someone to write Dan's examples :-) .
>  
>
Experience with the IETF Last Call and IESG review process shows that it 
just about *always* catches some things that the WG on its own did not 
think of.

I think it would be good for the WG to have that part done with while we 
still have this document in our active memory.

I'll make that a separate question when we send out the WG Last Call.

                         Harald



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3P6A9pG091976; Mon, 24 Apr 2006 23:10:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3P6A9WO091975; Mon, 24 Apr 2006 23:10:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3P6A8BZ091968 for <[e-mail]>; Mon, 24 Apr 2006 23:10:08 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 46A94D4C6ED for <[e-mail]>; Tue, 25 Apr 2006 02:10:05 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Tue, 25 Apr 2006 02:09:22 -0400
X-Sasl-enc: OCGVisvoJEpLtREtOaelMxc8M+c9xOmt1oFH7jvyxs9R 1145945362
Received: from [10.0.1.2] (c-69-181-82-41.hsd1.ca.comcast.net [69.181.82.41]) by frontend3.messagingengine.com (Postfix) with ESMTP id 18DAF201C for <[e-mail]>; Tue, 25 Apr 2006 02:09:21 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v749.3)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dan Kohn <[e-mail]>
Subject: email vs. Email
Date: Mon, 24 Apr 2006 23:09:59 -0700
To: [e-mail]
X-Mailer: Apple Mail (2.749.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsay wrote:

>>>    The Message-ID header field contains a single unique message
>>>    identifier.  Netnews is more dependent on message identifier
>>>    uniqueness and fast comparison than Email is, and some news
>>> software
>
>> s/Email/email/
>
> No, we have consistently used "Netnews" when referring to the overall
> system that we are defining, and similarly we have always used  
> "Email as
> opposed to "email" in analogous situations.

I believe the pertinent issue is the standard usage, not what the  
drafts have done so far.  When I search email on Google, all of the  
top 20 results use lowercase email, and only capitalize in titles.   
(Some use e-mail, but hyphens are regularly dropped as words become  
more familiar.)  By contrast, in Google, NetNews has a variety of  
capitalizations, including Netnews, and netnews.  So, I would use  
email and Netnews.

            - dan
-- 
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com/>  <tel:[phone]>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OLLtY9071003; Mon, 24 Apr 2006 14:21:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3OLLtNK071002; Mon, 24 Apr 2006 14:21:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OLLs6L070996 for <[e-mail]>; Mon, 24 Apr 2006 14:21:54 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF9AF25970F; Mon, 24 Apr 2006 23:21:27 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00955-06; Mon, 24 Apr 2006 23:21:21 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 313E325970D; Mon, 24 Apr 2006 23:21:21 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 24 Apr 2006 23:21:46 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6-7.5.20060mdk (X11/20050322)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
Cc: Dan Kohn <[e-mail]>, [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Alexey Melnikov wrote:

> Harald Alvestrand wrote:
>
>>>>>>    The MIME header fields MIME-Version, Content-Type, Content- 
>>>>>> Transfer-
>>>>>>    Encoding, Content-Disposition, and Content-Language are used  
>>>>>> in news
>>>>>>    articles in the same circumstances and with the same meanings as
>>>>>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with  
>>>>>> the added
>>>>>>    restrictions detailed in Section 2.2.
>>>>>
>>>>>
>>>>> It's inconsistent that the ABNF for RFC 2822 headers has been  
>>>>> repeated throughout the spec (with the addition of : SP), but not  
>>>>> these headers.  My first choice would be to remove all ABNF from  
>>>>> the spec that only differ in showing the ": SP" (although they  
>>>>> might still be included in an appendix).  Alternatively, these  
>>>>> headers should be specified.
>>>>
>>>>
>>>> Are there other headers that differ only with the ": SP"? I'm not  
>>>> sure.
>>>> Other opinions?
>>>
>>>
>>> The following header ABNF differ from RFC 2822 only in their use of  
>>> ": SP".  I believe all of the following would best be moved to an  
>>> appendix:
>>>
>>>    from            =  "From:" SP mailbox-list CRLF
>>>    orig-date       =  "Date:" SP date-time CRLF
>>>    subject         =  "Subject:" SP unstructured CRLF
>>>    sender          =  "Sender:" SP mailbox CRLF
>>>    reply-to        =  "Reply-To:" SP address-list CRLF
>>>    comments        =  "Comments:" SP unstructured CRLF
>>>    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF
>>
>>
>> Thanks. I don't see that including this ABNF in this document 
>> contributes much at all - except that it gives the sections a 
>> consistent look. Other opinions?
>
>
> If I remember correctly Charles has suggested to have collected ABNF 
> in one place, so that people don't have to track 4 different documents 
> for different ABNF pieces.
> If I am to choose between ABNF only or existing sections describing 
> 2822 header fields, I choose ABNF. But I am fine with leaving existing 
> sections as is and add ABNF in an appendix.

A collected ABNF of what? All constructs defined in USEFOR, or all 
constructs from USEFOR and its supporting documents?

I think it would be presumptuous and error-prone to include all of 
2822's grammar in an USEFOR appendix - a collected ABNF for the USEFOR 
constructs might be a Good Thing; I think the ABNF is stable now. Ken, 
do you feel like writing one?

But this doesn't address the basic question on whether the lines Dan 
listed above should continue to be listed in their various sections, 
whether they should be in the collected ABNF, whether they should be 
dropped altogether, or whether more ABNF for other fields mentioned 
(such as the MIME headers) should be added.

I can't bring myself to care much one way or the other; their inclusion 
or non-inclusion doesn't change the protocol that the document 
specifies. Leave them the way they are?

                       Harald






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OL6WlH070487; Mon, 24 Apr 2006 14:06:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3OL6W5E070486; Mon, 24 Apr 2006 14:06:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OL6UCX070479 for <[e-mail]>; Mon, 24 Apr 2006 14:06:31 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E6D0C25970F; Mon, 24 Apr 2006 23:06:03 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00690-06; Mon, 24 Apr 2006 23:06:00 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66E3B25970D; Mon, 24 Apr 2006 23:06:00 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 24 Apr 2006 23:06:25 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6-7.5.20060mdk (X11/20050322)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
Cc: Dan Kohn <[e-mail]>, [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Alexey Melnikov wrote:

> Harald Alvestrand wrote:
>
>>>>    Most of these headers are mainly of interest to news servers, and
>>>>    news servers often need to process these fields very rapidly.
>>>
>>>
>>> I would remove this whole sentence, or at least the second half, as 
>>> it's superfluous to the specification.
>>
>>
>> It's been used as an argument for why (for instance) comments should 
>> not be permitted in this field. So I'd keep it.
>
>
> Unfortunately the quoted sentence doesn't explain why it is in the 
> document. I suggest addition of "Thus some headers prohibit comments." 
> or similar.
>
That makes sense.
Even more specific:

  Most of these headers are mainly of interest to news servers, and news 
servers often need to
  process these fields very rapidly. Thus the syntax of these headers is 
rather rigid; for instance
  they do not allow comments.

OK?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OIbsH5063843; Mon, 24 Apr 2006 11:37:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3OIbs6Y063842; Mon, 24 Apr 2006 11:37:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OIbrD1063836 for <[e-mail]>; Mon, 24 Apr 2006 11:37:53 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 24 Apr 2006 19:37:47 +0100
Message-ID: <[e-mail]>
Date: Mon, 24 Apr 2006 19:37:32 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Harald Alvestrand <[e-mail]>
CC: Dan Kohn <[e-mail]>, [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Alvestrand wrote:

>>>>>    The MIME header fields MIME-Version, Content-Type, Content- 
>>>>> Transfer-
>>>>>    Encoding, Content-Disposition, and Content-Language are used  
>>>>> in news
>>>>>    articles in the same circumstances and with the same meanings as
>>>>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with  
>>>>> the added
>>>>>    restrictions detailed in Section 2.2.
>>>>
>>>> It's inconsistent that the ABNF for RFC 2822 headers has been  
>>>> repeated throughout the spec (with the addition of : SP), but not  
>>>> these headers.  My first choice would be to remove all ABNF from  
>>>> the spec that only differ in showing the ": SP" (although they  
>>>> might still be included in an appendix).  Alternatively, these  
>>>> headers should be specified.
>>>
>>> Are there other headers that differ only with the ": SP"? I'm not  
>>> sure.
>>> Other opinions?
>>
>> The following header ABNF differ from RFC 2822 only in their use of  
>> ": SP".  I believe all of the following would best be moved to an  
>> appendix:
>>
>>    from            =  "From:" SP mailbox-list CRLF
>>    orig-date       =  "Date:" SP date-time CRLF
>>    subject         =  "Subject:" SP unstructured CRLF
>>    sender          =  "Sender:" SP mailbox CRLF
>>    reply-to        =  "Reply-To:" SP address-list CRLF
>>    comments        =  "Comments:" SP unstructured CRLF
>>    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF
>
> Thanks. I don't see that including this ABNF in this document 
> contributes much at all - except that it gives the sections a 
> consistent look. Other opinions?

If I remember correctly Charles has suggested to have collected ABNF in 
one place, so that people don't have to track 4 different documents for 
different ABNF pieces.
If I am to choose between ABNF only or existing sections describing 2822 
header fields, I choose ABNF. But I am fine with leaving existing 
sections as is and add ABNF in an appendix.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OHuK5g061590; Mon, 24 Apr 2006 10:56:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3OHuK6U061589; Mon, 24 Apr 2006 10:56:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3OHuJwF061582 for <[e-mail]>; Mon, 24 Apr 2006 10:56:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 24 Apr 2006 18:56:11 +0100
Message-ID: <[e-mail]>
Date: Mon, 24 Apr 2006 18:55:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Harald Alvestrand <[e-mail]>
CC: Dan Kohn <[e-mail]>, [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Alvestrand wrote:

>>>    Most of these headers are mainly of interest to news servers, and
>>>    news servers often need to process these fields very rapidly.
>>
>> I would remove this whole sentence, or at least the second half, as 
>> it's superfluous to the specification.
>
> It's been used as an argument for why (for instance) comments should 
> not be permitted in this field. So I'd keep it.

Unfortunately the quoted sentence doesn't explain why it is in the 
document. I suggest addition of "Thus some headers prohibit comments." 
or similar.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3LI35In009250; Fri, 21 Apr 2006 11:03:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3LI35F2009249; Fri, 21 Apr 2006 11:03:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from th-mail-b0116.gradwell.net (th-mail-b0116.gradwell.net [193.111.201.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3LI33xq009242 for <[e-mail]>; Fri, 21 Apr 2006 11:03:04 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-65-230.midband.mdip.bt.net ([81.144.65.230]) by th-mail-b0116.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44491e55.815.34c for [e-mail]; Fri, 21 Apr 2006 19:03:01 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3LHxrX06122; Fri, 21 Apr 2006 18:59:53 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23264
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Forward-looking statements (Re: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 21 Apr 2006 13:25:52 GMT
Lines: 29
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>The word "future" occurs four times in usefor-07:

>- justification for reserving _ in newsgroup name components
>- note that Approved can't be verified, but a future version may add 
>digital signatures
>- note that the Lines: field may be removed in a future version
>- A wish that PGPVERIFY will be standardized "in the near future"

Yes, it is agreed that the present PGPVERIFY has some technical problems,
and our charter explicitly mentions it as a thing needing attention. In
fact, we did some work on replacing it a few years back, but then decided
that it was a step too far for our present drafts, so we decided to leave
it for a future 'security' extension. There are several other security
issues which need to be looked at, so I still believe we need to work on
that security extension, but not until our present drafts are well out of
the way.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3KGDbFI041761; Thu, 20 Apr 2006 09:13:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3KGDbou041760; Thu, 20 Apr 2006 09:13:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3KGDaEq041752 for <[e-mail]>; Thu, 20 Apr 2006 09:13:37 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-221.midband.mdip.bt.net ([81.144.67.221]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 4447b32e.7309.15b for [e-mail]; Thu, 20 Apr 2006 17:13:34 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3KGC2j16579 for [e-mail]; Thu, 20 Apr 2006 17:12:03 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23262
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Non-substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 20 Apr 2006 12:05:27 GMT
Lines: 35
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bill McQuillan <[e-mail]> writes:

>On Tue, 2006-04-18, Charles Lindsey wrote:

>>>>    o  it ensures that no string of characters is quoted if it was
>>>>       already a <dot-atom-text> (it MUST start or end with a ".", or
>>>>       contain at least one <mqspecial>),

>>>s/was/were/   [subjunctive tense]

>I fail to see where the subjunctive fits here! There is no fictious
>existence. The sentence should probably be in the present tense, however:

>   o  it insures that no string of characters is quoted if it is
>      already a <dot-atom-text> ...

It may or may not be the case that the string is "already a
<dot-atom-text>". Hence the subjunctive is pedantically correct because
the "ensuring" only takes place in one of those cases.

I agreee with the present tense change (s/was/is/) and would agree that a
subjunctive present tense ("be") would be an overkill. However, your
s/ensure/insure/ is totally wrong (there are no insurance companies
involved in this :-) ).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3K5sx12015426; Wed, 19 Apr 2006 22:54:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3K5sxo5015425; Wed, 19 Apr 2006 22:54:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3K5swDx015417 for <[e-mail]>; Wed, 19 Apr 2006 22:54:58 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 544912596E0; Thu, 20 Apr 2006 07:54:35 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06084-09; Thu, 20 Apr 2006 07:54:31 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A1342596DC; Thu, 20 Apr 2006 07:54:31 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 20 Apr 2006 07:54:53 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: Forward-looking statements (Re: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>
>   
>>
>> I will not countenance forward-looking statements in this document 
>> unless there's clear WG consensus for them.
>>     
>
> A sentence to that effect has been in all our previous 'article' drafts,
> and thereafter in all our USEPRO drafts.
>
> This issue (#1178) started with a suggestion to more that sentence from
> USEPRO into USEFOR (since it was clealy a USEFOR matter). However,
> subsequent discussion seems to have concentrated on other related wording
> and that particular part of the proposal was never really commented upon -
> one way or the other. Sure, if the WG does not want to say that, then it
> need not be said, but the WG does not seem to, have expressed an opinion
> thus far.
>
>   
Anyone else want to defend notes claiming future relaxations?

The word "future" occurs four times in usefor-07:

- justification for reserving _ in newsgroup name components
- note that Approved can't be verified, but a future version may add 
digital signatures
- note that the Lines: field may be removed in a future version
- A wish that PGPVERIFY will be standardized "in the near future"

I don't see a reason to add a fifth one; the 8 occurences in usepro will 
no doubt  be critically examined when the WG's attention turns fully to 
that document.

                      Harald



                             Harald



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3JGJa4l081937; Wed, 19 Apr 2006 09:19:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3JGJaTe081936; Wed, 19 Apr 2006 09:19:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3JGJY3J081930 for <[e-mail]>; Wed, 19 Apr 2006 09:19:36 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-64-235.midband.mdip.bt.net ([81.144.64.235]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444661b5.3b17.3c02 for [e-mail]; Wed, 19 Apr 2006 17:13:41 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3JGC2f12333 for [e-mail]; Wed, 19 Apr 2006 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23259
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 19 Apr 2006 14:07:41 GMT
Lines: 63
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>Charles Lindsey wrote:
>> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>>
>>   
>>> The note is from section 3.2 of USEPRO, "Transitional arrangements":
>>>     
>>
>>   
>>> * Because of its importance to all serving agents, the whitespace and 
>>> folding in Newsgroups header fields newly permitted by [USEFOR] SHOULD 
>>> NOT be generated (though it MUST be accepted); this restriction may well 
>>> be removed in a future version of this standard.
>>>     
>>
>>   
>>> I suggest the following resolution for USEFOR:
>>>     
>>
>>   
>>> In section 3.1.5:
>>>     
>>
>>   
>>> Not all servers support <FWS> in the list of newsgroups. In particular, 
>>> folding the Newsgroups header field over several lines has been shown to 
>>> harm propagation significantly. <FWS> in the <newsgroup-list> SHOULD NOT 
>>> be generated, but MUST be accepted.
>>>     
>>
>> s/has been shown to/will currently/
>>
>> I would still like a sentence to the efffect that some future standard may
>> lift the restriction (just to encourage implementors to take the MUST
>> accept seriously). Lack of folding of newsgroups is currently a
>> confounded nuisance, which is why insisting on its being accepted was one
>> of the first decisions taken by this WG.
>>   
>I will not countenance forward-looking statements in this document 
>unless there's clear WG consensus for them.

A sentence to that effect has been in all our previous 'article' drafts,
and thereafter in all our USEPRO drafts.

This issue (#1178) started with a suggestion to more that sentence from
USEPRO into USEFOR (since it was clealy a USEFOR matter). However,
subsequent discussion seems to have concentrated on other related wording
and that particular part of the proposal was never really commented upon -
one way or the other. Sure, if the WG does not want to say that, then it
need not be said, but the WG does not seem to, have expressed an opinion
thus far.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3JAUr1s064093; Wed, 19 Apr 2006 03:30:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3JAUrQM064092; Wed, 19 Apr 2006 03:30:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3JAUpib064086 for <[e-mail]>; Wed, 19 Apr 2006 03:30:52 -0700 (MST) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1FW9xM-000EuP-Cv for [e-mail]; Wed, 19 Apr 2006 10:30:48 +0000
Message-ID: <[e-mail]>
Date: Wed, 19 Apr 2006 11:29:36 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <HD6$+bqr77PuEOKLDOQ+dOA5KI>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes

>I would still like a sentence to the efffect that some future standard may
>lift the restriction (just to encourage implementors to take the MUST
>accept seriously). Lack of folding of newsgroups is currently a
>confounded nuisance, 

It's the main thing -- at the edges -- preventing idiots from posting to
500 newsgroups at once...

... "cleanfeed" style restrictions on cross-posting do of course exist
but are far from universally applied.

So I'm happy to leave it without the indication that a future standard
might change things, because (a) I don't think it will and (b) it's true
anyway, and it would be a really dumb implementer who failed to realise
that's what the MUST was intended to mean.

>which is why insisting on its being accepted was one
>of the first decisions taken by this WG.

I shall be constructive, and not comment on that last bit :)

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBREYREJoAxkTY1oPiEQL+aQCgx7Mup+EhUUP0XYvo7nnTaZz82K8AoLtB
Fq6FP/RUUVVN+bbVGl6y89rG
=0/V1
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3J8UKOs057237; Wed, 19 Apr 2006 01:30:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3J8UKFY057236; Wed, 19 Apr 2006 01:30:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from proof.pobox.com ([e-mail] [207.106.133.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3J8UJnV057230 for <[e-mail]>; Wed, 19 Apr 2006 01:30:19 -0700 (MST) (envelope-from [e-mail])
Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id B550AF2998; Wed, 19 Apr 2006 04:30:18 -0400 (EDT)
Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 5491B3D66F; Wed, 19 Apr 2006 04:30:17 -0400 (EDT)
Date: Wed, 19 Apr 2006 01:30:16 -0700
From: Bill McQuillan <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Usenet <[e-mail]>
Subject: Re: Non-substantive edits to draft-ietf-usefor-usefor-07
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue, 2006-04-18, Charles Lindsey wrote:

>>>    o  it ensures that no string of characters is quoted if it was
>>>       already a <dot-atom-text> (it MUST start or end with a ".", or
>>>       contain at least one <mqspecial>),

>>s/was/were/   [subjunctive tense]

> Yes, I like correct use of the subjunctive (though I refrained from
> criticising a recent text from Harald on those gounds - perhaps I shall
> remember later exactly where it was :-) ).

I fail to see where the subjunctive fits here! There is no fictious
existence. The sentence should probably be in the present tense, however:

   o  it insures that no string of characters is quoted if it is
      already a <dot-atom-text> ...


-- 
Bill McQuillan <[e-mail]>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3J19FQi038320; Tue, 18 Apr 2006 18:09:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3J19Fae038319; Tue, 18 Apr 2006 18:09:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3J19Egc038313 for <[e-mail]>; Tue, 18 Apr 2006 18:09:14 -0700 (MST) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k3J19D1W019158 for <[e-mail]>; Tue, 18 Apr 2006 18:09:13 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 09818E7958; Tue, 18 Apr 2006 18:09:13 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
In-Reply-To: <[e-mail]> (Seth Breidbart's message of "Tue, 18 Apr 2006 15:25:52 -0400 (EDT)")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 18 Apr 2006 18:09:13 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Seth Breidbart <[e-mail]> writes:
> Russ Allbery <[e-mail]> wrote:

>> I think you have that almost exactly backwards.  An article may have
>> different newsgroup-specific identifiers in different newsgroups but
>> may not have more than one in a particular newsgroup.  (Read "article
>> number" for "newsgroup-specific identifier" if this isn't clear.)

> That's what I missed: that the "newsgroup-specific identifier" wasn't
> actually part of the article.

In most current implementations, it is in the article as delivered to a
client.  It's in the Xref header, as a list of pairs of newsgroups and
identifiers in that newsgroup.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3J0RLA7036129; Tue, 18 Apr 2006 17:27:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3J0RLhe036128; Tue, 18 Apr 2006 17:27:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.peak.org (a.shell.peak.org [69.59.192.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3J0RKwu036122 for <[e-mail]>; Tue, 18 Apr 2006 17:27:21 -0700 (MST) (envelope-from [e-mail])
Received: from shell.peak.org (a.shell.peak.org [127.0.0.1]) by shell.peak.org (8.13.1/8.13.1) with ESMTP id k3J0MULJ023865 for <[e-mail]>; Tue, 18 Apr 2006 17:22:30 -0700
Received: from localhost (stanley@localhost) by shell.peak.org (8.13.1/8.13.1/Submit) with ESMTP id k3J0MTUX023862 for <[e-mail]>; Tue, 18 Apr 2006 17:22:30 -0700
X-Authentication-Warning: shell.peak.org: stanley owned process doing -bs
Date: Tue, 18 Apr 2006 17:22:29 -0700 (PDT)
From: John Stanley <[e-mail]>
To: [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Seth Breidbart <sethb@xxxxxxxxx>:

>That's what I missed: that the "newsgroup-specific identifier" wasn't
>actually part of the article.

In the articles I read, the article number appears in the Xref header
field, and must do so to enable crosspost-thread-killing.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKu1K0025644; Tue, 18 Apr 2006 13:56:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKu1G6025643; Tue, 18 Apr 2006 13:56:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKu0Dw025628 for <[e-mail]>; Tue, 18 Apr 2006 13:56:01 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CDBA2596FF; Tue, 18 Apr 2006 22:55:38 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12107-10; Tue, 18 Apr 2006 22:55:34 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id B59662596FE; Tue, 18 Apr 2006 22:55:34 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 18 Apr 2006 22:55:57 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: Re: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>
>   
>> The note is from section 3.2 of USEPRO, "Transitional arrangements":
>>     
>
>   
>> * Because of its importance to all serving agents, the whitespace and 
>> folding in Newsgroups header fields newly permitted by [USEFOR] SHOULD 
>> NOT be generated (though it MUST be accepted); this restriction may well 
>> be removed in a future version of this standard.
>>     
>
>   
>> I suggest the following resolution for USEFOR:
>>     
>
>   
>> In section 3.1.5:
>>     
>
>   
>> Not all servers support <FWS> in the list of newsgroups. In particular, 
>> folding the Newsgroups header field over several lines has been shown to 
>> harm propagation significantly. <FWS> in the <newsgroup-list> SHOULD NOT 
>> be generated, but MUST be accepted.
>>     
>
> s/has been shown to/will currently/
>
> I would still like a sentence to the efffect that some future standard may
> lift the restriction (just to encourage implementors to take the MUST
> accept seriously). Lack of folding of newsgroups is currently a
> confounded nuisance, which is why insisting on its being accepted was one
> of the first decisions taken by this WG.
>   
I will not countenance forward-looking statements in this document 
unless there's clear WG consensus for them.

The MOST probable outcome of this effort is IMHO that this is the last 
Netnews standard ever issued - because the decline in the importance of 
Netnews is rapid enough that nobody will care what the standard says in 
another few years.

If I'm wrong, and Netnews continues to be important, the standard can be 
reissued. But don't make promises we're unlikely to keep.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKit43025087; Tue, 18 Apr 2006 13:44:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKitWY025086; Tue, 18 Apr 2006 13:44:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKirik025080 for <[e-mail]>; Tue, 18 Apr 2006 13:44:54 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-245.midband.mdip.bt.net ([81.144.67.245]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44454fc3.3afc.34a4 for [e-mail]; Tue, 18 Apr 2006 21:44:51 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3IKhTP01000 for [e-mail]; Tue, 18 Apr 2006 21:43:29 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23251
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 18 Apr 2006 20:29:42 GMT
Lines: 236
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Dan Kohn <[e-mail]> writes:

>Here are some slightly more substantive proposed changes.  Any of  
>these that are controversial may require a ticket.

Again, many of these are improvements, but some of them go too far.


>>    A "newsgroup" is a single news forum, a logical bulletin board,
>>    having a name and nominally intended for articles on a specific
>>    topic.  An article is "posted to" a single newsgroup or several
>>    newsgroups.  When an article is posted to more than one  
>> newsgroup, it
>>    is said to be "crossposted"; note that this differs from posting  
>> the
>>    same text as part of each of several articles, one per newsgroup.

>["logical bulletin board" doesn't mean anything, and so is not a  
>clarifying phrase.  Nominally is not the right word here, as it means  
>"In a nominal manner; by name; in name only; not in reality."   
>Newsgroups are intended to be on a topic in more than name only.   
>Here's a word-smithed version:]

>    A "newsgroup" is a single forum having a name and intended for  
>articles on a specific
>    topic.  An article is "posted" to a single newsgroup or  
>"crossposted" to several
>    newsgroups.  Crossposting uses a single article; it is different  
>from posting the
>    same text in different articles to different newsgroups.

s/uses a single article/creates a single article/

(I think I am disagreeing with John and agreeing with Seth).

>>    This document, and specifications that build upon it, specifies how
>>    to handle conformant articles.  Handling of non-conformant articles
>>    is outside the scope of this specification.
>>
>>    Agents conforming to this specification MUST generate only  
>> conformant
>>    articles.

>[I would remove these three sentences, as their meaning is implicit,  
>and yet goes unstated, in every IETF standard.  "handling of non- 
>conformant articles" must by definition be outside the scope of a  
>document that only specifies what a conformant article is.]

A lot of discussion went into those sentences. Safer to leave them as they
are.

>>    The text below uses ABNF to specify restrictions on the syntax
>>    specified in [RFC2822]; this grammar is intended to be more
>>    restrictive than the [RFC2822] grammar.  Articles must conform  
>> to the
>>    ABNF specified in [RFC2822].
>>
>>    Articles must also conform to the restrictions specified here, both
>>    those that are expressed as text and those that are expressed as
>>    ABNF.

>[I believe these two paragraphs should be deleted, as they are  
>confusing and don't add any new information.  Specifically, they seem  
>redundant to the opening sentence of this section:  "An article is  
>said to be conformant to this specification if it conforms to the  
>format specified in [RFC2822] Section 3 and to the additional  
>requirements of this specification."]

Ditto.


>>    o  Compliant software MUST NOT generate (but MAY accept) header
>>       fields of more than 998 octets.  This is the only limit on the
>>       length of a header field prescribed by this standard.  However,
>>       specific rules to the contrary may apply in particular cases  
>> (for
>>       example, according to [RFC2047] lines of a header field  
>> containing
>>       encoded-words are limited to 76 octets).  [I-D.ietf-usefor- 
>> useage]
>>       includes suggested limits for convenience of display by user
>>       agents.


Aaaarrrggggghhhhh! Bug or feature?

That was always meant to say "MUST NOT generate (but MAY accept) header
field lines...". I don't know how that wording crept it. So Dan's
suggested changes are certainly in order (though possibly not needed).

>[ I think this paragraph should be removed.

>The first sentence is redundant with RFC2822, Section 2.1.1, which  
>specified line lengths at 998 but says that implementations "would do  
>well to handle an arbitrarily large number of characters".   The  
>second sentence seems to override the "SHOULD be no more than 78  
>characters", however that's contradictory with the opening paragraph  
>of this section about this standard being "less permissive".  The  
>last two sentences are only necessary because the paragraph is sort  
>of departing from RFC 2822, but not really.

>If the purpose is just to remove the 78 character line limit, I would  
>say:]

Yes, the intention was most definitely to remove any mention of the 78
character limit (and removing it is still consistent with RFC 2822). In
Email, various intermediate agents use this limit as an excuse to refold
headers and even body lines en route. This is most definitely verboten in
Netnews. USEAGE discusses what are sensible practical limits on line
lengths.

>    Section 2.1.1 of [RFC2822] says:

>       "Each line of characters MUST be no more than 998 characters,
>       and SHOULD be no more than 78 characters, excluding the CRLF."

>    For news articles, this restriction is loosened as follows:

>       "Each line of characters MUST be no more than 998 characters,
>       and MAY be line wrapped at 78 characters, excluding the CRLF."

We certainly don't want that "MAY" line in there. The line MAY be wrapped
anyway the poster likes (subject to 998). USEAGE is the place to give more
precise advice.

My inclination would be to leave the paragraph as it is, after fixing the
"header field [lines]" bug.


>>          NOTE: There is NO restriction on the number of lines into  
>> which
>>          a header field may be split, and hence there is NO  
>> restriction
>>          on the total length of a header field (in particular it  
>> may, by
>>          suitable folding, be made to exceed the 998 octets  
>> restriction
>>          pertaining to a single header line).

>This note should also be removed, as it's implicit in the RFC 2822  
>definition of header folding.

Yes, that NOTE (which has been in our drafts for ages) confirms that is
was a bug rather than a feature. I would prefer to see those words left.

>>    o  The character set for header fields is US-ASCII.  Where the  
>> use of
>>       non-ASCII characters is required, they MUST be encoded using the
>>       MIME mechanisms defined in [RFC2047] and [RFC2231].

>This paragraph does not belong here, as these rules are the same as  
>RFC 2822 et al, rather than being an exception to them.  Further, it  
>is redundant with the subsequent section, and so can either be  
>deleted, or added there for emphasis.  (I would recommend deletion.)

It was there for emphasis. By all means move it.


>>    Most of these headers are mainly of interest to news servers, and
>>    news servers often need to process these fields very rapidly.

>I would remove this whole sentence, or at least the second half, as  
>it's superfluous to the specification.

It gives the reason why we have made some restrictions. Leave it.

>>    The MIME header fields MIME-Version, Content-Type, Content- 
>> Transfer-
>>    Encoding, Content-Disposition, and Content-Language are used in  
>> news
>>    articles in the same circumstances and with the same meanings as
>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with the  
>> added
>>    restrictions detailed in Section 2.2.

>It's inconsistent that the ABNF for RFC 2822 headers has been  
>repeated throughout the spec (with the addition of : SP), but not  
>these headers.  My first choice would be to remove all ABNF from the  
>spec that only differ in showing the ": SP" (although they might  
>still be included in an appendix).  Alternatively, these headers  
>should be specified.

I agree our treatment is inconsistent, but where do we stop? There are
lots of standards which have introduced extension headers to Email, and
some of them may be appropriate for news. They all need to have the SP
there if they appear. So, inconsistent as it is, I think Ken got it about
right.

>>       NOTE: The <date-time> in this header field would normally be
>>       expected to be later than the <date-time> in the Date header
>>       field, but differences between the clocks on the various agents
>>       and other special circumstances might vitiate that; no provision
>>       is made for any such discrepancy to be corrected - better  
>> that the
>>       news server should just insert the correct time as it sees it.

>[Rewritten:]

>NOTE:  Since clocks on various agents may not be in sync, the <date- 
>time> in this header field may not be later than the Date header  
>field, as would be expected.  Agents SHOULD use the <date-time> they  
>believe is correct when adding Inject-Info but SHOULD NOT alter the  
>pre-existing Date field.

I think I prefer the original, but no big deal.

>>    The syntax is the same as that of the Newsgroups header field
>>    (Section 3.1.5, with the exception that the keyword "poster" (which
>>    is always lowercase) requests that followups should be mailed to  
>> the
>>    article's reply address rather than posted.  Although the keyword
>>    "poster" is case-sensitive, user agents MAY choose to recognize  
>> case-
>>    insensitive forms such as "Poster".

>[This is wordy with mismatched parentheses.  How about:]

>    The syntax is the same as that of the Newsgroups header field
>    (Section 3.1.5), with the exception that the keyword "poster"
>    requests that followups should be mailed to the article's reply
>    address rather than posted.  Agents MUST generate the
>    keyword "poster" in lower-case, but MAY choose to recognize
>    case-insensitive forms such as "Poster".

That seems just as "wordy"

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKiruP025078; Tue, 18 Apr 2006 13:44:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKirvG025077; Tue, 18 Apr 2006 13:44:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKipjI025069 for <[e-mail]>; Tue, 18 Apr 2006 13:44:52 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-245.midband.mdip.bt.net ([81.144.67.245]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44454fc2.3afc.34a3 for [e-mail]; Tue, 18 Apr 2006 21:44:50 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3IKhTN00995 for [e-mail]; Tue, 18 Apr 2006 21:43:29 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23250
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Non-substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 18 Apr 2006 17:22:27 GMT
Lines: 151
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Dan Kohn <[e-mail]> writes:

>Here are some suggested edits to the usefor draft.

These are mostly fine, but still a few niggles.


>[Netnews was defined in the previous paragraph but network news was  
>not.]

>>    This specification is intended as a definition of what article
>>    content format is to be passed between systems.  Though some news
>>    systems locally store articles in this format (which eliminates the
>>    need for translation between formats) and others use formats that
>>    differ from the one specified in this standard, local storage is
>>    outside of the scope of this standard.

>s/Though/Although/.
>Delete " and others use formats that differ from the one specified in  
>this standard" as the phrase is redundant to the previous clause (if  
>some systems do x, others must not).

If you want to simplify that sentence, then you should say:

"News systems may or may not store articles in this format, but local
storage is ..."


>>    An "article" is the unit of news, synonymous with an [RFC2822]

>s/news/Netnews/.
>s/synonymous/analogous/.  [This is a real error, as news articles and  
>RFC 2822 messages are "Similar or alike in such a way as to permit  
>the drawing of an analogy" not "Having the same or a similar meaning".]

Yes, I agree that "analogous" is better.


>>    A "poster" is the person or software that composes and submits a
>>    possibly compliant article to a "user agent".  The poster is
>>    analogous to [RFC2822]'s author.

>s/a possibly compliant article/an article or proto-article/

>[A non-compliant article is not a Netnews article according to this  
>RFC, so it's not worth explicitly specifying the possibility.]

Actually no. Posters (humans) may attempt to create all sorts of
non-standard articles. It is the job of the user agent to catch them.
Actually, those "possibly compliant" words have been present since our
very earliest drafts (maybe even s-o-1036, though I haven't checked).
T'would be a pity to lose them.


>>    unstructured    =  *WSP utext *( [FWS] utext ) *WSP
>>
>>          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.

>s/but/and/

No, I think "but" expresses it better.


>>
>>    The Message-ID header field contains a single unique message
>>    identifier.  Netnews is more dependent on message identifier
>>    uniqueness and fast comparison than Email is, and some news  
>> software

>s/Email/email/

No, we have consistently used "Netnews" when referring to the overall
system that we are defining, and similarly we have always used "Email as
opposed to "email" in analogous situations.


>>    o  it ensures that no string of characters is quoted if it was
>>       already a <dot-atom-text> (it MUST start or end with a ".", or
>>       contain at least one <mqspecial>),

>s/was/were/   [subjunctive tense]

Yes, I like correct use of the subjunctive (though I refrained from
criticising a recent text from Harald on those gounds - perhaps I shall
remember later exactly where it was :-) ).



>>    The Injection-Date header field contains the date and time that the
>>    article was injected into the network.  Its purpose is to  
>> prevent the
>>    reinjection into the news stream of "stale" articles which have
>>    already expired by the time they arrive at some news server.

>s/reinjection/re-injection/
>s/which/that/

Note that we have consistently used the term "reinjection" in USEPRO to
describe a possible technical happening in certain unusual circumstances.
Admittedly, the use here is not one of those circumstances, but
consistency of spelling is still a good thing.



>>       NOTE: The syntax of <parameter> ([RFC2045] as amended by
>>       [RFC2231]), taken in conjunction with the folding rules of
>>       [RFC0822], effectively allows [CFWS] to occur on either side of
>>       the "=" inside a <parameter>.

>s/[RFC2045] as amended/[RFC2045] Section 5.1 as amended/
>s/[RFC0822]/[RFC2822]/

NO! It must be RFC 822 as already discussed. I would prefer it as
[RFC822], although I understand why Ken used 0822 to ensure proper sorting
in the References section. It is still a nasty kludge :-( .


>[The next 4 paragraphs should be indented so as to be included in the  
>same Note.]

Arrrrghhhhh! No! Those paragraphs are describing the semantics of those
various <parameter>s. Semantics don't go in NOTEs.

>>    The "posting-account" <parameter>> identifies the source from which

..........


>>    Early versions of news software following the modern format  
>> sometimes
>>    generated header fields like the following:

>Obsolete Netnews software sometimes generated header fields such as:
 ^^^^^^^^
 Earlier

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKipTB025068; Tue, 18 Apr 2006 13:44:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKipme025067; Tue, 18 Apr 2006 13:44:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKioPE025053 for <[e-mail]>; Tue, 18 Apr 2006 13:44:50 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-245.midband.mdip.bt.net ([81.144.67.245]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44454fc1.3afc.34a2 for [e-mail]; Tue, 18 Apr 2006 21:44:49 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3IKhS000978 for [e-mail]; Tue, 18 Apr 2006 21:43:28 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23247
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path header - proposed resolution
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 18 Apr 2006 16:47:01 GMT
Lines: 71
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>Charles Lindsey wrote:
>> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>>   
>>> path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
>>>     
>>                                          ^^^^^^^^^^^^^^
>>
>> I really dislike that. ...
>>   
>And I like that - these things have to be legal for acceptance, and they 
>even have to be legal for generation by new systems (those that replace 
>old systems which use those names). I think "legacy" is just about 
>exactly right - the discussion is over, all that's left is the codification.

I think you misunderstand my point. Your view is based on two premises:

1. They have to be legal for acceptance because they currently occur.

2. They have to be legal for new systems which replace old system which
need to continue to use existing names.

But you omit the third premise:

3. They have to be legal for new systems which may introduce new names
(but only where there is good reason).

My whole point is that I do not want to forbid case #3. Yes, new names are
only to be introduced by those who know what they are doing and have good
reasons, and for that sort of situation "SHOULD NOT" language is
appropriate (and there is such language in USEPRO).

No, I have not got any such reasons in mind at the moment (except perhaps
for the specialized case of a private network using UUCP), but that is not
to say that such reason may not appear. USEPRO contains the necessary
warnings.

>>   
>>>      NOTE: One usage of a path-diagnostic is to record an IP address.
>>>     The fact that IPv6 addresses
                      ^^^^^^^^^^^^^^
                      <IPv6address>es
>>>     are allowed means that the colon (:) is permitted; 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.
>>>     
>> You have removed the NOTE explaining why the <diag-deprecated> has been
>> included.  In years to come, people are going to wonder what it is all
>> about. I think it needs some explanation (though the explanation could go
>> in USEPRO).
>>
>>   
>Send text, or leave it to USEPRO.

      NOTE: Although , <IPv4address>es 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>).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKioQD025060; Tue, 18 Apr 2006 13:44:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKio7D025059; Tue, 18 Apr 2006 13:44:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKinZL025042 for <[e-mail]>; Tue, 18 Apr 2006 13:44:49 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-245.midband.mdip.bt.net ([81.144.67.245]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44454fc0.3afc.34a1 for [e-mail]; Tue, 18 Apr 2006 21:44:48 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3IKhS300990 for [e-mail]; Tue, 18 Apr 2006 21:43:28 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23249
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1179 not closed? Re: Ticket status, March 24
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 18 Apr 2006 16:55:03 GMT
Lines: 38
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>I am not happy with Charles' text on this issue. Trying again, based on 
>the -07 NOTE:

>    NOTE: The [RFC2822] specification sometimes uses [FWS] at the 
>beginning or end of ABNF
>   describing a header field content. This specification uses *WSP in 
>such cases, also in cases where
>   this specification redefines constructs from [RFC2822]. 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.

>Charles' proposed text was:

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

>If anyone wishes to make further changes, or prefers Charles' version, 
>please speak up.

I am happy with either text.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKimpB025039; Tue, 18 Apr 2006 13:44:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKimib025038; Tue, 18 Apr 2006 13:44:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKild9025024 for <[e-mail]>; Tue, 18 Apr 2006 13:44:47 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-245.midband.mdip.bt.net ([81.144.67.245]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44454fbd.3afc.349e for [e-mail]; Tue, 18 Apr 2006 21:44:45 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3IKhU401005 for [e-mail]; Tue, 18 Apr 2006 21:43:30 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23252
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 18 Apr 2006 20:35:21 GMT
Lines: 25
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>> Finally, I think it would highly useful to add an Appendix A with 
>> example articles the way RFC 2822 does.  The ABNF for <path>, for 
>> example, is crying out for examples. 
>Or we could add a new document with examples, the way SIP does.... I'd 
>like to get this one out the door....

I agree that some examples would be nice (even if we just copy the rather
simple example that appeared in the old "article" drafts).

But it is fair to point out that USEPRO contains a thorough Path example
(which now needs reworking, of course), and it also contains examples of
control messages.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKimC4025041; Tue, 18 Apr 2006 13:44:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKimqA025040; Tue, 18 Apr 2006 13:44:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKil8G025025 for <[e-mail]>; Tue, 18 Apr 2006 13:44:47 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-245.midband.mdip.bt.net ([81.144.67.245]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44454fbe.3afc.349f for [e-mail]; Tue, 18 Apr 2006 21:44:46 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3IKhU801010 for [e-mail]; Tue, 18 Apr 2006 21:43:30 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23253
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: End of issues
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 18 Apr 2006 20:42:54 GMT
Lines: 31
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>I believe that I have now suggested resolutions for all four open issues 
>listed on the April 11 issues list.

>With that, I'd like to ask the editor to produce an -08 version that 
>includes those resolutions, and make WG Last Call on that when it is ready.

I think I should make it clear that, although we need to review and draw a
line under USEFOR, I would be totally opposed to submitting it to the IESG
until there is a USEPRO ready to accompany it. There is just too great a
risk that the USEPRO work will through up some gross incompatibility which
will just _have_ to be fixed (not to mention that there are references to
USEPRO from within USEFOR).

But I would be quite happy for the agreed USEFOR draft to be put into a
"frozen" state, with all further change (certainly technical change)
forbidden except with the express authority of the Chair.

It might even allow time for someone to write Dan's examples :-) .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKinig025051; Tue, 18 Apr 2006 13:44:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IKinKV025050; Tue, 18 Apr 2006 13:44:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IKimfW025027 for <[e-mail]>; Tue, 18 Apr 2006 13:44:48 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-245.midband.mdip.bt.net ([81.144.67.245]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44454fbf.3afc.34a0 for [e-mail]; Tue, 18 Apr 2006 21:44:47 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3IKhSo00983 for [e-mail]; Tue, 18 Apr 2006 21:43:28 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23248
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 18 Apr 2006 16:53:56 GMT
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>The note is from section 3.2 of USEPRO, "Transitional arrangements":

>* Because of its importance to all serving agents, the whitespace and 
>folding in Newsgroups header fields newly permitted by [USEFOR] SHOULD 
>NOT be generated (though it MUST be accepted); this restriction may well 
>be removed in a future version of this standard.

>I suggest the following resolution for USEFOR:

>In section 3.1.5:

>Not all servers support <FWS> in the list of newsgroups. In particular, 
>folding the Newsgroups header field over several lines has been shown to 
>harm propagation significantly. <FWS> in the <newsgroup-list> SHOULD NOT 
>be generated, but MUST be accepted.

s/has been shown to/will currently/

I would still like a sentence to the efffect that some future standard may
lift the restriction (just to encourage implementors to take the MUST
accept seriously). Lack of folding of newsgroups is currently a
confounded nuisance, which is why insisting on its being accepted was one
of the first decisions taken by this WG.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IJPsvt021102; Tue, 18 Apr 2006 12:25:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IJPsHK021101; Tue, 18 Apr 2006 12:25:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IJPraC021095 for <[e-mail]>; Tue, 18 Apr 2006 12:25:53 -0700 (MST) (envelope-from [e-mail])
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 73FFC13A8A4 for <[e-mail]>; Tue, 18 Apr 2006 15:25:52 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k3IJPqk10158; Tue, 18 Apr 2006 15:25:52 -0400 (EDT)
Date: Tue, 18 Apr 2006 15:25:52 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ Allbery on Mon, 17 Apr 2006 20:24:46 -0700)
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery <[e-mail]> wrote:
> Seth Breidbart <[e-mail]> writes:
>> John Stanley <[e-mail]> wrote (in suggested text):

>>> Each crossposted article contains the same message id, but may have
>>> different newsgroup-specific identifiers.

>> Huh?  Since there's only _one_ article, it contains _several_ newsgroups
>> in the appropriate header.  (Whatever a "newsgroup-specific identifier"
>> is, the article might have several, but can't have different ones for
>> different newsgroups.)
>
> I think you have that almost exactly backwards.  An article may have
> different newsgroup-specific identifiers in different newsgroups but may
> not have more than one in a particular newsgroup.  (Read "article number"
> for "newsgroup-specific identifier" if this isn't clear.)

That's what I missed: that the "newsgroup-specific identifier" wasn't
actually part of the article.

Thanks,

Seth



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IIxJ6A018370; Tue, 18 Apr 2006 11:59:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3IIxJNs018369; Tue, 18 Apr 2006 11:59:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.peak.org (a.shell.peak.org [69.59.192.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3IIxHar018362 for <[e-mail]>; Tue, 18 Apr 2006 11:59:18 -0700 (MST) (envelope-from [e-mail])
Received: from shell.peak.org (a.shell.peak.org [127.0.0.1]) by shell.peak.org (8.13.1/8.13.1) with ESMTP id k3IIsRh0015551 for <[e-mail]>; Tue, 18 Apr 2006 11:54:27 -0700
Received: from localhost (stanley@localhost) by shell.peak.org (8.13.1/8.13.1/Submit) with ESMTP id k3IIsRiO015548 for <[e-mail]>; Tue, 18 Apr 2006 11:54:27 -0700
X-Authentication-Warning: shell.peak.org: stanley owned process doing -bs
Date: Tue, 18 Apr 2006 11:54:27 -0700 (PDT)
From: John Stanley <[e-mail]>
To: [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

John Stanley <stanley@xxxxxxxx> wrote (in suggested text):

> Each crossposted article contains the same message id, but may
> have different newsgroup-specific identifiers.

Seth Breidbart <sethb@xxxxxxxxx>:

>Huh?  Since there's only _one_ article, it contains _several_
>newsgroups in the appropriate header.

I didn't say anything about the newsgroups header field. I said "different
newsgroup-specific identifiers."

>(Whatever a "newsgroup-specific
>identifier" is, the article might have several, but can't have
>different ones for different newsgroups.)

You are patently wrong. A crossposted message may have article number
12345 in newsgroup A and article number 54321 in newsgroup B. The article
number, being one of the means of retrieving articles from a newsgroup,
is the 'newsgroup-specific identifier' I was talking about. In fact, as
I recall, those newsreaders that mark crossposted articles as read do so
using article numbers and not message id.

Dan Kohn <dan@xxxxxxxxxxx>:

>I don't mean to be pedantic, but I thought the definition of a unique 
>article is that it has a unique message-ID.

One article will have an almost certainly different newsgroup-specific
identifier in each newsgroup in which it appears. Whilst we may call
that "one article because it has one message id", in many ways it acts
like multiple articles.

Russ Allbery <rra@xxxxxxxxxxxx>:

>(Read "article number"
>for "newsgroup-specific identifier" if this isn't clear.)

Exactly. I was hesitant to tie the term too closely to any specific
implementation so I did not say "article number".



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I6LLfd072368; Mon, 17 Apr 2006 23:21:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3I6LLst072367; Mon, 17 Apr 2006 23:21:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I6LKsc072360 for <[e-mail]>; Mon, 17 Apr 2006 23:21:20 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 558252596E8; Tue, 18 Apr 2006 08:20:58 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23243-02; Tue, 18 Apr 2006 08:20:53 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 603AE2596E7; Tue, 18 Apr 2006 08:20:53 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 18 Apr 2006 08:22:45 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6-7.4.20060mdk (X11/20050322)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dan Kohn <[e-mail]>
Cc: [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Dan Kohn wrote:

>>>>    o  Compliant software MUST NOT generate (but MAY accept) header
>>>>       fields of more than 998 octets.  This is the only limit on the
>>>>       length of a header field prescribed by this standard.   However,
>>>>       specific rules to the contrary may apply in particular  cases 
>>>> (for
>>>>       example, according to [RFC2047] lines of a header field  
>>>> containing
>>>>       encoded-words are limited to 76 octets).  [I-D.ietf-usefor- 
>>>> useage]
>>>>       includes suggested limits for convenience of display by user
>>>>       agents.
>>>
>>>
>>> [ I think this paragraph should be removed.
>>>
>>> The first sentence is redundant with RFC2822, Section 2.1.1, which  
>>> specified line lengths at 998 but says that implementations "would  
>>> do well to handle an arbitrarily large number of characters".    The 
>>> second sentence seems to override the "SHOULD be no more than  78 
>>> characters", however that's contradictory with the opening  
>>> paragraph of this section about this standard being "less  
>>> permissive".  The last two sentences are only necessary because  the 
>>> paragraph is sort of departing from RFC 2822, but not really.
>>>
>>> If the purpose is just to remove the 78 character line limit, I  
>>> would say:]
>>>
>>>    Section 2.1.1 of [RFC2822] says:
>>>
>>>       "Each line of characters MUST be no more than 998 characters,
>>>       and SHOULD be no more than 78 characters, excluding the CRLF."
>>>
>>>    For news articles, this restriction is loosened as follows:
>>>
>>>       "Each line of characters MUST be no more than 998 characters,
>>>       and MAY be line wrapped at 78 characters, excluding the CRLF."
>>>
>>> [But I don't think changing a SHOULD to a MAY is worthwhile, so I  
>>> would just kill the paragraph.]
>>
>>
>> Actually the paragraph as written ("header fields of more than 998  
>> octets") specifies an absolute limit on a header field, INCLUDING  
>> folding, not a limit on header field lines. Which is in conflict  
>> with the next paragraph you quote.
>>
>> So I think the text you suggest is an improvement.
>
>
> Harald, you caught an error I missed, which is that the first  
> sentence of the original text meant to say header lines instead of  
> header fields.  In any event, I would still propose that the whole  
> paragraph be removed, as I don't see any reason to discourage agents  
> from wrapping at 78 characters.  Specifically, I don't see why news  
> articles are special in terms of line wrapping compared to mail  
> messages.

There is one specific reason to not wrap I know of, which is that 
wrapping of Path: is not handled well by all sites. Others will have to 
comment on how much of an operational issue this is, and whether 
wrapping near 998 is significantly less of a problem than wrapping near 72.

>
>>>>    o  The character set for header fields is US-ASCII.  Where the  
>>>> use of
>>>>       non-ASCII characters is required, they MUST be encoded  using 
>>>> the
>>>>       MIME mechanisms defined in [RFC2047] and [RFC2231].
>>>
>>>
>>> This paragraph does not belong here, as these rules are the same  as 
>>> RFC 2822 et al, rather than being an exception to them.   Further, 
>>> it is redundant with the subsequent section, and so can  either be 
>>> deleted, or added there for emphasis.  (I would  recommend deletion.)
>>>
>>> Thus, the only restrictions beyond RFC 2822 in this section 2.2  are 
>>> requiring a colon space and no whitespace-only headers.  This  
>>> matters because all of the header definitions below reference back  
>>> to this section.
>>
>
> Harald, you didn't comment on whether you agree with deletion of this  
> paragraph or not.

I think it's another one of those where people have argued so long and 
strenously for an opposite viewpoint (the whole just-send-8 thing) that 
we restate what's obvious to make sure it remains obvious. I don't see 
harm in letting it remain (despite being chair of the EAI WG, which 
proposes to do away with that restriction in that context...).

>
>>>>    The MIME header fields MIME-Version, Content-Type, Content- 
>>>> Transfer-
>>>>    Encoding, Content-Disposition, and Content-Language are used  in 
>>>> news
>>>>    articles in the same circumstances and with the same meanings as
>>>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with  the 
>>>> added
>>>>    restrictions detailed in Section 2.2.
>>>
>>>
>>> It's inconsistent that the ABNF for RFC 2822 headers has been  
>>> repeated throughout the spec (with the addition of : SP), but not  
>>> these headers.  My first choice would be to remove all ABNF from  
>>> the spec that only differ in showing the ": SP" (although they  
>>> might still be included in an appendix).  Alternatively, these  
>>> headers should be specified.
>>
>>
>> Are there other headers that differ only with the ": SP"? I'm not  sure.
>> Other opinions?
>
>
> The following header ABNF differ from RFC 2822 only in their use of  
> ": SP".  I believe all of the following would best be moved to an  
> appendix:
>
>    from            =  "From:" SP mailbox-list CRLF
>    orig-date       =  "Date:" SP date-time CRLF
>    subject         =  "Subject:" SP unstructured CRLF
>    sender          =  "Sender:" SP mailbox CRLF
>    reply-to        =  "Reply-To:" SP address-list CRLF
>    comments        =  "Comments:" SP unstructured CRLF
>    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

Thanks. I don't see that including this ABNF in this document 
contributes much at all - except that it gives the sections a consistent 
look. Other opinions?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I3fFT3064871; Mon, 17 Apr 2006 20:41:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3I3fF6x064870; Mon, 17 Apr 2006 20:41:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I3fEX8064864 for <[e-mail]>; Mon, 17 Apr 2006 20:41:15 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id CDDF5D4C5AA; Mon, 17 Apr 2006 23:41:12 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Mon, 17 Apr 2006 23:40:42 -0400
X-Sasl-enc: 04jRy87gpYjPl0vmeTErlvFlCjBpdzqUpAu4pmyGOzBh 1145331640
Received: from [10.0.1.2] (cust-195.squaw-pw.exwire.com [67.150.152.195]) by frontend3.messagingengine.com (Postfix) with ESMTP id C0A6388CB; Mon, 17 Apr 2006 23:40:32 -0400 (EDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: Dan Kohn <[e-mail]>
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Date: Mon, 17 Apr 2006 20:40:36 -0700
To: Harald Alvestrand <[e-mail]>
X-Mailer: Apple Mail (2.749.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

>>>    o  Compliant software MUST NOT generate (but MAY accept) header
>>>       fields of more than 998 octets.  This is the only limit on the
>>>       length of a header field prescribed by this standard.   
>>> However,
>>>       specific rules to the contrary may apply in particular  
>>> cases (for
>>>       example, according to [RFC2047] lines of a header field  
>>> containing
>>>       encoded-words are limited to 76 octets).  [I-D.ietf-usefor- 
>>> useage]
>>>       includes suggested limits for convenience of display by user
>>>       agents.
>>
>> [ I think this paragraph should be removed.
>>
>> The first sentence is redundant with RFC2822, Section 2.1.1, which  
>> specified line lengths at 998 but says that implementations "would  
>> do well to handle an arbitrarily large number of characters".    
>> The second sentence seems to override the "SHOULD be no more than  
>> 78 characters", however that's contradictory with the opening  
>> paragraph of this section about this standard being "less  
>> permissive".  The last two sentences are only necessary because  
>> the paragraph is sort of departing from RFC 2822, but not really.
>>
>> If the purpose is just to remove the 78 character line limit, I  
>> would say:]
>>
>>    Section 2.1.1 of [RFC2822] says:
>>
>>       "Each line of characters MUST be no more than 998 characters,
>>       and SHOULD be no more than 78 characters, excluding the CRLF."
>>
>>    For news articles, this restriction is loosened as follows:
>>
>>       "Each line of characters MUST be no more than 998 characters,
>>       and MAY be line wrapped at 78 characters, excluding the CRLF."
>>
>> [But I don't think changing a SHOULD to a MAY is worthwhile, so I  
>> would just kill the paragraph.]
>
> Actually the paragraph as written ("header fields of more than 998  
> octets") specifies an absolute limit on a header field, INCLUDING  
> folding, not a limit on header field lines. Which is in conflict  
> with the next paragraph you quote.
>
> So I think the text you suggest is an improvement.

Harald, you caught an error I missed, which is that the first  
sentence of the original text meant to say header lines instead of  
header fields.  In any event, I would still propose that the whole  
paragraph be removed, as I don't see any reason to discourage agents  
from wrapping at 78 characters.  Specifically, I don't see why news  
articles are special in terms of line wrapping compared to mail  
messages.

>>>    o  The character set for header fields is US-ASCII.  Where the  
>>> use of
>>>       non-ASCII characters is required, they MUST be encoded  
>>> using the
>>>       MIME mechanisms defined in [RFC2047] and [RFC2231].
>>
>> This paragraph does not belong here, as these rules are the same  
>> as RFC 2822 et al, rather than being an exception to them.   
>> Further, it is redundant with the subsequent section, and so can  
>> either be deleted, or added there for emphasis.  (I would  
>> recommend deletion.)
>>
>> Thus, the only restrictions beyond RFC 2822 in this section 2.2  
>> are requiring a colon space and no whitespace-only headers.  This  
>> matters because all of the header definitions below reference back  
>> to this section.

Harald, you didn't comment on whether you agree with deletion of this  
paragraph or not.

>>>    The MIME header fields MIME-Version, Content-Type, Content- 
>>> Transfer-
>>>    Encoding, Content-Disposition, and Content-Language are used  
>>> in news
>>>    articles in the same circumstances and with the same meanings as
>>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with  
>>> the added
>>>    restrictions detailed in Section 2.2.
>>
>> It's inconsistent that the ABNF for RFC 2822 headers has been  
>> repeated throughout the spec (with the addition of : SP), but not  
>> these headers.  My first choice would be to remove all ABNF from  
>> the spec that only differ in showing the ": SP" (although they  
>> might still be included in an appendix).  Alternatively, these  
>> headers should be specified.
>
> Are there other headers that differ only with the ": SP"? I'm not  
> sure.
> Other opinions?

The following header ABNF differ from RFC 2822 only in their use of  
": SP".  I believe all of the following would best be moved to an  
appendix:

    from            =  "From:" SP mailbox-list CRLF
    orig-date       =  "Date:" SP date-time CRLF
    subject         =  "Subject:" SP unstructured CRLF
    sender          =  "Sender:" SP mailbox CRLF
    reply-to        =  "Reply-To:" SP address-list CRLF
    comments        =  "Comments:" SP unstructured CRLF
    keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

            - dan
-- 
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com/>  <tel:[phone]>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I3Onqm064309; Mon, 17 Apr 2006 20:24:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3I3On4O064308; Mon, 17 Apr 2006 20:24:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I3OmwR064302 for <[e-mail]>; Mon, 17 Apr 2006 20:24:48 -0700 (MST) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k3I3Ol1X031007 for <[e-mail]>; Mon, 17 Apr 2006 20:24:47 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 1B354E7958; Mon, 17 Apr 2006 20:24:47 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
In-Reply-To: <[e-mail]> (Seth Breidbart's message of "Mon, 17 Apr 2006 16:15:03 -0400 (EDT)")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]>
Date: Mon, 17 Apr 2006 20:24:46 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Seth Breidbart <[e-mail]> writes:
> John Stanley <[e-mail]> wrote (in suggested text):

>> Each crossposted article contains the same message id, but may have
>> different newsgroup-specific identifiers.

> Huh?  Since there's only _one_ article, it contains _several_ newsgroups
> in the appropriate header.  (Whatever a "newsgroup-specific identifier"
> is, the article might have several, but can't have different ones for
> different newsgroups.)

I think you have that almost exactly backwards.  An article may have
different newsgroup-specific identifiers in different newsgroups but may
not have more than one in a particular newsgroup.  (Read "article number"
for "newsgroup-specific identifier" if this isn't clear.)

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I3DePe063850; Mon, 17 Apr 2006 20:13:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3I3Deam063849; Mon, 17 Apr 2006 20:13:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3I3DdJG063843 for <[e-mail]>; Mon, 17 Apr 2006 20:13:39 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id C5B24D4BEBE; Mon, 17 Apr 2006 23:13:37 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Mon, 17 Apr 2006 23:13:07 -0400
X-Sasl-enc: +vGfqVOcJZLC45NNnvU3/VDsKYLBpm3OqirPM9zkpyqe 1145329986
Received: from [10.0.1.2] (cust-195.squaw-pw.exwire.com [67.150.152.195]) by frontend3.messagingengine.com (Postfix) with ESMTP id 6089C88BD; Mon, 17 Apr 2006 23:13:04 -0400 (EDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: Dan Kohn <[e-mail]>
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Date: Mon, 17 Apr 2006 20:13:24 -0700
To: John Stanley <[e-mail]>
X-Mailer: Apple Mail (2.749.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Apr 17, 2006, at 11:17 AM, John Stanley wrote:

> Dan Kohn <dan@xxxxxxxxxxx>:
>
>> A "newsgroup" is a single forum having a name and intended for  
>> articles on a specific topic. An article is "posted" to a single  
>> newsgroup or "crossposted" to several newsgroups. Crossposting  
>> uses a single article; it is different from posting the same text  
>> in different articles to different newsgroups.
>
> Crossposting does not use articles, it creates them. Further, even  
> crossposting creates multiple articles (each one gets a different  
> article
> number), but only one message (a single message id).
>
> Also, a "newsgroup" may have related attachments, such as a mailing  
> list,
> so it is not necessarily a "single forum".
>
> :::::
> A "newsgroup" is a forum having a name and which is intended for  
> articles relating to a specific topic. An article may be "posted"  
> to a single newsgroup, be "posted" to multiple newsgroups, or be  
> "crossposted" to several newsgroups. Crossposting differs from  
> posting to multiple newsgroups in that only one copy of the message  
> is created and transported, even though it shows up as different  
> articles in different newsgroups. Each crossposted article contains  
> the same message id, but may have different newsgroup-specific  
> identifiers. For reasons of efficiency and netiquette, crossposting  
> is almost always the preferred method of
> submitting an article to multiple newsgroups.
> :::::

I don't mean to be pedantic, but I thought the definition of a unique  
article is that it has a unique message-ID.  When you post a proto- 
article to multiple newsgroups, the article in each newsgroup gets a  
unique message-ID, and therefore one can't really post the same  
article to multiple newsgroups, except by crossposting.  If I'm wrong  
about this, than John Stanley's language is fine.

            - dan
-- 
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com/>  <tel:[phone]>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HNtLi4052824; Mon, 17 Apr 2006 16:55:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HNtLZM052823; Mon, 17 Apr 2006 16:55:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HNtKGv052817 for <[e-mail]>; Mon, 17 Apr 2006 16:55:20 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id C155CD4C2F9; Mon, 17 Apr 2006 19:55:18 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Mon, 17 Apr 2006 19:54:48 -0400
X-Sasl-enc: rspgwEOE2A1ZxdR4VGrqe/GiXz4knEoY39KWSJcYnF2l 1145318087
Received: from [10.0.1.2] (cust-195.squaw-pw.exwire.com [67.150.152.195]) by frontend3.messagingengine.com (Postfix) with ESMTP id 38ACA8836; Mon, 17 Apr 2006 19:54:44 -0400 (EDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail]
Content-Transfer-Encoding: 7bit
From: Dan Kohn <[e-mail]>
Subject: Re: Non-substantive edits to draft-ietf-usefor-usefor-07
Date: Mon, 17 Apr 2006 16:55:02 -0700
To: Harald Alvestrand <[e-mail]>
X-Mailer: Apple Mail (2.749.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Apr 17, 2006, at 11:02 AM, Harald Alvestrand wrote:
> In this case, it's necessary to refer to RFC 822, since that's what  
> RFC 2045 is based on. Unfortunately.

Makes sense.  I withdraw the suggested change.

            - dan
-- 
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com/>  <tel:[phone]>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HKGaAq039554; Mon, 17 Apr 2006 13:16:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HKGa9o039553; Mon, 17 Apr 2006 13:16:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HKGZKF039547 for <[e-mail]>; Mon, 17 Apr 2006 13:16:35 -0700 (MST) (envelope-from [e-mail])
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id ED0475B714 for <[e-mail]>; Mon, 17 Apr 2006 16:16:32 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k3HKF3n14369; Mon, 17 Apr 2006 16:15:03 -0400 (EDT)
Date: Mon, 17 Apr 2006 16:15:03 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from John Stanley on Mon, 17 Apr 2006 11:17:02 -0700 (PDT))
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

John Stanley <[e-mail]> wrote (in suggested text):

> Each crossposted article contains the same message id, but may 
> have different newsgroup-specific identifiers.

Huh?  Since there's only _one_ article, it contains _several_
newsgroups in the appropriate header.  (Whatever a "newsgroup-specific
identifier" is, the article might have several, but can't have
different ones for different newsgroups.)

Seth



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HIw7wU035312; Mon, 17 Apr 2006 11:58:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HIw7s4035311; Mon, 17 Apr 2006 11:58:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HIw5H3035304 for <[e-mail]>; Mon, 17 Apr 2006 11:58:06 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C2D2259716; Mon, 17 Apr 2006 20:57:44 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01042-09; Mon, 17 Apr 2006 20:57:38 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72F60259710; Mon, 17 Apr 2006 20:57:32 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2006 20:57:45 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Dan Kohn <[e-mail]>
Cc: [e-mail]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Summary:

I don't see any protocol changes being proposed, but have a different 
opinion about what's clearest in a few of these.

Dan Kohn wrote:
>
> Here are some slightly more substantive proposed changes.  Any of 
> these that are controversial may require a ticket.
>
>
>>    Additionally, Section 3.1.3 updates the [RFC2822] definition of
>>    <msg-id>.
>
> [This is wrong, as this document is not updating RFC 2822.  Here's 
> replacement text:]
>
>    Additionally, Section 3.1.3 specifies a stricter definition of
>    <msg-id> than the syntax used in [RFC2822] Section 3.6.4.
Doesn't seem controversial to me.
>
>>    A "newsgroup" is a single news forum, a logical bulletin board,
>>    having a name and nominally intended for articles on a specific
>>    topic.  An article is "posted to" a single newsgroup or several
>>    newsgroups.  When an article is posted to more than one newsgroup, it
>>    is said to be "crossposted"; note that this differs from posting the
>>    same text as part of each of several articles, one per newsgroup.
>
> ["logical bulletin board" doesn't mean anything, and so is not a 
> clarifying phrase.  Nominally is not the right word here, as it means 
> "In a nominal manner; by name; in name only; not in reality."  
> Newsgroups are intended to be on a topic in more than name only.  
> Here's a word-smithed version:]
>
>    A "newsgroup" is a single forum having a name and intended for 
> articles on a specific
>    topic.  An article is "posted" to a single newsgroup or 
> "crossposted" to several
>    newsgroups.  Crossposting uses a single article; it is different 
> from posting the
>    same text in different articles to different newsgroups.
Doesn't seem controversial to me, but I think the original second 
sentence is clearer than the proposed replacement.
>
>>    An article that uses the obsolete syntax specified in Section 4 of
>>    [RFC2822], except for the two exceptions mentioned below, is NOT
>>    conformant to this specification.
>>
>>    Articles are conformant if they use the <obs-phrase> construct (use
>>    of a phrase like "John Q. Public" without the use of quotes, see
>>    [RFC2822] Section 4.1) but agents MUST NOT generate productions of
>>    such syntax.
>>
>>    Articles are conformant if they use the "GMT" <zone>, as specified in
>>    Section 3.1.2.
>
> [This can be made much more clear as an ordered list:]
>
>    An article that uses the obsolete syntax specified in Section 4 of
>    [RFC2822] is NOT conformant to this specification, except for these
>    two cases:
>
>       1) Articles are conformant if they use the <obs-phrase> 
> construct (use
>       of a phrase like "John Q. Public" without the use of quotes, see
>       [RFC2822] Section 4.1) but agents MUST NOT generate productions of
>       such syntax.
>
>       2) Articles are conformant if they use the "GMT" <zone>, as 
> specified in
>       Section 3.1.2.
This seems noncontroversial to me.
>
>>    This document, and specifications that build upon it, specifies how
>>    to handle conformant articles.  Handling of non-conformant articles
>>    is outside the scope of this specification.
>>
>>    Agents conforming to this specification MUST generate only conformant
>>    articles.
>
> [I would remove these three sentences, as their meaning is implicit, 
> and yet goes unstated, in every IETF standard.  "handling of 
> non-conformant articles" must by definition be outside the scope of a 
> document that only specifies what a conformant article is.]
Unfortunately the discussion in the WG has shown that in this context, 
those sentences are not self-evident. I would like to keep them.
>
>>    The text below uses ABNF to specify restrictions on the syntax
>>    specified in [RFC2822]; this grammar is intended to be more
>>    restrictive than the [RFC2822] grammar.  Articles must conform to the
>>    ABNF specified in [RFC2822].
>>
>>    Articles must also conform to the restrictions specified here, both
>>    those that are expressed as text and those that are expressed as
>>    ABNF.
>
> [I believe these two paragraphs should be deleted, as they are 
> confusing and don't add any new information.  Specifically, they seem 
> redundant to the opening sentence of this section:  "An article is 
> said to be conformant to this specification if it conforms to the 
> format specified in [RFC2822] Section 3 and to the additional 
> requirements of this specification."]
I think this is an example of saying the same thing twice, but I'd like 
to keep the text.
>
>>          NOTE: This means that no header field body defined by or
>>          referenced by this document can be empty.  As a result, this
>>          document updates the <unstructured> construct from Section
>>          3.2.6 of [RFC2822] as follows:
>
> ["updates" means that RFC 2822 is being updated, but that is not case 
> here.]
>
>         NOTE: This means that no header field body defined by or
>         referenced by this document can be empty.   As a result,
>         rather than using the <unstructured> syntax from Section 3.2.6
>         of [RFC2822], this document uses a stricter definition:
Seems OK with me.
>
>>    o  Compliant software MUST NOT generate (but MAY accept) header
>>       fields of more than 998 octets.  This is the only limit on the
>>       length of a header field prescribed by this standard.  However,
>>       specific rules to the contrary may apply in particular cases (for
>>       example, according to [RFC2047] lines of a header field containing
>>       encoded-words are limited to 76 octets).  [I-D.ietf-usefor-useage]
>>       includes suggested limits for convenience of display by user
>>       agents.
>
> [ I think this paragraph should be removed.
>
> The first sentence is redundant with RFC2822, Section 2.1.1, which 
> specified line lengths at 998 but says that implementations "would do 
> well to handle an arbitrarily large number of characters".   The 
> second sentence seems to override the "SHOULD be no more than 78 
> characters", however that's contradictory with the opening paragraph 
> of this section about this standard being "less permissive".  The last 
> two sentences are only necessary because the paragraph is sort of 
> departing from RFC 2822, but not really.
>
> If the purpose is just to remove the 78 character line limit, I would 
> say:]
>
>    Section 2.1.1 of [RFC2822] says:
>
>       "Each line of characters MUST be no more than 998 characters,
>       and SHOULD be no more than 78 characters, excluding the CRLF."
>
>    For news articles, this restriction is loosened as follows:
>
>       "Each line of characters MUST be no more than 998 characters,
>       and MAY be line wrapped at 78 characters, excluding the CRLF."
>
> [But I don't think changing a SHOULD to a MAY is worthwhile, so I 
> would just kill the paragraph.]
Actually the paragraph as written ("header fields of more than 998 
octets") specifies an absolute limit on a header field, INCLUDING 
folding, not a limit on header field lines. Which is in conflict with 
the next paragraph you quote.

So I think the text you suggest is an improvement.
>
>>          NOTE: There is NO restriction on the number of lines into which
>>          a header field may be split, and hence there is NO restriction
>>          on the total length of a header field (in particular it may, by
>>          suitable folding, be made to exceed the 998 octets restriction
>>          pertaining to a single header line).
>
> This note should also be removed, as it's implicit in the RFC 2822 
> definition of header folding.
Agreed.
>
>>    o  The character set for header fields is US-ASCII.  Where the use of
>>       non-ASCII characters is required, they MUST be encoded using the
>>       MIME mechanisms defined in [RFC2047] and [RFC2231].
>
> This paragraph does not belong here, as these rules are the same as 
> RFC 2822 et al, rather than being an exception to them.  Further, it 
> is redundant with the subsequent section, and so can either be 
> deleted, or added there for emphasis.  (I would recommend deletion.)
>
> Thus, the only restrictions beyond RFC 2822 in this section 2.2 are 
> requiring a colon space and no whitespace-only headers.  This matters 
> because all of the header definitions below reference back to this 
> section.
>
>>    Most of these headers are mainly of interest to news servers, and
>>    news servers often need to process these fields very rapidly.
>
> I would remove this whole sentence, or at least the second half, as 
> it's superfluous to the specification.
It's been used as an argument for why (for instance) comments should not 
be permitted in this field. So I'd keep it.
>
>>    The MIME header fields MIME-Version, Content-Type, Content-Transfer-
>>    Encoding, Content-Disposition, and Content-Language are used in news
>>    articles in the same circumstances and with the same meanings as
>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with the added
>>    restrictions detailed in Section 2.2.
>
> It's inconsistent that the ABNF for RFC 2822 headers has been repeated 
> throughout the spec (with the addition of : SP), but not these 
> headers.  My first choice would be to remove all ABNF from the spec 
> that only differ in showing the ": SP" (although they might still be 
> included in an appendix).  Alternatively, these headers should be 
> specified.
Are there other headers that differ only with the ": SP"? I'm not sure.
Other opinions?
>
>>       NOTE: The <date-time> in this header field would normally be
>>       expected to be later than the <date-time> in the Date header
>>       field, but differences between the clocks on the various agents
>>       and other special circumstances might vitiate that; no provision
>>       is made for any such discrepancy to be corrected - better that the
>>       news server should just insert the correct time as it sees it.
>
> [Rewritten:]
>
> NOTE:  Since clocks on various agents may not be in sync, the 
> <date-time> in this header field may not be later than the Date header 
> field, as would be expected.  Agents SHOULD use the <date-time> they 
> believe is correct when adding Inject-Info but SHOULD NOT alter the 
> pre-existing Date field.
This language is clearer.
>
>>    The syntax is the same as that of the Newsgroups header field
>>    (Section 3.1.5, with the exception that the keyword "poster" (which
>>    is always lowercase) requests that followups should be mailed to the
>>    article's reply address rather than posted.  Although the keyword
>>    "poster" is case-sensitive, user agents MAY choose to recognize case-
>>    insensitive forms such as "Poster".
>
> [This is wordy with mismatched parentheses.  How about:]
>
>    The syntax is the same as that of the Newsgroups header field
>    (Section 3.1.5), with the exception that the keyword "poster"
>    requests that followups should be mailed to the article's reply
>    address rather than posted.  Agents MUST generate the
>    keyword "poster" in lower-case, but MAY choose to recognize
>    case-insensitive forms such as "Poster".
Seems an improvement to me.
>
>>    Additionally, any other <parameter> whose <attribute> starts with
>>    "x-" MAY be used where the defined ones appear to be unsuitable, but
>>    other unlisted <parameter>s SHOULD NOT be used unless defined in
>>    extensions to this standard.
>
> Rewritten:
>
>    Other <attribute>s SHOULD NOT be used unless defined in extensions
>    to this standard.  If non-standards-based <attribute>s are used, they
>    MUST begin with an "x-".
Clearer, in my opinion.
>
>
>>    Although comments and folding of white space are permitted throughout
>>    the Injection-Info header field, it is RECOMMENDED that folding is
>>    not used within any <parameter> (but only before or after the ";"
>>    separating those <parameter>s), and that comments are only used
>>    following the last <parameter>.
>
> [Rewritten:]
>
>    Although comments and folding of white space are permitted throughout
>    the Injection-Info header field, folding SHOULD NOT be
>    used within any <parameter>.  Folding SHOULD only occur before or 
> after
>    the ";" separating <parameter>s, and comments SHOULD only be used
>    following the last <parameter>.
Clearer.
>
>>    The header fields listed above are documented for historical purposes
>>    only.  Articles containing these header fields MUST NOT be generated.
>>    Persons writing new agents SHOULD ignore any former meanings of these
>>    header fields.
>
>    The header fields listed above are documented for historical purposes
>    only.  These header fields MUST NOT be generated and SHOULD be 
> ignored.
>
>
> Finally, I think it would highly useful to add an Appendix A with 
> example articles the way RFC 2822 does.  The ABNF for <path>, for 
> example, is crying out for examples. 
Or we could add a new document with examples, the way SIP does.... I'd 
like to get this one out the door....



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HILqNf032812; Mon, 17 Apr 2006 11:21:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HILqoN032811; Mon, 17 Apr 2006 11:21:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.peak.org (a.shell.peak.org [69.59.192.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HILnVh032805 for <[e-mail]>; Mon, 17 Apr 2006 11:21:51 -0700 (MST) (envelope-from [e-mail])
Received: from shell.peak.org (a.shell.peak.org [127.0.0.1]) by shell.peak.org (8.13.1/8.13.1) with ESMTP id k3HIH3p5028422 for <[e-mail]>; Mon, 17 Apr 2006 11:17:03 -0700
Received: from localhost (stanley@localhost) by shell.peak.org (8.13.1/8.13.1/Submit) with ESMTP id k3HIH23O028419 for <[e-mail]>; Mon, 17 Apr 2006 11:17:03 -0700
X-Authentication-Warning: shell.peak.org: stanley owned process doing -bs
Date: Mon, 17 Apr 2006 11:17:02 -0700 (PDT)
From: John Stanley <[e-mail]>
To: [e-mail]
Subject: rE: Substantive edits to draft-ietf-usefor-usefor-07
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Dan Kohn <dan@xxxxxxxxxxx>:

> A "newsgroup" is a single forum having a name and intended for articles 
>on a specific topic. An article is "posted" to a single newsgroup or 
>"crossposted" to several newsgroups. Crossposting uses a single article; 
>it is different from posting the same text in different articles to 
>different newsgroups.

Crossposting does not use articles, it creates them. Further, even 
crossposting creates multiple articles (each one gets a different article
number), but only one message (a single message id).

Also, a "newsgroup" may have related attachments, such as a mailing list,
so it is not necessarily a "single forum".

:::::
A "newsgroup" is a forum having a name and which is intended for 
articles relating to a specific topic. An article may be "posted" to a 
single newsgroup, be "posted" to multiple newsgroups, or be "crossposted" 
to several newsgroups. Crossposting differs from posting to multiple 
newsgroups in that only one copy of the message is created and 
transported, even though it shows up as different articles in different 
newsgroups. Each crossposted article contains the same message id, but may 
have different newsgroup-specific identifiers. For reasons of efficiency 
and netiquette, crossposting is almost always the preferred method of
submitting an article to multiple newsgroups.
:::::



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HI2H5e032171; Mon, 17 Apr 2006 11:02:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HI2HEC032170; Mon, 17 Apr 2006 11:02:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HI2G5C032164 for <[e-mail]>; Mon, 17 Apr 2006 11:02:17 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC8D525971B; Mon, 17 Apr 2006 20:01:54 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31825-07; Mon, 17 Apr 2006 20:01:51 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0884F25971A; Mon, 17 Apr 2006 20:01:49 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2006 20:02:06 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Dan Kohn <[e-mail]>
Cc: [e-mail]
Subject: Re: Non-substantive edits to draft-ietf-usefor-usefor-07
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Thanks for the thorough review, Dan!

Some small comments, only one of which is significant:

Dan Kohn wrote:
>
>>    An "article" is the unit of news, synonymous with an [RFC2822]
>
> s/news/Netnews/.
> s/synonymous/analogous/.  [This is a real error, as news articles and 
> RFC 2822 messages are "Similar or alike in such a way as to permit the 
> drawing of an analogy" not "Having the same or a similar meaning".]
actuallly a NetNews article is a syntactically valid RFC 2822 message. 
So while both terms are "not exactly the whole truth", I don't think 
"analogous" is a significant improvement.
>
>>       NOTE: The syntax of <parameter> ([RFC2045] as amended by
>>       [RFC2231]), taken in conjunction with the folding rules of
>>       [RFC0822], effectively allows [CFWS] to occur on either side of
>>       the "=" inside a <parameter>.
>
> s/[RFC2045] as amended/[RFC2045] Section 5.1 as amended/
> s/[RFC0822]/[RFC2822]/
In this case, it's necessary to refer to RFC 822, since that's what RFC 
2045 is based on. Unfortunately.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HEsjra021472; Mon, 17 Apr 2006 07:54:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HEsjYZ021471; Mon, 17 Apr 2006 07:54:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HEsiKc021464 for <[e-mail]>; Mon, 17 Apr 2006 07:54:44 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id BB791D4C6E2 for <[e-mail]>; Mon, 17 Apr 2006 10:54:43 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Mon, 17 Apr 2006 10:54:13 -0400
X-Sasl-enc: +Pp2h2DtEuHlkN0THnO2S63BwbNs87Vj5hOvZB+URl4l 1145285652
Received: from [10.0.1.2] (cust-195.squaw-pw.exwire.com [67.150.152.195]) by frontend3.messagingengine.com (Postfix) with ESMTP id 2393C8670 for <[e-mail]>; Mon, 17 Apr 2006 10:54:12 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: [e-mail]
From: Dan Kohn <[e-mail]>
Subject: Substantive edits to draft-ietf-usefor-usefor-07
Date: Mon, 17 Apr 2006 07:54:36 -0700
X-Mailer: Apple Mail (2.749.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Here are some slightly more substantive proposed changes.  Any of  
these that are controversial may require a ticket.


>    Additionally, Section 3.1.3 updates the [RFC2822] definition of
>    <msg-id>.

[This is wrong, as this document is not updating RFC 2822.  Here's  
replacement text:]

    Additionally, Section 3.1.3 specifies a stricter definition of
    <msg-id> than the syntax used in [RFC2822] Section 3.6.4.

>    A "newsgroup" is a single news forum, a logical bulletin board,
>    having a name and nominally intended for articles on a specific
>    topic.  An article is "posted to" a single newsgroup or several
>    newsgroups.  When an article is posted to more than one  
> newsgroup, it
>    is said to be "crossposted"; note that this differs from posting  
> the
>    same text as part of each of several articles, one per newsgroup.

["logical bulletin board" doesn't mean anything, and so is not a  
clarifying phrase.  Nominally is not the right word here, as it means  
"In a nominal manner; by name; in name only; not in reality."   
Newsgroups are intended to be on a topic in more than name only.   
Here's a word-smithed version:]

    A "newsgroup" is a single forum having a name and intended for  
articles on a specific
    topic.  An article is "posted" to a single newsgroup or  
"crossposted" to several
    newsgroups.  Crossposting uses a single article; it is different  
from posting the
    same text in different articles to different newsgroups.

>    An article that uses the obsolete syntax specified in Section 4 of
>    [RFC2822], except for the two exceptions mentioned below, is NOT
>    conformant to this specification.
>
>    Articles are conformant if they use the <obs-phrase> construct (use
>    of a phrase like "John Q. Public" without the use of quotes, see
>    [RFC2822] Section 4.1) but agents MUST NOT generate productions of
>    such syntax.
>
>    Articles are conformant if they use the "GMT" <zone>, as  
> specified in
>    Section 3.1.2.

[This can be made much more clear as an ordered list:]

    An article that uses the obsolete syntax specified in Section 4 of
    [RFC2822] is NOT conformant to this specification, except for these
    two cases:

       1) Articles are conformant if they use the <obs-phrase>  
construct (use
       of a phrase like "John Q. Public" without the use of quotes, see
       [RFC2822] Section 4.1) but agents MUST NOT generate  
productions of
       such syntax.

       2) Articles are conformant if they use the "GMT" <zone>, as  
specified in
       Section 3.1.2.

>    This document, and specifications that build upon it, specifies how
>    to handle conformant articles.  Handling of non-conformant articles
>    is outside the scope of this specification.
>
>    Agents conforming to this specification MUST generate only  
> conformant
>    articles.

[I would remove these three sentences, as their meaning is implicit,  
and yet goes unstated, in every IETF standard.  "handling of non- 
conformant articles" must by definition be outside the scope of a  
document that only specifies what a conformant article is.]

>    The text below uses ABNF to specify restrictions on the syntax
>    specified in [RFC2822]; this grammar is intended to be more
>    restrictive than the [RFC2822] grammar.  Articles must conform  
> to the
>    ABNF specified in [RFC2822].
>
>    Articles must also conform to the restrictions specified here, both
>    those that are expressed as text and those that are expressed as
>    ABNF.

[I believe these two paragraphs should be deleted, as they are  
confusing and don't add any new information.  Specifically, they seem  
redundant to the opening sentence of this section:  "An article is  
said to be conformant to this specification if it conforms to the  
format specified in [RFC2822] Section 3 and to the additional  
requirements of this specification."]

>          NOTE: This means that no header field body defined by or
>          referenced by this document can be empty.  As a result, this
>          document updates the <unstructured> construct from Section
>          3.2.6 of [RFC2822] as follows:

["updates" means that RFC 2822 is being updated, but that is not case  
here.]

         NOTE: This means that no header field body defined by or
         referenced by this document can be empty.   As a result,
         rather than using the <unstructured> syntax from Section 3.2.6
         of [RFC2822], this document uses a stricter definition:

>    o  Compliant software MUST NOT generate (but MAY accept) header
>       fields of more than 998 octets.  This is the only limit on the
>       length of a header field prescribed by this standard.  However,
>       specific rules to the contrary may apply in particular cases  
> (for
>       example, according to [RFC2047] lines of a header field  
> containing
>       encoded-words are limited to 76 octets).  [I-D.ietf-usefor- 
> useage]
>       includes suggested limits for convenience of display by user
>       agents.

[ I think this paragraph should be removed.

The first sentence is redundant with RFC2822, Section 2.1.1, which  
specified line lengths at 998 but says that implementations "would do  
well to handle an arbitrarily large number of characters".   The  
second sentence seems to override the "SHOULD be no more than 78  
characters", however that's contradictory with the opening paragraph  
of this section about this standard being "less permissive".  The  
last two sentences are only necessary because the paragraph is sort  
of departing from RFC 2822, but not really.

If the purpose is just to remove the 78 character line limit, I would  
say:]

    Section 2.1.1 of [RFC2822] says:

       "Each line of characters MUST be no more than 998 characters,
       and SHOULD be no more than 78 characters, excluding the CRLF."

    For news articles, this restriction is loosened as follows:

       "Each line of characters MUST be no more than 998 characters,
       and MAY be line wrapped at 78 characters, excluding the CRLF."

[But I don't think changing a SHOULD to a MAY is worthwhile, so I  
would just kill the paragraph.]

>          NOTE: There is NO restriction on the number of lines into  
> which
>          a header field may be split, and hence there is NO  
> restriction
>          on the total length of a header field (in particular it  
> may, by
>          suitable folding, be made to exceed the 998 octets  
> restriction
>          pertaining to a single header line).

This note should also be removed, as it's implicit in the RFC 2822  
definition of header folding.

>    o  The character set for header fields is US-ASCII.  Where the  
> use of
>       non-ASCII characters is required, they MUST be encoded using the
>       MIME mechanisms defined in [RFC2047] and [RFC2231].

This paragraph does not belong here, as these rules are the same as  
RFC 2822 et al, rather than being an exception to them.  Further, it  
is redundant with the subsequent section, and so can either be  
deleted, or added there for emphasis.  (I would recommend deletion.)

Thus, the only restrictions beyond RFC 2822 in this section 2.2 are  
requiring a colon space and no whitespace-only headers.  This matters  
because all of the header definitions below reference back to this  
section.

>    Most of these headers are mainly of interest to news servers, and
>    news servers often need to process these fields very rapidly.

I would remove this whole sentence, or at least the second half, as  
it's superfluous to the specification.

>    The MIME header fields MIME-Version, Content-Type, Content- 
> Transfer-
>    Encoding, Content-Disposition, and Content-Language are used in  
> news
>    articles in the same circumstances and with the same meanings as
>    those specified in [RFC2045], [RFC2183], and [RFC3282] with the  
> added
>    restrictions detailed in Section 2.2.

It's inconsistent that the ABNF for RFC 2822 headers has been  
repeated throughout the spec (with the addition of : SP), but not  
these headers.  My first choice would be to remove all ABNF from the  
spec that only differ in showing the ": SP" (although they might  
still be included in an appendix).  Alternatively, these headers  
should be specified.

>       NOTE: The <date-time> in this header field would normally be
>       expected to be later than the <date-time> in the Date header
>       field, but differences between the clocks on the various agents
>       and other special circumstances might vitiate that; no provision
>       is made for any such discrepancy to be corrected - better  
> that the
>       news server should just insert the correct time as it sees it.

[Rewritten:]

NOTE:  Since clocks on various agents may not be in sync, the <date- 
time> in this header field may not be later than the Date header  
field, as would be expected.  Agents SHOULD use the <date-time> they  
believe is correct when adding Inject-Info but SHOULD NOT alter the  
pre-existing Date field.

>    The syntax is the same as that of the Newsgroups header field
>    (Section 3.1.5, with the exception that the keyword "poster" (which
>    is always lowercase) requests that followups should be mailed to  
> the
>    article's reply address rather than posted.  Although the keyword
>    "poster" is case-sensitive, user agents MAY choose to recognize  
> case-
>    insensitive forms such as "Poster".

[This is wordy with mismatched parentheses.  How about:]

    The syntax is the same as that of the Newsgroups header field
    (Section 3.1.5), with the exception that the keyword "poster"
    requests that followups should be mailed to the article's reply
    address rather than posted.  Agents MUST generate the
    keyword "poster" in lower-case, but MAY choose to recognize
    case-insensitive forms such as "Poster".

>    Additionally, any other <parameter> whose <attribute> starts with
>    "x-" MAY be used where the defined ones appear to be unsuitable,  
> but
>    other unlisted <parameter>s SHOULD NOT be used unless defined in
>    extensions to this standard.

Rewritten:

    Other <attribute>s SHOULD NOT be used unless defined in extensions
    to this standard.  If non-standards-based <attribute>s are used,  
they
    MUST begin with an "x-".

>    Although comments and folding of white space are permitted  
> throughout
>    the Injection-Info header field, it is RECOMMENDED that folding is
>    not used within any <parameter> (but only before or after the ";"
>    separating those <parameter>s), and that comments are only used
>    following the last <parameter>.

[Rewritten:]

    Although comments and folding of white space are permitted  
throughout
    the Injection-Info header field, folding SHOULD NOT be
    used within any <parameter>.  Folding SHOULD only occur before or  
after
    the ";" separating <parameter>s, and comments SHOULD only be used
    following the last <parameter>.

>    The header fields listed above are documented for historical  
> purposes
>    only.  Articles containing these header fields MUST NOT be  
> generated.
>    Persons writing new agents SHOULD ignore any former meanings of  
> these
>    header fields.

    The header fields listed above are documented for historical  
purposes
    only.  These header fields MUST NOT be generated and SHOULD be  
ignored.


Finally, I think it would highly useful to add an Appendix A with  
example articles the way RFC 2822 does.  The ABNF for <path>, for  
example, is crying out for examples.

            - dan
-- 
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com/>  <tel:[phone]>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HEsDK6021227; Mon, 17 Apr 2006 07:54:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HEsDX3021226; Mon, 17 Apr 2006 07:54:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HEsCJZ021218 for <[e-mail]>; Mon, 17 Apr 2006 07:54:12 -0700 (MST) (envelope-from [e-mail])
Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id AD2DCD4C65E for <[e-mail]>; Mon, 17 Apr 2006 10:54:10 -0400 (EDT)
Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Mon, 17 Apr 2006 10:53:40 -0400
X-Sasl-enc: +6pOMe/bOyHztVdASlLLQIZGpuYO73xEsanHxVZM8NaM 1145285619
Received: from [10.0.1.2] (cust-195.squaw-pw.exwire.com [67.150.152.195]) by frontend3.messagingengine.com (Postfix) with ESMTP id 327388675 for <[e-mail]>; Mon, 17 Apr 2006 10:53:38 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v749.3)
References: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Dan Kohn <[e-mail]>
Subject: Non-substantive edits to draft-ietf-usefor-usefor-07
Date: Mon, 17 Apr 2006 07:53:57 -0700
To: [e-mail]
X-Mailer: Apple Mail (2.749.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Here are some suggested edits to the usefor draft.  This email  
consists of grammatical fixes, typos, and rewordings that don't  
change the meaning.  Hopefully, none of these should require a  
ticket.  The next draft has some slightly more substantive changes,  
though hopefully nothing too controversial.


>    This document specifies the syntax of network news (Netnews)  
> articles

s/network news (Netnews)/Netnews/

[Netnews was defined in the previous paragraph but network news was  
not.]

>    This specification is intended as a definition of what article
>    content format is to be passed between systems.  Though some news
>    systems locally store articles in this format (which eliminates the
>    need for translation between formats) and others use formats that
>    differ from the one specified in this standard, local storage is
>    outside of the scope of this standard.

s/Though/Although/.
Delete " and others use formats that differ from the one specified in  
this standard" as the phrase is redundant to the previous clause (if  
some systems do x, others must not).

>    Header fields defined in this specification use the Augmented  
> Backus-
>    Naur Form (ABNF) notation (including the Core Rules) specified in
>    [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as
>    amended by [RFC2231], and [RFC3986], specifically:

s/amended/updated/ [to use standard RFC terminology.]

>    An "article" is the unit of news, synonymous with an [RFC2822]

s/news/Netnews/.
s/synonymous/analogous/.  [This is a real error, as news articles and  
RFC 2822 messages are "Similar or alike in such a way as to permit  
the drawing of an analogy" not "Having the same or a similar meaning".]

>    "message".  A "proto-article" is one that has not yet been injected
>    into the news system.  In constrast to an "article", a "proto-
>    article" may lack some mandatory header fields.

s/constrast/contrast/

>    A "message identifier" (Section 3.1.3) is a unique identifier  
> for an
>    article, usually supplied by the "user agent" which posted it or,

s/which/that/

>    A "poster" is the person or software that composes and submits a
>    possibly compliant article to a "user agent".  The poster is
>    analogous to [RFC2822]'s author.

s/a possibly compliant article/an article or proto-article/

[A non-compliant article is not a Netnews article according to this  
RFC, so it's not worth explicitly specifying the possibility.]

>    Section 2 defines the format of news articles.  Section 3  
> details the
>    header fields necessary to make an article suitable for the Netnews
>    environment.

s/news/Netnews/

>    This document, and specifications that build upon it, specifies how
>    to handle conformant articles.  Handling of non-conformant articles
>    is outside the scope of this specification.

/specifies/specify/

>    General rules which apply to all header fields (even those  
> documented
>    in [RFC2822] and [RFC2045]) are listed below and those that  
> apply to
>    specific header fields are described in the relevent sections of  
> this
>    document.

s/relevent/relevant/

>    unstructured    =  *WSP utext *( [FWS] utext ) *WSP
>
>          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.

s/but/and/

>    For the purposes of Section 5 of [RFC2047], all header fields  
> defined
>    in Section 3 of this standard are to be considered as "extension
>    message header fields" (insofar as they are not already so  
> considered
>    under the existing Email standards), permitting the use of  
> [RFC2047]
>    encodings within any <unstructured> header field, or within any
>    <comment> or <phrase> permittted within any structured header  
> field.

delete " (insofar as they are not already so considered under the  
existing Email standards)" since it adds nothing.  s/permittted/ 
permitted/

>    Therefore, agents MUST accept <date-time> constructs which use the
>    "GMT" zone.

s/which/that/

>       NOTE: This specification does not change [RFC2822], which says
>       that agents MUST NOT generate <date-time> constructs which  
> include
>       any zone names defined by <obs-zone>.

s/which/that/
>
>    The Message-ID header field contains a single unique message
>    identifier.  Netnews is more dependent on message identifier
>    uniqueness and fast comparison than Email is, and some news  
> software

s/Email/email/

>    and standards [I-D.ietf-nntpext-base] might have trouble with the
>    full range of possible <msg-id>s permitted by [RFC2822]; this  
> section

s/[RFC2822]; this/[RFC2822].  This/

>    therefore restricts the syntax of <msg-id> as compared to Section
>    3.6.4 of [RFC2822].  The global uniqueness requirement for <msg-id>
>    in [RFC2822] is to be understood as applying across all protocols
>    using such message identifiers, and across both Email and  
> Netnews in
>    particular.

s/Email/email/

>       NOTE: The length restriction ensures that systems which accept
>       message identifiers as a parameter when retrieving an article
>       (e.g.  [I-D.ietf-nntpext-base]) can rely on a bounded length.

s/which/that/

>    o  it ensures that no string of characters is quoted if it was
>       already a <dot-atom-text> (it MUST start or end with a ".", or
>       contain at least one <mqspecial>),

s/was/were/   [subjunctive tense]

>    When generationg a <msg-id>, implementations SHOULD use a domain  
> name
>    as the <id-right>.

s/generationg/generating/

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

s/will cause interoperability problems/may cause interoperability  
problems/

>    The Injection-Date header field contains the date and time that the
>    article was injected into the network.  Its purpose is to  
> prevent the
>    reinjection into the news stream of "stale" articles which have
>    already expired by the time they arrive at some news server.

s/reinjection/re-injection/
s/which/that/

>       NOTE: The Expires header field is also sometimes used in Email
>       with a similar meaning [RFC2156].

s/Email/email/

>       NOTE: The Supersedes header field defined here has no connection
>       with the Supersedes header field that sometimes appears in Email
>       messages converted from X.400 according to [RFC2156]; in
>       particular, the syntax here permits only one <msg-id> in  
> contrast
>       to the multiple <msg-id>s in that Email version.

s/Email/email/  [2 occurrences]

>    "All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD  
> contain
>    at least three characters, except when they are two-letter country
>    names as in [ISO.3166.1988]. <dist-name>s are case-insensitive  
> (i.e.
>    "US", "Us", "uS", and "us" all specify the same distribution).

s/as in/drawn from/

>    There is no "s" in Organization.

Add a "NOTE: " in front of this paragraph to match Supersedes.

>    The User-Agent header field contains information about the user  
> agent
>    (typically a newsreader) generating the article, for statistical
>    purposes and tracing of standards violations to specific software
>    needing correction.  It is intended that this header field be
>    suitable for use in Email.

s/Email/email/

>       NOTE: The syntax of <parameter> ([RFC2045] as amended by
>       [RFC2231]), taken in conjunction with the folding rules of
>       [RFC0822], effectively allows [CFWS] to occur on either side of
>       the "=" inside a <parameter>.

s/[RFC2045] as amended/[RFC2045] Section 5.1 as amended/
s/[RFC0822]/[RFC2822]/

>       NOTE: Since any such <host-value>>, <sender-value> or <address-
>       list> has also to be a syntactically correct <value>, it will
>       usually be necessary to encapsulate it as a <quoted-string>, for
>       example:

s/<host-value>>/<host-value>/
s/has also to be/also has to be/

[The next 4 paragraphs should be indented so as to be included in the  
same Note.]

>    The "posting-account" <parameter>> identifies the source from which
>
>    The "sender" <parameter>> identifies a mailbox that the news server
>
>    It is a matter of local policy whether to include the "posting-
>    account" <parameter>>, the "sender" <parameter>, both, or neither.

s/<parameter>>/<parameter>/  [3 occurrences]

>    The "logging-data" <parameter> contains information (typically a
>    session number or other non-persistent means of identifying a  
> posting
>    account) which will enable the true origin of the article to be
>    determined by reference to logging information kept by the news
>    server.

s/which/that/

>    The "mail-complaints-to" <parameter> specifies mailbox(es) for
>    sending complaints concerning the behavior of the poster of the
>    article.

s/mailbox(es)/one or more mailboxes/

>    Early versions of news software following the modern format  
> sometimes
>    generated header fields like the following:

Obsolete Netnews software sometimes generated header fields such as:

>    In addition, this present standard obsoletes certain header fields
>    defined in [Son-of-1036]:

s/this present standard/this standard/

>    [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
>               text messages", STD 11, RFC 822, August 1982.

[This should be removed, as the citation should be to RFC 2822.]

>    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>               Resource Identifier (URI): Generic Syntax", STD 66,
>               RFC 3986, January 2005.

[This reference needs to be moved to the normative section.]

> Appendix A.  Acknowledgements

s/Acknowledgments/Acknowledgments

>    o  Certain header fields, notably Lines, have been made obsolete
>       (Section 3.3).

s/made obsolete/deprecated or made obsolete/

            - dan
-- 
Dan Kohn <mailto:[e-mail]>
<http://www.dankohn.com/>  <tel:[phone]>







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HAPR2V005826; Mon, 17 Apr 2006 03:25:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HAPRJM005825; Mon, 17 Apr 2006 03:25:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HAPQLE005817 for <[e-mail]>; Mon, 17 Apr 2006 03:25:26 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A22F259706 for <[e-mail]>; Mon, 17 Apr 2006 12:25:05 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21359-01 for <[e-mail]>; Mon, 17 Apr 2006 12:25:00 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5FDAA259703 for <[e-mail]>; Mon, 17 Apr 2006 12:25:00 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2006 12:25:20 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: [e-mail]
Subject: End of issues
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I believe that I have now suggested resolutions for all four open issues 
listed on the April 11 issues list.

With that, I'd like to ask the editor to produce an -08 version that 
includes those resolutions, and make WG Last Call on that when it is ready.

             Harald



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HANs1m005757; Mon, 17 Apr 2006 03:23:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HANsB2005756; Mon, 17 Apr 2006 03:23:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HANrC2005750 for <[e-mail]>; Mon, 17 Apr 2006 03:23:53 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 71643259706; Mon, 17 Apr 2006 12:23:29 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20672-08; Mon, 17 Apr 2006 12:23:25 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id CDEB5259703; Mon, 17 Apr 2006 12:23:24 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2006 12:23:44 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: Re: #1179 not closed? Re: Ticket status, March 24
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I am not happy with Charles' text on this issue. Trying again, based on 
the -07 NOTE:

    NOTE: The [RFC2822] specification sometimes uses [FWS] at the 
beginning or end of ABNF
   describing a header field content. This specification uses *WSP in 
such cases, also in cases where
   this specification redefines constructs from [RFC2822]. 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.

Charles' proposed text was:

   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.

If anyone wishes to make further changes, or prefers Charles' version, 
please speak up.

                    Harald

Charles Lindsey wrote:
> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>
>   
>> Charles Lindsey wrote:
>>     
>
>   
>>> 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.
>>>
>>>  
>>>
>>>       
>> 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.
>>     
>
> Ah! I had not spotted that small change in the actual draft-07 text.
>
>   
>> 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?
>>     
>
> 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
>
>   



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HAE9hL004981; Mon, 17 Apr 2006 03:14:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3HAE9hn004980; Mon, 17 Apr 2006 03:14:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3HAE81C004973 for <[e-mail]>; Mon, 17 Apr 2006 03:14:09 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5BC82259703 for <[e-mail]>; Mon, 17 Apr 2006 12:13:47 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20672-07 for <[e-mail]>; Mon, 17 Apr 2006 12:13:43 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id A03752596D9 for <[e-mail]>; Mon, 17 Apr 2006 12:13:43 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2006 12:14:03 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: [e-mail]
Subject: #1178 USEFOR 3.1.5++: Whitespace in headers with newsgroup names
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

This ticket has a confused history, but the issue seems clear:

Whitespace, including folding whitespace, in lists of newsgroups 
(Newsgroups:, Distribution:, Followup-to:) is a newly introduced feature 
of this specification, and doesn't work as intended on all news servers.

The current text in 3.1.5 is:

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.

The claim (by Frank, Feb 20) is that:

> 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.
The note is from section 3.2 of USEPRO, "Transitional arrangements":

* Because of its importance to all serving agents, the whitespace and 
folding in Newsgroups header fields newly permitted by [USEFOR] SHOULD 
NOT be generated (though it MUST be accepted); this restriction may well 
be removed in a future version of this standard.

I suggest the following resolution for USEFOR:

In section 3.1.5:

Not all servers support <FWS> in the list of newsgroups. In particular, 
folding the Newsgroups header field over several lines has been shown to 
harm propagation significantly. <FWS> in the <newsgroup-list> SHOULD NOT 
be generated, but MUST be accepted.

In section 3.2.3 (followup-to):

As in the Newsgroups: header field, <FWS> in the <newsgroup-list> SHOULD 
NOT be generated, but MUST be accepted.

In section 3.2.7 (distribution):

<FWS> in the <dist-list> SHOULD NOT be generated, but MUST be accepted.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3H8fdRw098673; Mon, 17 Apr 2006 01:41:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3H8fdmB098672; Mon, 17 Apr 2006 01:41:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3H8fbi7098665 for <[e-mail]>; Mon, 17 Apr 2006 01:41:38 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEB442596FE; Mon, 17 Apr 2006 10:41:16 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18289-08; Mon, 17 Apr 2006 10:41:13 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA0CF2596FF; Mon, 17 Apr 2006 10:41:12 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2006 10:41:32 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: Re: #1047 Path header - proposed resolution
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>
>   
>> Are we done with this now?
>>     
>
> We are pretty nearly there.
>
>   
>> ==============================================================
>>     
>
>   
>> 3.1.6.  Path
>>     
>
>
>   
>> path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
>>     
>                                          ^^^^^^^^^^^^^^
>
> I really dislike that. If these things are legal, then they may well
> continue to arise in future. This is USEPRO territory, and there is
> already wording there pointing out that this is a less-preferred
> alternative to be used only when there is good reason, and by people who
> know what they are about and who understand (and have accepted) certain
> risks. We can review this wording when we come to USEPRO if people do not
> feel it is strong/clear enough, but let us not preempt that discussion by
> including a non-normative comment here.
>   
And I like that - these things have to be legal for acceptance, and they 
even have to be legal for generation by new systems (those that replace 
old systems which use those names). I think "legacy" is just about 
exactly right - the discussion is over, all that's left is the codification.
>
>   
>>   Each <path-identity> in the <path-list> (which does not include  the
>>   <tail-entry>) indicates, from right to left, the successive agents
>>   through which the article has passed.   The use
>>   of the <diag-match>, which appears as "!!", indicates that the agent 
>> to its left
>>     
>
> Still not entirely clear. How about:
>
> The use of the <diag-match> which, since it follows a <path-delimiter>,
> appears as "!!", indicates that the agent to its left ...
>
>  verified the identity of the agent to its right before
>   
actually the <diag-match> precedes a <path-delimiter>. People can read 
the grammar.
>>   the article (whereas the <path-delimiter> "!" implies no such claim).
>>     
>                          ^
>                        single
>   
In the grammar, !! is not a double <path-delimiter>. So this change is 
actually not consistent with grammar.
I'd support removing the parenthesis.
>
>   
>>      NOTE: One usage of a path-diagnostic is to record an IP address.
>>     The fact that IPv6 addresses
>>     are allowed means that the colon (:) is permitted; 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.
>>     
>
> You have removed the NOTE explaining why the <diag-deprecated> has been
> included.  In years to come, people are going to wonder what it is all
> about. I think it needs some explanation (though the explanation could go
> in USEPRO).
>
>   
Send text, or leave it to USEPRO.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3H8Z12s098436; Mon, 17 Apr 2006 01:35:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3H8Z1nc098435; Mon, 17 Apr 2006 01:35:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3H8YvL3098422 for <[e-mail]>; Mon, 17 Apr 2006 01:34:58 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62FA92596FF; Mon, 17 Apr 2006 10:34:36 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18021-05; Mon, 17 Apr 2006 10:34:32 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 968EC2596FE; Mon, 17 Apr 2006 10:34:32 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2006 10:34:52 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>
>
>   
>>   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 administrator.  This notation can include any
>>   information the administrator deems pertinent.  In order to limit the
>>   exposure of personal data, it SHOULD be given in a form that can't be
>>   interpreted by other sites.  However, to make it useful for rate
>>   limiting and abuse detection, two messages posted from the same source
>>   SHOULD have the same value of "posting-account", and two messages from
>>   different sources SHOULD have differing values of "posting-account".
>>   The exact definition of "source" is left to the discretion of the news
>>   server administrator.
>>     
>
> Or you could say that it is a matter for negotiation between the
> administrator and the poster (for example a group of moderators might
> negotiate use of some authorization identity, but otherwise you get an
> authentication identity of some sort).
>   
I would not say that. This header is set by the administrator, and 
referring to negotiation with the poster is going to make life as an 
administrator look more complex (as well as being untrue in the majority 
of the cases).
> I also prefer s/differing/different/, as a matter of style.
>   
For this instance, I'd actually prefer "differing", but that's a nit I'm 
happy to leave as editor's choice.
>   
>> Are we done?
>>     
>
> Pretty much. That text will do if needs be.
>
>   



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLUE6V097320; Sat, 15 Apr 2006 14:30:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3FLUE0C097319; Sat, 15 Apr 2006 14:30:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLU6XD097284 for <[e-mail]>; Sat, 15 Apr 2006 14:30:07 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-64-190.midband.mdip.bt.net ([81.144.64.190]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444165dd.3b15.2d7d for [e-mail]; Sat, 15 Apr 2006 22:30:05 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3FLSG315344 for [e-mail]; Sat, 15 Apr 2006 22:28:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23230
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 14 Apr 2006 19:35:50 GMT
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:


>   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 administrator.  This notation can include any
>   information the administrator deems pertinent.  In order to limit the
>   exposure of personal data, it SHOULD be given in a form that can't be
>   interpreted by other sites.  However, to make it useful for rate
>   limiting and abuse detection, two messages posted from the same source
>   SHOULD have the same value of "posting-account", and two messages from
>   different sources SHOULD have differing values of "posting-account".
>   The exact definition of "source" is left to the discretion of the news
>   server administrator.

Or you could say that it is a matter for negotiation between the
administrator and the poster (for example a group of moderators might
negotiate use of some authorization identity, but otherwise you get an
authentication identity of some sort).

I also prefer s/differing/different/, as a matter of style.

>Are we done?

Pretty much. That text will do if needs be.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLUASv097316; Sat, 15 Apr 2006 14:30:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3FLUA4O097315; Sat, 15 Apr 2006 14:30:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLU8eE097300 for <[e-mail]>; Sat, 15 Apr 2006 14:30:09 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-64-190.midband.mdip.bt.net ([81.144.64.190]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444165df.3b15.2d7f for [e-mail]; Sat, 15 Apr 2006 22:30:07 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3FLSFc15327 for [e-mail]; Sat, 15 Apr 2006 22:28:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23227
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path header - proposed resolution
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 14 Apr 2006 19:06:08 GMT
Lines: 63
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>Are we done with this now?

We are pretty nearly there.

>==============================================================

>3.1.6.  Path


>path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
                                         ^^^^^^^^^^^^^^

I really dislike that. If these things are legal, then they may well
continue to arise in future. This is USEPRO territory, and there is
already wording there pointing out that this is a less-preferred
alternative to be used only when there is good reason, and by people who
know what they are about and who understand (and have accepted) certain
risks. We can review this wording when we come to USEPRO if people do not
feel it is strong/clear enough, but let us not preempt that discussion by
including a non-normative comment here.


>   Each <path-identity> in the <path-list> (which does not include  the
>   <tail-entry>) indicates, from right to left, the successive agents
>   through which the article has passed.   The use
>   of the <diag-match>, which appears as "!!", indicates that the agent 
>to its left

Still not entirely clear. How about:

The use of the <diag-match> which, since it follows a <path-delimiter>,
appears as "!!", indicates that the agent to its left ...

 verified the identity of the agent to its right before
>   the article (whereas the <path-delimiter> "!" implies no such claim).
                         ^
                       single


>      NOTE: One usage of a path-diagnostic is to record an IP address.
>     The fact that IPv6 addresses
>     are allowed means that the colon (:) is permitted; 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.

You have removed the NOTE explaining why the <diag-deprecated> has been
included.  In years to come, people are going to wonder what it is all
about. I think it needs some explanation (though the explanation could go
in USEPRO).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLU8pE097308; Sat, 15 Apr 2006 14:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3FLU8Db097307; Sat, 15 Apr 2006 14:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLU7VR097285 for <[e-mail]>; Sat, 15 Apr 2006 14:30:08 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-64-190.midband.mdip.bt.net ([81.144.64.190]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444165de.3b15.2d7e for [e-mail]; Sat, 15 Apr 2006 22:30:06 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3FLSGH15339 for [e-mail]; Sat, 15 Apr 2006 22:28:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23229
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Fri, 14 Apr 2006 19:29:20 GMT
Lines: 49
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:


>An obvious Usenet-relevant example would be a posting account that's used
>by the moderators of example.research.  example.research has five
>different moderators, all of whom can approve articles.  Each moderator
>authenticates with their own credentials, and all moderators have access
>to a shared "example.research moderator" account on the server that's used
>for all of the posting.

I think it should normally be the authentication identity, but just
occasionally authorization might be appropriate, so the wording should be
slanted that way.

BTW, since SASL will become more and more used, there was a suggestion to
have a separate "authentication=" parameter, which we never really decided
on. It would make the matter entirely clear.


>>   The "logging-data" <parameter> contains information (typically a
>>   session number or other non-persistent means of identifying a posting
>>   account) which will enable the true origin of the article to be
>>   determined by reference to logging information kept by the news
>>   server.

>I remain sad to see this go into the document, but the redundancy with
>message ID isn't sufficiently bad for me to raise a stink.  Consider me
>part of the rough in rough consensus, I guess.

The essential diference is that the same parameter does not occur for each
article from the same source. Some ISPs, who cannot be bothered to keep
logs, include an encrypted log entry in the article. We all agree this is
a dumb idea (and USEAGE might well say so), but it happens.

The more useful use is as an index into the injectors logs, so that their
abuse desk can quickly locate the entry. But that usage should be
_in_addition_ to a posting-account (and/or posting-host). We might even say
that.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLU8os097298; Sat, 15 Apr 2006 14:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3FLU8J4097297; Sat, 15 Apr 2006 14:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FLU67j097283 for <[e-mail]>; Sat, 15 Apr 2006 14:30:07 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-64-190.midband.mdip.bt.net ([81.144.64.190]) by sov-mail-b0013.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 444165dc.3b15.2d7c for [e-mail]; Sat, 15 Apr 2006 22:30:04 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k3FLSGb15334 for [e-mail]; Sat, 15 Apr 2006 22:28:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23228
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 14 Apr 2006 19:19:58 GMT
Lines: 28
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Alvestrand <[e-mail]> writes:

>Here is where I believe we stand at the moment.


>Are we done?

Bar minor niggles.

>3.2.14.  Injection-Info


>   The "posting-host" <parameter> specifies the FQDN and/or IP address
>   (IPv4address or IPv6address) of the host from which the news server
     ^^^^^^^^^^^^^^^^^^^^^^^^^^
    <IPv4address> or <IPv6address>
>   received the article.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3D4OltZ015044; Wed, 12 Apr 2006 21:24:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3D4Olep015043; Wed, 12 Apr 2006 21:24:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3D4Ok22015037 for <[e-mail]>; Wed, 12 Apr 2006 21:24:46 -0700 (MST) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k3D4OjGM029401 for <[e-mail]>; Wed, 12 Apr 2006 21:24:45 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id D6C0DE7911; Wed, 12 Apr 2006 21:24:44 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
In-Reply-To: <[e-mail]> (Harald Alvestrand's message of "Thu, 13 Apr 2006 06:22:42 +0200")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 12 Apr 2006 21:24:44 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Alvestrand <[e-mail]> writes:

> This looks good to me - there's one remaining occurence of "account" in
> the text outside the parameter name; once we replace that with "source"
> too, it's consistent:

>   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 administrator.  This notation can include any
>   information the administrator deems pertinent.  In order to limit the
>   exposure of personal data, it SHOULD be given in a form that can't be
>   interpreted by other sites.  However, to make it useful for rate
>   limiting and abuse detection, two messages posted from the same source
>   SHOULD have the same value of "posting-account", and two messages from
>   different sources SHOULD have differing values of "posting-account".
>   The exact definition of "source" is left to the discretion of the news
>   server administrator.

> I'll insert this version in the tracker.

> Are we done?

Works for me.  Thanks for catching the account that I missed!

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3D4MmvD014966; Wed, 12 Apr 2006 21:22:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3D4Mm2g014965; Wed, 12 Apr 2006 21:22:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3D4MlZY014959 for <[e-mail]>; Wed, 12 Apr 2006 21:22:47 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B109259773; Thu, 13 Apr 2006 06:22:29 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07452-03; Thu, 13 Apr 2006 06:22:25 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id C23DC259751; Thu, 13 Apr 2006 06:22:25 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 13 Apr 2006 06:22:42 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Russ Allbery <[e-mail]>
Cc: [e-mail]
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

>
> How about this:
>
>    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 administrator.  This notation can include any
>    information the administrator deems pertinent.  In order to limit the
>    exposure of personal data, it SHOULD be given in a form that can't be
>    interpreted by other sites.  However, to make it useful for rate
>    limiting and abuse detection, two messages posted from the same source
>    SHOULD have the same value of "posting-account", and two messages from
>    different accounts SHOULD have differing values of "posting-account".
>    The exact definition of source is left to the discretion of the news
>    server administrator.
>
> That also adds some explanation of why we care about matching up
> posting-account between different messages.
This looks good to me - there's one remaining occurence of "account" in 
the text outside the parameter name; once we replace that with "source" 
too, it's consistent:

   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 administrator.  This notation can include any
   information the administrator deems pertinent.  In order to limit the
   exposure of personal data, it SHOULD be given in a form that can't be
   interpreted by other sites.  However, to make it useful for rate
   limiting and abuse detection, two messages posted from the same source
   SHOULD have the same value of "posting-account", and two messages from
   different sources SHOULD have differing values of "posting-account".
   The exact definition of "source" is left to the discretion of the news
   server administrator.

I'll insert this version in the tracker.

Are we done?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3D02KCI097209; Wed, 12 Apr 2006 17:02:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3D02KtS097208; Wed, 12 Apr 2006 17:02:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3D02J4W097201 for <[e-mail]>; Wed, 12 Apr 2006 17:02:19 -0700 (MST) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k3D02GoO011375 for <[e-mail]>; Wed, 12 Apr 2006 17:02:16 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3A800E7911; Wed, 12 Apr 2006 17:02:16 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
In-Reply-To: <[e-mail]> (Harald Alvestrand's message of "Wed, 12 Apr 2006 19:20:20 +0200")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 12 Apr 2006 17:02:16 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Alvestrand <[e-mail]> writes:
> Russ Allbery wrote:
>> Harald Alvestrand <[e-mail]> writes:

>> Here's my worry on this:

>>>   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 administrator.  This notation can
>>>   include any information the administrator deems pertinent.  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", and two messages from different accounts SHOULD
>>>   have differing values of "posting-account".

>> What does "account" mean in the last sentence?  We have a SHOULD here,
>> so this isn't just an idle terminology question.  In order to produce a
>> fully complying implementation, an implementer is going to have to know
>> what account means in order to do the right thing.

> I think this may be a local matter - "whatever makes sense in the
> context of the sender"..... an university that uses authentication by IP
> address probably doesn't have something reasonable to use as "account",
> and so perhaps shouldn't use the field.... I find it hard to come up
> with a more precise definition. Suggestions?

How about this:

   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 administrator.  This notation can include any
   information the administrator deems pertinent.  In order to limit the
   exposure of personal data, it SHOULD be given in a form that can't be
   interpreted by other sites.  However, to make it useful for rate
   limiting and abuse detection, two messages posted from the same source
   SHOULD have the same value of "posting-account", and two messages from
   different accounts SHOULD have differing values of "posting-account".
   The exact definition of source is left to the discretion of the news
   server administrator.

That also adds some explanation of why we care about matching up
posting-account between different messages.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CHKRlj078837; Wed, 12 Apr 2006 10:20:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3CHKRVE078836; Wed, 12 Apr 2006 10:20:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3CHKQNn078830 for <[e-mail]>; Wed, 12 Apr 2006 10:20:26 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2F3D259766; Wed, 12 Apr 2006 19:20:08 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18033-07; Wed, 12 Apr 2006 19:20:03 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1431259761; Wed, 12 Apr 2006 19:20:03 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 12 Apr 2006 19:20:20 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Russ Allbery <[e-mail]>
Cc: [e-mail]
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery wrote:
> Harald Alvestrand <[e-mail]> writes:
>
>   
>> Here is where I believe we stand at the moment.
>>     
>
>   
>> I deleted the piece about authorized and authenticated identities; after
>> reviewing discussion, I believe that's not appropriate to discuss
>> here. Possibly in USEAGE.
>>     
>
>   
>> I added words to say that different accounts should have different
>> "posting-account" parameters too.
>>     
>
>   
>> Are we done?
>>     
>
> Here's my worry on this:
>
>   
>>   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 administrator.  This notation can
>>   include any information the administrator deems pertinent.  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", and
>>   two messages from different accounts SHOULD have differing values of
>>   "posting-account".
>>     
>
> What does "account" mean in the last sentence?  We have a SHOULD here, so
> this isn't just an idle terminology question.  In order to produce a fully
> complying implementation, an implementer is going to have to know what
> account means in order to do the right thing.
>   
I think this may be a local matter - "whatever makes sense in the 
context of the sender"..... an university that uses authentication by IP 
address probably doesn't have something reasonable to use as "account", 
and so perhaps shouldn't use the field.... I find it hard to come up 
with a more precise definition. Suggestions?
> Now, in practice, NNTP is going to (hopefully) move with the rest of the
> world towards SASL authentication.  That means that NNTP is going to hand
> the underlying server two pieces of data, namely the authentication
> identity and the authorization identity.  The authentication identity
> corresponds to the credentials presented by the client.  The authorization
> identity corresponds to the identity the client is acting as.  Often they
> will be the same; sometimes they will be different.
>
> An obvious Usenet-relevant example would be a posting account that's used
> by the moderators of example.research.  example.research has five
> different moderators, all of whom can approve articles.  Each moderator
> authenticates with their own credentials, and all moderators have access
> to a shared "example.research moderator" account on the server that's used
> for all of the posting.
>
> Should messages approved by these moderators all have the same
> posting-account parameter (meaning that the posting-account represents the
> authorization identity)?  Or should the posting-account parameter vary
> depending on which moderator initiates the posting (meaning that the
> posting-account represents the authentication identity)?
>
> Both are useful in different circumstances.
>   
in this particular use-case, I'd say that they are using different 
accounts - the only time I could think that the parameter would be 
useful is if someone is finding the moderation decisions inconsistent, 
and wants to check if one moderator is making the moderator approvals 
that he does not agree with (without caring who it actually is).
In a SASL context, that maps to the autentication identity. In other 
contexts, the item could have different names - would one represent this 
by a group name if authorizing in a pure UNIX context?
>   
>>   The "logging-data" <parameter> contains information (typically a
>>   session number or other non-persistent means of identifying a posting
>>   account) which will enable the true origin of the article to be
>>   determined by reference to logging information kept by the news
>>   server.
>>     
>
> I remain sad to see this go into the document, but the redundancy with
> message ID isn't sufficiently bad for me to raise a stink.  Consider me
> part of the rough in rough consensus, I guess.
>   
I don't have any great enthusiasm for reopening this issue either.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BNltxT037122; Tue, 11 Apr 2006 16:47:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3BNltjr037121; Tue, 11 Apr 2006 16:47:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BNls9V037114 for <[e-mail]>; Tue, 11 Apr 2006 16:47:54 -0700 (MST) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k3BNlr4f029255 for <[e-mail]>; Tue, 11 Apr 2006 16:47:53 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 06DCAE7911; Tue, 11 Apr 2006 16:47:53 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
In-Reply-To: <[e-mail]> (Harald Alvestrand's message of "Tue, 11 Apr 2006 15:03:58 +0200")
Organization: The Eyrie
References: <[e-mail]>
Date: Tue, 11 Apr 2006 16:47:52 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Alvestrand <[e-mail]> writes:

> Here is where I believe we stand at the moment.

> I deleted the piece about authorized and authenticated identities; after
> reviewing discussion, I believe that's not appropriate to discuss
> here. Possibly in USEAGE.

> I added words to say that different accounts should have different
> "posting-account" parameters too.

> Are we done?

Here's my worry on this:

>   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 administrator.  This notation can
>   include any information the administrator deems pertinent.  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", and
>   two messages from different accounts SHOULD have differing values of
>   "posting-account".

What does "account" mean in the last sentence?  We have a SHOULD here, so
this isn't just an idle terminology question.  In order to produce a fully
complying implementation, an implementer is going to have to know what
account means in order to do the right thing.

Now, in practice, NNTP is going to (hopefully) move with the rest of the
world towards SASL authentication.  That means that NNTP is going to hand
the underlying server two pieces of data, namely the authentication
identity and the authorization identity.  The authentication identity
corresponds to the credentials presented by the client.  The authorization
identity corresponds to the identity the client is acting as.  Often they
will be the same; sometimes they will be different.

An obvious Usenet-relevant example would be a posting account that's used
by the moderators of example.research.  example.research has five
different moderators, all of whom can approve articles.  Each moderator
authenticates with their own credentials, and all moderators have access
to a shared "example.research moderator" account on the server that's used
for all of the posting.

Should messages approved by these moderators all have the same
posting-account parameter (meaning that the posting-account represents the
authorization identity)?  Or should the posting-account parameter vary
depending on which moderator initiates the posting (meaning that the
posting-account represents the authentication identity)?

Both are useful in different circumstances.

>   The "logging-data" <parameter> contains information (typically a
>   session number or other non-persistent means of identifying a posting
>   account) which will enable the true origin of the article to be
>   determined by reference to logging information kept by the news
>   server.

I remain sad to see this go into the document, but the redundancy with
message ID isn't sufficiently bad for me to raise a stink.  Consider me
part of the rough in rough consensus, I guess.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BD44Ar009141; Tue, 11 Apr 2006 06:04:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3BD44sR009140; Tue, 11 Apr 2006 06:04:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BD43x0009134 for <[e-mail]>; Tue, 11 Apr 2006 06:04:03 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B14AF259762 for <[e-mail]>; Tue, 11 Apr 2006 15:03:46 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01485-05 for <[e-mail]>; Tue, 11 Apr 2006 15:03:42 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9FCD0259761 for <[e-mail]>; Tue, 11 Apr 2006 15:03:42 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 11 Apr 2006 15:03:58 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: #1159: USEFOR 3.2.14: Resolution of sender / posting-account
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Here is where I believe we stand at the moment.

I deleted the piece about authorized and authenticated identities; after 
reviewing discussion, I believe that's not appropriate to discuss here. 
Possibly in USEAGE.
I added words to say that different accounts should have different 
"posting-account" parameters too.

Are we done?

3.2.14.  Injection-Info

   The Injection-Info header field contains information provided by the
   injecting news server as to how an article entered the Netnews system
   and to assist in tracing its true origin.  It can also specify one or
   more addresses where complaints concerning the poster of the article
   may be sent.

   injection-info  =  "Injection-Info:" SP [CFWS] path-identity
                      [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF

      NOTE: The syntax of <parameter> ([RFC2045] as amended by
      [RFC2231]), taken in conjunction with the folding rules of
      [RFC0822], effectively allows [CFWS] to occur on either side of
      the "=" inside a <parameter>.

   The following table gives the <attribute> and the format of the
   <value> for each <parameter> defined for use with this header field.
   At most one occurrence of each such <parameter> is allowed.

   <attribute>              format of <value>
   --------------------     -----------------
   "posting-host"           a <host-value>
   "posting-account"        any <value>
   "logging-data"           any <value>
   "mail-complaints-to"     an <address-list>

   where

   host-value      =  dot-atom-text / IPv4address / IPv6address /
                      (dot-atom-text ":" ( IPv4address / IPv6address ))

      NOTE: Since any such <host-value> or <address-
      list> has also to be a syntactically correct <value>, it will
      usually be necessary to encapsulate it as a <quoted-string>, for
      example:

   posting-host = "[e-mail]:192.168.0.1"

   Additionally, any other <parameter> whose <attribute> starts with
   "x-" MAY be used where the defined ones appear to be unsuitable, but
   other unlisted <parameter>s SHOULD NOT be used unless defined in
   extensions to this standard.

   Although comments and folding of white space are permitted throughout
   the Injection-Info header field, it is RECOMMENDED that folding is
   not used within any <parameter> (but only before or after the ";"
   separating those <parameter>s), and that comments are only used
   following the last <parameter>.

      NOTE: Some of this information has previously been sent in non-
      standardized header fields such as NNTP-Posting-Host, X-trace,
      X-Complaints-To, and others.  Once a news server uses Injection-
      Info, it should have no need to send these non-standard header
      fields.

   The "posting-host" <parameter> specifies the FQDN and/or IP address
   (IPv4address or IPv6address) of the host from which the news server
   received the article.

      NOTE: If the "posting-host" <parameter> identifies a dial-up
      point-of-presence, the "posting-account" or the "logging-data"
      <parameter> may provide additional information about the true
      origin of the article.

   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 administrator.  This notation can
   include any information the administrator deems pertinent.  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", and two messages from different accounts SHOULD have
   differing values of "posting-account".


   The "logging-data" <parameter> contains information (typically a
   session number or other non-persistent means of identifying a posting
   account) which will enable the true origin of the article to be
   determined by reference to logging information kept by the news
   server.

   The "mail-complaints-to" <parameter> specifies mailbox(es) for
   sending complaints concerning the behavior of the poster of the
   article.

   It is a matter of local policy which <parameter>s to include.
   Some pieces of information have privacy implications; this is
   discussed in [USEAGE].



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BCpxm5008753; Tue, 11 Apr 2006 05:51:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3BCpxpP008752; Tue, 11 Apr 2006 05:51:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BCpvdH008746 for <[e-mail]>; Tue, 11 Apr 2006 05:51:58 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E7398259762 for <[e-mail]>; Tue, 11 Apr 2006 14:51:40 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32531-06 for <[e-mail]>; Tue, 11 Apr 2006 14:51:37 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DCC5259761 for <[e-mail]>; Tue, 11 Apr 2006 14:51:37 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 11 Apr 2006 14:51:52 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: #1047 Path header - proposed resolution
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

reviewing the thread, here is what I think we have for section 3.1.6.

I have incorporated some of Charles' comments from March 16, but not 
all. Of particular note is that I added the [FWS] he asked for, which 
allows the header to be folded before any ! except the one that
is part of the "diag-match".

I also reformatted the IPv6 warning into a "NOTE".

Are we done with this now?

==============================================================

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 at least one <path-identity> to this
   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] "!" )

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

diag-match = "!" ; another "!"

diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]

diag-deprecated = "!" IPv4address [FWS]

diag-keyword = 1*ALPHA ; see USEPRO

diag-identity = path-identity / IPv4address / IPv6address

tail-entry = path-nodot
   ; may be the string "not-for-mail"

path-identity = ( 1*( label "." ) toplabel ) / path-nodot

path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names

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 two or more components separated by dots,
   or a single name with no dots (<path-nodot>).

   Each <path-identity> in the <path-list> (which does not include  the
   <tail-entry>) indicates, from right to left, the successive agents
   through which the article has passed.   The use
   of the <diag-match>, which appears as "!!", 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).

      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 should be in upper case, to
      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. The use of these 
is described
   in [USEPRO].

      NOTE: One usage of a path-diagnostic is to record an IP address.
     The fact that IPv6 addresses
     are allowed means that the colon (:) is permitted; 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BBjZm2005954; Tue, 11 Apr 2006 04:45:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3BBjZqC005953; Tue, 11 Apr 2006 04:45:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3BBjXhL005947 for <[e-mail]>; Tue, 11 Apr 2006 04:45:34 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DFB625970A for <[e-mail]>; Tue, 11 Apr 2006 13:45:17 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26726-02 for <[e-mail]>; Tue, 11 Apr 2006 13:45:13 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF5A02596EF for <[e-mail]>; Tue, 11 Apr 2006 13:45:13 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 11 Apr 2006 13:45:29 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Ticket status, April 11
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Now the IETF is over, and we should beat the last pieces into the ground....

Open tickets on USEFOR, which need resolution before -08:

1047 USEFOR 3.1.6: Path field delimiters and components

   Keywords go to USEPRO. I will suggest text.

1156 USEFOR Appendix: IANA registration form for headers.

  No comments since -07. Closing ticket.

1159 USEFOR 3.2.14: Advice on sender vs posting-account

  "Sender" is gone. "Posting-account" is kept. I will suggest text.

1178 USEFOR 3.1.6: Whitespace in headers with newsgroup names

  I have not suggested text. Will do.

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

  Charles suggests a further clarification of its NOTE. I'll suggest a 
resolution.

With that, -08 seems near. I'll send out a WG Last Call on -08.

                     Harald



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k33BDjKg040809; Mon, 3 Apr 2006 04:13:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k33BDjZh040808; Mon, 3 Apr 2006 04:13:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from th-mail-b0114.gradwell.net (th-mail-b0114.gradwell.net [193.111.201.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k33BDfd0040802 for <[e-mail]>; Mon, 3 Apr 2006 04:13:44 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-66-194.midband.mdip.bt.net ([81.144.66.194]) by th-mail-b0114.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44310362.6f43.9b for [e-mail]; Mon,  3 Apr 2006 12:13:38 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id k33BCF727058 for [e-mail]; Mon, 3 Apr 2006 12:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23214
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Imroved <toplabel> idea (was: RFC 4408 <draft-schlitt-spf-classic-02.txt> -- AUTH48 changes)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 3 Apr 2006 10:08:10 GMT
Lines: 32
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>(About the <toplabel> thread in SPF-discuss)  Wait a moment...

>>>> toplabel =
>>>>       ( *alphanum alpha *alphanum ) /
>>>>       ( 1*alphanum "-" *( alphanum / "-" ) alphanum )

>...it's simple to add the "no single alpha" case to this beast:

What's the point? It resolves no ambiguities/whatever for our use. Is
there some rule somewhere disallowing single alphas at TLDs in the DNS? It
is really not our job to define the rules for domain names. There is
already enough confusion out there already without us adding to it.

I grant you that your syntax is neat and does the job, but it is really
someone else's job to fix it.

>| toplabel =
>|       ( alpha 1*alphanum ) / ( 1*digit alpha *alphanum ) /
>|       ( 1*alphanum "-" *( alphanum / "-" ) alphanum )

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3201Ysb055040; Sat, 1 Apr 2006 17:01:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3201YTW055039; Sat, 1 Apr 2006 17:01:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3201U27055032 for <[e-mail]>; Sat, 1 Apr 2006 17:01:33 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FPq24-0004mg-Na for [e-mail]; Sun, 02 Apr 2006 02:01:28 +0200
Received: from o1647.o.pppool.de ([89.51.22.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 02 Apr 2006 02:01:28 +0200
Received: from nobody by o1647.o.pppool.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 02 Apr 2006 02:01:28 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Imroved <toplabel> idea (was: RFC 4408 <draft-schlitt-spf-classic-02.txt> -- AUTH48 changes)
Date:  Sun, 02 Apr 2006 01:33:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: o1647.o.pppool.de
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

(About the <toplabel> thread in SPF-discuss)  Wait a moment...

>>> toplabel =
>>>       ( *alphanum alpha *alphanum ) /
>>>       ( 1*alphanum "-" *( alphanum / "-" ) alphanum )

...it's simple to add the "no single alpha" case to this beast:

| toplabel =
|       ( alpha 1*alphanum ) / ( 1*digit alpha *alphanum ) /
|       ( 1*alphanum "-" *( alphanum / "-" ) alphanum )

I'll propose that for USEFOR, it's clearer than the convoluted
syntax based on <label>.  It's also unambiguous for a parser -
credits to Matthew.van.Eerde, copy to USEFOR.

                              Bye, Frank