Subject: draft-ietf-usefor-usefor-09

From: Ken Murchison <[email-masked]>
Date: Mon, 28 Aug 2006 11:31:53 -0400

I just submitted USEFOR draft -09.  This draft includes resolutions to
the tickets opened during the last call.

You can grab the full document from here:

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

Or see the diffs from -08 here:

http://tinyurl.com/qtwe4

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 31 Aug 2006 10:28:21 GMT

>http://tinyurl.com/qtwe4

Yes, that seems a job well done.

Naturally, I have a few niggles, but Ken can probably just take note of
them now until there is an opportunity to fix them. Only one of them may
need some thought from this WG.

#1. In section 1.5 (Definitions), the term "followup" has been changed to
"follow-up". Did we ever agree on that? Because the usage of the term has
not been changed elsewhere in the document. I count 9 occurrences of
"followup" remaining, including one in the paragraph defining "follow-up"
itself, which now reads:

   A "follow-up" is an article containing a response to the contents of
   an earlier article, its "precursor".  Every followup includes a
   "References" header field identifying that precursor (but note that
   non-followup articles may also use a References header field).

For sure, "followup" is the term regularly used in the Real World out
there, and if we are going to adopt this change, then it needs to be
changed elsewhere ion the document, and I need to go through USEPRO and
USEAGE and change it there.

May I suggest it would ne simpler just to put it back as "followup"?

#2. In section 3.1.5 (Path), "upper case" has been changed to
"upper-case". And yet the document also contains another instance of
"uppercase", and that is the term that is used throughout USEPRO (and in
lot of other places too, including RFC 2822). I suggest we stick to
"uppercase" throughout (I agree that "upper case" needed changing).

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

#4. In section 3.2.7 (Injection-Date) we have:

      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.

s/as be expected/as would be expected/.

-- 
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: Ken Murchison <[email-masked]>
Date: Thu, 31 Aug 2006 09:02:24 -0400

> May I suggest it would ne simpler just to put it back as "followup"?

Done.  Not sure how it got changed in the first place.

> "uppercase" throughout (I agree that "upper case" needed changing).

Done.

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

> s/as be expected/as would be expected/.

Done.  There was an extra space where "would" should have been, probably 
the result of a bad cut-n-paste.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 31 Aug 2006 16:08:32 +0200

> Or see the diffs from -08 here:

Thanks.  The default rfcdiff HTML output is hard to read with
my browser, but I just found that rfcdiff has at least three
"undocumented" output formats.  Taking the long URL of your
tinyurl and adding a parameter &difftype= does the the trick:

...&difftype=--abdiff is a "before after diff" (OLD + NEW with
           context, like the HTML output, but not side by side)
...&difftype=--chbars shows url2 (= -09) as is with a change
           bar in column 1 (very readable)
...&difftype=--hwdiff is a HTML wdiff.  I didn't like wdiff as
           plain text tool, but presented as HTML it's great:
           Removed parts red, inserted parts green.

Sorting the header fields was a good idea.

 [-09]
| making all headers compliant with this specification
| inherently compliant with [RFC2822].

That was "all messages", why a restriction to "all headers" ?
We didn't do anything weird with the <body>, and actually we
removed a minor difference from RFC2822 (empty <body> case).

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

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

In 3.1.5 (Path) we have a ... "; compare RFC3696", that didn't
make it into the informative references.

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

Please s/two-letter country names/two-letter country codes/

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

I'd still opt for VCHAR in <article-locator>, and also in
<argument>, importing it from 4234.  

And if I could I'd also put VCHAR in <unstructured> instead
of <utext>, but it's clear that this is a minority position.

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

In the security considerations there's one sentence suddenly
talking to the reader with "if you see" ... "you can predict".
Is that okay ?  If not maybe write:  "If a bad actor can" etc.
(or similar, something without "you" and "your").  

s/addreses/addresses/ in apendix B.

In essence two typos and two nits, and an "A" in Harald's poll.

Thanks, Frank

---

From: Ken Murchison <[email-masked]>
Date: Thu, 31 Aug 2006 11:55:20 -0400

>            Removed parts red, inserted parts green.

Ahh, nice find.  The hwdiff format is exactly what the RFC editors send 
to authors during AUTH48.

> removed a minor difference from RFC2822 (empty <body> case).

This was Harald's suggested text, so I'll let him defend it.

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

> make it into the informative references.

Fixed.

> It could be an unnecessary MUST NOT.

Don't know.  AFAICT, ticket #1309 didn't direct me to remove it.

> Please s/two-letter country names/two-letter country codes/

Fixed.

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

How about "Once a user agent generates a User-Agent header field, ..."

> of <utext>, but it's clear that this is a minority position.

I'll let the WG and/or chairs make this call.

> want any effects of "Also-Control".

Seems reasonable to me, but I'll let the WG and/or chairs make this call.

> (or similar, something without "you" and "your").  

How about this:

"If a malicious agent can predict the identifier of a message, it can 
preempt the message by posting its own message (possibly to a quite
different group) with the same message identifier, thereby preventing 
the target message from propagating.  Therefore, agents ..."

> s/addreses/addresses/ in apendix B.

Fixed.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 31 Aug 2006 23:34:35 +0200

> removed a minor difference from RFC2822 (empty <body> case).
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.....

                             Harald

Date: Thu, 31 Aug 2006 23:34:35 +0200
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-usefor-usefor-09
Sender: [email-masked]

> removed a minor difference from RFC2822 (empty <body> case).
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.....

                             Harald

Date: Thu, 31 Aug 2006 11:55:20 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Frank Ellermann <[email-masked]>
CC: [email-masked], Harald Tveit Alvestrand <[email-masked]>
Subject: Re: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Fixed.

Fixed.

How about this:

Fixed.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: draft-ietf-usefor-usefor-09
Date:  Thu, 31 Aug 2006 16:08:32 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 65
Sender: [email-masked]

 [-09]

Thanks, Frank

Date: Thu, 31 Aug 2006 09:02:24 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-usefor-usefor-09
Sender: [email-masked]

Done.

To: [email-masked]
Xref: clerew local.usefor:23581
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-ietf-usefor-usefor-09
Date: Thu, 31 Aug 2006 10:28:21 GMT
Lines: 71
Sender: [email-masked]

Date: Thu, 31 Aug 2006 00:18:40 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: WG LAST CALL RESOLUTION OF COMMENTS: draft-ietf-usefor-usefor-09
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usefor-09.txt 
Date: Tue, 29 Aug 2006 15:50:02 -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-09.txt
	Pages		: 53
	Date		: 2006-8-29
	
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-09.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-09.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-09.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-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 28 Aug 2006 11:31:53 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: draft-ietf-usefor-usefor-09
Sender: [email-masked]

http://tinyurl.com/qtwe4

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1314 Resolution - Newsgroups and reserved characters
Date:  Fri, 25 Aug 2006 14:06:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Charles Lindsey wrote:
 
> there was no specific extension in view. There were just
> three characters (+-_) that were syntactically harmless, but
> by well-established convention _never_ appeared at the start

Okay, maybe "'_' for I18N" is a product of my imagination, and
the future USEFORbis could find better uses for it.

> we might want some day for each newsgroup to be accompanied
> by a meta-group containing meta-information about the main
> group

For meta-data see also draft-dfncis-netnews-admin-sys-07.txt -
trapped in the RFC editor queue for four years.  

Frank

To: [email-masked]
Xref: clerew local.usefor:23577
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Date: Fri, 25 Aug 2006 10:24:57 GMT
Lines: 44
Sender: [email-masked]

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

>Harald Alvestrand wrote:

>>> We could be more specific why "_" is reserved:  s/future
>>> versions/future I18N/

>> We don't have a documented consensus on what it's going to
>> be used for.

>Yes, but I assumed that there once was some kind of consensus
>why it's reserved - if a hypothetical USEFORbis finds another
>solution (like the 2047-constructs in s-o-1036) they could then
>"unreserve" the underline.  Otherwise they (= USEFORbis folks)
>might not know that they are supposed to use or "unreserve" it.

No, there was no specific extension in view. There were just three
characters (+-_) that were syntactically harmless, but by well-established
convention _never_ appeared at the start of a newsgroup-component. We
wished to preseve the convention, so took the opportunity of reserving
those characters for special uses.

I have at times suggested odd things that '+' and '-' might be used by
particular servers by private arrangement with their own clients. If you
want a suggestion for '_', then we might want some day for each newsgroup
to be accompanied by a meta-group containing meta-information about the
main group (NOCEMs for articles in the main group, perhaps). So if the
main group was example.foo, then the meta-group would be _example.foo.
>> So better not say.

Agreed to that. It is just a loophole which costs nothing, but might be
useful someday.

To: [email-masked]
Xref: clerew local.usefor:23578
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Date: Fri, 25 Aug 2006 10:29:41 GMT
Lines: 31
Sender: [email-masked]

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

>Frank Ellermann wrote:
>> <shrug />  So let them read the old USEFOR archive.  With other
>> Chairs I'd be paranoid about the curious lack of I18N in this
>> draft.  When the UTF-8 header fields were killed four years ago
>> in a WGLC the various *prep RFCs didn't exist.
>>   
>this WG was chartered to fix that.....

>I guess we need a new charter even though it's out-of-sequence with our 
>other out-of-date milestones...

When we have got our present committments out of the way, then it would be
in order to sit down and see what other unfinished business we need to
attend to, and a charter revision would then be in order.

The things that spring to mind are I18N (but the EAI group seems to be
laying a good groundwork for that) and various security-related matters.
But that is all for the future.

To: [email-masked]
Xref: clerew local.usefor:23572
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1299 Suggested resolution
Date: Thu, 24 Aug 2006 14:26:10 GMT
Lines: 33
Sender: [email-masked]

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

>Harald Alvestrand wrote:

>> Accept:
>> 
>> An agent is said to "accept" a construct if some other entity
>> generates it and passes it to the agent in question, and the agent 
>> processes it without treating it as a protocol error.

>I changed the above to "... without treating it as a format or protocol 
>error" in the draft, since this is the Usenet format draft.

Yes, that is better.

Once you have accepted it as not being a format error, then USEPRO should
tell you what, if anything, you are supposed to do with it next.

If we find a situation where USEFOR says you MUST/SHOULD/MAY accept
something, and then USEPRO fails to tell you what to do with it, then that
would be a bug in USEPRO. We need to watch out for those, but I am not
aware of any such cases.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1314 Resolution - Newsgroups and reserved characters
Date:  Thu, 24 Aug 2006 16:56:01 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

Harald Alvestrand wrote:

> I guess we need a new charter

If there's something better than "No Request For Comments"
at the end of that page, approved and waiting for missing
normative references will do.

For some of the open questions in the old charter it can
be good if mail solutions like DKIM or EAI test the water
before NetNews.

Frank

Date: Thu, 24 Aug 2006 02:09:45 -0700
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Sender: [email-masked]

Frank Ellermann wrote:
> <shrug />  So let them read the old USEFOR archive.  With other
> Chairs I'd be paranoid about the curious lack of I18N in this
> draft.  When the UTF-8 header fields were killed four years ago
> in a WGLC the various *prep RFCs didn't exist.
>   
this WG was chartered to fix that.....

> At the present time an urgent need has been identified to formalize and
> document many of the current and proposed extensions to the Usenet
> Article format. Many extensions are only vaguely documented and have
> competing and overlapping alternatives.
>
> In particular the following areas need urgent attention:
>
> - Standards for the signing of articles (sign-control and PGP-MOOSE)
> - Authentication of cancels.
> - Use of non-ASCII character sets in article headers and bodies
> - Standardization of article bodies and the use of MIME in articles.
> - Standardization and extension of 3rd party control messages affecting
>   articles (NOCEM)
> - General revision of various limits (eg article size) listed in
>   previous standards.
>
> and many other aspects of the standards need reviewing.
>
I guess we need a new charter even though it's out-of-sequence with our 
other out-of-date milestones...

                     Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1314 Resolution - Newsgroups and reserved characters
Date:  Thu, 24 Aug 2006 10:21:57 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Harald Alvestrand wrote:

>> We could be more specific why "_" is reserved:  s/future
>> versions/future I18N/

> We don't have a documented consensus on what it's going to
> be used for.

Yes, but I assumed that there once was some kind of consensus
why it's reserved - if a hypothetical USEFORbis finds another
solution (like the 2047-constructs in s-o-1036) they could then
"unreserve" the underline.  Otherwise they (= USEFORbis folks)
might not know that they are supposed to use or "unreserve" it.
 
> So better not say.

<shrug />  So let them read the old USEFOR archive.  With other
Chairs I'd be paranoid about the curious lack of I18N in this
draft.  When the UTF-8 header fields were killed four years ago
in a WGLC the various *prep RFCs didn't exist.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1312 Resolution - Lines
Date:  Thu, 24 Aug 2006 09:57:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Charles Lindsey wrote:
 
> I specifically asked for it to be made clear that is was
> "body" as defined by the syntax that was meant. Agreed that
> putting it in <...> is almost good enough.

That's what I meant, all terms in angle brackets in the prose
are no nonsense, they are defined before, ABNF or imported
ABNF.  No big deal, "make a shorter draft" => "lillyguilding"
=> "time for a new draft if there are no serious problems with
other tickets".

Ticket 1312 was "description of Lines header field can be much
shorter" in Alexey's list of Ralph's points,

Frank

Date: Wed, 23 Aug 2006 13:25:45 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Harald Alvestrand <[email-masked]>
CC: [email-masked]
Subject: Re: #1315 Definition of "poster"
Sender: [email-masked]

Harald Alvestrand wrote:
> 
> 
> Existing text in 1.5:
> 
>   A "poster" is the person or software that composes and submits a
>   possibly compliant article to a "user agent".  The poster is
>   analogous to an [RFC2822] author.
> 
> Suggested resolution:
> 
>   A "poster" is the person or software that composes and submits a
>   possibly compliant article to a "user agent".

I changed "possibly" to "potentially" in the draft.

Date: Wed, 23 Aug 2006 13:04:06 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: #1311 Resolution: Default value for the Archive header
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Harald Alvestrand <[email-masked]> writes:
> 
>> 3.2.12.  Archive
> 
> 
>>   The presence of an Archive header field in an article with a field
>>   body of "no" indicates that the poster does not permit
>>   redistribution
>>   from publicly accessible long-term or permanent archives.
>>   A field body of "yes" indicates that the poster permits such
>>   redistribution.
> 
>>   No parameters have been defined so far; if present, they can be
>>   ignored.
> 
>> I think discussion showed that this is not the document to talk about 
>> interpretation of the absence of the header.
> 
> Fine, if the matter is addressed in USEAGE. Do you want a pointer to
> USEAGE here?

Done.

To: [email-masked]
Xref: clerew local.usefor:23566
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1336 Expires field semantics
Date: Wed, 23 Aug 2006 11:39:17 GMT
Lines: 30
Sender: [email-masked]

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

>Suggested change:

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

>   NOTE: This is most useful when the poster desires an unusually long
>   or an unusually short expiry time.

>Let's not get into the interactions with local policy here.

Maybe s/desires/recommends/.

And maybe s/most//.

But if people want to omit the NOTE entirely, I can live with that, since
it will be in USEAGE anyway.

To: [email-masked]
Xref: clerew local.usefor:23563
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1312 Resolution - Lines
Date: Wed, 23 Aug 2006 11:16:15 GMT
Lines: 30
Sender: [email-masked]

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

>Harald Alvestrand wrote:
> 
>>   The line count is the number of CRLF separators in the
>> <body>, where <body> is defined in [RFC 2822].
> 
>> Add to "import interface" in section 1.4
> 
>>   body = <see RFC 2822 Section 3.5>
> 
>> OK?

>Sure.  For "make a shorter draft" fans the "where <body>" ...
>blurb is unnecessary after it's imported before its first use.

No. I specifically asked for it to be made clear that is was "body" as
defined by the syntax that was meant. Agreed that putting it in <...> is
almost good enough.

To: [email-masked]
Xref: clerew local.usefor:23565
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1315 Definition of "poster"
Date: Wed, 23 Aug 2006 11:36:21 GMT
Lines: 26
Sender: [email-masked]

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

>Harald Alvestrand wrote:
> 
>> A "poster" is the person or software that composes and
>> submits a possibly compliant article to a "user agent".

>Maybe add "operator of" before "software", IIRC we need
>"poster" as "human with a mailbox" later.

I don't think you need to be that specific. Any piece of software that
generates anything needs to be set up to cope with whatever bounces or
email responses may come its way. It the implementor believes that it is
OK not to forward it to a human, then that is up to him (and if he is
wrong, then it is his problem).

To: [email-masked]
Xref: clerew local.usefor:23562
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Resolution: Default value for the Archive header
Date: Wed, 23 Aug 2006 11:13:23 GMT
Lines: 31
Sender: [email-masked]

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

>3.2.12.  Archive

>   The presence of an Archive header field in an article with a field
>   body of "no" indicates that the poster does not permit
>   redistribution
>   from publicly accessible long-term or permanent archives.
>   A field body of "yes" indicates that the poster permits such
>   redistribution.

>   No parameters have been defined so far; if present, they can be
>   ignored.

>I think discussion showed that this is not the document to talk about 
>interpretation of the absence of the header.

Fine, if the matter is addressed in USEAGE. Do you want a pointer to
USEAGE here?

To: [email-masked]
Xref: clerew local.usefor:23564
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Date: Wed, 23 Aug 2006 11:31:38 GMT
Lines: 42
Sender: [email-masked]

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

>Wordsmithed resolution (going almost all the SHOULD way):

>Proposed new text:

><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 [I-D.ietf-usefor-usepro]). However, such names MUST be
>accepted by news servers, if permitted by site policy.

No, I don't think site policy is relevant here. The original intent was
that the future extension should be able to presume that these "funny"
articles would propagate normally through existing servers (at least until
they hit a server which knew what they meant and what to do with them).

But, of course, site policy is very relevant for the next case:

><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, if permitted by site policy.

but in that case you need to s/MUST/MAY/ (or maybe s/MUST/SHOULD/).

Or you could follow Harald's argument that they MUST be accepted (or
servers MUST be capable of accepting them). But then you need to
understand what "accept" means, and IMO "accept" includes "read and
recognize, and then drop on the floor".

Date: Wed, 23 Aug 2006 10:30:50 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Harald Alvestrand <[email-masked]>
CC: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1299 Suggested resolution
Sender: [email-masked]

Harald Alvestrand wrote:
> 
> Charles Lindsey wrote:
>>> Accept: An agent is said to "accept" a construct if some other entity
>>> generates it and passes it to the agent in question.
>>>     
>>
>> I think the intention of "accept" was that the agent in question would 
>> not
>> explode if it was passed that construct. The wording above seems to imply
>> that it was agent #1 that caused "accept"ance to happen, rather than 
>> agent
>> #2.
>>
>> "Accept: An agent is said to "accept" a construct from some other 
>> entity if
>> it receives and recognizes it."
>>
>> You might add something like "... processes or ignores it".
>>   
> I'll try ", and the agent processes it without treating it as a protocol 
> error".
> 
> Accept:
> 
> An agent is said to "accept" a construct if some other entity
> generates it and passes it to the agent in question, and the agent 
> processes it without treating it as a protocol error.

I changed the above to "... without treating it as a format or protocol 
error" in the draft, since this is the Usenet format draft.

Date: Wed, 23 Aug 2006 04:47:06 -0700
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Sender: [email-masked]

Frank Ellermann wrote:
>> But if a site is configured to not accept any such group
>> name, that's a legitimate configuration choice.
>>     
>
> Yes, about as interesting as not accepting names containing a
> Z (or later for Unicode various scripts).  We could be more
> specific why "_" is reserved:  s/future versions/future I18N/
>
>   
We don't have a documented consensus on what it's going to be used for. 
So better not say.

Date: Wed, 23 Aug 2006 04:45:23 -0700
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1299 Suggested resolution
Sender: [email-masked]

Charles Lindsey wrote:
>> Accept: An agent is said to "accept" a construct if some other entity
>> generates it and passes it to the agent in question.
>>     
>
> I think the intention of "accept" was that the agent in question would not
> explode if it was passed that construct. The wording above seems to imply
> that it was agent #1 that caused "accept"ance to happen, rather than agent
> #2.
>
> "Accept: An agent is said to "accept" a construct from some other entity if
> it receives and recognizes it."
>
> You might add something like "... processes or ignores it".
>   
I'll try ", and the agent processes it without treating it as a protocol 
error".

Accept:

An agent is said to "accept" a construct if some other entity
generates it and passes it to the agent in question, and the agent processes it without treating it as a protocol error.

But - my usual warning - we can go on polishing forever. Let's get -09 out the door.

To: [email-masked]
Xref: clerew local.usefor:23559
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1299 Suggested resolution
Date: Wed, 23 Aug 2006 11:11:30 GMT
Lines: 27
Sender: [email-masked]

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

>Text as modified, to avoid a circular "generate" definition:

>Accept: An agent is said to "accept" a construct if some other entity
>generates it and passes it to the agent in question.

I think the intention of "accept" was that the agent in question would not
explode if it was passed that construct. The wording above seems to imply
that it was agent #1 that caused "accept"ance to happen, rather than agent
#2.

"Accept: An agent is said to "accept" a construct from some other entity if
it receives and recognizes it."

You might add something like "... processes or ignores it".

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1156 Header field registrations
Date:  Tue, 22 Aug 2006 10:29:49 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Harald Alvestrand wrote:

> once I get a round tuit

dict.leo.org + MW + dict.org (incl. jargon file 2001): fail,
google + wikipedia: pass.  That could be a nice application
for the "IONs", transform various terminology RFCs into IONs:

Collect terms, approval => add to ION, and from time to time
publish it as updated RFC.  The "most popular" ABNF terms
could be also collected, to simplify references / recycling.

Or the xml2rfc "bibxml" collection - the part with anything
that's neither RFC nor I-D, e.g. the updated 3166 reference -
if somebody gets a round tuit this probably works like "send
XML snippet to Marshal".

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1312 Resolution - Lines
Date:  Tue, 22 Aug 2006 09:28:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Harald Alvestrand wrote:
 
>   The line count is the number of CRLF separators in the
> <body>, where <body> is defined in [RFC 2822].
 
> Add to "import interface" in section 1.4
 
>   body = <see RFC 2822 Section 3.5>
 
> OK?

Sure.  For "make a shorter draft" fans the "where <body>" ...
blurb is unnecessary after it's imported before its first use.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1314 Resolution - Newsgroups and reserved characters
Date:  Tue, 22 Aug 2006 09:23:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 28
Sender: [email-masked]

Harald Alvestrand wrote:

>>> However such names MUST be accepted by news servers, if
>>> permitted by site policy.
[...]
>> "MUST NOT be rejected for this reason alone".

Third proposal in another article:
| MAY be rejected.

> What I'd like the words to mean is that if you ship a product
> that can't be configured to accept newsgroup names starting
> with "_" or "+", the customer can point to the RFC and say
> "this product is deficent".

Makes sense, maybe say "such names MUST be supported by news
servers and user agents." (period, same idea as you've used it
elsewhere, don't talk about "site policy" if it's unnecessary).

> But if a site is configured to not accept any such group
> name, that's a legitimate configuration choice.

Yes, about as interesting as not accepting names containing a
Z (or later for Unicode various scripts).  We could be more
specific why "_" is reserved:  s/future versions/future I18N/

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1315 Definition of "poster"
Date:  Tue, 22 Aug 2006 08:42:10 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Harald Alvestrand wrote:
 
> A "poster" is the person or software that composes and
> submits a possibly compliant article to a "user agent".

Maybe add "operator of" before "software", IIRC we need
"poster" as "human with a mailbox" later.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1336 Expires field semantics
Date:  Tue, 22 Aug 2006 08:33:57 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Russ Allbery wrote:

>> Let's not get into the interactions with local policy here.
> Looks good to me.

+1.  Later (not in USEFOR) we should say something about the
relation between Expires and X-No.  Even if it's only "don't know".

Frank

Date: Mon, 21 Aug 2006 23:25:53 +0200
From: Harald Alvestrand <[email-masked]>
To: Seth Breidbart <[email-masked]>
Cc: [email-masked]
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Sender: [email-masked]

Seth Breidbart wrote:
>> However, such names MUST be accepted by news servers, if permitted
>> by site policy.
>>     
>
> I really dislike the "MUST ... if" construction; it seems to violate
> the meaning (at least spirit) of "MUST".  I'd prefer something like
> "MUST NOT be rejected for this reason alone".  That still permits
> rejection for any other reason, so it should retain the desired
> meaning.
>   
What I'd like the words to mean is that if you ship a product that can't 
be configured to accept newsgroup names starting with "_" or "+", the 
customer can point to the RFC and say "this product is deficent".

But if a site is configured to not accept any such group name, that's a 
legitimate configuration choice.

I'm sure there are servers configured to reject all groups with "binary" 
in their names, too.....

> There is a potential difference in meaning in the case of "site policy
> is to reject components beginning with _".  I think we want to say not
> to have such a policy, in which case my wording would be better.  (If
> we don't say not to have such a policy, the entire sentence is
> meaningless.)
>
> Seth
>
>
>   

Date: Mon, 21 Aug 2006 14:19:22 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Sender: [email-masked]

Harald Alvestrand wrote:
 > However, such names MUST be
> accepted by news servers, if permitted by site policy.

I aagree with Seth.

To me, that "MUST accept, if permitted by site policy" actually means "MAY 
reject for [rare] site-specific reasons."

Can it be written using "MAY reject" in both places?

Date: Mon, 21 Aug 2006 13:38:31 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1314 Resolution - Newsgroups and reserved characters
Sender: [email-masked]

> However, such names MUST be accepted by news servers, if permitted
> by site policy.

I really dislike the "MUST ... if" construction; it seems to violate
the meaning (at least spirit) of "MUST".  I'd prefer something like
"MUST NOT be rejected for this reason alone".  That still permits
rejection for any other reason, so it should retain the desired
meaning.

There is a potential difference in meaning in the case of "site policy
is to reject components beginning with _".  I think we want to say not
to have such a policy, in which case my wording would be better.  (If
we don't say not to have such a policy, the entire sentence is
meaningless.)

Seth

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1336 Expires field semantics
Organization: The Eyrie
Date: Mon, 21 Aug 2006 09:43:26 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> Suggested change:

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

>   NOTE: This is most useful when the poster desires an unusually long
>   or an unusually short expiry time.

> Let's not get into the interactions with local policy here.

Looks good to me.

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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1315 Definition of "poster"
Organization: The Eyrie
Date: Mon, 21 Aug 2006 09:43:04 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> Existing text in 1.5:

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

> Suggested resolution:

>   A "poster" is the person or software that composes and submits a
>   possibly compliant article to a "user agent".

> I think discussion (all 3 messages of it) showed this to be reasonable.

Seems fine to me.

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

Date: Mon, 21 Aug 2006 05:25:18 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Ticket status, USEFOR WG Last Call processing
Sender: [email-masked]

Here is what I have as status for the tickets:

1156 USEFOR Appendix: IANA registration forms for headers
   Resolved, with Frank's additional reference

1298 USEFOR WG LC issues raised by Charles Lindsey
  Will be resolved once 1305 is resolved

1299 USEFOR WG LC issues raised by Richard Clayton
  No comments to last suggested text. Resolved.

1300 USEFOR WG LC issues raised by Ralph Babel
   Will be resolved once 1309, 1310, 1311, 1312, 1313, 1314, 1315, 1334,
1335, 1336 are resolved

1305 USEFOR 3.1.6 Path - NOTE to explain diag-deprecated
   Suggested text accepted.

1309 USEFOR 3.2.7 Distribution header fields need more description
  Change reference to 3166; change text for "special" distribution names.

1310 USEFOR 3.2.9 Approved header field description
  Charles Lindsey disagrees with proposed text. Russ Allberry agrees.
  Resolved: The proposed text is going in.

1311 USEFOR 3.2.12 Default value for the Archive header field
  Resolved to not talk about the meaning of the header's absence.

1312 USEFOR 3.3.1 - Description of Lines header field can be much shorter
  Resolved, with improvements.

1313 USEFOR 2.2 Syntax for Usenet articles: RFC 2822 + MIME
  Suggested resolution is accepted (minus quibbles from Charles).

1314 USEFOR 3.1.5 Definition of Newsgroups header field is not precise
  Suggested SHOULD NOT for all cases of use of the "reserved" characters
  Suggested that MUST accept be softened by inclusion of "subject to
  site policy".
  New text suggested.

1315 USEFOR definiont of "poster"
  "No big deal" - suggested shortening definition.

1335 USEFOR description of Iniection-Date purpose is not precise
  Charles' version suggested.

1336 USEFOR 3.2.4 Additonal description of Expires header field
  Suggested resolution with an added note + reformulation.

I think everything has a proposed text now. We can proceed to cut -09, 
if nobody has serious objection to any of these resolutions before Ken 
gets that far.

                     Harald

Date: Mon, 21 Aug 2006 05:23:58 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1336 Expires field semantics
Sender: [email-masked]

Suggested change:

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

   NOTE: This is most useful when the poster desires an unusually long
   or an unusually short expiry time.

Let's not get into the interactions with local policy here.

Date: Mon, 21 Aug 2006 05:07:14 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1335 Injection-date
Sender: [email-masked]

Suggested rephrase of last sentence of "injection-date" is now:

    Its purpose is to enable news servers, when checking for "stale"
    articles, to use a <date-time> that was
    added by a news server at injection time rather than one added by the
    user agent at message composition time.

Date: Mon, 21 Aug 2006 05:04:29 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1315 Definition of "poster"
Sender: [email-masked]

Existing text in 1.5:

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

Suggested resolution:

   A "poster" is the person or software that composes and submits a
   possibly compliant article to a "user agent".

I think discussion (all 3 messages of it) showed this to be reasonable.

Date: Mon, 21 Aug 2006 05:00:37 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1314 Resolution - Newsgroups and reserved characters 
Sender: [email-masked]

Wordsmithed resolution (going almost all the SHOULD way):

Proposed new text:

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

NOTE: All-digit components conflict with one widely used storage
scheme for articles. Mixed case groups cause confusion between
systems with case sensitive matching and systems with case
insensitive matching of <newsgroup-name>s.

<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 [I-D.ietf-usefor-usepro]). However, such names MUST be
accepted by news servers, if permitted by site policy.

<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, if permitted by site policy.

Date: Mon, 21 Aug 2006 04:53:47 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1312 Resolution - Lines
Sender: [email-masked]

Resolution:

Replace the text starting with "The line count..." with the following:

  The line count is the number of CRLF separators in the <body>, where 
<body>
  is defined in [RFC 2822].

Add to "import interface" in section 1.4

  body = <see RFC 2822 Section 3.5>

OK?

Date: Mon, 21 Aug 2006 04:46:17 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1311 Resolution: Default value for the Archive header
Sender: [email-masked]

Current section text:

3.2.12.  Archive

   The Archive header field provides an indication of the poster's
   intent regarding preservation of the article in publicly accessible
   long-term or permanent storage.

   archive         =  "Archive:" SP [CFWS] ("no" / "yes")
                      *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF

   archive-param   =  parameter

   The presence of an Archive header field in an article with a field
   body of "no" indicates that the poster does not permit redistribution
   from publicly accessible long-term or permanent archives.  The
   absence of this header field, or the presence of this header field
   with a field body of "yes", indicates that the poster is willing for
   such redistribution to take place.  Further extensions to this
   standard may provide parameters for administration of the archiving
   process.

Suggested resolution: Replace last paragraph with:

   The presence of an Archive header field in an article with a field
   body of "no" indicates that the poster does not permit
   redistribution
   from publicly accessible long-term or permanent archives.
   A field body of "yes" indicates that the poster permits such
   redistribution.

   No parameters have been defined so far; if present, they can be
   ignored.

I think discussion showed that this is not the document to talk about 
interpretation of the absence of the header.

                     Harald

Date: Mon, 21 Aug 2006 04:41:42 -0700
From: Harald Alvestrand <[email-masked]>
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Subject: Re: #1309 resolution - Distribution header
Sender: [email-masked]

Harald Alvestrand wrote:
>
> Suggested resolution:
>
> - Change 3166 reference to the one LTRU uses:
>
> <reference anchor="ISO3166-1">
>   <front>
>   <title>ISO 3166-1:1997. Codes for the representation of names of 
> countries and their subdivisions -- Part 1: Country codes</title>
>   <author>
> <organization abbrev="ISO">International Organization for 
> Standardization</organization></author>
> <date year="1997"/>
> </front>
>
> - No other change; handling details deferred to USEPRO.
>
>
I let the buffer escape too early. Here's the complete one:

Suggested resolution:

- Change 3166 reference to the one LTRU uses:

<reference anchor="ISO3166-1">
   <front>
   <title>ISO 3166-1:1997. Codes for the representation of names of 
countries and their subdivisions -- Part 1: Country codes</title>
   <author>
<organization abbrev="ISO">International Organization for 
Standardization</organization></author>
<date year="1997"/>
</front>

- Change the "predefined" text to:

    The <dist-name>s "world" and "local" are reserved.  "world" indicates
    unlimited distribution and SHOULD NOT be used explicitly, since it is
    the default when the Distribution header field is absent entirely.
    "local" is reserved for indicating distribution only to the local
    site, as defined by local software configuration.

- No other change; handling details deferred to USEPRO.

Date: Mon, 21 Aug 2006 04:39:40 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1309 resolution - Distribution header
Sender: [email-masked]

Suggested resolution:

- Change 3166 reference to the one LTRU uses:

<reference anchor="ISO3166-1">
   <front>
   <title>ISO 3166-1:1997. Codes for the representation of names of 
countries and their subdivisions -- Part 1: Country codes</title>
   <author>
<organization abbrev="ISO">International Organization for 
Standardization</organization></author>
<date year="1997"/>
</front>

- No other change; handling details deferred to USEPRO.

Date: Mon, 21 Aug 2006 04:35:06 -0700
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1156 Header field registrations
Sender: [email-masked]

Frank Ellermann wrote:
> Harald Alvestrand wrote:
>  
>   
>> "obsoleted" for all fields that we have deprecated
>>     
> [...]
>   
>> Add RFC 850 to informative references.
>>     
> [...]
>   
>> OK?
>>     
>
> + RFC 2980 for NNTP-Posting-Host.  Keep "deprecated" for 
> Lines: as is because it's only deprecated, not obsoleted.
>   
OK.
> Maybe update your netnews page, the NNTP part is ready ;-)
>
>   
once I get a round tuit :-)

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1156 Header field registrations
Date:  Fri, 18 Aug 2006 07:13:04 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 13
Sender: [email-masked]

Harald Alvestrand wrote:
 
> "obsoleted" for all fields that we have deprecated
[...]
> Add RFC 850 to informative references.
[...]
> OK?

+ RFC 2980 for NNTP-Posting-Host.  Keep "deprecated" for 
Lines: as is because it's only deprecated, not obsoleted.

Maybe update your netnews page, the NNTP part is ready ;-)

Date: Thu, 17 Aug 2006 15:18:19 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1299 Suggested resolution
Sender: [email-masked]

Text as modified, to avoid a circular "generate" definition:

Add to 1.5:

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

Accept: An agent is said to "accept" a construct if some other entity
generates it and passes it to the agent in question.

Date: Thu, 17 Aug 2006 15:15:48 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1156 Header field registrations
Sender: [email-masked]

I think the last bits that need to be nailed are:

- Use "obsoleted" for all fields that we have deprecated or declared 
obsolete elsewhere in the document - simply because we don't want to 
invent new words.

- Add RFC 850 to informative references.

- Author/change controller is "IETF" for all the fields; no matter where 
they came from originally, the IETF is now the one that makes statements 
about them (even when that statement is "obsoleted".

OK?

(I have 20 min before a meeting, and am trying to use it to nail a few 
USEFOR tickets)

To: [email-masked]
Xref: clerew local.usefor:23533
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: USEPRO 8.3
Date: Thu, 10 Aug 2006 12:57:30 GMT
Lines: 25
Sender: [email-masked]

>> Never mind about the exact wording, we can discuss that when
>> we come to USEAGE.

>Okay, otherwise I'd say that it should also offer something
>for sites like GMaNe (= not Usenet), and especially more than:

Sure. When we come to discuss USEAGE in detail it will be in order to
propose further related items such as that. But if we are all happy that
advice and warnings rgearding how to use the Archive header are OK in
USEAGE, then we can omit them from USEFOR, and move on.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: USEPRO 8.3
Date:  Wed, 09 Aug 2006 23:08:17 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 34
Sender: [email-masked]

Charles Lindsey wrote:

> Never mind about the exact wording, we can discuss that when
> we come to USEAGE.

Okay, otherwise I'd say that it should also offer something
for sites like GMaNe (= not Usenet), and especially more than:

> Some posters take great exception to having their words on
> public display for ever

...or to be sold as some kind of "support"

> The effect of omitting this header entirely is not defined,
> but posters should be aware that the current practice is for
> such sites to assume that such absence implies consent, and
> to go ahead and archive it anyway.

...that's IMO still beside the point, they do offer ways to get
rid of articles, probably because they know that there is _no_
automatical + irrevocable consent (without Archive: yes).

> NOTE: The header "X-No-Archive: yes" (somewhat confusingly
> named) has hitherto been used for this purpose and archiving
> sites will doubtless continue to take note of it, but in
> writing [USEFOR] the opportunity was taken to standardize it
> without that negative in it.

Yes, that's good.  This note would be also okay in USEFOR, but
better keep it together with USEPRO 8.3 and all other "Archive
considerations" moved to USEAGE.

Frank

Date: Wed, 9 Aug 2006 13:58:04 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>There is not much point in your taking part in a discussion if you are
>going to ignore all the proposed changes that have been made and merely
>continue to rant about the unmodified text which people have already
>agreed needs to be changed.

First you deny there is a MUST in the section being discussed (when there 
are two of them), then you ignore that the MUST being discussed is the 
first of two, then you dismiss what you disagree with as a "rant" and tell 
me I have no business being part of the discussion.

I'm not the one not keeping up with the discussion, Charles.

>I would imagine that a poster who was a party to such a "private
>agreement" would have configured his user agent to indicate that was a
>valid group.

I seriously doubt that, since I know of NO configuration options in any of 
the newsreaders I have ever used that would tell it to accept a newsgroup
name that it otherwise would believe is invalid. This option is not going
to spring up overnight, especially in existing code.

No, the most likely scenario is the one I presented, where the agent
acts the same way no matter what we have said about it generating a 
component with + or -.

Justify the MUST or get rid of it.

Date: Wed, 9 Aug 2006 13:49:05 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1310 Approved
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Yes, I agree. The Internet is plagued with scams and spams of every sort.
>Do these not count as "harm"

Not in the context of a technical standard.

>and should not standards set things up so as
>to make life as hard as possible for the s[cp]ammers?

If only.

>What is in the Current draft regarding Approved will not of itself cure
>all the ills of the Internet, but it is a step in that direction.

What complete and utter nonsense. What is in the current draft regarding
Approved will do nothing at all to prevent internet scamming or spamming.
It is an unenforcable mandate that is undetectable outside the poster's
server and usually undetectable there, too.

And aren't YOU the fellow who just told me there is no point in my taking 
part in a discussion if I ignore the proposed changes, just as you have 
done here? Yes:

>There is not much point in your taking part in a discussion if you are
>going to ignore all the proposed changes that have been made and merely
>continue to rant about the unmodified text which people have already
>agreed needs to be changed.

Pot. Kettle.

Date: Wed, 09 Aug 2006 13:28:13 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1310 Approved
Sender: [email-masked]

Charles Lindsey wrote:

>>Software trying to match Approved: header fields with moderated
>>newsgroups can't work with forged addresses (= addresses used
>>_without_ the permission of the mailbox owner).  That should
>>suffice for legal action + termination of the posting account
>>or similar consequences, maybe enough to justify a MUST in this
>>direction:  never forge addresses in an Approved header field.
> 
> 
> Yes, I agree. The Internet is plagued with scams and spams of every sort.
> Do these not count as "harm" and should not standards set things up so as
> to make life as hard as possible for the s[cp]ammers?
> 
> What is in the Current draft regarding Approved will not of itself cure
> all the ills of the Internet, but it is a step in that direction.
> 

I wish you were joking, Charles.

We've been through debunking your attitude about this dozens of times.  An IETF 
standard is not a contract. It is not a LART.  It is merely an invitation to 
implementors to do things a certain way.

Do you really think that someone knowingly flaunting civil laws regarding
fraud is going to care about the piddling result(s) of this WG?

I see much text in the current draft that will tie the hands of the good guys 
who care in the face of the behavior of the bad guys who care not at all.  If
that is true, we will make the situation worse.

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.

To: [email-masked]
Xref: clerew local.usefor:23527
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1310 Approved
Date: Wed, 9 Aug 2006 12:59:01 GMT
Lines: 41
Sender: [email-masked]

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

>Harald Alvestrand wrote:
> 
>> 6. Guidance in the use of these Imperatives
>>    Imperatives of the type defined in this memo must be used with care
>>    and sparingly.  In particular, they MUST only be used where it is
>>    actually required for interoperation or to limit behavior which has
>>    potential for causing harm (e.g., limiting retransmisssions).

>That's also a nice example for a MUST.

No, it's a "MUST only", and we just got rid of one of those :-) .

>> I think you have to identify the actual harm in order to base yourself
>> on that....

>Software trying to match Approved: header fields with moderated
>newsgroups can't work with forged addresses (= addresses used
>_without_ the permission of the mailbox owner).  That should
>suffice for legal action + termination of the posting account
>or similar consequences, maybe enough to justify a MUST in this
>direction:  never forge addresses in an Approved header field.

Yes, I agree. The Internet is plagued with scams and spams of every sort.
Do these not count as "harm" and should not standards set things up so as
to make life as hard as possible for the s[cp]ammers?

What is in the Current draft regarding Approved will not of itself cure
all the ills of the Internet, but it is a step in that direction.

To: [email-masked]
Xref: clerew local.usefor:23526
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: USEPRO 8.3 (was: #1311 Archive)
Date: Wed, 9 Aug 2006 12:53:15 GMT
Lines: 63
Sender: [email-masked]

>> Maybe USEAGE is the place to say these things. WOuld people
>> find that better?

>Yes.  Not a complete "roll your own cancel-bot" guide, but some
>essential technical points from Rosalind's + Skirvin's FAQs.

OK, I have written the following into my draft of USEAGE. Never mind about
the exact wording, we can discuss that when we come to USEAGE. But if
people are happy that something along those lines should appear, then I
don't mind if mention of the Archive default is omitted from USEFOR.

0.0.1.  Archive

   There are various sites which attempt to keep a permanent (or at
   least exceedingly long term) archive of every article posted to
   Usenet (or to some part of it) and to make them available for public
   searching and download.  Clearly, this has Copyright implications
   which go beyond the normal presumptions set out in P-8.3.  Some
   posters take great exception to having their words on public display
   for ever (whereas other posters find it a useful resource of
   information).
[It has also been suggested that P-8.3 should be moved into this
document.]

   Posters who wish to exercise their right to withold permission for
   such sites to redistribute their words may include the header
   "Archive: no", and likewise "Archive: yes" explicitly to allow it
   (F-3.2.12).  The effect of omitting this header entirely is not
   defined, but posters should be aware that the current practice is for
   such sites to assume that such absence implies consent, and to go
   ahead and archive it anyway.

        NOTE: The header "X-No-Archive: yes" (somewhat confusingly
        named) has hitherto been used for this purpose and archiving
        sites will doubtless continue to take note of it, but in writing
        [USEFOR] the opportunity was taken to standardize it without
        that negative in it.

>Unless you have that already in USEPRO.  The complete section
>8.3 in USEPRO could be moved to USEAGE, and / or trimmed to a
>"TPOV" (= technical POV, I just made this up).

I think it is clear that USEPRO is the wrong place for P-8.3, since it has
nothing to do with the protocols. Either USEFOR of USEAGE would be more
sensible, and somehow I think it unlikely that it will get into USEFOR at
this stage.

To: [email-masked]
Xref: clerew local.usefor:23528
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1313 Newsgroups and reserved characters
Date: Wed, 9 Aug 2006 13:06:12 GMT
Lines: 45
Sender: [email-masked]

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

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>There are current proposals, elsewhere in this thread, to replace that 2nd
>>MUST by something like

>>   "SHOULD NOT be rejected by news servers on that account [alone]".

>I don't care what proposals say, I am talking about the current text,
>and specifically the part:

There is not much point in your taking part in a discussion if you are
going to ignore all the proposed changes that have been made and merely
continue to rant about the unmodified text which people have already
agreed needs to be changed.

>>>   <component>s beginning with "+" and "-" are reserved for private use
>>>   and MUST 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.

>A user agent author is either going to ignore this command completely, or
>will assume that the poster knows of an existing "private prior agreement"
>when he commands the agent to create a followup, and thus will create a
>newsgroups header field by copying the contents of a followup-to that has
>a component beginning with '+' or '-'.

I would imagine that a poster who was a party to such a "private
agreement" would have configured his user agent to indicate that was a
valid group.

But, FWIW, I would have no strong objection if someone wants to demote
that first MUST NOT to SHOULD NOT.

Date: Tue, 8 Aug 2006 13:10:15 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1310 Approved
Sender: [email-masked]

Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:

>Software trying to match Approved: header fields with moderated
>newsgroups can't work with forged addresses (= addresses used
>_without_ the permission of the mailbox owner).

What software tries to match approved header fields with addresses
contained therein? Remember that current standards do not mandate an
address in that header field, so they would already fail with valid
headers.

>That should suffice for legal action ...

You have got to be kidding. You think a MUST appearing in our standard
will be a valid basis for legal action? You think someone ought to be
sued or go to jail because they did not put their own address in the
Approved header of an article they posted?

The fact remains that agents have even less idea of what is "legal" in
that header than they do in the From header, and trying to mandate 
something that they simply do not care about and does not break anything
is a violation of RFC2119.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1310 Approved
Date:  Tue, 08 Aug 2006 15:50:11 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Harald Alvestrand wrote:
 
> 6. Guidance in the use of these Imperatives
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions).

That's also a nice example for a MUST.

> I think you have to identify the actual harm in order to base yourself
> on that....

Software trying to match Approved: header fields with moderated
newsgroups can't work with forged addresses (= addresses used
_without_ the permission of the mailbox owner).  That should
suffice for legal action + termination of the posting account
or similar consequences, maybe enough to justify a MUST in this
direction:  never forge addresses in an Approved header field.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  USEPRO 8.3 (was: #1311 Archive)
Date:  Tue, 08 Aug 2006 15:27:52 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Charles Lindsey wrote:

> Maybe USEAGE is the place to say these things. WOuld people
> find that better?

Yes.  Not a complete "roll your own cancel-bot" guide, but some
essential technical points from Rosalind's + Skirvin's FAQs.

For the semantics of "Archive: no" we could say that it's often
interpreted as a deliberately unspecified "Expires: 'soon'".

Unless you have that already in USEPRO.  The complete section
8.3 in USEPRO could be moved to USEAGE, and / or trimmed to a
"TPOV" (= technical POV, I just made this up).

Frank

Date: Tue, 08 Aug 2006 05:37:15 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1310 Approved
Sender: [email-masked]

Charles Lindsey wrote:
>> What stops working if "one of those mailboxes" is not that of the person
>> or other entity? Justify thy MUST.
>>     
>
> Nothing stops working. But that is not a requirement for using "MUST". You
> are also allowed to use "MUST" for security issues, and that is the
> justification here.
>   
Are you referring to this (RFC 2119)?

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions).

I think you have to identify the actual harm in order to base yourself 
on that....

Date: Tue, 08 Aug 2006 05:33:10 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1311 Archive
Sender: [email-masked]

Charles Lindsey wrote:
>   
>> Adding warnings everywhere is dubious, "a supersedes might be
>> honoured by some but not all servers", "a cancel might be ..."
>> - we could write a complete document about the finer points of
>> the various kinds of "cancel" messages - and the same goes for
>> "expires" and "distribution".
>>     
>
> Maybe USEAGE is the place to say these things. WOuld people find that
> better?
>   
to me, this seems a good fit for what USEAGE aims to be.

Date: Mon, 7 Aug 2006 11:59:43 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

I wrote:

>>I see no "SHOULD NOT" in that paragraph. I see a clear MUST NOT.

>There are current proposals, elsewhere in this thread, to replace that 2nd
>MUST by something like

>   "SHOULD NOT be rejected by news servers on that account [alone]".

I don't care what proposals say, I am talking about the current text,
and specifically the part:

>>   <component>s beginning with "+" and "-" are reserved for private use
>>   and MUST 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.

A user agent author is either going to ignore this command completely, or
will assume that the poster knows of an existing "private prior agreement"
when he commands the agent to create a followup, and thus will create a
newsgroups header field by copying the contents of a followup-to that has
a component beginning with '+' or '-'.

Since nothing is done any differently because of this demand, and 
everything "works OK" even if it is ignored, this MUST NOT is another
example of misapplication of RFC2119 mandates.

Justify the MUST NOT or get rid of it.

Date: Mon, 7 Aug 2006 11:54:11 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1310 Approved
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

I wrote:

>>The fact that it cannot be neither enforced nor detected is sufficient.

>It can be enforced mechanically by including that header in some digital
>signature.

You can digitally sign all the crap you want, it will still be crap.

There is no way for any enforcement of the contents of that header, and no
way to detect crap even if the crap is signed.

>But in the meantime, it can be and regularly is detected by observant
>Newscops who then try to send LARTs to the perpetrator's ISP.

"Observant Newscops" have no idea of all the possible valid values I
could put in an Approved header. They would likewise have no clue if
the moderator of a group gave me permission to post something and I
put his address in the Approved header.

>Nothing stops working.

Then the MUST does not meet RFC2119 requirements and must be removed.

>But that is not a requirement for using "MUST". You
>are also allowed to use "MUST" for security issues, and that is the
>justification here.

This is not a "security" issue, and even were it one, since you cannot
detect an invalid contextual (vs. syntactically incorrect) value, and
nothing should be doing anything with the value in the first place, the
MUST is still incorrect.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Some late -08 nits
Organization: The Eyrie
Date: Mon, 07 Aug 2006 08:42:58 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Frank Ellermann <[email-masked]> writes:

>> In draft 08 we have this:

>> |     Header field name: NNTP-Posting-Host
>> |     Applicable protocol: netnews
>> |     Status: obsoleted
>> |     Author/change controller: IETF
>> |     Specification document(s): none

>> Please replace "none" by "[RFC 2980] (3.4.1)" and add 2980 to
>> the informative references.  We could mention RFC 2980 (3.4.2)
>> also in the first note of 3.2.13 (User-Agent), but it doesn't
>> offer any further insights.

> Well spotted. RFC 2980 is sufficiently obscure that few people are aware
> of that. Though oddly he did not cover NNTP-Posting-Date.

RFC 2980 isn't particularly obscure in the NNTP community.  I'd just
completely forgotten that it defined any headers, since it's really an
NNTP document.

NNTP-Posting-Host predates NNTP-Posting-Date by possibly a decade.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 1156
Date:  Mon, 07 Aug 2006 14:16:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Harald Alvestrand wrote:

> I checked the registration RFC, and it's not a completely
> restricted field - we can make up words if we have to.
> That said, I don't want to do that if we don't REALLY have 
> to.

Yes, the "deprecated" in 08 should do.  When I saw "1156" I
thought that it's about "obsoleted", but that's not possible,
the status value for the Lines is already "deprecated" in 08.

Now I'm lost what else in #1156 was still unclear, maybe the
three "obsoleted" RFC 850 header fields, or should that be
"historic"... no, the RFC editor has 850 as status "unknown"
and "obsoleted by 1036".

Frank

From: "Ruud H.G. van Tol" <[email-masked]>
To: <[email-masked]>
Subject: Re: #1311 Archive
Date: Mon, 7 Aug 2006 13:40:42 +0200
Organization: Chaos rules.
Sender: [email-masked]

Harald Alvestrand schreef:
> Charles Lindsey:

>> Yes, but nobody is ever going to write Archive: yes 
>> (have you ever seen X-No-Archive: no?).

Plenty.

> http://www.thescripts.com/forum/thread172325.html
> 
> give them the tools, and they will proceed to use it.

My favourite is Archive: please. 

-- 
Groet, Ruud

To: [email-masked]
Xref: clerew local.usefor:23510
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1313 Newsgroups and reserved characters
Date: Mon, 7 Aug 2006 10:09:01 GMT
Lines: 28
Sender: [email-masked]

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

>Nonsense. We say, quite clearly:

>>   <component>s beginning with "+" and "-" are reserved for private use
>>   and MUST 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.

>I see no "SHOULD NOT" in that paragraph. I see a clear MUST NOT.

There are current proposals, elsewhere in this thread, to replace that 2nd
MUST by something like

   "SHOULD NOT be rejected by news servers on that account [alone]".

To: [email-masked]
Xref: clerew local.usefor:23508
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Some late -08 nits
Date: Mon, 7 Aug 2006 09:26:09 GMT
Lines: 29
Sender: [email-masked]

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

>In draft 08 we have this:

>|     Header field name: NNTP-Posting-Host
>|     Applicable protocol: netnews
>|     Status: obsoleted
>|     Author/change controller: IETF
>|     Specification document(s): none

>Please replace "none" by "[RFC 2980] (3.4.1)" and add 2980 to
>the informative references.  We could mention RFC 2980 (3.4.2)
>also in the first note of 3.2.13 (User-Agent), but it doesn't
>offer any further insights.

Well spotted. RFC 2980 is sufficiently obscure that few people are aware
of that. Though oddly he did not cover NNTP-Posting-Date.

To: [email-masked]
Xref: clerew local.usefor:23511
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1310 Approved
Date: Mon, 7 Aug 2006 10:17:07 GMT
Lines: 39
Sender: [email-masked]

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

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>Yes, I mentioned the *.answers as a special case, but that is no reason to
>>throw out the whole requirement.

>The fact that it cannot be neither enforced nor detected is sufficient.

It can be enforced mechanically by including that header in some digital
signature. Agreed this practice is not as widespread as it should be
(except for control messages) because the standards for doing it need some
tidying up (and this group looked at that years back and decided it was
future work).

But in the meantime, it can be and regularly is detected by observant
Newscops who then try to send LARTs to the perpetrator's ISP.

>>.. one of those mailboxes MUST be that of the person or other entity
>>claiming authority to issue this header, and moreover one of them SHOULD
>>be that of the actual sender.

>What stops working if "one of those mailboxes" is not that of the person
>or other entity? Justify thy MUST.

Nothing stops working. But that is not a requirement for using "MUST". You
are also allowed to use "MUST" for security issues, and that is the
justification here.

To: [email-masked]
Xref: clerew local.usefor:23509
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Mon, 7 Aug 2006 09:42:03 GMT
Lines: 80
Sender: [email-masked]

>> technical documents often give warnings about the
>> consequences of using/not using certain features.

>Here that's about "not using Archive: yes".  Apparently you
>would prefer a default "yes", and then this value whould be
>in essence redundant.  Folks supporting that solution could
>argue to get rid of the "yes" - same idea as for "all" and
>"world" wrt Distribution.

No, I accept there is no consensus for a formally defined default. All I
am pressing for is some mention of the likely (and de facto) consequnce of
silence.

>I don't support this, I'm more (mildly) interested in future
>parameters like GFDL or cc-by-sa, maybe cc-by-nc, for the
>Archive header field.

Sure, and we have left space for future parameters that may turn out to be
necessary/usefful.

>> nobody is ever going to write Archive: yes (have you ever
>> seen X-No-Archive: no?).

>This double "no" was never a good idea, in some languages it
>could be mistaken for a strong no.  The purpose of an explicit
>Archive: yes is to be available on demand.  It tells archivers
>that they can't assume that anything they do is automatically
>okay _without_ an explicit "Archive: yes".

I doubt archivers are going to take that view (unless some court forces
them to - possible but unlikely).

>IMO they've to offer some way to get rid of articles.  As it
>happens I tried to track this down wrt IETF lists carried by
>GMaNe yesterday, arriving at http://gmane.org/expiry.php and
>http://www.ietf.org/maillist.html

I agree, and most of them do (but only provide well-hidden hurdles for
those who seek to do so). I would have no problem saying that (in the
Security and Related section, for example). But I am not pressing for
that.

>When "deja" started to archive articles I was annoyed (behind
>a maze of gateways) and used X-No for some time.  More than a
>decade ago.  The mere existence of the "Archive" header field
>is a warning.  After all folks are supposed to know that it
>has consequences if they post in a public group / list / forum.

Yes, I think that was a likely reaction from most people. The present
situation is that most people find it Google a useful resources to
retrieve _other_ people's articles, but are mildly irritated to find their
own articles archived there :-( .

Which is why they will grudgingly omit any Archive header (in full
knowledge that Google will then archve it), but are unlikely to explicitly
permit it using Archive: yes.

>Adding warnings everywhere is dubious, "a supersedes might be
>honoured by some but not all servers", "a cancel might be ..."
>- we could write a complete document about the finer points of
>the various kinds of "cancel" messages - and the same goes for
>"expires" and "distribution".

Maybe USEAGE is the place to say these things. WOuld people find that
better?

Date: Mon, 07 Aug 2006 03:47:44 -0700
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: 1156
Sender: [email-masked]

Frank Ellermann wrote:
> Harald Alvestrand wrote:
>
>   
>> Here is what I have as status for the tickets:
>>     
>
> Thanks...
>
>   
>> 1156 USEFOR Appendix: IANA registration forms for headers
>>     
>
> ...that's rather old, was that about "we can't say 'obsolete'
> for Lines" ?  Please replace it by 'obsolescent' or similar.
>   
I checked the registration RFC, and it's not a completely restricted 
field - we can make up words if we have to.
That said, I don't want to do that if we don't REALLY have to.
> For four header fields I found older documents, three in
> RFC 850 (not yet mentioned in the IANA chapter), one in
> RFC 2980 (NNTP-Posting-Host).  If used also needed in the
> informative references.
Good catch - should be uncontroversial.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  1156 (was: Ticket status, USEFOR WG Last Call processing)
Date:  Mon, 07 Aug 2006 10:05:06 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Harald Alvestrand wrote:

> Here is what I have as status for the tickets:

Thanks...

> 1156 USEFOR Appendix: IANA registration forms for headers

...that's rather old, was that about "we can't say 'obsolete'
for Lines" ?  Please replace it by 'obsolescent' or similar.

For four header fields I found older documents, three in
RFC 850 (not yet mentioned in the IANA chapter), one in
RFC 2980 (NNTP-Posting-Host).  If used also needed in the
informative references.

Frank

Date: Sun, 06 Aug 2006 22:10:06 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Ticket status, USEFOR WG Last Call processing
Sender: [email-masked]

Here is what I have as status for the tickets:

1156 USEFOR Appendix: IANA registration forms for headers

1298 USEFOR WG LC issues raised by Charles Lindsey
  Will be resolved once 1305 is resolved

1299 USEFOR WG LC issues raised by Richard Clayton
  Suggested text is acceptable with a minor text change (don't define 
"generate" in terms of "generate"

1300 USEFOR WG LC issues raised by Ralph Babel
   Will be resolved once 1309, 1310, 1311, 1312, 1313, 1314, 1315, 1334, 
1335, 1336 are resolved

1305 USEFOR 3.1.6 Path - NOTE to explain diag-deprecated
   Suggested text accepted.

1309 USEFOR 3.2.7 Distribution header fields need more description
  In discussion, the proper reference for ISO 3066 surfaced.
  It was suggested to change the resolution text slightly to avoid the 
term "predefined".
  Under the same ticket number, there was also discussion about 
"supersedes".

1310 USEFOR 3.2.9 Approved header field description
  Charles Lindsey disagrees with proposed text. Russ Allberry agrees.
  Resolved: The proposed text is going in.

1311 USEFOR 3.2.12 Default value for the Archive header field
  Suggested to remove the words "wish to" from the suggested resolution 
text.
  It's been pointed out that "permanent" is included in "long-term", so 
isn't needed.
  Charles has produced alternate text; I have seen no consensus that 
this is better than what
  I suggested (quite the opposite).
  I'll suggest a slightly revised text (based on mine, not charles').

1312 USEFOR 3.3.1 - Description of Lines header field can be much shorter
  Suggested text accepted. Some suggestions have been made for improving it.

1313 USEFOR 2.2 Syntax for Usenet articles: RFC 2822 + MIME
  Suggested resolution is accepted (minus quibbles from Charles).

1314 USEFOR 3.1.5 Definition of Newsgroups header field is not precise
  Suggested SHOULD NOT for all cases of use of the "reserved" characters
  Suggested that MUST accept be softened by inclusion of "subject to 
site policy"

1315 USEFOR definiont of "poster"
  "No big deal" - and no clear consensus.

1334 USEFOR path preloading and path components case sensitivity
  "No change" seems to be "no big deal". Resolved "no change".

1335 USEFOR description of Iniection-Date purpose is not precise
  Sliglhtly modified description seems adequate (what charles suggested).

1336 USEFOR 3.2.4 Additonal description of Expires header field
  Argumensts in multiple directions here.

I'll send out new resolution proposals for the stuff not completely 
resolved shortly.

Date: Sun, 06 Aug 2006 21:54:50 -0700
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1311 Archive
Sender: [email-masked]

Charles Lindsey wrote:
> Yes, but nobody is ever going to write Archive: yes (have you ever seen
> X-No-Archive: no?).

http://www.thescripts.com/forum/thread172325.html

give them the tools, and they will proceed to use it.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Archive
Date:  Sat, 05 Aug 2006 16:02:39 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 69
Sender: [email-masked]

Charles Lindsey wrote:

> technical documents often give warnings about the
> consequences of using/not using certain features.

Here that's about "not using Archive: yes".  Apparently you
would prefer a default "yes", and then this value whould be
in essence redundant.  Folks supporting that solution could
argue to get rid of the "yes" - same idea as for "all" and
"world" wrt Distribution.

I don't support this, I'm more (mildly) interested in future
parameters like GFDL or cc-by-sa, maybe cc-by-nc, for the
Archive header field.

> nobody is ever going to write Archive: yes (have you ever
> seen X-No-Archive: no?).

This double "no" was never a good idea, in some languages it
could be mistaken for a strong no.  The purpose of an explicit
Archive: yes is to be available on demand.  It tells archivers
that they can't assume that anything they do is automatically
okay _without_ an explicit "Archive: yes".

IMO they've to offer some way to get rid of articles.  As it
happens I tried to track this down wrt IETF lists carried by
GMaNe yesterday, arriving at http://gmane.org/expiry.php and
http://www.ietf.org/maillist.html

Apparently it's possible to purge articles from GMaNe, but not
necessarily from IETF archives - unless you'd find someone
willing to manually edit obscure application/mbox files on a
public IETF FTP server.  Maybe it also depends on the IETF list
in question, there are different "hosters" (list owners), and
it can be hard to solve technical problem with the IETF, unless
you know who does what (Bill, Dave, Harald, Henrik, Marshal,
Ned, Paul, Randy, and many others).

> we need to warn them of this likely consequence

When "deja" started to archive articles I was annoyed (behind
a maze of gateways) and used X-No for some time.  More than a
decade ago.  The mere existence of the "Archive" header field
is a warning.  After all folks are supposed to know that it
has consequences if they post in a public group / list / forum.

Adding warnings everywhere is dubious, "a supersedes might be
honoured by some but not all servers", "a cancel might be ..."
- we could write a complete document about the finer points of
the various kinds of "cancel" messages - and the same goes for
"expires" and "distribution".

As soon as you start to talk about legal issues you lose, I'd
avoid it where possible.  A recommendation that public archives
SHOULD offer to delete articles (for original or faked posters)
could make sense.  But probably not in USEFOR.

> But X-No-Archive currently comes with a generally accepted
> convention of what happens if you leave it out.

Yes, let's agree to disagree about this.  If I'd find my (e.g.
this) article "sold" by a commercial archive I'd ask them to
stop this.  And if I make exceptions for Google considering it
as "non-commercial" (and because I know how to purge articles
there if I'd want it) that's my business, not some "generally
accepted convention" I'd wish to document in a standard.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Some late -08 nits
Date:  Sat, 05 Aug 2006 14:41:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

In addition to the "IANA considerations" nits:

> Three RFC 850 header fields are mentioned in section 3.3, but
> not covered by section 6 (= IANA considerations).  Let's just
> formally kill them and be done with it:
 
>       Header field name: Relay-Version
>       Applicable protocol: netnews
>       Status: obsoleted
>       Author/change controller: IETF
>       Specification document(s): [RFC 850] (2.1.1)
 
>       Header field name: Posting-Version
[...see above...]
>       Header field name: Date-Received
[...see above...]

In draft 08 we have this:

|     Header field name: NNTP-Posting-Host
|     Applicable protocol: netnews
|     Status: obsoleted
|     Author/change controller: IETF
|     Specification document(s): none

Please replace "none" by "[RFC 2980] (3.4.1)" and add 2980 to
the informative references.  We could mention RFC 2980 (3.4.2)
also in the first note of 3.2.13 (User-Agent), but it doesn't
offer any further insights.

Frank

Date: Fri, 4 Aug 2006 13:10:09 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1310 Approved
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Yes, I mentioned the *.answers as a special case, but that is no reason to
>throw out the whole requirement.

The fact that it cannot be neither enforced nor detected is sufficient.

>.. one of those mailboxes MUST be that of the person or other entity
>claiming authority to issue this header, and moreover one of them SHOULD
>be that of the actual sender.

What stops working if "one of those mailboxes" is not that of the person
or other entity? Justify thy MUST.

>But at least require a genuine address, because ISPs will often be
>convinced by a LART relating to forged or bogus headers, even when they
>are otherwise netnews-ignorant, which sadly many are.

We've had a similar discussion involving the From header: how does the
injection agent enforce this requirement when it has no idea whether the
address belongs to the poster or not? In this case, we aren't even allowed
to limit ourselves to information we know (if anything) about the poster,
since the "person responsible for the approval" might not be the one
doing the posting.

And then just how do we tell all the injecting agents around the world
when we have a moderated newsgroup that has no "moderator" and thus
can accept ANY mailbox in an Approved header? If we say "MUST", then
we MUST have some means of telling agents when that MUST applies and
when it does not.

Date: Fri, 4 Aug 2006 12:25:49 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>How does the user agent know if a "private prior agreement" exists?

>Because the server that created it (i.e. the NNTP server he connects to)
>should have told him.

More silliness. First, the server doesn't create private agreements, and 
second, the "user agent" isn't a "him" and I know of no standard mechanism
for one agent to tell another about any "private agreements" even if the
user agent was a "him".

>But is is mainly serving agents that will set up these private
>arrangements, not user agents.

Right. Sure. I don't want my serving agents running off creating "private
arangements" with other serving agents any more than I want my user
agents creating private arangements.

>>I've now seen the message where you explain why this paragraph is deemed
>>necessary. I'd challenge any software author to correctly deal with the
>>situation of a leaked experimental article that contains "Followup-To:
>>+test.me.please". His code is either going to generate a Newsgroups header
>>we tell him he MUST NOT, or he will be fastidious and refuse to do so,
>>even though the user just called Bob the Server Admin and got permission
>>to join the experiment.

>No, we told him he SHOULD NOT.

Nonsense. We say, quite clearly:

>   <component>s beginning with "+" and "-" are reserved for private use
>   and MUST 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.

I see no "SHOULD NOT" in that paragraph. I see a clear MUST NOT.

So, we are still stuck with a user agent that will, most likely, create
a Newsgroups header that we tell it it MUST NOT, because most authors
will simply ignore this section and do "the right thing" by copying
the Followup-To to the Newsgroups header field.

>If he inadvertently does, then it will be
>propagated if there are are further proper crossposts, otherwise it will
>only be accepted at sites where that group exists (i.e. those that are
>party to the "private arrangement"). That all seems OK to me.

A clearer argument for removing a specious MUST NOT is seldom heard. If
it is "all OK" when something we say MUST NOT happen happens, then we
are clearly using MUST NOT incorrectly.

Seth Breidbart <sethb@xxxxxxxxx>:

>The user agent asks the user: "You just generated an article to be
>posted in the newsgroup '+test.me.please'.  That name violates the
>RFCs unless there is a private agreement in place allowing it.  Do you
>want to Continue or Edit?: "

I seriously doubt any author is going to pay that much attention to this 
part of the standard and actually ask, and even if it did, my answer is "I 
pushed 'f', which is a clear and explicit instruction to you to create a 
followup. Don't ask me twice." And were I writing code to this standard, 
that is exactly how I would interpret the user's command.

In other words, I would do absolutely nothing different about a followup
going to +test.me.please than I would to any other group. That makes the
MUST NOT meaningless.

>Being a user agent, it's allowed to communicate with the user.

And similarly the user communicates with the user agent.

To: [email-masked]
Xref: clerew local.usefor:23503
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Fri, 4 Aug 2006 12:02:36 GMT
Lines: 53
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>> the wording would need to be revised to address Russ's point
>> that it could become invalidated if Google lost some court
>> case (unlikely, but you never know).

>Really, the "net news article format" is a technical document,
>it shouldn't depend on or consider hypothetical court cases
>wrt one particular archive, even if it's admittedly the most
>famous Usenet archive.

That is all true, but technical documents often give warnings about the
consequences of using/not using certain features. In IETF documents, this
is usually done in a "Security Considerations" section - but this is not
quite a security issue, though it is certainly a "this is a way for
unexpected things to happen" issue. That is why, when we wrote the
Archive header (that was many years back) we wrote a "Security and Related
considerations" section to go with it, with a sub-section on "Liability"
within that. When the split came, that section landed up in USEPRO. It is
certainly a reasonable place to warn of possible effects of omitting an
Archive header, though it might be better moved to USEFOR.

>> But if we are to remain totally silent on this issue, then I
>> think it would be better to drop the Archive header entirely
>> and leave it to the present confused situation

>We offer "yes" and "no", and both make sense if there is no
>wannabe-default.  That's not silent, it's IMO fine, or at least
>better than the unofficial x-no: yes kludge.

Yes, but nobody is ever going to write Archive: yes (have you ever seen
X-No-Archive: no?). They will just presume that if they write nothing,
then Google (and anywhere else) will just go ahead. So we need to warn
them of this likely consequence (but I accept that it need not be written
as rigidly as in the present draft).

>Besides Archive: no is less confusing than x-NoArchive: yes.

I agree with that. But X-No-Archive currently comes with a generally
accepted convention of what happens if you leave it out.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Archive
Organization: The Eyrie
Date: Thu, 03 Aug 2006 06:07:44 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Seth Breidbart <[email-masked]> writes:
>> "Charles Lindsey" <[email-masked]> wrote:

>>> OK, then would you be happy with a wording such as:
>>> 
>>>   "Posters should be aware that omission of this header field (or of the
>>>   X-No-Archive used for this purpose hitherto) is likely to be
>>>   interpreted as implying "Archive: yes".

>> That's fine with me, but is USEFOR the right place for it?

> Well I think at least s/likely/may well/ or s/is likely/is, under current
> practice, likely/, in order to meet Russ's objection.

That will not meet my objection.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Archive
Date:  Thu, 03 Aug 2006 13:28:14 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 38
Sender: [email-masked]

Charles Lindsey wrote:
 
> the wording would need to be revised to address Russ's point
> that it could become invalidated if Google lost some court
> case (unlikely, but you never know).

Really, the "net news article format" is a technical document,
it shouldn't depend on or consider hypothetical court cases
wrt one particular archive, even if it's admittedly the most
famous Usenet archive.

> But if we are to remain totally silent on this issue, then I
> think it would be better to drop the Archive header entirely
> and leave it to the present confused situation

We offer "yes" and "no", and both make sense if there is no
wannabe-default.  That's not silent, it's IMO fine, or at least
better than the unofficial x-no: yes kludge.

Besides Archive: no is less confusing than x-NoArchive: yes.

> which would be a pity because I think we all agree that
> X-headers are a Bad Thing except for private/vanity purposes.

I'm not sure about that argument, when x-No was invented back
in 1995 (or was that earlier ?) it was a plausible idea.  Minus
its weird "say yes to no" syntax.

Today we have a new nice header field registry, folks should
start use it, it's no rocket science, and Bruce has written a
kind of "header field how to" RFC.  Also rather new.

I'd seriously consider to kill "Archive" if it would allow us
to get rid of <parameter>, but that's not the case, we need it
also for Injection-Info.

Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:23495
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Thu, 3 Aug 2006 10:06:51 GMT
Lines: 33
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>> would you be happy with a wording such as:
> 
>> "Posters should be aware that omission of this header field (or of the
>>  X-No-Archive used for this purpose hitherto) is likely to be
>>  interpreted as implying "Archive: yes".

>No, that's not the case.  I'm aware that if I post a net news
>article then it will be transported to various news servers,
>and read by some folks.  They might even archive it for private
>purposes.  After some time the article will expire from almost
>all servers, and that's it.  It doesn't imply "Archive: yes".

No, the Archive header does not apply to either of those cases.

"Long term or permanent" excludes servers which expire articles on the
sort of timescale normally encountered.

"publicly available" excludes private purposes.

To: [email-masked]
Xref: clerew local.usefor:23496
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Thu, 3 Aug 2006 10:14:22 GMT
Lines: 27
Sender: [email-masked]

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

>I think we have a consensus-minus-Charles that not putting an Archive: 
>header on an article means that there is no Archive: header on the 
>article, and that there is no standardized meaning for its absence.

Not quite. I see that Seth is prepared to contemplate my revised
("likely") wording, though not necessarily with those words, and not
necessarily in that place. And the wording would need to be revised to
address Russ's point that it could become invalidated if Google lost some
court case (unlikely, but you never know).

But if we are to remain totally silent on this issue, then I think it
would be better to drop the Archive header entirely and leave it to the
present confused situation - which would be a pity because I think we all
agree that X-headers are a Bad Thing except for private/vanity purposes.

To: [email-masked]
Xref: clerew local.usefor:23498
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1313 Newsgroups and reserved characters
Date: Thu, 3 Aug 2006 10:34:30 GMT
Lines: 42
Sender: [email-masked]

In <[email-masked]> Seth Breidbart <[email-masked]> writes:

>> You could argue that "MUST accept" does not imply "MUST propagate", but
>> that is a bit thin.
>>
>> So I would suggest (in the two places, for "[+-]" and for "_") either
>>
>>   "MUST be accepted (subject to site policy)"
>> or
>>   "SHOULD be accepted".
>> I think I prefer the "SHOULD".

>I'd prefer something like "MUST NOT be rejected for this reason
>alone".  If they want to reject for some other reason, fine.

Isn't that, more or less, the meaning of "SHOULD"? And in any case, if
there is a MUST reject elsewhere, it will trump any SHOULD.

But I am not averse to such a wording, though I think I would prefer

   "SHOULD NOT be rejected by news servers on that account [alone]".

>(Which is the RFC that specifies a mailswerver MUST NOT reject a
>message because the HELO argument doesn't resolve to the sending IP?
>That's the sort of wording I'd want.)

The wording in RFC 2821 (which Frank drew our attentio to) is:

   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.

To: [email-masked]
Xref: clerew local.usefor:23497
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Thu, 3 Aug 2006 10:25:02 GMT
Lines: 29
Sender: [email-masked]

In <[email-masked]> Seth Breidbart <[email-masked]> writes:

>"Charles Lindsey" <[email-masked]> wrote:

>> OK, then would you be happy with a wording such as:
>>
>>   "Posters should be aware that omission of this header field (or of the
>>   X-No-Archive used for this purpose hitherto) is likely to be
>>   interpreted as implying "Archive: yes".

>That's fine with me, but is USEFOR the right place for it?

Well I think at least s/likely/may well/ or s/is likely/is, under current
practice, likely/, in order to meet Russ's objection.

As to where to say it, read section of 8.3 of USEPRO (which may need
revision when this matter is settled). It could go there, or maybe the
whole of that 8.3 could be moved into USEFFOR.

Date: Wed, 02 Aug 2006 18:16:30 +0100
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: #1335 Injection-date
Sender: [email-masked]

Charles Lindsey wrote:

>In <[email-masked]> Harald Alvestrand <[email-masked]> writes:
>  
>
>>3.2.1.  Injection-Date
>>    
>>
>>  The Injection-Date header field contains the date and time that the
>>  article was injected into the network.  Its purpose is to prevent the
>>  reinjection into the news stream of "stale" articles which have
>>  already expired by the time they arrive at some news server.
>>    
>>
>>Suggested rephrase of last sentence:
>>    
>>
>>  Its purpose is to allow news servers that try to reject "stale" 
>>  articles to check
>>  a date field that was added by a news server at injection time, 
>>  rather than the
>>  Date: field that is added by the user agent at message composition time.
>>    
>>
>>Works?
>>    
>>
>
>I don't like the word "try". Rejecting stale articles is a MUST in USEPRO
>(you can end up with looping if you omit that check).
>
>So it should be:
>
>   Its purpose is to enable news servers, when checking for "stale"
>   articles [refer to USEPRO if you like], to use a <date-time> that was
>   added by a news server at injection time rather than one added by the
>   user agent at message composition time.
>  
>
Works for me.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1313 Newsgroups and reserved characters
Date:  Tue, 01 Aug 2006 22:17:03 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Seth Breidbart wrote:

> Which is the RFC that specifies a mailswerver MUST NOT reject
> a message because the HELO argument doesn't resolve to the
> sending IP?

Near the bottom of http://tools.ietf.org/html/rfc2821#page-39

Frank

Date: Tue, 1 Aug 2006 15:47:06 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Archive
Sender: [email-masked]

>> would you be happy with a wording such as:
>
>> "Posters should be aware that omission of this header field (or of the
>>  X-No-Archive used for this purpose hitherto) is likely to be
>>  interpreted as implying "Archive: yes".
>
> No, that's not the case.

Yes, it is.  Hint: How does Google interpret lack of the X-No-Archive
header?

>  I'm aware that if I post a net news article then it will be
> transported to various news servers, and read by some folks.  They
> might even archive it for private purposes.  After some time the
> article will expire from almost all servers, and that's it.  It
> doesn't imply "Archive: yes".

That's the point.  Posting without the header is _neither_ granting
permission nor denying permission.  However, many third parties
(e.g. Google) will archive articles that lack the header.  That is a
simple fact.

Whether or not we should state that fact (and in which document) is a
separate issue, and not one I find worth arguing over.

Seth

Date: Tue, 1 Aug 2006 15:18:55 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Archive
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> wrote:

> OK, then would you be happy with a wording such as:
>
>   "Posters should be aware that omission of this header field (or of the
>   X-No-Archive used for this purpose hitherto) is likely to be
>   interpreted as implying "Archive: yes".

That's fine with me, but is USEFOR the right place for it?

Seth

Date: Tue, 1 Aug 2006 15:17:47 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

> You could argue that "MUST accept" does not imply "MUST propagate", but
> that is a bit thin.
>
> So I would suggest (in the two places, for "[+-]" and for "_") either
>
>   "MUST be accepted (subject to site policy)"
> or
>   "SHOULD be accepted".
> I think I prefer the "SHOULD".

I'd prefer something like "MUST NOT be rejected for this reason
alone".  If they want to reject for some other reason, fine.

(Which is the RFC that specifies a mailswerver MUST NOT reject a
message because the HELO argument doesn't resolve to the sending IP?
That's the sort of wording I'd want.)

Seth

Date: Tue, 01 Aug 2006 11:44:31 -0700
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1311 Archive
Sender: [email-masked]

I think we have a consensus-minus-Charles that not putting an Archive: 
header on an article means that there is no Archive: header on the 
article, and that there is no standardized meaning for its absence.

                      Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Archive
Date:  Tue, 01 Aug 2006 20:27:21 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Sender: [email-masked]

Charles Lindsey wrote:
 
> would you be happy with a wording such as:
 
> "Posters should be aware that omission of this header field (or of the
>  X-No-Archive used for this purpose hitherto) is likely to be
>  interpreted as implying "Archive: yes".

No, that's not the case.  I'm aware that if I post a net news
article then it will be transported to various news servers,
and read by some folks.  They might even archive it for private
purposes.  After some time the article will expire from almost
all servers, and that's it.  It doesn't imply "Archive: yes".

Frank

Date: Tue, 1 Aug 2006 19:14:20 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1311 Archive
Sender: [email-masked]

In message <[email-masked]>, Russ Allbery
<[email-masked]> writes
>
>Charles Lindsey <[email-masked]> writes:
>
>> OK, then would you be happy with a wording such as:
>
>>    "Posters should be aware that omission of this header field (or of the
>>    X-No-Archive used for this purpose hitherto) is likely to be
>>    interpreted as implying "Archive: yes".
>
>No.

I agree ... suppose someone successfully sues Google for archiving
without permission.  If they obey the court then omission will mean no
archiving (by them). Hence such a statement will be wrong (and
obstructive to the decision of the court...)

Omission is "undefined" ... with all that that implies for differing
occurrences at different points in space and time.

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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Archive
Organization: The Eyrie
Date: Tue, 01 Aug 2006 11:04:39 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> OK, then would you be happy with a wording such as:

>    "Posters should be aware that omission of this header field (or of the
>    X-No-Archive used for this purpose hitherto) is likely to be
>    interpreted as implying "Archive: yes".

No.

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

To: [email-masked]
Xref: clerew local.usefor:23483
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1313 Newsgroups and reserved characters
Date: Tue, 1 Aug 2006 14:20:23 GMT
Lines: 55
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>Charles Lindsey wrote, in part:
>> 
>> No, we told him he SHOULD NOT. If he inadvertently does, then it will be
>> propagated if there are are further proper crossposts, otherwise it will
>> only be accepted at sites where that group exists (i.e. those that are
>> party to the "private arrangement"). That all seems OK to me.
>> 

>Why can't we let the "private arrangements" fall outside the standard?

Because, having created the notation, we don't want normal MUAs and
servers to refuse to accept it (claiming that it is 'non-standard').
People who enter into "private arrangements" will still expect their MUAs
to work with the arrangement. So we say that _generating_ the notation
should only be done by servers for the benefit off their own 'private'
clients.

>Why even discuss how "contractual" those arrangements must be?

Agreed. We don't say that (apart from saying it is a 'private' matter).

>Besides: if I have a private heirarchy, I may want to configure my relayer
>to reject articles which are cross-posted to private newsgroups (either inbound
>or outbound.)

USEPRO makes it clear that relayers MAY reject anything they like for
reasons of site policy (MUST or no MUST). What they can't to is to relay
it in an altered form.

>In the draft, that violates a MUST.  That's a problem with the draft.

Hmmm! You have a point there, and a deviation from USEPRO.

You could argue that "MUST accept" does not imply "MUST propagate", but
that is a bit thin.

So I would suggest (in the two places, for "[+-]" and for "_") either

   "MUST be accepted (subject to site policy)"
or
   "SHOULD be accepted".
I think I prefer the "SHOULD".

To: [email-masked]
Xref: clerew local.usefor:23486
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1309 Supersedes and Distribution
Date: Tue, 1 Aug 2006 14:43:00 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> Seth Breidbart <[email-masked]> writes:

>"Charles Lindsey" <[email-masked]> wrote:

>[Supersedes]

>> "This header MUST/SHOULD NOT be used unless the Newsgroups header
>> field of the article contains at least one <newsgroup-name> in
>> common with with the Newsgroups header field of the superseded
>> article."
>>
>> MUST vs SHOULD is open to discussion.

>At most SHOULD, but I think that is too strong.

I have no problem with not making the change, but Frank raised the point
and so I suggested wording that would address it. I see that he still
wants it fixed. But I think we would all agree that SHOULD is as far as we
need go.

To: [email-masked]
Xref: clerew local.usefor:23485
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Tue, 1 Aug 2006 14:38:20 GMT
Lines: 49
Sender: [email-masked]

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

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

>> The current situation is that no X-No-Archive and "X-No-Archive: no" are
>> equivalent.

>X-No-Archive: no is probably undefined.  I'm not sure anyone has used
>that, and I expect at least some archives just check for the existence of
>the header.

Would things be simpler if we defined a No-Archive header rather than an
Archive header?

>> Therefore, to retain the current situation, 
>>      no X-No-Archive
>> plus no Archive

>> should be equivalent to "X-No-Archive: no", which is in turn equivalent
>> to "Archive: yes".

>No, absolutely not.  My lack of expression of any archive policy on my
>posts is *absolutely not* the same thing as asserting a policy that anyone
>can archive my posts.

OK, then would you be happy with a wording such as:

   "Posters should be aware that omission of this header field (or of the
   X-No-Archive used for this purpose hitherto) is likely to be
   interpreted as implying "Archive: yes".

>I am leaving my archive policy intentionally undefined with the
>understanding that some sites have chosen to take that as permission.  I
>am *not* estopping myself from taking exception to that decision in the
>future should I have grounds and reason to do so.

OK, but in the face of current existing practice you would have a hard
time making that case.

To: [email-masked]
Xref: clerew local.usefor:23484
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Tue, 1 Aug 2006 14:29:35 GMT
Lines: 34
Sender: [email-masked]

In <[email-masked]> Seth Breidbart <[email-masked]> writes:

>The standard should NOT say anything like "Lack of an Archive: header
>means <X>".

>If I post "Archive: yes" I'm granting permission to archive.  If I
>post "Archive: no" I'm explicitly denying permission to archive.  If I
>don't include an Archive header I'm not doing either (at least, not in
>that way).

But nobody is ever going to write "Archive: yes", any more that anybody
currently writes "X_No_Archive: no", because the general understanding is
that if they write nothing that will be the effect, i.e. Google et al will
assume that they don't object. That is the state that I wish to preserve.

If they have 2nd thoughts, or they want to negotiate with Google in other
ways, then other mechanisms are available (as Frank has pointed out)

>It does not seem useful to force the poster to make a decision that
>isn't necessary.

I don't think we are forcing the poster to decide anything. Just pointing
out the consequences if he does nothing.