Subject: Proposing a new editor for the USEPRO document

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Nov 2006 10:34:12 +0100

Greetings,

Now that we're finished with USEFOR (we hope), we should try to finish
USEPRO.

Since a major source of controversy with the document has been the
description style and richness of features favoured by the current
editor (Charles Lindsey), the chairs would like to see if it is possible
to get some progress on this document by doing a radical reset.

We have therefore asked Russ Allbery, with editing assistance from Ken
Murchison, to prepare a draft, to be published as
draft-allbery-usefor-usepro-00, that will serve as a possible other
basis from which to build an USEPRO document that the group can get
consensus on.

Once we have both versions available, the group will be asked to form a
consensus on which draft to use as a basis for the next version, and the
favoured version will be published as the next version of
draft-ietf-usefor-usepro.

We hope the alternate text will be available by the end of November.

                         The chairs

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Nov 2006 16:12:37 +0100

> We hope the alternate text will be available by the end of November.

Maybe the Article Format makes it next week (11-30) - IIRC we wanted
to update the Charter when it's approved.  One (vague) idea to get a
shorter USEPRO was a separate document for gateway considerations.
There are also some pending USEPRO tickets.  

Frank

---

From: Dan Schlitt <[email-masked]>
Date: Tue, 21 Nov 2006 11:01:01 -0500

I think this is a fine idea for moving things forward.

/dan

-- 

Dan Schlitt
[email-masked]

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 22 Nov 2006 13:04:05 GMT

>basis from which to build an USEPRO document that the group can get

Well there are two issues.

1. What technical features should USEPRO contain?

2. How should they be described?

It is, in my opinion, a recipe for disaster to consider these two issues
at the same time.

We have just come to the end of 2 years during which we started with a new
document with a new editor for USEPRO. The first drafts of this contained
so many technical omissions from what had been correctly present for years
in the original ARTICLE series as to be useless. Obvious examples are the
restrictions on newsgroup-names, the syntax of message identifiers, and
the correct way to describe <parameter>s; but there were plenty of others.

Most of our effort over those years has therefore been devoted to
reexamining and fixing issues that were once correct. In going over the
same ground and re-explaining to people why they needed to be fixed. True,
we discovered new oddities and made further refinements during the
process, and introduced one substantial change (the new syntax for the
Path header). But in the great majority of instances the final form of
each feature is little different from what is was before.

I grant you that the final product is neater, tidier and correcter, but it
has come at a considerable price.

There is a lot of detailed stuff in USEPRO, most of it put there over a
long period to cover issues that were raised. Some of it represents the
outcome of long drawn-out battles.

The question of exactly what followup agents should do, and the role that
the prefix "Re:" should or not play in the process is the best-known, but
not the only, example. That one ended in a consensue for a compromise
(Seth's 4 principles) which only two people would not accept. But note
that of the people who accepted it, approximately half would have
preferred something stronger, and half something weaker. I don't really
want to have to go through all that again.

Another example from further back was the issue of how much change an
injecting agent was allowed to make. The wording you see now is exactly
what was agreed. Rewrite it now, and you risk going right back to square
one.

So please can we have clear guidance before we start whether this is an
exercise for making technical changhes, and if so which ones, or whether
it is for using different wording. Because if we try to do both at the
same time, then if will take us another two years at the least.

>draft-ietf-usefor-usepro.

But if this beauty contest gives us a choice between teo drafts which have
both technical and stylistic differences, on what basis will people be
expected to differentiate between them?

Anyway, I am about to produce a new version of the present USEFOR draft,
just to serve as a baseline. It does not contain any changes of
significance that you have not already seen - just moves things around a
bit and changes a bit of terminology to bring it more into line with the
final form of USEFOR.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Nov 2006 05:38:35 -0800

> bit and changes a bit of terminology to bring it more into line with the
Thank you. Having both drafts online in a current form will be a good 
thing when trying to compare them.

               Harald

---

From: Russ Allbery <[email-masked]>
Date: Thu, 30 Nov 2006 13:28:47 -0800

Charles Lindsey <[email-masked]> writes:
> Harald Alvestrand <[email-masked]> writes:

>> editor (Charles Lindsey), the chairs would like to see if it is
>> possible to get some progress on this document by doing a radical
>> reset.

>> basis from which to build an USEPRO document that the group can get

I have finished an initial draft and will submit it to the draft editor as
soon as I get a chance to look up the details on how one goes about doing
that.  Once that's done, it will also be available on the web.

I was going to discuss some of the details sooner, but I had less time
this month than I had expected to work on WG issues, and what time I had
went into the work so that I could get it done in a reasonable amount of
time.  However, Charles raises several good questions that I did want to
respond to, however belatedly.

First, I want to note that writing a separate draft is for me an efficient
way of capturing everything that I would change or that I disagree with in
one place where it can be looked at as a whole rather than brought up as a
myriad separate points.  In some cases, the changes are minor but
systematic in a way that's hard to discuss.  I found it a useful exercise
and offer it for discussion; I'm happy to move forward with the current
draft edited by Charles if that's what the group prefers.  I expect that
my draft will still be useful as a point of discussion and comparison as
part of our work on finishing USEPRO.

> It is, in my opinion, a recipe for disaster to consider these two issues

I can try to make it clear where the distinctions lie, although the line
between technical features and method of description is blurry in many
places.

> We have just come to the end of 2 years during which we started with a
> new document with a new editor for USEPRO. The first drafts of this
> contained so many technical omissions from what had been correctly
> present for years in the original ARTICLE series as to be
> useless. Obvious examples are the restrictions on newsgroup-names, the
> syntax of message identifiers, and the correct way to describe
> <parameter>s; but there were plenty of others.

This is not that sort of completely separate work.

I started from the existing draft and worked under the assumption that any
technical requirement in the existing draft was presumed to be correct
unless I had a clear justification in mind for changing it.  I have tried
to preserve the existing work, and while I'm sure I was not entirely
successful, I believe that at least the obvious points of agreement within
the WG are still present.

The draft will look very familiar and is even substantially similar in
layout.  (Hopefully, this will also make it easier to compare
side-by-side.)

> The question of exactly what followup agents should do, and the role
> that the prefix "Re:" should or not play in the process is the
> best-known, but not the only, example. That one ended in a consensue for
> a compromise (Seth's 4 principles) which only two people would not
> accept. But note that of the people who accepted it, approximately half
> would have preferred something stronger, and half something weaker. I
> don't really want to have to go through all that again.

Yes, I'm painfully aware of some of these battles, and it's not my
intention to reopen many of them.  There are some that I do want to
reopen, but I tried to only do that where I felt there was a real
improvement to be made.  For instance, I am still quite skeptical whether
Path header field folding is a good idea, but we've already discussed that
at length and have a working consensus, so I kept it.

The specific major technical changes that I am proposing are (and I may
have missed some, and some that I consider minor others may not):

 * Drop mvgroup and initial articles.

 * Completely ban reinjection as permitted in the current draft.  This
   allows a much sharper and clearer distinction between articles and
   proto-articles and simplifies the descriptions of both posting and
   injecting agents.  Instead, state that agents that wish to transfer
   articles between two separate Netnews networks are gateways, are
   subject to the requirements of a gateway, and must rewrite the articles
   into proto-articles and inject them as normal.

 * Drop all description of the batch format and don't allow batches to be
   sent via application/news-transmission.  The batch format described in
   the current draft isn't sufficient to describe existing practice anyway
   (it doesn't handle compression), and sending batches via e-mail in
   application/news-transmission is a new feature with marginal use.  I'll
   describe the full batch format if I ever get around to writing up the
   NNTP XBATCH extension.

 * Make use of the new path diag-keywords optional but recommended.

 * Add charset parameters for application/news-groupinfo and
   application/news-checkgroups.  We can't just tell everyone to use
   ASCII; they aren't now, and they're not going to.  Having explicit
   charset information at least allows someone to do something sane while
   still meeting the requirements of NNTP to use UTF-8.

 * Recommend use of the control hierarchy for storing control messages
   rather than storing them in normal groups (upgraded from a NOTE).

 * Be more explicit about the requirements for newgroup control messages
   and their special propagation rules.

 * Add explicit requirements around checkgroups serial numbers.  If we're
   going to specify them, we need to specify their behavior.  I'm still
   seriously considering proposing dropping both checkgroups scope and
   serial numbers entirely; I'm not sure that anyone will ever adopt this
   proposal.  But if we are going to include those features, more language
   was needed to specify the behavior of agents processing them.

I'll go ahead and post this now in advance of the draft so that we can
have some discussion, if people wish, of the technical changes separate
from the way in which they're described, since I think that's a valid
point.

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Dec 2006 00:25:19 +0100

Russ Allbery wrote:
 
> I started from the existing draft and worked under the assumption
> that any technical requirement in the existing draft was presumed
> to be correct unless I had a clear justification in mind for changing
> it.
[...]

>  * Drop mvgroup and initial articles.

I like 'mvgroup' as idea.  If it's hopeless in practice getting rid
of it is no showstopper, but I'd like to know your justification for
this modification.

>  * Completely ban reinjection as permitted in the current draft.

Sounds good.

> I'll describe the full batch format if I ever get around to writing
> up the NNTP XBATCH extension.

Also fine, but IIRC the usage in mail was designed for forwarding of
articles to a moderator, or between moderators.  In the times of SPF,
DKIM, and SenderID we've to say something about this case.

>  * Make use of the new path diag-keywords optional but recommended.

Pick at most one of MAY, SHOULD, or MUST ;-)  I guess you mean SHOULD.

>    application/news-checkgroups.

Probably a good idea.

>    charset information at least allows someone to do something sane
>    while still meeting the requirements of NNTP to use UTF-8.

Required for future newsgroup names, anywhere else ?

>    rather than storing them in normal groups (upgraded from a NOTE).

Good.  Maybe we can add a recommendation to split control.cancel in
some appropriate way (for modem users like me when they try to figure
out if some rogue cancel bot is at it again)

Frank

---

From: Russ Allbery <[email-masked]>
Date: Thu, 30 Nov 2006 15:59:54 -0800

> I like 'mvgroup' as idea.  If it's hopeless in practice getting rid of
> it is no showstopper, but I'd like to know your justification for this
> modification.

My justification is that it's an entirely experimental feature which has
not been implemented in any news server distribution that I'm aware of.
No one is currently issuing them, even though many news servers support
dropping in a new control message handler for a new type and then issuing
them and the specification has been available for years.  I'd prefer to
see it published as a separate experimental protocol and see if anyone
actually adopts it.

In general, I removed any experimental feature that was never implemented
and which wasn't a standardization of some existing similar practice on
the grounds that such proposals could start on the experimental track and
then be incorporated later as need be.  The one exception, which I think
may have been a mistake to retain, was the additional arguments to
checkgroups.

(The new Path diag-keywords are a standardization of existing practice, as
is Injection-Info.  Injection-Date is iffier, but it fixes a specific
problem with the current practice and is already in USEFOR, which I was
treating as sacrosanct.)

>> I'll describe the full batch format if I ever get around to writing up
>> the NNTP XBATCH extension.

> DKIM, and SenderID we've to say something about this case.

When forwarding to moderators, including a batch rather than a single
message was already prohibited.  Batches were only permitted for
usage=inject, which is a theoretical feature not currently in use.

The general application/news-transmission media type was retained, with
SHOULD support, SHOULD NOT use unless the moderator is known to accept it
language.

> Pick at most one of MAY, SHOULD, or MUST ;-)  I guess you mean SHOULD.

Yeah, I probably should have said RECOMMENDED; the draft will say SHOULD.

> Required for future newsgroup names, anywhere else ?

Required right now for newsgroup descriptions.  The output of LIST
NEWSGROUPS is defined to be in UTF-8 (although people are not yet doing
this in practice).  Descriptions are more the problem case right now than
newsgorups; non-ASCII newsgroups are not currently in significant use.

>>    rather than storing them in normal groups (upgraded from a NOTE).

By recommend here I mean SHOULD.

> Good.  Maybe we can add a recommendation to split control.cancel in some
> appropriate way (for modem users like me when they try to figure out if
> some rogue cancel bot is at it again)

I think that's more a USEAGE thing.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 30 Nov 2006 23:18:15 -0500

> of it is no showstopper, but I'd like to know your justification for

We are not chartered to produce an experimental RFC. (I don't
have a problem with someone going off and doing that. But I
have always objected to it happening here.)

Many features got into the drafts under a sadly mistaken assumption
about how the world works. Including a feature in a "proposed standard"
does NOT mean that future implementors could be forced or shamed into
implementing it.

Practical considerations (limited software developer manpower) and
Engineering considerations (limited bandwidth/storage/CPU) are always
going to trump what the proposed standard says.  People don't care that
much about being labeled "out of compliance."

Remember, RFCs are merely invitations to do something a certain way,
IF YOU HAVE DECIDED _ALREADY_ TO IMPLEMENT.

mvgroup is experimental and will not be standardized in any reasonable
time frame.  Why?  It is hard to implement on some servers, due to architecture
choices.  So it has high implementation cost.  My perception is that it is 
likely to be used only dozens of times per year.  So it has low value.
It requires interoperating server and client implementations, so it
has a chicken and egg problem.

There are not going to interoperating implementations in any reasonable time.
Ergo, not standardized in reasonable time.
Ergo, remove it from the draft.

I admit others can have different opinions on deciding if a particular feature 
is experimental.  But if the consensus is that it is experimental, then remove
it from the draft.

Can someone make a case for why mvgroup belongs in THIS draft and not as
a separate document?  What is the problem with letting mvgroup stand on its own 
merits?

Date: Thu, 30 Nov 2006 23:18:15 -0500
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Proposing a new editor for the USEPRO document
Sender: [email-masked]

> of it is no showstopper, but I'd like to know your justification for

We are not chartered to produce an experimental RFC. (I don't
have a problem with someone going off and doing that. But I
have always objected to it happening here.)

Many features got into the drafts under a sadly mistaken assumption
about how the world works. Including a feature in a "proposed standard"
does NOT mean that future implementors could be forced or shamed into
implementing it.

Practical considerations (limited software developer manpower) and
Engineering considerations (limited bandwidth/storage/CPU) are always
going to trump what the proposed standard says.  People don't care that
much about being labeled "out of compliance."

Remember, RFCs are merely invitations to do something a certain way,
IF YOU HAVE DECIDED _ALREADY_ TO IMPLEMENT.

mvgroup is experimental and will not be standardized in any reasonable
time frame.  Why?  It is hard to implement on some servers, due to architecture
choices.  So it has high implementation cost.  My perception is that it is 
likely to be used only dozens of times per year.  So it has low value.
It requires interoperating server and client implementations, so it
has a chicken and egg problem.

There are not going to interoperating implementations in any reasonable time.
Ergo, not standardized in reasonable time.
Ergo, remove it from the draft.

I admit others can have different opinions on deciding if a particular feature 
is experimental.  But if the consensus is that it is experimental, then remove
it from the draft.

Can someone make a case for why mvgroup belongs in THIS draft and not as
a separate document?  What is the problem with letting mvgroup stand on its own 
merits?

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Proposing a new editor for the USEPRO document
Organization: The Eyrie
Date: Thu, 30 Nov 2006 15:59:54 -0800
Sender: [email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Proposing a new editor for the USEPRO document
Date:  Fri, 01 Dec 2006 00:25:19 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 48
Sender: [email-masked]

[...]

Sounds good.

Probably a good idea.

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Proposing a new editor for the USEPRO document
Organization: The Eyrie
Date: Thu, 30 Nov 2006 13:28:47 -0800
Sender: [email-masked]

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usepro-06.txt 
Date: Mon, 27 Nov 2006 15:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: News Article Architecture and Protocols
	Author(s)	: C. Lindsey
	Filename	: draft-ietf-usefor-usepro-06.txt
	Pages		: 55
	Date		: 2006-11-27
	
This Draft, together with its companion draft [USEFOR], are
   intended as standards track documents, together obsoleting RFC
   1036, which itself dates from 1987.

   This Standard defines the architecture of Netnews systems and
   specifies the requirements to be met by software which originates,
   distributes, stores and displays Netnews articles.

   Backward compatibility has been a major goal of this endeavour, but
   where this standard and earlier documents or practices conflict, this
   standard should be followed. In most such cases, current practice is
   already compatible with these changes.

   A companion Best Current Practice document [USEAGE], addressing
   requirements which are present for Social rather than Normative
   reasons is in preparation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-06.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-usepro-06.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-usepro-06.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-usepro-06.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Xref: clerew local.usefor:23760
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: draft-ietf-usefor-usepro-06
Date: Fri, 24 Nov 2006 19:43:56 GMT
Lines: 21
Sender: [email-masked]

On its way to the drafts editor.

In the meantime, you can look at

   http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-usepro-06.txt
   http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-usepro-06.unpaged

and for the diffs

   http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-usepro-06-from-5.wdiff.html

Date: Thu, 23 Nov 2006 05:38:35 -0800
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposing a new editor for the USEPRO document
Sender: [email-masked]

               Harald

To: [email-masked]
Xref: clerew local.usefor:23753
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Proposing a new editor for the USEPRO document
Date: Wed, 22 Nov 2006 13:04:05 GMT
Lines: 92
Sender: [email-masked]

Date: Tue, 21 Nov 2006 11:01:01 -0500
From: Dan Schlitt <[email-masked]>
To: Harald Alvestrand <[email-masked]>
cc: [email-masked]
Subject: Re: Proposing a new editor for the USEPRO document
Sender: [email-masked]

/dan

-- 

Dan Schlitt
[email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Proposing a new editor for the USEPRO document
Date:  Tue, 21 Nov 2006 16:12:37 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Frank

Date: Tue, 21 Nov 2006 10:34:12 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Proposing a new editor for the USEPRO document
Sender: [email-masked]

Greetings,

                         The chairs

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date:  Wed, 15 Nov 2006 20:36:47 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Sender: [email-masked]

Lisa Dusseault wrote:

> It's currently an experiment, as we don't have a real process
> for knowing when "early review" happens or on which documents

That "early review" rings a bell, I've read about it somewhere,
techspec or a similar list.

> Thanks for the reminder to put pointers to it at some point.

I'd know where to do it for the non-WG-list, but this would end
up in your inbox anyway - I tested the submission form for the
smtp list last year (worked, Scott got it, and it's now listed).

Frank

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date: Tue, 14 Nov 2006 19:46:38 -0800
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

We just started that list this year, intending to do early review of  
documents by a review team with expertise common to Apps area (XML,  
HTTP, i18n, etc).  It's currently an experiment, as we don't have a  
real process for knowing when "early review" happens or on which  
documents, but I'm working with a bunch of WG chairs to see if they  
like getting review by this list and others (like the security  
directorate review team).

Thanks for the reminder to put pointers to it at some point.

Lisa

On Nov 14, 2006, at 1:43 PM, Frank Ellermann wrote:

>
> Alexey Melnikov wrote:
>
>> The issue was reraised by Dave Cridland on Apps review mailing list.
>
> http://www1.ietf.org/mail-archive/web/apps-review/current/ 
> msg00005.html
>
> I'd have loved to build some kind of stable converging at a magic FWS
> instead of a magic SP, but months or rather years later... :-(
>
> BTW, I didn't know that this list exists, it's no IETF list as far as
> the "official" non-WG-list page is concerned:
>
> https://datatracker.ietf.org/public/nwg_list.cgi
>
> It also isn't listed on the "apps" area page http://www.apps.ietf.org/
> or on the "apps" list page http://www.apps.ietf.org/mailing-lists.html
>
> At least it's now clear what the remark on the apps-discuss list about
> an "issue raised so far on subsetting and supersetting RFC2822" meant,
> compare http://permalink.gmane.org/gmane.ietf.apps-discuss/179
>
> Frank
>
>

Date: Tue, 14 Nov 2006 21:58:56 +0000
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Sender: [email-masked]

Charles Lindsey wrote:

>It would be more appropriate to try to persuade RFC 2822bis (there is a
>draft out, but no public comments on it yet) to move that 'no SP after
>colon' to its obs syntax. Nobody anywhere in the world ever generates
>headers with that space missing (except when trying to 'show off' that
>they cover all obscure cases).
>  
>
That would be nice. But unfortunately my Sieve parser will have to 
handle lack of the space for many years to come.

>There are a few other things that RFC2822bis should do to move nearer to
>Netnews, such as making its message-ids 'octet comparable', as we have
>done.
>  
>
(chair hat off) I would encourage you to do that.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date:  Tue, 14 Nov 2006 22:43:01 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Alexey Melnikov wrote:

> The issue was reraised by Dave Cridland on Apps review mailing list.

http://www1.ietf.org/mail-archive/web/apps-review/current/msg00005.html

I'd have loved to build some kind of stable converging at a magic FWS
instead of a magic SP, but months or rather years later... :-(

BTW, I didn't know that this list exists, it's no IETF list as far as
the "official" non-WG-list page is concerned:

https://datatracker.ietf.org/public/nwg_list.cgi

It also isn't listed on the "apps" area page http://www.apps.ietf.org/
or on the "apps" list page http://www.apps.ietf.org/mailing-lists.html

At least it's now clear what the remark on the apps-discuss list about
an "issue raised so far on subsetting and supersetting RFC2822" meant,
compare http://permalink.gmane.org/gmane.ietf.apps-discuss/179

Frank

Date: Tue, 14 Nov 2006 18:43:24 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Sender: [email-masked]

Frank Ellermann wrote:

>Lisa Dusseault wrote:
>  
>
>> As far as the list is concerned, we might as well assume that 
>>Alexey had the idea
>>    
>>
>Unlikely, he wouldn't claim that his personal opinion alone is some
>kind of IETF consensus no matter what the WG discussed for months -
>after all he was forced to watch some rounds of these discussions.
>  
>
The issue was reraised by Dave Cridland on Apps review mailing list.

To: [email-masked]
Xref: clerew local.usefor:23732
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date: Tue, 14 Nov 2006 14:05:30 GMT
Lines: 34
Sender: [email-masked]

>> I concur.

>> And RFC3977 (NNTP) doesn't support it either, and the IETF allowed that
>> one through without demur.

>Oh, good point.  I had completely forgotten about that.

And you can add to that that RFC 1036 required it. And in the very early
days of this WG we took the view that we should not REQUIRE (or even
RECOMMEND) that News agents accept constructs that had never ever been
seen in any News Article - that was also why we ditched the obs-syntax
from RFC 2822.

And we can be quite sure that no article with that SP missing ever got out
into the wild because the software around then (as now) would have choked
on it.

Of course, an agent that handles both Mail and News will have to accept
that missing SP, which is why that "MAY" is there.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: usefor-11 diffs
Date:  Tue, 14 Nov 2006 17:27:47 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Sender: [email-masked]

Ken Murchison wrote:

> The changes to the section numbering style is obviously an xml2rfc'ism.

Odd, if it doesn't like dots anymore, why did it remove them everywhere
but not for chapter 7 (references) ?  I didn't get that effect with my
combination of "processing instructions" <?rfc some="thing"> + 1.32pre2.

Rhethoric question, I'm too lazy to debug which combination of "PIs" or
other factors might have caused this "dotless" effect.  The I-D is of
course fine otherwise, informative [Errata] is clearly better than
normative.  Besides Ned's 2045-erratum submitted 2004-02 is not yet
published, IIRC that was Bruce's point about the [errata] reference.

Frank

Date: Mon, 13 Nov 2006 20:44:02 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: usefor-11 diffs
Sender: [email-masked]

The changes from the GenArt and AD reviews were minor.  The changes to 
the section numbering style is obviously an xml2rfc'ism.

http://tinyurl.com/yggm8y

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usefor-11.txt 
Date: Mon, 13 Nov 2006 18:50:01 -0500
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date:  Mon, 13 Nov 2006 23:12:39 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 33
Sender: [email-masked]

Lisa Dusseault wrote:

> You might raise this on [email-masked] if you support a change in
> policy or announcement text.

Yes, the next round of 2026bis is scheduled for spring 2007 directly
after the next "UTF-8 RFCs in Office formats" thread... ;-)

>=A0As far as the list is concerned, we might as well assume that =

> Alexey had the idea

Unlikely, he wouldn't claim that his personal opinion alone is some
kind of IETF consensus no matter what the WG discussed for months -
after all he was forced to watch some rounds of these discussions.

A consistent change to "let's at least _try_ to get rid of the odd
magic SP" would require much more than one s/MAY/SHOULD/ - Bruce
posted various proposals in this direction.  I also tried it, but
it didn't fly... :-(

>=A0We shouldn't disallow input just because we don't quite know where
> it came from :)

If it's convincing there could be a summary and a new "last call",
or better return the I-D to the WG before if it came from a WG...

Whatever took them ten years, maybe it was more difficult than some
last minute modifications of 2119-keywords.  Or maybe it was a bad
compromise after a long time, but that could be discussed in public.

Frank

From: Russ Allbery <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Organization: The Eyrie
Date: Mon, 13 Nov 2006 11:44:21 -0800
Sender: [email-masked]

Lisa Dusseault <[email-masked]> writes:
> On Nov 10, 2006, at 10:41 AM, Frank Ellermann wrote:

>> With a MAY I'm not too surprised if my tests resulted in a series of
>> "maybe not" (admittedly all tested servers were INNs)

> Yes, MAY has the associated implication of "maybe not".  Thus I can't
> see how this change in itself makes any clients uncompliant.

MAY is certainly fine (and is the current language).  Changing the MAY to
a SHOULD (in the sense of "agents SHOULD accept headers without the SP")
is a problem because, among other things NNTP requires the space:

   The headers of an article consist of one or more header lines.  Each
   header line consists of a header name, a colon, a space, the header
   content, and a CRLF, in that order.

RFC 3977, section 3.6.  We'd tried to write the NNTP specification (and in
particular the specification of the overview format and the OVER and HDR
commands) without requiring this and it added so much complexity for a
case not seen in the real world and not accepted by existing software that
we simply required it.

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date: Mon, 13 Nov 2006 11:02:46 -0800
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

--Apple-Mail-1-453773175
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Nov 10, 2006, at 10:41 AM, Frank Ellermann wrote:

>  But if the comments are
> sent to "invisible" addresses (iesg@ or private mail) it's not
> more obvious how the new consensus was determined.
>
> First time that I see this as a potential problem - if I post
> a comment in a "Last call" it's normally on some public list.

We don't require LC comments to be public though I agree it is nice  
to have.  The IESG is thinking about whether to change its LC  
feedback guidance to prefer the public WG lists, or the public IETF  
discussion list, over the private IESG list.  But as it stands right  
now, the latter two are specifically suggested in LC announcements,  
and no other options are forbidden.  You might raise this on  
[email-masked] if you support a change in policy or announcement text.

In general, a reasonable technical point can be raised in many ways.   
It could occur to a participant at any time instead of being  
suggested via private mail.  As far as the list is concerned, we  
might as well assume that Alexey had the idea as that it was  
suggested to him by somebody else during last call.  We shouldn't  
disallow input just because we don't quite know where it came from :)

This particular issue is not yet a matter for consensus, specifically  
it's not a matter of IETF consensus overriding a WG consensus.    
Consensus is more useful when balancing tradeoffs than when making  
corrections (and though there's no fine line between the two there is  
a gradation).

>
>> But - one objection to the objection:
>> Frank, a MUST NOT generate / SHOULD accept is no more
>> inconsistent than a MUST NOT generate/MAY accept is.
>
> With a MAY I'm not too surprised if my tests resulted in a
> series of "maybe not" (admittedly all tested servers were INNs)

Yes, MAY has the associated implication of "maybe not".  Thus I can't  
see how this change in itself makes any clients uncompliant.

Thanks!
Lisa
--Apple-Mail-1-453773175
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On Nov 10, 2006, =
at 10:41 AM, Frank Ellermann wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><SPAN =
class=3D"Apple-converted-space">=A0</SPAN>But if the comments =
are</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">sent to =
"invisible" addresses (iesg@ or private mail) it's not</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">more obvious how the new =
consensus was determined.</FONT></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">First time that I see this =
as a potential problem - if I post</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">a comment in a "Last call" it's normally on some =
public list.</FONT></P></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>We don't require LC =
comments to be public though I agree it is nice to have.=A0 The IESG is =
thinking about whether to change its LC feedback guidance to prefer the =
public WG lists, or the public IETF discussion list, over the private =
IESG list.=A0 But as it stands right now, the latter two are =
specifically suggested in LC announcements, and no other options are =
forbidden.=A0 You might raise this on <A =
href=3D"mailto:[email-masked]">[email-masked]</A> if you support a change =
in policy or announcement text.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>In general,=A0a reasonable =
technical point can be raised in many ways. =A0It could occur to a =
participant at any time instead of being suggested via private mail.=A0=A0=
As far as the list is concerned, we might as well assume that Alexey had =
the idea as that it was suggested to him by somebody else during last =
call.=A0=A0We shouldn't disallow input just because we don't quite know =
where it came from :)=A0=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>This particular issue is =
not yet a matter for consensus, specifically it's not a matter of IETF =
consensus overriding a WG consensus. =A0 Consensus is more useful when =
balancing tradeoffs than when making corrections (and though there's no =
fine line between the two there is a gradation).</DIV><BR><BLOCKQUOTE =
type=3D"cite"> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px =
Helvetica; min-height: 14.0px"><BR></P> <BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">But - one objection to the =
objection:</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Frank, a MUST NOT generate / SHOULD accept is no more<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></FONT></P> <P style=3D"margin: =
0.0px 0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">inconsistent than a MUST NOT =
generate/MAY accept is.</FONT></P> </BLOCKQUOTE><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: =
14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">With a =
MAY I'm not too surprised if my tests resulted in a</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">series of "maybe not" =
(admittedly all tested servers were INNs)</FONT></P> =
</BLOCKQUOTE></DIV><BR><DIV>Yes, MAY has the associated implication of =
"maybe not".=A0 Thus I can't see how this change in itself makes any =
clients uncompliant.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Thanks!</DIV><DIV>Lisa</DIV><=
/BODY></HTML>=

--Apple-Mail-1-453773175--

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Organization: The Eyrie
Date: Mon, 13 Nov 2006 09:25:25 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> I concur.

> And RFC3977 (NNTP) doesn't support it either, and the IETF allowed that
> one through without demur.

Oh, good point.  I had completely forgotten about that.

To: [email-masked]
Xref: clerew local.usefor:23721
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date: Mon, 13 Nov 2006 12:28:46 GMT
Lines: 51
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

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

>> Based on LC comments, -11 will change the following sentence in section
>> 2.2 to use SHOULD instead of the MAY:

>>      News agents MAY accept header fields which do not contain the
>>      required space.

>I doubt there's any existing news software anywhere that supports this.
>INN certainly doesn't.  This change basically declares all existing news
>software non-compliant, and on a point where I expect most implementors to
>see that change and ignore it, refusing to change their software.

>I strongly disagree with this change, enough so that I would raise a Last
>Call objection to it myself were it in the document at the time of Last
>Call.  This is a little-used corner case of the RFC 2822 standard that
>isn't even used in practice by e-mail clients on any broad basis.  A
>significant amount of existing news software will outright reject such
>articles, and given the slow upgrade path for news software, that will
>likely continue to be the case for decades.  It's almost impossible that
>such articles would ever be usefully usable in the wild, and the "feature"
>is of marginal utility only (basically *only* for compatibility with an
>e-mail feature no one uses).

I concur.

And RFC3977 (NNTP) doesn't support it either, and the IETF allowed that
one through without demur.

It would be more appropriate to try to persuade RFC 2822bis (there is a
draft out, but no public comments on it yet) to move that 'no SP after
colon' to its obs syntax. Nobody anywhere in the world ever generates
headers with that space missing (except when trying to 'show off' that
they cover all obscure cases).

There are a few other things that RFC2822bis should do to move nearer to
Netnews, such as making its message-ids 'octet comparable', as we have
done.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date:  Fri, 10 Nov 2006 19:41:15 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Sender: [email-masked]

Harald Alvestrand wrote:

> The chairs messed up, having forgotten part of the history.

That's a dark corner in the standards process, "IETF consensus"
must beat "WG consensus" if necessary.  But if the comments are
sent to "invisible" addresses (iesg@ or private mail) it's not
more obvious how the new consensus was determined.

First time that I see this as a potential problem - if I post
a comment in a "Last call" it's normally on some public list.
 
> But - one objection to the objection:
> Frank, a MUST NOT generate / SHOULD accept is no more 
> inconsistent than a MUST NOT generate/MAY accept is.

With a MAY I'm not too surprised if my tests resulted in a
series of "maybe not" (admittedly all tested servers were INNs)

With a SHOULD the magic SP MUSTard everywhere - even in appendix
C there's a REQUIRED, the very first thing listed as "important"
- would be undermined.  A new SHOULD would be also relevant for
apppendix B.

We discussed it for months, I tried all exits like 1*WSP or *WSP
instead of SP *WSP, but unfortunately they all failed miserably.

Frank

Date: Fri, 10 Nov 2006 09:30:16 -0800
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Sender: [email-masked]

I think the point is clearly made.

The chairs messed up, having forgotten part of the history.
Editor, please revert the SHOULD to a MAY; if the doc is already sent to 
the I-D queue, we'll do this via an RFC Editor note.

But - one objection to the objection:
Frank, a MUST NOT generate / SHOULD accept is no more inconsistent than a 
MUST NOT generate/MAY accept is.

                 Harald

--On 10. november 2006 13:57 +0100 Frank Ellermann 
<[email-masked]> wrote:

>
> Alexey Melnikov wrote:
>
>> Based on LC comments
>
> Where?  I haven't seen any public comments, only the GenArt review,
> and IANA's confirmation that they looked at the "considerations".
>
> The tracker said "waiting for writeup", and now it was switched to
> "waiting for writeup - revised ID needed" by Lisa.
>
>> MAY is too week, people would like to use MUST, but this is
>> impractical due to backward compatibility.
>
> The magic SP issue took about one of the ten USEFOR years, touching
> it now somewhere behind the scenes is execessively annoying and rude.
>
> There are no "people" and no comments I'm aware of.  Accepting no
> magic SP is clearly an OPTION in 2119-termonology, no recommendation.
>
> The draft uses MUSTard for the magic-SP.  You can't have a SHOULD
> conflicting with a MUST.  This needs a new IETF LC, it's no obscure
> "experiment", where a SHOULD conflicting with a SHOULD NOT is no
> big deal, or at least that's what some I* PTB decreed.
>
> JFTR, I don't love the magic SP.  Count me in if you want to add a
> note that it's ridiculous.  But no SHOULD against the WG consensus.
>
> Frank
>
>
>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Date:  Fri, 10 Nov 2006 13:57:40 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Sender: [email-masked]

Alexey Melnikov wrote:
 
> Based on LC comments

Where?  I haven't seen any public comments, only the GenArt review,
and IANA's confirmation that they looked at the "considerations".

The tracker said "waiting for writeup", and now it was switched to
"waiting for writeup - revised ID needed" by Lisa.

> MAY is too week, people would like to use MUST, but this is 
> impractical due to backward compatibility.

The magic SP issue took about one of the ten USEFOR years, touching
it now somewhere behind the scenes is execessively annoying and rude.

There are no "people" and no comments I'm aware of.  Accepting no
magic SP is clearly an OPTION in 2119-termonology, no recommendation.

The draft uses MUSTard for the magic-SP.  You can't have a SHOULD
conflicting with a MUST.  This needs a new IETF LC, it's no obscure
"experiment", where a SHOULD conflicting with a SHOULD NOT is no
big deal, or at least that's what some I* PTB decreed.

JFTR, I don't love the magic SP.  Count me in if you want to add a
note that it's ridiculous.  But no SHOULD against the WG consensus.

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Organization: The Eyrie
Date: Thu, 09 Nov 2006 18:07:40 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Based on LC comments, -11 will change the following sentence in section
> 2.2 to use SHOULD instead of the MAY:

>      News agents MAY accept header fields which do not contain the
>      required space.

I doubt there's any existing news software anywhere that supports this.
INN certainly doesn't.  This change basically declares all existing news
software non-compliant, and on a point where I expect most implementors to
see that change and ignore it, refusing to change their software.

I strongly disagree with this change, enough so that I would raise a Last
Call objection to it myself were it in the document at the time of Last
Call.  This is a little-used corner case of the RFC 2822 standard that
isn't even used in practice by e-mail clients on any broad basis.  A
significant amount of existing news software will outright reject such
articles, and given the slow upgrade path for news software, that will
likely continue to be the case for decades.  It's almost impossible that
such articles would ever be usefully usable in the wild, and the "feature"
is of marginal utility only (basically *only* for compatibility with an
e-mail feature no one uses).

Date: Thu, 09 Nov 2006 17:50:41 -0800
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: IETF LC comment on draft-ietf-usefor-usefor-10.txt
Sender: [email-masked]

Based on LC comments, -11 will change the following sentence in section 
2.2 to use SHOULD instead of the MAY:

      News agents MAY accept header fields which do not contain the 
required space.

(MAY is too week, people would like to use MUST, but this is impractical 
due to backward compatibility.)