#1300 was Admin: Resolution of WG

[[e-mail]]

>| A newsgroup may be "moderated", in which case submissions
>| are not posted directly, but mailed to a "moderator" for
>| consideration and possible posting. Moderators are
>| typically human but may be implemented partially or
>| entirely in software.

>The word "moderated" occurs only once,
>in the "Approved" section.

Moderators are ALWAYS human.

Suggested replacement text:

A newsgroup may be "moderated". Articles are not posted directly to a 
moderated group, but are submitted (usually by email) to one or more 
moderators for approval and eventual posting. Some moderators have 
implemented automated systems to help them perform this function.





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 k5UHQr3s064131; Fri, 30 Jun 2006 10:26:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5UHQr1Q064130; Fri, 30 Jun 2006 10:26:53 -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 k5UHQqGH064105 for <[e-mail]>; Fri, 30 Jun 2006 10:26:52 -0700 (MST) (envelope-from [e-mail])
Received: from shell.peak.org (shell.peak.org [127.0.0.1]) by shell.peak.org (8.13.1/8.13.1) with ESMTP id k5UGQjwU007419 for <[e-mail]>; Fri, 30 Jun 2006 09:26:45 -0700
Received: from localhost (stanley@localhost) by shell.peak.org (8.13.1/8.13.1/Submit) with ESMTP id k5UGQiXn007416 for <[e-mail]>; Fri, 30 Jun 2006 09:26:45 -0700
X-Authentication-Warning: shell.peak.org: stanley owned process doing -bs
Date: Fri, 30 Jun 2006 09:26:44 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Subject: #1300 was Admin: Resolution of WG
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>

>| A newsgroup may be "moderated", in which case submissions
>| are not posted directly, but mailed to a "moderator" for
>| consideration and possible posting. Moderators are
>| typically human but may be implemented partially or
>| entirely in software.

>The word "moderated" occurs only once,
>in the "Approved" section.

Moderators are ALWAYS human.

Suggested replacement text:

A newsgroup may be "moderated". Articles are not posted directly to a 
moderated group, but are submitted (usually by email) to one or more 
moderators for approval and eventual posting. Some moderators have 
implemented automated systems to help them perform this function.



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 k5REHXV5099664; Tue, 27 Jun 2006 07:17:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5REHXuY099663; Tue, 27 Jun 2006 07:17:33 -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 k5REHW4a099657 for <[e-mail]>; Tue, 27 Jun 2006 07:17:33 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E1002596E5 for <[e-mail]>; Tue, 27 Jun 2006 16:16:19 +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 03318-04 for <[e-mail]>; Tue, 27 Jun 2006 16:16:13 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB3592580CD for <[e-mail]>; Tue, 27 Jun 2006 16:16:13 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 27 Jun 2006 07:17:25 -0700
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: [e-mail]
Subject: Admin: Resolution of WG Last Call comments
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>

At the moment, we have 5 open tickets on USEFOR:
#1298, #1299, #1300, #1305 and #1306.
I believe the substantive parts of #1298 are captured by #1305 and 
#1306, so when these are resolved, #1298 will also be resolved, with the 
editor taking editorial fixes according to editorial judgment.

The publication window before the IETF meeting has closed, so the next 
version of the draft cannot be emitted until mid-July (at which time I'm 
on holiday).

So - if we can resolve the outstanding issues, and get -09 issued, I'll 
issue a poll for resolution in late July with the following 
alternatives, based on practice with successful WG Last Calls and the 
sentiments raised at Last Call:

A - The specification has resolved all the issued raised at Last Call. 
It is ready to be sent to the IESG.

B - The specification has not resolved an issue raised at Last Call. 
It's critical that this should be resolved before passing it to the 
IESG. The issue number is #......

C - The specification has a fatal technical error, not raised at Last 
Call, and it is critical that this should be resolved before passing it 
to the IESG.

D - This effort is futile, we should abandon the document and close the WG.

Note that there is NO option of "I have a few remaining niggles". That's 
the purpose of the Last Call: To get *all* the remaining issues on the 
table. We can niggle documents forever if we want to; this is closure time.

Based on the results from the Last Call, I'm removing the option of 
putting the document on hold while waiting for USEPRO to complete.

Comments?

                       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 k5PKtlnb023611; Sun, 25 Jun 2006 13:55:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5PKtloM023610; Sun, 25 Jun 2006 13:55:47 -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 k5PKtk3X023604 for <[e-mail]>; Sun, 25 Jun 2006 13:55: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 CCC022596C5; Sun, 25 Jun 2006 22:54:34 +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 29733-05; Sun, 25 Jun 2006 22: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 73FF22596C1; Sun, 25 Jun 2006 22:54:31 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 25 Jun 2006 22:55:37 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Richard Clayton <[e-mail]>
Cc: [e-mail]
Subject: Re: #1299 Richard Clayton's comments
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>

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE----
>> That of whether or not we need to add definitions for the words 
>> "generate" and "inject", or his long list:
>>     
>
> The list was intended to indicate what a mess it currently was.
>
> I think it would be better to try and only use the words that have been
> defined...  and the simplest way of doing this is to stop using
> different words for identical things. I am NOT in favour of adding 25
> extra definitions just to make a few sentences flow better.
> Only allowing the use of defined words should properly concentrate
> peoples minds on the exactness of those definitions, which need to be
> clear about what changes are made as the article is moved from one state
> to another.  It's whether or not things can be expected to be changed
> that I found unclear.
>
> If the specification of that changing is in another document then the
> few mentions of changes and proto-articles and stuff that are in this
> document should be removed.
>   
I'm sympathetic to the idea of using fewer words. However, we have 
settled on using a rather free-form specification lanugage called 
"English", which means that we generally use many, many words that do 
not have definitions anywhere near the document.

I picked on "generate" and "inject" because "generate" has been worried 
about before, while "inject" may be a synonym for something else that we 
have defined.

I'm not sure how much value there is to hunting through the document for 
*all* the terms where a defined word can be used instead of the word 
currently used.

                    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 k5MG5909077988; Thu, 22 Jun 2006 09:05:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MG59bg077987; Thu, 22 Jun 2006 09:05:09 -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.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MG587k077980 for <[e-mail]>; Thu, 22 Jun 2006 09:05:09 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 87DB64BFF6 for <[e-mail]>; Thu, 22 Jun 2006 09:05:08 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 9B8074CA0F for <[e-mail]>; Thu, 22 Jun 2006 09:04:59 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8FCC6E78C2; Thu, 22 Jun 2006 09:04:59 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1299 Richard Clayton's comments
In-Reply-To: <[e-mail]> (Richard Clayton's message of "Thu, 22 Jun 2006 15:21:12 +0100")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]>
Date: Thu, 22 Jun 2006 09:04:59 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (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>

Richard Clayton <[e-mail]> writes:

> I'd draw attention to my comment on User-Agent. I suggested removing all
> the fancy ABNF and leaving it as free form text (because that's the way
> the world is when you're advertising your products). Charles did say it
> had been copied from HTTP ... but there people (as opposed to machines)
> don't see it -- so the incentives are very different.

User-Agent has already been fairly successfully deployed in the wild and
the uses of it that I've seen actually follow the specification, or at
least are within the typical degree of varience.  Given that, I think we
should keep the tight specification; it doesn't seem widely disobeyed in
practice, and there's no reason to throw away the parsability when it's
not causing a problem IMO.

> I think it would be better to try and only use the words that have been
> defined...  and the simplest way of doing this is to stop using
> different words for identical things. I am NOT in favour of adding 25
> extra definitions just to make a few sentences flow better.

I generally agree with the thought; I'm just not sure the rewrite effort
is worth it.

> Only allowing the use of defined words should properly concentrate
> peoples minds on the exactness of those definitions, which need to be
> clear about what changes are made as the article is moved from one state
> to another.  It's whether or not things can be expected to be changed
> that I found unclear.

> If the specification of that changing is in another document then the
> few mentions of changes and proto-articles and stuff that are in this
> document should be removed.

The split between the documents is certainly tricky.  It has the definite
advantage of keeping the format specification (which is what people are
going to refer to the most) far simpler and more straightforward, but it
means that the format specification really doesn't describe the *process*
of posting a Usenet article (since we can't get into that without dragging
in all of the other machinery).

-- 
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 k5MFTBTX068870; Thu, 22 Jun 2006 08:29:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MFTBie068869; Thu, 22 Jun 2006 08:29:11 -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-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MFT9Ap068857 for <[e-mail]>; Thu, 22 Jun 2006 08:29:10 -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-31.mail.demon.net with esmtp (Exim 4.42) id 1FtQmk-000JSt-3s; Thu, 22 Jun 2006 15:07:58 +0000
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 15:21:12 +0100
To: Harald Alvestrand <[e-mail]>
Cc: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: #1299 Richard Clayton's comments
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <r69$+$1H77$fiNKLYyZ+d+mmfU>
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]>, Harald Alvestrand
<[e-mail]> writes
>
>In reviewing Richard Clayton's comments, I find only one substantive 
>issue: 

I'd draw attention to my comment on User-Agent. I suggested removing all
the fancy ABNF and leaving it as free form text (because that's the way
the world is when you're advertising your products). Charles did say it
had been copied from HTTP ... but there people (as opposed to machines)
don't see it -- so the incentives are very different.

>That of whether or not we need to add definitions for the words 
>"generate" and "inject", or his long list:

The list was intended to indicate what a mess it currently was.

I think it would be better to try and only use the words that have been
defined...  and the simplest way of doing this is to stop using
different words for identical things. I am NOT in favour of adding 25
extra definitions just to make a few sentences flow better.

Only allowing the use of defined words should properly concentrate
peoples minds on the exactness of those definitions, which need to be
clear about what changes are made as the article is moved from one state
to another.  It's whether or not things can be expected to be changed
that I found unclear.

If the specification of that changing is in another document then the
few mentions of changes and proto-articles and stuff that are in this
document should be removed.

- -- 
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/AwUBRJqnWJoAxkTY1oPiEQLgAQCgtig+qn2hz9YmN2PSYHe0cJZoxVEAn19w
WE1j8Z44jfxnAWU6+2vTAS3Y
=j8ac
-----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 k5MDpP65045359; Thu, 22 Jun 2006 06:51:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MDpPkQ045358; Thu, 22 Jun 2006 06:51:25 -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 k5MDpO6n045348 for <[e-mail]>; Thu, 22 Jun 2006 06:51:25 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 652882596C0 for <[e-mail]>; Thu, 22 Jun 2006 15:50:15 +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 28289-02 for <[e-mail]>; Thu, 22 Jun 2006 15:50:12 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECC6F2596BF for <[e-mail]>; Thu, 22 Jun 2006 15:50:11 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 06:51:20 -0700
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: [e-mail]
Subject: #1299 Richard Clayton's comments
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>

In reviewing Richard Clayton's comments, I find only one substantive 
issue: That of whether or not we need to add definitions for the words 
"generate" and "inject", or his long list:

        generate

        inject

        posted to

        accept

        moderate

        supplied

        passing on

        make available to

        exchange with

        submit

        create

        process

        send to

        mailed

        expired

        relay

        filed

        enter

I suggest that if we need it, we add to 1.5:

Generate: An agent is said to "generate" an article or a header if it did not exist before the agent generated it. Examples are when an user agent generates a message from text and addressing information supplied by an user, or when a news server generates an "Injection-Info" header for a newly posted message.

Most of the other words have distinct meanings, I think; "posted to" is mentioned under the definition of "newsgroup" - this could be broken out as a more visible definition, since it's a pretty important concept.

Is it reasonable to replace all occurences of "injection" with "posting"? Or should we define "injection" as a synonym for "posting"?

                           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 k5MA3UKo095223; Thu, 22 Jun 2006 03:03:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MA3Ux8095222; Thu, 22 Jun 2006 03:03:30 -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 k5MA3SZc095204 for <[e-mail]>; Thu, 22 Jun 2006 03:03:29 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADC532596BC; Thu, 22 Jun 2006 12:02: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 18164-02; Thu, 22 Jun 2006 12:02:11 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0384C2596B8; Thu, 22 Jun 2006 12:02:10 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 03:03:19 -0700
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: #1298 -> 1305, 1306 + rejections and calls for comment (Re: Issue #1298 - Charles' niggles)
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>

I've gone through your list of "remaining issues" and created tickets 
for those that I think may warrant further tracking. For those where I 
don't think they warrant further tracking, I've given the reason below.

Comments from the WG welcome - if you want to address the two identified 
issues, please use that ticket number in the subject; if you want to 
comment on what's left here, use #1298 in the subject.

Thank you!

                     Harald

Charles Lindsey wrote:
> In <[e-mail]> Harald Alvestrand <[e-mail]> writes:
>
>
>   
>> C - I believe issues must be fixed; the following issue has not been
>> raised so far: .....................
>>     
>
>   
>>  Charles Lindsey - #1298 (although he believes that he can survive
>> without fixing the issues)
>>     
>
> I see that Harald has reproduced the whole of my list, although Ken had
> already agreed to incorporate all my minor corrections in the draft, so I
> has presumed they were non-controversial and accepted.
>
> So to confine discussion to the ones that Ken did not feel able to accept
> without further guidance, I have reproduced below the ones that are still
> outstanding, together with further comments (including some quotes from
> various subsequent messages).
>
> I have labelled my sub-issues as #1298.A, B, C, D, E and F, for
> convenience of reference. The ones I am most concerned about are A and B.
> C and E fix problems (bugs?) inadvertently introduced by Dan Kohn's
> revisions. The rest are relatively minor, and none of them is a matter of
> Life and Death.
>
>
> Issue 1298.A
> ------------
>
>   
>> 3.1.5.  Newsgroups
>>
>>    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.
>>
>> No, that paragraph gives entirely the wrong impression, and I have
>> repeatedly asked for it to be changed. What is wanted is something like:
>>
>>    Current practice does [OR the current standards do] not allow [FWS] in
>>    the list of newsgroups and thus it (and particularly folding) would
>>    harm propagation significantly. Therefore, [FWS] in the
>>    <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
>>
>> Eventually I hope (for some value of "eventually") it will be allowed
>> freely (since it is a confounded nuisance and current MUAs either do not
>> display the whole line, or display it folded in inappropriate manners).
>> But, for now, "SHOULD NOT be generated" is correct.
>>     
>
> To which ALexey replied:
>
>   
>>> Personally I don't think that the suggested text is an improvement over 
>>> existing one.
>>>       
>
> And I replied to him:
>
>   
>> My problem with the existing one is that it gives the impression that
>> someone has tried an experiment to see if these things propagated, found
>> that they didn't, and concluded that existing servers were therefore
>> deficient.
>>
>> This is not so. I doubt anyone has actually tried because it was well
>> known that the code of INN, CNews, etc just did not support the feature,
>> because RFC 1036 allowed neither whitespace nor folding in there.
>> Son-of-1036 did not require it either (though it did give a warning that
>> this was likely to change someday and suggested allowing it).
>>
>> The [FWS] here is a new feature we have introduced ("someday" has
>> arrived), as is clear from Appendix B. So why can't we have a wording that
>> makes the true sutuation clear?
>>
>> Now that I want to make too big an issue of this, because we could get by
>> with the present wording is that's what the WG wants.
>>     
As I said on the list, you performed the experiment yourself a year ago.
I won't reopen #1042. Rejected.

>
>
> Issue 1298.B
> ------------
>
>   
>> 3.1.6.  Path
>>
>> We still need some explanation for the presence of <diag-deprecated>. In
>> response to your request, I proposed the folowing NOTE:
>>
>>       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>).
>>     
>
>   
This is already a NOTE-rich paragraph, and I don't see any big harm in 
adding another.

I've made this ticket #1305.
> Issue 1298.C
> ------------
>
>   
>> 3.2.1.  Injection-Date
>>
>>       NOTE: Since clocks on various agents may not be synchronized, 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 header field.
>>
>> Also, I think, s/SHOULD/MUST/. There is one obscure situation (see USEPRO
>> 7.8) where a moderator may rewrite the Date, but then I don't think a
>> moderator is an "agent" as we have defined the term.
>>     
>
> I had some private email from Alexey on this, asking:
>
>   
>>> Clarifying question: are you talking about the first SHOULD, the second 
>>> (SHOULD NOT) or both?
>>>       
>
> To which I replied
>  
>   
>> I think it is the second (SHOULD NOT). It is not the end of the world if the 
>> injecting agent puts a slightly wrong date-time there (though he "SHOULD" get 
>> it right), but our drafts have always made it clear that altering what the 
>> poster has written is always a MUST NOT (with only some very obscure 
>> exceptions, like the moderator who sits on it for too long as in USEPRO 7.8).
>>
>> This was one of Dan Kohn's rewrites, and I don't think we spotted the anomaly 
>> he had introduced. Mind you, it is only a NOTE.
>>     
The 07 version of the NOTE was:

     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.

I think the 08 version is a lot clearer in what it says, but introduces 
protocol requirements where -07 was clearly just commentary.

I've made this ticket #1306.
>  
>
> Issue 1298.D
> ------------
>
>   
>> 3.2.14.  Injection-Info
>>
>> But also, with the demise of the sender <paramter> we have lost that "Joe
>> Q. Public" example, which is a pity. How about:
>>
>>       mail-complaints-to=
>>         "\"Re: msg <[e-mail]>\" <[e-mail]>"
>>
>>
>>     
Grumble. Making the examples as complex as possible doesn't seem like a 
big benefit to me.
Anyone else who likes this?

> Issue 1298.E
> ------------
>
>   
>> 3.2.14.  Injection-Info
>>
>>    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-".
>>
>> That MUST conflicts with the SHOULD. How about:
>>
>>    Other <attribute>s MUST NOT be used unless defined in extensions to
>>    this standard, or unless they begin with an "x-".
>>     
>
> That was another Dan Kohn change which introduced an anomaly that we
> didn't spot at the time.
>   
I don't see the conflict. SHOULD NOT, and if you violate the SHOULD NOT, 
you MUST do this.

I don't see that the new text is clearer. Does anyone else like this?
>
> Issue 1298.F
> ------------
>
>   
>> 3.3.  Obsolete Header Fields
>>
>> The text which follows is copied verbatim from Son-of-1036. Assuming
>> Son-of-1036 is to be republished an an information/historic RFC, ths could
>>     
>  
> Is there any chance of this happening?  Has any work been done on it?
>   
No reply....
>  
>   
>> be shortened (I have removed all the long verbatim extracts from
>> Son-of-1036 from USEPRO).
>>
>> So I would suggest omitting the two paragraphs starting with:
>>
>>    Relay-Version contained ...
>> and
>>    Also-Control indicated ...
>>
>> and replacing them with a pointer to Son-of-1036 for further details of
>> what these headers formerly signified. ALso, the two sentences about "for
>> hsitorical purposes" could probably be combined.
>>     
>
> Ralph Babel also mentioned this (but wanted to omit more).
>
> I think we should proceed on the assumption that Henry Spencer will indeed
> fulfil his promise to republish Son-of-1036 as an informational/historic
> RFC, and hence we should not include any large quotes from s-o-1036 (I
> havge already removed all such large quotes from USEPRO).
>
> We might have to beat him about the head during the RFC Editor phase, but
> his willingness to do the job has never been in doubt and it is merely a
> matter of obtaining sufficient Round Tuits.
>   
Introducing a dependency on son-of-1036 at this time would be extremely 
unwise, in my opinion; the harm in including these two paragraphs is 
minimal.

Unless someone else speaks up in favour of this, I'll declare that this 
won't happen.
>
>
> Issue 1298.G
> ------------
>
>  6.  IANA Considerations
>   
>>       Header field name: User-Agent
>>       Applicable protocol: netnews
>>       Status: standard
>>       Author/change controller: IETF
>>       Specification document(s): This document (Section 3.2.13)
>>
>> I would like to add
>>       Applicable protocol: email
>>
>> That is technically outside our charter, but was always intended and
>> should be non-controversial. Could we ask the IESG for permission to do
>> that?`
>>     
>
> Well that is a pretty long shot, so I am not really expecting it to get
> anywhere. WHen we are all done, I might introduce an I.D. to make this
> header the official version of User-Agent in email too, just to get it
> recorded in the IANA registry.
>
>   

You're right. #1078 is closed, and will remain so.



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 k5GIDQE1048130; Fri, 16 Jun 2006 11:13:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GIDQ6O048129; Fri, 16 Jun 2006 11:13:26 -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 k5GIDOwh048114 for <[e-mail]>; Fri, 16 Jun 2006 11:13:25 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-65-135.midband.mdip.bt.net ([81.144.65.135] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 4492f4c2.b42e.7cf for [e-mail]; Fri, 16 Jun 2006 19:13:22 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5GI4GK18940 for [e-mail]; Fri, 16 Jun 2006 19:04:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23324
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Issue #1298 - Charles' niggles
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 16 Jun 2006 17:09:47 GMT
Lines: 219
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:


>C - I believe issues must be fixed; the following issue has not been
>raised so far: .....................

>  Charles Lindsey - #1298 (although he believes that he can survive
>without fixing the issues)

I see that Harald has reproduced the whole of my list, although Ken had
already agreed to incorporate all my minor corrections in the draft, so I
has presumed they were non-controversial and accepted.

So to confine discussion to the ones that Ken did not feel able to accept
without further guidance, I have reproduced below the ones that are still
outstanding, together with further comments (including some quotes from
various subsequent messages).

I have labelled my sub-issues as #1298.A, B, C, D, E and F, for
convenience of reference. The ones I am most concerned about are A and B.
C and E fix problems (bugs?) inadvertently introduced by Dan Kohn's
revisions. The rest are relatively minor, and none of them is a matter of
Life and Death.


Issue 1298.A
------------

> 3.1.5.  Newsgroups
> 
>    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.
> 
> No, that paragraph gives entirely the wrong impression, and I have
> repeatedly asked for it to be changed. What is wanted is something like:
> 
>    Current practice does [OR the current standards do] not allow [FWS] in
>    the list of newsgroups and thus it (and particularly folding) would
>    harm propagation significantly. Therefore, [FWS] in the
>    <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
> 
> Eventually I hope (for some value of "eventually") it will be allowed
> freely (since it is a confounded nuisance and current MUAs either do not
> display the whole line, or display it folded in inappropriate manners).
> But, for now, "SHOULD NOT be generated" is correct.

To which ALexey replied:

>>Personally I don't think that the suggested text is an improvement over 
>>existing one.

And I replied to him:

>My problem with the existing one is that it gives the impression that
>someone has tried an experiment to see if these things propagated, found
>that they didn't, and concluded that existing servers were therefore
>deficient.
> 
>This is not so. I doubt anyone has actually tried because it was well
>known that the code of INN, CNews, etc just did not support the feature,
>because RFC 1036 allowed neither whitespace nor folding in there.
>Son-of-1036 did not require it either (though it did give a warning that
>this was likely to change someday and suggested allowing it).
> 
>The [FWS] here is a new feature we have introduced ("someday" has
>arrived), as is clear from Appendix B. So why can't we have a wording that
>makes the true sutuation clear?
> 
>Now that I want to make too big an issue of this, because we could get by
>with the present wording is that's what the WG wants.


Issue 1298.B
------------

> 3.1.6.  Path
> 
> We still need some explanation for the presence of <diag-deprecated>. In
> response to your request, I proposed the folowing NOTE:
> 
>       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>).


Issue 1298.C
------------

> 3.2.1.  Injection-Date
> 
>       NOTE: Since clocks on various agents may not be synchronized, 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 header field.
> 
> Also, I think, s/SHOULD/MUST/. There is one obscure situation (see USEPRO
> 7.8) where a moderator may rewrite the Date, but then I don't think a
> moderator is an "agent" as we have defined the term.

I had some private email from Alexey on this, asking:

>>Clarifying question: are you talking about the first SHOULD, the second 
>>(SHOULD NOT) or both?

To which I replied
 
>I think it is the second (SHOULD NOT). It is not the end of the world if the 
>injecting agent puts a slightly wrong date-time there (though he "SHOULD" get 
>it right), but our drafts have always made it clear that altering what the 
>poster has written is always a MUST NOT (with only some very obscure 
>exceptions, like the moderator who sits on it for too long as in USEPRO 7.8).
> 
>This was one of Dan Kohn's rewrites, and I don't think we spotted the anomaly 
>he had introduced. Mind you, it is only a NOTE.
 

Issue 1298.D
------------

> 3.2.14.  Injection-Info
> 
> But also, with the demise of the sender <paramter> we have lost that "Joe
> Q. Public" example, which is a pity. How about:
> 
>       mail-complaints-to=
>         "\"Re: msg <[e-mail]>\" <[e-mail]>"
> 
> 
Issue 1298.E
------------

> 3.2.14.  Injection-Info
> 
>    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-".
> 
> That MUST conflicts with the SHOULD. How about:
> 
>    Other <attribute>s MUST NOT be used unless defined in extensions to
>    this standard, or unless they begin with an "x-".

That was another Dan Kohn change which introduced an anomaly that we
didn't spot at the time.


Issue 1298.F
------------

> 3.3.  Obsolete Header Fields
> 
> The text which follows is copied verbatim from Son-of-1036. Assuming
> Son-of-1036 is to be republished an an information/historic RFC, ths could
 
Is there any chance of this happening?  Has any work been done on it?
 
> be shortened (I have removed all the long verbatim extracts from
> Son-of-1036 from USEPRO).
> 
> So I would suggest omitting the two paragraphs starting with:
> 
>    Relay-Version contained ...
> and
>    Also-Control indicated ...
> 
> and replacing them with a pointer to Son-of-1036 for further details of
> what these headers formerly signified. ALso, the two sentences about "for
> hsitorical purposes" could probably be combined.

Ralph Babel also mentioned this (but wanted to omit more).

I think we should proceed on the assumption that Henry Spencer will indeed
fulfil his promise to republish Son-of-1036 as an informational/historic
RFC, and hence we should not include any large quotes from s-o-1036 (I
havge already removed all such large quotes from USEPRO).

We might have to beat him about the head during the RFC Editor phase, but
his willingness to do the job has never been in doubt and it is merely a
matter of obtaining sufficient Round Tuits.



Issue 1298.G
------------

 6.  IANA Considerations
> 
>       Header field name: User-Agent
>       Applicable protocol: netnews
>       Status: standard
>       Author/change controller: IETF
>       Specification document(s): This document (Section 3.2.13)
> 
> I would like to add
>       Applicable protocol: email
> 
> That is technically outside our charter, but was always intended and
> should be non-controversial. Could we ask the IESG for permission to do
> that?`

Well that is a pretty long shot, so I am not really expecting it to get
anywhere. WHen we are all done, I might introduce an I.D. to make this
header the official version of User-Agent in email too, just to get it
recorded in the IANA registry.

-- 
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 k5GIDPD3048121; Fri, 16 Jun 2006 11:13:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GIDPja048120; Fri, 16 Jun 2006 11:13:25 -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 k5GIDNAT048094 for <[e-mail]>; Fri, 16 Jun 2006 11:13:24 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-65-135.midband.mdip.bt.net ([81.144.65.135] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 4492f4be.b42e.7cc for [e-mail]; Fri, 16 Jun 2006 19:13:18 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5GI4IZ18948 for [e-mail]; Fri, 16 Jun 2006 19:04:18 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23325
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Issue #1300 - Ralph's niggles
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 16 Jun 2006 17:58:05 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:

>D - I have another opinion, which is: ...................

>  Ralph Babel - give up (specific issues recorded in #1300)

I have already responded in detail to these. Many of them were reasonable
fixes for textual matters, and I indicated (with OK or similar wording)
that I was happy with them. If that is the general opinion, and Ken is
happy to accept those, then can we take those items as resolved?

There were other items that I did not accept for various reasons. May I
suggest to Ralph that he produces a list of the ones that he still wants
to be considered, as I have just done in the case of my own list.

-- 
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 k5FEei5F094132; Thu, 15 Jun 2006 07:40:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5FEeiDI094131; Thu, 15 Jun 2006 07:40:44 -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 k5FEehXF094118 for <[e-mail]>; Thu, 15 Jun 2006 07:40:43 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57B332596F1 for <[e-mail]>; Thu, 15 Jun 2006 16:39:39 +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 06764-10 for <[e-mail]>; Thu, 15 Jun 2006 16:39:35 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A4AD2596DC for <[e-mail]>; Thu, 15 Jun 2006 16:39:35 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 15 Jun 2006 07:40:38 -0700
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: [e-mail]
Subject: Tally from USEFOR Last Call on draft-ietf-usefor-usefor-08
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>

The USEFOR WG Last Call on draft-ietf-usefor-usefor-08 has concluded. 9
people responded; I've attempted a summary of positions below.
If anyone thinks I've misrepresented their position, or if I've failed
to include anyone's position in the tally, please speak up on the list ASAP.

The following results are recorded:

- A clear consensus exists that there are issues that should be fixed
before publication (6 of 9)
- Two people believe that we should give up the effort

The specific issues raised are recorded in #1298, #1299 and #1300.
We'll split out details into separate issues when appropriate.

- An almost even split (5 against 4) exists between those who believe
we should send this document forward to the IESG and those who disagree
with that notion. Of those who disagree, 2 believe we should give up; 2
believe that we should keep the document in the WG and continue.

Details, with names:

1) Is draft-ietf-usefor-usefor-08 ready to go forward?

A - I believe it is ready to go forward.

  Dan Schlitt

B - I believe issues must be fixed; all my issues have been raised by
others, and once these are resolved, I believe it is ready.

  Ken Murchison
  Graham Drabble
  Harald Alvestrand
  Alexey Melnikov

C - I believe issues must be fixed; the following issue has not been
raised so far: .....................

  Charles Lindsey - #1298 (although he believes that he can survive
without fixing the issues)
  Richard Clayton - #1299

D - I have another opinion, which is: ...................

  Forrest J. Cavalier III - weblogs are more interesting
  Ralph Babel - give up (specific issues recorded in #1300)

2) How should draft-ietf-usefor-usefor-08 be carried forward?

A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call
and processing (knowing that it will likely be in REF hold at the RFC
Editor until draft-ietf-usefor-usepro is finished)

   Dan Schlitt
   Ken Murchison
   Graham Drabble (with procedural reservations)
   Harald Alvestrand
   Alexey Melnikov

B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state",
where we will promise to only change it if work on USEPRO proves to us
that we have something wrong in -usefor-.

   Charles Lindsey

C - I have another opinion, which is........

   Forrest J. Cavalier III ("B .... my real vote is to decharter")
   Ralph Babel - give up ("I vote for B - under protest")
   Richard Clayton ("B, but frozen conceptually, not frozen textually")







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 k5E5kdv2003057; Tue, 13 Jun 2006 22:46:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5E5kdFC003055; Tue, 13 Jun 2006 22:46: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 k5E5kcJc003038 for <[e-mail]>; Tue, 13 Jun 2006 22:46: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 E202625971B; Wed, 14 Jun 2006 07:45:34 +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 18817-05; Wed, 14 Jun 2006 07:45:30 +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 A3196259726; Wed, 14 Jun 2006 07:45:29 +0200 (CEST)
Date: Wed, 14 Jun 2006 07:46:31 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: #1042 CLOSED ISSUE: Propagation of folded Newsgroups: haders (Re: WG Last Call: draft-ietf-usefor-usefor-08)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

--On tirsdag, juni 13, 2006 15:39:13 +0000 Charles Lindsey 
<[e-mail]> wrote:

>>>
>> Personally I don't think that the suggested text is an improvement over
>> existing one.
>
> My problem with the existing one is that it gives the impression that
> someone has tried an experiment to see if these things propagated, found
> that they didn't, and concluded that existing servers were therefore
> deficient.
>
> This is not so.

How quickly we forget....

from the text of ticket 1042, closed 11 months ago:

> On June 10, Charles Lindsey said:
>
> I have just submitted an article with the following headers to a server
> using INN 2.4.1. It certainly got stored on that server. I invite you
> all to see whether it arrived on any of the groups it was sent to, and
> especially indications of how long it took and the route it took would
> be interesting, since propagation using only INN 2.4+ servers may be
> rather slow. If you do not see it in the named groups, it might be worth
> looking to see if your server has filed it under "junk".
>
> Newsgroups: man.test,
> uk.test,
> misc.test,
> de.test
> Path: chl
> From: "Charles Lindsey" <[e-mail]>
> Subject: Testing folded newsgroups.
> Message-ID: <[e-mail]>
> Date: Fri, 10 Jun 2005 18:32:18 GMT
> Lines: 14
>
> It would also be helpful if others who have relaying privileges would
> try the same experiment.


> On June 12, Richard Clayton reported:
>
> the article
>
>> Message-ID: <[e-mail]>
>
> is not currently (almost 2 days later) available on news.demon.co.uk
> (well connected UK ISP server), news.mit.edu (MIT's server) or
> news.cam.ac.uk (Cambridge University's server)
>
> retention is sufficient for the article to be seen if it managed to
> reach these servers by any flood-fill route (direct routes would have
> meant that it arrived in seconds)
>
>> It would also be helpful if others who have relaying privileges would
> try
>> the same experiment.
>
> the existing result speaks for itself
>
> "Broken" articles like this don't propagate at all well :(
>
> hence any suggestion that folded newsgroups header lines are current
> state of the art (rather than some future possibility) seems premature




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 k5DGLagB019281; Tue, 13 Jun 2006 09:21:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5DGLarB019277; Tue, 13 Jun 2006 09:21:36 -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-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5DGLYHJ019248 for <[e-mail]>; Tue, 13 Jun 2006 09:21:35 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-66-181.midband.mdip.bt.net ([81.144.66.181] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 448ee60c.c7dd.103 for [e-mail]; Tue, 13 Jun 2006 17:21:32 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5DGCTg12450 for [e-mail]; Tue, 13 Jun 2006 17:12:29 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23321
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 13 Jun 2006 15:39:13 GMT
Lines: 56
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]> Alexey Melnikov <[e-mail]> writes:

>Charles Lindsey wrote:

>>3.1.5.  Newsgroups
>>
>>   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.
>>
>>No, that paragraph gives entirely the wrong impression, and I have
>>repeatedly asked for it to be changed. What is wanted is something like:
>>
>>   Current practice does [OR the current standards do] not allow [FWS] in
>>   the list of newsgroups and thus it (and particularly folding) would
>>   harm propagation significantly. Therefore, [FWS] in the
>>   <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
>>
>>Eventually I hope (for some value of "eventually") it will be allowed
>>freely (since it is a confounded nuisance and current MUAs either do not
>>display the whole line, or display it folded in inappropriate manners).
>>But, for now, "SHOULD NOT be generated" is correct.
>>  
>>
>Personally I don't think that the suggested text is an improvement over 
>existing one.

My problem with the existing one is that it gives the impression that
someone has tried an experiment to see if these things propagated, found
that they didn't, and concluded that existing servers were therefore
deficient.

This is not so. I doubt anyone has actually tried because it was well
known that the code of INN, CNews, etc just did not support the feature,
because RFC 1036 allowed neither whitespace nor folding in there.
Son-of-1036 did not require it either (though it did give a warning that
this was likely to change someday and suggested allowing it).

The [FWS] here is a new feature we have introduced ("someday" has
arrived), as is clear from Appendix B. So why can't we have a wording that
makes the true sutuation clear?

Now that I want to make too big an issue of this, because we could get by
with the present wording is that's what the WG wants.

-- 
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 k5C9g87Z032222; Mon, 12 Jun 2006 02:42:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5C9g7Wc032219; Mon, 12 Jun 2006 02:42:07 -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 k5C9g6M3032206 for <[e-mail]>; Mon, 12 Jun 2006 02:42:07 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 12 Jun 2006 10:42:02 +0100
Message-ID: <[e-mail]>
Date: Sun, 11 Jun 2006 21:00:50 +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
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Charles Lindsey wrote:

>3.1.5.  Newsgroups
>
>   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.
>
>No, that paragraph gives entirely the wrong impression, and I have
>repeatedly asked for it to be changed. What is wanted is something like:
>
>   Current practice does [OR the current standards do] not allow [FWS] in
>   the list of newsgroups and thus it (and particularly folding) would
>   harm propagation significantly. Therefore, [FWS] in the
>   <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
>
>Eventually I hope (for some value of "eventually") it will be allowed
>freely (since it is a confounded nuisance and current MUAs either do not
>display the whole line, or display it folded in inappropriate manners).
>But, for now, "SHOULD NOT be generated" is correct.
>  
>
Personally I don't think that the suggested text is an improvement over 
existing one.




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 k5C9g8IQ032230; Mon, 12 Jun 2006 02:42:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5C9g8Al032229; Mon, 12 Jun 2006 02:42:08 -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 k5C9g6M4032206 for <[e-mail]>; Mon, 12 Jun 2006 02:42:08 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA  for <[e-mail]>; Mon, 12 Jun 2006 10:42:04 +0100
Message-ID: <[e-mail]>
Date: Sun, 11 Jun 2006 21:07:04 +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
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Reminder: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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:

>> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>>
>> Possible answers:
>>
>> A - I believe it is ready to go forward.
>>
>> B - I believe issues must be fixed; all my issues have been raised by 
>> others, and once these are resolved, I believe it is ready.
>
Ralph, Richard and Charles has raised issues that need fixing.

>> C - I believe issues must be fixed; the following issue has not been 
>> raised so far: .....................
>>
>> D - I have another opinion, which is: ...................
>>
>> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
>>
>> Possible answers:
>>
>> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
>> and processing (knowing that it will likely be in REF hold at the RFC 
>> Editor until draft-ietf-usefor-usepro is finished)
>
A. (Should serve as a very good incentive for not changing the document, 
however it also allows for some parallelization of work)

>> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
>> where we will promise to only change it if work on USEPRO proves to 
>> us that we have something wrong in -usefor-.
>>
>> C - I have another opinion, which is........
>>
>> This WG Last Call will end two weeks from now, on June 8, 2006, at 
>> 17:02 Central European Time.
>




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 k5C9fvIw032149; Mon, 12 Jun 2006 02:41:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5C9fvBQ032148; Mon, 12 Jun 2006 02:41:57 -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 k5C9ftHa032132 for <[e-mail]>; Mon, 12 Jun 2006 02:41:56 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 12 Jun 2006 10:41:28 +0100
Message-ID: <[e-mail]>
Date: Sun, 11 Jun 2006 15:08:24 +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
MIME-Version: 1.0
To: Ralph Babel <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

Ralph,
Thank you for the comments.
Just commenting on a little portion of them in this message:

Ralph Babel wrote:

>| The list of current Internet-Drafts can be accessed
>| at http://www.ietf.org/ietf/1id-abstracts.txt.
>|
>| The list of Internet-Draft Shadow Directories can be
>| accessed at http://www.ietf.org/shadow.html.
>
>Might be a good idea to use angle brackets
>to separate URLs from punctuation.
>  
>
Ralph, this is a part of the standard Internet Draft template.

>| 1.3.  Requirements Notation
>|
>| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>| "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
>| and "OPTIONAL" in this document are to be interpreted as
>| described in [RFC2119].
>
>"SHALL", "SHALL NOT", "RECOMMENDED", and "OPTIONAL" do not
>even occur in the draft.
>  
>
You are correct, but the recent IESG rule (enforced by the ID nits 
checker tool) is that this sentence is to be copied verbatim from RFC 2119.

>| Intellectual Property Statement
>
>"Intellectual" refers to "Property", not
>to "[Property] Statement", so there's a hyphen
>missing between "Intellectual" and "Property".
>
>| Copies of IPR disclosures made to the IETF Secretariat and
>| any assurances of licenses to be made available, or the
>| result of an attempt made to obtain a general license or
>| permission for the use of such proprietary rights by
>| implementers or users of this specification can be
>| obtained from the IETF on-line IPR repository at
>| http://www.ietf.org/ipr.
>
>Either superfluous comma after "available"
>or missing comma after "specification".
>
>| Disclaimer of Validity
>|
>| This document and the information contained herein are
>| provided on an "AS IS" basis and THE CONTRIBUTOR, THE
>| ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF
>| ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>| TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
>| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>| THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
>| IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
>| PARTICULAR PURPOSE.
>
>Missing comma after "basis".
>  
>
The quoted text is also a part of the standard template.
You should send your comments to the IPR mailing list.

>------------------------------------------------------------
>
>Typographical issues:
>  
>
[...]

>- I would also suggest that in the table of contents and
>  in section headings - like in continuous text -, chapter
>  and section numbers be used without a trailing dot.
>  
>
I think this is an xml2rfc feature.

Alexey




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 k5A3J5b2047535; Fri, 9 Jun 2006 20:19:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5A3J5Wb047534; Fri, 9 Jun 2006 20:19:05 -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-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5A3J3CR047516 for <[e-mail]>; Fri, 9 Jun 2006 20:19:04 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-123.midband.mdip.bt.net ([81.144.67.123] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.219) id 448a3a22.4b0e.167 for [e-mail]; Sat, 10 Jun 2006 04:18:58 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5A3C9R18819 for [e-mail]; Sat, 10 Jun 2006 04:12:10 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23315
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 9 Jun 2006 19:43:46 GMT
Lines: 1091
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]> [e-mail] (Ralph Babel) writes:


>------------------------------------------------------------

I will let Ken deal with all the issues regarding commas (Oxford or
otherwise), hyphenation, capitalization, which/that, and the like. Some of
Ralph's typos have been spotted already, but many of them are new, and
presumably non-controversial.

>| The list of current Internet-Drafts can be accessed
>| at http://www.ietf.org/ietf/1id-abstracts.txt.

>Might be a good idea to use angle brackets
>to separate URLs from punctuation.

Standard IETF boilerplate :-(.

>| Abstract
>|
>| This document supersedes RFC 1036, updating it...

>Judging by the usual RFC conventions, I'd say that
>"supersedes" and "updating it" are mutually exclusive.

Disagree


>| 1.1.  Basic Concepts
>|
>| "Netnews" is a set of protocols for generating, storing
>| and retrieving news "articles" (whose format is a subset
>| of that for Email messages) and for exchanging them

"Netnews" is a technical term here defined. It mught be useful to add
'(often abbreviated to "news")' to forestall some of Ralph's later
comments. Indeed, some earlier draft somewhere once said that.



>| 1.5.  Definitions

>This section probably needs to be rewritten from scratch.
>Even though this group decided to abandon the muddy "agent"
>nomenclature, many of the subdefinitions are still based on
>it, if only to define a single type of agent ("injection",
>"proto-article"). Many other "definitions" are unclear,
>circular, or not overly helpful.

I think it might be useful, at the end of section 1.1, to add:

   The architecture of a Netnews system, together with the protocols that
   govern it, are set out in [draft-usefor-usepro]. This specification
   assumes (especially in explanatory remarks with no normative effect) a
   broad understanding of the principles of that architecture.

We decided, way back, to restrict the definitions given here to those used
here (or broadly so). It is one of the consequences of specifying the
system in two standards, and inevitably leads to 'chicken and egg'
problems. That sentence is also aimed at some of Richard's concerns.

>| A "message identifier" (Section 3.1.3) is a unique
>| identifier for an article, usually supplied by the
>| "user agent" that posted it or, failing that,
>| by the "news server".

>Any statistics to back the "usually"?

My guess is somewhere between 20% and 80%. s/usually/often/.

>Besides, I see a contradiction between the strict
>"mandatory/optional header field" duality described by
>this draft and news servers adding missing "mandatory"
>header fields. Obviously, we need to make clear to
>whom "mandatory" applies.

USEFOR defines "news articles". "Proto-articles" relax a few of the
requirements which are otherwise mandatory. Exactly which things you can
leave out, and when, are set out in excruciating detail in USEPRO. Perhaps
Ken can add a pointer to USEPRO at the end of the definition of
"proto-article".

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

>Remove first "single".

OK


>"crossposted" is used only once, in the "Xref" section.

But used extensively in USEPRO. It makes sense to keep the definition of
"crossposted" close to that of "posted". Likewise for some other
definitions little used in USEFOR.


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

We have discussed this before, and that is the terminology agreed.

>Actually, I'd associate "poster" with "sender", not "author"
>(and so does section 3.2.14). Why not simply use "author"
>for "From:" and "sender" for "Sender:"? This way, the draft
>would be less likely to confuse readers, in particular once
>they run across the "Followup-To: poster" functionality,
>which needs to take "Reply-To:" into account.


>| Every followup includes a "References"
>| header field identifying that precursor

>That and the previous sentence basically mean
>"an article not containing a References header
>field is not a follow-up". Not overly useful.

No, but it was what was agreed after one hell of an argument :-( .

>| a news server receiving such an article may (subject
>| to the policies observed at that site) take actions
>| beyond just filing and passing on the article.

>So does "Supersedes" make an article a control message?

Yes, according to some wording in 7.9.2 of USEPRO. I think every place
where "Supersedes" appears, the wording covers any possible
misunderstanding over this.

>| The generic term "agent" is used when describing
>| requirements that apply to both user agents and
>| news servers.

>The term "news agent" is used in the draft as well.

I only spotted it once, in 2.2, in a context where "agent" on its own
would look wrong.

>| 1.6.  Structure of This Document

>| rather than repeating the contents of other standards,
>| which could otherwise result in subtle differences and
>| interoperability challenges.

>It is unclear to which of the
>two options the "otherwise" refers.

s/repeating the contents of other standards, which could otherwise
 /repeating the contents of other standards which could otherwise/

>| Although this document is as a result rather short,
>| it requires complete understanding and implementation
>| of the normative references to be compliant.

>"it" (= "the document"?) requires
>understanding to _be_ compliant? - Ouch.

It is correct English. "one requires" would look stilted.

>| 2.1.  Base
>|
>| An article is said to be conformant to this specification
>| if it conforms to the format specified in [RFC2822]
>| Section 3

>"as amended by the MIME RFCs"

All the MIME RFCs already conform to RFC 2822 (or RFC *822 maybe).
Well not quite, as I realised a few further lines down ...

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

>So the resulting article is conformant, but the agent that
>generated it isn't?

Yes, a typical example of MUST accept MUST/SHOULD NOT generate (lots of
that in RFC 2822).

>... That's an unfortunate choice of words,
>in particular in light of the following sentence:

>| Agents conforming to this specification
>| MUST generate only conformant articles.

Yes, that is a good point, and Richard raised it also. Could omit that
paragrpaph as a tautology. Harald wrote it. I will accept his decision.


>| 2.2.  Header Fields
>|
>| All header fields in a news article are compliant with
>| [RFC2822], however this specification is less permissive
>| in what can be generated and accepted by news agents.

>Slightly misleading "however". Should probably be
>"... [RFC2822]; this specification, however, is ...".

OK

>| The syntax allowed for news articles is a strict subset ...

>"... as extended by the MIME RFCs."

>Otherwise, since we're not redefining <text> (and of
>course we shouldn't be), anything other than "7bit" and
>"quoted-printable" would not conform to this draft.

Ah Yes! MIME indeed permits 8bit (and USEPRO requires transports to be
8bit clean). Your suggested addition would cover it.

>While section 2.2 is about "header fields", there is no
>corresponding section on article bodies, so we should
>either add one or rename that section.

There was one once, but it died of starvation :-( .

>| 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 relevant sections of this document.

>It's also the article _body_ that matters.

But are there some specific rules regarding body matters you would like
mentioned hereabouts?

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

>It says "header fields" here ...

Yes, that is a known bug with an agreed fix.

>| [I-D.ietf-usefor-useage] includes suggested
>| limits for convenience of display by user agents.

>Crystal-ball mode detected!

There exists a draft for USEAGE, and it covers that issue (using agreed
words from very early drafts long before USEAGE was split off).



>| 3.1.  Mandatory Header Fields
>|
>| Each news article conformant with this specification MUST
>| have exactly one of each of the following header fields:
>| From, Date, Message-ID, Subject, Newsgroups, Path.

>So we should point out that this draft doesn't apply
>to communication between user agents and news servers.

There are relaxations for proto-articles, as already mentioned above.

>| 3.1.1.  From
>|

>| from = "From:" SP mailbox-list CRLF

>"mailbox-list" is a change from 1036 that
>deserves to be documented in appendix B.

OK


>| 3.1.3.  Message-ID
>|
>| The Message-ID header field contains
>| a single unique message identifier.

>What purpose does the "single" serve here?

OK

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

>It's not just retrieval. For instance, a news server
>may suggest or report a message ID when an article
>is posted. We could say "when referencing".

OK

>| Observe that msg-id includes the < and >.

>Actually, it might be a good idea to provide a token
>that describes the message ID _without_ its enclosing
>angle brackets, e.g. for use in a news URL RFC.

There is an internet-draft for that (which I need to resurrect sometime),
and it contains suitable verbiage to cover the point. USEPRO (and RFC 2822
too) carefully uses the term "message identifier" in contexts where the
<..> are irrelevant. So it ain't actually broke ...


>| 3.1.5.  Newsgroups
>|

>| Such components MAY be used only to refer to existing
>| groups that do not conform to this naming scheme.

>I find this a little wishy-washy. The syntax clearly states
>that a newsgroup name may well contain all-digit components
>or uppercase letters; the two "SHOULD NOT"s warn about
>compatibility issues. _Of_ _course_, clients and servers are
>free to support the full syntax. So what's this "MAY" about?

It carefully says "MAY ... only", which seems clear enough to me.


>| <component>s beginning with underline ("_") are reserved
>| for use by future versions of this standard and MUST NOT
>| be generated by user agents

>Just user agents? What about servers _generating_ components
>like these? After all, the newsgroups listed in "Xref" are
>documented as not necessarily agreeing with the Newsgroups
>header field, so news servers may well generate newsgroup
>names themselves in articles.

If user agents never generate then, they will never turn up in servers.
If they do, they must be propagated. If one turns up in an Xref, I don't
really care.

>| (whether in Newsgroups header fields

>What about "Followup-To" header fields?

OK


>| However, such names MUST be accepted by news servers.

>Just by servers? What about user agents?

OK s/news servers/all agents/

>| <component>s beginning with "+" and "-" are reserved for
>| private use and MUST NOT be generated by user agents

>As above.

My comment as above.

>| (whether in Newsgroups header fields

>As above.

OK

>| such names MUST be accepted by news servers.

>As above.

OK


>| Groups whose first (or only) component is "example"

>"<component>"?

Correct


>| "example.*" is reserved for examples
>| in this and other standards;

>This draft does not contain any such example.

But USEPRO does. I'll let Ken fix this it he think it needs fixing.

>| "to.*" is reserved for certain
>| point-to-point communications

>Really plural?

Yes, there in only one protocol that uses it, but sites might generate
lots of communications using that protocol


>| and "ctl" was formerly used to indicate a
>| <control-command> within the Subject header field.

>No, not the "Subject" header field; that was the
>"cmsg" mechanism. "ctl" was used in "Newsgroups".

s/Subject/Newsgroups/

>| 3.1.6.  Path
>|
>| Each agent that processes an article is required to
>| prepend at least one <path-identity> to this header
>| field body.

>Well, no; not strictly. An agent _forwarding_ an article is
>required to have prepended its own identity to the beginning
>of the path of the forwarded article. What happens locally
>("processes") is outside the scope of this draft.

OK

>| This is primarily to enable news servers to avoid
>| sending articles to sites already known to have them,

>Path-preloading needs to be mentioned in section 5.

It is covered adequately in USEPRO.

>| NOTE: Although case-insensitive,

>If the path or components of it are to be treated as
>case-insensitive, this needs to be mentioned outside
>of a "note". Traditionally, the path and UUCP names
>were case-sensitive; domain names are case-insensitive.
>So we need to make clear what the status of each of the
>individual components is.

Oh Dear! There was wording in the old *-article-* drafts which covered
this, but it seems to have disappeared. The situation is that some
relaying agents do it case insentitively and some not. It is safest to
assume case-insensitivity, but warn against sites using <path-identity>s
which differ only in case. USEPRO is the right place to do that (because
we give other advice on choosing identities there), and I have made a note
to attend to it.

In the meantime, the intention in USEFOR was that those <path-keyword>s
should be case-sensitive (though by convention in upper case).

So I think the first requirement is to extend the paragraph dealing with
<path-identity)s:

   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>). Although mostly derived from
   domain names (which are case-insensitive), <path-identity>s are to be
   considered as case-sensitive (though traditionally they are chosen to
   be in lower case).

And then replace that NOTE by

   <path-keyword>s are to be considered as case-insensitive, though it is
   intended they be rendered in upper case to distinguish them from
   <path-identity>s.


>| 3.2.  Optional Header Fields
>|
>| None of the header fields appearing in this section
>| is required to appear in every article but some of
>| them may be required in certain types of articles.
>| Further discussion of these requirements appears in
>| [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage].

>Section 1.5 already contains one such requirement.

No, 1.5 just gives definitions, and makes a statement which is true and
helpful, but relies on USEPRO and USEAGE as to why it is true. We argued
long and hard over this, and what you see is how it was finally resolved.

>| The header fields Reply-To, Sender, Comments, and Keywords
>| are used in news articles in the same circumstances and
>| with the same meaning as that specified in [RFC2822]

>Consistency: "meaning ... that" here, but ...

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

>... "meanings ... those" here.

I delegate Ken to toss a coin.


>| 3.2.1.  Injection-Date
>|
>| 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.

>If they have already "expired", then "reinjection"
>isn't an issue.

Yes it is, because they can come around (by some delayed progagation
route) and get reinjected again, and even cause loops.


>I thought its purpose was to aid in the _propagation_ of
>articles that are "injected" a long time _after_ their
>"Date" header field has been added locally by the client.

No, it was to prevent loops more effectively that the Date header alone
(but the Date header is still used as a fallback - see USEPRO).

>| This header field MUST be inserted
>| whenever an article is injected.

>By whom? And when exactly does "injection" take place?

Gory details given in USEPRO. All you need to know in USEFOR is that it
happens. Perhaps Ken could add a reference to USEPRO here.

>| software that predates this standard does not use
>| this header, and therefore agents MUST accept
>| articles without the Injection-Date header field.

>I consider this to be a contradiction. We cannot make an
>experimental header field (and that's what "Injection-Date"
>is at this point) mandatory (see "MUST be inserted" above).

No. Existing software will not be compliant with the new standard until it
is upgraded. However, USEPRO has arranged that nothing breaks during the
catch-up period, though things may run more smoothly once everyone is
compliant. See "Transitional arrangements" section in USEPRO.


>| Since clocks on various agents may not be synchronized,
>| the <date-time> in this header field may not be later
>| than the Date header field,

>"may" could be misread as a 2119-like "MAY" here.

A Dan Kohn-ism, which Richard already complained about (and proposed a
solution).


>| Agents SHOULD use the <date-time> they
>| believe is correct when adding Inject-Info

>Beg pardon? This sounds rather redundant.

They should do what their own clocks tell them, even if it gives the
appearance of negative time.


>| 3.2.3.  Followup-To
>|
>| The Followup-To header field specifies to which
>| newsgroup(s) followups should be posted.

>"... according to the author".

Or some such wording. I think Richard also raised this point and suggested
a wording.

>The draft needs to make it absolutely clear that
>this is nothing but a _suggestion_ by the author.

>| The syntax is the same as that of the Newsgroups (Section
>| 3.1.5) header field, with the exception that the keyword
>| "poster" requests that followups should be mailed to the
>| article's reply address rather than posted.

>"reply address" needs clarification.

I think we defined that term once, but took it out because of little use.
In this case, RFC 2822 tells you all you need to know.

>| 3.2.4.  Expires
>|
>| The Expires header field specifies a date and time when
>| the article is deemed to be no longer relevant and could
>| usefully be removed ("expired").

>How about a note that this is used both to reduce and to
>extend the "regular" expiration period and that the local
>effects are implementation/configuration-specific?

Yes, I wanted such a text, but the group decided otherwise :-( . It is
covered in USEAGE.


>| 3.2.6.  Supersedes
>|
>| The Supersedes header field contains a message identifier
>| specifying an article to be superseded upon the arrival
>| of this one.

>So what does "superseded" mean? I'd add something along the
>lines of "The local effects of superseding an article are
>implementation-specific.".

It means "superseded". If you want to know in more detail what happens
when an agent sees this header, then USEPRO is your friend.

>| the syntax here permits only one <msg-id> in contrast
>| to the multiple <msg-id>s in that Email version.

>Actually, s-o-1036 _did_ permit multiple message IDs,
>which should also be mentioned in appendix B.

OK

>| 3.2.7.  Distribution
>|
>| The Distribution header field specifies geographic or
>| organizational limits on an article's propagation.

>Doesn't say a whole lot about how it actually _works_.

That's what USEPRO's for.

>A few words to the effect that a site may consider itself
>(or others) to be a member of one or more <dist-name>s?

If you like.

>| The <dist-name>s "world" and "local" are predefined.

>Where? In which way?

By the words you have just quoted. If you want to know how agents are
supposed to react to them, then USEPRO is your friend.

>| "All" MUST NOT be used as a <dist-name>.

>So it's sort of predefined as well, isn't it?

Not really. You can write "local" (and "world" at a pinch), but you cannot
write "all".

>| 3.2.9.  Approved
>|
>| Its principal uses are in moderated articles and
>| in group control messages [I-D.ietf-usefor-usepro].
>| one of those mailboxes MUST be that
>| of the actual sender of the article.

>Huh? Why and since when? There has never been a requirement
>of this kind, at least not in Usenet as deployed in _my_
>universe.

Yes, it is new (though it has been in our drafts for yonks). It is there
to discourage the "Approved: me" sort of thing (thereby making it more
likely that ISPs will respond to LARTs). It can help sustain an accusation
of forgery. It makes people accountable for what they put there. It is a
step in the direction of strengthening this header, though it will need
digital signatures to do it properly, and we decided way back that was
future work.

> A moderator (or anybody else wishing to use that
>header) is certainly free to have somebody else inject his
>messages on his behalf without listing the sender in the
>Approved header field.

Then you should sign it yourself, and add a comment to say that you had
the moderator's permission, or you should include both addresses in the
header.


>| 3.2.11.  Xref
>|
>| The Xref header field indicates where an article was
>| filed by the last news server to process it. The article
>| locations are used to keep track of crossposted articles
>| so that user agents serviced by a particular news server
>| can mark such articles as read.

>"by that particular" (= "the last
>news server to process it").

Maybe. The main point is that you cannot expect it all to work if you get
articles from several servers and mix them all up. It ain't broke ...

>| article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )

>I probably missed the discussion on this one, but is
>anyone actually making use of anything but digits?

Decided years ago. There used to be a remark "for the benefit of unusual
implementations", but it seems to have got optimized away :-( .

>| 3.2.12.  Archive
>|
>| The absence of this header field, or the presence of this
>| header field with a field body of "yes", indicates that
>| the poster is willing for such redistribution to take
>| place.

>The default value in absence of this header is a copyright
>issue subject to numerous local jurisdictions we cannot
>reasonably take a stand on.

No, it needs to be made very clear that the permission is either given or
not given (the concept of giving or witholding permission is well
understood in copyright law, and established by international treaty).

Usenet is clearly a very public place, and can only work on the
understanding that you have given permission for your words to be copied
as least within the normal operation of Usenet (this point is widely
understood, and USEPRO repeats it to put it beyond all doubt).

Permanent archives go beyond that, hence this header. But if it cannot be
made clear that, in the absence of this header, permission is implied,
then Google is stuck (and, for all its faults, the consensus on USENET is
that it is a useful facility).

We last discussed this many years ago, concluded it was basically a
copyright issue, and wrote the simplest wording that would cover exactly
what we wanted and no more (backed up by the wording in USEPRO that I
mentioned). BTW, that USEPRO wording also warns you about libel and
defamation and about legal jurisdictions in far away places, and advises
you to take legal advice if you have further concerns.


>The change was introduced without discussion in
>draft-ietf-usefor-usefor-02.txt,

All that happened in draft-02 was that we put back the wording that had
been there for years previously (the earlier USEFOR drafts omitted all
sorts of things that had been established long before).

This header has been present in our drafts for a long long time. If you
wanted such a substantial change to it, then you should have raised a
formal issue long ago.

>| Further extensions to this standard may provide
>| parameters for administration of the archiving process.

>Crystal-ball mode again.

>Replace by "No parameters are currently defined.".

Tautology. Let us at least give them some indication of which such
parameters _might_ be useful for,

>| 3.2.13.  User-Agent
>|
>| This header field MAY contain multiple product-tokens

>"<product> tokens".

Or "<product>s"

>| listed in order of their significance

>Ascending or descending?

I would suggest most significant first, if Ken would care to write
something suitable.

>| [RFC2616] describes a similar facility for the HTTP
>| protocol. This specification differs in that "{" and "}"
>| are allowed in tokens (<product> and <product-version>)
>| and comments are permitted wherever whitespace is allowed.

>The use of "This" is ambiguous here.

>Replace by "The netnews article format".

OK

>| 3.2.14.  Injection-Info


>There was also strong support for
>generic complaints URLs, not just mail.

And also much opposition. An Issue was raised, and that is how it was
decided.

>| The Injection-Info header field contains
>| information provided by the injecting news server

>"injecting news server" seems a misnomer to me. It's
>not the server that is "injecting". "injection" maybe?

You need an adjective, such as "injecting". Some servers are "injecting"
(because they inject). Some servers are "relaying" (because they relay).
Seems clear to me.

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

>How does the "@" fit into <host-value>/<dot-atom-text>?

Aaaaaarrrrgghhhh! s/@/./


>| Although comments and folding of white space are
>| permitted throughout the Injection-Info header field,

>"folding _of_ white space"? "at"? "upon"?

I see no problem.

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

>If this is a newly defined header field, how can 2119
>language apply here? What are the interoperability
>issues as required by RFC 2119 section 6?

It's a SHOULD. It otherwise makes life difficult for people who write
scripts or killfiles involving this header.

>| 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 usual form is "X-Trace".

OK

>| it SHOULD be given in a form that
>| can't be interpreted by other sites.

>"sites" can interpret data? Not really.

You'd be surpries how "smart" some sites are. Never met a "smarthost" yet?


>| 3.3.  Obsolete Header Fields

>So many words, so little effect. If we can obsolete (see
>section 6) non-RFC headers such as those from s-o-1036,
>what's the problem with these headers from RFC 850? Yes,
>850 is a "nonstandard". So how is this different from
>1036 and s-o-1036?

>My suggestion: Replace the entire section by ...

>| The header field names Date-Received, Posting-Version, and
>| Relay-Version defined in [RFC850] as well as Also-Control,
>| Article-Names, Article-Updates, and See-Also defined in
>| [Son-of-1036] are declared obsolete. See the original
>| documents for further information on their original use.

I agree this section is overlong (and have said so). But you are
over-simplifying it.

>Add to section 6:

>| Header field name: Date-Received
>| Applicable protocol: netnews
>| Status: obsoleted
>| Author/change controller: IETF
>| Specification document(s): [RFC850] (section 2.2.4)
>|
>| Header field name: Posting-Version
>| Applicable protocol: netnews
>| Status: obsoleted
>| Author/change controller: IETF
>| Specification document(s): [RFC850] (section 2.1.2)
>|
>| Header field name: Relay-Version
>| Applicable protocol: netnews
>| Status: obsoleted
>| Author/change controller: IETF
>| Specification document(s): [RFC850] (section 2.1.1)

>(or "historic" instead of "obsoleted")

OK

>Add to section 7.2:

>| [RFC850]  Horton, Mark R., "Standard for Interchange
>|           of USENET Messages", RFC 850, June 1983.

Up to Ken.

>| 3.3.1.  Lines
>|
>| The Lines header field indicates the number
>| of lines in the body of the article.
>|
>| lines =  "Lines:" SP *WSP 1*DIGIT *WSP CRLF
>|
>| The line count includes all body lines, including the
>| signature if any, including empty lines (if any) at the
>| beginning or end of the body, and including the whole of
>| all MIME message and multipart parts contained in the body
>| (the single empty separator line between the header fields
>| and the body is not part of the body). The "body" here is
>| the body as found in the posted article as transmitted by
>| the user agent.

>Again, so many words ...

But it was never written down clearly before.


>| 5.  Security Considerations
>|
>| Additionally, several currently non-standardized
>| protocols [PGPVERIFY] will hopefully be standardized
>| in the near future.

>Insert "such as" before "[PGPVERIFY]".

Already suggested :-)

>Replace "will hopefully" by "may".

No, it is only "hope" that keeps the world turning :-) .

>| articles are refused

>"may be refused". After all, there's
>a limit to a server's history size.

OK

>| (in server-to-server transfer)
>| if the identifier has already been seen.

That is the context in which this happens. What else?

>Not just in server-to-server transfer.

>| Such differences in parsing may
>| be used as part of an attack.

>"differences"? "deviations" or "deficiencies" maybe?

OK

>| 6.  IANA Considerations
>|
>| Header field name: Also-Control
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: Article-Names
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: Article-Updates
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: See-Also
>| Status: obsoleted
>| Author/change controller: IETF

>These are not strictly IETF header fields,
>so their status may have to be "deprecated".

Up to Harald I think.

>| Header field name: Comments
>| Header field name: Date
>| Header field name: From
>| Header field name: Keywords
>| Header field name: References
>| Header field name: Reply-To
>| Header field name: Sender
>| Header field name: Subject

>Is there a reason why it's ...

>| Specification document(s): This document (Section 3.X),
>| [RFC2822] (Section 3.Y)

>... for the fields above, but ...

>| Specification document(s): This document (Section 3.1.3)
>| Related information: [RFC2822] (Section 3.6.4)

>... for Message-ID?

Becvause our Message-ID is different from the RFC 2822 one.


>| Header field name: Archive
>| Status: standard
>|
>| Header field name: Injection-Date
>| Status: standard
>|
>| Header field name: Injection-Info
>| Status: standard

>Isn't that "experimental" for now? After all,
>there's not a single implementation yet, is there?

No, it is a new standard with new requirements. Transitional arrangements
have been taken care of.

>| Header field name: Lines
>| Status: deprecated

>"deprecated" isn't listed among the preferred values for
>IETF documents, and we call it "obsolescent" in 3.3.1.

I think it is the status of RFC 1036 that determines which set of terms is
applicable. And the stratus of RFC 1036 is as woolly as they come :-( .

>| Header field name: NNTP-Posting-Date
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: NNTP-Posting-Host
>| Status: obsoleted
>| Author/change controller: IETF

>According to section 3.2.1, it's "deprecated".
>Are these really IETF header fields?

Only in the sense that the IETF is declaring their new status, at least
from now on.

>| Header field name: User-Agent

>Add "Related information: [RFC2616] (section 14.43)".

OK

>| [Errata] "RFC Editor Errata".

>Add "<URL:http://www.rfc-editor.org/errata.html>".

Yes, I have already prodded Ken on some of those.

>| [ISO.3166.1988]

>Not strictly the same, but add ...

><URL:http://www.iso.org/iso/en/prods-services/iso3166ma/index.html>

>... maybe?

Not needed for documents from well-known sources such as ISO.

>| [PGPVERIFY] Lawrence, D., "PGPverify", June 1999.

>"pgpverify" is a minimum of two years older; at least that's
>when I first mentioned the replay attack against the de.*
>hierarchy key. What exactly is the draft referring to?

I think it was revised then. It's another URL that Ken has managed to
lose.

>| As this document is the result of an eight year effort,

>"nine-year effort".

and rising ...


>| Intellectual Property Statement

>"Intellectual" refers to "Property", not
>to "[Property] Statement", so there's a hyphen
>missing between "Intellectual" and "Property".

>| Copies of IPR disclosures made to the IETF Secretariat and
>| any assurances of licenses to be made available, or the
>| result of an attempt made to obtain a general license or
>| permission for the use of such proprietary rights by
>| implementers or users of this specification can be
>| obtained from the IETF on-line IPR repository at
>| http://www.ietf.org/ipr.

Standard IETF boilerplate, as scrutinized by their lawyers :-( .


>------------------------------------------------------------

OK, a lot of well-spotted items in there. I would suggest to Ken that he
adopts all the things I have marked as "OK" (or similar), unless there are
screams to the contrary pretty soon.

If Ralph still wants us to pursue some of the other items, I suggest he
prepares a new, shorter list.

-- 
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 k5A3Ixfr047479; Fri, 9 Jun 2006 20:18:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5A3IxeJ047472; Fri, 9 Jun 2006 20:18:59 -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-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5A3IvLf047454 for <[e-mail]>; Fri, 9 Jun 2006 20:18:58 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-123.midband.mdip.bt.net ([81.144.67.123] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.219) id 448a3a1e.4b0e.164 for [e-mail]; Sat, 10 Jun 2006 04:18:54 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5A3CBh18828 for [e-mail]; Sat, 10 Jun 2006 04:12:11 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23316
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Fri, 9 Jun 2006 20:02:35 GMT
Lines: 103
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]> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes
>>
>>There are several places where we say "MUST accept, but SHOULD NOT
>>generate", usually because it is some newly introduced feature which will
>>cause trouble if people start using it before deployed agents can cope
>>with it. Which begs the question why this particular one is MUST NOT
>>rather than SHOULD NOT.

>that is indeed an interesting question... but my main point was that I
>have no clear idea what the difference is between...

>        generate

>        inject

>        posted to

>        accept

>        moderate

>        supplied

>        passing on

>        make available to

>        exchange with

>        submit

>        create

>        process

>        send to

>        mailed

>        expired

>        relay

>        filed

>        enter

>which appear to be 18 terms for 4 or 5 actual types of action

The purpose of USEFOR is to define what is or is not a compliant article,
and to give semantics (but without going into protocol details). It is
clear from the contexts that nearly all the words you mention are
'actions' or 'events' to which articles may be subjected as they wander
around the system, and that is all you really need to know from a USEFOR
POV. I have written a paragraph in response to Ralph, which points you to
USEPRO if you want to learn about the overall architecture of a Netnews
system, and that may help resolve your problem.

The only two words which actually convey meaning directly relevant to
USEFOR are "generate" and "accept". Both those terms are used, without
definition and in the same contexts, in RFC 2822, which suggests that we
do not really need formal definitions here.

But if such definitions *are* deemed necessary, then section 2.1 would be
the place to put them. It is well recognized that RFC 2822 effectively
defines two grammars, a "generate" one, and a more liberal "accept" one -
that is the concept any definition would have to capture.

Harald has asked for suggested texts. If someone produces one, I would be
happy to consider it.


>>>3.2.13.  User-Agent
>>
>>>   The User-Agent header field ....  It is intended that this header field be
>>>   suitable for use in Email.
>>
>>>        does that last sentence mean that it shouldn't contain NULs ?
>>
>>Eh?

>I don't understand what "use in Email" means -- probably because it is
>not immediately obvious why User-Agent has a special relationship with
>email that other header fields do not.

It means it could be used in Email with the same syntax and semantics we
have given here. Indeed, it is so used, but not with any well-understood
syntax. There are other headers defined in News that are suited to Email
also (Organization is the obvious one).

-- 
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 k59E6DGI078624; Fri, 9 Jun 2006 07:06:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k59E6Duc078623; Fri, 9 Jun 2006 07:06:13 -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 k59E6COV078610 for <[e-mail]>; Fri, 9 Jun 2006 07:06:12 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 232A6259714 for <[e-mail]>; Fri,  9 Jun 2006 16:05:12 +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 17293-09 for <[e-mail]>; Fri,  9 Jun 2006 16:05:07 +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 2FBE2259713 for <[e-mail]>; Fri,  9 Jun 2006 16:05:07 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 09 Jun 2006 16:06:05 +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: [e-mail]
Subject: WG Last Call on draft-ietf-usefor-usefor-08 has expired
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 is just to note that the 2-week timer for the WG Last Call has expired.

The chairs will attempt to pull together a summary of opinions stated, 
and suggest some next steps.

                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 k591rVXU062549; Thu, 8 Jun 2006 18:53:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k591rVSK062548; Thu, 8 Jun 2006 18:53:31 -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 k591rUj0062527 for <[e-mail]>; Thu, 8 Jun 2006 18:53:30 -0700 (MST) (envelope-from [e-mail])
Received: from shell.peak.org (shell.peak.org [127.0.0.1]) by shell.peak.org (8.13.1/8.13.1) with ESMTP id k591rUaS010365 for <[e-mail]>; Thu, 8 Jun 2006 18:53:30 -0700
Received: from localhost (stanley@localhost) by shell.peak.org (8.13.1/8.13.1/Submit) with ESMTP id k591rTmo010362 for <[e-mail]>; Thu, 8 Jun 2006 18:53:30 -0700
X-Authentication-Warning: shell.peak.org: stanley owned process doing -bs
Date: Thu, 8 Jun 2006 18:53:29 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
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>

rbabel@xxxxxxxxxxxxxxxxxxxx (Ralph Babel):

>| A newsgroup may be "moderated", in which case submissions
>| are not posted directly, but mailed to a "moderator" for
>| consideration and possible posting. Moderators are
>| typically human but may be implemented partially or
>| entirely in software.

>The word "moderated" occurs only once,
>in the "Approved" section.

Additionally, moderators are ALWAYS human, but they may use software to
perform or automate their tasks.

>That and the previous sentence basically mean
>"an article not containing a References header
>field is not a follow-up". Not overly useful.

If one is trying to determine what is and is not a follow-up, at least
we can still identify "not a follow-up". We lost "this is a follow-up"
a long time ago.





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 k58H5aGU048419; Thu, 8 Jun 2006 10:05:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k58H5adl048418; Thu, 8 Jun 2006 10:05:36 -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-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58H5YqE048403 for <[e-mail]>; Thu, 8 Jun 2006 10:05:35 -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-33.mail.demon.net with esmtp (Exim 4.42) id 1FoNwr-000AKt-CL; Thu, 08 Jun 2006 17:05:33 +0000
Message-ID: <[e-mail]>
Date: Thu, 8 Jun 2006 18:04:06 +0100
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <v13$+DUn77$ZMMKLw2W+duaO8X>
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
>
>In <[e-mail]> Richard Clayton <[e-mail]> 
>writes:
>
>>#2.1 says that user agents must not "generate" a specific obsolete
>>construct. But in the long list of definitions in #1.5 there is no
>>meaning given to generate.  I suspect what is meant that a user agent
>>must not accept an article from a poster if it contains this construct.
>>We'd surely expect user agents to do all the other things (give it to
>>readers, swap it with other sites etc)
>
>There are several places where we say "MUST accept, but SHOULD NOT
>generate", usually because it is some newly introduced feature which will
>cause trouble if people start using it before deployed agents can cope
>with it. Which begs the question why this particular one is MUST NOT
>rather than SHOULD NOT.

that is indeed an interesting question... but my main point was that I
have no clear idea what the difference is between...

        generate

        inject

        posted to

        accept

        moderate

        supplied

        passing on

        make available to

        exchange with

        submit

        create

        process

        send to

        mailed

        expired

        relay

        filed

        enter

which appear to be 18 terms for 4 or 5 actual types of action

since some of these actions are subtly different from each other, it
would seem wise to choose good words for these different actions, define
them carefully and then use them consistently

otherwise I might get confused :(

>The pair of terms "generate" and "accept" could be defined if you want,
>but I am happy with their normal dictionary meanings here.

I am not happy that a range of words with apparently similar meanings
are used for a range of different actions in a technical standard.

They don't necessarily mean exactly what they mean in a dictionary :(
leaving aside that OED offers 7 definitions for generate (in 4 groups)
and 9 definitions for accept (in 6 groups).

>>3.2.13.  User-Agent
>
>>   The User-Agent header field ....  It is intended that this header field be
>>   suitable for use in Email.
>
>>        does that last sentence mean that it shouldn't contain NULs ?
>
>Eh?

I don't understand what "use in Email" means -- probably because it is
not immediately obvious why User-Agent has a special relationship with
email that other header fields do not.

[snip rest to keep the discussion concise]

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

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

iQA/AwUBRIhYhpoAxkTY1oPiEQJ/kACfRvz0D3njCemcx0jS8aeRd3Bt6gcAoI1b
KtDbbGH1WfdR0iri4ZaCsp8x
=L3Zn
-----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 k58GEb5M018638; Thu, 8 Jun 2006 09:14:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k58GEbd0018637; Thu, 8 Jun 2006 09:14: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-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58GEX3x018601 for <[e-mail]>; Thu, 8 Jun 2006 09:14:36 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-65-3.midband.mdip.bt.net ([81.144.65.3] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 44884cc4.a364.373 for [e-mail]; Thu,  8 Jun 2006 17:13:56 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k58GCRW27157 for [e-mail]; Thu, 8 Jun 2006 17:12:27 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23311
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Thu, 8 Jun 2006 15:14:32 GMT
Lines: 205
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]> Richard Clayton <[e-mail]> writes:

>#2.1 says that user agents must not "generate" a specific obsolete
>construct. But in the long list of definitions in #1.5 there is no
>meaning given to generate.  I suspect what is meant that a user agent
>must not accept an article from a poster if it contains this construct.
>We'd surely expect user agents to do all the other things (give it to
>readers, swap it with other sites etc)

There are several places where we say "MUST accept, but SHOULD NOT
generate", usually because it is some newly introduced feature which will
cause trouble if people start using it before deployed agents can cope
with it. Which begs the question why this particular one is MUST NOT
rather than SHOULD NOT.

The answer is that we are following RFC 2822 precisely here. It is a "new"
feature, which they bizarrely described as "obs-ohrase" (and have
regretted it ever since - it should have been called an
"extended-phrase"). So it was MUST NOT generate in RFC 2822, and we have
enough problems with RFC 2822 not to embark on differences over this one.
Actually, many current agents accept it and quietly put quotes around it
(which works if they remember to quote any pre-existing quotes within it).

>A little further down "generate" is used again, but this time for all
>agents...  "Agents conforming to this specification MUST generate only
>conformant articles."   which, if I knew from the spec what "generate"
>meant would probably be a tautology :(

Yes, it is a tautology. We had argued long and hard about some of these
issues until Harald proposed the text you now see, and everyone was so
relieved that they decided to leave it be and move on.

>There's more mentions of "generate" later on in the document as well...
>in one case this covers the creation of a new Path: header field, and so
>generate means a bit more than what one might loosely call "posting".
>Hence I think it's rather important to be more clear what's going on.

I think "generate" means to "create out of then air" (or in response to some
human), as opposed to passing forward something as received which you
"accepted" from some earlier agent. The 'accept' rules are more liberal
than the 'generate' rules, so once you have accepted something, you leave
it be as you pass it forward, unless USEPRO gives you some specific
instruction to the contrary.

The pair of terms "generate" and "accept" could be defined if you want,
but I am happy with their normal dictionary meanings here.

>I note that the definition of the Path header field uses the term
>"injection" which is apparently different again. Indeed it pops up again
>in #3.2.1 (not surprisingly) but I wonder what it means :(

It is one of those consequences of splitting USEFOR apart from USEPRO
which the WG, in its ineffable wisdom, decided upon some years ago. Yes,
the term is defined, and used extensively in USEPRO. I think its
dictionary meaning is good enough for the informal paragraphs used to
introduce and motivate the various header fields.

>Then #2.1 says

>   The text below uses ABNF ....

>   Articles must also conform....

>could we run these two paragraphs together... they're inextricably
>linked.`

Yes, I'll buy that.

>#3.1.6

>   This is primarily to enable news servers to avoid
>   sending articles to sites already known to have them

>        to enable to avoid to sites ...  ain't grammar :(

>        This is primarily so that news servers are able to avoid..

I think the grammar is fine, but will buy your improvement.

>#3.2.1
>   NOTE: Since clocks on various agents may not be synchronized, 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 header field.

>   horribly sub-clauses, why not:

>        NOTE: It might be expected that the <date-time> in the Date
>        header field would be earlier than the Injection-Date header
>        field's value. However, clocks on different machines may not be
>        synchronised, so this will not necessarily be the case. Agents
>        SHOULD ... etc

Yes, that's more or less what it said before Dan Kohn popped up and
"improved" it. I can live with either, but marginally prefer yours. It
isn't the only Dan Kohn change that, upon further examination, was not
quite right (there was another one in my list of niggles).

>3.2.3.  Followup-To

>   The Followup-To header field specifies to which newsgroup(s)
>   followups should be posted.  

>        since that's not SHOULD, would it not be clearer to say "to
>        which newsgroup(s) the poster has requested that followups are
>        to be posted"

I'll buy that.


>3.2.11.  Xref

>   The Xref header field indicates where an article was filed by the
>   last news server to process it.  The article locations are used to
>   keep track of crossposted articles so that user agents serviced by a
>   particular news server can mark such articles as read.

>        the second sentence doesn't illuminate

>        Why not replace it by

>        User agents often use the information in the Xref field to avoid
>        multiple processing of crossposted articles.

That doesn't illuminate either. How about:

        User agents often use the information in the Xref field to avoid
        exhibiting crossposted articles in more than one of its groups.


>3.2.13.  User-Agent

>   The User-Agent header field ....  It is intended that this header field be
>   suitable for use in Email.

>        does that last sentence mean that it shouldn't contain NULs ?

Eh?

>        frankly all the ABNF here is a waste of time, make it freeform
>        text because I assure you that's all that software authors will
>        bother with

We took the syntax from the HTTP standard, which was the only place that
header was defined (modulo a slight difference in the syntax of <token>
between HTTP and MIME). The IETF was supposed to pat us in the back for
not inventing different syntax than existing standards :-) .

>3.2.14.  Injection-Info

>these sections appear to be in a random order. Either make them
>alphabetical or arrange them by topic. Injection-Info and Injection-Date
>belong next to each other

I agree.


>It's several years since I last read this document carefully from one
>end to other.  To be honest, I find many paragraphs unnecessarily
>confusing (the worst stuff I've picked out above).

>There's no very clear sense here of the life history of articles, what
>stages they pass through and what sort of changes and validation are
>permitted when. That's quite important :(

That's all in USEPRO (see remark above :-) )

>The definitions are sloppy and frankly rather strange.

Youi should ahve seen them as they were in draft-00 :-(

> The sloppiness
>I've picked out above; for a "strange" example: "proto article" is only
>ever used in the definition of "user agent" -- and so I'm not really
>entirely clear why it needs defining.

Used extensively in USEPRO. Easier to define it here, within the same
paragraph as "article".


>So my opinion is that someone skilled at precise technical writing
>should go through the thing from top to bottom to produce a document
>which is considerably more inspiring to read... the current one is
>second-rate and should not in my opinion go anywhere near a critical
>readership.

Yes, we had a draft with "precise technical writing" once (see remark
above :-) )

But in the state this WG is in, it will have to do. Actually, as I read it
right through from beginning to end last week, I was quite pleased with
the way it read (and you know whom I learnt my technical writing skills
from). Or would you rather let Simon Watkin loose on it :-( .

-- 
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 k58F1beT075396; Thu, 8 Jun 2006 08:01:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k58F1bSk075395; Thu, 8 Jun 2006 08:01:37 -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 k58F1Y5L075342 for <[e-mail]>; Thu, 8 Jun 2006 08:01:35 -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 AC7C910DDBF for <[e-mail]>; Thu,  8 Jun 2006 17:01:26 +0200 (CEST)
Date: Thu, 8 Jun 2006 17:00:16 +0200
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
From: [e-mail] (Ralph Babel)
To: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
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:

> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>
> A - I believe it is ready to go forward.

I'd be _ashamed_ to call something like this "ready".

> B - I believe issues must be fixed; all my issues have
>     been raised by others, and once these are resolved,
>     I believe it is ready.

No.

> C - I believe issues must be fixed; the following
>     issue has not been raised so far:

See below.

> D - I have another opinion, which is:

Protocol-wise, netnews and NNTP still beat all of
the web-based forums/blogs/feeds hands down, but
politically, Usenet and Usefor are a hopeless case.

> 2) How should draft-ietf-usefor-usefor-08 be carried
>    forward?
>
> A - Pass draft-ietf-usefor-usefor to the IESG for
>     IETF-wide Last Call and processing (knowing that
>     it will likely be in REF hold at the RFC Editor
>     until draft-ietf-usefor-usepro is finished)

No. There are far too many references to documents that
are both controversial _and_ still in a state of flux.

> B - Put draft-ietf-usefor-usefor into a "WG-internal
>     frozen state", where we will promise to only change
>     it if work on USEPRO proves to us that we have
>     something wrong in -usefor-.

No.

> C - I have another opinion, which is

... to give up. Okay, since you don't seem to be willing
to accept this choice, I vote for B - under protest.

------------------------------------------------------------

| The list of current Internet-Drafts can be accessed
| at http://www.ietf.org/ietf/1id-abstracts.txt.
|
| The list of Internet-Draft Shadow Directories can be
| accessed at http://www.ietf.org/shadow.html.

Might be a good idea to use angle brackets
to separate URLs from punctuation.

| Abstract
|
| This document supersedes RFC 1036, updating it to reflect
| current practice and incorporating incremental changes
| specified in other documents.

Judging by the usual RFC conventions, I'd say that
"supersedes" and "updating it" are mutually exclusive.

"... obsoletes RFC 1036, providing an
updated specification to reflect ..."

| 1.1.  Basic Concepts
|
| "Netnews" is a set of protocols for generating, storing
| and retrieving news "articles" (whose format is a subset
| of that for Email messages) and for exchanging them

Add comma after closing parenthesis. (Oxford comma
is used (almost) everywhere else in the draft.)

| amongst a readership which is
| potentially widely distributed.

General: replace "which" by "that" in
restrictive clauses for ease of reading?

| 1.2.  Scope
|
| This document supersedes [RFC1036], updating it to
| reflect current practice and incorporating changes and
| clarifications specified in other documents such as
| [Son-of-1036].

See above.

| [I-D.ietf-usefor-usepro] is also a standards-track
| document, and describes the protocol issues of Netnews
| articles, independent of transport protocols such as
| [I-D.ietf-nntpext-base].

No comma after "document".

| A best common practice document,

"best-common-practice document"

| 1.3.  Requirements Notation
|
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
| "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
| and "OPTIONAL" in this document are to be interpreted as
| described in [RFC2119].

"SHALL", "SHALL NOT", "RECOMMENDED", and "OPTIONAL" do not
even occur in the draft.

| 1.4.  Syntax Notation
|
| dot-atom-text = <see RFC2045 Section 5.1>
| dot-atom-text = <see RFC2822 Section 3.2.4>

First one is incorrect.

| 1.5.  Definitions

This section probably needs to be rewritten from scratch.
Even though this group decided to abandon the muddy "agent"
nomenclature, many of the subdefinitions are still based on
it, if only to define a single type of agent ("injection",
"proto-article"). Many other "definitions" are unclear,
circular, or not overly helpful.

| A "message identifier" (Section 3.1.3) is a unique
| identifier for an article, usually supplied by the
| "user agent" that posted it or, failing that,
| by the "news server".

Any statistics to back the "usually"?

Besides, I see a contradiction between the strict
"mandatory/optional header field" duality described by
this draft and news servers adding missing "mandatory"
header fields. Obviously, we need to make clear to
whom "mandatory" applies.

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

Remove first "single".

"intended for articles on a specific topic"? Well,
maybe, assuming a suitable definition of "topic".

| When an article is posted to more than one
| newsgroup, it is said to be "crossposted";

"crossposted" is used only once, in the "Xref" section.

| A newsgroup may be "moderated", in which case submissions
| are not posted directly, but mailed to a "moderator" for
| consideration and possible posting. Moderators are
| typically human but may be implemented partially or
| entirely in software.

The word "moderated" occurs only once,
in the "Approved" section.

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

Actually, I'd associate "poster" with "sender", not "author"
(and so does section 3.2.14). Why not simply use "author"
for "From:" and "sender" for "Sender:"? This way, the draft
would be less likely to confuse readers, in particular once
they run across the "Followup-To: poster" functionality,
which needs to take "Reply-To:" into account.

| A "followup" is an article containing a response to
| the contents of an earlier article, its "precursor".

That's "follow-up" according to my edition of Webster's.

| Every followup includes a "References"
| header field identifying that precursor

That and the previous sentence basically mean
"an article not containing a References header
field is not a follow-up". Not overly useful.

| a news server receiving such an article may (subject
| to the policies observed at that site) take actions
| beyond just filing and passing on the article.

So does "Supersedes" make an article a control message?

| The generic term "agent" is used when describing
| requirements that apply to both user agents and
| news servers.

The term "news agent" is used in the draft as well. For
clarity, it should be either "agent" or "news agent".
Or at least "news agent" should be mentioned as an
alternative term in the sentence above. The draft also
uses both "news article[s]" and "Netnews article[s]".

| 1.6.  Structure of This Document

I'd use a lowercase "this" here (it's "Status of this Memo"
further above), but I'm well aware of the many different
conventions for capitalization in headings.

| This document uses a cite by reference methodology,

"cite-by-reference methodology".

| rather than repeating the contents of other standards,
| which could otherwise result in subtle differences and
| interoperability challenges.

It is unclear to which of the
two options the "otherwise" refers.

| Although this document is as a result rather short,
| it requires complete understanding and implementation
| of the normative references to be compliant.

"it" (= "the document"?) requires
understanding to _be_ compliant? - Ouch.

| 2.1.  Base
|
| An article is said to be conformant to this specification
| if it conforms to the format specified in [RFC2822]
| Section 3

"as amended by the MIME RFCs"

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

Add "the" after "for".

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

So the resulting article is conformant, but the agent that
generated it isn't? That's an unfortunate choice of words,
in particular in light of the following sentence:

| Agents conforming to this specification
| MUST generate only conformant articles.

We could phrase it similar to the "GMT" issue.

| Handling of non-conformant articles is
| outside the scope of this specification.

Actually, that's not quite true: We do give explicit
permission to accept long header fields/lines or header
fields that do not contain a space after the colon.

| 2.2.  Header Fields
|
| All header fields in a news article are compliant with
| [RFC2822], however this specification is less permissive
| in what can be generated and accepted by news agents.

Slightly misleading "however". Should probably be
"... [RFC2822]; this specification, however, is ...".

| The syntax allowed for news articles is a strict subset
| of the "Internet Message Format", making all messages
| compliant with this specification inherently compliant
| with [RFC2822].

"... as extended by the MIME RFCs."

Otherwise, since we're not redefining <text> (and of
course we shouldn't be), anything other than "7bit" and
"quoted-printable" would not conform to this draft.

While section 2.2 is about "header fields", there is no
corresponding section on article bodies, so we should
either add one or rename that section.

| General rules which apply to all header fields (even those
| documented in [RFC2822] and [RFC2045]) are listed below

Missing comma after "below".

| and those that apply to specific header fields are
| described in the relevant sections of this document.

It's also the article _body_ that matters.

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

It says "header fields" here ...

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

Missing comma after "[RFC2047]".

| [I-D.ietf-usefor-useage] includes suggested
| limits for convenience of display by user agents.

Crystal-ball mode detected!

| (in particular it may, by suitable folding, be made
| to exceed the 998 octets restriction pertaining to
| a single header line).

... but "header line" here.

While the 998-character limit originally applied to the raw
line, there may well be reasons to limit an entire header
field. In fact, some software does reject articles based
on the length of the header _field_, not (just) line.

| 2.3.  MIME Conformance
|
| User agents MUST meet the definition of MIME-conformance
| in [RFC2049] and MUST also support [RFC2231].

"MIME conformance", as in the section title.

| This level of MIME Conformance provides support
| for internationalization and multimedia in message
| bodies ([RFC2045], [RFC2046], [RFC2231]),

"MIME conformance", no capitalization.

| 3.1.  Mandatory Header Fields
|
| Each news article conformant with this specification MUST
| have exactly one of each of the following header fields:
| From, Date, Message-ID, Subject, Newsgroups, Path.

So we should point out that this draft doesn't apply
to communication between user agents and news servers.

| 3.1.1.  From
|
| The From header field is the same as that specified in
| Section 3.6.2 of [RFC2822] with the added restrictions
| detailed in Section 2.2.

Section 2.2 of RFC 2822 or of the draft? Add "above"?

| from = "From:" SP mailbox-list CRLF

"mailbox-list" is a change from 1036 that
deserves to be documented in appendix B.

| 3.1.2.  Date
|
| The Date header field is the same as that specified
| in Sections 3.3 and 3.6.1 of [RFC2822] with the added
| restrictions detailed in Section 2.2.

Again, "above". Occurs a few more times.

| Also note that these requirements apply wherever
| <date-time> is used, including Injection-Date and Expires
| in Section 3.2.1 and Section 3.2.4 respectively.

Add comma before "respectively".

| 3.1.3.  Message-ID
|
| The Message-ID header field contains
| a single unique message identifier.

What purpose does the "single" serve here?

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

It's not just retrieval. For instance, a news server
may suggest or report a message ID when an article
is posted. We could say "when referencing".

| Observe that msg-id includes the < and >.

Actually, it might be a good idea to provide a token
that describes the message ID _without_ its enclosing
angle brackets, e.g. for use in a news URL RFC.

| 3.1.4.  Subject
|
| Further discussion of the content of the Subject header
| field appears in [I-D.ietf-usefor-usepro] and
| [I-D.ietf-usefor-useage].

Crystal-ball alert!

| 3.1.5.  Newsgroups
|
| A newsgroup component SHOULD NOT consist of digits only,
| and SHOULD NOT contain uppercase letters.

Remove comma.

| Such components MAY be used only to refer to existing
| groups that do not conform to this naming scheme.

I find this a little wishy-washy. The syntax clearly states
that a newsgroup name may well contain all-digit components
or uppercase letters; the two "SHOULD NOT"s warn about
compatibility issues. _Of_ _course_, clients and servers are
free to support the full syntax. So what's this "MAY" about?

| Mixed case groups cause confusion between systems
| with case sensitive matching and systems with
| case insensitive matching of <newsgroup-name>s.

"Mixed-case", "case-sensitive", "case-insensitive".

| <component>s beginning with underline ("_") are reserved
| for use by future versions of this standard and MUST NOT
| be generated by user agents

Just user agents? What about servers _generating_ components
like these? After all, the newsgroups listed in "Xref" are
documented as not necessarily agreeing with the Newsgroups
header field, so news servers may well generate newsgroup
names themselves in articles.

| (whether in Newsgroups header fields

What about "Followup-To" header fields?

| or in newgroup control messages [I-D.ietf-usefor-usepro]).

Add "as defined by" before "[I-D.ietf-usefor-usepro]".

| However, such names MUST be accepted by news servers.

Just by servers? What about user agents?

| <component>s beginning with "+" and "-" are reserved for
| private use and MUST NOT be generated by user agents

As above.

| (whether in Newsgroups header fields

As above.

| or in newgroup control messages [I-D.ietf-usefor- usepro])

As above.

| such names MUST be accepted by news servers.

As above.

| The following <newsgroup-name>s are reserved,
| and MUST NOT be used as the name of a newsgroup:

Remove comma after "reserved".

| Groups whose first (or only) component is "example"

"<component>"?

| The following <newsgroup-name>s have been used for
| specific purposes in various implementations and
| protocols, and therefore MUST NOT be used
| for the names of normal newsgroups.

Remove comma after "protocols".

| They MAY be used for their specific purpose,
| or by local agreement.

Remove comma after "purpose".

| "example.*" is reserved for examples
| in this and other standards;

This draft does not contain any such example.

| "to.*" is reserved for certain
| point-to-point communications

Really plural?

| in conjunction with the "ihave" control message
| [I-D.ietf-usefor-usepro];

Add "defined in" after "message".

| "control.*" and "junk" have special meanings
| in some news-servers;

"news servers".

| and "ctl" was formerly used to indicate a
| <control-command> within the Subject header field.

No, not the "Subject" header field; that was the
"cmsg" mechanism. "ctl" was used in "Newsgroups".

| 3.1.6.  Path
|
| Each agent that processes an article is required to
| prepend at least one <path-identity> to this header
| field body.

Well, no; not strictly. An agent _forwarding_ an article is
required to have prepended its own identity to the beginning
of the path of the forwarded article. What happens locally
("processes") is outside the scope of this draft.

| This is primarily to enable news servers to avoid
| sending articles to sites already known to have them,

Path-preloading needs to be mentioned in section 5.

| NOTE: Although case-insensitive,

If the path or components of it are to be treated as
case-insensitive, this needs to be mentioned outside
of a "note". Traditionally, the path and UUCP names
were case-sensitive; domain names are case-insensitive.
So we need to make clear what the status of each of the
individual components is.

| it is intended

"intended"? Ah, the obligatory work-in-progress reference.

| that the <path-keyword>s should be in upper case,

"<diag-keyword>" maybe?

| 3.2.  Optional Header Fields
|
| None of the header fields appearing in this section
| is required to appear in every article but some of
| them may be required in certain types of articles.

Add comma before "but".

| Further discussion of these requirements appears in
| [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage].

Section 1.5 already contains one such requirement.

| The header fields Reply-To, Sender, Comments, and Keywords
| are used in news articles in the same circumstances and
| with the same meaning as that specified in [RFC2822]

Consistency: "meaning ... that" here, but ...

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

... "meanings ... those" here.

| Multiple occurances of the Keywords
| header field are not permitted.

"occurrences".

| 3.2.1.  Injection-Date
|
| 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.

If they have already "expired", then "reinjection"
isn't an issue. Quite the contrary: once everybody starts
depending on "Injection-Date" and - ignoring "Date" - uses
it to check against the history cut-off limit, reinjection
of stale articles (after stripping "Injection-Date",
of course) will become a lot _easier_.

I thought its purpose was to aid in the _propagation_ of
articles that are "injected" a long time _after_ their
"Date" header field has been added locally by the client.

| This header field MUST be inserted
| whenever an article is injected.

By whom? And when exactly does "injection" take place?

| software that predates this standard does not use
| this header, and therefore agents MUST accept
| articles without the Injection-Date header field.

I consider this to be a contradiction. We cannot make an
experimental header field (and that's what "Injection-Date"
is at this point) mandatory (see "MUST be inserted" above).

The first step will have to be a "MAY",
default value being the "Date" header field body.

| Since clocks on various agents may not be synchronized,
| the <date-time> in this header field may not be later
| than the Date header field,

"may" could be misread as a 2119-like "MAY" here.

I'd replace "may not be" by "are not necessarily".

| as would be expected.

Replace "would" by "might".

| Agents SHOULD use the <date-time> they
| believe is correct when adding Inject-Info

Beg pardon? This sounds rather redundant.

| but SHOULD NOT alter the pre-existing Date header field.

Replace "the" by "a".

| This header field is intended to replace the
| currently-used but undocumented "NNTP-Posting-Date"
| header field, whose use is now deprecated.

I'm not aware of "NNTP-Posting-Date" ever having been
anything but a trace field, so it served a completely
different purpose.

| 3.2.3.  Followup-To
|
| The Followup-To header field specifies to which
| newsgroup(s) followups should be posted.

"... according to the author".

The draft needs to make it absolutely clear that
this is nothing but a _suggestion_ by the author.

| The syntax is the same as that of the Newsgroups (Section
| 3.1.5) header field, with the exception that the keyword
| "poster" requests that followups should be mailed to the
| article's reply address rather than posted.

"reply address" needs clarification.

| 3.2.4.  Expires
|
| The Expires header field specifies a date and time when
| the article is deemed to be no longer relevant and could
| usefully be removed ("expired").

How about a note that this is used both to reduce and to
extend the "regular" expiration period and that the local
effects are implementation/configuration-specific?

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

"... meaning; see [RFC2156]."

| 3.2.5.  Control
|
| The Control header field marks the article as a control
| message, and specifies the desired actions (additional to
| the usual ones of storing and/or relaying the article).

Remove comma before "and".

| 3.2.6.  Supersedes
|
| The Supersedes header field contains a message identifier
| specifying an article to be superseded upon the arrival
| of this one.

So what does "superseded" mean? I'd add something along the
lines of "The local effects of superseding an article are
implementation-specific.".

| the syntax here permits only one <msg-id> in contrast
| to the multiple <msg-id>s in that Email version.

Actually, s-o-1036 _did_ permit multiple message IDs,
which should also be mentioned in appendix B.

| 3.2.7.  Distribution
|
| The Distribution header field specifies geographic or
| organizational limits on an article's propagation.

Doesn't say a whole lot about how it actually _works_.
A few words to the effect that a site may consider itself
(or others) to be a member of one or more <dist-name>s?

| The <dist-name>s "world" and "local" are predefined.

Where? In which way?

| "All" MUST NOT be used as a <dist-name>.

So it's sort of predefined as well, isn't it?

| 3.2.9.  Approved
|
| Its principal uses are in moderated articles and
| in group control messages [I-D.ietf-usefor-usepro].

"... messages; see [I-D.ietf-usefor-usepro]."

| one of those mailboxes MUST be that
| of the actual sender of the article.

Huh? Why and since when? There has never been a requirement
of this kind, at least not in Usenet as deployed in _my_
universe. A moderator (or anybody else wishing to use that
header) is certainly free to have somebody else inject his
messages on his behalf without listing the sender in the
Approved header field.

| (e.g. digitial signatures).

"digital".

| 3.2.11.  Xref
|
| The Xref header field indicates where an article was
| filed by the last news server to process it. The article
| locations are used to keep track of crossposted articles
| so that user agents serviced by a particular news server
| can mark such articles as read.

"by that particular" (= "the last
news server to process it").

| article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )

I probably missed the discussion on this one, but is
anyone actually making use of anything but digits?

| 3.2.12.  Archive
|
| The absence of this header field, or the presence of this
| header field with a field body of "yes", indicates that
| the poster is willing for such redistribution to take
| place.

The default value in absence of this header is a copyright
issue subject to numerous local jurisdictions we cannot
reasonably take a stand on.

It makes a difference whether a private company like
Dejanews, Altavista, or Google defines the default of
a nonstandard header field this way or whether an RFC
does so for what is to become a standard header.

The draft should simply remain silent on the default.

The change was introduced without discussion in
draft-ietf-usefor-usefor-02.txt, and I don't see any
justification for it; in fact, the ramifications
were discussed in May/June 2001 already:

 <[e-mail]>
 <[e-mail]>

| Further extensions to this standard may provide
| parameters for administration of the archiving process.

Crystal-ball mode again.

Replace by "No parameters are currently defined.".

| 3.2.13.  User-Agent
|
| This header field MAY contain multiple product-tokens

"<product> tokens".

| listed in order of their significance

Ascending or descending?

| [RFC2616] describes a similar facility for the HTTP
| protocol. This specification differs in that "{" and "}"
| are allowed in tokens (<product> and <product-version>)
| and comments are permitted wherever whitespace is allowed.

The use of "This" is ambiguous here.

Replace by "The netnews article format".

| 3.2.14.  Injection-Info

See <[e-mail]>; after all,
"injection" is not clearly defined by this draft, and
there's a <path-identity> anyway; let's put it to some use.

There was also strong support for
generic complaints URLs, not just mail.

| The Injection-Info header field contains
| information provided by the injecting news server

"injecting news server" seems a misnomer to me. It's
not the server that is "injecting". "injection" maybe?

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

How does the "@" fit into <host-value>/<dot-atom-text>?

| Although comments and folding of white space are
| permitted throughout the Injection-Info header field,

"folding _of_ white space"? "at"? "upon"?

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

If this is a newly defined header field, how can 2119
language apply here? What are the interoperability
issues as required by RFC 2119 section 6?

| 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 usual form is "X-Trace".

| it SHOULD be given in a form that
| can't be interpreted by other sites.

"sites" can interpret data? Not really.

| Some pieces of information have privacy implications;
| this is discussed in [I-D.ietf-usefor-useage].

Crystal-ball mode again.

| 3.3.  Obsolete Header Fields

So many words, so little effect. If we can obsolete (see
section 6) non-RFC headers such as those from s-o-1036,
what's the problem with these headers from RFC 850? Yes,
850 is a "nonstandard". So how is this different from
1036 and s-o-1036?

My suggestion: Replace the entire section by ...

| The header field names Date-Received, Posting-Version, and
| Relay-Version defined in [RFC850] as well as Also-Control,
| Article-Names, Article-Updates, and See-Also defined in
| [Son-of-1036] are declared obsolete. See the original
| documents for further information on their original use.

I'm not aware of anything that breaks _if_ these
header fields are included in an article, so
there's no need for 2119 language.

Add to section 6:

| Header field name: Date-Received
| Applicable protocol: netnews
| Status: obsoleted
| Author/change controller: IETF
| Specification document(s): [RFC850] (section 2.2.4)
|
| Header field name: Posting-Version
| Applicable protocol: netnews
| Status: obsoleted
| Author/change controller: IETF
| Specification document(s): [RFC850] (section 2.1.2)
|
| Header field name: Relay-Version
| Applicable protocol: netnews
| Status: obsoleted
| Author/change controller: IETF
| Specification document(s): [RFC850] (section 2.1.1)

(or "historic" instead of "obsoleted")

Add to section 7.2:

| [RFC850]  Horton, Mark R., "Standard for Interchange
|           of USENET Messages", RFC 850, June 1983.

| 3.3.1.  Lines
|
| The Lines header field indicates the number
| of lines in the body of the article.
|
| lines =  "Lines:" SP *WSP 1*DIGIT *WSP CRLF
|
| The line count includes all body lines, including the
| signature if any, including empty lines (if any) at the
| beginning or end of the body, and including the whole of
| all MIME message and multipart parts contained in the body
| (the single empty separator line between the header fields
| and the body is not part of the body). The "body" here is
| the body as found in the posted article as transmitted by
| the user agent.

Again, so many words ...

For short: "the number of CRLF-separated
<*998text> productions in the <body>".

(Do we really wish to support articles
without a trailing CRLF as per 2822?)

| this header field was used by the
| [I-D.ietf-nntpext-base] Overview facility,

"overview"; see "capitalization" below.

| Servers and clients SHOULD ignore it,
| and SHOULD NOT generate it.

Remove comma.

| 5.  Security Considerations
|
| Additionally, several currently non-standardized
| protocols [PGPVERIFY] will hopefully be standardized
| in the near future.

Insert "such as" before "[PGPVERIFY]".

Replace "will hopefully" by "may".

| articles are refused

"may be refused". After all, there's
a limit to a server's history size.

| (in server-to-server transfer)
| if the identifier has already been seen.

Not just in server-to-server transfer.

| Such differences in parsing may
| be used as part of an attack.

"differences"? "deviations" or "deficiencies" maybe?

| 6.  IANA Considerations
|
| Header field name: Also-Control
| Status: obsoleted
| Author/change controller: IETF
|
| Header field name: Article-Names
| Status: obsoleted
| Author/change controller: IETF
|
| Header field name: Article-Updates
| Status: obsoleted
| Author/change controller: IETF
|
| Header field name: See-Also
| Status: obsoleted
| Author/change controller: IETF

These are not strictly IETF header fields,
so their status may have to be "deprecated".

| Header field name: Comments
| Header field name: Date
| Header field name: From
| Header field name: Keywords
| Header field name: References
| Header field name: Reply-To
| Header field name: Sender
| Header field name: Subject

Is there a reason why it's ...

| Specification document(s): This document (Section 3.X),
| [RFC2822] (Section 3.Y)

... for the fields above, but ...

| Specification document(s): This document (Section 3.1.3)
| Related information: [RFC2822] (Section 3.6.4)

... for Message-ID?

I'd suggest the latter - if only to avoid the line break.

| Header field name: Archive
| Status: standard
|
| Header field name: Injection-Date
| Status: standard
|
| Header field name: Injection-Info
| Status: standard

Isn't that "experimental" for now? After all,
there's not a single implementation yet, is there?

| Header field name: Lines
| Status: deprecated

"deprecated" isn't listed among the preferred values for
IETF documents, and we call it "obsolescent" in 3.3.1.

| Header field name: NNTP-Posting-Date
| Status: obsoleted
| Author/change controller: IETF
|
| Header field name: NNTP-Posting-Host
| Status: obsoleted
| Author/change controller: IETF

According to section 3.2.1, it's "deprecated".
Are these really IETF header fields?

| Header field name: User-Agent

Add "Related information: [RFC2616] (section 14.43)".

| [Errata] "RFC Editor Errata".

Add "<URL:http://www.rfc-editor.org/errata.html>".

| [ISO.3166.1988]

Not strictly the same, but add ...

<URL:http://www.iso.org/iso/en/prods-services/iso3166ma/index.html>

... maybe?

| [PGPVERIFY] Lawrence, D., "PGPverify", June 1999.

"pgpverify" is a minimum of two years older; at least that's
when I first mentioned the replay attack against the de.*
hierarchy key. What exactly is the draft referring to?

| As this document is the result of an eight year effort,

"nine-year effort".

| the number of people that have contributed to its
| content are too numerous to mention individually.

Replace by "Unfortunately, nine years didn't provide
enough time to give credit where credit is due."

| Appendix B.  Differences from RFC 1036 and its derivatives
|
| This appendix contains a list of changes that have been
| made in the Netnews Article Format from earlier standards,
| specifically [RFC1036].

See "capitalization" below.

| They are, however, still disallowed for performance and/or
| compatibility reasons in the Message-ID, Newsgroups, Path,
| Followup-To, Control, Supersedes, Distribution, Xref and
| Lines header fields.

Add comma after "Xref".

| An enhanced syntax for the Path header field enables the
| injection point of, and the route taken by an article to
| be determined with more precision.

Either remove comma after "of" or add comma after "by".

| There is a new Injection-Date header to make the rejection
| of stale articles more precise and to minimize spurious
| rejections.

"header field".

| There are several new optional header fields defined,
| notably Archive, Injection-Info and User-Agent,
| leading to increased functionality.

Add comma before "and".

| There are numerous other small changes,
| clarifications and enhancements.

Add comma before "and".

| Intellectual Property Statement

"Intellectual" refers to "Property", not
to "[Property] Statement", so there's a hyphen
missing between "Intellectual" and "Property".

| Copies of IPR disclosures made to the IETF Secretariat and
| any assurances of licenses to be made available, or the
| result of an attempt made to obtain a general license or
| permission for the use of such proprietary rights by
| implementers or users of this specification can be
| obtained from the IETF on-line IPR repository at
| http://www.ietf.org/ipr.

Either superfluous comma after "available"
or missing comma after "specification".

| Disclaimer of Validity
|
| This document and the information contained herein are
| provided on an "AS IS" basis and THE CONTRIBUTOR, THE
| ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF
| ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
| TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
| THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
| IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
| PARTICULAR PURPOSE.

Missing comma after "basis".

------------------------------------------------------------

Typographical issues:

- Line breaks within tokens, reference labels,
  and header field names are irritating.

- Inconsistency: "nonstandard" vs. "non-standard".

- As the draft does not make use of quotation marks around
  header field names in continuous text but relies solely
  on capitalization instead, I would suggest that all other
  capitalization be kept to a minimum for ease of reading:
  "e-mail" instead of "Email" (as discussed), "netnews",
  "section", "appendix".

- I would also suggest that in the table of contents and
  in section headings - like in continuous text -, chapter
  and section numbers be used without a trailing dot.



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 k586pkgs014356; Wed, 7 Jun 2006 23:51:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k586pkSY014350; Wed, 7 Jun 2006 23:51:46 -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 k586phtS014313 for <[e-mail]>; Wed, 7 Jun 2006 23:51:45 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97572259716; Thu,  8 Jun 2006 08:50: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 30754-06; Thu,  8 Jun 2006 08:50:40 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0F7A2580D1; Thu,  8 Jun 2006 08:50:40 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 07 Jun 2006 23:51:38 -0700
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Richard Clayton <[e-mail]>
Cc: [e-mail]
Subject: "Generate" (Re: WG Last Call: draft-ietf-usefor-usefor-08)
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>

Thanks for the review, Richard!

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <[e-mail]>, Harald Alvestrand
> <[e-mail]> writes
>
>   
>> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
>> this Last Call with your answer on the two following points:
>>
>> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>>
>> C - I believe issues must be fixed; the following issue has not been 
>> raised so far: .....................
>>     
>
> I'm coming at this as "what do I need to do to my software to handle
> this revised standard...".  So I'm very interested in seeing precisely
> what I have to do (and what is entirely avoidable)
>
> - -=-=-=-=-=-
>
> #2.1 says that user agents must not "generate" a specific obsolete
> construct. But in the long list of definitions in #1.5 there is no
> meaning given to generate.  I suspect what is meant that a user agent
> must not accept an article from a poster if it contains this construct.
> We'd surely expect user agents to do all the other things (give it to
> readers, swap it with other sites etc)
>
> A little further down "generate" is used again, but this time for all
> agents...  "Agents conforming to this specification MUST generate only
> conformant articles."   which, if I knew from the spec what "generate"
> meant would probably be a tautology :(
>
> There's more mentions of "generate" later on in the document as well...
> in one case this covers the creation of a new Path: header field, and so
> generate means a bit more than what one might loosely call "posting".
> Hence I think it's rather important to be more clear what's going on.
I think the intention of "generate" was to say "create something", as 
opposed to "copy something that someone else has generated".

This is especially obvious in the section on the "newsgroups" header, 
which states a number of places where something MUST NOT be generated, 
but MUST be accepted - which means, in many cases, that you have to pass 
it on if you're given the junk.

In the case of an user agent, the theory is that the article did not 
exist before, so the user agent has to take full responsibility for 
making it conform (I think).

Suggestions for a definition of "generate", anyone?




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 k586idah009827; Wed, 7 Jun 2006 23:44:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k586idri009826; Wed, 7 Jun 2006 23:44: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 k586icp9009811 for <[e-mail]>; Wed, 7 Jun 2006 23:44: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 487E525971D; Thu,  8 Jun 2006 08:43:39 +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 30708-04; Thu,  8 Jun 2006 08:43:36 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DDA2259716; Thu,  8 Jun 2006 08:43:36 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 07 Jun 2006 23:44:34 -0700
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Harald Alvestrand <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
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>

It's about time to give my answers.

Harald Alvestrand wrote:
>
> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>
> B - I believe issues must be fixed; all my issues have been raised by 
> others, and once these are resolved, I believe it is ready.

> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
>
> Possible answers:
>
> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
> and processing (knowing that it will likely be in REF hold at the RFC 
> Editor until draft-ietf-usefor-usepro is finished)
>
>
Getting the rest of the IETF to look at the document is, IMHO, important.




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 k581jPtE039511; Wed, 7 Jun 2006 18:45:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k581jPrx039510; Wed, 7 Jun 2006 18:45:25 -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-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k581jNhE039487 for <[e-mail]>; Wed, 7 Jun 2006 18:45:23 -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-30.mail.demon.net with esmtp (Exim 4.42) id 1Fo9aL-0002q4-1H; Thu, 08 Jun 2006 01:45:21 +0000
Message-ID: <[e-mail]>
Date: Thu, 8 Jun 2006 02:44:03 +0100
To: Harald Alvestrand <[e-mail]>
Cc: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <396$+jg$77vatOKLkuc+dO76Zc>
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]>, Harald Alvestrand
<[e-mail]> writes

>Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
>this Last Call with your answer on the two following points:
>
>1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>
>C - I believe issues must be fixed; the following issue has not been 
>raised so far: .....................

I'm coming at this as "what do I need to do to my software to handle
this revised standard...".  So I'm very interested in seeing precisely
what I have to do (and what is entirely avoidable)

- -=-=-=-=-=-

#2.1 says that user agents must not "generate" a specific obsolete
construct. But in the long list of definitions in #1.5 there is no
meaning given to generate.  I suspect what is meant that a user agent
must not accept an article from a poster if it contains this construct.
We'd surely expect user agents to do all the other things (give it to
readers, swap it with other sites etc)

A little further down "generate" is used again, but this time for all
agents...  "Agents conforming to this specification MUST generate only
conformant articles."   which, if I knew from the spec what "generate"
meant would probably be a tautology :(

There's more mentions of "generate" later on in the document as well...
in one case this covers the creation of a new Path: header field, and so
generate means a bit more than what one might loosely call "posting".
Hence I think it's rather important to be more clear what's going on.

I note that the definition of the Path header field uses the term
"injection" which is apparently different again. Indeed it pops up again
in #3.2.1 (not surprisingly) but I wonder what it means :(


Then #2.1 says

   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.

could we run these two paragraphs together... they're inextricably
linked.

#3.1.6

   This is primarily to enable news servers to avoid
   sending articles to sites already known to have them

        to enable to avoid to sites ...  ain't grammar :(

        This is primarily so that news servers are able to avoid..

#3.2    occurances -> occurrences

#3.2.1
   NOTE: Since clocks on various agents may not be synchronized, 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 header field.

   horribly sub-clauses, why not:

        NOTE: It might be expected that the <date-time> in the Date
        header field would be earlier than the Injection-Date header
        field's value. However, clocks on different machines may not be
        synchronised, so this will not necessarily be the case. Agents
        SHOULD ... etc

3.2.3.  Followup-To

   The Followup-To header field specifies to which newsgroup(s)
   followups should be posted.  

        since that's not SHOULD, would it not be clearer to say "to
        which newsgroup(s) the poster has requested that followups are
        to be posted"

#3.2.9  digitial -> digital

3.2.11.  Xref

   The Xref header field indicates where an article was filed by the
   last news server to process it.  The article locations are used to
   keep track of crossposted articles so that user agents serviced by a
   particular news server can mark such articles as read.

        the second sentence doesn't illuminate

        Why not replace it by

        User agents often use the information in the Xref field to avoid
        multiple processing of crossposted articles.

3.2.13.  User-Agent

   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.

        does that last sentence mean that it shouldn't contain NULs ?

        "in Email" doesn't mean all that much to me :(

        frankly all the ABNF here is a waste of time, make it freeform
        text because I assure you that's all that software authors will
        bother with

3.2.14.  Injection-Info

these sections appear to be in a random order. Either make them
alphabetical or arrange them by topic. Injection-Info and Injection-Date
belong next to each other

>2) How should draft-ietf-usefor-usefor-08 be carried forward?
>
>Possible answers:
>
>A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
>and processing (knowing that it will likely be in REF hold at the RFC 
>Editor until draft-ietf-usefor-usepro is finished)

if we do this, people might consider it finished and start changing
their software. Overall, that's probably a good thing...

>C - I have another opinion, which is........

... BUT

It's several years since I last read this document carefully from one
end to other.  To be honest, I find many paragraphs unnecessarily
confusing (the worst stuff I've picked out above).

There's no very clear sense here of the life history of articles, what
stages they pass through and what sort of changes and validation are
permitted when. That's quite important :(

The definitions are sloppy and frankly rather strange. The sloppiness
I've picked out above; for a "strange" example: "proto article" is only
ever used in the definition of "user agent" -- and so I'm not really
entirely clear why it needs defining. If you want to say "some header
fields are not made by the user" then say that. If you want to say "when
articles are posted the user agent must ensure that any header fields
required by this standard are added" then say that!

The general chatty tone and abbreviation -- using netnews sometimes,
then news, using "email" but "mailed to" ... and there's many other
examples, frankly makes the standard hard to read -- and if you are not
an English native speaker I'm not sure you'll understand when a
shorthand is being used and when a different concept is meant.

So my opinion is that someone skilled at precise technical writing
should go through the thing from top to bottom to produce a document
which is considerably more inspiring to read... the current one is
second-rate and should not in my opinion go anywhere near a critical
readership.

So in the end I think I'm a (B) but it should not be frozen textually
just frozen conceptually -- and sometime who can write carefully should
rework it to say the same thing but a heck of a lot more precisely and
preferably with a bit more flair!

Finally, just to confuse the chair even more -- I have considerable
sympathy with the "just throw it away" school of thought. Son-of-RFC1036
was a much more useful document in understanding what you need to build
and indeed why :( 

>This WG Last Call will end two weeks from now, on June 8, 2006, at 17:02 
>Central European Time.

had a lot of other things to do :(  with earlier deadlines! Apologies
for coming in with all this so late.

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

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

iQA/AwUBRIeA45oAxkTY1oPiEQLiCQCfY4eMwDE2FYseSVDgwct7bEU3GHMAoJM5
0Gp+c98lFS4wtksYI395f5Rm
=pYsk
-----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 k57BDOSt099296; Wed, 7 Jun 2006 04:13:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k57BDOOs099295; Wed, 7 Jun 2006 04:13:24 -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-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57BDNVi099279 for <[e-mail]>; Wed, 7 Jun 2006 04:13:23 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-66-143.midband.mdip.bt.net ([81.144.66.143] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 4486b4d0.f7df.25a for [e-mail]; Wed,  7 Jun 2006 12:13:20 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k57BCNY20864 for [e-mail]; Wed, 7 Jun 2006 12:12:23 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23305
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Wed, 7 Jun 2006 09:27:09 GMT
Lines: 29
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]> Ken Murchison <[e-mail]> writes:

>Harald Alvestrand wrote:
>> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
>> and processing (knowing that it will likely be in REF hold at the RFC 
>> Editor until draft-ietf-usefor-usepro is finished)
>> 
>> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
>> where we will promise to only change it if work on USEPRO proves to us 
>> that we have something wrong in -usefor-.

>A.  We should make it as painful as possible to ticker with, but we can 
>still make changes if absolutely necessary.

Sure. My understanding of B is that it would include painful procedures
against tinkering. What I had in mind was "further changes only with the
explicit permission of the Chair". I think we can assume that Harald would
not give such permission lightly.

-- 
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 k576BZqm015172; Tue, 6 Jun 2006 23:11:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k576BYQg015171; Tue, 6 Jun 2006 23:11:34 -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 k576BX23015159 for <[e-mail]>; Tue, 6 Jun 2006 23:11:33 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62F27259702; Wed,  7 Jun 2006 08:10: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 22194-06; Wed,  7 Jun 2006 08:10: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 0EDB02596CB; Wed,  7 Jun 2006 08:10:32 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 07 Jun 2006 08:11:27 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Graham Drabble <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
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>

Graham Drabble wrote:
> On 25 May 2006 Harald Alvestrand <[e-mail]> wrote in
> news:[e-mail]: 
>
>   
>> Please - once you have reviewed draft-ietf-usefor-usefor-08 -
>> reply to this Last Call with your answer on the two following
>> points: 
>>     
>
> I've not had time to do a detailed review, I've had a thesis to 
> write. :-( However I've not noticed anything major.
>  
>   
>> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>>
>> B - I believe issues must be fixed; all my issues have been raised
>> by others, and once these are resolved, I believe it is ready.
>>     
>
> Once Charles' comments have been addressed.
>
>   
>> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
>>
>> Possible answers:
>>
>> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last
>> Call and processing (knowing that it will likely be in REF hold at
>> the RFC Editor until draft-ietf-usefor-usepro is finished)
>>
>> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen
>> state", where we will promise to only change it if work on USEPRO
>> proves to us that we have something wrong in -usefor-.
>>     
>
> If we go to A and then decide whilst doing usepro that we made a 
> mistake with usefor what's the procedure for correcting it? If it's 
> possible then I'd suggest A, if not B.
>   
We submit a new draft with the changed text, after checking with the AD 
and getting his approval.

If it is a nit, that's it - the RFC Editor works from our changed draft. 
(Some people try to fix the nits in AUTH48, the checking phase just 
before publication - that's a method I personally dislike, because it's 
easy to forget to do so).

If it's a major change, we ask the AD for another round of IETF-wide 
Last Call and IESG approval.

Both mechanisms have been used - the last one only a few times, luckily, 
but it's possible.


                           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 k56HFCiX088995; Tue, 6 Jun 2006 10:15:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k56HFC7T088994; Tue, 6 Jun 2006 10:15:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k56HF9RM088977 for <[e-mail]>; Tue, 6 Jun 2006 10:15:11 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.herald.ox.ac.uk ([163.1.0.235]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.62) (envelope-from <[e-mail]>) id 1Fnf90-0007y1-1v for [e-mail]; Tue, 06 Jun 2006 18:15:06 +0100
Received: from stu325.sjc.ox.ac.uk ([129.67.63.75] helo=ID-77355.user.dfncis.de) by smtp2.herald.ox.ac.uk with smtp (Exim 3.36 #1) id 1Fnf90-0000OX-02 for [e-mail]; Tue, 06 Jun 2006 18:15:06 +0100
Received: from sjoh1646 ([127.0.0.1]) by sjoh1646 (129.67.63.75) with news-to-mail ; Tue, 06 Jun 2006 18:14:07 +0100
To: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
From: Graham Drabble <[e-mail]>
References: <[e-mail]>
Date: Tue, 06 Jun 2006 18:14:07 +0100
Organization: Home
Message-ID: <[e-mail]>
User-Agent: Xnews/5.04.25 Hamster-Pg/1.24
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 25 May 2006 Harald Alvestrand <[e-mail]> wrote in
news:[e-mail]: 

> Please - once you have reviewed draft-ietf-usefor-usefor-08 -
> reply to this Last Call with your answer on the two following
> points: 

I've not had time to do a detailed review, I've had a thesis to 
write. :-( However I've not noticed anything major.
 
> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
> 
> B - I believe issues must be fixed; all my issues have been raised
> by others, and once these are resolved, I believe it is ready.

Once Charles' comments have been addressed.

> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
> 
> Possible answers:
> 
> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last
> Call and processing (knowing that it will likely be in REF hold at
> the RFC Editor until draft-ietf-usefor-usepro is finished)
> 
> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen
> state", where we will promise to only change it if work on USEPRO
> proves to us that we have something wrong in -usefor-.

If we go to A and then decide whilst doing usepro that we made a 
mistake with usefor what's the procedure for correcting it? If it's 
possible then I'd suggest A, if not B.

-- 
Graham Drabble
http://www.drabble.me.uk/



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 k56FkAZw059886; Tue, 6 Jun 2006 08:46:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k56FkA0K059885; Tue, 6 Jun 2006 08:46:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k56Fk9Yb059866 for <[e-mail]>; Tue, 6 Jun 2006 08:46:09 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k56Fk5Z8029365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 11:46:06 -0400
Message-ID: <[e-mail]>
Date: Tue, 06 Jun 2006 11:46:03 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: Harald Alvestrand <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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:
> 
> OK folks, it's time.
> All tracked issues with this document have been declared resolved, and 
> the resolutions entered.
> We know of one bug in -08 (the line length phrasing). But it's time to 
> make the call.
> 
> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
> this Last Call with your answer on the two following points:
> 
> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
> 
> Possible answers:
> 
> A - I believe it is ready to go forward.
> 
> B - I believe issues must be fixed; all my issues have been raised by 
> others, and once these are resolved, I believe it is ready.
> 
> C - I believe issues must be fixed; the following issue has not been 
> raised so far: .....................
> 
> D - I have another opinion, which is: ...................


Based on Charles' feedback, I'd say B.  Hopefully -09 will be the last 
version.


> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
> 
> Possible answers:
> 
> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
> and processing (knowing that it will likely be in REF hold at the RFC 
> Editor until draft-ietf-usefor-usepro is finished)
> 
> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
> where we will promise to only change it if work on USEPRO proves to us 
> that we have something wrong in -usefor-.
> 
> C - I have another opinion, which is........

A.  We should make it as painful as possible to ticker with, but we can 
still make changes if absolutely necessary.

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



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 k56DGqST034840; Tue, 6 Jun 2006 06:16:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k56DGqJn034839; Tue, 6 Jun 2006 06:16:52 -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 k56DGpgB034830 for <[e-mail]>; Tue, 6 Jun 2006 06:16:51 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D99042596D6; Tue,  6 Jun 2006 15:15:53 +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 24888-10; Tue,  6 Jun 2006 15:15:50 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE2522596CD; Tue,  6 Jun 2006 15:15:50 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 06 Jun 2006 06:16:47 -0700
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
To: Ralph Babel <[e-mail]>
Cc: [e-mail]
Subject: Re: Reminder: WG Last Call: draft-ietf-usefor-usefor-08
References: <[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>

Ralph Babel wrote:
> Yeah, after nine years, let's quickly rush it
> through Last Call while everybody is asleep
> or on vacation. Maybe no one will notice.
>
> Heck, maybe no one will _care_.
>   
It's news to me that people sleep more in early June than the rest of 
the year.

2-week WG Last Calls are normal, I think - everyone's supposed to have 
read all the versions anyway.

But if you need an extension in order to do a proper review, you can 
certainly ask for that.



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 k56DDXTU034334; Tue, 6 Jun 2006 06:13:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k56DDX5Q034333; Tue, 6 Jun 2006 06:13:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k56DDWSg034326 for <[e-mail]>; Tue, 6 Jun 2006 06:13:32 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k56DDUnL031628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Tue, 6 Jun 2006 09:13:31 -0400
Message-ID: <[e-mail]>
Date: Tue, 06 Jun 2006 09:13:30 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Reminder: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Ralph Babel wrote:
> Dan Schlitt wrote:
> 
>> The lack of response may be a strong indication
>> of the (lack of) importance of this work.
> 
> Yup. See Forrest's response.
> 
> | Goals and Milestones:
> |
> | Nov 2004  Last Call USEFOR
> | Apr 2005  ReCharter or conclude
> 
> http://www.ietf.org/html.charters/usefor-charter.html
> 
> A Last Call for a document with "Issues to
> be addressed" seems rather dubious to me.

That section should not be in -08, that was an oversight by me.

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



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 k56DDVPt034323; Tue, 6 Jun 2006 06:13:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k56DDVZ4034321; Tue, 6 Jun 2006 06:13:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k56DDTWx034307 for <[e-mail]>; Tue, 6 Jun 2006 06:13:29 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k56DCuej031477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Jun 2006 09:12:57 -0400
Message-ID: <[e-mail]>
Date: Tue, 06 Jun 2006 09:12:56 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
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
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]> Ken Murchison <[e-mail]> writes:
> 
>> Charles Lindsey wrote:
>>> 1.4.  Syntax Notation
>>>
>>>    dot-atom-text = <see RFC2045 Section 5.1>
>>>
>>>    dot-atom-text = <see RFC2822 Section 3.2.4>
>>>
>>> We seem to have covered <dot-atom-text> twice. I think the first one is
>>> wrong (but is there something else from RFC 2045 that was supposed to be
>>> mentioned there)?
> 
>> Actually, this was a cut-n-paste error, or just a brain fart.  The first 
>> <dot-atom-text> is supposed to be <value>.
> 
> Yes, that seems to make sense. I presume you have adopted that fix.

Yes.

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



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 k56BNFKJ020213; Tue, 6 Jun 2006 04:23:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k56BNFvp020212; Tue, 6 Jun 2006 04:23:15 -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 k56BND6G020205 for <[e-mail]>; Tue, 6 Jun 2006 04: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 9966A10DDBF for <[e-mail]>; Tue,  6 Jun 2006 13:23:11 +0200 (CEST)
Date: Tue, 6 Jun 2006 13:22:10 +0200
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
From: [e-mail] (Ralph Babel)
To: [e-mail]
Subject: Re: Reminder: WG Last Call: draft-ietf-usefor-usefor-08
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 Schlitt wrote:

> The lack of response may be a strong indication
> of the (lack of) importance of this work.

Yup. See Forrest's response.

| Goals and Milestones:
|
| Nov 2004  Last Call USEFOR
| Apr 2005  ReCharter or conclude

http://www.ietf.org/html.charters/usefor-charter.html

A Last Call for a document with "Issues to
be addressed" seems rather dubious to me.

> Let us get this thing out the door.

Yeah, after nine years, let's quickly rush it
through Last Call while everybody is asleep
or on vacation. Maybe no one will notice.

Heck, maybe no one will _care_.



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 k56BDUB4018805; Tue, 6 Jun 2006 04:13:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k56BDUTx018804; Tue, 6 Jun 2006 04:13:30 -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-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k56BDTuk018796 for <[e-mail]>; Tue, 6 Jun 2006 04:13:29 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-234.midband.mdip.bt.net ([81.144.67.234] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 44856357.163db.922 for [e-mail]; Tue,  6 Jun 2006 12:13:27 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k56BCMC11510 for [e-mail]; Tue, 6 Jun 2006 12:12:23 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23298
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 6 Jun 2006 10:49:34 GMT
Lines: 133
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]> Ken Murchison <[e-mail]> writes:

>Charles Lindsey wrote:

>> So here is what I have found:

>I applied all of Charles' edits except for those remaining below.  If 
>anyone has an issue with the others, please speak up.


>> 1.4.  Syntax Notation
>> 
>>    dot-atom-text = <see RFC2045 Section 5.1>
>> 
>>    dot-atom-text = <see RFC2822 Section 3.2.4>
>> 
>> We seem to have covered <dot-atom-text> twice. I think the first one is
>> wrong (but is there something else from RFC 2045 that was supposed to be
>> mentioned there)?

>Actually, this was a cut-n-paste error, or just a brain fart.  The first 
><dot-atom-text> is supposed to be <value>.

Yes, that seems to make sense. I presume you have adopted that fix.

>> 3.1.3.  Message-ID
>> 
>>    Observe that msg-id includes the < and >.

Is that what I wrote? If so, it should have been

   The msg-id MUST NOT be more than 250 octets in length.

in which case it needs
 
>> s/msg-id/<msg-id>/
>> 
>>    Observe that msg-id includes the < and >.
>> 
>> s/msg-id/<msg-id>/

>Do we want the < and >, since they aren't part of the construct we're 
>talking about?  I'll leave this up to the WG/chairs.

Eh? I would have though they were exactly that. We are discussing the
<message-id>, and within that you will find a <msg-id>, and it is required
to have a certain property, and we also NOTE an observation about it. But,
typo or not, this is not a show-stopping issue.

>> 3.1.5.  Newsgroups
>> 

>I'll leave this up to the WG/chairs.


>> 3.1.6.  Path
>> 

>I'll leave this up to the WG/chairs.


>> 3.2.1.  Injection-Date
>> 

>I'll leave this up to the WG/chairs.


>> 3.2.14.  Injection-Info
>> 
>>       [RFC0822], effectively allows [CFWS] to occur on either side of
>> 
>> I dislike [RFC0822] when [RFC822] is meant. Yes it makes sorting of the
>> References easier, but I hope Ken can fix that some other way.

>This is an xml2rfc'ism.   If you have a way to change it, please let me 
>know.

Ah! You mean it is a "feature" and not a "bug" :-) .


>I'll leave this up to the WG/chairs.


>> 3.3.  Obsolete Header Fields
>> 

>I'll leave this up to the WG/chairs.


>> 6.  IANA Considerations
>> 

>I'll leave this up to the WG/chairs.


>> 7.2.  Informative References
>> 
>>    [PGPVERIFY]
>>               Lawrence, D., "PGPverify", June 1999.
>> Add "<ftp://ftp.isc.org/pub/pgpcontrol/README.html>" (which is what I did
>> in USEPRO).
>> 
>> 
>>    [Son-of-1036]
>>               Spencer, H., "News Article Format and Transmission",
>>               June 1994.
>> Add "<ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>"

>I have <format type=X target=Y> tags for these which get rendered 
>correctly in HTML, but not text.  Do you know of a better way to do this?

Seems like a "bug" rather than a "feature". Since the definitive form of
an RFC is its text (i.e. nroff) form, I think you need just to include
those URLs as plain texts. If that means people who read the RFC in HTML
cannot 'click' on them, well they will just have to cut and paste :-( .

As an aside, it is impossible to type a URL into a Word document without
its showing up in blue with presumably an HREF hidden behind it :-( .

OK, so most of my niggles are dealt with. That leaves just six items
unresolved. None of them are show stoppers, but I think they would all be
improvements. Other opinions would be welcome.

-- 
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 k55KfPwL012250; Mon, 5 Jun 2006 13:41:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55KfPcr012249; Mon, 5 Jun 2006 13:41:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k55KfOoJ012243 for <[e-mail]>; Mon, 5 Jun 2006 13:41:24 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.22] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k55KfH19013292 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jun 2006 16:41:19 -0400
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 16:41:16 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
CC: [e-mail], Harald Tveit Alvestrand <[e-mail]>, Alexey Melnikov <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Charles Lindsey wrote:

> So here is what I have found:

I applied all of Charles' edits except for those remaining below.  If 
anyone has an issue with the others, please speak up.


> 1.4.  Syntax Notation
> 
>    dot-atom-text = <see RFC2045 Section 5.1>
> 
>    dot-atom-text = <see RFC2822 Section 3.2.4>
> 
> We seem to have covered <dot-atom-text> twice. I think the first one is
> wrong (but is there something else from RFC 2045 that was supposed to be
> mentioned there)?

Actually, this was a cut-n-paste error, or just a brain fart.  The first 
<dot-atom-text> is supposed to be <value>.


> 3.1.3.  Message-ID
> 
>    Observe that msg-id includes the < and >.
> 
> s/msg-id/<msg-id>/
> 
>    Observe that msg-id includes the < and >.
> 
> s/msg-id/<msg-id>/

Do we want the < and >, since they aren't part of the construct we're 
talking about?  I'll leave this up to the WG/chairs.


> 3.1.5.  Newsgroups
> 
>    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.
> 
> No, that paragraph gives entirely the wrong impression, and I have
> repeatedly asked for it to be changed. What is wanted is something like:
> 
>    Current practice does [OR the current standards do] not allow [FWS] in
>    the list of newsgroups and thus it (and particularly folding) would
>    harm propagation significantly. Therefore, [FWS] in the
>    <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
> 
> Eventually I hope (for some value of "eventually") it will be allowed
> freely (since it is a confounded nuisance and current MUAs either do not
> display the whole line, or display it folded in inappropriate manners).
> But, for now, "SHOULD NOT be generated" is correct.

I'll leave this up to the WG/chairs.


> 3.1.6.  Path
> 
> We still need some explanation for the presence of <diag-deprecated>. In
> response to your request, I proposed the folowing NOTE:
> 
>       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>).

I'll leave this up to the WG/chairs.


> 3.2.1.  Injection-Date
> 
>       NOTE: Since clocks on various agents may not be synchronized, 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 header field.
> 
> Also, I think, s/SHOULD/MUST/. There is one obscure situation (see USEPRO
> 7.8) where a moderator may rewrite the Date, but then I don't think a
> moderator is an "agent" as we have defined the term.

I'll leave this up to the WG/chairs.


> 3.2.14.  Injection-Info
> 
>       [RFC0822], effectively allows [CFWS] to occur on either side of
> 
> I dislike [RFC0822] when [RFC822] is meant. Yes it makes sorting of the
> References easier, but I hope Ken can fix that some other way.

This is an xml2rfc'ism.   If you have a way to change it, please let me 
know.


> But also, with the demise of the sender <paramter> we have lost that "Joe
> Q. Public" example, which is a pity. How about:
> 
>       mail-complaints-to=
>         "\"Re: msg <[e-mail]>\" <[e-mail]>"
> 
> 
>    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-".
> 
> That MUST conflicts with the SHOULD. How about:
> 
>    Other <attribute>s MUST NOT be used unless defined in extensions to
>    this standard, or unless they begin with an "x-".

I'll leave this up to the WG/chairs.


> 3.3.  Obsolete Header Fields
> 
> The text which follows is copied verbatim from Son-of-1036. Assuming
> Son-of-1036 is to be republished an an information/historic RFC, ths could

Is there any chance of this happening?  Has any work been done on it?

> be shortened (I have removed all the long verbatim extracts from
> Son-of-1036 from USEPRO).
> 
> So I would suggest omitting the two paragraphs starting with:
> 
>    Relay-Version contained ...
> and
>    Also-Control indicated ...
> 
> and replacing them with a pointer to Son-of-1036 for further details of
> what these headers formerly signified. ALso, the two sentences about "for
> hsitorical purposes" could probably be combined.

I'll leave this up to the WG/chairs.


> 6.  IANA Considerations
> 
>       Header field name: User-Agent
>       Applicable protocol: netnews
>       Status: standard
>       Author/change controller: IETF
>       Specification document(s): This document (Section 3.2.13)
> 
> I would like to add
>       Applicable protocol: email
> 
> That is technically outside our charter, but was always intended and
> should be non-controversial. Could we ask the IESG for permission to do
> that?

I'll leave this up to the WG/chairs.


> 7.2.  Informative References
> 
>    [PGPVERIFY]
>               Lawrence, D., "PGPverify", June 1999.
> Add "<ftp://ftp.isc.org/pub/pgpcontrol/README.html>" (which is what I did
> in USEPRO).
> 
> 
>    [Son-of-1036]
>               Spencer, H., "News Article Format and Transmission",
>               June 1994.
> Add "<ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>"

I have <format type=X target=Y> tags for these which get rendered 
correctly in HTML, but not text.  Do you know of a better way to do this?


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



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 k55KQkKw010998; Mon, 5 Jun 2006 13:26:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55KQkvu010997; Mon, 5 Jun 2006 13:26:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k55KQgnJ010985 for <[e-mail]>; Mon, 5 Jun 2006 13:26:43 -0700 (MST) (envelope-from [e-mail])
Received: from shell.TheWorld.com ([e-mail] [192.74.137.71]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id k55KQDnr018878; Mon, 5 Jun 2006 16:26:13 -0400
Received: from localhost (schlitt@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA120038; Mon, 5 Jun 2006 16:26:12 -0400 (EDT)
X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs
Date: Mon, 5 Jun 2006 16:26:12 -0400
From: Dan Schlitt <[e-mail]>
X-X-Sender: [e-mail]
To: Harald Alvestrand <[e-mail]>
cc: [e-mail]
Subject: Re: Reminder: WG Last Call: draft-ietf-usefor-usefor-08
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Status: No, score=-3.5 required=10.0 tests=ALL_TRUSTED,AWL,BAYES_00  autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pcls2.std.com
X-Virus-Scanned: ClamAV 0.88/1513/Mon Jun  5 13:41:42 2006 on pcls2.std.com
X-Virus-Status: Clean
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>

The lack of response may be a strong indication of the (lack of)
importance of this work.

1) A - Let us get this thing out the door. It has had sufficient working
over.

2) A - There are unlikely to be any show stoppers that need correction.
Getting it into the editors queue drives a stake in the ground to anchor
the work on the next document. Given past history any other choice will
lead to endless back and forth between the two documents and further
delay things.

/dan

-- 

Dan Schlitt
[e-mail]


On Mon, 5 Jun 2006, Harald Alvestrand wrote:


This Last Call ends in 3 days. So far, I have heard 2 people's opinions.

                    Harald

Harald Alvestrand wrote:
>
> OK folks, it's time.
> All tracked issues with this document have been declared resolved, and
> the resolutions entered.
> We know of one bug in -08 (the line length phrasing). But it's time to
> make the call.
>
> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to
> this Last Call with your answer on the two following points:
>
> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>
> Possible answers:
>
> A - I believe it is ready to go forward.
>
> B - I believe issues must be fixed; all my issues have been raised by
> others, and once these are resolved, I believe it is ready.
>
> C - I believe issues must be fixed; the following issue has not been
> raised so far: .....................
>
> D - I have another opinion, which is: ...................
>
> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
>
> Possible answers:
>
> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call
> and processing (knowing that it will likely be in REF hold at the RFC
> Editor until draft-ietf-usefor-usepro is finished)
>
> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state",
> where we will promise to only change it if work on USEPRO proves to us
> that we have something wrong in -usefor-.
>
> C - I have another opinion, which is........
>
> This WG Last Call will end two weeks from now, on June 8, 2006, at
> 17:02 Central European Time.
>
>                       Harald Alvestrand, for the chairs.
>
>



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 k55HFOc1087371; Mon, 5 Jun 2006 10:15:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55HFOlW087370; Mon, 5 Jun 2006 10:15:24 -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 k55HFNlW087361 for <[e-mail]>; Mon, 5 Jun 2006 10:15:23 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F9142596CB; Mon,  5 Jun 2006 19:14:26 +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 23429-03; Mon,  5 Jun 2006 19:14:23 +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 F2B032596B8; Mon,  5 Jun 2006 19:14:22 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 19:15:17 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Harald Alvestrand <[e-mail]>
Cc: [e-mail]
Subject: Reminder: WG Last Call: draft-ietf-usefor-usefor-08
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>

This Last Call ends in 3 days. So far, I have heard 2 people's opinions.

                    Harald

Harald Alvestrand wrote:
>
> OK folks, it's time.
> All tracked issues with this document have been declared resolved, and 
> the resolutions entered.
> We know of one bug in -08 (the line length phrasing). But it's time to 
> make the call.
>
> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
> this Last Call with your answer on the two following points:
>
> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>
> Possible answers:
>
> A - I believe it is ready to go forward.
>
> B - I believe issues must be fixed; all my issues have been raised by 
> others, and once these are resolved, I believe it is ready.
>
> C - I believe issues must be fixed; the following issue has not been 
> raised so far: .....................
>
> D - I have another opinion, which is: ...................
>
> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
>
> Possible answers:
>
> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
> and processing (knowing that it will likely be in REF hold at the RFC 
> Editor until draft-ietf-usefor-usepro is finished)
>
> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
> where we will promise to only change it if work on USEPRO proves to us 
> that we have something wrong in -usefor-.
>
> C - I have another opinion, which is........
>
> This WG Last Call will end two weeks from now, on June 8, 2006, at 
> 17:02 Central European Time.
>
>                       Harald Alvestrand, for the chairs.
>
>



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 k55HEJQv087211; Mon, 5 Jun 2006 10:14:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55HEJ8k087205; Mon, 5 Jun 2006 10:14:19 -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 k55HEHb3087193 for <[e-mail]>; Mon, 5 Jun 2006 10:14:18 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B65452596CB; Mon,  5 Jun 2006 19:13:20 +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 23429-02; Mon,  5 Jun 2006 19:13:16 +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 CCB2E2596B8; Mon,  5 Jun 2006 19:13:15 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 19:14:10 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Forrest J. Cavalier III" <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
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>

Answers will be counted as "D" (I have another opinion) and "B".

Forrest J. Cavalier III wrote:
>
> [Resend unedited.  Previous was sent from wrong account. Sorry]
>
> Harald Alvestrand wrote:
>
>> OK folks, it's time.
>> All tracked issues with this document have been declared resolved, 
>> and the resolutions entered.
>> We know of one bug in -08 (the line length phrasing). But it's time 
>> to make the call.
>>
>> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply 
>> to this Last Call with your answer on the two following points:
>>
>> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>>
>
> Mu. The question is imprecise.
>
> "Go forward" means nothing.  Of course the succession of motion that
> we label "time" continues (despite the WG's best efforts to ignore that
> fact.)  So yes it is "ready to go forward" because there is no other
> alternative.  The Laws of Physics demand it.
>
> This document was supposed to establish a baseline for innovation.  It
> was not supposed to be innovative itself.  But since people tried to
> make it innovative, it was controversial, so it is delayed.  What year
> is it?  I thought the chair promised we would complete or dissolve.
> Is it August 2005 yet?
>
> So draft-i-u-u-08 may describe Usenet as it should have been. But the 
> succession
> of motion has caused how people do group discussion on the Internet to 
> evolve.
>
> Since there was no innovation in Usenet, it evolved outside Usenet,
> and people call it Weblogs.
>
>>
>> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
>>
>> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
>> where we will promise to only change it if work on USEPRO proves to 
>> us that we have something wrong in -usefor-.
>>
>
> There is no way that this WG is to be trusted to produce a Software 
> Design
> Specification like usefor-usefor without being able to go back and 
> debug and
> rewrite and tweak it while writing usefor-usepro.
>
> Most contributors and participants do not operate here at the level of 
> Software
> Engineering.  They are hacks.
>
> Releasing it out of the WG would be a deception, likely to encourage
> implementations which will be in error once the "Real" version is 
> ready with
> UsePro, say, sometime after 2015 or later.
>
> I have my doubts that most of the active participants here even 
> understand
> the engineering challenges of production servers even 5 years ago, let 
> alone
> today, let alone what Usenet SHOULD HAVE become, (if the UI and protocol
> designers had been able to make it a P2P system a la modern P2P.)
>
> My real votes are to decharter.
>
>
>
>
>
>



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 k55HCsXq087002; Mon, 5 Jun 2006 10:12:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55HCsRN087001; Mon, 5 Jun 2006 10:12: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 k55HCqNL086992 for <[e-mail]>; Mon, 5 Jun 2006 10:12: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 CF2472596B8; Mon,  5 Jun 2006 19:11:55 +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 22949-10; Mon,  5 Jun 2006 19:11:49 +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 B16CC2596CB; Mon,  5 Jun 2006 19:11:49 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 19:12:44 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
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:
>
>   
>> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
>> this Last Call with your answer on the two following points:
>>     
>
> Right! I have now carefully read through the whole draft, and it is
> looking pretty good. I have encountered numerous small niggles, and a few
> items which may need further discussion (but none of them makes any
> technical difference, so we should be able to get working on USEPRO).
>
>   
>> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
>>     
>
>   
>> Possible answers:
>>     
>
>   
>> A - I believe it is ready to go forward.
>>     
>
>   
>> B - I believe issues must be fixed; all my issues have been raised by 
>> others, and once these are resolved, I believe it is ready.
>>     
>
>   
>> C - I believe issues must be fixed; the following issue has not been 
>> raised so far: .....................
>>     
>
>   
>> D - I have another opinion, which is: ...................
>>     
>
> I believe all my niggles should be fixed. It is not clear whether my
> bigger points are controversial enough to be raised as formal "issues",
> and the sky will not fall in if they are not accepted. I guess that makes
> my answer "D", though I do not think this need hold us up for long. A
> further draft was probably going to be needed anyway.
>   
I think that closely resembles what I described as option "C".
> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
>
>   
>> Possible answers:
>>     
>
>   
>> A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
>> and processing (knowing that it will likely be in REF hold at the RFC 
>> Editor until draft-ietf-usefor-usepro is finished)
>>     
>
>   
>> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
>> where we will promise to only change it if work on USEPRO proves to us 
>> that we have something wrong in -usefor-.
>>     
>
>   
>> C - I have another opinion, which is........
>>     
>
> My answer there is definitely 'B'.
>   
Noted.



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 k55H6mJE086306; Mon, 5 Jun 2006 10:06:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55H6m4X086305; Mon, 5 Jun 2006 10:06:48 -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 k55H6luH086299 for <[e-mail]>; Mon, 5 Jun 2006 10:06:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10845 invoked from network); 5 Jun 2006 17:06:47 -0000
Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 5 Jun 2006 17:06:47 -0000
X-pair-Authenticated: 216.108.206.21
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 13:06:44 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Alvestrand <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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>

[Resend unedited.  Previous was sent from wrong account. Sorry]

Harald Alvestrand wrote:

> OK folks, it's time.
> All tracked issues with this document have been declared resolved, and 
> the resolutions entered.
> We know of one bug in -08 (the line length phrasing). But it's time to 
> make the call.
> 
> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
> this Last Call with your answer on the two following points:
> 
> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
> 

Mu. The question is imprecise.

"Go forward" means nothing.  Of course the succession of motion that
we label "time" continues (despite the WG's best efforts to ignore that
fact.)  So yes it is "ready to go forward" because there is no other
alternative.  The Laws of Physics demand it.

This document was supposed to establish a baseline for innovation.  It
was not supposed to be innovative itself.  But since people tried to
make it innovative, it was controversial, so it is delayed.  What year
is it?  I thought the chair promised we would complete or dissolve.
Is it August 2005 yet?

So draft-i-u-u-08 may describe Usenet as it should have been. But the succession
of motion has caused how people do group discussion on the Internet to evolve.

Since there was no innovation in Usenet, it evolved outside Usenet,
and people call it Weblogs.

> 
> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
> 
> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
> where we will promise to only change it if work on USEPRO proves to us 
> that we have something wrong in -usefor-.
> 

There is no way that this WG is to be trusted to produce a Software Design
Specification like usefor-usefor without being able to go back and debug and
rewrite and tweak it while writing usefor-usepro.

Most contributors and participants do not operate here at the level of Software
Engineering.  They are hacks.

Releasing it out of the WG would be a deception, likely to encourage
implementations which will be in error once the "Real" version is ready with
UsePro, say, sometime after 2015 or later.

I have my doubts that most of the active participants here even understand
the engineering challenges of production servers even 5 years ago, let alone
today, let alone what Usenet SHOULD HAVE become, (if the UI and protocol
designers had been able to make it a P2P system a la modern P2P.)

My real votes are to decharter.







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 k55H5faG086170; Mon, 5 Jun 2006 10:05:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55H5foE086169; Mon, 5 Jun 2006 10:05:41 -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 k55H5dNW086157 for <[e-mail]>; Mon, 5 Jun 2006 10:05:40 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10478 invoked from network); 5 Jun 2006 17:05:36 -0000
Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 5 Jun 2006 17:05:36 -0000
X-pair-Authenticated: 216.108.206.21
Message-ID: <[e-mail]>
Date: Mon, 05 Jun 2006 13:05:34 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Alvestrand <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; 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:

> OK folks, it's time.
> All tracked issues with this document have been declared resolved, and 
> the resolutions entered.
> We know of one bug in -08 (the line length phrasing). But it's time to 
> make the call.
> 
> Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
> this Last Call with your answer on the two following points:
> 
> 1) Is draft-ietf-usefor-usefor-08 ready to go forward?
> 

Mu. The question is imprecise.

"Go forward" means nothing.  Of course the succession of motion that
we label "time" continues (despite the WG's best efforts to ignore that
fact.)  So yes it is "ready to go forward" because there is no other
alternative.  The Laws of Physics demand it.

This document was supposed to establish a baseline for innovation.  It
was not supposed to be innovative itself.  But since people tried to
make it innovative, it was controversial, so it is delayed.  What year
is it?  I thought the chair promised we would complete or dissolve.
Is it August 2005 yet?

So draft-i-u-u-08 may describe Usenet as it should have been. But the succession 
of motion has caused how people do group discussion on the Internet to evolve.

Since there was no innovation in Usenet, it evolved outside Usenet,
and people call it Weblogs.

> 
> 2) How should draft-ietf-usefor-usefor-08 be carried forward?
> 
> B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
> where we will promise to only change it if work on USEPRO proves to us 
> that we have something wrong in -usefor-.
> 

There is no way that this WG is to be trusted to produce a Software Design 
Specification like usefor-usefor without being able to go back and debug and 
rewrite and tweak it while writing usefor-usepro.

Most contributors and participants do not operate here at the level of Software 
Engineering.  They are hacks.

Releasing it out of the WG would be a deception, likely to encourage 
implementations which will be in error once the "Real" version is ready with 
UsePro, say, sometime after 2015 or later.

I have my doubts that most of the active participants here even understand
the engineering challenges of production servers even 5 years ago, let alone
today, let alone what Usenet SHOULD HAVE become, (if the UI and protocol
designers had been able to make it a P2P system a la modern P2P.)

My real votes are to decharter.





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 k55GDhP2079206; Mon, 5 Jun 2006 09:13:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k55GDhur079205; Mon, 5 Jun 2006 09:13:43 -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-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k55GDf5b079199 for <[e-mail]>; Mon, 5 Jun 2006 09:13:42 -0700 (MST) (envelope-from [e-mail])
Received: from host81-144-67-112.midband.mdip.bt.net ([81.144.67.112] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 44845832.2bbf.72 for [e-mail]; Mon,  5 Jun 2006 17:13:38 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k55GCAV24192 for [e-mail]; Mon, 5 Jun 2006 17:12:10 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:23290
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 5 Jun 2006 11:43:42 GMT
Lines: 402
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:

>Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
>this Last Call with your answer on the two following points:

Right! I have now carefully read through the whole draft, and it is
looking pretty good. I have encountered numerous small niggles, and a few
items which may need further discussion (but none of them makes any
technical difference, so we should be able to get working on USEPRO).

>1) Is draft-ietf-usefor-usefor-08 ready to go forward?

>Possible answers:

>A - I believe it is ready to go forward.

>B - I believe issues must be fixed; all my issues have been raised by 
>others, and once these are resolved, I believe it is ready.

>C - I believe issues must be fixed; the following issue has not been 
>raised so far: .....................

>D - I have another opinion, which is: ...................

I believe all my niggles should be fixed. It is not clear whether my
bigger points are controversial enough to be raised as formal "issues",
and the sky will not fall in if they are not accepted. I guess that makes
my answer "D", though I do not think this need hold us up for long. A
further draft was probably going to be needed anyway.

2) How should draft-ietf-usefor-usefor-08 be carried forward?

>Possible answers:

>A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
>and processing (knowing that it will likely be in REF hold at the RFC 
>Editor until draft-ietf-usefor-usepro is finished)

>B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
>where we will promise to only change it if work on USEPRO proves to us 
>that we have something wrong in -usefor-.

>C - I have another opinion, which is........

My answer there is definitely 'B'.



So here is what I have found:

Issues to be addressed

   o  Path header field delimiters and components ABNF (ticket #1047).

   o  Whitespace in Path header field (ticket #1178).  Editor isn't
      clear on what the issue actually is.

I think those were addressed long ago.


1.2.  Scope

   This specification is intended as a definition of what article
   content format is to be passed between systems.  Although some news
   systems locally store articles in this format ...

s/some news/many news/


1.4.  Syntax Notation

   dot-atom-text = <see RFC2045 Section 5.1>

   dot-atom-text = <see RFC2822 Section 3.2.4>

We seem to have covered <dot-atom-text> twice. I think the first one is
wrong (but is there something else from RFC 2045 that was supposed to be
mentioned there)?


2.1.  Base

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

s/except for/except for the/


2.2.  Header Fields

   o  All agents MUST ... (for compatibility with deployed software,
      including [I-D.ietf-nntpext-base] servers).  News agents MAY
      accept header fields which do not contain the required space.

s/including [I-D.ietf-nntpext-base] servers/
  including NNTP [I-D.ietf-nntpext-base] servers/
[when "I-D.ietf-nntpext-base" is replace by "RFCxxxx", it will not be so
obvious that NNTP is being referred to, and it needs to be clear here.]


   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.

s/header fields/header field lines/
s/header field/header field line/
[I think we were already aware of that bug, and Alexei mentioned it. See
the following NOTE for explanation.]


3.  News Header Fields

   Most of these header fields are mainly of interest to news servers,
   and news servers often need to process these fields very rapidly.
   Thus some header fields prohibit comments.

s/comments/<comment>s/


3.1.3.  Message-ID

   Observe that msg-id includes the < and >.

s/msg-id/<msg-id>/

   Observe that msg-id includes the < and >.

s/msg-id/<msg-id>/


3.1.5.  Newsgroups

   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.

No, that paragraph gives entirely the wrong impression, and I have
repeatedly asked for it to be changed. What is wanted is something like:

   Current practice does [OR the current standards do] not allow [FWS] in
   the list of newsgroups and thus it (and particularly folding) would
   harm propagation significantly. Therefore, [FWS] in the
   <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.

Eventually I hope (for some value of "eventually") it will be allowed
freely (since it is a confounded nuisance and current MUAs either do not
display the whole line, or display it folded in inappropriate manners).
But, for now, "SHOULD NOT be generated" is correct.


3.1.6.  Path

   diag-keyword    =  1*ALPHA                      ; see USEPRO

s/USEPRO/[I.D. ietf-usefor-usepro]/

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

I am still unhappy about the words "legacy names" here. But not to the
extent of holding things up just for that.


   NOTE: Historically, the <tail-entry> indicated the name of the

   NOTE: Although case-insensitive, it is intended that the <path-

   NOTE: One usage of a <path-diagnostic> is to record an IP address.

All NOTEs need indenting.

We still need some explanation for the presence of <diag-deprecated>. In
response to your request, I proposed the folowing NOTE:

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


3.2.  Optional Header Fields

   None of the header fields appearing in this section is required to
   appear in every article but some of them may be required in certain
   types of articles.  Further discussion of these requirements appears
   in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage].

s/types of articles/types of article/


3.2.1.  Injection-Date

      NOTE: Since clocks on various agents may not be synchronized, 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 header field.

Something wrong there with "Inject-Info".
s/Inject-Info/an Injection-Date/

Also, I think, s/SHOULD/MUST/. There is one obscure situation (see USEPRO
7.8) where a moderator may rewrite the Date, but then I don't think a
moderator is an "agent" as we have defined the term.


3.2.10.  Organization

   NOTE: There is no "s" in Organization.

NOTE should be indented.


3.2.14.  Injection-Info

      [RFC0822], effectively allows [CFWS] to occur on either side of

I dislike [RFC0822] when [RFC822] is meant. Yes it makes sorting of the
References easier, but I hope Ken can fix that some other way.


      NOTE: Since any such <host-value> or <address-list> also has 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"

Shouldn't that example be indented (it is part of the NOTE).

But also, with the demise of the sender <paramter> we have lost that "Joe
Q. Public" example, which is a pity. How about:

      mail-complaints-to=
        "\"Re: msg <[e-mail]>\" <[e-mail]>"


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

That MUST conflicts with the SHOULD. How about:

   Other <attribute>s MUST NOT be used unless defined in extensions to
   this standard, or unless they begin with an "x-".


   ...  In order
   to limit the exposure of personal data, it SHOULD be given in a form
   that can't be interpreted by other sites.  ...

s/can't/cannot/


   It is a matter of local policy which <parameter>s to include.  Some
   pieces of information have privacy implications; this is discussed in
   [I-D.ietf-usefor-useage].

s/which <parameter>s/which of the above <parameter>s/


3.3.  Obsolete Header Fields

The text which follows is copied verbatim from Son-of-1036. Assuming
Son-of-1036 is to be republished an an information/historic RFC, ths could
be shortened (I have removed all the long verbatim extracts from
Son-of-1036 from USEPRO).

So I would suggest omitting the two paragraphs starting with:

   Relay-Version contained ...
and
   Also-Control indicated ...

and replacing them with a pointer to Son-of-1036 for further details of
what these headers formerly signified. ALso, the two sentences about "for
hsitorical purposes" could probably be combined.


3.3.1.  Lines

   Historically, this header field was used by the [I-D.ietf-nntpext-
   base] Overview facility, but its use for this purpose is now
   deprecated.  As a result, this header field is to be regarded as
   obsolescent, and it is likely to be removed entirely in a future
   version of this standard.  Servers and clients SHOULD ignore it, and
   SHOULD NOT generate it.

s/Servers and clients/All agents/
[I don't think we have used the term "client" anywhere else.]


5.  Security Considerations

   ...  Additionally, several currently non-standardized
   protocols [PGPVERIFY] will hopefully be standardized in the near
   future.

s/protocols [PGPVERIFY]/protocols such as [PGPVERIFY]/


At the end of this section, add:

   Further security considerations are discussed in [I.D.
   ietf-usefor-usepro].


6.  IANA Considerations

      Header field name: User-Agent
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document (Section 3.2.13)

I would like to add
      Applicable protocol: email

That is technically outside our charter, but was always intended and
should be non-controversial. Could we ask the IESG for permission to do
that?


7.2.  Informative References

   [PGPVERIFY]
              Lawrence, D., "PGPverify", June 1999.
Add "<ftp://ftp.isc.org/pub/pgpcontrol/README.html>" (which is what I did
in USEPRO).


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

Already mentioned above: "[RFC822]" would be nuch nicer.


   [Son-of-1036]
              Spencer, H., "News Article Format and Transmission",
              June 1994.
Add "<ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>"


Appendix A.  Acknowledgments

   As this document is the result of an eight year effort, the number of
   people that have contributed to its content are too numerous to
   mention individually.  Many thanks go out to all past and present
   members of the USEFOR Working Group of the Internet Engineering Task
   Force (IETF) and the accompanying mailing list.

s/and the accompanying mailing list/and its accompanying mailing list/


Appendix B.  Differences from RFC 1036 and its derivatives

   o  Whitespace is permitted in Newsgroups header fields.

s/Whitespace/[FWS]/
[Since we now allow both whtiespace and folding, although both are
deprecated. Perhaps the deprecation should be mentioned here.]


Authors' Addresses
   Kenneth Murchison (editor)
...
   US

   Charles H. Lindsey
...
   GB

   Dan Kohn
...
   US

I don't think it is usual to use the two-letter country codes in postal
addresses. And the country where I live is entitled "The United Kingdom of
Great Britain and Northern Ireland", usually abbreviated to "U.K." (GB is
only a subset of it). So I suggest s/US/U.S.A./ and s/GB/U.K./

Also. my email address is years out of date.

s/[e-mail]/[e-mail]/



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