Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 5 Jun 2006 11:43:42 GMT

In <[email-masked]> Harald Alvestrand <[email-masked]> 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 = "[email-masked]: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 <[email-masked]>\" <[email-masked]>"

   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/[email-masked]/[email-masked]/

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

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 05 Jun 2006 13:05:34 -0400

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

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.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Jun 2006 19:15:17 +0200

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

                    Harald

Harald Alvestrand wrote:
> 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.
>
>

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 05 Jun 2006 13:06:44 -0400

[Resend unedited.  Previous was sent from wrong account. Sorry]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Jun 2006 19:14:10 +0200

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

Forrest J. Cavalier III wrote:
>> 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:
>>
>> where we will promise to only change it if work on USEPRO proves to 
>> us that we have something wrong in -usefor-.
>>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Jun 2006 19:12:44 +0200

> further draft was probably going to be needed anyway.
I think that closely resembles what I described as option "C".
> My answer there is definitely 'B'.
Noted.

---

From: Dan Schlitt <[email-masked]>
Date: Mon, 5 Jun 2006 16:26:12 -0400

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
[email-masked]

On Mon, 5 Jun 2006, Harald Alvestrand wrote:

                    Harald

---

From: Ken Murchison <[email-masked]>
Date: Mon, 05 Jun 2006 16:41:16 -0400

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

> wrong (but is there something else from RFC 2045 that was supposed to be

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

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

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.

> But, for now, "SHOULD NOT be generated" is correct.

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

>       is deprecated (though it is still acceptable in the form of the

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

> moderator is an "agent" as we have defined the term.

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

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

>    this standard, or unless they begin with an "x-".

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

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

> hsitorical purposes" could probably be combined.

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

> should be non-controversial. Could we ask the IESG for permission to do

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

> 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

---

From: [email-masked] (Ralph Babel)
Date: Tue, 6 Jun 2006 13:22:10 +0200

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 06 Jun 2006 09:12:56 -0400

Charles Lindsey wrote:
> In <[email-masked]> Ken Murchison <[email-masked]> writes:
> 
>> Charles Lindsey wrote:
>>> 1.4.  Syntax Notation
>>>
> Yes, that seems to make sense. I presume you have adopted that fix.

Yes.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 06 Jun 2006 06:16:47 -0700

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 6 Jun 2006 10:49:34 GMT

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

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

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

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

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 06 Jun 2006 09:13:30 -0400

> be addressed" seems rather dubious to me.

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 06 Jun 2006 11:46:03 -0400

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

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

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

---

From: Graham Drabble <[email-masked]>
Date: Tue, 06 Jun 2006 18:14:07 +0100

On 25 May 2006 Harald Alvestrand <[email-masked]> wrote in
news:[email-masked]: 

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

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Jun 2006 08:11:27 +0200

> 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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 7 Jun 2006 09:27:09 GMT

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

---

From: Richard Clayton <[email-masked]>
Date: Thu, 8 Jun 2006 02:44:03 +0100

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

>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

   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

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Jun 2006 23:51:38 -0700

Thanks for the review, Richard!

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
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?

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Jun 2006 23:44:34 -0700

It's about time to give my answers.

> Editor until draft-ietf-usefor-usepro is finished)
Getting the rest of the IETF to look at the document is, IMHO, important.

---

From: [email-masked] (Ralph Babel)
Date: Thu, 8 Jun 2006 17:00:16 +0200

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

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

 <[email-masked]>
 <[email-masked]>

| 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 <[email-masked]>; 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 = "[email-masked]: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.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 8 Jun 2006 15:14:32 GMT

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

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

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

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

>   The text below uses ABNF ....

>   Articles must also conform....

>linked.`

Yes, I'll buy that.

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

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

>        synchronised, so this will not necessarily be the case. Agents

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

>        which newsgroup(s) the poster has requested that followups are

I'll buy that.

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

>   The User-Agent header field ....  It is intended that this header field be

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

Eh?

>        text because I assure you that's all that software authors will

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

>belong next to each other

I agree.

>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
>entirely clear why it needs defining.

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

>second-rate and should not in my opinion go anywhere near a critical

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

---

From: Richard Clayton <[email-masked]>
Date: Thu, 8 Jun 2006 18:04:06 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>with it. Which begs the question why this particular one is MUST 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 :(

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

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

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]

- --

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 9 Jun 2006 20:02:35 GMT

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

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 9 Jun 2006 19:43:46 GMT

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.

>to separate URLs from punctuation.

Standard IETF boilerplate :-(.

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

>"supersedes" and "updating it" are mutually exclusive.

Disagree

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

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

>Any statistics to back the "usually"?

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

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

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

>| The poster is analogous to an [RFC2822] author.

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

>field is not a follow-up". Not overly useful.

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

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

>two options the "otherwise" refers.

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

>understanding to _be_ compliant? - Ouch.

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

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

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

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

>"... [RFC2822]; this specification, however, is ...".

OK

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

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

>either add one or rename that section.

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

>It's also the article _body_ that matters.

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

>It says "header fields" here ...

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

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

>to communication between user agents and news servers.

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

>deserves to be documented in appendix B.

OK

>What purpose does the "single" serve here?

OK

>is posted. We could say "when referencing".

OK

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

>free to support the full syntax. So what's this "MAY" about?

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

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

>What about "Followup-To" header fields?

OK

>Just by servers? What about user agents?

OK s/news servers/all agents/

>As above.

My comment as above.

>As above.

OK

>As above.

OK

>"<component>"?

Correct

>This draft does not contain any such example.

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

>Really plural?

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

>"cmsg" mechanism. "ctl" was used in "Newsgroups".

s/Subject/Newsgroups/

>("processes") is outside the scope of this draft.

OK

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

It is covered adequately in USEPRO.

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

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

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

I delegate Ken to toss a coin.

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

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

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

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

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

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

>Beg pardon? This sounds rather redundant.

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

>"... according to the author".

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

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

>effects are implementation/configuration-specific?

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

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

>which should also be mentioned in appendix B.

OK

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

That's what USEPRO's for.

>(or others) to be a member of one or more <dist-name>s?

If you like.

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

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

>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

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.

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

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

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

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

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

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

>"<product> tokens".

Or "<product>s"

>Ascending or descending?

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

>Replace by "The netnews article format".

OK

>generic complaints URLs, not just mail.

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

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

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

Aaaaaarrrrgghhhh! s/@/./

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

I see no problem.

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

>The usual form is "X-Trace".

OK

>"sites" can interpret data? Not really.

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

>| documents for further information on their original use.

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

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

OK

>|           of USENET Messages", RFC 850, June 1983.

Up to Ken.

>Again, so many words ...

But it was never written down clearly before.

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

Already suggested :-)

>Replace "will hopefully" by "may".

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

>a limit to a server's history size.

OK

>| if the identifier has already been seen.

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

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

OK

>so their status may have to be "deprecated".

Up to Harald I think.

>... for Message-ID?

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

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

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

>Are these really IETF header fields?

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

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

OK

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

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

>... maybe?

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

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

>"nine-year effort".

and rising ...

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 11 Jun 2006 21:00:50 +0100

>But, for now, "SHOULD NOT be generated" is correct.
Personally I don't think that the suggested text is an improvement over 
existing one.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 11 Jun 2006 15:08:24 +0100

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

>to separate URLs from punctuation.
Ralph, this is a part of the standard Internet Draft template.

>"SHALL", "SHALL NOT", "RECOMMENDED", and "OPTIONAL" do not
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.

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

[...]

>  and section numbers be used without a trailing dot.
I think this is an xml2rfc feature.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 11 Jun 2006 21:07:04 +0100

>> others, and once these are resolved, I believe it is ready.
Ralph, Richard and Charles has raised issues that need fixing.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 13 Jun 2006 15:39:13 GMT

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

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.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Jun 2006 07:46:31 +0200

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

> 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" <[email-masked]>
> Subject: Testing folded newsgroups.
> Message-ID: <[email-masked]>
> 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: <[email-masked]>
>
> 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