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

From: Frank Ellermann <[email-masked]>
Date: Wed, 12 Jul 2006 05:52:32 +0200

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

That was an impressive list. About the URL issue:

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

IIRC that could be an xml2rfc "feature", where it's 
possible to convince this tool that the plain text 
output is relevant, not the meta data in other output
formats.

>>"nine-year effort".
> and rising ...

Ralph didn't say that the draft is better than 2003,
but I like the current versions, less wishful thinking.

Bye, Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Jul 2006 21:57:40 +0100

I've trimmed the comments. I think Ken has applied most editorial 
changes/fixes not listed below.

Ralph Babel wrote:

>| 1.5.  Definitions

[...]

>| A "poster" is the person or software that composes and
>| submits a possibly compliant article to a "user agent".
>| The poster is analogous to an [RFC2822] author.
>
>Actually, I'd associate "poster" with "sender", not "author"
>(and so does section 3.2.14). Why not simply use "author"
>for "From:" and "sender" for "Sender:"? This way, the draft
>would be less likely to confuse readers, in particular once
>they run across the "Followup-To: poster" functionality,
>which needs to take "Reply-To:" into account.

Created new ticket # 1315.

>| 1.6.  Structure of This Document
>
>| This document uses a cite by reference methodology,
>
>| rather than repeating the contents of other standards,
>| which could otherwise result in subtle differences and
>| interoperability challenges.
>
>It is unclear to which of the
>two options the "otherwise" refers.*
>*
>
Both.

>| 3.1.5.  Newsgroups
>|
>| Such components MAY be used only to refer to existing
>| groups that do not conform to this naming scheme.
>
>I find this a little wishy-washy. The syntax clearly states
>that a newsgroup name may well contain all-digit components
>or uppercase letters; the two "SHOULD NOT"s warn about
>compatibility issues. _Of_ _course_, clients and servers are
>free to support the full syntax. So what's this "MAY" about?
>
>| <component>s beginning with underline ("_") are reserved
>| for use by future versions of this standard and MUST NOT
>| be generated by user agents
>
>Just user agents? What about servers _generating_ components
>like these? After all, the newsgroups listed in "Xref" are
>documented as not necessarily agreeing with the Newsgroups
>header field, so news servers may well generate newsgroup
>names themselves in articles.
>
>| (whether in Newsgroups header fields
>
>What about "Followup-To" header fields?
>
>| or in newgroup control messages [I-D.ietf-usefor-usepro]).
>
>| However, such names MUST be accepted by news servers.
>
>Just by servers? What about user agents?
>
>| <component>s beginning with "+" and "-" are reserved for
>| private use and MUST NOT be generated by user agents
>
>As above.
>
>| (whether in Newsgroups header fields
>
>As above.
>
>| or in newgroup control messages [I-D.ietf-usefor- usepro])
>
>As above.
>
>| such names MUST be accepted by news servers.
>
>As above.
>
Created ticket # 1314.

>| 3.1.6.  Path
>|
>| This is primarily to enable news servers to avoid
>| sending articles to sites already known to have them,
>
>Path-preloading needs to be mentioned in section 5.
>
>| NOTE: Although case-insensitive,
>
>If the path or components of it are to be treated as
>case-insensitive, this needs to be mentioned outside
>of a "note". Traditionally, the path and UUCP names
>were case-sensitive; domain names are case-insensitive.
>So we need to make clear what the status of each of the
>individual components is.
>
Created new ticker # 1334.

>| 3.2.1.  Injection-Date
>|
>| Its purpose is to prevent the reinjection into the news
>| stream of "stale" articles which have already expired
>| by the time they arrive at some news server.
>
>If they have already "expired", then "reinjection"
>isn't an issue. Quite the contrary: once everybody starts
>depending on "Injection-Date" and - ignoring "Date" - uses
>it to check against the history cut-off limit, reinjection
>of stale articles (after stripping "Injection-Date",
>of course) will become a lot _easier_.
>
>I thought its purpose was to aid in the _propagation_ of
>articles that are "injected" a long time _after_ their
>"Date" header field has been added locally by the client.
>
>| This header field MUST be inserted
>| whenever an article is injected.
>
>By whom? And when exactly does "injection" take place?
>
>| software that predates this standard does not use
>| this header, and therefore agents MUST accept
>| articles without the Injection-Date header field.
>
>I consider this to be a contradiction. We cannot make an
>experimental header field (and that's what "Injection-Date"
>is at this point) mandatory (see "MUST be inserted" above).
>
>The first step will have to be a "MAY",
>default value being the "Date" header field body.  
>
Reopening closed issue: #1088.

>| but SHOULD NOT alter the pre-existing Date header field.
>
>| This header field is intended to replace the
>| currently-used but undocumented "NNTP-Posting-Date"
>| header field, whose use is now deprecated.
>
>I'm not aware of "NNTP-Posting-Date" ever having been
>anything but a trace field, so it served a completely
>different purpose.
>
Created new ticket #1335

>| 3.2.4.  Expires
>|
>| The Expires header field specifies a date and time when
>| the article is deemed to be no longer relevant and could
>| usefully be removed ("expired").
>
>How about a note that this is used both to reduce and to
>extend the "regular" expiration period and that the local
>effects are implementation/configuration-specific?
>
Created new ticket #1336

>| 3.2.6.  Supersedes
>|
>| The Supersedes header field contains a message identifier
>| specifying an article to be superseded upon the arrival
>| of this one.
>
>So what does "superseded" mean?
>
Replace?

> I'd add something along the
>lines of "The local effects of superseding an article are
>implementation-specific.".
>
>| 3.2.7.  Distribution
>|
>| The Distribution header field specifies geographic or
>| organizational limits on an article's propagation.
>
>Doesn't say a whole lot about how it actually _works_.
>A few words to the effect that a site may consider itself
>(or others) to be a member of one or more <dist-name>s?
>
>| The <dist-name>s "world" and "local" are predefined.
>
>Where? In which way?
>
>| "All" MUST NOT be used as a <dist-name>.
>
>So it's sort of predefined as well, isn't it?
>
Created new ticked # 1309

>| 3.2.9.  Approved
>|
>| one of those mailboxes MUST be that
>| of the actual sender of the article.
>
>Huh? Why and since when? There has never been a requirement
>of this kind, at least not in Usenet as deployed in _my_
>universe. A moderator (or anybody else wishing to use that
>header) is certainly free to have somebody else inject his
>messages on his behalf without listing the sender in the
>Approved header field.
>
Created new ticket # 1310.
[...]

>| 3.2.12.  Archive
>|
>| The absence of this header field, or the presence of this
>| header field with a field body of "yes", indicates that
>| the poster is willing for such redistribution to take
>| place.
>
>The default value in absence of this header is a copyright
>issue subject to numerous local jurisdictions we cannot
>reasonably take a stand on.
>
>It makes a difference whether a private company like
>Dejanews, Altavista, or Google defines the default of
>a nonstandard header field this way or whether an RFC
>does so for what is to become a standard header.
>
>
>The draft should simply remain silent on the default.
>
>The change was introduced without discussion in
>draft-ietf-usefor-usefor-02.txt, and I don't see any
>justification for it; in fact, the ramifications
>were discussed in May/June 2001 already:
>
> <[email-masked]>
> <[email-masked]>
>
New ticket # 1311.

>| 3.2.14.  Injection-Info
[...]

>There was also strong support for
>generic complaints URLs, not just mail.
>  
>
I was also in favour of this, but there was no consensus in the WG.
People who want to do this should write a separate draft.

>| Some pieces of information have privacy implications;
>| this is discussed in [I-D.ietf-usefor-useage].
>
>| 3.3.  Obsolete Header Fields
>
>So many words, so little effect. If we can obsolete (see
>section 6) non-RFC headers such as those from s-o-1036,
>what's the problem with these headers from RFC 850? Yes,
>850 is a "nonstandard". So how is this different from
>1036 and s-o-1036?
>
>My suggestion: Replace the entire section by ...
>
>| The header field names Date-Received, Posting-Version, and
>| Relay-Version defined in [RFC850] as well as Also-Control,
>| Article-Names, Article-Updates, and See-Also defined in
>| [Son-of-1036] are declared obsolete. See the original
>| documents for further information on their original use.
>
>I'm not aware of anything that breaks _if_ these
>header fields are included in an article, so
>there's no need for 2119 language.
>
>Add to section 6:
>
>| Header field name: Date-Received
>| Applicable protocol: netnews
>| Status: obsoleted
>| Author/change controller: IETF
>| Specification document(s): [RFC850] (section 2.2.4)
>|
>| Header field name: Posting-Version
>| Applicable protocol: netnews
>| Status: obsoleted
>| Author/change controller: IETF
>| Specification document(s): [RFC850] (section 2.1.2)
>|
>| Header field name: Relay-Version
>| Applicable protocol: netnews
>| Status: obsoleted
>| Author/change controller: IETF
>| Specification document(s): [RFC850] (section 2.1.1)
>
>(or "historic" instead of "obsoleted")
>
>Add to section 7.2:
>
>| [RFC850]  Horton, Mark R., "Standard for Interchange
>|           of USENET Messages", RFC 850, June 1983.
>
[...]

>| 6.  IANA Considerations
>|
>| Header field name: Also-Control
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: Article-Names
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: Article-Updates
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: See-Also
>| Status: obsoleted
>| Author/change controller: IETF
>
>These are not strictly IETF header fields,
>so their status may have to be "deprecated".
>
>| Header field name: Archive
>| Status: standard
>|
>| Header field name: Injection-Date
>| Status: standard
>|
>| Header field name: Injection-Info
>| Status: standard
>
>Isn't that "experimental" for now? After all,
>there's not a single implementation yet, is there?
>
>| Header field name: Lines
>| Status: deprecated
>
>"deprecated" isn't listed among the preferred values for
>IETF documents, and we call it "obsolescent" in 3.3.1.
>
>| Header field name: NNTP-Posting-Date
>| Status: obsoleted
>| Author/change controller: IETF
>|
>| Header field name: NNTP-Posting-Host
>| Status: obsoleted
>| Author/change controller: IETF
>
>According to section 3.2.1, it's "deprecated".
>Are these really IETF header fields?

I've reopened ticket # 1156.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 12:10:53 GMT

>Created new ticket # 1315.

"Poster" is the term in current widespresd use on Usenet. Leave it alone.
"Sender" means exactly the same as in Email. Leave it alone.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 21:11:43 GMT

>>effects are implementation/configuration-specific?

Yes, I wanted that, but failed to convince the WG, so the issue is dead.
It is covered in USEAGE.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 21:02:29 GMT

>>"Date" header field has been added locally by the client.

Yes, that is the benefit of the new arrangement. Using the Date header for
checking against the history (which is current practice) may cause
articles injected much later to fail to propagate.
>>By whom? And when exactly does "injection" take place?

By the injecting agent. USEPRO specifies exactly when to insert it. If you
are arguing that the "MUST" is premature in UESFOR, then I don't mind if
Ken changes it to "is to be inserted". The real "MUST" is in USEPRO.
>>is at this point) mandatory (see "MUST be inserted" above).

No, it is not an experimental header. Existing software will be
non-compliant until it implements this. However, USEPRO gives clear
instructions what to do if it is absent, so the transition should be quite
smooth.
>>default value being the "Date" header field body.

No, that would mean it would never happen, and the benefit would never
be achieved. It is perfectly OK to creqte new mandatory requirements in
a new standard, provided you include some transitional mechanism so that
the old stuff does not break.  This was all agreed years ago when this new
header was invented.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 21:32:41 GMT

>>messages on his behalf without listing the sender in the

A new requirement indeed, and intended to provide one more hurdle for
script kiddies who like to be pretend to be clever by posting to moderated
groups (and also a good stick to wave when LARTing them to their ISPs).
Admittedly nor a strong hoop until we get around to digital signatures of
such things, but a start in the right direction.

As to moderators who delegate their authority, I think the proper way is
to include both the moderator and his nominee in the header. In the case
where I post to such a moderated group, I give my own email address, but
add a comment that it is with the permission of the moderator. In the case
of the *.answers groups, there may be a problem. But I think best practice
in that case would be to include both the actual poster and also the
address of the *.answers team (who routinely give permission for that).

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 20:46:11 GMT

>>| 3.1.5.  Newsgroups

We spent a long time a few months back deciding exactly what was allowed
in a newsgroup-name and when, and I think we reached consensus on
technical matters; so I hope this issue is merely to address whether our
description of that consensus is clear enough.
>>free to support the full syntax. So what's this "MAY" about?

It is well known that a few such groups exist currently (alt.2600 is the
best known). The wording in the draft is "MAY be used only ...", and that
"only" is important. Hence you MAY post articles to alt.2600, but for
alt.2700 (which does not currently exist), the full force of the SHOULD
NOT applies (and in particular the SHOULD NOT applies to creating newgroup
messages for alt.2700). So the "MAY ... only" is providing an exception to
an otherwise general rule. Seems OK to me.
>>names themselves in articles.

Yes, it means exactly what is says. You MUST NOT attempt to post articles
to, or to newgroup, such newsgroup-names. However, if they turn up,
servers are to propagate them (because perhaps by then some extension to
this standard has invented a use for them, and so existing software should
propagate them). Generally speaking, servers never do "generate"
newsgroup-names, so the question does not arise. The prohibition indeed
extends to generating such things in Xref headers, and that is correct. If
some serving agents wishes to do something funny in its own Xref headers
for the benefit of its own clients, then that is fine - we have provided
"+" and "-" for that sort of use, so there is no need for them to use the
reserved "_". So the present wording is correct.
>>What about "Followup-To" header fields?

Yes, Ken can add that if he wants.
>>Just by servers? What about user agents?

If you read it carefully, you will see that the behaviour of user agents
is carefully left undefined (so some future extension or private
arrangement is free to specify some particular effect). The "MUST NOT"
simply ensures that such articles propagate normally.

As above.
>>| (whether in Newsgroups header fields

Yes.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 21:08:32 GMT

>>anything but a trace field, so it served a completely

In addition to its primary purpose of more effectively dealing with stale
articles, this header has a secondary use as a trace field. Hence
NNTP-Posting-Date (nowhere officially defined and badly named) is still
redundant. It would, in any case, have become a field of Injection-Info if
we had wanted to keep it (as NNTP-posting-host did).

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 21:23:11 GMT

>>So what does "superseded" mean?

No, Supersedes.

>>implementation-specific.".

The full effects are described in USEPRO. In the meantime, it is clearly
stated that "Supersedes" is equivalent to "cancel" followed by a new
article. That is quite enough to say in USEFOR.

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

That is the job of USEPRO.

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

But yes, if Ken cares to write some such words.

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

They are predefined by the sentence in question. What to do if you
encounter either of them is clearly stated in USEPRO. In the meantime, the
words themselves convey a strong (and correct) hint as to their meaning.
>>So it's sort of predefined as well, isn't it?

No. The other two may appear and behave as defined (though "world" is
redundant and remains for historical reasons). But "all" is most
definitely forbidden (because it could cause funny things to happen in
CNews, and likely in other implemenations too).

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 21:54:22 GMT

>>reasonably take a stand on.

I think it is essential that the situation is clear in all cases.
Moreover, what we have written reflects current practice. If there is no
such header present, Google et al consider themselves at liberty to
archive the article indefinitely. Our wording confirms that effect. If the
poster wishes to declare that he does not allow such permanent copying,
then he needs to say so explicitly.

>>does so for what is to become a standard header.

I don't see what difference it makes at all. We are standardizing an
existing practice (albeit with slightly changed notation). It is clearly
directed at Google (though not said explicitly), but could apply to any
other archiving sites that might arise in the future. The wording here is
to be read in conjunction with some wording regarding copyright in the
"Security and Related Considerations in USEPRO", which was written at the
same time as the wording here (there could be a pointer to that).  
>>The draft should simply remain silent on the default.

If it reamins silent, there is no default, and the Google situation is not
covered.
>>draft-ietf-usefor-usefor-02.txt,

Not true. The wording you see was in our drafts for many years before
that. There were lots of things omitted from draft--usefor-01 that had
been in earlier drafts, and which were reinstated in draft-02 and later
(it is inevitable that a new draft with a new editor based on an untried
draft written earlier by a non-participant of the group would be riddled
with initial errors, and it took time to get these out).

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 22:06:58 GMT

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

They were defined in Son-of-1036. There is nothing in RFC 3864 to say that
it only covers IETF headers, and if an IETF standard obsoletes some header
that was not previously defined in an IETF document, then there is little
alternative but to say that from henceforth that header is under the
control of the IETF. If you don't like that, then you will have to get RFC
3864 changed.
>>there's not a single implementation yet, is there?

No, it is not experimental, and I have even seen one in the wild.
>>IETF documents, and we call it "obsolescent" in 3.3.1.

Indeed. It should be "obsoleted" IMO.

>>Are these really IETF header fields?

No, but we want to declare them obsolete (that is the only available word
according to RFC 3864). Clearly "obsolete" headers will still be seen from
time to time, but such practices are reasonably to be "deprecated".

---

From: Russ Allbery <[email-masked]>
Date: Tue, 25 Jul 2006 21:19:11 -0700

> script kiddies who like to be pretend to be clever by posting to
> moderated groups (and also a good stick to wave when LARTing them to
> their ISPs).  Admittedly nor a strong hoop until we get around to
> digital signatures of such things, but a start in the right direction.

This is just silly.  We would be arbitrarily declaring common existing
practice in many moderated groups to be non-compliant for no actual gain
in security and no useful end whatsoever.

It is routine to use Approved headers that do not correspond to the Sender
of the message for such purposes as, say, news.answers approval, and it
does nothing to help Usenet to outlaw such behavior.

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 25 Jul 2006 21:27:40 -0700

> No, it is not experimental, and I have even seen one in the wild.

Injection-Info should definitely be experimental.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 25 Jul 2006 21:26:52 -0700

> I think it is essential that the situation is clear in all cases.

I think it's more important that the situation match reality than that the
situation be clear.  I'm inclined to agree with the objection here, define
"yes" and "no", and leave the situation undefined in the absence of the
header.

Right now, we would be saying that an article with X-No-Archive: yes and
no Archive header indicates that the poster is willing for such
redistribution to take place, which is obviously wrong.

> archive the article indefinitely.

If there *is* such a header present, Google et al consider themselves at
liberty to archive the article indefinitely, as so far as I know the only
thing they look for is X-No-Archive.

This entire header is, unfortunately, a probably pointless idea.  I say
unfortunately because it would be nice to standardize an X-* header that
people actually use, but the nature of the header is such that it's
unlikely that some new header we invent is going to replace it in
practice.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Jul 2006 00:36:59 -0700

> an otherwise general rule. Seems OK to me.
I believe the wording here would have been clearer without uppercasing 
the MAY - in this case, I read the the sense of 2119 (MAY = "can choose 
to do so, can choose not to do so) and the sense of common English ("may 
be used only" = other uses are not permitted) is different.

If 2119 language was being used, it would be "MUST NOT be used when it 
is not being used to refer to existing groups that do not conform to 
this scheme". The idea was that we wanted to allow people to go on 
reading alt.2600, but make it illegal to send out a newgrp for 
misc.perfumes.4711.

But I think the 2119 language is longer and harder to understand than a 
downcased "may only be used".

                      Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Jul 2006 00:42:18 -0700

> Injection-Info should definitely be experimental.
Once usefor goes to proposed standard (if ever), injection-info is 
described in a standard document.

I think we cannot reasonably call it anything but "standard" in a 
document that both defines it and is itself a standards-track document.

Understand the sentiment, but I don't think you can get there from here.

                   Harald

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Wed, 26 Jul 2006 08:55:14 -0400

> Understand the sentiment, but I don't think you can get there from here.

Well then....remove it from the document.  It is not existing practice.  It
was so controversial to define and settle, that I doubt we fully understand
the implications or possible improvements that interoperating implementations
would uncover.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 26 Jul 2006 10:10:31 -0700

> I think we cannot reasonably call it anything but "standard" in a document
> that both defines it and is itself a standards-track document.

> Understand the sentiment, but I don't think you can get there from here.

It's almost tempting to argue for taking it out of the document and
publishing it in a separate experimental RFC, but at this stage in the
document's life, it probably does less harm to just publish the damn thing
and have it not be used.

So yeah, I can live with that; I see what you're getting at.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Jul 2006 13:07:47 -0700

> does nothing to help Usenet to outlaw such behavior.
I think Russ has provided compelling argument for striking the requirement.

                 Harald

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 28 Jul 2006 07:39:50 +0200

Charles Lindsey wrote:

> If the poster wishes to declare that he does not allow such
> permanent copying, then he needs to say so explicitly.

No.  Adding "Archive: No" is not the only way how I can try to
protect my rights.

> It is clearly directed at Google

Again no, I'd know how to avoid archiving by Google, or how to
"purge" individual articles.  The more problematic cases are
obscure "web forums" of commercial sites, where they hijack
Usenet groups as "support forum", and then "forget" to mention
that almost all participants are unpaid volunteers in a public
newsgroup.

If I don't use an "Archive: No" I still want to have all legal
options against such activities.

> If it reamins silent, there is no default, and the Google
> situation is not covered.

The default is something like WIPO, none of our business here.

Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 28 Jul 2006 08:00:04 +0200

>>>So what does "superseded" mean?

What's wrong with "replace" ?  Serious question, the last time
I checked it news.clara.net ignored "Supersedes" for "security
reasons".  Maybe something with our definition is not yet good
enough.  "Replace" could imply "same groups".

> In the meantime, it is clearly stated that "Supersedes" is
> equivalent to "cancel" followed by a new article. That is
> quite enough to say in USEFOR.

Something is odd if I post an article in group A, and at the 
same time try to cancel an article in group B.  Maybe we can
do something about this situation in USEPRO later.

Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 28 Jul 2006 21:58:02 GMT

>the implications or possible improvements that interoperating implementations

Existing practice is X-Trace (plus a bit of NNTP-Posting-Host and
NNTP-Posting-Date). We cannot standardize those, and they are a mess
anyway.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 28 Jul 2006 21:32:29 GMT

>What's wrong with "replace" ?

Just that "supersedes" is the technical term we have adopted, and its
meaning is described in the next sentence.

>do something about this situation in USEPRO later.

Two points there. USEPRO currently says very little about this header, and
that needs fixing (probably along with the duties of a serving agent). I
have made a note to deal with that.

The point about trying to supersede an article in one group with an
article in another has not been raised before AFAIR. There are of course
various possibilities if the new article is to a subset, a superset, or
some strange intersection of the crossposts of the original article.

If this is mentioned (and it probably should be, though not every
sub/super/inter case is necessarily wrong), then I think USEFOR is
probably the place to mention it.

But first, just which cases do we wish to outlaw? I would have thought
some non-empty intersection was good enough to allow it through.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 28 Jul 2006 21:47:10 GMT

>does nothing to help Usenet to outlaw such behavior.

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

At the moment "Approved: foobar" is sufficient to work. I think the least
we should require is a working, non-forged email address that bears some
relationship to the person or entity responsible for the approval. So
something like:

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

That will cover the *.answers case, but will also encourage *.answers
submitters to include themselves, as well as the *.answers moderators.

When digital signatures become the norm (and work needs doing on that),
then it will be the inclusion of the Approved header within the digital
signature that actually confirms the claimed authority.

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.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 29 Jul 2006 20:54:04 GMT

>"yes" and "no", and leave the situation undefined in the absence of the

I think the place where we want to get to is that the situation regarding
Google (and any similar sites) will be the same under Archive as it
currently is (de facto, since it is nowhere written down) under
X-No-Archive.

>redistribution to take place, which is obviously wrong.

and yes, that is a valid point. Google have dropped hints that they will
be happy to recognise and act upon Archive (when it is standardised) as
they currently do for X-No-Archive. But obviously people will continue to
use X-No-Archive for some considerable time, and Google will continue to
take note of it.

The meaning of Archive with 'yes' or 'no' is clear (it asserts that the
poster gives or witholds permission for certain copying). Likewise,
X-No-Archive makes similar assertions (so far as one can judge), but with
'yes' and 'no' reversed.

So clearly, if either of these headers appears, it should be taken as
making that assertion. If both appear, and they conflict, then I really
don't care, and if they agree, then no problem.

So what if both are absent? That should reflect present practice, which is
that Google presumes they have permission to copy, and go ahead
accordingly. So how to bring that about? I would suggest something like:

   If this header is omitted, and no other indication of the poster's
   willingness for such redistribution to take place has been given (e.g.
   by an X-No-Archive header field which has hitherto been used for this
   purpose), the default is as if an Archive header field had been given
   with ¨yes".

That wording would also cope with any other unusual means of conveying
permissions (for example, some people have given permanent instructions to
Google Never to redistribute Any of their articles).

BTW, someone queried the use of the word "redistribution". It is in fact
correct. It is well known that Google actually store everything; what they
do is to refuse to supply it (i.e. to "redistribute" it) when asked for
it.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 28 Jul 2006 21:55:24 GMT

>Indeed. It should be "obsoleted" IMO.

On further thought, I think this should be stated as "standard" (it is not
actually "obsolete" yet, though rapidly heading in that direction). But
then add a "Related Information" (which you are allowed to do) to say that
it is "obsolescent".

>>>Are these really IETF header fields?

I note that Harald accepts that these are now IETF-controlled, even if
they were not before. But here, I think we have no option but to say
"obsolete".

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 30 Jul 2006 13:32:32 +0200

Charles Lindsey wrote:

 [Supersedes in group A => cancel in group B]
> But first, just which cases do we wish to outlaw? I would
> have thought some non-empty intersection was good enough to
> allow it through.

Yes, that should IMO cover the plausible uses of Supersedes.

Ideally the same groups, otherwise good faith efforts to find
an apparently lost article in control.cancel.* will fail.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 30 Jul 2006 13:15:55 +0200

Charles Lindsey wrote:

> I would suggest something like:

NAK, no archive header field and "Archive: yes" are different.
Very different in fact.  It's one of the reasons why there is
a semi-automated way to "purge" articles in Google's archive.
And this known archive isn't the real problem, unlike others.

Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 31 Jul 2006 11:44:39 GMT

>Yes, that should IMO cover the plausible uses of Supersedes.

In that case, you would need something like the following at the end of
the first paragraph of 3.2.6:

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 31 Jul 2006 11:35:29 GMT

>NAK, no archive header field and "Archive: yes" are different.

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

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". What other wording would you propose to achieve that?

>And this known archive isn't the real problem, unlike others.

Please explain your 'semi-automated way to "purge" articles' as it
currently works. Then we can see how it might work (or not) with the
Archive header.

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 31 Jul 2006 12:44:47 -0400 (EDT)

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

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

Seth

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 31 Jul 2006 12:41:49 -0400 (EDT)

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

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

If someone falls into a Followup-To trap (a troll sets it to some
random groups and the poster doesn't notice until just after posting),
why not supersede to just the correct groups?

There might be an issue of which groups are carried where, but I don't
see that as a major one these days.

Seth

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 31 Jul 2006 19:54:52 +0200

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

My gut feeling is that we can't jump from "do what
you like" to MUST,  But less than SHOULD would be
pointless to begin with, so if it's a good idea
it needs SHOULD, otherwise DEL.

> If someone falls into a Followup-To trap (a troll
> sets it to some random groups and the poster doesn't
> notice until just after posting), why not supersede
> to just the correct groups?

That's a legit case, where Supersedes is in fact only
a shorthand for an arbitrary Cancel + posting a more
or less unrelated new article.

If you thinkl that's fine you could also have it that
a troll first posts in group A, and later "hides" the
Cancel by a Supersedes in a test group.  In the worst
case a test group in a different TLH.

Obviously you cant have both, allow the shorthand, and
discourage the "hidden" Cancel.

I'm not hot about it, only a bit annoyed than one news
server I use(d) doesn't support it at all for obscure
"security reasons" (while allowing ordinary Cancels).

Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 31 Jul 2006 20:19:08 +0200

Charles Lindsey wrote:

> What other wording would you propose to achieve that?

As Seth said it, just don't define a default for this header
field, posters are then free to make no statement.  Today
(it used to be different when deja was new) I don't care if
Google archives my articles, and I know how to delete them
in their archive (I didn't need that for real so far, but I
tested that it would work in an emergency).

So that's this archive, it's fine as far as I'm concerned.
Other archives have other rules - try to delete a mail sent
to an IETF list (AFAIK impossible), to a W3C list (tricky),
on GMaNe (AFAIK impossible), or on an obscure Web forum
archiving Usenet articles.

Maybe they don't offer a feature to "purge" articles.  As I
have the copyright (to a certain degree) I could insist on
deleting stuff I've written.  Or rather I could try to insist
on it.

But if I've stated "Archive: Yes" they could send an invoice,
or flatly refuse to do what I want.  Therefore I don't want
an "Archive: Yes" default, in many legal matters being silent
is often the best way to protect your rights.

> Please explain your 'semi-automated way to "purge" articles'
> as it currently works.

For Google all you need is a valid working From: address and
the mailbox behind it.  Then go to http://purl.net/net/msgid
and kill your own article.  Confirmation and verification is
by mail to the From: address of the affected article.

For this procedure the future Archive header field (or its
X-No predecessor) is irrelevant.

Bye, Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Archive
Organization: The Eyrie
Date: Mon, 31 Jul 2006 17:49:46 -0700
Sender: [email-masked]

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

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.

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

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.  I am most certainly not
making a public statement that archiving my posts is unconditionally fine
by me.

This is exactly why I object to the default language.  We have no business
saying that everyone on Usenet is agreeing to have their posts archived
unless they include this new header that we just made up.  The default
archive policy and the legal ramifications thereof (and whether it differs
in different jurisdictions, etc.) is outside the scope of our document.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Archive
Date:  Mon, 31 Jul 2006 20:19:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 40
Sender: [email-masked]

Charles Lindsey wrote:

> What other wording would you propose to achieve that?

As Seth said it, just don't define a default for this header
field, posters are then free to make no statement.  Today
(it used to be different when deja was new) I don't care if
Google archives my articles, and I know how to delete them
in their archive (I didn't need that for real so far, but I
tested that it would work in an emergency).

So that's this archive, it's fine as far as I'm concerned.
Other archives have other rules - try to delete a mail sent
to an IETF list (AFAIK impossible), to a W3C list (tricky),
on GMaNe (AFAIK impossible), or on an obscure Web forum
archiving Usenet articles.

Maybe they don't offer a feature to "purge" articles.  As I
have the copyright (to a certain degree) I could insist on
deleting stuff I've written.  Or rather I could try to insist
on it.

But if I've stated "Archive: Yes" they could send an invoice,
or flatly refuse to do what I want.  Therefore I don't want
an "Archive: Yes" default, in many legal matters being silent
is often the best way to protect your rights.

> Please explain your 'semi-automated way to "purge" articles'
> as it currently works.

For Google all you need is a valid working From: address and
the mailbox behind it.  Then go to http://purl.net/net/msgid
and kill your own article.  Confirmation and verification is
by mail to the From: address of the affected article.

For this procedure the future Archive header field (or its
X-No predecessor) is irrelevant.

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1309 Supersedes and Distribution
Date:  Mon, 31 Jul 2006 19:54:52 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

Bye, Frank

Date: Mon, 31 Jul 2006 12:44:47 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Archive
Sender: [email-masked]

Seth

Date: Mon, 31 Jul 2006 12:41:49 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1309 Supersedes and Distribution
Sender: [email-masked]

[Supersedes]

Seth

To: [email-masked]
Xref: clerew local.usefor:23472
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Mon, 31 Jul 2006 11:35:29 GMT
Lines: 41
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23473
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1309 Supersedes and Distribution
Date: Mon, 31 Jul 2006 11:44:39 GMT
Lines: 30
Sender: [email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Improved <toplabel> idea
Date:  Mon, 31 Jul 2006 14:34:37 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Charles Lindsey wrote (in April):

> I grant you that your syntax is neat and does the job, but it
> is really someone else's job to fix it.

Credits to Matthew.van.Eerde for the simple variant. I thought
it's a bit better than what we have if we extend it to "minimal
length two" (as we have it already, only somewhat convoluted).

Translating what we have to his style I arrived at:

>>| toplabel =
>>|       ( alpha 1*alphanum ) / ( 1*digit alpha *alphanum ) /
>>|       ( 1*alphanum "-" *( alphanum / "-" ) alphanum )

Matter of taste, probably, if you like our old solution better.

The 4408 folks picked his original idea (= minimal length one),
not our ABNF (= minimal length two), and not the combination.

Bye, Frank

Date: Mon, 31 Jul 2006 06:45:44 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

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?

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

I think the language in the text under discussion about "accepting newsgroup 
names" is confusing, because "accepting newsgroup names" is different than
"accepting newsgroup."

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

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

Date: Mon, 31 Jul 2006 10:44:43 +0200
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1312 LInes: This may be tricky.... suggested resolution
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> "Charles Lindsey" <[email-masked]> writes:
>
>   
>> In <[email-masked]> Harald Alvestrand <[email-masked]> writes:
>>     
>
>   
>>> Suggested resolution:
>>>       
>
>   
>>> Replace the last paragraph with:
>>>       
>
>   
>>>   The line count is the number of CRLF separators in the body.
>>>       
>
>   
>> Yes, that would do. The main intent of the original wording was to
>> emphasise that it really did mean the _whole_ body, hence the mention of
>> the things that people might be tempted not to count. A lot of systems
>> have been known to get it wrong through such misunderstandings.
>>     
>
> On further thought, the usual mistake is to count the CRLF in the empty
> line which separates the header fields from the body. Maybe that is worth
> pointing out.
>   
Other common mistakes (from email) include counting bare LFs as 
linebreaks, representing multiple blank lines as CRLFLFLF and counting 
them all, breaking lines without adjusting the linecount, not counting a 
blank line at the end of a message, counting the line at the end of the 
message even when it's not CRLF-terminated, not including the blank 
lines around MIME boundaries.... I don't think you can usefully single 
out one common error. Agree that body needs to be <body>.
> But at the very least, it needs s/body/<body>/ in Harald's text. That
> makes it clear to anyone who takes the trouble to consult the RFC 2822
> syntax.
>
>   

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Some late -08 nits
Date:  Mon, 31 Jul 2006 06:07:32 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Sender: [email-masked]

Before deleting the old 07 from my box I went through a diff:

In 3.2 s/occurances/occurences/ (?)

In 3.2.11 we still have a complex "article-locator" different
from s-o-1036, I'd prefer 1*VCHAR here as defined in RFC 4234,
adding VCHAR to the import interface in section 1.4.

In 3.2.14 we lost the "quotes within quoted string" example by
the elimination of 'sender'.  How about a non-trivial example
for mail-complaints-to ?

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
      Applicable protocol: netnews
      Status: obsoleted
      Author/change controller: IETF
      Specification document(s): [RFC 850] (2.1.2)

      Header field name: Date-Received
      Applicable protocol: netnews
      Status: obsoleted
      Author/change controller: IETF
      Specification document(s): [RFC 850] (2.2.4)

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1312 LInes: This may be tricky.... suggested resolution
Date:  Mon, 31 Jul 2006 00:19:16 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 25
Sender: [email-masked]

Charles Lindsey wrote:
 
> the usual mistake is to count the CRLF in the empty
> line which separates the header fields from the body. Maybe
> that is worth pointing out.

| message         =       (fields / obs-fields)
|                         [CRLF body]
|
| body            =       *(*998text CRLF) *998text

We've removed the "MUST end with CRLF" to get in synch with
2822 some time ago.  That can result in an "off by two" error,
a short note about that effect is fine.

> it needs s/body/<body>/ in Harald's text.  That makes it
> clear to anyone who takes the trouble to consult the RFC 2822
> syntax.

Okay, then also add it to the import interface in section 1.4:

   body          = <see RFC2822 Section 3.5>

Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:23465
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1334 Path and case sensitivity
Date: Sun, 30 Jul 2006 19:37:02 GMT
Lines: 57
Sender: [email-masked]

>> Existing text:

>>   NOTE: Although case-insensitive, it is intended that the <path-
>>   keyword>s should be in upper case, to distinguish them from the
>>   <path-identity>s which are traditionally in lower case.

>> This refers to the idea that the path-diagnostics

>>  !.MISMATCH.1.2.3.4!
>>  !.Mismatch.1.2.3..4!
>>  !.mismatch.1.2.3.4!

>> should all be interpreted the same; when the keywords were given as ABNF
>> constants (like "MISMATCH") in the ABNF grammar, this was implicit in the
>> ABNF rules, and I think we've had discussions on this before without
>> changing them.

>> Nothing here speaks to the case-sensitivity of other path components.

>> I suggest "no change". Comments?

>I think it's really annoying to have the keywords be case-insensitive from
>an implementation standpoint when the rest of the Path header is
>case-sensitive and has been in implementations for years.  It's probably
>not a big deal, but it's annoying, and I don't see what the gain is.

Actually, I thought the case-sensitivity or otherwise of the Path header
was very much dependent on the whim of the implementor. In our old
"article" drafts we said that comparisons might be case sensitive or not,
and that people inventing new identities should be aware of this when
choosing names. But that bit seems to have got lost, and USEFOR does not
say one way or the other (however, since we are encouraging the use of
domain-names, which are case-insensitive, people may well assume that path
entries in general are case-insensitive).

As to the keywords, it is general IETF policy that they be
case-insensitive (and Netnews has consistently broken that rule in all
sorts of cases). Whether that is an argument for breaking it again here,
or whether it is an argument for trying to get it right for once makes an
interesting question.

I would support "no change".

To: [email-masked]
Xref: clerew local.usefor:23466
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1313 Newsgroups and reserved characters
Date: Sun, 30 Jul 2006 19:54:12 GMT
Lines: 55
Sender: [email-masked]

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

>On Fri, 28 Jul 2006, Harald Alvestrand wrote:

>> No, you have it the wrong way around.
>> SHOULD NOT = don't use it if you don't know what you're doing.
>> The MAY identifies one case where you have to use it - access to existing 
>> group.
>> The MUST NOT coves the rest of the cases, including newsgroup creation.

On further thought (I agreed with John the first time) I think Harald's
argument is right.

>Then there is no use for the SHOULD NOT's. You are putting special 
>requirements on the user who accesses known existing groups -- why should
>he have to think twice about going to alt.2600 every time he does?

One should be happy if posters to that group even get as far as thinking
once :-) . So no real danger of them actually thinking twice.

>>> How does the user agent know if a "private prior agreement" exists?
>> Because it's entered into the private prior agreement. How that's done is 
>> their own business.

>I've seen a lot of strange things come out of this group, but a user agent
>that enters into private agreements is just too silly.

But is is mainly serving agents that will set up these private
arrangements, not user agents. The _users_ should be aware of the "private
arrangement", as a result of which they may configure their user agent to
subscribe to the group.

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

To: [email-masked]
Xref: clerew local.usefor:23463
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1336 Expires field semantics
Date: Sun, 30 Jul 2006 18:51:44 GMT
Lines: 57
Sender: [email-masked]

>Suggested change, indicating that the field is the desire of the poster:

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

>  The way in which this interacts with local retention policy on servers is
>  a local matter.

No, I don't think that is what Ralph was after. What a server is expected
to do when it receives an Expires header is quite clear according to
USEPRO. The only choice the server admin has is whether or not to do it
(news servers are usually configurable both to set the normal expiry
time, and in addition to indicate whether (and by how much) an Expires
header can change it.

If you wanted to say that, then a sentence like "It is a matter of local
policy whether, and by how much, this header is allowed to modify the
normal expiry time".

I think Ralph's first point would be covered by somerthing like the
following NOTE, which appeared in our earlier "article" series of drafts:

        NOTE: This header is suitable for specifying both unusually
        short and unusually long expiry times; there is little point in
        using it in other circumstances.

I wanted that to be retained in USEFOR, but the WG thought otherwise.
Naturally, I would be happy to see it restored. Alternatively, it could go
in USEAGE. The point is that its use for extending the storage of FAQs
until the next issue appears is well known. Not so well known is its use
in articles like "I have two spare tickets for the cup final on Friday".
Keeping such an article beyond Friday would be pointless, so an Expires
header for Friday would be a kindness.

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

To: [email-masked]
Xref: clerew local.usefor:23464
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1312 LInes: This may be tricky.... suggested resolution
Date: Sun, 30 Jul 2006 19:01:48 GMT
Lines: 33
Sender: [email-masked]

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

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

>>Suggested resolution:

>>Replace the last paragraph with:

>>   The line count is the number of CRLF separators in the body.

>Yes, that would do. The main intent of the original wording was to
>emphasise that it really did mean the _whole_ body, hence the mention of
>the things that people might be tempted not to count. A lot of systems
>have been known to get it wrong through such misunderstandings.

On further thought, the usual mistake is to count the CRLF in the empty
line which separates the header fields from the body. Maybe that is worth
pointing out.

But at the very least, it needs s/body/<body>/ in Harald's text. That
makes it clear to anyone who takes the trouble to consult the RFC 2822
syntax.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Date:  Sun, 30 Jul 2006 13:42:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Sender: [email-masked]

Charles Lindsey wrote:
 
 [ISO.3166.1988].
> Is there an update of [ISO.3166.1988] that we should be 
> referring to?

Yes, see my later article in this thread.  The 1997 version
also isn't free, but it's the base of the current list, and
that's available online.  

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Archive
Date:  Sun, 30 Jul 2006 13:15:55 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Charles Lindsey wrote:

>   willingness for such redistribution to take place has been given (e.g=
=2E
>   by an X-No-Archive header field which has hitherto been used for this=

>   purpose), the default is as if an Archive header field had been given=

>   with =A8yes".

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1309 Supersedes and Distribution
Date:  Sun, 30 Jul 2006 13:32:32 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Charles Lindsey wrote:

Frank

To: [email-masked]
Xref: clerew local.usefor:23452
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Archive
Date: Sat, 29 Jul 2006 20:54:04 GMT
Lines: 71
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23435
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1310 Approved
Date: Fri, 28 Jul 2006 21:47:10 GMT
Lines: 53
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23457
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1335 Injection-date
Date: Sat, 29 Jul 2006 22:19:19 GMT
Lines: 61
Sender: [email-masked]

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

>> Works?

>Using Injection-date to prevent re-injection as described in USEPRO
>depends that all agents work as described and never alter or remove
>the header.  This is not robust, and I don't see how it offers significant 
>improvement over Date:.

USEPRO clearly states that removing Injection-Date is a MUST NOT (indeed
changing ANY non-variant header during relaying is a MUST NOT).

>There is language that an "injecting agent" receiving a message with an 
>injection-date, SHOULD cause the message to be relayed.

No, that "SHOULD" only comes into effect if, when reinjecting (where an
Injection-Date may be already present), the injecting agent chose (MAY)
not to reject it. A very specific and special circumstance.

>USEPRO is not germane at the momenet, but all the distinctions of "agent"
>are meaningless and not helpful.  The way that INN relays messages
>is to accept them.  It sends messages from the same storage as they exist
>for reading.

The effect is to be as if injecting, relaying and storing were separate
processes that have to be gone through. INN and other servers may well
combine these operations for convenience of implementation. But in CNews,
to take a contrary example, the injection and the subsequent relaying are
indeed separate operations. Also, there are plenty of relayers around that
do not store.

>So USEPRO in 7.2 says that INN, as the injecting agent, "SHOULD cause [the
>message] to be relayed" (note no mention of rejecting stale Injecting dates).

The word "INN" does not occur in that section.
And there is nothing to say that the relaying agent may not fail to relay
for some reason.

>And in 7.2.2. #3 it says an injecting agent MUST reject any article with such a 
>field, except when re-injecting. (Which is a meaningless tautology, I suppose.)

No, an explicit exception for an explicit case.

>Then in 7.3 #2 it says that INN, as relaying agent, MUST examine Injection-Date:
>and reject as stale if that predates the local cutoff.

Again, the word "INN" does not occur in that section

>So, USEPRO states "SHOULD cause to be relayed" + "MUST reject" for those
>stale injection-dates.

To: [email-masked]
Xref: clerew local.usefor:23434
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1309 Supersedes and Distribution
Date: Fri, 28 Jul 2006 21:32:29 GMT
Lines: 47
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23453
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1311 Default value for the Archive header
Date: Sat, 29 Jul 2006 21:08:09 GMT
Lines: 46
Sender: [email-masked]

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

>Frank Ellermann wrote:

>> I'd like it better without "wish to" for the "no" case.  And as
>> noted elsewhere "long term" covers "permanent", you could get
>> rid of "or permanent".
>After having suffered through excessive reviews of the terms of 
>"copyright" in IPR and in other fora, I believe "wish to" is correct, 
>because the poster frequently has no legal right to decide one way or 
>the other, and the only way to discover whether he has the right or not 
>is to drag the case into a court of law.

>Examples include the mandatory-by-law storing of newsgroups in national 
>history archives, retention of messages in Sarbanes-Oxley mandated 
>archives, deletion of messages by company policy under Sarbanes-Oxley, 
>fair use, reposting of others' messages, "+1" messages that can be 
>deemed to have "no creative content" and so forth.

Yes, edge cases like those can always be troublesome. See the wording in
the "security and related considerations" in USEPRO, which covers the
presumed permission inherent in Usenet for copying to servers worldwide
(not permanent by usual expectations), and covers the Archive header, and
gives warnings and directs you to your lawyer for just about everything
else.

As to "wish to", we currently say that he permits or does not permit
something. If you want to say that he "wishes to permit ...", then you
could do so but it won't really make any difference. If the courts decide
he had no right to "permit" (or not), then they will proceed accordingly
anyway.

Although "long term" covers "permanent", it is probably better left just
to convey a little extra emphasis.

To: [email-masked]
Xref: clerew local.usefor:23442
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1313 Resolution of 2.2 - syntax for USENET articles
Date: Fri, 28 Jul 2006 22:14:17 GMT
Lines: 46
Sender: [email-masked]

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

>Ralph Babel thinks that we need to make note of MIME in this section.

>MIME is described in the next section (2.3), which deals explicitly with 
>MIME conformance.
>I suggest that rather than mixing MIME into 2.2, we modify section 2.2 
>so that it ONLY deals with headers.

>I suggest the following change to section 2.2:

>OLD:

>   The syntax allowed for news
>   articles is a strict subset of the "Internet Message Format", making
>   all messages compliant with this specification inherently compliant
>   with [RFC2822].  Note however that the converse is not guaranteed to
>   be true in all cases.

>NEW:

>   The syntax allowed for news
>   article headers is a strict subset of the "Internet Message Format" 
>headers, making
>   all headers compliant with this specification inherently compliant
>   with [RFC2822].  Note however that the converse is not guaranteed to
>   be true in all cases.

I agree that mentioning "header fields" would be better. I prefer not to
use the RFC 2822 term "header" with its defined meaning, because so may
people will misinterpret it as "header field".

But the only change you have actually made is to remove the "bodies" from
consideration in the sentence, which is technically less accurate. So I
prefer the original.

To: [email-masked]
Xref: clerew local.usefor:23436
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1156 IANA considerations
Date: Fri, 28 Jul 2006 21:55:24 GMT
Lines: 47
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23437
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1156 IANA considerations
Date: Fri, 28 Jul 2006 21:58:02 GMT
Lines: 37
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23454
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1313 Newsgroups and reserved characters
Date: Sat, 29 Jul 2006 21:21:01 GMT
Lines: 43
Sender: [email-masked]

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

>Harald Alvestrand <harald@xxxxxxxxxxxxx>:

>> 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 MUST NOT be used otherwise.

>Since the restriction on future creation of groups is only SHOULD NOT,
>you now have a situation where new groups with digit-only or uppercase
>names can be created but MUST NOT be accessable. This needs to be either
>SHOULD NOT or MUST NOT throughout.

Yes, I think John is right here. To be consistent, it should be "SHOULD
NOT be used otherwise".

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

>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. For example, a server might choose to offer filtered
and unfiltered versions of a newsgroup, using a '-' to indicate the
filtered one. In that case, it might be wise to insert Followup-To the
unfiltered group.

To: [email-masked]
Xref: clerew local.usefor:23441
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1312 LInes: This may be tricky.... suggested resolution
Date: Fri, 28 Jul 2006 22:10:08 GMT
Lines: 36
Sender: [email-masked]

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

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

>Suggested resolution:

>Replace the last paragraph with:

>   The line count is the number of CRLF separators in the body.

Yes, that would do. The main intent of the original wording was to
emphasise that it really did mean the _whole_ body, hence the mention of
the things that people might be tempted not to count. A lot of systems
have been known to get it wrong through such misunderstandings.

To: [email-masked]
Xref: clerew local.usefor:23456
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1335 Injection-date
Date: Sat, 29 Jul 2006 21:39:59 GMT
Lines: 41
Sender: [email-masked]

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.

To: [email-masked]
Xref: clerew local.usefor:23440
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1310 Resolution "Approved" header field description
Date: Fri, 28 Jul 2006 22:03:44 GMT
Lines: 30
Sender: [email-masked]

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

>Current text of section:

>3.2.9.  Approved

>   Each mailbox contained in the Approved header field MUST be that of
>   one of the person(s) or entity(ies) in question, and one of those
>   mailboxes MUST be that of the actual sender of the article.  Note
>   that this standard does not provide any means to enforce or verify
>   this requirement, but future extensions or standards may provide such
>   a facility (e.g. digitial signatures).

>Suggested resolution:

>Delete the paragraph starting "Each mailbox...."

Disagree, for reasons stated in my reply to Russ. But some intermediate
wording should be possible.

To: [email-masked]
Xref: clerew local.usefor:23439
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Date: Fri, 28 Jul 2006 22:02:01 GMT
Lines: 27
Sender: [email-masked]

> [distribution]
>> two-letter country names drawn from [ISO.3166.1988].
> [...] 
>> Comments?

>The CS disaster was after 1988.  Does that mean we inherit it,
>or is ISO.3166.1988 meant as frozen state of those in practice
>irrelevant distribution codes ?  Or do we decide this later in
>USEPRO ?

Is there an update of [ISO.3166.1988] that we should be referring to? Or
we could add "... or any extension of it".

To: [email-masked]
Xref: clerew local.usefor:23438
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1299 Suggested resolution
Date: Fri, 28 Jul 2006 21:59:23 GMT
Lines: 22
Sender: [email-masked]

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

>> Generate: An agent is said to "generate" a construct if it did not
>> exist before the agent generated it.
>                         ^^^^^^^^^
>That doesn't sound right.

>Generate: An agent is said to "generate" a construct if it was not
>provided to the agent as input, but emanates from the agent.

Yes, Seth's wording, or something derived from it, is better. Otherwise OK.

To: [email-masked]
Xref: clerew local.usefor:23455
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1315 Definition of "poster"
Date: Sat, 29 Jul 2006 21:26:43 GMT
Lines: 30
Sender: [email-masked]

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

>Discussion shows that analogy creates debate, and I don't see that it 
>contributes anything.
>Suggested resolution:

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

>Comments?

Well it could be weakened. '...to a "user agent" (cf. the term "author" in
[RFC2822]). But no big deal either way.

From: Russ Allbery <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1315 Definition of "poster"
Organization: The Eyrie
Date: Fri, 28 Jul 2006 16:29:48 -0700
Sender: [email-masked]

>> The poster is analogous to an [RFC2822] author.
>  [...]
>> Discussion shows that analogy creates debate

> That's also the case for mail (last seen in DKIM), and "what
> does From: xyz mean" is an important detail.

I'd rather keep the comparison, but don't have a strong opinion.

> Does that explain the deserts of "Sender != Poster" ?  We need
> it for Followup-To: poster among others, and then we want the
> same behaviour as in mail:

The "poster" in Followup-To: poster is not the same thing as the poster as
used elsewhere in the document.  "poster" in that case indicates the
Reply-To or From address, not the person making the post.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1334 Path and case sensitivity
Organization: The Eyrie
Date: Fri, 28 Jul 2006 16:28:04 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> Existing text:

>   NOTE: Although case-insensitive, it is intended that the <path-
>   keyword>s should be in upper case, to distinguish them from the
>   <path-identity>s which are traditionally in lower case.

> This refers to the idea that the path-diagnostics

>  !.MISMATCH.1.2.3.4!
>  !.Mismatch.1.2.3..4!
>  !.mismatch.1.2.3.4!

> should all be interpreted the same; when the keywords were given as ABNF
> constants (like "MISMATCH") in the ABNF grammar, this was implicit in the
> ABNF rules, and I think we've had discussions on this before without
> changing them.

> Nothing here speaks to the case-sensitivity of other path components.

> I suggest "no change". Comments?

I think it's really annoying to have the keywords be case-insensitive from
an implementation standpoint when the rest of the Path header is
case-sensitive and has been in implementations for years.  It's probably
not a big deal, but it's annoying, and I don't see what the gain is.

Date: Fri, 28 Jul 2006 13:47:20 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

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

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

> User agent has no way of knowing. The only thing it can do is assume
> that the user knows, and that means that when the user presses 'f'
> to followup, or any other command that generates an otherwise
> prohibited component, the user agent has to assume that agreement
> exists. Since this is no different than any other situation, there
> is no reason to even mention it.

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

Seth

Date: Fri, 28 Jul 2006 09:44:07 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

On Fri, 28 Jul 2006, Harald Alvestrand wrote:

> No, you have it the wrong way around.
> SHOULD NOT = don't use it if you don't know what you're doing.
> The MAY identifies one case where you have to use it - access to existing 
> group.
> The MUST NOT coves the rest of the cases, including newsgroup creation.

Then there is no use for the SHOULD NOT's. You are putting special 
requirements on the user who accesses known existing groups -- why should
he have to think twice about going to alt.2600 every time he does?

>> How does the user agent know if a "private prior agreement" exists?
> Because it's entered into the private prior agreement. How that's done is 
> their own business.

I've seen a lot of strange things come out of this group, but a user agent
that enters into private agreements is just too silly.

>>Just where would a user agent generate said components in the first 
>>place? Is moving a newsgroup name from a Followup-To to the Newsgroups 
>>header field "generating"? (It would seem to be, since the Followup-To 
>>causes the existing Newsgroups to be discarded and a new one generated.) 
>>Is the mere existance of a Followup-To in the parent proof of the 
>>"private prior agreement" that allows the user agent to generate an 
>>otherwise prohibited "component". I don't think so.

>Me neither. But that's outside the scope of the standard.

If we are putting a MUST NOT on a certain activity, then we certainly
are making that activity within the scope of this standard, and are
making an implicit requirement for the software author to be able to
detect such conditions.

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.

User agent has no way of knowing. The only thing it can do is assume that
the user knows, and that means that when the user presses 'f' to followup,
or any other command that generates an otherwise prohibited component,
the user agent has to assume that agreement exists. Since this is no 
different than any other situation, there is no reason to even mention it.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Default value for the Archive header
Date:  Fri, 28 Jul 2006 09:43:36 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

Harald Alvestrand wrote:

> messages in Sarbanes-Oxley mandated archives

Oops, in another browser window I was just about to ask Google
what it knows about "SOX" (because Scott K. mentioned it on
the general list), now you gave me an idea how to refine this
query...
 [some minutes later]
...how's that related to what I post as an unpaid volunteer ?

> "+1" messages that can be deemed to have "no creative
> content" and so forth.  This is Yet Another Minefield.

Yes, please make "Archive: No" a minefield as much as possible.

If you can't strike this vague "wish to" between "does not" and
"permit" add an adverb like "explicitly" / "clearly".  It's not
that I suddenly like wishful thinking in a technical document,
but "does not wish to permit" sounds too obviously irrelevant.

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Date:  Fri, 28 Jul 2006 10:24:30 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 42
Sender: [email-masked]

Harald Alvestrand wrote:

> a reasonable interpretation is that it refers to the list of
> currently valid country codes.

Fine.

> If we want to nitpick ourselves to death on this issue

Not really.

> we can adopt relevant language from LTRU.

"Alpha-2 region codes of the BCP 47 subtag registry" (instead
of referencing "ISO.3166.1988") is an alternative to avoid any
conflicts forever, but for "Distribution" we want the _actual_
codes, not the old CS or DD or BU or other long dead codes.

> Or we can leave it alone.

What I really wanted to say:  LTRU managed to use the _actual_
3066 in the BCP 47 references:

| [ISO3166-1] International Organization for Standardization,
| "ISO 3166-1:1997. Codes for the representation of names of
| countries and their subdivisions -- Part 1: Country codes",
| 1997.

This "1997" is better than "1988" in USEFOR.  The used XML is:

~~~ cut ~~~
<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>
~~~ end ~~~

That should be ready for copy and paste into USEFOR-09.

Date: Fri, 28 Jul 2006 00:37:50 -0700
From: Harald Alvestrand <[email-masked]>
To: Seth Breidbart <[email-masked]>
Cc: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

Seth Breidbart wrote:
>>   <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.
>>     
>
> So if a user agent incorrectly believes there's a private prior
> agreement, it generates such a component.  The server knows that
> there's no such agreement, but it can't reject on that basis?  That
> doesn't seem right; I'd say that in the absence of such an agreement,
> such names SHOULD NOT be accepted by the news server.
>   
the idea (as I understood others' explanation of previous debates in the 
group, about a year ago) is to be able to create groups with special 
semantics, interpreted by clients, and perhaps acted upon in special 
ways by servers that are part of the experiment, which nevertheless get 
passed along just like ordinary groups by "old" servers - allowing the 
participants in the experiment to get a predictable behaviour from 
newsservers that are not part of the experiment.

Search for #1021 in the archive, June 2005.

I'm not a great fan of the thing myself - the document would be one 
paragraph shorter if we just removed the whole idea and made the ABNF 
say that these chars are not permitted. But I didn't see any reason to 
challenge a consensus of the WG that predated my involvement, and my 
judgment of consensus a year ago was that the WG wanted to retain it.

                             Harald

Date: Fri, 28 Jul 2006 03:23:26 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Default value for the Archive header
Sender: [email-masked]

Harald Alvestrand <[email-masked]> wrote:

> After having suffered through excessive reviews of the terms of
> "copyright" in IPR and in other fora, I believe "wish to" is
> correct, because the poster frequently has no legal right to decide
> one way or the other, and the only way to discover whether he has
> the right or not is to drag the case into a court of law.

I don't permit redistribution.

I might not have the legal ability to _prevent_ redistribution, but I
still don't _permit_ it.

That is, I (the poster) am not granting permission for ("permitting")
redistribution.  You might have the legal right, or even obligation,
to redistribute it anyway.

So I think "the poster does not permit redistribution" is better,
though I agree that it doesn't make any actual difference.

Seth

Date: Fri, 28 Jul 2006 03:20:37 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

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

So if a user agent incorrectly believes there's a private prior
agreement, it generates such a component.  The server knows that
there's no such agreement, but it can't reject on that basis?  That
doesn't seem right; I'd say that in the absence of such an agreement,
such names SHOULD NOT be accepted by the news server.

Seth

Date: Fri, 28 Jul 2006 08:32:54 +0200
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1311 Default value for the Archive header
Sender: [email-masked]

Frank Ellermann wrote:
> Harald Alvestrand wrote:
>
>  [old]
>   
>> the poster does not permit redistribution
>>     
>  [new]
>   
>> the poster does not wish to permit redistribution
>>     
>  [...]
>   
>> Comments?
>>     
>
> I'd like it better without "wish to" for the "no" case.  And as
> noted elsewhere "long term" covers "permanent", you could get
> rid of "or permanent".
After having suffered through excessive reviews of the terms of 
"copyright" in IPR and in other fora, I believe "wish to" is correct, 
because the poster frequently has no legal right to decide one way or 
the other, and the only way to discover whether he has the right or not 
is to drag the case into a court of law.

Examples include the mandatory-by-law storing of newsgroups in national 
history archives, retention of messages in Sarbanes-Oxley mandated 
archives, deletion of messages by company policy under Sarbanes-Oxley, 
fair use, reposting of others' messages, "+1" messages that can be 
deemed to have "no creative content" and so forth.

This is Yet Another Minefield.

Date: Fri, 28 Jul 2006 08:28:29 +0200
From: Harald Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Sender: [email-masked]

Frank Ellermann wrote:
> Harald Alvestrand wrote:
>
>  [distribution]
>   
>> two-letter country names drawn from [ISO.3166.1988].
>>     
>  [...] 
>   
>> Comments?
>>     
>
> The CS disaster was after 1988.  Does that mean we inherit it,
> or is ISO.3166.1988 meant as frozen state of those in practice
> irrelevant distribution codes ?  Or do we decide this later in
> USEPRO ?
ISO 3166.1988 includes procedures for updating, so a reasonable 
interpretation is that it refers to the list of currently valid country 
codes.
If we want to nitpick ourselves to death on this issue (no big news 
here), we can adopt relevant language from LTRU.
Or we can leave it alone.

Date: Fri, 28 Jul 2006 08:26:02 +0200
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

[email-masked] wrote:
>
>
> Harald Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> 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 MUST NOT be used otherwise.
>
> Since the restriction on future creation of groups is only SHOULD NOT,
> you now have a situation where new groups with digit-only or uppercase
> names can be created but MUST NOT be accessable. This needs to be either
> SHOULD NOT or MUST NOT throughout.
No, you have it the wrong way around.
 SHOULD NOT = don't use it if you don't know what you're doing.
The MAY identifies one case where you have to use it - access to 
existing group.
The MUST NOT coves the rest of the cases, including newsgroup creation.
>
>   <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.
>
> How does the user agent know if a "private prior agreement" exists?
Because it's entered into the private prior agreement. How that's done 
is their own business.
> Just
> where would a user agent generate said components in the first place? 
> Is moving a newsgroup name from a Followup-To to the Newsgroups header
> field "generating"? (It would seem to be, since the Followup-To causes
> the existing Newsgroups to be discarded and a new one generated.) Is
> the mere existance of a Followup-To in the parent proof of the "private
> prior agreement" that allows the user agent to generate an otherwise 
> prohibited "component". I don't think so.
Me neither. But that's outside the scope of the standard.

Date: Fri, 28 Jul 2006 08:00:58 +0200
From: Harald Alvestrand <[email-masked]>
To: Richard Clayton <[email-masked]>
Cc: [email-masked]
Subject: Re: #1313 Resolution of 2.2 - syntax for USENET articles
Sender: [email-masked]

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <[email-masked]>, Harald Alvestrand
> <[email-masked]> writes
>
>   
>> NEW:
>>
>>  The syntax allowed for news
>>  article headers is a strict subset of the "Internet Message Format" 
>> headers, making
>>  all headers compliant with this specification inherently compliant
>>  with [RFC2822].  Note however that the converse is not guaranteed to
>>  be true in all cases.
>>     
>
> /headers/header fields/
>   
In this particular case, "headers" is correct - we're talking about the 
entire header for all messages.

Of course, the sentence would be true if we said "header fields" too.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1309 Supersedes and Distribution
Date:  Fri, 28 Jul 2006 08:00:04 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Sender: [email-masked]

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Archive
Date:  Fri, 28 Jul 2006 07:39:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Sender: [email-masked]

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1315 Definition of "poster"
Date:  Fri, 28 Jul 2006 07:07:38 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 28
Sender: [email-masked]

Harald Alvestrand wrote:

> The poster is analogous to an [RFC2822] author.
 [...]
> Discussion shows that analogy creates debate

That's also the case for mail (last seen in DKIM), and "what
does From: xyz mean" is an important detail.

> I don't see that it contributes anything.

It says that it's (almost) exactly the same mess as in mail.

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

Does that explain the deserts of "Sender != Poster" ?  We need
it for Followup-To: poster among others, and then we want the
same behaviour as in mail:  Send replies to Reply-To if it's
there, otherwise send replies to one or more From-addresses,
don't use any Sender or Approved address not included in the
Reply-To / From.

IMO the mail analogy is helpful.  

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1313 Resolution of 2.2 - syntax for USENET articles
Date:  Fri, 28 Jul 2006 06:39:15 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Sender: [email-masked]

Richard Clayton wrote:
 
> /headers/header fields/

In that paragraph the text could talk about complete "headers".

We're not interested in "non Internet Message Format" header 
fields, whatever that might be.  Are you sure that you prefer
"header fields" here ?

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1312 LInes: This may be tricky.... suggested resolution
Date:  Fri, 28 Jul 2006 06:30:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 7
Sender: [email-masked]

Harald Alvestrand wrote:

 [count CRLFs to get Lines]
> Comments?

+1

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1311 Default value for the Archive header
Date:  Fri, 28 Jul 2006 06:25:16 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Harald Alvestrand wrote:

 [old]
> the poster does not permit redistribution
 [new]
> the poster does not wish to permit redistribution
 [...]
> Comments?

I'd like it better without "wish to" for the "no" case.  And as
noted elsewhere "long term" covers "permanent", you could get
rid of "or permanent".

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Date:  Fri, 28 Jul 2006 06:12:48 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

Harald Alvestrand wrote:

 [distribution]
> two-letter country names drawn from [ISO.3166.1988].
 [...] 
> Comments?

The CS disaster was after 1988.  Does that mean we inherit it,
or is ISO.3166.1988 meant as frozen state of those in practice
irrelevant distribution codes ?  Or do we decide this later in
USEPRO ?

Bye, Frank

Date: Thu, 27 Jul 2006 16:38:55 -0700
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1313 Resolution of 2.2 - syntax for USENET articles
Sender: [email-masked]

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

>NEW:
>
>  The syntax allowed for news
>  article headers is a strict subset of the "Internet Message Format" 
>headers, making
>  all headers compliant with this specification inherently compliant
>  with [RFC2822].  Note however that the converse is not guaranteed to
>  be true in all cases.

/headers/header fields/

>Comments?

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

Date: Thu, 27 Jul 2006 16:50:49 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Default value for the Archive header
Sender: [email-masked]

[email-masked] wrote:

> 
> Harald Alvestrand <harald@xxxxxxxxxxxxx>:
> 
> 
>>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 wish to permit
>    redistribution from publicly accessible long-term or permanent archives.
> 
> When I use X-No-Archive: yes, the intent is not related to redistribution,
> it is the archiving itself. My desire it to prohibit archiving in
> long-term archives. (Long-term covers "permanent", does it not?)

USEPRO has no mandatory language regarding this field, so
"not wish to permit" is about as meaningless as can be.

Maybe the true wanted meaning is closer to "wishes to not permit."

If you observe Usenet today, by volume, chances are the poster has no copyright 
interest in what they post without permission, so their permission to archive is 
humorous.

This discussion already happened, and ended in controversy, if I recall.  So, 
I'd suggest this....

Descriptive language belongs in USEPRO. For USEFOR, I think the least you can 
say is....

     The Archive header field indicates the poster's preference for long-term
     archiving.

And our grandchildren can nitpick this item again in USEPRO.

Is it April 2005 yet?

Date: Thu, 27 Jul 2006 12:07:47 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1311 Default value for the Archive header
Sender: [email-masked]

Harald Alvestrand <harald@xxxxxxxxxxxxx>:

>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 wish to permit
   redistribution from publicly accessible long-term or permanent archives.

When I use X-No-Archive: yes, the intent is not related to redistribution,
it is the archiving itself. My desire it to prohibit archiving in
long-term archives. (Long-term covers "permanent", does it not?)

Date: Thu, 27 Jul 2006 12:05:08 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1313 Newsgroups and reserved characters
Sender: [email-masked]

Harald Alvestrand <harald@xxxxxxxxxxxxx>:

> 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 MUST NOT be used otherwise.

Since the restriction on future creation of groups is only SHOULD NOT,
you now have a situation where new groups with digit-only or uppercase
names can be created but MUST NOT be accessable. This needs to be either
SHOULD NOT or MUST NOT throughout.

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

How does the user agent know if a "private prior agreement" exists? Just
where would a user agent generate said components in the first place? 
Is moving a newsgroup name from a Followup-To to the Newsgroups header
field "generating"? (It would seem to be, since the Followup-To causes
the existing Newsgroups to be discarded and a new one generated.) Is
the mere existance of a Followup-To in the parent proof of the "private
prior agreement" that allows the user agent to generate an otherwise 
prohibited "component". I don't think so.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1336 Expires field semantics
Organization: The Eyrie
Date: Thu, 27 Jul 2006 11:02:52 -0700
Sender: [email-masked]

> Suggested change, indicating that the field is the desire of the poster:

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

>  The way in which this interacts with local retention policy on servers is
>  a local matter.

> Comments?

I prefer the original, although wouldn't mind the addition of the "poster"
bit.  I think the second sentence could be added to everything in the
standard; I don't think there's much point.

Date: Thu, 27 Jul 2006 11:07:39 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: Harald Alvestrand <[email-masked]>, [email-masked]
Subject: Re: #1335 Injection-date
Sender: [email-masked]

Harald Alvestrand wrote:
> Current text (omitting the comments about MUST, which are in closed 
> issue #1088):
> 
> 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.
> 
>  Ralph Babel said:
> 
> 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?

Using Injection-date to prevent re-injection as described in USEPRO
depends that all agents work as described and never alter or remove
the header.  This is not robust, and I don't see how it offers significant 
improvement over Date:.

There is language that an "injecting agent" receiving a message with an 
injection-date, SHOULD cause the message to be relayed.

USEPRO is not germane at the momenet, but all the distinctions of "agent"
are meaningless and not helpful.  The way that INN relays messages
is to accept them.  It sends messages from the same storage as they exist
for reading.

So USEPRO in 7.2 says that INN, as the injecting agent, "SHOULD cause [the
message] to be relayed" (note no mention of rejecting stale Injecting dates).

And in 7.2.2. #3 it says an injecting agent MUST reject any article with such a 
field, except when re-injecting. (Which is a meaningless tautology, I suppose.)

Then in 7.3 #2 it says that INN, as relaying agent, MUST examine Injection-Date:
and reject as stale if that predates the local cutoff.

So, USEPRO states "SHOULD cause to be relayed" + "MUST reject" for those
stale injection-dates.

Right.  Who thought this scheme through?

Again....

Chair, we are chartered to conclude ALL OF THIS, USEPRO TOO, by April 2005.

How can we be continuing?

Date: Thu, 27 Jul 2006 02:03:31 -0700
From: Harald Alvestrand <[email-masked]>
To: Harald Alvestrand <[email-masked]>
Cc: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Admin: Resolution of WG Last Call comments
Sender: [email-masked]

Harald Alvestrand wrote:
> When looking back over the tally, I identified 3 groups:
>
> - The document should be sent to the IESG
> - The effort should be abandoned; if not abandoned, we should put the 
> document on hold
> - The document should be put on hold.
>
> The last group consisted of you.
correction: you and one other.

Date: Thu, 27 Jul 2006 01:58:32 -0700
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: Admin: Resolution of WG Last Call comments
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Harald Alvestrand <[email-masked]> writes:
>
>   
>> Based on the results from the Last Call, I'm removing the option of 
>> putting the document on hold while waiting for USEPRO to complete.
>>     
>
> The 'votes' on that issue were rather evenly balanced. There was hardly
> consensus on the matter of whether to put it on hold, whereas I believe
> we could achieve a consensus that the document was as complete as we could
> make it at the present time.
>   
When looking back over the tally, I identified 3 groups:

- The document should be sent to the IESG
- The effort should be abandoned; if not abandoned, we should put the 
document on hold
- The document should be put on hold.

The last group consisted of you.
> In the meantime, since there are no technical issues outstanding on
> USEFOR, is it in order to proceed with constructive discussion of USEPRO?
> If so, some comments on my suggested texts for handling Paths, which I
> published some weeks back, would be a good start.
>
>   
Let's get this one out of the way.

Date: Thu, 27 Jul 2006 01:55:44 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: End of tickets
Sender: [email-masked]

I think I have sent out a suggestion for resolution on all the tickets 
that remain open after the Last Call.

If we can resolve these quickly, we can get to the second WG Last Call 
and (perhaps) get this document done.

                   Harald

Date: Thu, 27 Jul 2006 01:53:27 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1156 Header field registrations
Sender: [email-masked]

The Author/Change controller field needs to be filled out.

This is an IETF standard.

I think the only sensible field for Author/Change controller is "IETF" - 
that doesn't mean that the IETF defined it first, it means that the IETF 
is asserting change control of the registration in the IANA registry.

Apart from that, I think the last round of comments are more-or-less 
editorial, and can be handled by the editor.

OK?

Date: Thu, 27 Jul 2006 01:50:35 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1336 Expires field semantics
Sender: [email-masked]

 > effects are implementation/configuration-specific?

Suggested change, indicating that the field is the desire of the poster:

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

  The way in which this interacts with local retention policy on servers is
  a local matter.

Comments?

Date: Thu, 27 Jul 2006 01:45:20 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1335 Injection-date
Sender: [email-masked]

Current text (omitting the comments about MUST, which are in closed 
issue #1088):

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.

 > "Date" header field has been added locally by the client.

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?

                       Harald

Date: Thu, 27 Jul 2006 01:09:08 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1334 Path and case sensitivity
Sender: [email-masked]

Ralph Babel claims that path-preloading needs to be mentioned in section 5.
This may refer to security considerations; I think, however, that this 
is more likely to belong in USEPRo.

Or "send text".

 > individual components is.

Existing text:

   NOTE: Although case-insensitive, it is intended that the <path-
  keyword>s should be in upper case, to distinguish them from the
   <path-identity>s which are traditionally in lower case.

This refers to the idea that the path-diagnostics

  !.MISMATCH.1.2.3.4!
  !.Mismatch.1.2.3..4!
  !.mismatch.1.2.3.4!

should all be interpreted the same; when the keywords were given as ABNF 
constants (like "MISMATCH") in the ABNF grammar, this was implicit in 
the ABNF rules, and I think we've had discussions on this before without 
changing them.

Nothing here speaks to the case-sensitivity of other path components.

I suggest "no change". Comments?

                           Harald

Date: Thu, 27 Jul 2006 00:59:23 -0700
From: Harald Alvestrand <[email-masked]>
To: Harald Alvestrand <[email-masked]>
Cc: [email-masked]
Subject: #1314 not #1313 Newsgroups and reserved characters
Sender: [email-masked]

Mistyped the ticket number, sorry.

Harald Alvestrand wrote:
>
> Existing text:
>
>   A newsgroup component SHOULD NOT consist of digits only, and SHOULD
>   NOT contain uppercase letters.  Such components MAY be used only to
>   refer to existing groups that do not conform to this naming scheme.
>
>      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 MUST NOT be generated by user
>   agents (whether in Newsgroups header fields or in newgroup control
>   messages [I-D.ietf-usefor-usepro]).  However, such names MUST be
>   accepted by news servers.
>
>   <component>s beginning with "+" and "-" are reserved for private use
>   and MUST NOT be generated by user agents (whether in Newsgroups
>   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.
>
> Proposed new text - clarifying that "may only" means MAY + MUST NOT,
> and making it clear that restriction applies to all header fields, not 
> just Newsgroups:
>
>   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 MUST 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 MUST 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.
>
>   <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.
>
> WRT whether user agents should accept or not:
> I think user agents are free to accept or reject these components at 
> will; the standard
> shouldn't have a need to say anything about that. So being silent is 
> good.
>
> Comments?
>
>
>
>

Date: Thu, 27 Jul 2006 00:58:44 -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.

Discussion shows that analogy creates debate, and I don't see that it 
contributes anything.
Suggested resolution:

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

Comments?

Date: Thu, 27 Jul 2006 00:54:48 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1313 Newsgroups and reserved characters
Sender: [email-masked]

Existing text:

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

      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 MUST NOT be generated by user
   agents (whether in Newsgroups header fields or in newgroup control
   messages [I-D.ietf-usefor-usepro]).  However, such names MUST be
   accepted by news servers.

   <component>s beginning with "+" and "-" are reserved for private use
   and MUST NOT be generated by user agents (whether in Newsgroups
   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.

Proposed new text - clarifying that "may only" means MAY + MUST NOT,
and making it clear that restriction applies to all header fields, not 
just Newsgroups:

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

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

WRT whether user agents should accept or not:
I think user agents are free to accept or reject these components at 
will; the standard
shouldn't have a need to say anything about that. So being silent is good.

Comments?

Date: Thu, 27 Jul 2006 00:44:26 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1313 Resolution of 2.2 - syntax for USENET articles
Sender: [email-masked]

Ralph Babel thinks that we need to make note of MIME in this section.

MIME is described in the next section (2.3), which deals explicitly with 
MIME conformance.
I suggest that rather than mixing MIME into 2.2, we modify section 2.2 
so that it ONLY deals with headers.

I suggest the following change to section 2.2:

OLD:

   The syntax allowed for news
   articles is a strict subset of the "Internet Message Format", making
   all messages compliant with this specification inherently compliant
   with [RFC2822].  Note however that the converse is not guaranteed to
   be true in all cases.

NEW:

   The syntax allowed for news
   article headers is a strict subset of the "Internet Message Format" 
headers, making
   all headers compliant with this specification inherently compliant
   with [RFC2822].  Note however that the converse is not guaranteed to
   be true in all cases.

Comments?

Date: Thu, 27 Jul 2006 02:10:16 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1299 Suggested resolution
Sender: [email-masked]

Harald Alvestrand <[email-masked]> wrote:

> I'd use "created by" rather than "emanates from", but that's because
> I rarely use the word "emanate", and suspect others might find it
> strange too.

That's fine; I just want the distinction to be "It didn't exist until
the agent outputted it."

Seth

Date: Thu, 27 Jul 2006 07:51:32 +0200
From: Harald Alvestrand <[email-masked]>
To: Seth Breidbart <[email-masked]>
Cc: [email-masked]
Subject: Re: #1299 Suggested resolution
Sender: [email-masked]

Seth Breidbart wrote:

>>Generate: An agent is said to "generate" a construct if it did not
>>exist before the agent generated it.
>>    
>>
>                         ^^^^^^^^^
>That doesn't sound right.
>
>Generate: An agent is said to "generate" a construct if it was not
>provided to the agent as input, but emanates from the agent.
>
>  
>
I'd use "created by" rather than "emanates from", but that's because I 
rarely use the word "emanate", and suspect others might find it strange too.

But of course defining "generate" in terms of "generate" is a no-no....

Date: Wed, 26 Jul 2006 21:16:26 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1299 Suggested resolution
Sender: [email-masked]

> Generate: An agent is said to "generate" a construct if it did not
> exist before the agent generated it.
                         ^^^^^^^^^
That doesn't sound right.

Generate: An agent is said to "generate" a construct if it was not
provided to the agent as input, but emanates from the agent.

Seth

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1312 LInes: This may be tricky.... suggested resolution
Organization: The Eyrie
Date: Wed, 26 Jul 2006 14:29:42 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> Suggested resolution:

> Replace the last paragraph with:

>   The line count is the number of CRLF separators in the body.

> The whole field is obsolete anyway, so we shouldn't waste that many
> bytes on it.

Yup, sounds fine to me.  The language there currently stresses how the
field is formed, but in practice the field is formed a variety of
different ways (some of which are completely wrong) and one can't trust
that any particular algorithm is used.  Given that, I'd rather just say
the simplest possible thing about what the field is supposed to have and
let its deprecation stand as a comment on the weirdness of how it's
derived.

Date: Wed, 26 Jul 2006 14:20:46 -0700
From: Harald Alvestrand <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked]
Subject: Re: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Sender: [email-masked]

Russ Allbery wrote:
> In general, I agree with deferring this for USEPRO; I think that's what
> happens as a result of our split.  However, the one part that does still
> bother me is the "predefined" part on this.
>
> I think what we're really trying to say is:
>
>     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.
>
> That gets into the definition of "local" to some degree, but it's just one
> sentence and stating that (fairly general) sentence seems better to me
> than replacing it with a reference to USEPRO.
>
> The above wording avoids introducing the term "predefined."
>
>   
I like that.

                 Harald

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Default value for the Archive header
Organization: The Eyrie
Date: Wed, 26 Jul 2006 14:18:59 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> 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 wish to permit
>   redistribution from publicly accessible long-term or permanent
>   archives.  A field body of "yes" indicates that the poster wishes to
>   permit such redistribution.  No parameters have been defined so far;
>   if present, they can be ignored.

Looks good to me.

Date: Wed, 26 Jul 2006 14:18:41 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1312 LInes: This may be tricky.... suggested resolution
Sender: [email-masked]

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

Unfortunately I don't think the two are equivalent - and my guess would 
be that Ralph's version is more likely to be true than the long 
versionm, but if you check out 2822 section 3.5, you'll find that the body

  One line of text<CRLF>

actually has two productions of *998text in it (the last being empty). 
But I think it has one line.

Suggested resolution:

Replace the last paragraph with:

   The line count is the number of CRLF separators in the body.

The whole field is obsolete anyway, so we shouldn't waste that many 
bytes on it.

Comments?

                    Harald

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Organization: The Eyrie
Date: Wed, 26 Jul 2006 14:08:00 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> The current text of this section is:

> 3.2.7.  Distribution

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

>   distribution    =  "Distribution:" SP dist-list CRLF

>   dist-list       =  *WSP dist-name
>                      *( [FWS] "," [FWS] dist-name ) *WSP

>   dist-name       =  ALPHA / DIGIT
>                      *( ALPHA / DIGIT / "+" / "-" / "_" )

>   The <dist-name>s "world" and "local" are predefined.  However,
>   "world" SHOULD NOT be used explicitly, since it is the default when
>   the Distribution header field is absent entirely.

In general, I agree with deferring this for USEPRO; I think that's what
happens as a result of our split.  However, the one part that does still
bother me is the "predefined" part on this.

I think what we're really trying to say is:

    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.

That gets into the definition of "local" to some degree, but it's just one
sentence and stating that (fairly general) sentence seems better to me
than replacing it with a reference to USEPRO.

The above wording avoids introducing the term "predefined."

Date: Wed, 26 Jul 2006 14:03:19 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1311 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 wish to permit 
redistribution
   from publicly accessible long-term or permanent archives.
   A field body of "yes" indicates that the poster wishes to permit such
   redistribution.

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

(note - ignoring unknown parameters is probably a requirement if 
parameters are
ever going to be deployed on this. So it makes sense to say how to treat 
them here.)

Comments?

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1310 Resolution "Approved" header field description
Organization: The Eyrie
Date: Wed, 26 Jul 2006 14:01:38 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> Current text of section:

> 3.2.9.  Approved

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

>   approved        =  "Approved:" SP mailbox-list CRLF

>   Each mailbox contained in the Approved header field MUST be that of
>   one of the person(s) or entity(ies) in question, and one of those
>   mailboxes MUST be that of the actual sender of the article.  Note
>   that this standard does not provide any means to enforce or verify
>   this requirement, but future extensions or standards may provide such
>   a facility (e.g. digitial signatures).

> Suggested resolution:

> Delete the paragraph starting "Each mailbox...."

Agreed.

We're going to get real security here, if we ever do manage to deploy
something other than PGPMoose, by adding a digital signature.  At the
point that such a thing exists, the Approved header will be irrelevant for
sites that can verify the digital signature and we can deal with
verification of identity as part of developing that signature protocol.
In the meantime, changes to Approved that still don't add real security
aren't a step in the right direction; the right direction will involve
doing something completely different.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1299 Suggested resolution
Organization: The Eyrie
Date: Wed, 26 Jul 2006 13:58:11 -0700
Sender: [email-masked]

Harald Alvestrand <[email-masked]> writes:

> I believe that it's not unreasonable to close #1299 (Richard Clayton's
> comments) with the following substantial change:

> Add to 1.5:

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

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

> The editorial issues have already been taken care of; the generic comment
> that "it is a mess" is not something that I think we can address within a
> reasonable amount of time at this stage.

> Good enough?

Looks good to me.  And I think this is a very useful clarification.

Date: Wed, 26 Jul 2006 13:50:18 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1310 Resolution "Approved" header field description
Sender: [email-masked]

Current text of section:

3.2.9.  Approved

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

   approved        =  "Approved:" SP mailbox-list CRLF

   Each mailbox contained in the Approved header field MUST be that of
   one of the person(s) or entity(ies) in question, and one of those
   mailboxes MUST be that of the actual sender of the article.  Note
   that this standard does not provide any means to enforce or verify
   this requirement, but future extensions or standards may provide such
   a facility (e.g. digitial signatures).

Suggested resolution:

Delete the paragraph starting "Each mailbox...."

Date: Wed, 26 Jul 2006 13:47:51 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1309 resolution "no change" suggested - USEFOR 3.2.7 - Distribution header field needs more description
Sender: [email-masked]

The current text of this section is:

3.2.7.  Distribution

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

   distribution    =  "Distribution:" SP dist-list CRLF

   dist-list       =  *WSP dist-name
                      *( [FWS] "," [FWS] dist-name ) *WSP

   dist-name       =  ALPHA / DIGIT
                      *( ALPHA / DIGIT / "+" / "-" / "_" )

   The <dist-name>s "world" and "local" are predefined.  However,
   "world" SHOULD NOT be used explicitly, since it is the default when
   the Distribution header field is absent entirely.

   "All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain
   at least three characters, except when they are two-letter country
   names drawn from [ISO.3166.1988]. <dist-name>s are case-insensitive
   (i.e.  "US", "Us", "uS", and "us" all specify the same distribution).

   [FWS] in the <dist-list> SHOULD NOT be generated, but MUST be
   accepted.

Ralph's comment was

3.2.7.  Distribution
|

Where? In which way?

I suggest to resolve this by "no change" - the details belong in USEPRO, 
they're not part of the article format. We could add Yet Another pointer 
to USEPRO, but I don't see a value in that - we already have 10 forward 
pointers to it.

Comments?

Date: Wed, 26 Jul 2006 13:40:05 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1305 suggested resolution 3.1.6 Path - NOTE to explain diag-deprecated
Sender: [email-masked]

I think Charles Lindsey's suggested addition was uncontroversial:

 > NOTE: Although , <IPv4address>es have occasionally been used in
 > the past (usually with a diagnostic intent), their continued use
 > is deprecated (though it is still acceptable in the form of the
 > <diag-deprecated>).

Unless I hear objection, this is adopted.

Date: Wed, 26 Jul 2006 13:37:47 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1299 Suggested resolution
Sender: [email-masked]

I believe that it's not unreasonable to close #1299 (Richard Clayton's 
comments) with the following substantial change:

Add to 1.5:

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

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

The editorial issues have already been taken care of; the generic 
comment that "it is a mess" is not something that I think we can address 
within a reasonable amount of time at this stage.

Good enough?

                 Harald

Date: Wed, 26 Jul 2006 13:07:47 -0700
From: Harald Alvestrand <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked]
Subject: Re: #1310 Approved
Sender: [email-masked]

                 Harald

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1156 IANA considerations
Organization: The Eyrie
Date: Wed, 26 Jul 2006 10:10:31 -0700
Sender: [email-masked]

Date: Wed, 26 Jul 2006 08:55:14 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1156 IANA considerations
Sender: [email-masked]

Date: Wed, 26 Jul 2006 00:42:18 -0700
From: Harald Alvestrand <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked]
Subject: Re: #1156 IANA considerations
Sender: [email-masked]

                   Harald

Date: Wed, 26 Jul 2006 00:36:59 -0700
From: Harald Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Subject: Re: #1314 Newsgroup-names
Sender: [email-masked]

                      Harald

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1156 IANA considerations
Organization: The Eyrie
Date: Tue, 25 Jul 2006 21:27:40 -0700
Sender: [email-masked]

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1311 Archive
Organization: The Eyrie
Date: Tue, 25 Jul 2006 21:26:52 -0700
Sender: [email-masked]

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1310 Approved
Organization: The Eyrie
Date: Tue, 25 Jul 2006 21:19:11 -0700
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23378
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1088 Injection-Date
Date: Tue, 25 Jul 2006 21:02:29 GMT
Lines: 66
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23381
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1309 Supersedes and Distribution
Date: Tue, 25 Jul 2006 21:23:11 GMT
Lines: 67
Sender: [email-masked]

No, Supersedes.

To: [email-masked]
Xref: clerew local.usefor:23383
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1311 Archive
Date: Tue, 25 Jul 2006 21:54:22 GMT
Lines: 62
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23382
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1310 Approved
Date: Tue, 25 Jul 2006 21:32:41 GMT
Lines: 40
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23377
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1314 Newsgroup-names
Date: Tue, 25 Jul 2006 20:46:11 GMT
Lines: 89
Sender: [email-masked]

As above.

Yes.

To: [email-masked]
Xref: clerew local.usefor:23379
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1335 NNTP-Posting-Date
Date: Tue, 25 Jul 2006 21:08:32 GMT
Lines: 37
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23384
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1156 IANA considerations
Date: Tue, 25 Jul 2006 22:06:58 GMT
Lines: 82
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23380
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1336 Expires (Note)
Date: Tue, 25 Jul 2006 21:11:43 GMT
Lines: 27
Sender: [email-masked]

Date: Tue, 25 Jul 2006 17:44:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: #1298 -> 1305, 1306 + rejections and calls for comment  (Re: Issue #1298 - Charles' niggles)
Sender: [email-masked]

Charles Lindsey wrote:

>In <[email-masked]> Alexey Melnikov <[email-masked]> writes:
>  
>
>>Charles Lindsey wrote:
>>    
>>
>>>Yes it is clearer, but it is bad practice to use RFC 2119 language in
>>>NOTEs except where it is merely reinforcing normative material written
>>>elsewhere. In this case, the "SHOULD NOT" is contrary to the general "MUST
>>>NOT alter what is already present", as written at many places into USEPRO.
>>>I would have no problewm with MUST NOT here.
>>>      
>>>
>>>>I've made this ticket #1306.
>>>>        
>>>>
>>I've seen nobody objecting to this change.
>>Ken applied the proposed text, so the ticket is now closed.
>>    
>>
>Which proposed text? If you mean with the "MUST NOT", then fine.
>  
>
Yes.

To: [email-masked]
Xref: clerew local.usefor:23376
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1315 poeter/author/sender
Date: Tue, 25 Jul 2006 12:10:53 GMT
Lines: 32
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23375
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1298 -> 1305, 1306 + rejections and calls for comment (Re: Issue #1298 - Charles' niggles)
Date: Tue, 25 Jul 2006 12:03:54 GMT
Lines: 29
Sender: [email-masked]

>>Yes it is clearer, but it is bad practice to use RFC 2119 language in
>>NOTEs except where it is merely reinforcing normative material written
>>elsewhere. In this case, the "SHOULD NOT" is contrary to the general "MUST
>>NOT alter what is already present", as written at many places into USEPRO.
>>I would have no problewm with MUST NOT here.
>>  
>>
>>>I've made this ticket #1306.
>>>    
>>>
>I've seen nobody objecting to this change.
>Ken applied the proposed text, so the ticket is now closed.

Which proposed text? If you mean with the "MUST NOT", then fine.

Date: Mon, 24 Jul 2006 18:34:38 +0100
From: Alexey Melnikov <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: #1298 -> 1305, 1306 + rejections and calls for comment  (Re: Issue #1298 - Charles' niggles)
Sender: [email-masked]

Charles Lindsey wrote:

>>>Issue 1298.C
>>>------------
>>>      
>>>
>>>>3.2.1.  Injection-Date
>>>>
>>>>      NOTE: Since clocks on various agents may not be synchronized, the
>>>>      <date-time> in this header field may not be later than the Date
>>>>      header field, as would be expected.  Agents SHOULD use the <date-
>>>>      time> they believe is correct when adding Inject-Info but SHOULD
>>>>      NOT alter the pre-existing Date header field.
>>>>
>>>>        
>>>>
>I think s/SHOULD NOT/MUST NOT/. There is one obscure situation (see USEPRO
>7.8) where a moderator may rewrite the Date, but then I don't think a
>moderator is an "agent" as we have defined the term.
>  
>
>>>>    
>>>>        
>>>>
>>The 07 version of the NOTE was:
>>    
>>
>>    NOTE: The <date-time> in this header field would normally be
>>     expected to be later than the <date-time> in the Date header
>>     field, but differences between the clocks on the various agents
>>     and other special circumstances might vitiate that; no provision
>>     is made for any such discrepancy to be corrected - better that the
>>     news server should just insert the correct time as it sees it.
>>    
>>
>>I think the 08 version is a lot clearer in what it says, but introduces 
>>protocol requirements where -07 was clearly just commentary.
>>    
>>
>Yes it is clearer, but it is bad practice to use RFC 2119 language in
>NOTEs except where it is merely reinforcing normative material written
>elsewhere. In this case, the "SHOULD NOT" is contrary to the general "MUST
>NOT alter what is already present", as written at many places into USEPRO.
>I would have no problewm with MUST NOT here.
>  
>
>>I've made this ticket #1306.
>>    
>>
I've seen nobody objecting to this change.
Ken applied the proposed text, so the ticket is now closed.

Date: Sat, 22 Jul 2006 21:59:30 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Issue #1300 - Ralph's niggles
Sender: [email-masked]

3 more tickets:

1334 USEFOR: Path preloading and Path components case sensitivity

1335 USEFOR: description of Injection-Date purpose is not precise

1336 USEFOR 3.2.4: Additional description of Expires header field

Date: Sat, 22 Jul 2006 21:57:40 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-usefor-usefor-08
Sender: [email-masked]

[...]

Both.

Created ticket # 1314.

Created new ticket #1335

Created new ticket #1336

Replace?

New ticket # 1311.

[...]

[...]

Date: Sat, 22 Jul 2006 21:03:57 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Issue #1300 - Ralph's niggles
Sender: [email-masked]

Charles Lindsey wrote:

>There were other items that I did not accept for various reasons. May I
>suggest to Ralph that he produces a list of the ones that he still wants
>to be considered, as I have just done in the case of my own list.
>  
>
Ralph didn't produce a list. So I've created the following tickets:

1309 USEFOR 3.2.7 - Distribution header field needs more description

1310 USEFOR 3.2.9 - Approved header field description

1311 USEFOR 3.2.12 - Default value for the Archive header field 
(copyright issue)

1312 USEFOR 3.3.1 - Description of Lines header field can be much shorter

1313 USEFOR 2.2 - syntax for Usenet Articles: RFC 2822 + MIME

1314 USEFOR 3.1.5 - Definition of Newsgroups header field is not precise

1315 USEFOR - definition of "poster"

Date: Sat, 22 Jul 2006 21:05:09 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Issue #1300 - Ralph's niggles
Sender: [email-masked]

Alexey Melnikov wrote:

> Charles Lindsey wrote:
>
>> There were other items that I did not accept for various reasons. May I
>> suggest to Ralph that he produces a list of the ones that he still wants
>> to be considered, as I have just done in the case of my own list.
>
> Ralph didn't produce a list. So I've created the following tickets:
>
> 1309 USEFOR 3.2.7 - Distribution header field needs more description
>
> 1310 USEFOR 3.2.9 - Approved header field description
>
> 1311 USEFOR 3.2.12 - Default value for the Archive header field 
> (copyright issue)
>
> 1312 USEFOR 3.3.1 - Description of Lines header field can be much shorter
>
> 1313 USEFOR 2.2 - syntax for Usenet Articles: RFC 2822 + MIME
>
> 1314 USEFOR 3.1.5 - Definition of Newsgroups header field is not precise
>
> 1315 USEFOR - definition of "poster"

I've also reopened 1156: USEFOR Appendix: IANA registration forms for 
headers

To: [email-masked]
Xref: clerew local.usefor:23368
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1300 was Admin: Resolution of WG
Date: Thu, 13 Jul 2006 16:11:16 GMT
Lines: 47
Sender: [email-masked]

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

>[email-masked] wrote:
>> 
>> 
>>> | A newsgroup may be "moderated", in which case submissions
>>> | are not posted directly, but mailed to a "moderator" for
>>> | consideration and possible posting. Moderators are
>>> | typically human but may be implemented partially or
>>> | entirely in software.
>> 
>>> The word "moderated" occurs only once,
>>> in the "Approved" section.
>> 
>> Moderators are ALWAYS human.
>> 
>> Suggested replacement text:
>> 
>> A newsgroup may be "moderated". Articles are not posted directly to a 
>> moderated group, but are submitted (usually by email) to one or more 
>> moderators for approval and eventual posting. Some moderators have 
>> implemented automated systems to help them perform this function.

>FWIW, I (as editor) am in favor of the replacement text.  Setting aside 
>the "human" argument, can anyone make an argument that the new text is 
>fundamentally wrong?

Neither text is fundamentally wrong, and in any case both are just trying
to give a brief introduction to a topic upon which you need to go to
USEPRO to see all the gory details.

Text #1 underestimates the humanity of the moderator
(s/tpyically/generally/ would help). Text #2 overestimates it. It is no
huge deal either way, but I prefer #1 over #2. Change the last sentence of
#2 to "Moderators often set up automated systems to perform part or all of
their task." and I will be happy.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1300 was Admin: Resolution of WG
Date:  Thu, 13 Jul 2006 17:57:17 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Ralph Babel wrote:

> try the following _technical_ _description_ instead

Possible.  Make sure that I'm still entiteled to (try to)
approve my own cancel messages for articles claiming to
be "from" me whenever I feel like it.

Bye, Frank

From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Date: Thu, 13 Jul 2006 07:36:00 +0200 (CEST)
Sender: [email-masked]

Harald Alvestrand suggested:

> A newsgroup may be "moderated". Articles are not posted
> directly to a moderated group, but are submitted (usually
> by email) to one or more moderation addresses for approval
> and eventual posting.

As Richard already pointed out, the entire terminology
is completely fuzzy and inconsistent. When Joe A. User's
client connects to port 119 and sends an article without
"Approved" header field to a "moderated" group, is it
"submitted"? "posted"? "injected"? "generated"? What if
a moderator does - after having included an "Approved"
header field? What about server-to-server communication?

What a total mess!

The word "moderated" occurs only once, in the "Approved"
section. So simply get rid of it in the list of definitions.
If you really insist on retaining something like the current
definition, try the following _technical_ _description_
instead:

| A news server typically will not forward to other news
| servers articles destined for at least one newsgroup
| locally marked as "moderated" unless an Approved header
| field is included. Articles without Approved header field
| received by such a news server are typically e-mailed
| to a so-called "moderator" (the e-mail address of which
| is configured locally) if and only if that article has
| been received directly from the sender. If not received
| directly from the sender, articles without an Approved
| header field destined for a moderated newsgroup MUST NOT
| be forwarded to the "moderator"; such articles are
| typically discarded.

Gee, folks, it's not rocket science - once you cut the
political crap. (See my Last Call comments regarding
the current "author"/"sender"/"poster" fuck-up.)

Can we disband now, please?

Date: Wed, 12 Jul 2006 23:58:21 +0200
From: Harald Alvestrand <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

Ken Murchison wrote:
>
> [email-masked] wrote:
>>
>>> The word "moderated" occurs only once,
>>> in the "Approved" section.
>>
>> Moderators are ALWAYS human.
>>
>> Suggested replacement text:
>>
>> A newsgroup may be "moderated". Articles are not posted directly to a 
>> moderated group, but are submitted (usually by email) to one or more 
>> moderators for approval and eventual posting. Some moderators have 
>> implemented automated systems to help them perform this function.
>
> FWIW, I (as editor) am in favor of the replacement text.  Setting 
> aside the "human" argument, can anyone make an argument that the new 
> text is fundamentally wrong?
>
If we are not ready to declare consensus on whether or not moderators 
are human, I would prefer......

   A newsgroup may be "moderated". Articles are not posted directly to a 
moderated group, but are submitted (usually by email) to one or more
   moderation addresses for approval and eventual posting.

(there may be a better word than "moderation address" somewhere in the 
documents).

That describes the function - that articles to moderated groups go 
"elsewhere", not directly to the group - but doesn't attempt to get into 
the space of defining what the process is that has to exist when it gets 
there, or to what degree humans are involved. The discussion has shown 
that this varies widely.

                   Harald

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Organization: The Eyrie
Date: Wed, 12 Jul 2006 14:50:10 -0700
Sender: [email-masked]

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

>> Suggested replacement text:

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

> FWIW, I (as editor) am in favor of the replacement text.  Setting aside
> the "human" argument, can anyone make an argument that the new text is
> fundamentally wrong?

Looks fine to me.

Date: Wed, 12 Jul 2006 16:30:01 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

[email-masked] wrote:
> 
> 
>> | A newsgroup may be "moderated", in which case submissions
>> | are not posted directly, but mailed to a "moderator" for
>> | consideration and possible posting. Moderators are
>> | typically human but may be implemented partially or
>> | entirely in software.
> 
>> The word "moderated" occurs only once,
>> in the "Approved" section.
> 
> Moderators are ALWAYS human.
> 
> Suggested replacement text:
> 
> A newsgroup may be "moderated". Articles are not posted directly to a 
> moderated group, but are submitted (usually by email) to one or more 
> moderators for approval and eventual posting. Some moderators have 
> implemented automated systems to help them perform this function.

FWIW, I (as editor) am in favor of the replacement text.  Setting aside 
the "human" argument, can anyone make an argument that the new text is 
fundamentally wrong?

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

Date: Wed, 12 Jul 2006 15:10:28 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

[email-masked] wrote:

> The rest of the world is operating as if the moderator is a human
> who sometimes has software doing part or all of the work for him.

Consider the statement: "The rest of the world is operating as if the
moderator is a program that automagically determines whether or not
and when to post the article, perhaps with modifications."

How can I determine which of those is the case based on the actions of
"the rest of the world"?

> This paragraph does not define what a moderator is. It says only
> that he is "typically" a human, when in real life he is always a
> human. Someone is always responsible. Someone picks what code to
> run.

So a dead human can be a moderator.  So can a committee.  A committee
is not a human.

Seth

Date: Wed, 12 Jul 2006 14:51:25 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

[email-masked] wrote:
  This paragraph does not define what a moderator is. It
> says only that he is "typically" a human, when in real life he is always a 
> human. Someone is always responsible. Someone picks what code to run. The 
> fact that you do not see him on a daily basis does not mean he does not 
> exist any more than your dissappearance for weeks at a time means you do 
> not exist.

/+1

A moderator cannot be software anymore than "some computer" can post UCE.  ["Oh,
so sorry, but that computer just keeps posting all that UCE, and our hands
are tied, you know...."]

Hey, since you want to elevate the moderator's implementation choices up
into the document, can the wording state that the injecting server sends posts 
for approval to the spam filter of the moderator, or the user-agent of the 
moderator, or the MSA at the address of the moderator?  Surely the moderator
uses most of those.

And since it is possible to set up a newsgroup and let their dog approve or 
reject submissions, should the document mention that?

OK, now for some "big picture" criticism of this farce....

Typically, this "WG" (by that I mean Charles) has produced volumes of text just 
like this, which describes the design from the bottom-up.  This style makes the 
reasons you want to do something hard to discern.

While I am bothering to write, this bottom-up vs top-down is why issuing 
USEFOR-USEFOR before USEFOR-USEPRO makes little sense to me.

Suppose some group (of people) were to design a messaging system, and needed to 
specify procedures for handling all communication, error conditions, protocol, 
etc.....Do you suppose they would publish the message format specification 
first, and then hold the rest of the design to be subject to those details?

Sigh.  bottoms-up, all.  Any implementor trying to use a document
produced by this WG is going to want to start with a good stiff drink.

Date: Wed, 12 Jul 2006 08:54:00 -0700 (PDT)
From: [email-masked]
To: Harald Alvestrand <[email-masked]>
cc: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

On Wed, 12 Jul 2006, Harald Alvestrand wrote:

> Stanley,

Alvestrand?

> you insist on using your own definitions rather than trying to get the 
> document to have consistent and useful definitions.

Nonsense. I'm looking at the real world. I call that "useful".

> The document currently says "articles are forwarded to a moderator".
> If the moderator can be a software program, we have one self-consistent 
> definition of "moderator".

And if we don't say anything about what the moderator is, we still
have a self-consistent definition of moderator, especially since we
have no definition of moderator at all.

I'll say this again since saying it once didn't seem to sink in and 
actually reading the text doesn't seem to be an option. The text I 
proposed says NOTHING AT ALL about what a moderator is, it only removes a 
patently silly claim that a moderator is only "typically" a human.

If it is acceptable to say "articles are forwarded to a moderator" then
it is just as acceptable to say "articles are submitted" to them, since
your "forwarding" is just another way of saying they are "submitted", and
the latter emphasizes that they are submissions and not necessarily
acceptable.

> If the moderator is human, but may never get sent most of the articles, as 
> you seem to imply,

I made no such implication. You didn't read the proposed text, did you? It 
says that articles ARE submitted to "one or more moderators". That is 
hardly an implication that they may never get sent most of the articles. 
There is no other option in the proposed text. Articles ARE submitted.
What other option do you see my text allowing?

Now, just as in real life, the moderator might not SEE every article,
but he is SENT every article; otherwise, his automated software would
not be able to approve and post it.

> we have another self-consistent definition, but the 
> sentence that is currently in the document is not consistent with it.

This is an interesting argument style. We cannot change a statement in
the draft because changing it would make it inconsistent with what was
already there.

In any case, you are wrong. It is not inconsistent at all. If you want to 
continue with an odd, unrealistic definition of moderator that has it 
being some self-aware bit of software that makes decisions all by itself, 
fine. Articles are submitted to "it". Maybe "it" has written other 
software to automate the process. After all, if it is conscious enough to 
produce itself without human oversight, then maybe it can produce other 
software. Nothing in the proposed texts prevents that.

The rest of the world is operating as if the moderator is a human who 
sometimes has software doing part or all of the work for him. If you want 
a realistic description, that's the direction you'll go. But then, as I 
said several times already, my proposed text does not mandate the human 
status of a moderator. Any objection you have to my proposed text based on 
it mandating that moderators are human just demonstrates that you didn't 
bother reading either the proposed text or the message to which you have 
just replied.

> I suggest that we're much better off with the current document's definition 
> of "moderator" than with your implied one.

I suggest you read the proposed text for what it actually says and stop
objecting to things it doesn't say. You're the chair of this group;
I expect at least YOU to read what is written.

As for the current document's definition of moderator, I find none. The 
word "moderator" appears exactly twice in -08, both times in the paragraph 
under discussion. This paragraph does not define what a moderator is. It 
says only that he is "typically" a human, when in real life he is always a 
human. Someone is always responsible. Someone picks what code to run. The 
fact that you do not see him on a daily basis does not mean he does not 
exist any more than your dissappearance for weeks at a time means you do 
not exist.

In the same vein, my proposed text does nothing to define what a moderator
is. Of course, if you actually read the text, you'd see that. It's a silly
argument to claim that I'm defining "moderator" in a non-consistent manner
when neither paragraph defines moderator to start with.

Date: Wed, 12 Jul 2006 14:45:16 +0200
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

[email-masked] wrote:
>
>
> Harald Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> I've seen mailing lists gatewayed to Netnews where the "moderator" 
>> was set to be the mailing list - the result was that all messages 
>> posted to the newsgroup were sent to the mailing list, and eventually 
>> came back to the newsgroup. No human moderator anywhere in sight.
>
> The moderator was the person who set up that configuration; and as I 
> said in the suggested text: some moderators have implemented automated 
> systems. You've just provided one example. The fact that you don't see 
> him
> on a daily basis does not mean he does not exist. I don't see you on a 
> daily basis; do YOU not exist?
Stanley,

you insist on using your own definitions rather than trying to get the 
document to have consistent and useful definitions.

The document currently says "articles are forwarded to a moderator".
If the moderator can be a software program, we have one self-consistent 
definition of "moderator".

If the moderator is human, but may never get sent most of the articles, 
as you seem to imply, we have another self-consistent definition, but 
the sentence that is currently in the document is not consistent with it.

I suggest that we're much better off with the current document's 
definition of "moderator" than with your implied one.

                  Harlad

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1300 was Admin: Resolution of WG
Date:  Wed, 12 Jul 2006 06:42:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Russ Allbery wrote:

> there isn't any inherent reason why some hierarchy couldn't
> have a central automated moderation service in which the
> software works the same for every group.  Indeed, the linux.*
> hierarchy is essentially that case.

Slightly abusing the term "hierarchy", all gmane.* articles
have Approved: [email-masked] when _read_ on GMaNe.  Including
anything I read in gmane.ietf.usenet.format

A special case, readers are supposed to know when to contact
GMane administrators, and when to discuss issues with the list
owners, and how to debug it.

It can get rather interesting if the list software changes its
behaviour, and nobody incl. the list owner expected problems
wrt MAIL FROM = Sender (GMane, subscribed) != From (poster, not
subscribed).

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: WG Last Call: draft-ietf-usefor-usefor-08
Date:  Wed, 12 Jul 2006 05:52:32 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1298 -> 1305, 1306 + rejections and calls for comment
Date:  Wed, 12 Jul 2006 04:08:33 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

Charles Lindsey wrote:

> It was originally Frank Ellerman's example in the form of
>         sender="\"Joe Q. Public\" <[email-masked]"
> designed to show the complexities of quotes within quotes.
> It's no big deal whether it goes in or not.

> BTW, where is Frank these days?

Spent some time on Mediawiki.  "No big deal" for putting quoted
text into quoted text in an example is okay.  With 108 unread
messages here I might miss some detail, I hope nobody's going
to use %22 instead of \" for this case.

> The reference to Son-of-1036 would be informative only (the
> paragraphs in question were merely explaining some history)
> But I won't press the point.

If USEFOR sits in the RFC editor queue waiting for USEPRO, and
s-o-1036 makes it in time, this nit could be trimmed in the
final AUTH48 clean up.

Bye, Frank

Date: Mon, 3 Jul 2006 12:52:48 -0700 (PDT)
From: [email-masked]
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

Harald Alvestrand <harald@xxxxxxxxxxxxx>:

>I've seen mailing lists gatewayed to Netnews where the "moderator" was set 
>to be the mailing list - the result was that all messages posted to the 
>newsgroup were sent to the mailing list, and eventually came back to the 
>newsgroup. No human moderator anywhere in sight.

The moderator was the person who set up that configuration; and as I 
said in the suggested text: some moderators have implemented automated 
systems. You've just provided one example. The fact that you don't see him
on a daily basis does not mean he does not exist. I don't see you on a 
daily basis; do YOU not exist?

>This document shouldn't try to mandate a human in the loop.

Non-sequitor. Nothing in my suggested text mandates anything. Did you
even bother to read it before you objected?

Here's the executive summary for the executive who is too busy to read the 
full text: I object to the text "Moderators are typically human". Period. 
Moderators are ALWAYS human. I suggested simple replacement text that 
solves that problem. It mandates nothing, it changes nothing other than 
removes an objectionable statement. It makes no reference to moderators
either being or not being human. What is your objection to that, if you
have one?

Seth Breidbart <sethb@xxxxxxxxx>:

>Even when the RFD and CFV say that the group will be robomoderated,
>and it is?

Yes. Even when there is a human in charge of a piece of software that
automates an approval. "Some moderators have implemented automated 
systems...".

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>I think the original text more accurately reflects reality. That wording
>has been around for more years than I care to remember, and it is odd that
>John has just noticed this.

I objected to this text before, and I'm objecting to it again while it is 
still open for discussion.  I did not "just notice this", despite your 
lie to the contrary, and I object formally to the Chair that you are 
bring ad-hominem back into the group at this point. Either support the 
text as it stands or argue the suggested text as it stands, but keep
your crap about "odd" and who proposed it to yourself.

The existing text does not reflect reality. Moderators aren't "typically"
human, they are always human.

>I could accept some intermediate wording (e.g. s/typically/usually/ (or
>'generally').

Since you are not the editor of this document, you will accept what the
group decides. I tired of your attempts at monarchy over this document a
long time ago, and I have tired of your attempted lies even before that.

Russ Allbery <rra@xxxxxxxxxxxx>:

>Hm, well, this is certainly true from the perspective of Big Eight policy,
>but there isn't any inherent reason why some hierarchy couldn't have a
>central automated moderation service in which the software works the same
>for every group.

I am simply fascinated by the number of people in this working group who
appear to think that software comes into existance sans any human action
or supervision.

I neither care about nor does my suggested text prohibit in any way a 
hierarchy that appoints one person to be the moderator for all the 
moderated groups within it, or even a hierarchy created by one person who 
claims moderator status over all his domain. If that person runs a piece 
of software to assist him in doing his job, I neither care nor does my 
suggested text prohibit it. If that person sets up the software and then 
goes on an extended vacation, neither I nor my suggested text cares.

All my suggested text does is remove the silly claim that the moderator
is only "typically" human. Period.

>It's semantic quibbling to a degree since you can always then argue that
>the hierarchy administrator is the moderator.

Of course the moderator is a human. That's the point, Russ. It is stupid
to pretend that a human is not the moderator just because he uses a piece
of software to assist him. He is not "typically" a human.

Seth Breidbart <sethb@xxxxxxxxx>:

>Except that (1) no one person decided on the bot, the group (by vote)
>did.

I see. So the human who sets it up and runs it is no longer a human 
because the group voted? I think not.

The group selected a moderator who promised to run a bot. If you check
your USENET (and Big 8 especially) history, you will find it replete with
a) such examples and b) moderators who realize they have to change the way
things were voted on so the group can continue to operate. SSFAM is just
one big example. Moderation by bot -- until the system was proven to be
trivially breakable. It wasn't the "bot" that decided something was wrong,
it was the MODERATOR team -- all of whom are humans.

>(2) Who is "whoever controls the modbot"?

Anyone who controls how it operates, and who is called upon to fix it
when it breaks. Usually specified in the group creation process.

>One of the five people with access to that account?

Any one or more of the five, perhaps. Who gets called to fix it? Who is
responsible for moving the operation of the modbot when the system upon
which it runs is removed from service?

>Them plus the sysadmins of the site it runs on?

Was the system admin named as the moderator of the group, or in the list
of moderators? You are asking questions whose answers depend on the actual
group creation.

>Or just the owner of the site, who has the final say?

Is the owner of the site not a human? Are ANY of the people you asked 
about NOT humans? I don't have to tell you which of those people are the
moderator, since my only claim is that the moderator is human. Since they
are all human, any one of them fits that criterion. I don't care which.

And nothing in my propsed text cares which it is, either. All my proposed
text does is remove a patently silly statement that the moderator is only
"typically" a human. What's the big deal?

>(3) What happens if everybody who controls the bot goes away,
>and it keeps running just fine on autopilot?

Humans never die in your universe? Wow. And systems run forever without 
upgrades or replacements?

Or is it just that software in your universe configures itself by itself
and never needs a human to set it up or monitor its operation?

Date: Mon, 3 Jul 2006 19:23:00 +0100
To: Seth Breidbart <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

In message <[email-masked]>, Seth Breidbart
<[email-masked]> writes

>Can an active moderated
>group have no moderator?

alt.hackers used to be the canonical example ...  marked as moderated,
but anyone could post provided that they worked out how to do so

seems to still exist in that form...

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

Date: Mon, 3 Jul 2006 14:02:46 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

Graham Drabble <[email-masked]> wrote:
> On 03 Jul 2006 Seth Breidbart <[email-masked]> wrote in 
> news:[email-masked]:
>> 
>>> Moderators are ALWAYS human.
>> 
>> Even when the RFD and CFV say that the group will be robomoderated,
>> and it is?  (typically to prevent crossposts)
>
> Yes. The moderator is whoever controls the modbot. Being robomoderated 
> merely means the moderator has decided to let software do all the work.

Except that (1) no one person decided on the bot, the group (by vote)
did.  (2) Who is "whoever controls the modbot"?  One of the five
people with access to that account?  Them plus the sysadmins of the
site it runs on?  Or just the owner of the site, who has the final
say?  (3) What happens if everybody who controls the bot goes away,
and it keeps running just fine on autopilot?  Can an active moderated
group have no moderator?

Seth

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Organization: The Eyrie
Date: Mon, 03 Jul 2006 09:31:32 -0700
Sender: [email-masked]

Graham Drabble <[email-masked]> writes:
> Seth Breidbart <[email-masked]> wrote:

>>> Moderators are ALWAYS human.

>> Even when the RFD and CFV say that the group will be robomoderated,
>> and it is?  (typically to prevent crossposts)

> Yes. The moderator is whoever controls the modbot. Being robomoderated 
> merely means the moderator has decided to let software do all the work.

Hm, well, this is certainly true from the perspective of Big Eight policy,
but there isn't any inherent reason why some hierarchy couldn't have a
central automated moderation service in which the software works the same
for every group.  Indeed, the linux.* hierarchy is essentially that case.

It's semantic quibbling to a degree since you can always then argue that
the hierarchy administrator is the moderator.

To: [email-masked]
Xref: clerew local.usefor:23333
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1298 -> 1305, 1306 + rejections and calls for comment (Re: Issue #1298 - Charles' niggles)
Date: Fri, 23 Jun 2006 14:19:26 GMT
Lines: 162
Sender: [email-masked]

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

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

>> Issue 1298.A
>> ------------
>>
>>> 3.1.5.  Newsgroups
>>>
>As I said on the list, you performed the experiment yourself a year ago.
>I won't reopen #1042. Rejected.

The purpose of the experiment was to determine whether the
non-implementation of [FWS], known to be prevalent up to that time
(because no standard had ever required it) had perhaps begun to lift a
little. It hadn't.

I won't push the issue any further, but my protest remains.

>>
>>
>> Issue 1298.B
>> ------------
>>
>>   
>>> 3.1.6.  Path
>>>
>>>       NOTE: Although , <IPv4address>es have occasionally been used in
>>>       the past (usually with a diagnostic intent), their continued use
>>>       is deprecated (though it is still acceptable in the form of the
>>>       <diag-deprecated>).
>>>     
>>
>>   
>This is already a NOTE-rich paragraph, and I don't see any big harm in 
>adding another.

>I've made this ticket #1305.

I am in favour (naturally), and it seems that you are at least unopposed.

>> Issue 1298.C
>> ------------
>>
>>   
>>> 3.2.1.  Injection-Date
>>>
>>>       NOTE: Since clocks on various agents may not be synchronized, the
>>>       <date-time> in this header field may not be later than the Date
>>>       header field, as would be expected.  Agents SHOULD use the <date-
>>>       time> they believe is correct when adding Inject-Info but SHOULD
>>>       NOT alter the pre-existing Date header field.
>>>
I think s/SHOULD NOT/MUST NOT/. There is one obscure situation (see USEPRO
7.8) where a moderator may rewrite the Date, but then I don't think a
moderator is an "agent" as we have defined the term.
>>>     
>The 07 version of the NOTE was:

>     NOTE: The <date-time> in this header field would normally be
>      expected to be later than the <date-time> in the Date header
>      field, but differences between the clocks on the various agents
>      and other special circumstances might vitiate that; no provision
>      is made for any such discrepancy to be corrected - better that the
>      news server should just insert the correct time as it sees it.

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

Yes it is clearer, but it is bad practice to use RFC 2119 language in
NOTEs except where it is merely reinforcing normative material written
elsewhere. In this case, the "SHOULD NOT" is contrary to the general "MUST
NOT alter what is already present", as written at many places into USEPRO.
I would have no problewm with MUST NOT here.

>I've made this ticket #1306.
>>  
>>
>> Issue 1298.D
>> ------------
>>
>>   
>>> 3.2.14.  Injection-Info
>>>
>>>       mail-complaints-to=
>>>         "\"Re: msg <[email-masked]>\" <[email-masked]>"
>>>
>>>
>>>     
>Grumble. Making the examples as complex as possible doesn't seem like a 
>big benefit to me.

It was originally Frank Ellerman's example in the form of

	sender="\"Joe Q. Public\" <[email-masked]"

designed to show the complexities of quotes within quotes. It's no big
deal whether it goes in or not.

BTW, where is Frank these days?

>Anyone else who likes this?

>> Issue 1298.E
>> ------------
>>
>>   
>>> 3.2.14.  Injection-Info
>>>
>>>    Other <attribute>s SHOULD NOT be used unless defined in extensions to
>>>    this standard.  If non-standards-based <attribute>s are used, they
>>>    MUST begin with an "x-".
>>>
>>> That MUST conflicts with the SHOULD. How about:
>>>
>>>    Other <attribute>s MUST NOT be used unless defined in extensions to
>>>    this standard, or unless they begin with an "x-".
>>>     
>I don't see the conflict. SHOULD NOT, and if you violate the SHOULD NOT, 
>you MUST do this.

It has introduced, by implication, "SHOULD NOT use attributes starting
with "x-", which was not the intention. In -07 it was an implicit "MAY do
it" (with a proviso that it was for cases where the existing ones were
unsuited to your particular situation). My sentence is shorter, and
retains the -07 intent.

>>
>> Issue 1298.F
>> ------------
>>
>>   
>>> 3.3.  Obsolete Header Fields
>>>
>>> So I would suggest omitting the two paragraphs starting with:
>>>
>>>    Relay-Version contained ...
>>> and
>>>    Also-Control indicated ...
>>>
>>> and replacing them with a pointer to Son-of-1036...
>>   
>Introducing a dependency on son-of-1036 at this time would be extremely 
>unwise, in my opinion; the harm in including these two paragraphs is 
>minimal.

It does not introduce any dependency. The reference to Son-of-1036 would
be informative only (the paragraphs in question were merely explaining some
history). But I won't press the point.

To: [email-masked]
Xref: clerew local.usefor:23335
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1299 Richard Clayton's comments
Date: Fri, 23 Jun 2006 14:46:51 GMT
Lines: 47
Sender: [email-masked]

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

>In message <[email-masked]>, Harald Alvestrand
><[email-masked]> writes
>>
>>In reviewing Richard Clayton's comments, I find only one substantive 
>>issue: 

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

I think few people actually "see" it, in either news, mail or HTTP, unless
they are actively searching for some perceived anomaly in the message (and
that can equally happen in HTTP). OTOH, people investigating such
anomalies might wish to use a script to search out instances of the
problem, and having a fixed syntax to look for makes that easier.

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

I think the possibly needed pair was "generate" and "accept".

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

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

But I don't think we DO use different words for identical things (though
we do sometimes use broader and narrower classes; e.g. we speak of news
servers "injecting" and "relaying" things, and also of "processing" things
where the distinction between the two is irrelevant).

To: [email-masked]
Xref: clerew local.usefor:23334
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1299 Richard Clayton's comments
Date: Fri, 23 Jun 2006 14:35:50 GMT
Lines: 48
Sender: [email-masked]

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

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

I think it was "generate" and "accept" that perhaps needed defining,
because there are used frequently in the form "MUST accept X, but SHOULD
NOT generate it".

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

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

Or maybe:

An agent is said to "generate" some construct if it did not exist
previously, and to "accept" it if received from alsewhere (there
are many constructs which SHOULD NOT be generated but MUST be accepted if
they arrive).

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

No, that would be quite wrong. After "posting" an article might be passed
around all over the place behind some firewall (perhaps having some
company boilerplate added), only to be "injected" into the "Real" Usenet
when it finally leaves. We don't care what happens behind that firewall,
but we do care what happens when it is finally injected into Usenet. In
some strange and exceptional circumstances, it may even get injected
twice, but clearly it was only ever posted once.

To: [email-masked]
Xref: clerew local.usefor:23343
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1300 was Admin: Resolution of WG
Date: Mon, 3 Jul 2006 09:05:09 GMT
Lines: 37
Sender: [email-masked]

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

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

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

>Moderators are ALWAYS human.

>Suggested replacement text:

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

I think the original text more accurately reflects reality. That wording
has been around for more years than I care to remember, and it is odd that
John has just noticed this.

I could accept some intermediate wording (e.g. s/typically/usually/ (or
'generally').

To: [email-masked]
Xref: clerew local.usefor:23340
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Admin: Resolution of WG Last Call comments
Date: Thu, 29 Jun 2006 09:10:05 GMT
Lines: 25
Sender: [email-masked]

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

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

The 'votes' on that issue were rather evenly balanced. There was hardly
consensus on the matter of whether to put it on hold, whereas I believe
we could achieve a consensus that the document was as complete as we could
make it at the present time.

In the meantime, since there are no technical issues outstanding on
USEFOR, is it in order to proceed with constructive discussion of USEPRO?
If so, some comments on my suggested texts for handling Paths, which I
published some weeks back, would be a good start.

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

To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
From: Graham Drabble <[email-masked]>
Date: Mon, 03 Jul 2006 14:03:07 +0100
Organization: Home
Sender: [email-masked]

On 03 Jul 2006 Harald Alvestrand <[email-masked]> wrote in
news:[email-masked]: 

> 
> [email-masked] wrote:
>>
>>
>>> | A newsgroup may be "moderated", in which case submissions
>>> | are not posted directly, but mailed to a "moderator" for
>>> | consideration and possible posting. Moderators are
>>> | typically human but may be implemented partially or
>>> | entirely in software.
>>
>>> The word "moderated" occurs only once,
>>> in the "Approved" section.
>>
>> Moderators are ALWAYS human.
>>
>> Suggested replacement text:
>>
>> A newsgroup may be "moderated". Articles are not posted directly
>> to a moderated group, but are submitted (usually by email) to one
>> or more moderators for approval and eventual posting. Some
>> moderators have implemented automated systems to help them
>> perform this function. 
>>
>>
> Hm.
> 
> I've seen mailing lists gatewayed to Netnews where the "moderator"
> was set to be the mailing list 

No, the moderator submission address was the mailing list. The 
moderator was whoever controlled that list.

> - the result was that all messages
> posted to the newsgroup were sent to the mailing list, and
> eventually came back to the newsgroup. No human moderator anywhere
> in sight. 
> 
> This document shouldn't try to mandate a human in the loop.

The human doesn't have to be in the loop but they have to exist and 
ultimately are responsible if things go wrong.

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

To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
From: Graham Drabble <[email-masked]>
Date: Mon, 03 Jul 2006 14:01:56 +0100
Organization: Home
Sender: [email-masked]

On 03 Jul 2006 Seth Breidbart <[email-masked]> wrote in 
news:[email-masked]:

> 
>> Moderators are ALWAYS human.
> 
> Even when the RFD and CFV say that the group will be robomoderated,
> and it is?  (typically to prevent crossposts)

Yes. The moderator is whoever controls the modbot. Being robomoderated 
merely means the moderator has decided to let software do all the work.

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

Date: Mon, 3 Jul 2006 03:00:28 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

> Moderators are ALWAYS human.

Even when the RFD and CFV say that the group will be robomoderated,
and it is?  (typically to prevent crossposts)

Seth

Date: Sun, 02 Jul 2006 23:37:22 -0700
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: #1300 was Admin: Resolution of WG
Sender: [email-masked]

[email-masked] wrote:
>
>
>> | A newsgroup may be "moderated", in which case submissions
>> | are not posted directly, but mailed to a "moderator" for
>> | consideration and possible posting. Moderators are
>> | typically human but may be implemented partially or
>> | entirely in software.
>
>> The word "moderated" occurs only once,
>> in the "Approved" section.
>
> Moderators are ALWAYS human.
>
> Suggested replacement text:
>
> A newsgroup may be "moderated". Articles are not posted directly to a 
> moderated group, but are submitted (usually by email) to one or more 
> moderators for approval and eventual posting. Some moderators have 
> implemented automated systems to help them perform this function.
>
>
Hm.

I've seen mailing lists gatewayed to Netnews where the "moderator" was 
set to be the mailing list - the result was that all messages posted to 
the newsgroup were sent to the mailing list, and eventually came back to 
the newsgroup. No human moderator anywhere in sight.

This document shouldn't try to mandate a human in the loop.

                      Harald