Subject: Last Call: 'Netnews Article Format' to Proposed Standard (draft-ietf-usefor-usefor)

From: The IESG <[email-masked]>
Date: Thu, 28 Sep 2006 16:53:27 -0400

The IESG has received a request from the Usenet Article Standard Update 
WG to consider the following document:

- 'Netnews Article Format '
   <draft-ietf-usefor-usefor-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-10-12.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-10.txt

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Netnews Article Format' to Proposed Standard  (draft-ietf-usefor-usefor) 
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Thu, 28 Sep 2006 16:53:27 -0400
Sender: [email-masked]

The IESG has received a request from the Usenet Article Standard Update 
WG to consider the following document:

- 'Netnews Article Format '
   <draft-ietf-usefor-usefor-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-10-12.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-10.txt

Date: Wed, 27 Sep 2006 01:34:26 -0700
From: Harald Alvestrand <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Ted Hardie <[email-masked]>, [email-masked], Alexey Melnikov <[email-masked]>
Subject: Request for IESG processing of draft-ietf-usefor-usefor-10 for Proposed Standard
Sender: [email-masked]

The USEFOR WG chairs are hereby requesting that the IESG review and 
process draft-ietf-usefor-usefor-10 for the status of Proposed Standard.

Below is some information about the document's state.

                   Harald & Alexey

1). Have the chairs personally reviewed this version of the ID
and do they believe this ID is sufficiently baked to forward to the IESG 
for publication?

Yes and yes.

2). Has the document had adequate review from both key WG members and 
key non-WG members?

Yes and No. External review has not been solicited.

Do you have any concerns about the depth or breadth of the reviews that 
have been performed?

No.

3). Do you have concerns that the document needs more review from a 
particular (broader) perspective (e.g., security, operational 
complexity, someone familiar with AAA, etc.)?

No concerns. This is a rather isolated field.

4). Do you have any specific concerns/issues with this document that you 
believe the ADs and/or IESG should be aware of? For example, perhaps you 
are uncomfortable with certain parts of the document, or whether there 
really is a need for it, etc., but at the same time these issues have 
been discussed in the WG and the WG has indicated it wishes to advance 
the document anyway.

No concerns regarding the document, however IESG should be aware that 
the document doesn't just standardize existing Usenet article format, 
but also adds several new header fields. This issue was discussed in the 
WG and rough consensus was to add new features.

The group feels that it would be most appropriate to have this document 
approved by the IESG now, but that publication should be delayed until 
the companion document (USEPRO) comes out. This might take a while, 
given the slow progress the group has made so far. In the event of the 
group closing, the document can be published without USEPRO - there are 
no normative references.

5). How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

There is rough consensus among the 10 active participants to send the 
document to IESG.

Two WG participants have said that they think the WG should shut down 
and not send any document, citing the length of time it has taken to get 
here and concerns with the document quality.

6). Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

Nobody has threated to appeal.

7). Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

Yes (Note that the ID nits tool reports several Experimental warnings, 
but they all wrong)

8). Does the document a) split references into normative/informative,

Yes

  and b) are there normative references to IDs, where the IDs are not 
also ready for advancement or are otherwise in an unclear state? (Note: 
the RFC editor will not publish an RFC with normative references to IDs, 
it will delay publication until all such IDs are also ready for 
publication as RFCs.)

This document doesn't have any normative reference to an ID.
There are three Informative references to IDs, two of them are working 
documents of the USEFOR WG
and another one (draft-ietf-nntpext-base) was approved for publication 
in June.

See above for discussion of the relation to draft-ietf-usefor-usepro.

9). For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following sections:

Summary

  This document specifies the syntax of Netnews articles in the context 
of the "Internet Message Format" (RFC 2822) and "Multipurpose  Internet 
Mail Extensions (MIME)" (RFC 2045).  This document obsoletes
the mesasge format parts of RFC 1036, providing an updated specification 
to reflect current  practice and incorporating incremental changes 
specified in other documents. The document also adds several new header 
fields that replace various non-standard and non-interoperable header 
fields in use in Usenet today.

 This is the first in a set of documents that obsolete RFC 1036. This
document focuses on the syntax and semantics of Netnews articles.

 Another document describes protocol issues of Netnews articles
independent of transport protocols, e.g. control articles.

 And yet another document describes policy related issues,
interoperability and usability related recommendations.

Process and goals history of this draft.

The USEFOR WG started its efforts to update RFC 1036 about 9 years ago. 
Several email related standards got published and updated in this 
timeframe.
Several WG chairs have changed since then, and many WG participants left 
or joined the WG (mostly left).

 In May 2004, this document was a part of the 98-page 
draft-ietf-usefor-article-13.txt. Following the proposal of Pete 
Resnick, WG chair at the time, the document got split into 2 documents: 
draft-ietf-usefor-usefor-00.txt and draft-ietf-usefor-usepro-00.txt.

Following feedback from the WG members, Alexey Melnikov asked Ken 
Murchison to edit draft-ietf-usefor-usefor-xx.txt instead of  Charles 
Lindsey, taking a more concise draft (draft-kohn-news-article-03.txt) by 
Dan Kohn as the base.
Ken Murchison became the primary editor, while Charles Lindsey and Dan 
Kohn got
listed as co-editors of the draft-ietf-usefor-usefor-00.txt  document.

While the split and new primary editor helped to move things forward, 
this was not sufficient to get the document finished.

In April 2005, Harald Alvestand joined as co-chair of the WG. He 
introduced issue tracker to the WG,
which helped to prevent people from reraising old issues again and 
again. He also on one occasion suspended posting rights of one of the 
abusive WG members, which helped reduce the personal attacks in the group.

draft-ietf-usefor-usefor-10.txt is the result of a WG Last Call in April 
2006 (which raised several issues, none of them requiring major changes) 
and a call for consensus on the resolution of Last Call comments in 
September 2006.

This draft is being submitted for Proposed Standard.

The USEFOR WG has reviewed the draft, last-call (and post last-call)
reviews included:
- Frank Ellermann
- Russ Allbery
- Richard Clayton
- Ralph Babel
- Forrest J. Cavalier III
- Seth Breidbart
- Dan Schlitt

Of the reviewers, two argued that the group should be disbanded and the 
draft ditched.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usefor-10.txt 
Date: Wed, 20 Sep 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Netnews Article Format
	Author(s)	: C. Lindsey, et al.
	Filename	: draft-ietf-usefor-usefor-10.txt
	Pages		: 42
	Date		: 2006-9-20
	
This document specifies the syntax of Netnews articles in the context
of the "Internet Message Format" (RFC 2822) and "Multipurpose
Internet Mail Extensions (MIME)" (RFC 2045).  This document obsoletes
RFC 1036, providing an updated specification to reflect current
practice and incorporating incremental changes specified in other
documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-usefor-usefor-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usefor-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usefor-10.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 18 Sep 2006 17:43:40 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Disband
Sender: [email-masked]

In message <[email-masked]>, Forrest J. Cavalier III
<[email-masked]> writes

>4. A WG that took this long to push the SIMPLEST document out the door,
>cannot expect to push a more complicated one out the door in far less time.

I note that draft-ietf-usefor-usepro-05 has timed out...  since I owe
the group a little of my time I will commit to promptly reviewing a
current version if an -06 is created...

... I expect to say [and invite the WG to agree] that whole swathes of
it describe vaporware and should be immediately discarded (unless
several writers of server software suddenly pop-up and commit to the
significant effort involved in implementing new functionality, MIME
handling capabilities and other architectural changes...).

Cutting it down from the current 54 pages to around 30 should be rapidly
possible; it can then be judged how contentious it is ... for an example
removing a number of entirely speculative forward looking statements
about how the current lack of security/accountability might be addressed
would alone save more than a page!

- -- 
richard                                                   Richard Clayton

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

To: [email-masked]
Xref: clerew local.usefor:23642
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Summary of responses, WG Last Call Comment Resolution
Date: Mon, 18 Sep 2006 13:33:53 GMT
Lines: 21
Sender: [email-masked]

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

>E - I do not agree with any of the above statements, and wish to say ....

>- Charles Lindsey - The document should be held in the WG waiting for 
>the WG to finish USEPRO. Otherwise A.

Since nobody picked up on my preference for leaving the document "on ice",
my vote reverts to an "A" which makes it 7:3, even using Ralph's method of
counting.

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

To: [email-masked]
Xref: clerew local.usefor:23643
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: WGLC edits
Date: Mon, 18 Sep 2006 13:40:13 GMT
Lines: 22
Sender: [email-masked]

In <[email-masked]> Ken Murchison <[email-masked]> writes:

>Here are the (hopefully non-controversial) edits that I have made based 
>on the WGLC comments.  If you see something that is incorrect please let 
>me know.

>Diffs:

>http://tinyurl.com/ee3sx

All seems fine to me.

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

Date: Mon, 18 Sep 2006 11:52:12 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Disband
Sender: [email-masked]

Harald Alvestrand wrote:

> A WG that has pushed one document out the door has some basis for 
> guessing what it'd take to finish another; with active management, my 
> personal guess is about a year for USEPRO. 

Hah.  That's a wish, not an engineering manager's estimate.  This is
not the IWTF.

This is what you wrote on 5/18/2005:  (Yes, 2005!)

 > As far as I can tell from the documents and discussion, the group is fairly
 > close to being able to emit some documents; this is good - but the group
 > has also been working on these documents since 1998 (when I was its first
 > AD, in fact), without finishing any - which is a VERY long time for an IETF
 > working group.

And on 7/1/2005, you wrote:

 > Our plan was to close as many tickets as possible by today, allowing Ken to
 > produce a clean -05 draft reflecting those resolutions, in preparation for
 > a WG Last Call on the usefor document.

And this is what you wrote on 9/4/2005,

 > OK, here's our result on injection-info.
 > A total of 3 people answered. Possible conclusions:
 >
 > - The rest doesn't really care about this bit
 > - The group is tired and doesn't want to form more opinions
 >
 > I can certainly believe tiredness. I did not make the timeline I suggested,
 > and have severely underestimated the amount of time and energy it takes me
 > to get even proposed closure on issues.
 > In terms of value for energy spent, closing the group may be a better
 > alternative.

And now it is 2006.

The chair is capable of seeing there is a process problem here.

If the chair is not able to identify what the problem is and the appropriate
fixes,  the chair should recommend the WG disband, or resign.  Considering
that this is not the first chair to have the same problem, I invoke Drucker:
(paraphrasing....) Any organizational position in which two capable, well 
selected people, failed is unfillable.  The organization must change so that
the position is not part of it.

If the chair can explain why his estimates from this year 2006 will be any
different from last year 2005, then I think we should also consider....

1. Who didn't participate in the poll within deadline, and estimate how many
people will be around a year from now.  John Stanley, Seth Briedbart, Bruce 
Lilly, Alexey Melnikov, Graham Drabble were recent participants, but
did not have the time or inclination to respond within deadline.

2. Of the people who participate, estimate person-by-person how many of those 
actually have real-world experience running or writing production news server 
software.

Remember this from 5/25/2005?  Has the situation improved?

 > So far, about 20 people (out of 49 subcribers) have answered my poll.
 > Most people gave a "range" for their commitment out of my list, so I'm
 > giving "ranges" for how many people are in each category:
 >
 > 1 (glance): 6-3 (pessimist says 6, optimist says 3)
 > 2 (read): 10-8
 > 3 (comment): 4-6
 > 4 (review): 0-3
 >
 > To me, this indicates that we have a serious risk of a shortage of
 > reviewers, but still have some interest..... I hope it's enough to make a
 > decent finish for the documents

3. Out the door is not the same as passing IETF last call.  And since there
is no way to have interoperating implementations without USEPRO, there is no way 
that USEFOR can get accepted as a standard.

4. A WG that took this long to push the SIMPLEST document out the door,
cannot expect to push a more complicated one out the door in far less time.

 > If the management isn't active, it won't finish.

True, but irrelevant to your point.

> 
> A WG that has not pushed a document out the door has no basis for saying 
> that it's going to finish another one.

True, but does not support your point, either.

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: Disband
Date: Sun, 17 Sep 2006 19:39:09 +0200 (CEST)
Sender: [email-masked]

Russ Allbery wrote:

> Note that this position is independent of whether USEPRO
> is ever published. I'm not horribly optimistic that it
> will be, but I think the format specification is useful
> on its own.

Yes - even regardless of whether this format specification
ever becomes an RFC, cf. s-o-1036. With all the dangling
forward references to a nonexistent USEPRO, it's not
likely to anyway.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Disband
Organization: The Eyrie
Date: Sun, 17 Sep 2006 10:22:18 -0700
Sender: [email-masked]

My feeling, from answering public questions about Usenet protocols, is
that having this document published is a clear improvement over having
people continue to rely solely on RFC 1036.  It's still not the standard
that I'd personally like to see, but I think it's what's reasonable to
expect someone to be able to produce given how few resources we have to do
the work and given the controversy.  There are still some bits in it that
I expect to be generally ignored, but there are way more of those bits in
RFC 1036 right now.

Note that this position is independent of whether USEPRO is ever
published.  I'm not horribly optimistic that it will be, but I think the
format specification is useful on its own.

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

Date: Sun, 17 Sep 2006 19:12:30 +0200
From: Harald Alvestrand <[email-masked]>
To: Ralph Babel <[email-masked]>
Cc: [email-masked]
Subject: Re: Disband
Sender: [email-masked]

I'll answer this one.

A WG that has pushed one document out the door has some basis for 
guessing what it'd take to finish another; with active management, my 
personal guess is about a year for USEPRO. If the management isn't 
active, it won't finish.

A WG that has not pushed a document out the door has no basis for saying 
that it's going to finish another one.

WRT the "number of remaining issues" gibe: While I have not been around 
for the previous Last Calls (and, as I indicated in my reply to some of 
Richard Clayton's comments, I do believe in the "last" word in the name 
of Last Call), I saw no really important technical issues raised at this 
Last Call.

The group has given proof positive that it can find any number of 
wording changes that would result in a slightly better document. So I 
regard it as one of the Chair's important tasks to *stop* such changes 
at one point in the document's lifecycle.

I think this point has now arrived for the USEFOR document.

                        Harald

Date: Sun, 17 Sep 2006 08:35:01 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In message <[email-masked]>, Ken Murchison
> <[email-masked]> writes
>> Richard Clayton wrote:
>>
>> I've resolved your issues regarding 2.1, 3.1.3, 3.1.4, and 3.2.7; in 
>> most cases using your suggested text.
> 
> Thank you, they look just fine.
> 
> If no-one else is going to speak up about User-Agent or the "posting
> account" SHOULD then there's clearly no consensus on those issues :(
> 
>>> #3.2.9
>>>
>>>    NOTE: If the "posting-host" <parameter> identifies a dial-up
>>>    point-of-presence, the "posting-account" or the "logging-data"
>>>    <parameter> may provide additional information about the true
>>>    origin of the article.
>>>
>>> I can see nothing special about dial-up, so:
>> How about:
>>
>> NOTE: If the "posting-host" <parameter> fails to identify a fixed host 
>> (e.g. dynamic IP address allocation), ...
> 
> "fails to identify the host" ...     as Yoda might put it, there is no
> fixed, only allocations that have yet to change :)

I changed it to:

NOTE: If the "posting-host" <parameter> fails to deterministically 
identify the host (e.g. dynamic IP address allocation), ...

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

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: USEFOR next steps
Date: Sun, 17 Sep 2006 13:28:41 +0200 (CEST)
Sender: [email-masked]

Harald Alvestrand wrote:

> Given that the poll, at the time it closed,
> showed a consensus for going ahead

No, in fact it didn't.

> with the document (6 for, 1 against, 3 "other"),

Trying it The Lindsey Way now, eh?

  http://www.imc.org/ietf-usefor/2002/Sep/0132.html

It's not gonna work, I'm afraid.

6:4 doesn't qualify as "rough consensus".

> This will be sent to the IESG for Last Call
> and, hopefully, eventual approval.

Fine, so let it be shot down there.

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Disband
Date: Sun, 17 Sep 2006 13:28:41 +0200 (CEST)
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> Harald Alvestrand wrote:
>
>> I did not see any questions for which an answer would
>> further the purposes of the group, so I said nothing.

Let me quote one of Forrest's points you ignored:

| Disband.
|
| Everytime we do an Internal Last Call, people come up
| with about the same number of remaining issues. Those
| familiar with software engineering will notice that
| defect discovery rates that are constant indicate
| there are many, many issues remaining, and that the
| process that produced the product was most likely broken.
|
| Once again I call on the chair to justify continuing this
| WG when we are several years and several chairs passed the
| original charter. The current charter was to complete ALL
| documents by April 2005 or disband. Instead there is no
| current date estimate for even completing the first
| document of three.

By the current charter, this WG has long lost its mandate.
Only two options are left: recharter or disband. Face the
ugly truth. Don't try to wait the criticism out.

> Charters and Rules of Order are not hoops. If you can't
> stay within them, the process is broken and the work
> product is invariably flawed.

Yup. Welcome to Usefor!

> We are wayyy past charter on the simplest part, USEFOR.
> Since USEPRO is going to be more controversial, on what
> basis and schedule does the chair proceed?

Again, don't expect an answer.

Date: Sat, 16 Sep 2006 21:13:24 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: Harald Alvestrand <[email-masked]>
CC: Ralph Babel <[email-masked]>, [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Harald Alvestrand wrote:

> Ralph Babel wrote:
> 
>>Forrest J. Cavalier III wrote:
>>
>>  
>>
>>>So, will the chair accept this entry to a poll after an
>>>arbitrary deadline, but not relevant comments from Mr.
>>>Clayton because they are after an arbitrary deadline?
>>>    
>>
>>You don't seriously expect an answer to this one,
>>do you? After all, the "chair" didn't answer your
>>earlier questions either.
>>
>>  
> 
> I did not see any questions for which an answer would further the 
> purposes of the group, so I said nothing.

I admit that was a rhetorical question, and I expected no answer.

Charters and Rules of Order are not hoops.  If you can't stay
within them, the process is broken and the work product is
invariably flawed.

We are wayyy past charter on the simplest part, USEFOR.  Since USEPRO is
going to be more controversial, on what basis and schedule
does the chair proceed?

Date: Sat, 16 Sep 2006 23:48:41 +0200
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: USEFOR next steps
Sender: [email-masked]

Given that the poll, at the time it closed, showed a consensus for going 
ahead with the document (6 for, 1 against, 3 "other"), and that I have 
seen no messages asking for a correction to that tabulation of results, 
the chairs are asking the editor to make those minor edits that were 
requested and uncontroversial, and do not introduce technical changes, 
and post an -10 version.

This will be sent to the IESG for Last Call and, hopefully, eventual 
approval.

                       Harald

Date: Sat, 16 Sep 2006 23:44:45 +0200
From: Harald Alvestrand <[email-masked]>
To: Ralph Babel <[email-masked]>
Cc: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Ralph Babel wrote:
> Forrest J. Cavalier III wrote:
>
>   
>> So, will the chair accept this entry to a poll after an
>> arbitrary deadline, but not relevant comments from Mr.
>> Clayton because they are after an arbitrary deadline?
>>     
>
> You don't seriously expect an answer to this one,
> do you? After all, the "chair" didn't answer your
> earlier questions either.
>
>   
I did not see any questions for which an answer would further the 
purposes of the group, so I said nothing.

Date: Sat, 16 Sep 2006 22:49:43 +0200
From: Harald Alvestrand <[email-masked]>
To: Richard Clayton <[email-masked]>
Cc: Ken Murchison <[email-masked]>, [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Richard Clayton wrote:
> If no-one else is going to speak up about User-Agent or the "posting
> account" SHOULD then there's clearly no consensus on those issues :(
>   
I think there's no consensus to change, at least..... we've discussed 
this before.
>   
>>> #3.2.9
>>>
>>>    NOTE: If the "posting-host" <parameter> identifies a dial-up
>>>    point-of-presence, the "posting-account" or the "logging-data"
>>>    <parameter> may provide additional information about the true
>>>    origin of the article.
>>>
>>> I can see nothing special about dial-up, so:
>>>       
>> How about:
>>
>> NOTE: If the "posting-host" <parameter> fails to identify a fixed host 
>> (e.g. dynamic IP address allocation), ...
>>     
>
> "fails to identify the host" ...     as Yoda might put it, there is no
> fixed, only allocations that have yet to change :)
actually the posting-account or logging-data may provide additional 
information about the true origin of the article in all cases, so if we 
want to be logically stringent, the part before the comma adds no 
information...... but I'm fine with Ken's suggestion. It's only a note - 
no behaviour needs to change based on this, and no article is rendered 
conformant or non-conformant by the tweaks to this wording.

                    Harald

Date: Sat, 16 Sep 2006 10:06:25 +0100
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>
>Richard Clayton wrote:
>
>> If no-one else is going to speak up about
>[...]
>> the "posting account" SHOULD then there's clearly no
>> consensus on those issues :(
>
>It's defined to be a "killfile-id".  In theory it would make
>sense to move the first SHOULD to USEAGE with the details, as
>you've proposed it, but in practice we don't know when USEAGE
>will be ready, and it's a serious issue.  

I don't think that it's an issue whose resolution will be changed by
this document

>No nice compromise,
>but I don't think it's wrong.  I'd feel bad about this issue
>with no caveat at all.

it does say further down at the end of the section

   It is a matter of local policy which of the above <parameter>s to
   include.  Some pieces of information have privacy implications; this
   is discussed in [I-D.ietf-usefor-useage].

but we pick out just one of the four and put a SHOULD on it. Now I don't
think it's a SHOULD because many other things within the article may
make this irrelevant (and it may, for example, be policy within an
organisation that articles written by employees may not have obfuscated
origins, so requiring their server to obfuscate just one parameter is
just daft).  However, if you really think it's a SHOULD then it seems
entirely inconsistent to apply it to just one header field line

- -- 
richard                                                   Richard Clayton

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: WGLC edits
Date:  Sat, 16 Sep 2006 02:14:21 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Ken Murchison wrote:

> (hopefully non-controversial) edits

I've only checked the changes, they are all fine from my POV.

> http://tinyurl.com/ee3sx

Thanks.  Meanwhile Henrik improved this, you can now omit url1
if it's in essence "url2 minus one", example:

http://tools.ietf.org/rfcdiff?url2=http://www.contrib.andrew.cmu.edu/~murch/draft-ietf-usefor-usefor-10.txt&difftype=--hwdiff

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Date:  Sat, 16 Sep 2006 01:59:16 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Sender: [email-masked]

Richard Clayton wrote:

> If no-one else is going to speak up about
[...]
> the "posting account" SHOULD then there's clearly no
> consensus on those issues :(

It's defined to be a "killfile-id".  In theory it would make
sense to move the first SHOULD to USEAGE with the details, as
you've proposed it, but in practice we don't know when USEAGE
will be ready, and it's a serious issue.  No nice compromise,
but I don't think it's wrong.  I'd feel bad about this issue
with no caveat at all.

Frank

Date: Fri, 15 Sep 2006 23:10:40 +0100
To: Ken Murchison <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

In message <[email-masked]>, Ken Murchison
<[email-masked]> writes
>
>Richard Clayton wrote:
>
>I've resolved your issues regarding 2.1, 3.1.3, 3.1.4, and 3.2.7; in 
>most cases using your suggested text.

Thank you, they look just fine.

If no-one else is going to speak up about User-Agent or the "posting
account" SHOULD then there's clearly no consensus on those issues :(

>> #3.2.9
>> 
>>    NOTE: If the "posting-host" <parameter> identifies a dial-up
>>    point-of-presence, the "posting-account" or the "logging-data"
>>    <parameter> may provide additional information about the true
>>    origin of the article.
>> 
>> I can see nothing special about dial-up, so:
>
>How about:
>
>NOTE: If the "posting-host" <parameter> fails to identify a fixed host 
>(e.g. dynamic IP address allocation), ...

"fails to identify the host" ...     as Yoda might put it, there is no
fixed, only allocations that have yet to change :)

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

Date: Fri, 15 Sep 2006 14:43:00 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: WGLC edits
Sender: [email-masked]

Here are the (hopefully non-controversial) edits that I have made based 
on the WGLC comments.  If you see something that is incorrect please let 
me know.

Diffs:

http://tinyurl.com/ee3sx
http://tinyurl.com/nlakh

Full document:

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

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

Date: Fri, 15 Sep 2006 14:32:33 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Richard Clayton wrote:

I've resolved your issues regarding 2.1, 3.1.3, 3.1.4, and 3.2.7; in 
most cases using your suggested text.

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

How about:

NOTE: If the "posting-host" <parameter> fails to identify a fixed host 
(e.g. dynamic IP address allocation), ...

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

Date: Fri, 15 Sep 2006 14:28:22 +0100
From: Alexey Melnikov <[email-masked]>
To: Harald Alvestrand <[email-masked]>
CC: Ken Murchison <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: SHOULD/MUST Re: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Harald Alvestrand wrote:

> Alexey Melnikov wrote:
>
>>> >Why do we say "SHOULD be ignored" about the obsolete header
>>> >fields, isn't that more like "MUST be ignored" ?  We don't
>>> >want any effects of "Also-Control".
>>>  
>>> Seems reasonable to me, but I'll let the WG and/or chairs make this 
>>> call.
>>
>> (chair hat off) Changing SHOULD to MUST is fine with me.
>
> (chair hat off) Making all implementations that make special 
> considerations for interworking with old systems non-conformant is not 
> fine with me. If someone has to interface with a system that uses 
> Also-Control, and understands completely the implications of being 
> able to configure that for that particular context, I do not want to 
> declare him unconditionally nonconformant.
> I think SHOULD is better.

Ok, this is a convincing argument to keep the SHOULD.

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Date: Fri, 15 Sep 2006 14:49:55 +0200 (CEST)
Sender: [email-masked]

Charles Lindsey wrote:

> Whilst I think most of Richard's emendations are
> improvements, and might well get added if ever we have
> to do another draft, I think they are unnecessary given
> that we are at Last Call.

| You got that backwards, I'm afraid.
|
| It's not the "stage" that determines what can be done to
| the draft; it's the state of the draft that determines the
| "stage" - and as anybody who doesn't just want to get it
| out the door can see, the draft is in a rather bad shape.

http://www.imc.org/ietf-usefor/2002/Aug/0217.html

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Date: Fri, 15 Sep 2006 14:49:55 +0200 (CEST)
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> So, will the chair accept this entry to a poll after an
> arbitrary deadline, but not relevant comments from Mr.
> Clayton because they are after an arbitrary deadline?

You don't seriously expect an answer to this one,
do you? After all, the "chair" didn't answer your
earlier questions either.

Date: Fri, 15 Sep 2006 12:49:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Richard Clayton <[email-masked]>
CC: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Richard Clayton wrote:

>#2.1
>
>   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.
>
>just keeps negating itself as each sentence follows the next, so why not
>one paragraph saying:
>
>   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] and also to the restrictions specified
>   here, both those that are expressed as text and those that are
>   expressed as ABNF.

[as a contributor] I like the new text.

>#3.1.3
>
>   Implementations MUST NOT generate two Message-IDs where the
>   only difference is the case of characters in the <id-right> part.
>
>isn't quite right, someone else might have made it:
>
>   Implementations MUST NOT generate a Message-ID where the only
>   difference from another Message-ID is the case of the characters
>   in the <id-right> part.

[as a contributor] That looks a bit better.

>#3.1.4
>
>   A newsgroup component SHOULD NOT consist of digits only and SHOULD
>   NOT contain uppercase letters.  Such components MAY be used only to
>   refer to existing groups that do not conform to this naming scheme,
>   but MUST NOT be used otherwise.
>
>much nicer (and more consistent) as:
>
>   A <component> SHOULD NOT consist solely of digits and SHOULD
>   NOT contain uppercase letters.

[as a contributor] Yes, this is more readable.

>  Such components MAY be used to
>   refer to existing groups that do not conform to this syntax,
>   but MUST NOT be used otherwise.

[as a contributor] Either this or the original sentence is fine with me.

>#3.2.7
>
>   NOTE: Since clocks on various agents are not necessarily
>   synchronized, the <date-time> in this header field may not be
>   later than the Date header field, as be expected.  Agents MUST NOT
>   alter a pre-existing Date header field when adding an Injection-
>   Date header field.
>
>the "may not" is unfortunate... so

[as a contributor] Indeed, I stumble on it every time I read the sentence.

>   NOTE: Since clocks on various agents are not necessarily
>   synchronized, hence the <date-time> in this header field will not
>   inevitably

[as a contributor] I would change "will not inevitably" to "might not".

[...]

>Also, in several places  "comments" should become "<comment>s" for
>consistency, and to avoid any possible confusion with <comments>  :) In
>fact, a general sweep through ensuring that syntactic elements are
>enclosed in angle brackets when appearing in commentary would be
>extremely desirable.

Chairs discussed this with Ken and decided that the current text is good 
enough. If you can point out specific places where lack of <comment> is 
problematic, we can reevaluate.

Date: Fri, 15 Sep 2006 12:38:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Charles Lindsey wrote:

>>#3.2.9
>>    
>>
>>  NOTE: If the "posting-host" <parameter> identifies a dial-up
>>  point-of-presence, the "posting-account" or the "logging-data"
>>  <parameter> may provide additional information about the true
>>  origin of the article.
>>    
>>
>>I can see nothing special about dial-up, so:
>>    
>>
>
>If I say
>  posting-host=clerew.man.ac.uk
>then that pretty well ties the article down to me. But if I say
>  posting-host=80.175.135.89
>then all you can establish is that that IP belongs to newnet.co.uk, which
>does not help much.
>
>The wording was written in that form (it has been there a long time) just
>to emphasise that merely identifying the host making the NNTP connection in
>the posting-host parameter would not always be good enough. And yet that
>is the way the current NNTP-Posting-Host header is normally used.
>
[as a contributor] I agree, that the text as written is fine.

>>Also, given that there is a statement    
>>
>>  Some pieces of information have privacy implications; this
>>  is discussed in [I-D.ietf-usefor-useage].    
>>
>>The earlier sentence (which isn't about syntax issues):    
>>
>>  "In order to limit the exposure of personal data, it SHOULD be given
>>  in a form that cannot be interpreted by other sites."    
>>
>>should be completely removed and hence the whole topic of SHOULDs
>>should be left to USEAGE    
>>
>
>I tend to agree with you, but that matter was discussed and people wanted
>that wording in there, so in it went.
>  
>
[as a contributor] I think it is reasonable to discuss Security 
considerations for different header fields in USEFOR itself.

>>#3.2.13
>>    
>>
>>I still strongly believe that the structured format for User-Agent is
>>whistling in the wind. This is branding, not protocols! Since it doesn't
>>affect interoperability it should be removed.
>>    
>>
>We inherited it from HTTP, which is the only protocol to have standardized
>that header so far.
>  
>
[as a chair] I don't hear any rough consensus to support Richard on 
this, so no change.

To: [email-masked]
Xref: clerew local.usefor:23616
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Date: Fri, 15 Sep 2006 09:58:02 GMT
Lines: 103
Sender: [email-masked]

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

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

>[chasing, so I've had a look]

Whilst I think most of Richard's emendations are improvements, and might
well get added if ever we have to do another draft, I think they are
unnecessary given that we are at Last Call.

I comment below on the few that I disagree with:

>#3.2.7

>   NOTE: Since clocks on various agents are not necessarily
>   synchronized, the <date-time> in this header field may not be
>   later than the Date header field, as be expected.  Agents MUST NOT
>   alter a pre-existing Date header field when adding an Injection-
>   Date header field.

>the "may not" is unfortunate... so

>   NOTE: Since clocks on various agents are not necessarily
>   synchronized, hence the <date-time> in this header field will not
>   inevitably be a later value than that in the Date header field.
>   Agents MUST NOT alter a pre-existing Date header field when adding an
>   Injection-Date header field.

The revised text seems a little awkward. Note that Ken has already
fixed the missing "might".

>#3.2.9

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

>I can see nothing special about dial-up, so:

If I say
  posting-host=clerew.man.ac.uk
then that pretty well ties the article down to me. But if I say
  posting-host=80.175.135.89
then all you can establish is that that IP belongs to newnet.co.uk, which
does not help much.

The wording was written in that form (it has been there a long time) just
to emphasise that merely identifying the host making the NNTP connection in
the posting-host parameter would not always be good enough. And yet that
is the way the current NNTP-Posting-Host header is normally used.

>Also, given that there is a statement

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

>The earlier sentence (which isn't about syntax issues):

>   "In order to limit the exposure of personal data, it SHOULD be given
>   in a form that cannot be interpreted by other sites."

>should be completely removed and hence the whole topic of SHOULDs
>should be left to USEAGE

I tend to agree with you, but that matter was discussed and people wanted
that wording in there, so in it went.

>#3.2.10

>Earlier in #3 it says "The following header fields defined in this
>document do not allow comments (CFWS):"  and a list follows.

>but References:  uniquely says: " Comments in CFWS between message
>identifiers can cause interoperability problems, so comments SHOULD NOT
>be generated, but MUST be accepted."

>Is this because people currently create them ?  ...

It is because RFC 2822 defines it that way, and we need a good reason to
depart from RFC 2822 (we had a good reason for Message-ID). And articles
might be gatewayed in from email.

>#3.2.13

>I still strongly believe that the structured format for User-Agent is
>whistling in the wind. This is branding, not protocols! Since it doesn't
>affect interoperability it should be removed.

We inherited it from HTTP, which is the only protocol to have standardized
that header so far.

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

To: [email-masked]
Xref: clerew local.usefor:23617
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-ietf-usefor-usefor-09
Date: Fri, 15 Sep 2006 09:59:19 GMT
Lines: 22
Sender: [email-masked]

In <[email-masked]> Alexey Melnikov <[email-masked]> writes:

>> >Please get rid of <msg-id-core> again, it's used nowhere else,
>> >and it makes that critical part more obscure than necessary.  
>>
>> Seems reasonable to me, but I'll let the WG and/or chairs make this call.

>Somebody has requested a new non-terminal for message-id with no angle
>brackets, as it is used in URLs.

I agree. That is another good reason to keep that syntax as we have it.

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

Date: Fri, 15 Sep 2006 10:05:03 +0200
From: Harald Alvestrand <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Ken Murchison <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked]
Subject: SHOULD/MUST Re: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Alexey Melnikov wrote:
>
>
>> >Why do we say "SHOULD be ignored" about the obsolete header
>> >fields, isn't that more like "MUST be ignored" ?  We don't
>> >want any effects of "Also-Control".
>>  
>> Seems reasonable to me, but I'll let the WG and/or chairs make this 
>> call.
>
> (chair hat off) Changing SHOULD to MUST is fine with me.
>
(chair hat off) Making all implementations that make special 
considerations for interworking with old systems non-conformant is not 
fine with me. If someone has to interface with a system that uses 
Also-Control, and understands completely the implications of being able 
to configure that for that particular context, I do not want to declare 
him unconditionally nonconformant.
I think SHOULD is better.

(chair hat on) Minimize technical changes 3 months after Last Call, please.

Date: Fri, 15 Sep 2006 09:38:50 +0200
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Summary of responses, WG Last Call Comment Resolution
Sender: [email-masked]

Here is what I interpret from the messages that I have received.
If I have missed or misinterpreted any statements, please respond 
quickly (before the weekend).

A - The specification has resolved all the issued raised at Last Call. 
It is ready to be sent to the IESG.
- Harald Alvestrand
- Ken Murchison
- Russ Allbery
- Dan Kohn
- Dan Schlitt
- Frank Ellermann

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

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

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

E - I do not agree with any of the above statements, and wish to say ....

- Charles Lindsey - The document should be held in the WG waiting for 
the WG to finish USEPRO. Otherwise A.
- Richard Clayton - new bugs (not raised at Last Call) should be fixed, 
then A
- Ralph Babel - The correct answers are B, C, D, and E

Date: Thu, 14 Sep 2006 11:01:36 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS:         draft-ietf-usefor-usefor-09
Sender: [email-masked]

So, will the chair accept this entry to a poll after an arbitrary
deadline, but not relevant comments from Mr. Clayton because they
are after an arbitrary deadline?

Since we are outside our charter, then I suppose anything goes.

 > Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])
           by rufus.isode.com (submission channel) via TCP with ESMTPA
           id <[email-masked]>; Thu, 14 Sep 2006 15:31:09 +0100
[snip]

>>>>This poll will close two weeks from now, on Thursday, September 14, 
>>>>at 07:18 GMT.

Date: Thu, 14 Sep 2006 15:31:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Harald Alvestrand <[email-masked]>, [email-masked]
Subject: Is the USEFOR->USEPRO dependency normative?
Sender: [email-masked]

>at the moment, and since at least version -00 of -usefor, usepro
>has been listed under INFORMATIVE references. So if the RFC
>Editor believes what we write, he won't block it.
>Furthermore, I don't see that the references are of such a
>nature that they would be taken as normative.
>  
>
>The references to USEPRO are:
>  
>
[skipped]

> We have talked before about the need to hold back USEFOR in case we 
> discover the need to make changes in USEFOR while we are sorting 
> through the details of USEPRO. But I don't see that it's obvious that 
> it's a true normative dependency.

I don't think any of the references listed above are normative for
USEFOR, at least understanding of USEPRO is not needed to construct a
syntactically valid article.
I always envisioned that USEPRO would reference USEFOR normatively, but
no normative reference in the opposite direction.

>If someone wishes to argue that it is, please state:
>
>- Which of the references above you see as "normative"
>  
>
> - That you think the USEPRO reference needs to be moved from the 
> "informative" to the "normative" section.
>
>The moving is a quick edit. But I'm not certain we need to do it.
>

Date: Thu, 14 Sep 2006 15:31:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Harald Alvestrand <[email-masked]>
CC: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Harald Alvestrand wrote:

>> Harald Alvestrand wrote:
>>
>>>
>>> I believe we have reached a resolution of all issues raised at WG 
>>> Last Call time against draft-ietf-usefor-usefor-08, and 
>>> draft-ietf-usefor-usefor-09 has been published.
>>>
>>> As I said in my June 27 message concerning the processing of Last 
>>> Call issues, I'm hereby issuing a poll for determining whether we 
>>> have WG consensus that the issues have been resolved and the 
>>> document can be sent to the IESG for processing.
>>>
>>> I'm hereby asking the WG members to say that they regard one of the 
>>> following statements as true (filling in details as necessary):
>>>
>>> A - The specification has resolved all the issued raised at Last 
>>> Call. It is ready to be sent to the IESG.
>>>
>>> B - The specification has not resolved an issue raised at Last Call. 
>>> It's critical that this should be resolved before passing it to the 
>>> IESG. The issue number is #......
>>
(As a contributor) There are some minor issues from Richard Clayton that
I think should be addressed. But as far as I am concerned none of them
is a showstopper. So I am for (A).

>>> C - The specification has a fatal technical error, not raised at 
>>> Last Call, and it is critical that this should be resolved before 
>>> passing it to the IESG. The error is....
>>>
>>> D - This effort is futile, we should abandon the document and close 
>>> the WG.
>>>
>>> E - I do not agree with any of the above statements, and wish to say 
>>> ....
>>>
>>> This poll will close two weeks from now, on Thursday, September 14, 
>>> at 07:18 GMT.
>>>
>>> For the chairs,
>>>
>>>                       Harald Alvestrand
>>

Date: Thu, 14 Sep 2006 15:31:00 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>, Frank Ellermann <[email-masked]>
CC: Harald Alvestrand <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-usefor-usefor-09
Sender: [email-masked]

> >Please get rid of <msg-id-core> again, it's used nowhere else,
> >and it makes that critical part more obscure than necessary.  
>
> Seems reasonable to me, but I'll let the WG and/or chairs make this call.

Somebody has requested a new non-terminal for message-id with no angle
brackets, as it is used in URLs.

I frankly care less how it is called, so if you have a better name for
it, let me know.

[...]

> >Why do we say "SHOULD be ignored" about the obsolete header
> >fields, isn't that more like "MUST be ignored" ?  We don't
> >want any effects of "Also-Control".
>  
> Seems reasonable to me, but I'll let the WG and/or chairs make this call.

(chair hat off) Changing SHOULD to MUST is fine with me.

Date: Thu, 14 Sep 2006 11:52:48 +0100
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

In message <[email-masked]>, Harald Alvestrand
<[email-masked]> writes
>Richard,
>Richard Clayton wrote:

>> the above things need fixing, my apologies if any of them are too
>> repetitious. Once fixed then I'd move to an (A)
>>   
>do you regard any of the things you listed as FATAL TECHNICAL ERRORS?

>>#2.1

it's very confusingly expressed and could mislead

>>#3.1.3

a nit

>>#3.1.4

a nit

>>#3.2.7

the use of an uncapitalised "may not" is poor quality

>>#3.2.9

the concentration on dialup (rather than dynamic IP address allocation)
may lead the naive into traceability problems

>>The earlier sentence (which isn't about syntax issues):
>>
>>  "In order to limit the exposure of personal data, it SHOULD be given
>>   in a form that cannot be interpreted by other sites."

this sentence requires a change to many server systems which may not be
in the least bit appropriate for some of them anyway. That's a flaw both
on the wire and in the split between the concerns of this document and
USEAGE

>>#3.2.10

the References: issue was answered by Frank. I withdraw this one.

>>#3.2.13

the structured field for User-Agent remains a flaw. There's absolutely
no processing reason for requiring this structure, nor can I envisage
one :(

>>Also, in several places  "comments" should become "<comment>s" for
>>consistency, and to avoid any possible confusion with <comments>  :)
>>In fact, a general sweep through ensuring that syntactic elements are
>>enclosed in angle brackets when appearing in commentary would be
>>extremely desirable.

IMHO, this is indicative of the general quality of the document :(

>I'm sorry - but the Last Call, where it was appropriate to raise issues 
>of nits and style, was sent out on May 25, and closed on June 8. It is 
>now 3 months later.
>
>If we're EVER going to close on this document, at some point, the chair 
>has to say "No more small changes are going to be accepted".

I understand your frustration, and in particular I apologise to you and
to the group for not having found the time to look at the document until
right on the deadline. 

Most of the changes should be completely uncontroversial, but the two
which are not : the "posting-account" obfuscation and User-Agent
structure I have raised before -- I, probably unwisely, didn't bang on
about them. So if you rule them closed, so be it.  Fixing them wouldn't
raise the quality of the document -- merely make it more accurate in
describing the current approach to what appears in header fields.

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

Date: Wed, 13 Sep 2006 23:58:07 -0700
From: Harald Alvestrand <[email-masked]>
To: Richard Clayton <[email-masked]>
Cc: [email-masked]
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Richard,

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
>   
.... nits removed....
>>>> A - The specification has resolved all the issued raised at Last 
>>>> Call. It is ready to be sent to the IESG.
>>>>
>>>> B - The specification has not resolved an issue raised at Last Call. 
>>>> It's critical that this should be resolved before passing it to the 
>>>> IESG. The issue number is #......
>>>>
>>>> C - The specification has a fatal technical error, not raised at Last 
>>>> Call, and it is critical that this should be resolved before passing 
>>>> it to the IESG. The error is....
>>>>
>>>> D - This effort is futile, we should abandon the document and close 
>>>> the WG.
>>>>
>>>> E - I do not agree with any of the above statements, and wish to say 
>>>> ....
>>>>         
>
> the above things need fixing, my apologies if any of them are too
> repetitious. Once fixed then I'd move to an (A)
>   
do you regard any of the things you listed as FATAL TECHNICAL ERRORS?

I'm sorry - but the Last Call, where it was appropriate to raise issues 
of nits and style, was sent out on May 25, and closed on June 8. It is 
now 3 months later.

If we're EVER going to close on this document, at some point, the chair 
has to say "No more small changes are going to be accepted".
> I'm still not impressed by all the chattiness and random use of similar
> words for subtly different activities.  If the IESG responses are along
> those lines than I think I'd feel like (D).
>   
I would certainly feel like that too, in that case....
> - -- 
> richard @ highwayman . com                       "Nothing seems the same
>                           Still you never see the change from day to day
>                                 And no-one notices the customs slip away"
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBRQg5hpoAxkTY1oPiEQLeIwCg/IDweWefEKYKbVZsQpXgCc5HawIAmgNh
> 2u1Zo0MZLNth1I7xsX/iVANL
> =19Dk
> -----END PGP SIGNATURE-----
>
>   

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Date: Thu, 14 Sep 2006 00:34:27 +0200 (CEST)
Sender: [email-masked]

> I'm hereby asking the WG members to say
> that they regard one of the following statements
> as true (filling in details as necessary):

The correct answers are B, C, D, and E.

> This poll will close two weeks from now,
> on Thursday, September 14, at 07:18 GMT.

Without reasonable deadlines for internal review, these
issues probably need to be dealt with outside this WG -
naively assuming that anyone will still care at that point.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Comments in references (was: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09)
Date:  Wed, 13 Sep 2006 20:14:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Richard Clayton wrote:
 
 [comments between referenced Message-IDs] 
> Is this because people currently create them ?

AFAIK it's because 2822 allows this before mail2news gateways.

> This just complicates to no purpose :(

If we ban it completely gateways have to strip these comments
(or trust that nobody uses them).  On the other hand a UA for
mail and news has to support them.  Why would that be better ?

Frank

P.S. about 3.2.13, of course it's whistling in the wind, but
just saying <unstructured> isn't really better.  I prefer to
keep it as is (= derived from HTTP), but adding a note that
this might turn out to be a case of wishful thinking is okay.

Date: Wed, 13 Sep 2006 18:01:58 +0100
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

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

[chasing, so I've had a look]

#2.1

   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.

just keeps negating itself as each sentence follows the next, so why not
one paragraph saying:

   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] and also to the restrictions specified
   here, both those that are expressed as text and those that are
   expressed as ABNF.

#3.1.3

   Implementations MUST NOT generate two Message-IDs where the
   only difference is the case of characters in the <id-right> part.

isn't quite right, someone else might have made it:

   Implementations MUST NOT generate a Message-ID where the only
   difference from another Message-ID is the case of the characters
   in the <id-right> part.

#3.1.4

   A newsgroup component SHOULD NOT consist of digits only and SHOULD
   NOT contain uppercase letters.  Such components MAY be used only to
   refer to existing groups that do not conform to this naming scheme,
   but MUST NOT be used otherwise.

much nicer (and more consistent) as:

   A <component> SHOULD NOT consist solely of digits and SHOULD
   NOT contain uppercase letters.  Such components MAY be used to
   refer to existing groups that do not conform to this syntax,
   but MUST NOT be used otherwise.

#3.2.7

   NOTE: Since clocks on various agents are not necessarily
   synchronized, the <date-time> in this header field may not be
   later than the Date header field, as be expected.  Agents MUST NOT
   alter a pre-existing Date header field when adding an Injection-
   Date header field.

the "may not" is unfortunate... so

   NOTE: Since clocks on various agents are not necessarily
   synchronized, hence the <date-time> in this header field will not
   inevitably be a later value than that in the Date header field.
   Agents MUST NOT alter a pre-existing Date header field when adding an
   Injection-Date header field.

#3.2.9

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

I can see nothing special about dial-up, so:

   NOTE: The "posting-account" and "logging-data" information provide
   further ways to identify the article origin when "posting-host" is
   insufficient for that purpose.

Also, given that there is a statement

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

The earlier sentence (which isn't about syntax issues):

   "In order to limit the exposure of personal data, it SHOULD be given
   in a form that cannot be interpreted by other sites."

should be completely removed and hence the whole topic of SHOULDs
should be left to USEAGE

#3.2.10

Earlier in #3 it says "The following header fields defined in this
document do not allow comments (CFWS):"  and a list follows.

but References:  uniquely says: " Comments in CFWS between message
identifiers can cause interoperability problems, so comments SHOULD NOT
be generated, but MUST be accepted."

Is this because people currently create them ?  Why not just ban them
here as well using the general ban in #3 ?  What's the value of this
special status for References ? This just complicates to no purpose :(

#3.2.13

I still strongly believe that the structured format for User-Agent is
whistling in the wind. This is branding, not protocols! Since it doesn't
affect interoperability it should be removed.

Also, in several places  "comments" should become "<comment>s" for
consistency, and to avoid any possible confusion with <comments>  :) In
fact, a general sweep through ensuring that syntactic elements are
enclosed in angle brackets when appearing in commentary would be
extremely desirable.

>>> A - The specification has resolved all the issued raised at Last 
>>> Call. It is ready to be sent to the IESG.
>>>
>>> B - The specification has not resolved an issue raised at Last Call. 
>>> It's critical that this should be resolved before passing it to the 
>>> IESG. The issue number is #......
>>>
>>> C - The specification has a fatal technical error, not raised at Last 
>>> Call, and it is critical that this should be resolved before passing 
>>> it to the IESG. The error is....
>>>
>>> D - This effort is futile, we should abandon the document and close 
>>> the WG.
>>>
>>> E - I do not agree with any of the above statements, and wish to say 
>>> ....

the above things need fixing, my apologies if any of them are too
repetitious. Once fixed then I'd move to an (A)

I'm still not impressed by all the chattiness and random use of similar
words for subtly different activities.  If the IESG responses are along
those lines than I think I'd feel like (D).

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

Date: Wed, 13 Sep 2006 08:53:35 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Last Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Half a day. The number of comments is still relatively low.

                     Harald

Harald Alvestrand wrote:
> You now have 6 days to state your opinion, if you have not already 
> done so.
> I'll list the opinions of all the people I have received opinions from 
> soon after Sept 14.
>
>                      Harald
>
> Harald Alvestrand wrote:
>>
>> I believe we have reached a resolution of all issues raised at WG 
>> Last Call time against draft-ietf-usefor-usefor-08, and 
>> draft-ietf-usefor-usefor-09 has been published.
>>
>> As I said in my June 27 message concerning the processing of Last 
>> Call issues, I'm hereby issuing a poll for determining whether we 
>> have WG consensus that the issues have been resolved and the document 
>> can be sent to the IESG for processing.
>>
>> I'm hereby asking the WG members to say that they regard one of the 
>> following statements as true (filling in details as necessary):
>>
>> A - The specification has resolved all the issued raised at Last 
>> Call. It is ready to be sent to the IESG.
>>
>> B - The specification has not resolved an issue raised at Last Call. 
>> It's critical that this should be resolved before passing it to the 
>> IESG. The issue number is #......
>>
>> C - The specification has a fatal technical error, not raised at Last 
>> Call, and it is critical that this should be resolved before passing 
>> it to the IESG. The error is....
>>
>> D - This effort is futile, we should abandon the document and close 
>> the WG.
>>
>> E - I do not agree with any of the above statements, and wish to say 
>> ....
>>
>> This poll will close two weeks from now, on Thursday, September 14, 
>> at 07:18 GMT.
>>
>> For the chairs,
>>
>>                       Harald Alvestrand
>>
>>
>>
>
>

Date: Fri, 08 Sep 2006 08:30:20 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Harald Alvestrand <[email-masked]>
CC: [email-masked]
Subject: Re: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Harald Alvestrand wrote:
> 
> I believe we have reached a resolution of all issues raised at WG Last 
> Call time against draft-ietf-usefor-usefor-08, and 
> draft-ietf-usefor-usefor-09 has been published.
> 
> As I said in my June 27 message concerning the processing of Last Call 
> issues, I'm hereby issuing a poll for determining whether we have WG 
> consensus that the issues have been resolved and the document can be 
> sent to the IESG for processing.
> 
> I'm hereby asking the WG members to say that they regard one of the 
> following statements as true (filling in details as necessary):
> 
> A - The specification has resolved all the issued raised at Last Call. 
> It is ready to be sent to the IESG.

The few nits from Charles and Frank notwithstanding, I believe the 
document is ready.

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

Date: Fri, 08 Sep 2006 03:32:11 -0700
From: Harald Alvestrand <[email-masked]>
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Subject: Reminder: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

You now have 6 days to state your opinion, if you have not already done so.
I'll list the opinions of all the people I have received opinions from 
soon after Sept 14.

                      Harald

Harald Alvestrand wrote:
>
> I believe we have reached a resolution of all issues raised at WG Last 
> Call time against draft-ietf-usefor-usefor-08, and 
> draft-ietf-usefor-usefor-09 has been published.
>
> As I said in my June 27 message concerning the processing of Last Call 
> issues, I'm hereby issuing a poll for determining whether we have WG 
> consensus that the issues have been resolved and the document can be 
> sent to the IESG for processing.
>
> I'm hereby asking the WG members to say that they regard one of the 
> following statements as true (filling in details as necessary):
>
> A - The specification has resolved all the issued raised at Last Call. 
> It is ready to be sent to the IESG.
>
> B - The specification has not resolved an issue raised at Last Call. 
> It's critical that this should be resolved before passing it to the 
> IESG. The issue number is #......
>
> C - The specification has a fatal technical error, not raised at Last 
> Call, and it is critical that this should be resolved before passing 
> it to the IESG. The error is....
>
> D - This effort is futile, we should abandon the document and close 
> the WG.
>
> E - I do not agree with any of the above statements, and wish to say ....
>
> This poll will close two weeks from now, on Thursday, September 14, at 
> 07:18 GMT.
>
> For the chairs,
>
>                       Harald Alvestrand
>
>
>

Date: Fri, 08 Sep 2006 00:07:06 -0700
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: Is the USEFOR->USEPRO dependency normative? (Re: message/news or message/rfc822)
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Harald Alvestrand <[email-masked]> writes:
>
>   
>> at the moment, and since at least version -00 of -usefor, usepro has 
>> been listed under INFORMATIVE references. So if the RFC Editor believes 
>> what we write, he won't block it.
>>     
>
> Hmmm! I had not noticed that. However, I agree that USEFOR does not depend
> normatively on USEPRO, although USEPRO will certainly depend normatively
> on USEFOR. However, USEFOR on its own does not tell you how to construct a
> Netnews system (any more than RFC 2822 tells you how to construct an email
> system).
>
> OTOH, I understood you to say, at the time of your first last call some
> months back, that USEFOR, even if it passed IETF Last Call now, would not
> actually be published until USEPRO caught up with it.
>   
That was said, yes. I think that's a reasonable idea.

However, if the group peters out totally before publishing USEPRO, it 
may actually be rational for the IESG to say "OK, let's just push USEFOR 
as an RFC".
>   
>> The references to USEPRO are:
>>     
>
>   
>> 1.2:
>>     
>
>   
>>   This is the first in a set of documents that obsolete [RFC1036].
>>   This document focuses on the syntax and semantics of Netnews
>>   articles.  [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].
>>   A best-common-practice document, [I-D.ietf-usefor-useage], describes
>>   implementation recommendations to improve interoperability and
>>   usability.
>>     
>
> Actually, that paragraph makes exactly the point I was trying to raise. It
> states that, in order to obsolete [RFC1036], a "set of documents" will be
> needed, and then lists USEPRO and USEAGE as the other two. I grant you
> that USEAGE is not really necessary for the purpose, and indeed had noted
> that slight anomaly some time ago, but did not think it important enough
> to quibble about. But certainly, USEFOR on its own, does not address all
> the matters that RFC1036 deals with.
>
>   
Agreed.

To: [email-masked]
Xref: clerew local.usefor:23601
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Is the USEFOR->USEPRO dependency normative? (Re: message/news or message/rfc822)
Date: Thu, 7 Sep 2006 19:18:55 GMT
Lines: 47
Sender: [email-masked]

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

>at the moment, and since at least version -00 of -usefor, usepro has 
>been listed under INFORMATIVE references. So if the RFC Editor believes 
>what we write, he won't block it.

Hmmm! I had not noticed that. However, I agree that USEFOR does not depend
normatively on USEPRO, although USEPRO will certainly depend normatively
on USEFOR. However, USEFOR on its own does not tell you how to construct a
Netnews system (any more than RFC 2822 tells you how to construct an email
system).

OTOH, I understood you to say, at the time of your first last call some
months back, that USEFOR, even if it passed IETF Last Call now, would not
actually be published until USEPRO caught up with it.

>The references to USEPRO are:

>1.2:

>   This is the first in a set of documents that obsolete [RFC1036].
>   This document focuses on the syntax and semantics of Netnews
>   articles.  [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].
>   A best-common-practice document, [I-D.ietf-usefor-useage], describes
>   implementation recommendations to improve interoperability and
>   usability.

Actually, that paragraph makes exactly the point I was trying to raise. It
states that, in order to obsolete [RFC1036], a "set of documents" will be
needed, and then lists USEPRO and USEAGE as the other two. I grant you
that USEAGE is not really necessary for the purpose, and indeed had noted
that slight anomaly some time ago, but did not think it important enough
to quibble about. But certainly, USEFOR on its own, does not address all
the matters that RFC1036 deals with.

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

Date: Wed, 06 Sep 2006 04:39:11 -0700
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Is the USEFOR->USEPRO dependency normative? (Re: message/news or message/rfc822)
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Frank Ellermann <[email-masked]> writes:
>
>   
>> Yes, in practice, only the parameter CTE 8bits might differ (?)
>> In theory it's "will be identical", the "official" news format
>> is RFC 1036 until USEFOR obsoletes it.
>>     
>
> USEFOR won't obsolete RFC 1036 until it is published as an RFC, which
> cannot be before USEPRO is done because of the normative references to
> USEPRO within it (even it it is all IESG-approved-and-ready before then).
>
> In any case, it will take USEFOR + USEPRO to obsolete RFC 1036 entirely,
> because there is a lot of protocol stuff in RFC 1036.
>
>   
Somewhat challenging this statement....

at the moment, and since at least version -00 of -usefor, usepro has 
been listed under INFORMATIVE references. So if the RFC Editor believes 
what we write, he won't block it.

Furthermore, I don't see that the references are of such a nature that 
they would be taken as normative.

The references to USEPRO are:

1.2:

   This is the first in a set of documents that obsolete [RFC1036].
   This document focuses on the syntax and semantics of Netnews
   articles.  [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].
   A best-common-practice document, [I-D.ietf-usefor-useage], describes
   implementation recommendations to improve interoperability and
   usability.

3.1.4:

    <component>s beginning with underline ("_") are reserved for use by
   future versions of this standard and SHOULD NOT be generated by user
   agents (whether in header fields or in newgroup control messages as
   defined by [I-D.ietf-usefor-usepro]).  However, such names MUST be
   accepted by news servers.

   <component>s beginning with "+" and "-" are reserved for private use
   and SHOULD NOT be generated by user agents (whether in header fields
   or in newgroup control messages [I-D.ietf-usefor-usepro]) without a
   private prior agreement to do so.  However, such names MUST be
   accepted by news servers.
....
      NOTE: "example.*" is reserved for examples in this and other
      standards; "poster" has a special meaning in the Followup-To
      header field; "to.*" is reserved for certain point-to-point
      communications in conjunction with the "ihave" control message as
      defined in [I-D.ietf-usefor-usepro]; "control.*" and "junk" have
      special meanings in some news servers; "all" is used as a wildcard
      in some implementations; and "ctl" was formerly used to indicate a
      <control-command> within the Newsgroups header field.

3.1.5:

   diag-keyword    =  1*ALPHA      ; see [I-D.ietf-usefor-usepro]
...
   A <path-diagnostic> is an item inserted into the Path header field
   for purposes other than to indicate the name of a site.  The use of
   these is described in [I-D.ietf-usefor-usepro].

3.1.6:

   The Subject header field is the same as that specified in Section
   3.6.5 of [RFC2822] with the added restrictions detailed above in
   Section 2.2.  Further discussion of the content of the Subject header
   field appears in [I-D.ietf-usefor-usepro] and
   [I-D.ietf-usefor-useage].

3.2:

   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 article.  Further discussion of these requirements appears
   in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage].

3.2.1:

   The Approved header field indicates the mailing addresses (and
   possibly the full names) of the persons or entities approving the
   article for posting.  Its principal uses are in moderated articles
   and in group control messages; see [I-D.ietf-usefor-usepro].

3.2.3:

   The verb indicates what action should be taken, and the argument(s)
   (if any) supply details.  In some cases, the <body> (as defined in
   [RFC2822]) of the article may also contain details.  The legal verbs
   and respective arguments are discussed in the companion document,
   [I-D.ietf-usefor-usepro].

3.2.12:

   The Supersedes header field contains a message identifier specifying
   an article to be superseded upon the arrival of this one.  An article
   containing a Supersedes header field is equivalent to a "cancel"
   [I-D.ietf-usefor-usepro] control message for the specified article,
   followed immediately by the new article without the Supersedes header
   field.

5:

   Further security considerations are discussed in
   [I-D.ietf-usefor-usepro].

We have talked before about the need to hold back USEFOR in case we 
discover the need to make changes in USEFOR while we are sorting through 
the details of USEPRO. But I don't see that it's obvious that it's a 
true normative dependency.

If someone wishes to argue that it is, please state:

- Which of the references above you see as "normative"
- That you think the USEPRO reference needs to be moved from the 
"informative" to the "normative" section.

The moving is a quick edit. But I'm not certain we need to do it.

                         Harald

To: [email-masked]
Xref: clerew local.usefor:23599
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: message/news or message/rfc822
Date: Wed, 6 Sep 2006 09:50:45 GMT
Lines: 23
Sender: [email-masked]

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

>Yes, in practice, only the parameter CTE 8bits might differ (?)
>In theory it's "will be identical", the "official" news format
>is RFC 1036 until USEFOR obsoletes it.

USEFOR won't obsolete RFC 1036 until it is published as an RFC, which
cannot be before USEPRO is done because of the normative references to
USEPRO within it (even it it is all IESG-approved-and-ready before then).

In any case, it will take USEFOR + USEPRO to obsolete RFC 1036 entirely,
because there is a lot of protocol stuff in RFC 1036.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: message/news or message/rfc822
Date:  Mon, 04 Sep 2006 18:52:12 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 33
Sender: [email-masked]

Charles Lindsey wrote:

> Various other matters related to new media types and changes
> to existing ones are all together in USEPRO. Better to keep
> it that way.

I'm not sure about "better" - if USEPRO takes a quarter of the
time needed for USEFOR it would enter the RFC editor queue in
early 2009.  Maybe 2822 is already obsoleted by some UTF8SMTP
magic at this time.

> It was removed because nobody appeared to be using it.

It's possible that my MUA is the only surviving implementation,
with a worldwide user community of "nobody" (= me),

> Semantically, the two are identical.

Yes, in practice, only the parameter CTE 8bits might differ (?)
In theory it's "will be identical", the "official" news format
is RFC 1036 until USEFOR obsoletes it.

Apparently Henry registered message/news 1993 before s-o-1036,
maybe we could obsolete it informally, a mail from the shepherd
to IANA as soon as USEFOR is approved.

It's okay if you think that that's pedantic and overkill, but I
really like to have all those funny IANA registries up to date,
if it's the dict: URI scheme, or the missing mail format found
by EAI, a lost HTML i18n DTD, or this old message/news entry.

Frank

Date: Mon, 04 Sep 2006 07:25:55 -0700
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: message/news or message/rfc822
Sender: [email-masked]

Charles Lindsey wrote:
>> section 2.1 says:
>>     
>
>   
>>   An article is said to be conformant to this specification if it
>>   conforms to the format specified in [RFC2822] Section 3 and to the
>>   additional requirements of this specification.
>>     
>
>   
>> isn't that clear enough?
>>     
>
> Almost. It would be better to move the 2nd sentence of 2.2 (with
> s/headers/articles/) to 2.1. If people are happy with this, then it could
> be added to Ken's list of niggle fixes. But no big deal, and no reason to
> hold things up.
>   
in that case we'd be saying the same thing twice in one section instead 
of saying it twice in two sections. I fail to see the improvement.

No big deal, but I suggest we let it lie.

To: [email-masked]
Xref: clerew local.usefor:23596
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: message/news or message/rfc822 (was: draft-ietf-usefor-usefor-09)
Date: Mon, 4 Sep 2006 09:52:32 GMT
Lines: 31
Sender: [email-masked]

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

>Admittedly a bit late, but it's more related to USEFOR than to
>USEPRO,  A quick scan of section 9 on page 18 in RFC 4288:  No
>special problem with declaring message/news as OBSOLETE.

Various other matters related to new media types and changes to existing
ones are all together in USEPRO. Better to keep it that way.

>I wasn't immediately happy with obsoleting message/news, but
>others including Henry supported it.  The 4288 template is
>(after truncating anything that makes no sense - maybe that
> is not okay, but I don't find the original registration at
> the IANA site, or any other message/foobar registration):

It was removed because nobody appeared to be using it. To be useful, it
has to be recognized and processed by user agents (for neat display, etc).
Most user agents currently handle message/rfc822 in a sensible way. How
many agents do the same for message/news? Semantically, the two are
identical.

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

To: [email-masked]
Xref: clerew local.usefor:23595
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: message/news or message/rfc822
Date: Mon, 4 Sep 2006 09:45:52 GMT
Lines: 36
Sender: [email-masked]

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

>Frank Ellermann wrote:
>> I hope that I still recall this without digging.  Section 2.3
>> and RFC 2049 talk about user agents, user agents must be able
>> to handle message/rfc822.
>>
>> After removing it from 2.2 the only place explicitly stating
>> that the Netnews article format in fact _is_ (a proper subset
>> of) message/rfc822 is in appendix C (differences from 2822).
>>   
>I think you need to read the document again....

>section 2.1 says:

>   An article is said to be conformant to this specification if it
>   conforms to the format specified in [RFC2822] Section 3 and to the
>   additional requirements of this specification.

>isn't that clear enough?

Almost. It would be better to move the 2nd sentence of 2.2 (with
s/headers/articles/) to 2.1. If people are happy with this, then it could
be added to Ken's list of niggle fixes. But no big deal, and no reason to
hold things up.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: draft-ietf-usefor-usefor-09
Date:  Fri, 01 Sep 2006 19:17:07 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 54
Sender: [email-masked]

Charles Lindsey wrote:
 
>> Please get rid of <msg-id-core> again, it's used nowhere
>> else, and it makes that critical part more obscure than
>> necessary.
 
> No, the WG agreed to that change.

Maybe I missed that, and I don't like it, where was that ?
  
> I may well use it in USEPRO

I looked into usepro-05, it's not used there at the moment.
  
> I currently use "message identifier" (which seems to be the
> term RFC 2822 uses for the purpose).

That's fine.  The potential places where "<msg-id-core>" would
be more straight forward than clumsy "<msg-id> without angle
brackets" constructs are rare, "message identifier" is clear.
   
>> BTW, we might need a usepro-06 draft for the IETF last call.
>> Just a maintenance refresh of -05, because that's expired.
 
> http://www.imc.org/usefor/drafts/draft-ietf-usefor-usepro-05.txt

It's not lost, only expired.  Folks reviewing usefor-10 could
misinterpret this.

> I don't really want to do a new draft of USEPRO just yet.

With "maintenance refresh" I meant "new date" and the latest
boilerplate, no serious changes.  If you think that's a waste
of time because no reviewer would dig up the USEPRO reference
then don't submit it again.

>> Was '"ALL" MUST NOT be used as a <dist-name>' what we 
>> wanted ?  It could be an unnecessary MUST NOT.
 
> It is used by some servers (notably CNews) as a 'wildcard',
> so there is an interoperability issue.

Okay, then the MUST NOT is necessary.  If somebody can answer
questions about it in the last call it's okay.

>> We don't want any effects of "Also-Control".
 
> Sufficiently unlikely to happen to warrant a change at this
> stage. But I would not object if others want it.

Okay, one s/SHOULD/MUST/ move waiting for a second or timeout.

Frank

To: [email-masked]
Xref: clerew local.usefor:23589
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-ietf-usefor-usefor-09
Date: Fri, 1 Sep 2006 11:17:18 GMT
Lines: 48
Sender: [email-masked]

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

>Please get rid of <msg-id-core> again, it's used nowhere else,
>and it makes that critical part more obscure than necessary.

No, the WG agreed to that change. It is the <msg-id-core> that carries the
semantic meaning, and I may well use it in USEPRO in lots of places where
I currently use "message identifier" (which seems to be the term RFC 2822
uses for the purpose).

>BTW, we might need a usepro-06 draft for the IETF last call.
>Just a maintenance refresh of -05, because that's expired.

See http://www.imc.org/usefor/drafts/draft-ietf-usefor-usepro-05.txt (or
.unpaged). I don't really want to do a new draft of USEPRO just yet. There
are a host of minor things needing attention, and I would like to discuss
the texts relating to Path first.

>Was '"ALL" MUST NOT be used as a <dist-name>' what we wanted ?
>It could be an unnecessary MUST NOT.

It is used by some servers (notably CNews) as a 'wildcard', so there is an
interoperability issue. Some earlier drafts used to say that, but it seems
to have got lost somewhere.

>Is "Once a user agent uses User-Agent" acceptable English ?

Norwegian English apparently :-) . It is good enough.

>Why do we say "SHOULD be ignored" about the obsolete header
>fields, isn't that more like "MUST be ignored" ?  We don't
>want any effects of "Also-Control".

Sufficiently unlikely to happen to warrant a change at this stage. But I
would not object if others want it.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: message/news or message/rfc822
Date:  Fri, 01 Sep 2006 15:40:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 40
Sender: [email-masked]

Harald Alvestrand wrote:

> I think you need to read the document again....

Mainly I looked at the diff, top down, and missed...

> section 2.1

...when I saw the change in 2.2.

> isn't that clear enough?

It's perfectly okay, I missed that, sorry.

 [obsoleting message/news]
> I don't think this can be regarded as a fatal flaw in the
> specification,

Sure, it's only a minor inconsistency, anything related to the
format fits best into USEFOR.  And the interoperability issue
is real, my stoneage UA uses message/news when I forward news.
Other UAs consider this as evil unknown attachment, refusing
to open it.  The best I can do is s/news/rfc822/ manually.

> I think it's too late to raise this at the
> resolution-of-comments phase of WG Last Call....

If nobody disagrees we could add the registry update template
because it's "the right thing", like adding the reference to
3696 because it's mentioned in an ABNF comment.

We have "obsoletes 1036" in the header, that could justify to
also obsolete the MIME type registered with RFC 1036 as its
specification.

If you simply don't want it my premise "if nobody disagrees"
would be wrong (and that point moot).

Frank

Date: Fri, 01 Sep 2006 05:50:56 -0700
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: message/news or message/rfc822
Sender: [email-masked]

Frank Ellermann wrote:
> I hope that I still recall this without digging.  Section 2.3
> and RFC 2049 talk about user agents, user agents must be able
> to handle message/rfc822.
>
> After removing it from 2.2 the only place explicitly stating
> that the Netnews article format in fact _is_ (a proper subset
> of) message/rfc822 is in appendix C (differences from 2822).
>   
I think you need to read the document again....

section 2.1 says:

   An article is said to be conformant to this specification if it
   conforms to the format specified in [RFC2822] Section 3 and to the
   additional requirements of this specification.

isn't that clear enough?
> Is that good enough for this important point ?  How about 
> moving USEPRO-05 5.2 "Message/news obsoleted" as is to USEFOR ?
>
> Admittedly a bit late, but it's more related to USEFOR than to
> USEPRO,  A quick scan of section 9 on page 18 in RFC 4288:  No
> special problem with declaring message/news as OBSOLETE.  
>
> I wasn't immediately happy with obsoleting message/news, but
> others including Henry supported it.  The 4288 template is
> (after truncating anything that makes no sense - maybe that
>  is not okay, but I don't find the original registration at
>  the IANA site, or any other message/foobar registration):
>
>    Type name: message
>    Subtype name: news
>    Required parameters: none
>    Optional parameters: none
>    Encoding considerations: 8bit
>    Interoperability considerations:
>       Many applications support mesage/rfc822, some of
>       these applications don't support message/news.
>    Security considerations: see RFC xxxx (I-D.ietf-usefor) 
>    Published specification: RFC xxxx
>    Applications that use this media type: news
>    Intended usage: OBSOLETE
>    Restrictions on usage: 
>       message/news is a proper subset of message/rfc822,
>       message/rfc822 should be used instead of message/news
>    Author: Henry Spencer
>    Change controller: IETF
>
> Frank
>   
I don't think this can be regarded as a fatal flaw in the specification, 
so I think it's too late to raise this at the resolution-of-comments 
phase of WG Last Call....

To: [email-masked]
Xref: clerew local.usefor:23587
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-ietf-usefor-usefor-09
Date: Fri, 1 Sep 2006 11:05:47 GMT
Lines: 27
Sender: [email-masked]

In <[email-masked]> Ken Murchison <[email-masked]> writes:

>Charles Lindsey wrote:

>> #3. In section 3.2.2 (Archive) there is a new sentence:
>> 
>>    ...  Further discussion of the content of the Archive header
>>    field appears in [I-D.ietf-usefor-useage].
>> 
>> I would have preferred "use" or "application" in place of "content".

>I think I agree, however, a similar sentence is used when discussing 
>Subject.  Should I change that as well?

Actually no. The discussion in USEPRO is mainly concerned with whether the
content of the Subject should include a "Re: ". We had big battles about
that a year or so ago. So the present wording in 3.1.6 is fine.

-- 
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      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.usefor:23586
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Date: Fri, 1 Sep 2006 11:02:32 GMT
Lines: 32
Sender: [email-masked]

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

>I believe we have reached a resolution of all issues raised at WG Last 
>Call time against draft-ietf-usefor-usefor-08, and 
>draft-ietf-usefor-usefor-09 has been published.

>As I said in my June 27 message concerning the processing of Last Call 
>issues, I'm hereby issuing a poll for determining whether we have WG 
>consensus that the issues have been resolved and the document can be 
>sent to the IESG for processing.

>I'm hereby asking the WG members to say that they regard one of the 
>following statements as true (filling in details as necessary):

I am saying E - in effect a "write-in" vote for agreeing that it is
correct, and then keeping it on ice until at least USEPRO is done.

If that is not acceptable, then I vote for A:

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

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  message/news or message/rfc822 (was: draft-ietf-usefor-usefor-09)
Date:  Fri, 01 Sep 2006 13:05:34 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 60
Sender: [email-masked]

Harald Alvestrand wrote:

>>| making all headers compliant with this specification
>>| inherently compliant with [RFC2822].
>> That was "all messages", why a restriction to "all headers" ?
[...]

> actually this is a separation-of-concerns thing; this section
> talks about the headers, the next section talks about the 
> body.
 
> The suggestion I reacted to by suggesting this change was a
> suggestion that if this section talks about messages, it 
> should mention MIME as well as RFC 2822; I thought it better 
> to say that this section (which has "headers" in the title) 
> talks about headers, and leave MIME to the next section.

> It's ticket #1313 if you want to scan the archives.....

I hope that I still recall this without digging.  Section 2.3
and RFC 2049 talk about user agents, user agents must be able
to handle message/rfc822.

After removing it from 2.2 the only place explicitly stating
that the Netnews article format in fact _is_ (a proper subset
of) message/rfc822 is in appendix C (differences from 2822).

Is that good enough for this important point ?  How about 
moving USEPRO-05 5.2 "Message/news obsoleted" as is to USEFOR ?

Admittedly a bit late, but it's more related to USEFOR than to
USEPRO,  A quick scan of section 9 on page 18 in RFC 4288:  No
special problem with declaring message/news as OBSOLETE.  

I wasn't immediately happy with obsoleting message/news, but
others including Henry supported it.  The 4288 template is
(after truncating anything that makes no sense - maybe that
 is not okay, but I don't find the original registration at
 the IANA site, or any other message/foobar registration):

   Type name: message
   Subtype name: news
   Required parameters: none
   Optional parameters: none
   Encoding considerations: 8bit
   Interoperability considerations:
      Many applications support mesage/rfc822, some of
      these applications don't support message/news.
   Security considerations: see RFC xxxx (I-D.ietf-usefor) 
   Published specification: RFC xxxx
   Applications that use this media type: news
   Intended usage: OBSOLETE
   Restrictions on usage: 
      message/news is a proper subset of message/rfc822,
      message/rfc822 should be used instead of message/news
   Author: Henry Spencer
   Change controller: IETF

Frank