Re: Sender header

New Message Reply About this list Date view Thread view Subject view Author view

From: Russ Allbery (rra@stanford.edu)
Date: Tue Feb 26 2002 - 13:08:16 CST


Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
> Russ Allbery <rra@stanford.edu> writes:

>> I think that's a reasonable rule for Usenet at large, in part because
>> of the whole mess of suck/rpost feeds and the ways in which header
>> munging can mess those up, but I'm rather uncomfortable with that rule
>> in the context of private hierarchies (which are *also* supposed to be
>> served by this standard).

> A cooperating subnet can always tweak a SHOULD of that nature.

Insert previous bit about how the cooperating subnet thing is to some
degree a cop-out when used in this fashion. It basically amounts to
saying "writing a news standard for all netnews articles is too hard, so
we're only going to write a standard for articles in Usenet at large and
hand-wave when it comes to private hierarchies."

Cooperating subnets for the purposes of testing radical new features is
one thing, but if it's just something routine that people would like to do
but which isn't as appropriate to Usenet at large, it would be nice to
handle it in a more formalized manner.

>> What if you're using Usenet articles for a request tracking system of
>> some kind and want to add additional status headers to the message?
>> Sure, you can just say that you're not going to follow the Usenet
>> article format, but it seems a shame to have that make software only
>> conditionally compliant just because it's configured for a private
>> hierarchy.

> Indeed, but our draft does not forbid the injector to ADD a header
> X-Tracking: .

Yeah, it was a poorly chosen example. Sorry. A better example would be
an injector that automatically added a tracking number to the subject
line, perhaps because it's also gating messages into mail and can't assume
that mail clients will preserve References information.

>> Hm. Although, I guess that isn't that big of a deal; it does make a
>> degree of sense to have private hierarchy software be only
>> conditionally compliant with standards intended primarily for Usenet at
>> large.

> Yes, that is the "cooperating subnet" letout.

Not really. That's the RFC 2119 letout, which exists regardless of
whether we define the concept of a cooperating subnet or not.

Although I see that RFC 2119 doesn't actually define fully compliant and
conditionally compliant; other standards instead add that information to
the RFC 2119 keywords. That's unfortunate; I wonder why that is?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.