Subject: Re: Shame vs Engineering

From: John Stanley <[email-masked]>
Date: Fri, 5 Aug 2005 13:03:22 -0700 (PDT)

Bruce Lilly <blilly@xxxxxxxxx>:

> They shouldn't be "options" if they don't meet the (uniqueness) 
> criterion.

Ok. But if we do make them an option, then it is ludicrous to pretend that 
they are not an option. It's just as silly to say "this is an option but 
you must not use it." And even sillier to pretend that the path identity 
of an injection agent is somehow "special" and must meet more limited 
criteria. If relaying agents can put garbage into the path, then why are 
we limiting injection agents? We should limit EVERYTHING.

>He may have no choice; IP addresses are assigned by a service provider.

It's called "static IP", and every provider I know of sells them. Even the 
little Mom and Pop ISP I use sells them. Even Qwest sells them, although 
at the time I ordered DSL they swore to me that static IP was part of the 
basic package, and only after DSL was installed did they say "pay more".

>That's something that the site administrator
>might be able to determine, but cannot in general be determined by some
>other party, 

Nobody else has to determine if the IP is static or not. It is the 
resposibility of the site admin. You don't have to be able to determine 
it. You cannot determine whether the news servers anywhere but your own 
site change IP addresses tomorrow.

>Uniqueness is guaranteed by a FQDN, but
>not by an IP address (in general) 

That's why option 2 is not "IP address in general", but has limitations on 
it.

>Let's specify that (to meet the uniqueness
>requirement) the Path entries (other than the tail-entry) MUST be FQDNs
>and move on.

Works for me. Doesn't work for UUCP sites that have no FQDN. Oh, wait, I 
have UUCP sites sans FQDN. Never mind.

>The use of the Path field entries to limit retransmissions and the
>corresponding name uniqueness requirement applies to *all* entries in
>the Path field (except the meaningless tail-entry).

No, apparently it does not. We say that injection agents MUST use specific 
options, but other agents can use any one of the four. If a relaying agent
can use an option that results in non-unique identity in the path, then 
this unique identity in the path requirement clearly does not apply to all 
entries. Should it? Probably. But that's not the issue I asked about. If
relaying and transport and serving agents can put garbage in the path 
header (where "garbage" is "non-unique identities" for the purpose of this 
discussion), then how can we pretend that there is some interoperability 
or harm if an injecting agent does it? Why should it matter where it comes 
from?

---

From: John Stanley <[email-masked]>
Date: Tue, 9 Aug 2005 16:28:34 -0700 (PDT)

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>>I see both of those as nonsense addresses.

>that's because your procmail bounced the cc that I sent you specially :(

My procmail has nothing at all to do with the way the archive mangles 
messages. I could have no .procmailrc at all and the archive would still
change the content of the messages to make them confusing at best and
downright meaninless at worst. The Chair accepts this mangling of 
messages, I guess we must, as well.

And I will keep the filters that bounce unnecessary duplications of 
messages, thanks.

>c'est la vie

Lah Veee.