Subject: Standardize Complaints-To as deployed?

From: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Oct 2004 21:03:36 +0100

Hi,
I would like to poll the WG about fate of the Complaints-To header.
I would ask people to voice their opinion about the following question: 
should Complaints-To be standardized as described in section 6.20 of 
draft-ietf-usefor-article-13.txt?

If the answer to this question is "yes", than it will be added to 
draft-ietf-usefor-usefor-01.txt. Otherwise I will reopen the discussion 
whether it should be an email address or an URL.

Thanks,
Alexey

---

From: Russ Allbery <[email-masked]>
Date: Mon, 04 Oct 2004 14:30:39 -0700

Alexey Melnikov <[email-masked]> writes:

> I would like to poll the WG about fate of the Complaints-To header.  I
> would ask people to voice their opinion about the following question:

> whether it should be an email address or an URL.

I don't believe it should be standardized as described there.

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

---

From: Henry Spencer <[email-masked]>
Date: Mon, 4 Oct 2004 17:35:40 -0400 (EDT)

> draft-ietf-usefor-article-13.txt?

6.20 of article-13 looks good to me, let's do it that way.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 05 Oct 2004 08:06:05 -0400

> draft-ietf-usefor-article-13.txt?

No.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 6 Oct 2004 23:25:54 GMT

>whether it should be an email address or an URL.

Yes.

But note that Complaints-To comes as a pair with Injection-Info.

Also, I would have no problem with a URL as an alternative, but _only_ if
that URL were limited to 'mailto'.

-- 
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: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Oct 2004 20:09:41 +0100

Alexey Melnikov wrote:

> I would ask people to voice their opinion about the following 
> question: should Complaints-To be standardized as described in section 
> 6.20 of draft-ietf-usefor-article-13.txt?
>
> draft-ietf-usefor-usefor-01.txt. Otherwise I will reopen the 
> discussion whether it should be an email address or an URL.

Could I ask people who answered "yes" to this question to list software 
that generates this header?

Thanks,
Alexey

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 19 Oct 2004 20:57:44 GMT

>that generates this header?

No software generates this header, but lots of software generates the
X-Complaints-To header (and for email too, I believe), which is
essentially identical (but we cannot standardize X-headers). No regular
agent needs to recognize it, but doubtless lots of people (spam fighters
and the like) have scripts which use it; It would be trivial to modify
such scripts to recognize Complaints-To alongside X-Complaints-To.

A similar relation exists between the new Archive header and the current
X-No-Archive header (but only Google actually uses this header, so far as
anyone knows, and there have been hints that Google would likely recognize
the new one alongside the old one).

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Oct 2004 18:04:56 +0200

Alexey Melnikov wrote:

> Could I ask people who answered "yes" to this question to
> list software that generates this header?

At the moment you'd only find X-Complaints-To: (used by many
news servers).  IMHO the idea is to get rid of the "X-" here.

                         Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: Standardize Complaints-To as deployed?
Date: Wed, 27 Oct 2004 18:04:56 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Alexey Melnikov wrote:

> Could I ask people who answered "yes" to this question to
> list software that generates this header?

At the moment you'd only find X-Complaints-To: (used by many
news servers).  IMHO the idea is to get rid of the "X-" here.

                         Bye, Frank

To: LIST: [email-masked];
Xref: clerew local.usefor:20241
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Standardize Complaints-To as deployed?
Date: Tue, 19 Oct 2004 20:57:44 GMT
Lines: 39
Sender: [email-masked]

To: "Usefor WG" <[email-masked]>
Subject: Header Table
Date: Tue, 19 Oct 2004 12:52:37 +0100
From: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

------------p274O9WLZJUvIFimG3INvK
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Our Chair has asked me to produce this table showing where the various  
Netnews headers are generated and where they are consumed. Hopefully, this  
may be useful in our discussions, and maybe it should evan appear as an  
Appendix in one of the drafts.

It needs to be viewed in a wide window, or in landscape if prented (there  
is a FF character at a suitable place).

-- 
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
------------p274O9WLZJUvIFimG3INvK
Content-Disposition: attachment; filename=header-use
Content-Type: application/octet-stream; name=header-use
Content-Transfer-Encoding: 8bit

				Table showing Generation and Consumption of Netnews Headers.
				------------------------------------------------------------

Notation
--------

G (C, U) indicate where the header is normally Generated (Checked[1], Used).
g (c, u) indicate where the header is occasionally generated (checked, used).

Header		poster	posting	inject-	relay-	serv-	reading	follow-	reply	reader	special	gateway	gateway	moder-	
			agent	ing	ing	ing	agent	up	agent		scripts	in	out	ator
		[2]	[2]	agent	agent	agent		agent			[3]			
-------------------------------------------------------------------------------------------------------------------------
Used in Transit
-------------------------------------------------------------------------------------------------------------------------

Message-ID	-	g	G	U	U	-	-	-	-	-	c/g	c	-
Newsgroups	G	g	C/U[4]	U	C/U	U	g[5]	-	u	-	G	-	U
Path		-	g[6]	G	U/G	U/G	-	-	-	-	-	-	-	C
Injection-Date	-	-	C/G	U	U	-	-	-	-	-	-	U	C
Distribution	G	g	-	U	U	u	g[5]	-	-	-	-	-	-
Control		G	-	-	u[7]	U	-	-	-	-	-	-	C	g
Approved	G	-	U[4]	u	U	-	-	-	-	-	-	-	G
Supersedes	G	-	-	u[7]	U	-	-	-	-	-	-	-	-
Expires		G	-	-	-	U	-	-	-	-	-	-	-	-

-------------------------------------------------------------------------------------------------------------------------
Used for Reading/Followup/Reply
-------------------------------------------------------------------------------------------------------------------------

>From		g	G	g	C/g	C	-	-	U	U	-	-	-	-
Reply-To	g	G	-	-	-	-	-	U	-	-	-	-	-
Followup-To	G	-	-	-	-	-	U	-	-	-	-	-	-
Mail-Copies-To	-	G	-	-	-	-	U	U	-	-	-	-	-
References	g	-	-	-	-	U	U/G	-	-	-	-	-	-
Xref		-	-	-	-	G	U	-	-	-	-	-	-	-
Content-*	G	G	g	-	-	U	-	-	-	-	U	U	-

Header		poster	posting	inject-	relay-	serv-	reading	follow-	reply	reader	special	gateway	gateway	moder-	
			agent	ing	ing	ing	agent	up	agent		scripts	in	out	ator
		[2]	[2]	agent	agent	agent		agent			[3]			
-------------------------------------------------------------------------------------------------------------------------
Used by humans and special scripts
-------------------------------------------------------------------------------------------------------------------------

Date		-	G	C[8]	C[8]	C[8]	u	-	-	U	-	g	U	c/g
Subject		G	-	C	-	C	u	g[5]	-	U	-	-	-	-
Sender		-	G	-	-	-	-	-	u	U	U	G	-	-
Organization	-	G	g	-	-	-	-	-	U	-	-	-	-
Keywords	G	-	-	-	-	-	-	-	U	U	-	-	-
Summary		G	-	-	-	-	-	-	-	U	-	-	-	-
Posted-And-	-	G	-	-	-	-	G	-	U	-	-	-	-
      Mailed
Archive		-	G	-	-	-	-	-	-	-	U	-	-	-
Lines		-	G	-	-	-	-	-	-	U	-	-	-	-
User-Agent	-	G	g	-	-	-	-	-	U	-	-	-	-
Injection-Info	-	-	C/G	-	-	-	-	-	u	U	-	-	C
Complaints-To	-	-	C/G	-	-	-	-	-	U	U	-	-	C

Notes
-----

[1]   Checking is usually just for the presence of absence of the header.

[2]   Shown under poster if a per-article affair;
      Shown under posting agent if normally set automatically/by configuration.

[3]   For operations not part of the normal duties of the regular agents, but which need to rely on the structure
      and semantics of the header. In addition. just about any header may be used in a killfile.

[4]   To detect moderated articles already approved.

[5]   Defaults set by followup agent.

[6]   Posting agent may set <tail-entry>.

[7]   For articles arriving later than their cancels. Also to ensure further propagation of group control messages.

[8]   For detecting >24 hours into the future, or when Injection-Date absent.

------------p274O9WLZJUvIFimG3INvK--

Date: Mon, 18 Oct 2004 20:09:41 +0100
From: Alexey Melnikov <[email-masked]>
To: ietf-usefor <[email-masked]>
Subject: Re: Standardize Complaints-To as deployed?
Sender: [email-masked]

Thanks,
Alexey

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Russ Allbery <[email-masked]>
Subject: Re: draft-ietf-usefor-usepro-01
Date: Sun, 17 Oct 2004 11:49:04 -0400
Cc: [email-masked]
Sender: [email-masked]

[Incidentally, the original was apparently sent only to the old mailing list
rather than the "new" (as of a couple of months ago) mailing list]

On Sat October 9 2004 14:36, you wrote:
> Kai Henningsen <[email-masked]> writes:
> 
> > That sounds to me like a very special case. It seems to me it's much
> > more likely that you have your peers send you, say, a certain subset of
> > the Big8, and you want to get all the Big8 control messages, not just
> > that subset, so you can decide what other groups you might be interested
> > in.
> 
> Note that this has never been possible for the Big Eight, and I've never
> heard a complaint about it.  You're the first person who I recall
> indicating that you'd prefer things be done that way, rather than only
> sending control messages according to normal newsgroup subscription
> patterns.
[...]
> (This is probably more detailed than we really need to cover in our
> documents, but it is a good argument in favor of not banning crossposting
> control messages.)

We probably need to cover more detail; let's start with examining
the pros and cons for the different types of control messages:

So far you folks have been discussing newgroup messages, but there
are other types.  The considerations vary based on the control
message type.

Cancels could safely be limited to the newsgroup subscription patterns
*assuming* that newsgroups are specified exactly the same on the
cancel as in the original, *and* further assuming that there have
been no changes to newsgroup hierarchies in the time interval
between posting of the original and cancel messages, *and*
still further assuming that no site has changed newsgroup feed
patterns in such a way (e.g. dropping newsgroups) that would
prevent a cancel message from reaching a system that had
received the original.  I suspect that in a small but significant
portion of cases, one or more of those assumptions would fail
to conform to reality.  I believe that the specific mechanism
specified in RFC 1036 is reasonable; viz. propagate widely
initially, stopping propagation to downstream sites unless the
original message had been received.

Rmgroup messages, the newfangled mvgroup messages, newgroup
and checkgroups messages should probably propagate everywhere.
Otherwise a site that gets its initial list of active newsgroups e.g.
via ftp from some source would not be kept up to date w.r.t.
changes in hierarchies (additions, renaming, removals, changes in
suggested moderation status) if upstream sites fail to propagate
relevant control messages when newsgroups directly affected
are not fed.  That in turn could affect downstrean sites that
subsequently get the out-of-date active newsgroup list from the
site in question, administrators and users of that site may be
unaware of changes to newsgroups of potential interest (e.g. for
finding an alternate upstream feed for new groups of interest),
and sites with out-of-date lists may unintentionally become
sources of problems (e.g. crossposts to "old" newsgroups that
have been removed or renamed).

Ihave and sendme control messages should only propagate one
hop regardless of newsgroup subscriptions.  Generally, pseudo-
newsgroups are set up by administrators to implement that, but
the rule should be specified; implementation details are just
that -- implementation details.

Sendsys control messages are intended to gather statistics
about connectivity and newsgroup distribution.  If limited to
newsgroup hierarchies, then gathered connectivity statistics
will obviously only represent a subset of sites to which the
control message propagates. That is probably A Bad Thing for
connectivity (as distinct from newsgroup propagation)
statistics. Causing those control messages to propagate widely
in order to gather more complete statistics requires crossposting
to a huge number of newsgroups, which would likely cause
some breakage (I suspect that some software would be unable
to handle a Newsgroups field listing 30,000 newsgrousp).
On the other hand, collecting newsgroup propagation
statistics could be achieved even if propagation of the control
message is limited; conversely if it is not limited the only
downside is the volume of the responses sent to the requestor.
I believe sendsys control messages should therefore
propagate everywhere, unless superseded by two distinct
types of control messages for the two specific purposes (viz.
connectivity in general, and specific newsgroup hierarchy
propagation).

Version control messages are intended to gather statistics on
transport/spooling software, and is likely only to be of use to
a requestor if reasonably complete (e.g. to definitively answer
the question "is anybody still running B news 2.11?").  It
should therefore propagate widely (i.e. independently of
newsgroups).

Other considerations:

Since different types of control messages are handled differently
and affect different agents in different ways, we should probably
consider whether a long term split of the catch-all Control field
would be worth planning for (i.e. while keeping the catch-all
Control field name tag with a separate "verb" in the field for
the moment, advising implementors that at some future date
there may well be separate fields to facilitate the different
types of propagation and the different handling by different
agents).

Date: Tue, 12 Oct 2004 08:58:32 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-usefor <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked];
Subject: Re: Issues with MIME-style parameters
Sender: [email-masked]

Charles Lindsey wrote:

> The remark concerning the Path header was totally peripheral to the
> substance of what my message was about. I note that you have made no
> response to that substance.

Yet.  As you took more than a month to respond to the original
message, don't be so quick to note responses.  At the moment, I
have many far more important things to do than to respond to
imaginary "substance" in your self-contradictory ramblings.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: Usefor/usepro conflicts.
Date: Sat, 09 Oct 2004 10:22:35 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 33
Sender: [email-masked]

Charles Lindsey wrote:

> In the oft-quoted case where the Boss gets his Secretary to
> send the message, the Secretary is the Sender, but the Boss
> is the From.

Sorry, I should have looked into the normative reference (for
my parallel universe ;-), you're right, I was confused:

(5.2)
| The From header contains the electronic address, and possi-
| bly the full name, of the article's author:

(6.4)
| The Sender header identifies the poster, in the event that
| this differs from the author identified in the From header:
[...]
| In the absence of Sender, the default poster is the author
| (named in the From header).

(10.4)
| The Sender header is a tricky case, one where mailing-list
| and post-by-mail practice should differ.  For gatewaying
| mailing lists, the mailing-list host should be considered a
| relayer, and the From and Sender headers supplied in its
| transmissions left strictly untouched.  For post-by-mail, as
| for a moderator posting a mailed submission, the Sender
| header should reflect the poster rather than the author.  If
| a post-by-mail gateway receives a message  with its own
| Sender header, it might wish to preserve the content in an
| X-Sender header.
                          Bye, Frank

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20232
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Date: Fri, 8 Oct 2004 12:04:27 GMT
Lines: 25
Sender: [email-masked]

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

>Depends, my UA certainly uses it for threading, but it also
>displays the "References:" in a way suited for a "See-Also:"
>literal meaning of references.  Especially if I select its
>"options -> show headers -> brief".

Yes, I sometimes look at the References header if I want to view some
precursor in its un-snipped form.

>Of course both attempts (threading and "See-Also:") can fail,
>and the main purpose of references from my POV is threading.

But yes, the "main purpose" is threading.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20233
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: relay checking
Date: Fri, 8 Oct 2004 12:23:48 GMT
Lines: 63
Sender: [email-masked]

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

>Henry Spencer wrote:

>> I'm a little reluctant to use SHOULD for any of this, because that keyword
>> is generally understood to mean that the action in question is nearly
>> mandatory,

>No, it's understood to be a recommendation (and in fact the term
>explicitly and by definition carries the same weight as the
>adjective RECOMMENDED); MUST and MUST NOT are mandates (for
>conforming implementations -- and there is no enforcement, so
>even those terms are not terribly forceful).

Indeed, but "RECOMMENDATION" is usually taken as something more than mere
"recommendation". The phrase Henry would use (and I have seen it used also
by yourself) is that SHOULD is a "strong recommendation" not lightly to
be ignored, and RFC 2119 supports that interpretation.

>> or to say SHOULD but accompany it with an escape
>> hatch like "to the extent that performance requirements permit".

>I don't have a problem with that, but let's make sure the
>right wording is used; let's not speak of performance
>requirements where performance is not the major issue.

But the question here relates to the behaviour of relaying agents, where
performance is THE major issue.

>We also ought to recognize several different instances where
>different fields might be checked.  Some fields are checked
>at injection time and are supposed to remain unaltered
>during transport.

Indeed, and that is the case here. These headers are supposed to have been
checked already by an injecting agent (but there are some dodgy injecting
agents out there).

> ... On the
>other hand, there are fields (e.g. Path) which are modified
>during transport, and which are used in the protocol (at
>least by some implementations, as discussed). It is
>not unreasonable to recommend that these fields be checked,
>so as to be able to pinpoint the agent responsible for
>screwing up syntax or similar errors.

But again, there is a performance hit here. What relaying agents do in
practice, I suspect, is just to extract anything that looks like a
path-identity and do a crude comparison with the identity of the site it
is about to relay to. No great harm arises if it gets it wrong
occasionally.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20231
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Usefor/usepro conflicts.
Date: Fri, 8 Oct 2004 12:00:59 GMT
Lines: 39
Sender: [email-masked]

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

>Charles Lindsey wrote:

>> And, as someone else observed, "poster" is used as a keyword
>> in Followup-To and in Mail-Copies-To, and in both those
>> places it means the From/Reply-To guy.

>"Poster" is as you say the From/Reply-To guy.  That's the same
>as the 2822-Sender.

I think not. In the oft-quoted case where the Boss gets his Secretary to
send the message, the Secretary is the Sender, but the Boss is the From.
The Reply-To may be either of them, or even a third person.

> ...  Likewise the poster is generally the
>author, but not always (sometimes FAQs are written by A, but
>posted by B, where A is the author, and B is a posting-Bot run
>by somebody else).

B is the Sender. If the FAQ contains Followup-To: poster, then followups
would be mailed to A (assuming he is the From/Reply-To).

>I'm not sure about this, but a news From is not always exactly
>the same as a 2822-From, a news From is more like a MAIL FROM.

No, I think that is wrong. The MAIL FROM is where you send reports of
non-delivery and the like, which will usually be the Sender.

To: [email-masked]
Subject: Re: draft-ietf-usefor-usepro-01
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 07 Oct 2004 13:50:52 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> Anyway, for the final question, what about transit-only systems that
> keep no active file, nor any permenent store of articles? Do they need
> to take any special note of Control-headers, or do they just propagate
> them like ordinary articles, as determined by the Newsgroups-headers
> plus their peers' subscription information?

I think either approach works.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20222
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-ietf-usefor-usepro-01
Date: Thu, 7 Oct 2004 14:26:57 GMT
Lines: 43
Sender: [email-masked]

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

>Control messages MUST be propagated as if the newsgroup that they affect
>existed, even if it doesn't.  It is occasionally additionally a good idea
>to behave as if the Newsgroups header contains only the newsgroup being
>affected, rather than whatever other random junk the poster has chosen to
>put in there, but that's a different topic.  The important part is that if
>I post a newgroup message for news.misc, that newgroup message should
>propagate to any of my peers that would receive news.misc given their
>subscription patterns, even if that group doesn't actually exist.

Right! That last sentence is the bit that was missing from your previous
explanations of what INN actually did. There clearly had to be a 'sys'
file (however called) somewhere in the chain that controlled what actually
went to your downstream peers.

>This is significant since normally, for speed, implementations like INN
>turn feed subscriptions into a hash table keyed on newsgroup name and
>listing all the sites that want to retrieve that newsgroup.  This is an
>effective technique for nearly all traffic if you're maintaining an active
>file, but control messages cannot be handled this way, and INN pulls them
>out of normal feed processing and performs a special match of the affected
>group against the raw feed patterns instead.

OK, it is useful to know that, but I can still see variants on that
technique that would work equally well.

Anyway, for the final question, what about transit-only systems that keep
no active file, nor any permenent store of articles? Do they need to take
any special note of Control-headers, or do they just propagate them like
ordinary articles, as determined by the Newsgroups-headers plus their
peers' subscription information?

Date: Thu, 7 Oct 2004 09:11:17 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: relay checking
Sender: [email-masked]

Henry Spencer <henry@xxxxxxxxxxxxx>:

>Most people believe that SHOULD (or the seldom-used RECOMMENDED) carries a
>lot of weight -- that it is not just a suggestion or an encouragement, but
>an emphatic recommendation that you disregard at your peril, although
>unusual circumstances may occasionally justify violating it. 

>There are a few people who persist in claiming that it doesn't really mean
>that.  My concern is to communicate, and therefore I use SHOULD with its
>consensus meaning. 

Unfortunately, every standard that uses SHOULD proclaims somewhere within 
that they use SHOULD as it is defined in RFC2119. There is no mention of 
"peril" or "emphatic" in that standard. Not even the implication.

Wouldn't it be nice if the "consensus" meaning actually matched the
consensus meaning that was achieved when RFC2119 was adopted? I mean, if 
the authors of RFC2119 MEANT the strength of force that Henry's 
"consensus" says, they could have said so themselves. Since they did not,
it seems clear to me that they didn't intend any such force.

Date: Thu, 7 Oct 2004 09:07:15 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Usefor/usepro conflicts.
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Well "poster" is the word we have used in the draft all along, and I worry
>that some subtle change of meaning will ensue if we change it now. Any
>more opinions on this one?

Just as I did for the word "followup" and found nothing really changed, 
nothing really changes for the word "poster", since most of the standard 
deals with the actions of posting and what happens from thereon, and not 
much with the content of the body, which is the author's responsibility.

>And, as someone else observed, "poster" is used as a keyword in Followup-To
>and in Mail-Copies-To, and in both those places it means the From/Reply-To
>guy.

Yes, this is the only point I found that would be in error, but since it 
is current practice, it seems a bit late to change that to "author". It is 
also pretty much harmless, and can easily be covered by a simple statement
that "yes, we know it ought to be 'author', but its usage is historical 
and we're just going to live with it this way".

Date: Thu, 7 Oct 2004 09:01:00 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>The whole of this discussion started because it was reported that some FAQ
>writers had formed the habit of linking their multi-part FAQs together
>using References-headers, and a consensus developed that this practice was
>a Good Thing.

Umm, this discussion started when I read the document listed in the 
subject and saw a silly alternative definition for a word that implied
a level of control over something that did not exist.

>But why did those FAQ writers start doing that? Because they saw that it
>would cause their parts to be presented in the correct order, at least in
>those reading agents which did threading (which was enough of them to be
>useful).

And which reading agents did they see this in? Their own. Keep in mind,
they get to control how they see things, so the fact that they can control
how they see things is no big surprise. It is their ability to control
how OTHER PEOPLE see things that is the question, and which they lack.

>And I've just explained why it was right. Your move.

No, you explained why someone has unfounded expectations about something
they do being able to control other people's display of articles. 
Unfounded expectations are not a reason to change a definition.

However, the fact that they DO use the header to indicate relationships
that are just outside the old definition are a reason to change it, if
one it truly documenting existing practice. It's just not correct to imply
that their desire to indicate a relationship actually has some basis in
controlling the display of articles. That implication is the problem with
the alternate definition you have provided.

Date: Thu, 07 Oct 2004 11:39:02 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Henry Spencer <[email-masked]>
CC: Usefor Mailing List <[email-masked]>
Subject: Re: relay checking
Sender: [email-masked]

Henry Spencer wrote:

> I'm a little reluctant to use SHOULD for any of this, because that keyword
> is generally understood to mean that the action in question is nearly
> mandatory,

No, it's understood to be a recommendation (and in fact the term
explicitly and by definition carries the same weight as the
adjective RECOMMENDED); MUST and MUST NOT are mandates (for
conforming implementations -- and there is no enforcement, so
even those terms are not terribly forceful).

> I think the right choice is either to say MAY with some accompanying words
> urging people to do it,

The term MAY is generally used for clarification where an
implementor might misinterpret some normative text as
precluding something which is in fact not intended to be
precluded.  Any other use of the term tends to be vacuous
since it is generally permitted to do anything that is not
explicitly proscribed.

> or to say SHOULD but accompany it with an escape
> hatch like "to the extent that performance requirements permit".

I don't have a problem with that, but let's make sure the
right wording is used; let's not speak of performance
requirements where performance is not the major issue.

We also ought to recognize several different instances where
different fields might be checked.  Some fields are checked
at injection time and are supposed to remain unaltered
during transport. It would probably be unreasonable to
demand routine checks of such fields at every relay
agent, and given the protocol specifications (viz. checked
once at injection time and remaining unaltered thereafter)
there is only a small point (see below) in recommending
checks. There is no reason to prohibit such checks. On the
other hand, there are fields (e.g. Path) which are modified
during transport, and which are used in the protocol (at
least by some implementations, as discussed). It is
not unreasonable to recommend that these fields be checked,
so as to be able to pinpoint the agent responsible for
screwing up syntax or similar errors.  The questions then
are what might reasonably be checked, when, and by whom.  At
minimum, if a field is to be checked, the part which should
have been modified by the preceding (upstream) agent should
be checked.  If checking is a mere recommendation, then it
is possible that that upstream agent did no checking of what
was modified by its upstream neighbor and so on, so it
might be prudent to check everything that might have been
modified since injection.  Such checks (of modifications
made by predecessors) should probably be performed on
receipt, before other processing, so as to avoid attempting
to process broken articles. There is little point in an
agent attempting to check its own modifications prior to
sending an article downstream, since an author's error in
interpretation of requirements when modifying a field is
likely to be repeated when checking.  It is also conceivable
that an injection agent may have made an error, so there is
no reason to preclude a relay agent from checking parts of
fields that might have been set at injection time, or entire
fields that are supposed to be set at injection and remain
unmodified thereafter.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Date: Thu, 07 Oct 2004 14:09:49 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Charles Lindsey wrote:

> There would be little point in having the References header
> if it were not intended to be used for threading.

Depends, my UA certainly uses it for threading, but it also
displays the "References:" in a way suited for a "See-Also:"
literal meaning of references.  Especially if I select its
"options -> show headers -> brief".

Of course both attempts (threading and "See-Also:") can fail,
and the main purpose of references from my POV is threading.

                        Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: Usefor/usepro conflicts.
Date: Thu, 07 Oct 2004 13:55:16 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 28
Sender: [email-masked]

Charles Lindsey wrote:

>>> "poster" is the person or software that composes a possibly
>>> compliant article for submission to a posting agent. The
>>> poster is synonymous with [RFC 2822]'s author.

>> I believe this is wrong.  Poster is synonymous with sender.

> Well "poster" is the word we have used in the draft all
> along, and I worry that some subtle change of meaning will
> ensue if we change it now. Any more opinions on this one?
 
> And, as someone else observed, "poster" is used as a keyword
> in Followup-To and in Mail-Copies-To, and in both those
> places it means the From/Reply-To guy.

"Poster" is as you say the From/Reply-To guy.  That's the same
as the 2822-Sender.  It's generally the same as the 2822-From
(author), but not always.  Likewise the poster is generally the
author, but not always (sometimes FAQs are written by A, but
posted by B, where A is the author, and B is a posting-Bot run
by somebody else).

I'm not sure about this, but a news From is not always exactly
the same as a 2822-From, a news From is more like a MAIL FROM.

                         Bye, Frank

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20216
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Date: Wed, 6 Oct 2004 23:02:47 GMT
Lines: 47
Sender: [email-masked]

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

>You are indicating that your article and the article with the last
>message id in the References header has a child-parent relationship.
>Furthermore, you're saying that all message ids in the References header
>have an ancestry relationship to your article.  And you're saying that
>the very first message id in the References header is the very first
>message of this ancestry lineage.

>I guess this isn't quite correct, as the References header may also contain
>message ids that are not decendants of the very first article (when
>replying to two different articles as once), or doesn't this ever
>happen?

We have explicitly said we do not cover the case of followups to multiple
articles, and RFC 2822 says much the same thing for email. OTOH, if you do
make such a followup and manually create a References-header in a
plausible way, then most current threading agents will probably manage to
do something sensible with it.

>Isn't this what the references header really means?  How to display
>the article in a news reader isn't really that relevant, the natural
>way to display articles having such relations comes from the meaning
>of the header, not vice versa.

I think the two things go hand in hand. There would be little point in
having the References header if it were not intended to be used for
threading.

>Are we really not able to describe the semantics of the references
>header without doing it backwards by describing the ui rather
>than the meaning.

But I agree that some semantics in the USEFOR document would be a good
addition to the detailed instructions in USEPRO as to how to contruct it,
and I intend to look into this.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20218
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Usefor/usepro conflicts.
Date: Wed, 6 Oct 2004 23:23:15 GMT
Lines: 47
Sender: [email-masked]

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

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

>> OK, I now have:

>>    A "poster" is the person or software that composes a possibly
>>    compliant article for submission to a posting agent. The poster is
>>    synonymous with [RFC 2822]'s author.

>I believe this is wrong.  Poster is synonymous with sender.

Well "poster" is the word we have used in the draft all along, and I worry
that some subtle change of meaning will ensue if we change it now. Any
more opinions on this one?

And, as someone else observed, "poster" is used as a keyword in Followup-To
and in Mail-Copies-To, and in both those places it means the From/Reply-To
guy.

>>> The word in standard usage implies "the person who posts", which is
>>> different than "the person who writes", so as a synonym, it belongs to
>>> "sender".

>> But the term as widely used throughout Usenet is as I have defined it.

>I strongly disagree.  Everywhere that I've seen poster used on Usenet in a
>context that drew the distinction between author and transmitter, poster
>referred to the person who injected the article, not the author.

Yes, and in any case in the draft where that distinction is important we
need to be careful, as in the following case:

>>    Posting agents meant for use by ordinary posters SHOULD reject any
>>    attempt to post an article which cancels or Supersedes another
>>    article of which the poster is not the author or sender.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20220
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: relay checking
Date: Wed, 6 Oct 2004 23:28:06 GMT
Lines: 40
Sender: [email-masked]

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

>On Wed, 29 Sep 2004, Russ Allbery wrote:
>> I thought Henry and I just agreed on language, and I'm curious as to why
>> you decided to go with this language instead...
>> I don't see a lot of purpose served in distinguishing between existence
>> and syntactic validity of headers.  I think that makes the logic of the
>> standard slightly more complex for no particularly clear reason.

>To clarify my own position on this...

>+ I see a small benefit from insisting on presence of mandatory headers,
>but only a small one.  It's unobjectionable but not very important.

I have written SHOULD. 

>+ I'm reluctant to demand full checking by relay agents which otherwise
>don't have reason to do it.  Even SHOULD seems too strong a word here. 

I have written MAY.

>+ I would *like* to see relay agents not only permitted, but explicitly
>encouraged, to do as much checking as they feel they can. 

Not sure I want to encourage too hard. It could be a severe performance
penalty. And I agree that SHOULD is far too strong.

>+ I don't care deeply about the issue, and could live with any wording
>that permits full checking but doesn't require it. 

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20217
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: relay checking
Date: Wed, 6 Oct 2004 23:14:37 GMT
Lines: 31
Sender: [email-masked]

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

>On Wed, 29 Sep 2004, Charles Lindsey wrote:
>>    3.   It SHOULD reject any article that does not have the correct
>>         mandatory headers (section a-5) present.

>Why "correct"?  That seems redundant, and it is bound to make people
>wonder whether it has some special significance.  I'd take that word out.

Because that word has been there all along. But I take your point.

   3.   It SHOULD reject any article that does not include all the
        mandatory headers (section a-5).

And likewise for serving agents.

There was also a similar use of "correct" in relation to injecting agents
and proto-articles, where I have changed it to "proper".

>Otherwise, this seems okay.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20219
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Standardize Complaints-To as deployed?
Date: Wed, 6 Oct 2004 23:25:54 GMT
Lines: 29
Sender: [email-masked]

Yes.

To: [email-masked]
Subject: Re: draft-ietf-usefor-usepro-01
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 06 Oct 2004 19:28:16 -0700
Sender: [email-masked]

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

>> However, relay agents that check the Newsgroups header against a list
>> of valid groups *do* need to propagate control messages as if the group
>> they were affecting existed.  *That* behavior does need to be specified
>> in the standard.  This is independent of the question of whether one
>> should ignore the Newsgroups header on newgroup and rmgroup control
>> messages entirely.

> But if control messages are to be propagated regardless of what the
> Newsgroups-header says, then how is it that I do not see newgroup
> messages for jp.* and other hierarchies to which I do not subscribe?

I am completely baffled by this reply.  You seem to have not read what I
have said.

You don't get newgroup messages for jp.* because you are not being fed the
jp.* hierarchy, and the only mention of "control messages are to be
propagated regardless of what the Newsgroups-header says" is the text
that's currently in USEPRO that I'm trying to get you to take *out*.

Control messages MUST be propagated as if the newsgroup that they affect
existed, even if it doesn't.  It is occasionally additionally a good idea
to behave as if the Newsgroups header contains only the newsgroup being
affected, rather than whatever other random junk the poster has chosen to
put in there, but that's a different topic.  The important part is that if
I post a newgroup message for news.misc, that newgroup message should
propagate to any of my peers that would receive news.misc given their
subscription patterns, even if that group doesn't actually exist.

This is significant since normally, for speed, implementations like INN
turn feed subscriptions into a hash table keyed on newsgroup name and
listing all the sites that want to retrieve that newsgroup.  This is an
effective technique for nearly all traffic if you're maintaining an active
file, but control messages cannot be handled this way, and INN pulls them
out of normal feed processing and performs a special match of the affected
group against the raw feed patterns instead.

> So, back when Tale first created 'humanities.misc', I think you will
> find that his Newsgroups-header will have contained at least token
> groups from sci, comp, news, talk, etc. Otherwise, it would never have
> propagated very far.

How much money would you like to bet me?

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20212
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Issues with MIME-style parameters
Date: Wed, 6 Oct 2004 21:10:46 GMT
Lines: 32
Sender: [email-masked]

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

>Charles Lindsey wrote:

>[...]
>> So the
>> possibility that there may one day be parameters in the Path header has
>> changed nothing.
>[...]
>> why should it be used as an argument with
>> Injection-Date?

>The WG Chair declared the matter of so-called "MIME" parameters
>a closed issue on August 23, a full week before Charles' message
>was composed, and more than a month before it was posted to the
>mailing list.  This is outrageous.  Mr. Chairman, can we please
>settle this issue once and for all.

The remark concerning the Path header was totally peripheral to the
substance of what my message was about. I note that you have made no
response to that substance.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20213
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-ietf-usefor-usepro-01
Date: Wed, 6 Oct 2004 22:20:41 GMT
Lines: 119
Sender: [email-masked]

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

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

>> We did discuss the text that says control messages need to have a
>> Newsgroups-header that will steer them to the proper places, and the
>> text you see contains some tweaks arising from that.

>Control messages should not, in general, be crossposted to other
>newsgroups than they one that they affect.  David Lawrence was the one who
>first taught me the problems caused by doing so.  For example, when people
>form a habit of crossposting control messages to alt.config, someone
>limiting what hierarchies in alt.* they receive, they still ends up
>getting control messages for the hierarchies they don't want.

Indeed so, which is why our draft says you SHOULD include the affected
group in the Newsgroups-header, and you MAY include others, but it then
points out that this may cause other problems. However, it may sometimes
be useful, and others have said as much in response to your message.

>However, relay agents that check the Newsgroups header against a list of
>valid groups *do* need to propagate control messages as if the group they
>were affecting existed.  *That* behavior does need to be specified in the
>standard.  This is independent of the question of whether one should
>ignore the Newsgroups header on newgroup and rmgroup control messages
>entirely.

But if control messages are to be propagated regardless of what the
Newsgroups-header says, then how is it that I do not see newgroup messages
for jp.* and other hierarchies to which I do not subscribe? For sure
someone upstream of me is filtering them out, so I can only suppose that
some 'sys' files are being consulted somewhere in the process, but where?

>  I'm surprised that it's not in son-of-1036 and doesn't appear
>to be in CNews, but perhaps both predate the understanding that this was
>the right thing to do.  This has been implemented in INN since the 1.0
>release in 1991.

>If relay agents don't implement this behavior, booster rmgroups are
>futile because they won't propagate past the first host that already
>removed the group and newgroups won't propagate through relay agents that
>don't act on them immediately and require that newsgroups exist before
>propagating messages.  This is clearly wrong.

Sure, but different relay agents attack this problem in all sorts of
different ways.

For example, in CNews, it checks for the presence of a Control-header at
an early stage, and immediately decides to file it in the 'control'
newsgroup (which is always in the active file). So any control message
received (i.e. which the upstream peer was somehow configured to send to
it) will get stored regardless.

Then, whenever a new article is stored it consults its 'sys' file to see
which of its downstream peers it should send it to, and that of course is
determined by what is in the article's Newsgroups-header. Note that
'sys' files are usually broadly written, disposing of complete
(sub-)hierarchies using wildmat notation or similar.

So, back when Tale first created 'humanities.misc', I think you will find
that his Newsgroups-header will have contained at least token groups from
sci, comp, news, talk, etc. Otherwise, it would never have propagated very
far.

>Well, I don't believe that's correct, but there's no point in arguing
>about past history.  I'm making that statement now.  This should be part
>of the standard.

I think it is clear that we have to put _something_ in the standard about
this, but I think we need to understand the range of practices that
current relaying agents actually DO before writing any text.

>>    Even if relaying agents do not, as a matter of local policy, intend
>>    to honour certain control messages, they MUST still propagate them in
>>    the normal manner.
>> [The inclusion of that paragraph still remains under discussion.]

>This is still not correct.  This doesn't help with the issue addressed
>above in propagation of newgroup and rmgroup control messages and simply
>contradicts other portions of the document in a fashion that leaves one
>wondering what it's supposed to mean.

Sure, but it's not supposed to be anything to do with the issues discussed
above. It is concerned with agents that try to say "I am not going to
create this group, so I am not going to tell you about it".

>  Please, remove this language and
>just explain that newgroup and rmgroup control messages should always be
>propagated as if the group they're affecting exists, even if it does not.

I could easily be persuaded that the wording should come out, but at least
let us remove it for the right reasons (e.g. that no current agent is so
inconsiderate and mean as to do such a thing).

>> Ah! I had always understood, since the matter was first raised on the
>> news.admin.net-abuse groups, that it came out of the normal processing
>> of the Path header rather than on special code in transport agents.

>Nope.  It was possible because of a pre-existing feature in INN (the path
>aliasing concept predates pseudo-sites by quite some time), but path
>aliasing is not really part of the normal processing of the Path header.

OK. Thanks for that, though it implies that the trick would never have
worked on CNews.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20214
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Date: Wed, 6 Oct 2004 22:23:37 GMT
Lines: 27
Sender: [email-masked]

In <[email-masked]> "Shmuel (Seymour J.) Metz" <[email-masked]> writes:

>In <[email-masked]>, on 09/29/2004
>   at 06:07 PM, "Charles Lindsey" <[email-masked]> said:

>>OK, that is new wording, and it may yet disappear entirely. But the
>>"MUST be identical" is indeed too severe. I have made a note to
>>review it.

>You could just add an additional phrse along the lines of "except as
>requested by the reader."

>For the most part I like your text as it is.

Which seems to imply that you support retention of a "Duties of a Reading
Agent" section broadly as I have suggested it.

To: LIST: [email-masked], [email-masked];
Xref: clerew local.usefor:20215
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Date: Wed, 6 Oct 2004 22:45:51 GMT
Lines: 57
Sender: [email-masked]

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

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>The alternative text, which you did not quote, is

>Didn't need to quote it, I thought.

>>No, the poster cannot "define" how articles are to be displayed, but he
>>can indicate his intention in the matter ...

>If he cannot control it, his intention of controlling it is irrelevant. "I 
>want ...". That's nice, but you don't get to say. Presenting it as if 
>there was some mechanism, when none exists, just leads to foolish 
>expectations. Just like the foolish expectations that copyright notices in 
>the body of an article are going to change how Google or any other 
>automated news processor is going to work.

The whole of this discussion started because it was reported that some FAQ
writers had formed the habit of linking their multi-part FAQs together
using References-headers, and a consensus developed that this practice was
a Good Thing.

But why did those FAQ writers start doing that? Because they saw that it
would cause their parts to be presented in the correct order, at least in
those reading agents which did threading (which was enough of them to be
useful). In other words, they were indicating an intention of how they
would like their articles displayed. Not guaranteed to work, but working
often enough to be useful.

>>>The alternative I suggested is still better. Why has it never appeared in
>>>any form?

>>You need to explain _why_ your wording is better.

>I have, many times. On the other hand, I've not seen any explanation of 
>why your new alternative is better, it just appeared out of nowhere. And
>now I've explained why YOUR wording is wrong.

And I've just explained why it was right. Your move.

All the remaining points raised in your message raise nothing that has not
already been discussed on this list ad nauseam and received adequate
answers, both from myself and from others. If other members of this
list feel that any of your points are worth further discussion, then I am
willing to reopen them. But not otherwise.

Date: Tue, 5 Oct 2004 15:08:13 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: relay checking
Sender: [email-masked]

On Tue, 5 Oct 2004, Bruce Lilly wrote:
> > + I'm reluctant to demand full checking by relay agents which otherwise
> > don't have reason to do it.  Even SHOULD seems too strong a word here. 
> > + I would *like* to see relay agents not only permitted, but explicitly
> > encouraged, to do as much checking as they feel they can. 
> 
> Since SHOULD carries the same weight as RECOMMENDED...

Most people believe that SHOULD (or the seldom-used RECOMMENDED) carries a
lot of weight -- that it is not just a suggestion or an encouragement, but
an emphatic recommendation that you disregard at your peril, although
unusual circumstances may occasionally justify violating it. 

There are a few people who persist in claiming that it doesn't really mean
that.  My concern is to communicate, and therefore I use SHOULD with its
consensus meaning. 

                                                          Henry Spencer
                                                       [email-masked]

Date: Tue, 05 Oct 2004 08:06:05 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-usefor <[email-masked]>
Organization: Bruce Lilly
To: Alexey Melnikov <[email-masked]>
CC: ietf-usefor <[email-masked]>
Subject: Re: Standardize Complaints-To as deployed?
Sender: [email-masked]

No.

Date: Tue, 05 Oct 2004 09:26:56 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Henry Spencer <[email-masked]>
CC: Usefor Mailing List <[email-masked]>
Subject: Re: relay checking
Sender: [email-masked]

Henry Spencer wrote:

> To clarify my own position on this...
> 
[...]
> + I'm reluctant to demand full checking by relay agents which otherwise
> don't have reason to do it.  Even SHOULD seems too strong a word here. 
> 
> + I would *like* to see relay agents not only permitted, but explicitly
> encouraged, to do as much checking as they feel they can. 

Since SHOULD carries the same weight as RECOMMENDED, either there is
an inconsistency in your position or you believe that there is some
significant difference between "RECOMMENDED" and encouraged. So
please do clarify; how would an explicit recommendation not encourage
relay agent authors to "do as much checking as they feel they can"?

Date: Mon, 4 Oct 2004 15:08:01 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Seth Breidbart <sethb@xxxxxxxxx>:

>What part of "me, as a reader" didn't you understand?  The last word?

Already covered. And still, your deference to the poster is well and
good, but guessing nonetheless, and not in any way universal.

>When I post, I _intend_ that others read my post.  Obviously, I can't
>enforce that; 

Glad to see left field is still alive. The issue at hand is not whether 
they read your article or not, it is how your article is displayed when
they read it. Do you have control over that? No. Is your "intent" worth
much, given you have no control and no mechanism defined for describing
your intent? No.

>When I post a followup in response to a specific article, with a
>References header, am I indicating that my article is part of a
>thread, or am I indicating my intention that my article be treated as
>part of that thread?

Irrelevant question, since the issue is not "is this part of a thread",
but "do you have control over how it is displayed?"

>> Oh, I see where you get your SWAG number. YOUR newsreader shows you things 
>> the way YOU want them 99% of the time, thus everyone elses shows them 
>> things the way you want them 99% of the time.

>No, their newsreader shows them things the way they want.

Yes, exactly. So your control over how they see things is nada, and your
intentions about same are meaningless.

>Really?  If I put a References header into a new article, your
>newsreader (as you have it configured) won't show my article as part
>of the thread containing the messages referred to in that References
>header?

It shows things the way I specify. If I say not to, you have no control.
You certainly can't say "show this next to that". 

>> The fact remains: poster "intentions" on how messages are displayed,
>> or in what order, are irrelevant simply because the expectation of
>> control is specious.

>Let's remove the Newsgroups header, too, then, for the same reason.

Left field is active. I don't know what "same reason" you think applies,
but the control of the newsgroups to which an article is posted IS the
posters; how the article is displayed is up to the reader. The same
kinds of arguments do not apply to the Newsgroups  header.

Date: Mon, 04 Oct 2004 22:51:44 +0100
From: Alexey Melnikov <[email-masked]>
To: ietf-usefor <[email-masked]>
Subject: USEFOR WG meeting in Washington, DC
Sender: [email-masked]

Is there any interest to have an official WG slot at Washington, DC 
IETF? Please, let me know.

Alexey

Date: Mon, 4 Oct 2004 14:46:29 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Sender: [email-masked]

Seth Breidbart <sethb@xxxxxxxxx>:

>While I don't _have to_ display anything the
>way the poster wants, I will often _choose_ to _defer to_ the poster's
>wishes.

Sorry, the first time I read that I saw it as choosing to defer to the
reader's wishes. 

The fact is, the only "poster's wish" that you can know is that he thinks
some article is related to another. Whether that means he wants it 
displayed next to or above is difficult to tell, since there is no 
definition to guide anyone. You can defer to what you think the poster
wants for display, but you are just guessing, and in any case, the poster
doesn't have the control that this draft is trying to imply he has.

Date: Mon, 4 Oct 2004 17:35:40 -0400 (EDT)
From: Henry Spencer <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Re: Standardize Complaints-To as deployed?
Sender: [email-masked]

                                                          Henry Spencer
                                                       [email-masked]

To: ietf-usefor <[email-masked]>
Subject: Re: Standardize Complaints-To as deployed?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 04 Oct 2004 14:30:39 -0700
Sender: [email-masked]

Date: Mon, 04 Oct 2004 21:03:36 +0100
From: Alexey Melnikov <[email-masked]>
To: ietf-usefor <[email-masked]>
Subject: Standardize Complaints-To as deployed?
Sender: [email-masked]

Hi,

Thanks,
Alexey

Date: Mon, 4 Oct 2004 20:25:22 +0200
From: Eivind Tagseth <[email-masked]>
To: [email-masked]
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Mail-Followup-To: Eivind Tagseth <[email-masked]>, [email-masked]
Sender: [email-masked]

* Seth Breidbart <[email-masked]> [2004-10-04 13:11:39 -0400]:
> John Stanley <[email-masked]> wrote:

> > What you intend is nice, and it is nice that you think it is
> > important to you, but your intention really is irrelevant, since
> > there is no means for you to accomplish what you want.

> When I post a followup in response to a specific article, with a
> References header, am I indicating that my article is part of a
> thread, or am I indicating my intention that my article be treated as
> part of that thread?

You are indicating that your article and the article with the last
message id in the References header has a child-parent relationship.
Furthermore, you're saying that all message ids in the References header
have an ancestry relationship to your article.  And you're saying that
the very first message id in the References header is the very first
message of this ancestry lineage.

I guess this isn't quite correct, as the References header may also contain
message ids that are not decendants of the very first article (when
replying to two different articles as once), or doesn't this ever
happen?

Isn't this what the references header really means?  How to display
the article in a news reader isn't really that relevant, the natural
way to display articles having such relations comes from the meaning
of the header, not vice versa.

Are we really not able to describe the semantics of the references
header without doing it backwards by describing the ui rather
than the meaning.

Eivind

Date: Mon, 4 Oct 2004 13:11:39 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Sender: [email-masked]

John Stanley <[email-masked]> wrote:
> Seth Breidbart <sethb@xxxxxxxxx>:

>>> If he cannot control it, his intention of controlling it is
>>> irrelevant.
>
>>Not to me, as a reader.
>
> If you think you have some control, then you are ill informed.

What part of "me, as a reader" didn't you understand?  The last word?

> What you intend is nice, and it is nice that you think it is
> important to you, but your intention really is irrelevant, since
> there is no means for you to accomplish what you want.

When I post, I _intend_ that others read my post.  Obviously, I can't
enforce that; does that mean that transmission of posts should be
blocked entirely?

When I post a followup in response to a specific article, with a
References header, am I indicating that my article is part of a
thread, or am I indicating my intention that my article be treated as
part of that thread?

>>While I don't _have to_ display anything the way the poster wants, I
>>will often _choose_ to _defer to_ the poster's wishes.
>
> It's nice that you "choose" to defer, since you actually have no choice
> in the matter.

As the _reader_, I have _all_ the choice.

>>The "display intentions" are not irrelevant to me, as a reader,
>
> That's nice. Too bad you don't have a choice.

But I do.

>>because my newsreader adheres to them 99.9+% of the time (that is, I
>>seldom bother to override its defaults).
>
> Oh, I see where you get your SWAG number. YOUR newsreader shows you things 
> the way YOU want them 99% of the time, thus everyone elses shows them 
> things the way you want them 99% of the time.

No, their newsreader shows them things the way they want.

> Sorry, no. I bet mine doesn't show them your way even 1% of the
> time. Your average is down to 50%, and that's just after considering
> two readers.

Really?  If I put a References header into a new article, your
newsreader (as you have it configured) won't show my article as part
of the thread containing the messages referred to in that References
header?

And you think a significant fraction of other readers have their
newsreaders configured similarly?

> The fact remains: poster "intentions" on how messages are displayed,
> or in what order, are irrelevant simply because the expectation of
> control is specious.

Let's remove the Newsgroups header, too, then, for the same reason.

Seth

Date: Mon, 4 Oct 2004 08:30:57 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Sender: [email-masked]

Seth Breidbart <sethb@xxxxxxxxx>:

>> If he cannot control it, his intention of controlling it is
>> irrelevant.

>Not to me, as a reader.

If you think you have some control, then you are ill informed. What you
intend is nice, and it is nice that you think it is important to you, but 
your intention really is irrelevant, since there is no means for you to
accomplish what you want.

>While I don't _have to_ display anything the
>way the poster wants, I will often _choose_ to _defer to_ the poster's
>wishes.

It's nice that you "choose" to defer, since you actually have no choice
in the matter. If the user wants to display your message in 1 pt font in
red blinking letters, there isn't anything you can do to stop it.

>An expectation that is fulfilled, say, 98% of the time is far from
>"foolish".

An expectation based on SWAG numbers, with no mechanism to accomplish it
in the first place, is foolish.

>The "display intentions" are not irrelevant to me, as a reader,

That's nice. Too bad you don't have a choice.

>because my newsreader adheres to them 99.9+% of the time (that is, I
>seldom bother to override its defaults).

Oh, I see where you get your SWAG number. YOUR newsreader shows you things 
the way YOU want them 99% of the time, thus everyone elses shows them 
things the way you want them 99% of the time. Sorry, no. I bet mine 
doesn't show them your way even 1% of the time. Your average is down to
50%, and that's just after considering two readers. 

The fact remains: poster "intentions" on how messages are displayed, or in
what order, are irrelevant simply because the expectation of control is
specious. Better to teach people the truth than give them false
expectations, which will lead them to come here expecting their intentions
to be codified in the standard, as we are now seeing happen.

Date: Mon, 04 Oct 2004 15:14:26 +0100
From: Alexey Melnikov <[email-masked]>
To: ietf-usefor <[email-masked]>
Subject: Re: Issues with MIME-style parameters
Sender: [email-masked]

--------------020007080808030900050305
Content-type: text/plain; charset="us-ascii"

Bruce Lilly wrote:

>Charles Lindsey wrote:
>
>[...]  
>
>>So the
>>possibility that there may one day be parameters in the Path header has
>>changed nothing. 
>>
>[...]
>  
>
>>why should it be used as an argument with
>>Injection-Date?
>>    
>>
>
>The WG Chair declared the matter of so-called "MIME" parameters
>a closed issue on August 23, a full week before Charles' message
>was composed, and more than a month before it was posted to the
>mailing list.  This is outrageous.  Mr. Chairman, can we please
>settle this issue once and for all.
>
Just to clarify, based on WG feedback, I've declared that there is no WG 
support for generic MIME-type parameters applicable to all *existing* 
and new headers.

A new header can be designed to be extensible (including something that 
looks like MIME-style parameter), however the WG need to understand all 
"for" and "against" introducing extensibility for the header.

Alexey

--------------020007080808030900050305
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Bruce Lilly wrote:<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Charles Lindsey wrote:

[...]  </pre>
  <blockquote type="cite">
    <pre wrap="">So the
possibility that there may one day be parameters in the Path header has
changed nothing. </pre>
  </blockquote>
  <pre wrap=""><!---->[...]
  </pre>
  <blockquote type="cite">
    <pre wrap="">why should it be used as an argument with
Injection-Date?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The WG Chair declared the matter of so-called "MIME" parameters
a closed issue on August 23, a full week before Charles' message
was composed, and more than a month before it was posted to the
mailing list.  This is outrageous.  Mr. Chairman, can we please
settle this issue once and for all.</pre>
</blockquote>
Just to clarify, based on WG feedback, I've declared that there is no
WG support for generic MIME-type parameters applicable to all
*existing* and new headers.<br>
<br>
A new header can be designed to be extensible (including something that
looks like MIME-style parameter), however the WG need to understand all
"for" and "against" introducing extensibility for the header.<br>
<br>
Alexey<br>
<br>
</body>
</html>

--------------020007080808030900050305--

From: "petergordon" <[email-masked]>
Date: Sun, 03 Oct 2004 14:23:13 -0500 (CDT)
To: 
Subject: BUSINESS PROPOSAL!!

Mr.Peter Gordons
Imperial Bank.
140 Boeing Road East
Elma Park Edenvale
Gauteng 1610
Republic Of South Africa.
Fax:+27:732:632:745
email:[email-masked]

Dear Sir/Madam,

I am Mr.Peter Gordon, Head: Enterprise Wide Risk and member of the executive
and risk committees. of Imperial Bank, South Africa. This is an urgent and
very confidential business proposition.

On June 6, 2000,a Foreign Oil consultant/contractor with the South African
Institute of Mining and Metallurgy, Mr.Stephen Garrick made a numbered
time(Fixed) Deposit for twelve calendar months, valued at US$26,500,000.00,(Twenty-six
Million, five hundred thousand Dollars).

Upon maturity, I sent a routine notification to his forwarding address but
got no reply. After a month, we sent a reminder and finally we discovered
from his contract employers, the National Petroleum Corporation that Mr.Stephen
Garrick died from an automobile accident. On further investigation, I found
out that he died without making a "WILL", and all attempts to trace his
next of kin was fruitless.

I therefore made further investigation and discovered that Mr. Stephen Garrick
did not declare any kin or relations in all his official documents, including
his Bank Deposit paperwork in my Bank. This sum of US$26,500,000.00 has
carefully been fixed in my bank for safekeeping. No one will ever come forward
to claim it. According to South African Law, at the expiration of 5 (five)
years, the money will revert to the ownership of the Government if nobody
applies to claim the fund.

Consequently, my proposal is that I will like you as a Foreigner to stand
in as the owner of the money which was fixed deposited in my bank. I am
writing you because I as a public servant, I cannot operate a foreign account.

I want to present you as the owner of the funds so you can be able to claim
them with the help of my attorney. This is simple. I will like you to provide
immediately your full names,telephone/fax numbers and address, so that the
Attorney will prepare the necessary documents which will put you in place
as the beneficiary of the funds.

The money will be moved out for us to share in the ratio of 80% for me and
20% for you. The paperwork for this transaction will be done by the Attorney
If you are interested, please reply immediately via my email address and
Upon your response, I shall then provide you with more details that will
help you understand the transaction.

Please observe utmost confidentiality, and be rest assured that this transaction
would be most profitable for both of us because I shall require your assistance
to invest my share in real estate within your country.

Due to the nature of confidentiality in this Transaction our communication
can only be via email and fax mostly.

Awaiting your urgent reply via email.

Thanks and my regards.

Mr.Peter Gordon.

PLEASE REPLY TO my FAX NUMBER OR EMAIL:[email-masked]

Date: Sun, 3 Oct 2004 15:57:04 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: <draft-ietf-usefor-usepro-01.txt>
Sender: [email-masked]

John Stanley <[email-masked]> wrote:
> "Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>No, the poster cannot "define" how articles are to be displayed, but he
>>can indicate his intention in the matter ...
>
> If he cannot control it, his intention of controlling it is
> irrelevant.

Not to me, as a reader.  While I don't _have to_ display anything the
way the poster wants, I will often _choose_ to _defer to_ the poster's
wishes.

> "I want ...". That's nice, but you don't get to say. Presenting it
> as if there was some mechanism, when none exists, just leads to
> foolish expectations.

An expectation that is fulfilled, say, 98% of the time is far from
"foolish".

>>If you read the definition, some followups come from precursors and some
>>come from the poster's display intentions.
>
> Since the "display intentions" are irrelevant, that part of the 
> definition is irrelevant.

The "display intentions" are not irrelevant to me, as a reader,
because my newsreader adheres to them 99.9+% of the time (that is, I
seldom bother to override its defaults).

Seth

To: [email-masked]
Subject: Re: draft-ietf-usefor-usepro-01
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 02 Oct 2004 12:26:07 -0700
Sender: [email-masked]

Kai Henningsen <[email-masked]> writes:
> [email-masked] (Russ Allbery) wrote:

>> Control messages should not, in general, be crossposted to other
>> newsgroups than they one that they affect.

> That never seemed right to me. Surely group-list changing ones should be
> crossposted to a designated control message group for the hierarchy in
> question.

Why?  What purpose does this serve?

>> David Lawrence was the one who first taught me the problems caused by
>> doing so.  For example, when people form a habit of crossposting
>> control messages to alt.config, someone limiting what hierarchies in
>> alt.* they receive, they still ends up getting control messages for the
>> hierarchies they don't want.

> Frankly, I have trouble coming up with a reason why that's bad. From
> where I sit, that's an intended result.

Why?  If I have all of my peers sending me alt.*,@alt.binaries.*, I don't
want to get control messages for alt.binaries.* either.

Date: 02 Oct 2004 12:05:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: draft-ietf-usefor-usepro-01
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Russ Allbery)  wrote on 29.09.04 in <[email-masked]>:

> Control messages should not, in general, be crossposted to other
> newsgroups than they one that they affect.

That never seemed right to me. Surely group-list changing ones should be  
crossposted to a designated control message group for the hierarchy in  
question.

>David Lawrence was the one who
> first taught me the problems caused by doing so.  For example, when people
> form a habit of crossposting control messages to alt.config, someone
> limiting what hierarchies in alt.* they receive, they still ends up
> getting control messages for the hierarchies they don't want.

Frankly, I have trouble coming up with a reason why that's bad. From where  
I sit, that's an intended result.

MfG Kai