Re: Shame vs Engineering

[John Stanley <[e-mail]>]

"Forrest J. Cavalier III" <forrest@xxxxxxxxxxxxxxx> in
<[e-mail]>
(http://www.imc.org/ietf-usefor/mail-archive/msg02036.html) said it all.  
Bravo, hands clapping, etc. I saw that "shame them into conforming"
comment earlier and had just as negative a reaction as you did.

So, now I'll ask for the justification for the MUST regarding which of the 
four path-identity options an injecting agent MUST use. Up until now, I 
had assumed it was proper, but I see no harm in an injecting agent using 
either a valid IP literal or UUCP name. The headers will contain enough 
other information that I can contact the site, or barring that, one of its 
neighbors who know who the site is. Am I special in my abilities to ferret 
out contact data? I don't think so.

If a relaying agent admin can be contacted even if he uses an IP literal 
or UUCP name, then why cannot an injecting agent admin? 

In fact, I've been trying to follow this "diagnostic information only" 
debate about allowing IP literals and cannot understand what the problem 
is with an IP literal in the first place (other than IPv6, where the 
problem is coding it and not in its use, per se, and where the coding 
issue can be solved trivially if my suggested "coding" is used.) Yes, IP 
addresses can change, but so can FQDN. Why is one sacred and the other 
taboo?

Henry Spencer wrote:

>There are obviously judgement calls in how to apply this, but actual
>judgement is required, not just mindless repetition of "nothing to do with
>interoperability, so take it out". 

And this insult will probably pass under the radar of the Chairs, too.

Your claim that my responses to Charles's non-sequitors is "mindless"  is
just another insult, as is your mischaracterization of my entire objection
as "nothing to do with interoperability", but hey, it's Henry, so whack
away with impunity! The Chair's away, the mice will play, the Cat will
marry the spoon, or something like that. 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6U43xch091618 for <[e-mail]>; Fri, 29 Jul 2005 21:03:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6U43xKE091617 for ietf-usefor-skb; Fri, 29 Jul 2005 21:03:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.server.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6U43w7l091610 for <[e-mail]>; Fri, 29 Jul 2005 21:03:59 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org (a.shell.peak.org [69.59.192.81]) by mail01.server.peak.org (8.12.10/8.12.8) with ESMTP id j6U43dpQ039489 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 29 Jul 2005 21:03:39 -0700 (PDT)
Date: Fri, 29 Jul 2005 21:03:53 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Shame vs Engineering
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Forrest J. Cavalier III" <forrest@xxxxxxxxxxxxxxx> in
<[e-mail]>
(http://www.imc.org/ietf-usefor/mail-archive/msg02036.html) said it all.  
Bravo, hands clapping, etc. I saw that "shame them into conforming"
comment earlier and had just as negative a reaction as you did.

So, now I'll ask for the justification for the MUST regarding which of the 
four path-identity options an injecting agent MUST use. Up until now, I 
had assumed it was proper, but I see no harm in an injecting agent using 
either a valid IP literal or UUCP name. The headers will contain enough 
other information that I can contact the site, or barring that, one of its 
neighbors who know who the site is. Am I special in my abilities to ferret 
out contact data? I don't think so.

If a relaying agent admin can be contacted even if he uses an IP literal 
or UUCP name, then why cannot an injecting agent admin? 

In fact, I've been trying to follow this "diagnostic information only" 
debate about allowing IP literals and cannot understand what the problem 
is with an IP literal in the first place (other than IPv6, where the 
problem is coding it and not in its use, per se, and where the coding 
issue can be solved trivially if my suggested "coding" is used.) Yes, IP 
addresses can change, but so can FQDN. Why is one sacred and the other 
taboo?

Henry Spencer wrote:

>There are obviously judgement calls in how to apply this, but actual
>judgement is required, not just mindless repetition of "nothing to do with
>interoperability, so take it out". 

And this insult will probably pass under the radar of the Chairs, too.

Your claim that my responses to Charles's non-sequitors is "mindless"  is
just another insult, as is your mischaracterization of my entire objection
as "nothing to do with interoperability", but hey, it's Henry, so whack
away with impunity! The Chair's away, the mice will play, the Cat will
marry the spoon, or something like that. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6U3Ye1e088368 for <[e-mail]>; Fri, 29 Jul 2005 20:34:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6U3Ye0U088367 for ietf-usefor-skb; Fri, 29 Jul 2005 20:34:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.server.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6U3YdIL088359 for <[e-mail]>; Fri, 29 Jul 2005 20:34:40 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org (a.shell.peak.org [69.59.192.81]) by mail01.server.peak.org (8.12.10/8.12.8) with ESMTP id j6U3YKpQ030847 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 29 Jul 2005 20:34:20 -0700 (PDT)
Date: Fri, 29 Jul 2005 20:34:34 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

> and we all know that MUST sends John into apoplexy :-( .

Knock it off, Charles. You know you are wrong, and you know better than
this. Your insult will probably pass un-hindered by our Chairs, however,
so congrats and slipping it in.

Do you even know what apoplexy is? Probably not. 

What causes concern is your repeated failure to justify mandates you
fabricate after multiple requests to do so, and your abuse of position to
keep unjustified mandates in the draft and thus a target for discussion.  
There are a lot of MUSTs that our drafts contain that cause me no
"apoplexy" at all, because the use is justified. Justify YOUR proposed 
MUST and end the problem, or remove it and end the problem. 

I've provided explicit replacement text, so you cannot now play the "chair
says you must provide text" game. What will it be next?

>>I think it's a SHOULD, nothing really breaks if a site only posts
>>perfect, universally welcomed, articles and doesn't have an abuse
>>address.

>And pigs might fly :-) .

And nothing really breaks if a site only posts abusive articles and does
not have an abuse address specific for the injecting agent's FQDN, because
everyone I know is able to figure out what a top level domain is and send
abuse reports there. So, your "pigs might fly" response to "nothing really 
breaks" is a waste of time.

>All "mailable" means is that there is some server somewhere that will
>accept it. If it then silently goes to devnull, then that is regrettable,
>but not much we can do about it.

I've told you that at least once, but the problem text doesn't say 
"mailable", it says "available". What is "available" and how does it 
differ from "mailable"? The assumption is that it is some form of "valid", 
since otherwise your pet algorithm wouldn't be accomplished.

>Yes, but unfortunately its status is "Proposed Standard", and it is a
>mess. So I thought it better to decide exactly which bits we wanted and
>write them down clearly.

You did NOT "decide exactly which bits [we] wanted", you CREATED a 
requirement where there was an explicit non-requirement in RFC2142. It is 
ludicrous to claim that you simply copied bits of RFC2142. It is insulting 
to everyone here for you to waste our time with that claim.

>Anyway, I need to hear opinions on this. Can those sites be excused from
>"abuse@"?

I am simply amazed at the ridiculous twists you are making to the english 
language. Now you are pretending that by following RFC2142 instead of your 
new mandate that we would be "excusing" sites from having an abuse 
reporting address. How you got to this amazing result is, well, beyond 
comprehension.

The fact is, for every injection agent that has a FQDN that YOU want to
say MUST regarding abuse@ its FQDN, there is a top level domain readily
extractable from that FQDN which ALREADY has a mandate for an abuse
reporting address.  No sites would be excused from anything. Every site
MUST have an abuse reporting address, just not necessarily at the FQDN of
the injecting agent like you want them to.

Please stop it. If anything would cause "apoplexy", it is your abuse of 
the language in your campaign to make new mandates for trivial issues, 
and your abuse of your position in keeping unwarranted mandates from 
being removed.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TL9KJI051939 for <[e-mail]>; Fri, 29 Jul 2005 14:09:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TL9K9I051938 for ietf-usefor-skb; Fri, 29 Jul 2005 14:09:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TL9IwR051931 for <[e-mail]>; Fri, 29 Jul 2005 14:09:19 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dyc52-0008Ru-Sd for [e-mail]; Fri, 29 Jul 2005 23:07:44 +0200
Received: from du-001-123.access.de.clara.net ([212.82.227.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 23:07:44 +0200
Received: from nobody by du-001-123.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 23:07:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text (Hello, Chair?)
Date:  Fri, 29 Jul 2005 23:03:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 31
Message-ID:  <[e-mail]>
References:  <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-123.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> What is you position on MUST vs SHOULD for providing at least
> one? Richard seems to be preferring SHOULD, and we all know
> that MUST sends John into apoplexy :-(

Forrest's 2119 quote is important:

| they must not be used to try to impose a particular method
| on implementors where the method is not required for
| interoperability.

We can justify a MUST about news@ / usenet@ because that's how
it always was, and NetNews is one of these very old systems
where "interoperability problems" (aka errors) have to be fixed
manually and are reported by mail (or phone).

For the mail-complaints-to better avoid 2119 keywords, and as
long as Scott doesn't catch you there is still the lower case
"must" or similar words.  Actually I think you can omit abuse@,
those who don't use mail-complaints-to (or its x-predecessor)
will also ignore any "MUST abuse@".

Their "zone cut" will be listed as abuse.rfc-ignorant, their
peers will have to share the fun, sooner or later it goes to
news.admin.policy or what's the UDP group, and they're cut off.

Unrelated:  One script that will have to implement 2231 to get
mail-complaints-to is Spamcop (using SC for news complaints is
shaky, but in simple cases like groups.google.com okay).  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TK65Yg045553 for <[e-mail]>; Fri, 29 Jul 2005 13:06:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TK65b4045552 for ietf-usefor-skb; Fri, 29 Jul 2005 13:06:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lentil.epix.net (lentil.epix.net [199.224.64.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TK65Cf045546 for <[e-mail]>; Fri, 29 Jul 2005 13:06:05 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-199-224-120-50-pppoe.dsl.hrbg.epix.net [199.224.120.50]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j6TK5vBI022615 for <[e-mail]>; Fri, 29 Jul 2005 16:05:58 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 29 Jul 2005 16:05:57 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Usefor Mailing List <[e-mail]>
Subject: Re: Shame vs Engineering
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.154
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Henry Spencer wrote:

> On Fri, 29 Jul 2005, Forrest J. Cavalier III wrote:
> 
>>...Once that is set properly,
>>we can go about removing all the MUST/MUST NOTs which have nothing to
>>do with interoperability...
> 
> 
> RFC 2119 is quite explicit that achieving minimal interoperability is not
> the only reason to use MUST/MUST NOT; they are also appropriate "to limit
> behavior which has potential for causing harm".
> 
> There are obviously judgement calls in how to apply this, but actual
> judgement is required, not just mindless repetition of "nothing to do with
> interoperability, so take it out". 

How about "avoids no harm, has no practical benefit, and has nothing to do with
interoperability, and is outside out charter?"

Sure, decisions have to be made on some points.  The Chair can set how we
arrive at that decision.

I say it is clear that RFC2119's "with care and sparingly" means that anyone who
is called to explain why MUST/MUST NOT is appropriate, must defend the use by
showing what harm or interoperability issues there are IN THE REAL APPLICATION,
not just theoretical.  And must show that there IS NO PRACTICAL ALTERNATIVE to the
intended effect.

The Chair can set a policy that anyone can question an RFC2119 imperative, and
if no one can defend its use, it gets removed.  Too many people in this WG
argue that documents have inertia, and longstanding text is assumed to be above
dispute.

RFC2119 says this...
   "They must not be used to try to impose a particular method on implementors
   where the method is not required for interoperability."

Concrete example....
Having a way to report bad behavior to injecting site admins is a good thing, but
the abuse@ mandates (that Charles advocates) are "imposing particular methods",
which is an expressly forbidden use by RFC2119.

Additionally requiring SMTP mailboxes is outside our charter/protocol/article format.

It is a stretch to say that harm is caused by having to dig into a header
for a complaints address.  Until we have digitally signed path header fields, everything
in a header field is suspect. (There is all sorts of preloading going on today, and no
way to stop or detect it.)  Encouraging reliance on being able to get at an injection
site admin by looking at the path could cause more harm than not specifying a method.
There is a reason for all of the private opaque injection info index data, and
generally complaining to any abuse@ address about a particular article will be
ignored if you do not include the opaque info from all the headers so that the
origin of the article can be verified.

And who thinks the Bad Boys and Girls on Usenet are going to be nice and
set up an effective abuse@ system?  If they aren't voluntarily going to
follow netiquette, will a "MUST" in an IETF draft give them pause?  I don't
object to text that says "users expect to be able to report problems", I object
when someone thinks that the 4 letters "MUST" are so cheap they can be used
anywhere.

I think the Chair should provide guidance in specific situations when someone
questions that RFC2119 mandates are (in)appropriate.  John questioned.  Charles
has refused to respond.  It is the chair's responsibility to restore order
by telling John the reasons he is wrong to question, or Charles the reasons
he is wrong to refuse to respond with justification.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TJWObK040676 for <[e-mail]>; Fri, 29 Jul 2005 12:32:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TJWOAa040675 for ietf-usefor-skb; Fri, 29 Jul 2005 12:32:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TJWN78040669 for <[e-mail]>; Fri, 29 Jul 2005 12:32:23 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dyaaa-0007Ee-IO for [e-mail]; Fri, 29 Jul 2005 21:32:12 +0200
Received: from du-001-123.access.de.clara.net ([212.82.227.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 21:32:12 +0200
Received: from nobody by du-001-123.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 21:32:12 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and components
Date:  Fri, 29 Jul 2005 21:29:20 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Message-ID:  <[e-mail]>
References:  <[e-mail]>                 <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-123.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 
>> Is 1.2.3.4.SEEN! some kind of private info used only by A
>> internally ?
 
> A might find it useful if he has to analyze some Path later
> on. But I suppose the intent is that it should be useful to
> others outside who _can_ be "bothered to do the check". All
> we know is that _some_ sites are doing it already (but
> without any ".SEEN" to clarify who is doing what).

Hmm...  Lots of strange things are done for obscure reasons,
if we specify it "we" should at least know what it's good for.

I better stay out of this and discuss the magic SP with Bruce.
Don't make the syntax too baroque without good reason, please.

> Or the transport medium is via Carrier Pigeon, so you write
> "Budgie.SEEN" :-) .

Now if that helps Budgie or somebody somehow...  very obscure.

                            Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TJCLKq038229 for <[e-mail]>; Fri, 29 Jul 2005 12:12:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TJCLHw038228 for ietf-usefor-skb; Fri, 29 Jul 2005 12:12:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TJCKop038208 for <[e-mail]>; Fri, 29 Jul 2005 12:12:20 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j6TJCGtS016375; Fri, 29 Jul 2005 15:12:16 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j6TJCGh8016374; Fri, 29 Jul 2005 15:12:16 -0400 (EDT)
Date: Fri, 29 Jul 2005 15:12:15 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: Shame vs Engineering
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri, 29 Jul 2005, Forrest J. Cavalier III wrote:
> ...Once that is set properly,
> we can go about removing all the MUST/MUST NOTs which have nothing to
> do with interoperability...

RFC 2119 is quite explicit that achieving minimal interoperability is not
the only reason to use MUST/MUST NOT; they are also appropriate "to limit
behavior which has potential for causing harm".

There are obviously judgement calls in how to apply this, but actual
judgement is required, not just mindless repetition of "nothing to do with
interoperability, so take it out". 

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TJ8HE6037796 for <[e-mail]>; Fri, 29 Jul 2005 12:08:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TJ8Hfn037795 for ietf-usefor-skb; Fri, 29 Jul 2005 12:08:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TJ8FZb037788 for <[e-mail]>; Fri, 29 Jul 2005 12:08:16 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DyZr0-0002My-1Q for [e-mail]; Fri, 29 Jul 2005 20:45:06 +0200
Received: from du-001-123.access.de.clara.net ([212.82.227.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 20:45:06 +0200
Received: from nobody by du-001-123.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 20:45:06 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Fri, 29 Jul 2005 20:40:41 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 70
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-123.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:
 
> I proposed something over a year ago, based on the Received
> field syntax.

Did I miss, forget it, or was it incomplete ?  Your article
some days ago was "only" the general structure, but for the
Injection-Info we need also the specific details, the most
complex part is probably mail-complaints-to.

Can't judge it without seeing it, e.g. how you want to say that
joe sender is an invalid display name because it contains the
keyword sender (or similar).

> It's been discussed off-list with the WG Chair; at last
> discussion some months ago, it didn't seem worth pursuing.

You see Charles' proposal, if you really have something better
please post it.

> [dropping off-topic stuff because it's off-topic and
>  shouldn't have been mentioned in the first place]

ACK, and after all it didn't work as a method to avoid the
2231-parameter idea in Injection-Info, I skip also this stuff.

> Please reread RFCs 2017, 2045, and 2231.

Come on, I did that more than a year ago after you told me so,
and more than once.

> (e.g. 40-character limit).

BTW unnecessary, I hate new magic numbers without good reasons.
 
> You asked where the 255 number came from.  It's the limit on
> a fully-qualified domain name length.

Yes, I didn't get your point about 255 > 78, because 255 < 998.
The 78 is "only" a SHOULD, I'd ignore it e.g. for long URLs in
the body of an article.

>> The logging-data is readable for those who insert it, for
>> everybody else it's opaque.
 
> Not much point in transmitting it then; leave it in logs on
> the originating system, referenced by message-id and/or host
> plus timestamp.

If servers can solve it _without_ local data they'll do it, I
guess that's the idea of the logging-data.  Not only technical
reasons, also legal issues (privacy, any log file that doesn't
exist can't violate a law or similar problems)

>> Sub-strings reflecting 2047-words are allowed,
> Not clear; would have to be quoted,

Yes. = and ? are no specials, but if there's a blank => quoted.

> and encoded-words aren't allowed in quotes-strings.

No, = and ? are allowed in quoted-strings, in any combination.

>> It was the 2822 view, not the 2821 view.  Here we need both,
> No, 2821 is specific to SMTP; irrelevant to our work.

See the first lines for what I meant, your propsal has also to
cover the details, like 2821 does with "for", "via", "by", etc,
- but here it would be "sender", "logging-data", etc.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6THn2hX027825 for <[e-mail]>; Fri, 29 Jul 2005 10:49:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6THn2F0027824 for ietf-usefor-skb; Fri, 29 Jul 2005 10:49:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6THn14Y027815 for <[e-mail]>; Fri, 29 Jul 2005 10:49:02 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DyYxz-00047r-Uv for [e-mail]; Fri, 29 Jul 2005 19:48:15 +0200
Received: from du-001-123.access.de.clara.net ([212.82.227.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 19:48:15 +0200
Received: from nobody by du-001-123.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 19:48:15 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Fri, 29 Jul 2005 19:42:48 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 34
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-123.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>> - do we want the IP in square brackets ?  Copy whatever a
>>   2821 Received header field does in a "from"-value.

> No, do whatever is currently done in NNTP-Posting-Host,
> which is no square brackets AFAIK (also that is our present
> syntax).

Okay.  Reason I stumbled over it:  It starts (optionally) with
<host> ":" followed by the IP.  Hard to read for an IPv6, e.g.
need.more.cafe:cafe:cafe::cafe for a future gTLD cafe.  OTOH
need.more.cafe:[cafe:cafe::cafe] could be clearer.

>> - remove nonsense remarks about "unlikely" and "gibbous"
> If people want that.

Necessity, implementor's POV.  You can't suggest in a standard
(between the lines) that it will be never as bad as it is, in
reality it will be even worse, all those strange errors.

> Those examples are just plain ugly.

I took it from 3696 (or now its errata as Bruce pointed out),
maybe you see a better example.  IMHO we need two cases, a nice
address to show "needs quotes because it has an '@'", and an
ugly case showing how to escape quotes and backslash.

> nobody has spoken against my basic methodology, so that seems
> sort of accepted.

Reluctantly, yes, unless Bruce finds a way around 2231 based on
his "do it like Received" idea.  Still hoping...  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6THZhcC026719 for <[e-mail]>; Fri, 29 Jul 2005 10:35:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6THZhEs026718 for ietf-usefor-skb; Fri, 29 Jul 2005 10:35:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lentil.epix.net (lentil.epix.net [199.224.64.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6THZgZC026712 for <[e-mail]>; Fri, 29 Jul 2005 10:35:42 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-199-224-120-50-pppoe.dsl.hrbg.epix.net [199.224.120.50]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j6THZZBI025593 for <[e-mail]>; Fri, 29 Jul 2005 13:35:35 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 29 Jul 2005 13:35:34 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Shame vs Engineering
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.135
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote, in part...

> Currently (and in our drafts for many years) checking paths is a MUST.
> 
> Yes, we know full well that it will be a long time before even 95% of
> Usenet sites do it, but shaming the slow implementors with the tag
> "non-compliant" should provide _some_ incentive for them to catch up, and
> it provides ammunition to throw at them in the news.admin.* groups.

I think it is a grave problem when drafts are written by anyone who thinks
that "shame of non-compliance" is a motivator by itself.

A specification gets voluntary compliance not because it comes from
the IETF, or disregarding it is shameful, but because implementors
agree with the consequences and benefits as explained by the specification.

I think this is a fundamental point of understanding that the Chair
gets to set, in accordance with RFC2119.  Once that is set properly,
we can go about removing all the MUST/MUST NOTs which have nothing to
do with interoperability, and replacing them with explanations of
consequences and benefits.

Implementors must be able to make ENGINEERING choices of "benefit vs cost"
instead of SOCIAL choices of "compliance vs shame."

I think John is doing a fine job of explaining this to Charles.  The
chair even ruled that RFC2119 terms must be used appropriately.
So, I am wondering why the chair isn't policing that decision when
it comes up.

Can the chair either tell John why Charles can use MUST/MUST NOT when there
are no interoperability problems (e.g. in the complaints email text), or
tell Charles to start regarding the instructions in RFC2119 and stop
using them to create shame.

Letting participants go back and forth when there is a fundamental
disagreement about whether there is an interoperability issue is not
productive.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TH7S30023477 for <[e-mail]>; Fri, 29 Jul 2005 10:07:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TH7ShG023476 for ietf-usefor-skb; Fri, 29 Jul 2005 10:07:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TH7Q93023463 for <[e-mail]>; Fri, 29 Jul 2005 10:07:27 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DyYIz-0007Y9-9J for [e-mail]; Fri, 29 Jul 2005 19:05:53 +0200
Received: from c-180-161-53.hh.dial.de.ignite.net ([62.180.161.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 19:05:53 +0200
Received: from nobody by c-180-161-53.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 29 Jul 2005 19:05:53 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: USEFOR cite by reference vs. rewriting syntax
Date:  Fri, 29 Jul 2005 18:54:49 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 138
Message-ID:  <[e-mail]>
References:  <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-161-53.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

>>>> The long-term roadmap is to fix the <msg-id> in a 2822bis

> a) it's not broken

Of course it is, you claimed that it "invented" <id-left> and
<id-right> especially because <local-part> and <domain> don't
work in news.  Obviously they failed to get it right, so now
we do it, where's the problem ?

There will be also some bugs and oddities in what we do, fixed
by a future 2822bis.  Get over the idea that 2822 is perfect
and the end of the road, and don't fear that USEFOR will be
perfect and the last word on what works in news.

We've already heard that for huge amounts of news all we do is
irrelevant because they hate MIME and love yenc and think that
NetNews is the perfect way to distribute files.  No wonder if
they are less interested in the finer points of References etc.

> b) not in our scope of work

Print the charter and pin it to your monitor, I'm tired of your
endless rants about the "normative Internet message format".

NetNews always was a proper subset, and it always will be, crap
like length 250 (instead of 320) for the <msg-id> and no ">"
and the magic SP won't make it in 2822bis, it's just too silly.

OTOH if John's plan for I18N local parts makes it nonsense like
quoted-pairs and quoted-strings will die, good riddance.  Our
job is to update 1036 for this millennium _compatible_ with
NNTP and common pratice in news.

Eliminating almost all obs-cruft of 2822 which either never
worked in news or is useless is a huge step forward.  It will
help any future 2822bis WG to delete it (or some of it, bare
CR and similar crap).

  [colon SP CRLF SP msg-id]
>> That's a substantiated fact as far as I'm concerned.  I
>> tested it.

> No, you found one mailing-list-to-news-like site that rewrote
> an ID (and which was known a priori to do so).

I tested this in three or four groups on two or three servers.
Only one of these groups was gmane.test ("moderated NG" working
as a mailing list), and I didn't test anything where I knew the
result before I saw the outcome.  I tested '":" SP CRLF SP' and
'":" HT CRLF SP'.  Roll your own tests if you don't like what I
found.

>> It's in 1036,
> RFC 1036 has (unsurprisingly) no mention of NO-WS-CTL.  While
> it mentions "printing ASCII characters", it also strongly
> discourages '/', which is not mentioned in the usefor draft.

Yes, that has to be listed in the "differences from 10336".
The first time I saw a slash some years ago in a Message-ID I
was quite upset (it was in an admin group).

> We therefore have already deviated from 1036 (which is what
> is expected from an update and revision)

Yeah, 1036 meet IPv6, IPv6 meet 1036.  So let's add the domain
literals, and be silent about BITNET and UUCP (where possible).
And add those crappy slashes while we're at it.

> a roadmap should be specified

The roadmap is clear:  msg-id = "<" id-local "@" id-domain ">"
It updates "<" unique "@" full_domain_name ">" and other old
or incompatible constructs like "<" id-left "@" id-right ">".

>> 1738,
> Obsolete and irrelevant to our work.

Two errors in six words.  For the relevance see the charter,
and for the status see <http://purl.net/net/rfc/1738> = PS.

>> NNTPbis,
> *Perhaps* suitable for documentation in an implementation
> note.

That should be a _normative_ reference, not only informative.
You have a knack to find all bugs even if you don't want it,

>> and common practice.

> No, "common practice" can't declare something to be "plain
> wrong".

After you have already printed the charter, and later read it,
now comes the final step, guess what it meands.  It explains
why 1036 plus s-o-1036 are a de-facto standard (twice, you
cannot miss it).

"publish a standards-track successor to RFC 1036 that with
 particular attention to backward compatibility, formalizes
 best current practice and best proposed practice."

Anything that doesn't work with NNTP etc. would be FUBAR, not
limited to 2822.

> A mandatory SP with unjustified RFC 2119 imperative keywords
> is new.

| Each header line consist of a keyword, a colon, a blank, and
| some additional information.

> Changes to msg-id syntax (esp. declaring the RHS not to be a
> domain; see RFC 1036) are new.

They are not "new", they are completely wrong.  Do not use the
erroneous <id-left>"@"<id-right>, use <id-local>"@"<id-domain>.

> Imposing a new requirement would require code review of all
> UAs.

Fortunately the magic SP is several decades old, it's not new,
it's only odd - I'd prefer WSP and go for FWS, but all my tests
with HT failed resulting in s/HT/SP/.  Don't think that I like
the magic SP.

> So far none have been presented.

IIRC I quoted the magic SP line in 1036 several times over the
years.  The given reason "This is a subset of the Internet
standard, simplified to allow simpler software to handle it"
makes sense, but I'm lost why it doesn't allow HT.

Starting with a magic WSP we could recommend to support a FWS.
Starting with a magic SP we can only declare this to be a
hopeless casee, and accept it as is.
                                     Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEI3F019081 for <[e-mail]>; Fri, 29 Jul 2005 09:14:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TGEImh019080 for ietf-usefor-skb; Fri, 29 Jul 2005 09:14:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEHU7019070 for <[e-mail]>; Fri, 29 Jul 2005 09:14:18 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-111.midband.mdip.bt.net ([81.144.77.111]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42ea55d8.4077.13 for [e-mail]; Fri, 29 Jul 2005 17:14:16 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6TGCuk01707 for [e-mail]; Fri, 29 Jul 2005 17:12:56 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22165
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Fri, 29 Jul 2005 15:11:11 GMT
Lines: 133
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes

>>Right, so the algorithm I am trying to establish for finding that person
>>is:
>>
>>   IF there is an Injection-Info header THEN
...................

>yes, I'm happy with that...........

>>Actually, the <path-identity> you find in the Injection-Info is supposed
>>to be the same as the one you find from the Path

>I saw that, but I did not see why that was necessary.........

>>, just so there is one
>>thing less to go wrong.

>that's not necessary

OK, you have persuade me to s/MUST/SHOULD/

>Mind you, going back to the algorithm above -- if you have a mail-
>complaints-to clause then what purpose is the path-identity serving ?

You would still use it for "news@" and "usenet@". And just for knowing who
really injected it. If it really was injected at demon, but complaints
were supposed to go to the Beeb, for some strange reason, then it would
still help to know that it was demon that put the header there.

>>Question: Clearly injecting agents have to arrange that a working abuse
>>address can be found from the above algorithm. Do you want that to be a
>>requirement with the strength of a "MUST"?

>I think it's a SHOULD, nothing really breaks if a site only posts
>perfect, universally welcomed, articles and doesn't have an abuse
>address.

And pigs might fly :-) .

But your SHOULD preference is noted. Let us hear other opinions on that.

>   the Injection-Info header field data SHOULD contain values so that
>   following this algorithm will result in a suitable email address for
>   reporting problems with the article.

>no nonsense about mailable, or making statements such as the email must
>be accepted or acted upon or anything else implausible.

All "mailable" means is that there is some server somewhere that will
accept it. If it then silently goes to devnull, then that is regrettable,
but not much we can do about it.

>   An injecting agent MUST
>   identify itself with the same <path-identity> in both Path and
>   Injection-Info header fields

>that looks like a requirement to me.  If you want to say that if it
>chooses to have an Injection-Info header field then dot dot dot then I
>suggest you changing the text. I just read it as it is.

Point taken. I now have:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref header fields. Whatever <path-identity> is
   used in the Path header field SHOULD be used also in any Injection-
   Info header field (and it would be normal to use it in any Xref
   header field also).


>>Not quite. I would not expect "news@" to work for every domain name where
>>"abuse@" worked, or vice versa. 

>OK -- well that entirely argues for going for the determine the email
>address algorithm approach, since this subtlety would make the existing
>complex wording even worse

>>"Abuse@" should go to some designated desk
>>within the organization. Ideally, I would hope that "news@" would work for
>>every serving, relaying or injecting host identifiable in the Path (that
>>is what RFC 2142 implies, though I am not insisting on quite that much
>>in my text).

>2142 was merely recording what "everyone knew" at the time.

Yes, but unfortunately its status is "Proposed Standard", and it is a
mess. So I thought it better to decide exactly which bits we wanted and
write them down clearly.

> Times change
>(and so such specialist addresses fall out of use because of the need
>for spam filtering and the rise of the specialist abuse team).

Yes, but "news@" and "usenet@" are still expected, though not necessarily
for every server internal to some site. So I still think they need a
mention. They are comparable to "postmaster@" in mail (and that has a
"MUST" behind it in RFC 2821).


>>> and I have a big problem
>>>understanding why if the injection agent doesn't offer a public service
>>>they should be excused offering abuse@ ...
>>
>>It's what our drafts have said for the last N years. If someone wants to
>>propose a change, then do so, but I suspect that small private sites
>>currently do not provide "abuse@".

>if you don't provide abuse@ then you end up in the rfc-ignorant lists
>and the ignorant blacklist your email.  Only a fool doesn't currently
>accept email addressed to abuse@

Well "clerew.man.ac.uk" hasn't landed in rfc-ignorant yet :-) .

The point is that there are all sorts of small sites, private peering
arrangements, and so on.

Anyway, I need to hear opinions on this. Can those sites be excused from
"abuse@"?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEHXC019068 for <[e-mail]>; Fri, 29 Jul 2005 09:14:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TGEHtB019067 for ietf-usefor-skb; Fri, 29 Jul 2005 09:14:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEGX9019051 for <[e-mail]>; Fri, 29 Jul 2005 09:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-111.midband.mdip.bt.net ([81.144.77.111]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42ea55d7.4077.12 for [e-mail]; Fri, 29 Jul 2005 17:14:15 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6TGCRR01492 for [e-mail]; Fri, 29 Jul 2005 17:12:27 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22162
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and components
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>                 <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 29 Jul 2005 14:09:15 GMT
Lines: 67
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Russ Allbery wrote:

>> I'm more coming at this from the angle that large news sites
>> with hundreds of peers are likely to look at path checking
>> and decide to just not bother.

OTOH, even though they might not bother with the hard work of checking,
there is a reasonable chance that they would add '.SEEN', since there is
no rocket science involved there.

>Okay, and why would they want to use *.SEEN ?  Your example:

>A!1.2.3.4!C!...

>A inserted 1.2.3.4, the IP of C, or rather the IP of a site
>claiming to be C, unverified.  Charles transformed it into:

>A!1.2.2.4.SEEN!C!...

>Is the idea that A knows what it did, and won't send this
>article back to 1.2.3.4 ?  I'm a bit lost with news paths.

The idea is that, if C intends to use "C" as its <path-identity>, then it
so informs its peers, who then enter "C" into their 'sys' files (along
with any other aliases they are told about - even 1.2.3.4).

But nobody in his right mind is going to enter an identity ending in
".SEEN" into his 'sys' file, and nobody in his right mind is going to tell
his peers that he will use such an identity (but, for sure, we shall see
various trolls trying it on :-( ).

>Is 1.2.3.4.SEEN! some kind of private info used only by A
>internally ?

A might find it useful if he has to analyze some Path later on. But I
suppose the intent is that it should be useful to others outside who _can_
be "bothered to do the check". All we know is that _some_ sites are doing
it already (but without any ".SEEN" to clarify who is doing what).


>Adding "POSTED" to these examples would help.  So far I
>think we can forget "!*.MATCH!", because "!!" is better.

I only put "MATCH" in the set for the sake of completeness. The final text
would discourage its use without good cause.

OTOH, you need to bear in mind that the "SEEN" IP will not always be an
automatic match for the last identity shown in the Path. Suppose the
relaying takes place over a dial-up link. Then some
authentication-identity is probably the correct thing to put in the
SEEN/Whichever. Or take my case, where the relaying goes through an SSH
tunnel, and will appear to the server to have come from a different
machine than my own (which doesn't have a fixed IP anyway). Or the
transport medium is via Carrier Pigeon, so you write "Budgie.SEEN" :-) .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEGYP019058 for <[e-mail]>; Fri, 29 Jul 2005 09:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TGEGU5019057 for ietf-usefor-skb; Fri, 29 Jul 2005 09:14:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEFDu019049 for <[e-mail]>; Fri, 29 Jul 2005 09:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-111.midband.mdip.bt.net ([81.144.77.111]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42ea55d6.4077.11 for [e-mail]; Fri, 29 Jul 2005 17:14:14 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6TGCiD01607 for [e-mail]; Fri, 29 Jul 2005 17:12:44 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22163
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 29 Jul 2005 14:23:00 GMT
Lines: 53
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>- replace <mailbox> by <addr-spec> for the sender

I might buy that.

>- maybe replace <address-list> by a new <addr-spec-list>
>  (we need no <display-name> or <group>, we have CFWS)

But that is departing from the usual syntax as use in Reply-To and the
like. And a <display -name> ("AOL Abuse Desk") could actually be useful.
Moreover, it is useful to have a few folding points in it somewhere, just
in case the <address-list> get inconveniently long.

>- maybe replace <dot-atom> by <dot-atom-text> for the host

Yes, I think so

>- do we want the IP in square brackets ?  Copy whatever a
>  2821 Received header field does in a "from"-value.

No, do whatever is currently done in NNTP-Posting-Host, which is no square
brackets AFAIK (also that is our present syntax).

>- remove nonsense remarks about "unlikely" and "gibbous"

If people want that.

>- remove useless remarks about I18N and non-ASCII, those
>  who want it will find it in 2231 and 3066bis

Maybe. It is a bit more useful that the line-folding gibbousness.

>- update the example to show both " => \" and \ => \\,
>  add another example showing @ => must be quoted string

Those examples are just plain ugly. At least the "Joe Q. Public" is a case
that might actually arise, and one where your average reader can probably
figure out what problem you are trying to solve.

Anyway, nobody has spoken against my basic methodology, so that seems
sort of accepted.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEEZq019037 for <[e-mail]>; Fri, 29 Jul 2005 09:14:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TGEEx6019036 for ietf-usefor-skb; Fri, 29 Jul 2005 09:14:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEC2u019028 for <[e-mail]>; Fri, 29 Jul 2005 09:14:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-111.midband.mdip.bt.net ([81.144.77.111]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42ea55d3.4077.e for [e-mail]; Fri, 29 Jul 2005 17:14:11 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6TGCof01658 for [e-mail]; Fri, 29 Jul 2005 17:12:50 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22164
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 29 Jul 2005 14:29:34 GMT
Lines: 28
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>>    IF there is an Injection-Info header THEN
................

>Okay, now I think I see the problem:  What you want is in fact
>no "MUST abuse@<p-id>", but a "MUST mail-complaints-to" with a
>default abuse@<p-id>.

Not quite. You MUST provide _one_ of the mechanisms. We might not care
which (or we might drop some hint that one or other is preferable).

What is you position on MUST vs SHOULD for providing at least one? Richard
seems to be preferring SHOULD, and we all know that MUST sends John into
apoplexy :-( .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEE1s019045 for <[e-mail]>; Fri, 29 Jul 2005 09:14:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TGEE7W019044 for ietf-usefor-skb; Fri, 29 Jul 2005 09:14:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TGEDKV019030 for <[e-mail]>; Fri, 29 Jul 2005 09:14:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-111.midband.mdip.bt.net ([81.144.77.111]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42ea55d4.4077.f for [e-mail]; Fri, 29 Jul 2005 17:14:12 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6TGCHl01420 for [e-mail]; Fri, 29 Jul 2005 17:12:17 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22161
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Fri, 29 Jul 2005 12:33:32 GMT
Lines: 34
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Henry Spencer <[e-mail]> writes:

>> Not exactly:  that's the current semantics, and it makes sense (as in
>> Charles's latest proposal) to express it with the current syntax, a `!'
>> between the names.  Anything *else* should be expressed otherwise.

>Hm, yeah, that's a good point.  That might be sufficient (which means that
>we can't strongly deprecate ! since there are configurations where people
>will continue using it, unless we're intending to require or strongly
>recommend that everyone check paths).

Currently (and in our drafts for many years) checking paths is a MUST.

Yes, we know full well that it will be a long time before even 95% of
Usenet sites do it, but shaming the slow implementors with the tag
"non-compliant" should provide _some_ incentive for them to catch up, and
it provides ammunition to throw at them in the news.admin.* groups. And I
think we agree that widespread adoption would make it much harder for
Mallet and his cronies.

But that point is discussable.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TG4pc0017970 for <[e-mail]>; Fri, 29 Jul 2005 09:04:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TG4o7V017969 for ietf-usefor-skb; Fri, 29 Jul 2005 09:04:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TG4oVL017961 for <[e-mail]>; Fri, 29 Jul 2005 09:04:50 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j6TG4ltS014124; Fri, 29 Jul 2005 12:04:47 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j6TG4lEK014123; Fri, 29 Jul 2005 12:04:47 -0400 (EDT)
Date: Fri, 29 Jul 2005 12:04:47 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: USEFOR cite by reference vs. rewriting syntax (Was Re: USEPRO 7.9 gateway)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri, 29 Jul 2005, Bruce Lilly wrote:
> > The mandatory SP is not new...
> 
> There's nothing in 1036 that specifies that "blank" means SP

SP is also known as "blank", and there is no indication that 1036 is using
the term in a more generic sense.  In particular, when 1036 wishes to say
that either SP or HT is acceptable, it explicitly says "blank or tab". 
The terminology may not quite meet modern standards of rigor, but its
meaning is plain.

> nor that says that it's mandatory.

"Each header line consist of a keyword, a colon, a blank, and some
additional information."  There is no provision for the blank to be
omitted, any more than for the keyword or the colon to be omitted.

> Nearly two decades later, if there isn't a very
> good reason to require a mandatory SP, we shouldn't do so.

All previous news specifications (RFC and non-RFC) have required it, and
there definitely exists news software which insists on it.  The reasons
just don't come much better than that. 

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TFccx2015626 for <[e-mail]>; Fri, 29 Jul 2005 08:38:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TFccrR015625 for ietf-usefor-skb; Fri, 29 Jul 2005 08:38:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TFcccD015619 for <[e-mail]>; Fri, 29 Jul 2005 08:38:38 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 0C64C29A40; Fri, 29 Jul 2005 11:38:37 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6TFcYv5019092(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 29 Jul 2005 11:38:34 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6TFcXVG019091(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 29 Jul 2005 11:38:33 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: USEFOR cite by reference vs. rewriting syntax (Was Re: USEPRO 7.9 gateway)
Date: Fri, 29 Jul 2005 11:38:30 -0400
User-Agent: KMail/1.8.1
Cc: Henry Spencer <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri July 29 2005 11:25, Henry Spencer wrote:
> 
> On Fri, 29 Jul 2005, Bruce Lilly wrote:
> > > We're not inventing something new, and [gateways] already do what is
> > > necessary.
> > 
> > A mandatory SP with unjustified RFC 2119 imperative keywords is new.
> 
> The mandatory SP is not new, and the only reason RFC 1036 (and 850) didn't
> use RFC 2119 keywords for it is that the keywords hadn't been invented
> yet.  The form of description may be new, but the (mis)feature being
> described is not. 

There's nothing in 1036 that specifies that "blank" means SP, nor that
says that it's mandatory.  Nearly two decades later, if there isn't a very
good reason to require a mandatory SP, we shouldn't do so.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TFPsKU014663 for <[e-mail]>; Fri, 29 Jul 2005 08:25:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TFPspi014662 for ietf-usefor-skb; Fri, 29 Jul 2005 08:25:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TFPrC5014653 for <[e-mail]>; Fri, 29 Jul 2005 08:25:53 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j6TFPotS013511; Fri, 29 Jul 2005 11:25:50 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j6TFPoEP013510; Fri, 29 Jul 2005 11:25:50 -0400 (EDT)
Date: Fri, 29 Jul 2005 11:25:50 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: USEFOR cite by reference vs. rewriting syntax (Was Re: USEPRO 7.9 gateway)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri, 29 Jul 2005, Bruce Lilly wrote:
> > We're not inventing something new, and [gateways] already do what is
> > necessary.
> 
> A mandatory SP with unjustified RFC 2119 imperative keywords is new.

The mandatory SP is not new, and the only reason RFC 1036 (and 850) didn't
use RFC 2119 keywords for it is that the keywords hadn't been invented
yet.  The form of description may be new, but the (mis)feature being
described is not. 

                                                          Henry Spencer
                                                       [e-mail]




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TEm1tI010436 for <[e-mail]>; Fri, 29 Jul 2005 07:48:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TEm1To010435 for ietf-usefor-skb; Fri, 29 Jul 2005 07:48:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns2.townisp.com (ns2a.townisp.com [216.195.0.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TEm15g010429 for <[e-mail]>; Fri, 29 Jul 2005 07:48:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns2.townisp.com (Postfix) with ESMTP id 53F13299FF; Fri, 29 Jul 2005 10:48:00 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6TEloXp018690(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 29 Jul 2005 10:47:52 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6TElowr018689(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 29 Jul 2005 10:47:50 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date: Fri, 29 Jul 2005 10:47:46 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 28 2005 04:32, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > 822 does not define anything called "CFWS", much less
> > "[CFWS]". Those are defined in 2822.
> 
> Please propose a complete Injection-Info, I've just retracted
> my proposal.

I proposed something over a year ago, based on the Received field syntax.
If you want ABNF, take the 2822 Received field syntax, change the field
name and optionally drop the semicolon and timestamp.

It's been discussed off-list with the WG Chair; at last discussion
some months ago, it didn't seem worth pursuing.

> > Since our "document uses a cite by reference methodology,
> > rather than repeating the contents of other" documents, what
> > precisely are you suggesting if not a reference?
> 
> Anything that's not handled by reference (or differs) has to
> be specified, by copying similar constructs like the RfC 3834
> Auto-Submitted etc.

Since we're committed (sect. 1.6) not to rewrite syntax, that leaves
a reference citation.  Incidentally, 3834 uses MIME 2045/2231/errata
syntax.

[dropping off-topic stuff because it's off-topic and shouldn't have
been mentioned in the first place]
 
> >> FQDNs are used everywhere in header fields, why should that
> >> be different for the posting-host value ?
> 
> > Parameter values, unlike domains in other parts of structured
> > fields, must be quoted if folded.
> 
> Yes, but there are many [FWS] in the unquoted version, just fold
> it as needed, and then quote it with embedded FWS:
> 
>    foo = "b
>  ar"

Not likely to be interoperable. Please reread RFCs 2017, 2045, and 2231.
Note that 2017 applies to a specific parameter to a specific field when
used with a specific media type, and imposes several special constraints
(e.g. 40-character limit).  Note that 2231 provides an alternate,
uniform mechanism for handling long parameters and gives an example which
precisely covers the RFC 2017 case.

> >> You only need 2231 folding where embedded WSP can be sigificant
> >> (file names)
> 
> > No, quoting works for that.
> 
> In file names WSP is sigificant, you cannot freely replace SP by
> FWS, or insert FWS whereeveer you need it.

Nor can one do so in any other parameter without specific specification
of such syntax (see RFC 2017 for an example).


> Therefore you have to 
> use enumerated quoted strings:
> 
>     foo*0 = "b"
>     foo*1 = "ar"

That is quite different from your earlier example, which contained
embedded CR LF SP in the parameter value.
 

> > As we're talking about domain names, see RFC 1034 (sect. 3.1) and RFC
> > 1035 (sect. 2.3.4) as well as RFC 1123 (sect. 2.1).
> 
> I'm pretty sure that these standards don't talk about >> 255 for FQDNs.

You asked where the 255 number came from.  It's the limit on a fully-
qualified domain name length.

> Forget it, 255 is nothing we need to worry about, and 998 > 255 is
> clear for all implementors.

255 >> 78, and RFC 2822 gives a recommended maximum line length of 78
octets per line (not including CRLF) [we cite 2822 as normative].  If
you want to use 2017-like syntax, 255 >> 40.
 
> > some IDN advocates claim hat 8-bit stuff (i.e. not encoded) are
> > equally> valid
> 
> We're not doing I18N for

newsgroup names.  We address I18N via MIME for suitable header field
content (unstructured fields, words in phrases, in comments).  I18N
for domain names has been specified and applies to domain names where
they may appear (in LDH format).

> > We could define a structured field that avoids the issues raised
> > by trying to put such things in parameters.
> 
> If you have a good idea _without_ 2231 I'm very interested.

See above (and 2822 ABNF for Received).
 
> > So in this case you think that
> >   Injection-Info:
> >    (continuation line) foo.example.com
> > (i.e. SP on first line followed immediately by line folding) is OK?
> > Inconsistency detected.
> 
> Rough WG consensus, some proposals to fix [CFWS] were rejected.
> It is addressed in prose, for any trailing [CFWS] even in 2822.

No, there's no whitespace-only continuation line there; all perfectly
valid per 2822.  But there's only an SP after the colon on the first
line, in accordance with your proposed ABNF but contradicting the
unjustified BCP 14 imperative mandated non-whitespace on every line.
 
> > 1. unlike something based strictly on 2045/2231/errata, there are
> >    no existing implementations which could be adapted
> 
> It's the same as 2045 without 2231 (or that was the design idea,
> my bad if I didn't get it right).

See 2017 for the additional things that need to be specified for
implementations to discard embedded FWS.  That would of course
require new code in implementations.
 
> > 2. if intended to be human-readable ("to assist in tracing"), it
> >    fails to provide for specification of charset and language (BCP
> >    18), particularly for logging-data
> 
> The logging-data is readable for those who insert it, for everybody
> else it's opaque.

Not much point in transmitting it then; leave it in logs on the
originating system, referenced by message-id and/or host plus timestamp.
 
> >    and display name parts of address-lists
> 
> Sub-strings reflecting 2047-words are allowed,

Not clear; would have to be quoted, and encoded-words aren't allowed in
quotes-strings.  Not likely to be interoperable.

> and the display-name 
> is irrelevant at best.

It's specified in mailbox, address, address-list...
 
> > See the concise and clear syntax of the Received field (recently
> > posted separately) for a parameter-less syntax
> 
> Yes, I saw it.  It was the 2822 view, not the 2821 view.  Here we
> need both,

No, 2821 is specific to SMTP; irrelevant to our work.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TECN7Y007294 for <[e-mail]>; Fri, 29 Jul 2005 07:12:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6TECNhj007293 for ietf-usefor-skb; Fri, 29 Jul 2005 07:12:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6TECMTt007287 for <[e-mail]>; Fri, 29 Jul 2005 07:12:23 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id B16B7299FC; Fri, 29 Jul 2005 10:12:21 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6TECET2018443(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 29 Jul 2005 10:12:20 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6TECDoc018442(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 29 Jul 2005 10:12:14 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: USEFOR cite by reference vs. rewriting syntax (Was Re: USEPRO 7.9 gateway)
Date: Fri, 29 Jul 2005 10:12:07 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 28 2005 06:22, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:

> > Nor does it imply anything about best practice, which
> > is what we're supposed to be working on.
> 
> "Sometimes 'colon SP HT CRLF SP body' works" is not what I
> what to read in a standard.

What I'd like to read -- given the fact that numerous people have on
multiple occasions said that rewriting syntax is a problem and that
our stated methodology is to cite by reference -- is "use the Internet
Message Format as defined in RFC 2822, supplemented by extension
fields...".  *If* there is some specific justification, supplemented by
implementation notes documenting existing problems in widely-deployed
software with workarounds and a roadmap for conformance to 2822.
Definitely NOT rewritten syntax with various and sundry changes but
no rationale for the changes, especially since the stated methodology
says that won't be done.

> >> The long-term roadmap is to fix the <msg-id> in a 2822bis

a) it's not broken
b) not in our scope of work

> >> for 
> >> full conformance with what USEFOR will say, because NO-WS-CTL
> >> was plain wrong.
> 
> > That's an unsubstantiated assertion.
> 
> That's a substantiated fact as far as I'm concerned.  I tested
> it.

No, you found one mailing-list-to-news-like site that rewrote an ID
(and which was known a priori to do so).

> It's in 1036,

RFC 1036 has (unsurprisingly) no mention of NO-WS-CTL.  While it mentions
"printing ASCII characters", it also strongly discourages '/', which is
not mentioned in the usefor draft.  We therefore have already deviated
from 1036 (which is what is expected from an update and revision), and we
should continue to do so in order to converge with the Internet Message
Format specification except where there is a serious issue (in which case
the issue, workarounds, and a roadmap should be specified).

> s-o-1036,

Not a standard of any type, not an RFC of any type, not even a draft.

> 1738,

Obsolete and irrelevant to our work.

> NNTPbis,

*Perhaps* suitable for documentation in an implementation note.

> and common practice.     

No, "common practice" can't declare something to be "plain wrong".
  
> > "Change every gateway" is perhaps feasible
> 
> We're not inventing something new, and they already do what is
> necessary.

A mandatory SP with unjustified RFC 2119 imperative keywords is new.
Changes to msg-id syntax (esp. declaring the RHS not to be a domain;
see RFC 1036) are new.  Etc.
 
> > "change every UA" is unthinkable
> 
> Dito, all newsreaders know how to get it right.  Including all
> existing combined mail + news UAs.

Imposing a new requirement would require code review of all UAs.  Only
warranted if there's a very good reason.  So far none have been presented.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6T4VKuQ087251 for <[e-mail]>; Thu, 28 Jul 2005 21:31:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6T4VK53087250 for ietf-usefor-skb; Thu, 28 Jul 2005 21:31:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lentil.epix.net (lentil.epix.net [199.224.64.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6T4VJ0W087242 for <[e-mail]>; Thu, 28 Jul 2005 21:31:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-202-88-pppoe.dsl.hrbg.epix.net [216.37.202.88]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j6T4VCBI021476 for <[e-mail]>; Fri, 29 Jul 2005 00:31:13 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 29 Jul 2005 00:31:10 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New USEPRO path-identity text
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.133
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

John Stanley wrote:

> Excuse me, could you say that a little bit louder? Our draft editor isn't 
> noticing the number of people who say "remove the mandate". 
> 

I have no idea why the chair didn't step in and bounce all of this discussion.
It has NOTHING AT ALL TO DO WITH ARTICLE SYNTAX (USEFOR) and only marginally
has something to do with exchanging them (USEPRO.)

At BEST all this text being discussed belongs in USEAGE, and I prefer it not
appear there either.

And its use of RFC2119 imperatives is wrong.

It is unacceptable that a document editor conceives that RFC2119 imperatives are
"carrots and sticks."[1]  Their only proper use is specifying minimum requirements
for correct interoperation with specific features.  A NEWS standard cannot mandate
anything regarding other protocols and formats, no matter how good the carrot
tastes or how big a whelt mark the stick makes.  (And since this is VOLUNTARY
COMPLIANCE, the IETF has no sticks, just absence of carrots.)

Forrest

[1] - Charles wrote the following on 7/20/2005 in <[e-mail]>
which indicates a shocking ignorance of the proper use of RFC2119 terms....

    It was always considered that implementors would be more likely
    to implement the new features more quickly if we wrote a few MUSTs to
    encourage them (take your choice as to whether that counts as a carrot or
    a stick  :-)




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6T3jKxP084142 for <[e-mail]>; Thu, 28 Jul 2005 20:45:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6T3jKN7084141 for ietf-usefor-skb; Thu, 28 Jul 2005 20:45:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6T3jJJE084131 for <[e-mail]>; Thu, 28 Jul 2005 20:45:19 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org (a.shell.peak.org [69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6T3j2Q7093783 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 28 Jul 2005 20:45:03 -0700 (PDT)
Date: Thu, 28 Jul 2005 20:45:13 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Moreover it is up to that organization to designate its preferred "abuse@"
>domain, rather that have it tied to some mythical "top level" 

Not according to RFC2142, which we are not free to change and is not the 
subject of our working group. 

And your inability to understand the simple concept "top level domain" 
does not make the top level domain any more mythical than your inability 
to understand electronics would make electrons mythical.

>Right, so the algorithm I am trying to establish for finding that person
>is:

Your "algorithm" creates new RFC2119 mandates and contradicts existing 
standards in areas that are outside the scope of the USEFOR working group.
Any acceptable algorithm must live within the constraints of the problem.

>Question: Clearly injecting agents have to arrange that a working abuse
>address can be found from the above algorithm.

Not clearly at all. You can fabricate a thousand different algorithms and 
the injecting agent admins (not "injecting agents", since injecting agents 
are pieces of software that cannot arrange anything on their own) are not 
bound by any of it, unless you can justify the mandates so that your 
algorithm can be considered and validly entered into a standards document.
Finding text in a standard just because the editor wanted to put it there 
and the chair didn't act to prevent it" is a silly way to write standards.

>But I would like us to agree on what the complaints procedure is to be, 

It is not our job to define what the "complaints procedure" is, certainly 
not using interoperability-level mandates. It is our job to define how the 
news system works. If "abuse reports" are part of the "news system", then 
they fall under "usenet/news" addressing and the problem is moot. 
Otherwise, not our problem. It's a problem already solved by an existing 
RFC.

>Sure. I was merely pointing out that RFC 2821 used the dreaded "MUST" word
>in much the same context as I was trying to use it,

And it has been pointed out to you that you are patently wrong when you
make that claim. "abuse" has nothing to do with administration and
configuration of a protocol; "postmaster" does. The context is different.  
But the context is the same for "postmaster" and "usenet/news", and that
is one reason that I do not find any issue in repeating a mandate for
those addresses.

>      ELSE
>         use "abuse@<path-identity>"

People can "use" whatever they want when they send abuse reports, and they 
sometimes do. Telling them to use an address that you know is OPTIONAL is 
hardly productive. Perhaps you should rewrite your "algorithm" in light of 
the existing standards, which would be:

	ELSE
		use "abuse @ top-level-domain-of-path-identity"

That is what RFC2142 tells you, that is certainly good enough for us, 
unless you have some NEW stab at interoperability problems that justifies 
an RFC2119 mandate?

>   ELSE
>      Locate the <path-identity> of the injecting agent in the Path
>      header (it should be followed by "POSTED");
>      use "abuse@<path-identity>"

Ditto this clause. 

>The MUST relates to providing enough information for my algorithm above to
>work.

RFC2119 does not list "making sure that Charles's pet algorithms work" as
a justification for MUST language. There is no interoperability issue.

>The
>question at issue was whether the "MUST" word could be used at all in the
>context of ensuring that a clear route to an abuse address exists.

And has been pointed out to you numerous times, the MUST word is already 
being used in the context of ensuring that a route to an abuse address 
exists -- in RFC2142. And RFC2142 is just as explicit in saying that that 
address is NOT required for anything but a top level domain. Yes, I know, 
you can't figure out what a "top level domain" is, but I assure you, lots 
of people dumber than you are can and do figure it out every day.

>>>My proposal regarding "abuse" is less onerous than for 2142

>>That is a patently false, and you know better, because it has been
>>explained to you multiple times now.

>You have made assertions based on reading the first 8 words of the
>sentence which are quite nonsensical in the context established by the
>remainder of the sentence, which continues:

I went through each part of the remainder of your sentence and showed that
your proposal was either more onerous or made no difference. You cannot be
"less onerous" if the main thrust of your argument is more onerous and the
rest is the same. Less has a meaning;  please look it up if you don't
understand it. In fact, since your requirements are "greater than or equal 
to", your use of "less" is particularly insulting.

>If you intend to deliberately ignore the structure of what is written, and
>to pick out arbitrary sequences in the middle of a sentence for criticism,
>then I see little point in continuing this exchange.

Each part was dealt with at length.

If you refuse to justify the mandates you want for a section of the new
standard, then I see little point in continuing this exchange.  
Unfortunately, because you are the editor of this new standard, you are
able to put whatever you want into the text and it appears that nobody is
going to fix this problem. Our chairs are ignoring it. Thanks for nothing.

Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:

>Okay, now I think I see the problem:  What you want is in fact
>no "MUST abuse@<p-id>", 

What he wants is, I assume, what he has written and what he so fervently 
refuses to discuss on a reasonable level: a MUST that contradicts RFC2142 
without RFC2119 or any other reasonable justification.

>In other words, if abuse@<p-id> exists,
>a mail-complaints-to might be omitted, although that's not a
>good idea.  Is that so far correct ?

RFC2142 tells that that abuse@ is OPTIONAL (NOT required AT ALL) for 
anything but the top level domain. One cannot make it "mandatory unless 
other conditions are met" without contradicting RFC2142 which has NO 
conditions on the optional status of that address. 

And considering that abuse@ the top level domain is already mandatory, as 
well as usenet and news at the specific host, there is no justification 
for requiring it to be anything more than completely optional for the 
specific injecting agent. "Completely optional" is not "MUST/unless", it 
is "MAY" or even perhaps "SHOULD", but certainly not "MUST".

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>yes, but there should be a simple default if they do not so designate

If a domain owner has not designated the "default" recipient of mail sent 
to the mandatory abuse address for his domain, he is already violating 
RFC2142, and we have no reason to expect him to be any more fastidious in 
his adherance to USEPRO or USEFOR or USAGE. Yes, there are people who 
explicitely ignore RFC2142, and who continue to ignore it after being 
eductated as to its existance. They are not our problem, nor are they 
within the scope of our working group.

>So now you only need to say that if people
>choose to have an Injection-Info header field they should ensure that
>following this algorithm will result in a suitable address for reporting
>problems with the article.

Why do I predict that if Charles follows this suggestion and writes new 
text to put into USEPRO, he will have converted the "should ensure" into 
some RFC2119 mandate?

>2142 was merely recording what "everyone knew" at the time. Times change
>(and so such specialist addresses fall out of use because of the need
>for spam filtering and the rise of the specialist abuse team). Hence I
>don't a huge value in repeating any of what is in 2142 if it's not an
>actual requirement to make the system work.

Excuse me, could you say that a little bit louder? Our draft editor isn't 
noticing the number of people who say "remove the mandate". 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SJgWTe047370 for <[e-mail]>; Thu, 28 Jul 2005 12:42:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SJgWEY047369 for ietf-usefor-skb; Thu, 28 Jul 2005 12:42:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SJgU61047363 for <[e-mail]>; Thu, 28 Jul 2005 12:42:31 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-30.mail.demon.net with esmtp (Exim 4.42) id 1DyEGz-000PKL-2w for [e-mail]; Thu, 28 Jul 2005 19:42:30 +0000
Message-ID: <[e-mail]>
Date: Thu, 28 Jul 2005 20:41:14 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <HX2$+Lav77P5EOKLSOW+dOQI+7>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes

>>The basic idea is that someone stands up and takes responsibility for
>>articles that are injected into the system. In principle, they can stop
>>further articles by cancelling an account, barring a user, manually
>>checking future posts or whatever.
>
>Moreover it is up to that organization to designate its preferred "abuse@"
>domain, 

yes, but there should be a simple default if they do not so designate

>Right, so the algorithm I am trying to establish for finding that person
>is:
>
>   IF there is an Injection-Info header THEN
>      IF it includes a "mail-complaints-to" parameter THEN
>         use that address
>      ELSE
>         use "abuse@<path-identity>"
>      FI
>   ELSE
>      Locate the <path-identity> of the injecting agent in the Path
>      header (it should be followed by "POSTED");
>      use "abuse@<path-identity>"
>   FI

yes, I'm happy with that.   So now you only need to say that if people
choose to have an Injection-Info header field they should ensure that
following this algorithm will result in a suitable address for reporting
problems with the article.

>Actually, the <path-identity> you find in the Injection-Info is supposed
>to be the same as the one you find from the Path

I saw that, but I did not see why that was necessary. By making that a
requirement you are complicating things (because the path-identity in
the Injection-Info header field may have some relationship to email
handling, whereas the one in the Path header field has no such need)

>, just so there is one
>thing less to go wrong.

that's not necessary -- besides, if they mismatched should people
discard the article as malformed ?

Mind you, going back to the algorithm above -- if you have a mail-
complaints-to clause then what purpose is the path-identity serving ?

>Question: Clearly injecting agents have to arrange that a working abuse
>address can be found from the above algorithm. Do you want that to be a
>requirement with the strength of a "MUST"?

I think it's a SHOULD, nothing really breaks if a site only posts
perfect, universally welcomed, articles and doesn't have an abuse
address.  I like my words above as it happens

   the Injection-Info header field data SHOULD contain values so that
   following this algorithm will result in a suitable email address for
   reporting problems with the article.

no nonsense about mailable, or making statements such as the email must
be accepted or acted upon or anything else implausible.

I stick with my position that in 2005 everyone but everyone has an email
address, even people at the far end of mythical UUCP links.

>>For this purpose we have the Injection-Info: header field.  This field
>>is a MUST requirement according to 2.3 (though mysteriously in 3.1 it is
>>described as optional and in USEFOR it is said to be optional).
>
>No, I don't see that in 2.3. 

   An injecting agent MUST
   identify itself with the same <path-identity> in both Path and
   Injection-Info header fields

that looks like a requirement to me.  If you want to say that if it
chooses to have an Injection-Info header field then dot dot dot then I
suggest you changing the text. I just read it as it is.

>Certainly, provision of Injection-Info has
>always been a SHOULD, so it is not mandatory. If someone wants to change
>that, then speak up (though I detect some reluctance to create more
>mandatory headers).

Almost everyone generates one of the many variants.... so it is not a
huge imposition. However, given my remarks above about newsparadise.com
(or wherever) that never needs to trace anything and never has
complaints, then I don't suppose it reaches MUST status.

>>Anyway, we need to have a set of rules for what it says in this header
>>field and quite clearly (from above) it needs to be an identity from
>>which one can trivially obtain a domain, prepend abuse@, news@ or
>>usenet@ and have email delivered to the correct place.
>
>Not quite. I would not expect "news@" to work for every domain name where
>"abuse@" worked, or vice versa. 

OK -- well that entirely argues for going for the determine the email
address algorithm approach, since this subtlety would make the existing
complex wording even worse

>"Abuse@" should go to some designated desk
>within the organization. Ideally, I would hope that "news@" would work for
>every serving, relaying or injecting host identifiable in the Path (that
>is what RFC 2142 implies, though I am not insisting on quite that much
>in my text).

2142 was merely recording what "everyone knew" at the time. Times change
(and so such specialist addresses fall out of use because of the need
for spam filtering and the rise of the specialist abuse team). Hence I
don't a huge value in repeating any of what is in 2142 if it's not an
actual requirement to make the system work.

>>So I come back to the point made above -- viz: that what's needed is the
>>rules for the complainer to follow, then a statement that says that this
>>MUST yield a valid email address.  Then drop all the rest of the guff.
>
>Indeed, the text could be recast in that form. 

I recommend it

>> and I have a big problem
>>understanding why if the injection agent doesn't offer a public service
>>they should be excused offering abuse@ ...
>
>It's what our drafts have said for the last N years. If someone wants to
>propose a change, then do so, but I suspect that small private sites
>currently do not provide "abuse@".

if you don't provide abuse@ then you end up in the rfc-ignorant lists
and the ignorant blacklist your email.  Only a fool doesn't currently
accept email addressed to abuse@

but what I was puzzled about was why a "non-public service" was the
distinction ?  if the articles reach the main feed then the status of
the injecting site is not going to matter much one way or another

>

To restate (for the skip-reading) my slightly refined proposal:

a) set out the algorithm for deducing the email address to write to, the
one Charles proposed looks OK to me

b) make it a SHOULD that there is an Injection-Info header field and
that the information in that field yields a suitable email address, when
the algorithm is applied, to reach the people responsible for the
injection event.

c) someone needs to justify why there is a path-identity in the
Injection-Info at all (let alone why it has to match the Path), there's
two completely different things going on (where did it come from, who do
I complain to) and mixing them up is (apparently) pointless

d) drop all mention of news@ and usenet@  (leave 2142 to its own
devices)

e) I appreciate I'm going for "email only" to deal with complaints. I
think it's possible (and realistic) for all sites as a base level
complaint mechanism.

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQuk02poAxkTY1oPiEQIvdgCfUdmlxU1+4pEFryOhXQQJ4wGHcRoAn1ot
mk49V5gzPaqsEFNX+9efbI7T
=7YVh
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SJ1vl9044389 for <[e-mail]>; Thu, 28 Jul 2005 12:01:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SJ1vQH044388 for ietf-usefor-skb; Thu, 28 Jul 2005 12:01:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SJ1tox044374 for <[e-mail]>; Thu, 28 Jul 2005 12:01:56 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DyDdY-0000n4-Rf for [e-mail]; Thu, 28 Jul 2005 21:01:44 +0200
Received: from du-042-036.access.de.clara.net ([213.221.65.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 21:01:44 +0200
Received: from nobody by du-042-036.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 21:01:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and components
Date:  Thu, 28 Jul 2005 20:51:56 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 28
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-042-036.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery wrote:

> I'm more coming at this from the angle that large news sites
> with hundreds of peers are likely to look at path checking
> and decide to just not bother.

Okay, and why would they want to use *.SEEN ?  Your example:

A!1.2.3.4!C!...

A inserted 1.2.3.4, the IP of C, or rather the IP of a site
claiming to be C, unverified.  Charles transformed it into:

A!1.2.2.4.SEEN!C!...

Is the idea that A knows what it did, and won't send this
article back to 1.2.3.4 ?  I'm a bit lost with news paths.

Is 1.2.3.4.SEEN! some kind of private info used only by A
internally ?  Traditional path id.s separated by "!", new
path id.s separated by "!!", "!*.SEEN!", "!*.MISMATCH!" ?

Adding "POSTED" to these examples would help.  So far I
think we can forget "!*.MATCH!", because "!!" is better.

                    Bye, Frank





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SH8S6A032643 for <[e-mail]>; Thu, 28 Jul 2005 10:08:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SH8SaR032642 for ietf-usefor-skb; Thu, 28 Jul 2005 10:08:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SH8SmZ032636 for <[e-mail]>; Thu, 28 Jul 2005 10:08:28 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6SH8RIj021974 for <[e-mail]>; Thu, 28 Jul 2005 10:08:27 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 4519DE7928; Thu, 28 Jul 2005 10:08:27 -0700 (PDT)
To: [e-mail]
Subject: Re: #1047 Path field delimiters and components
In-Reply-To: <[e-mail]> (Frank Ellermann's message of "Thu, 28 Jul 2005 18:39:14 +0200")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Thu, 28 Jul 2005 10:08:27 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann <[e-mail]> writes:

> If Russ' example was meant to demonstrate that ignorants will do
> whatever pleases them, then hoping that they adopt "*.SEEN" would be
> futile.

No, I'm more coming at this from the angle that large news sites with
hundreds of peers are likely to look at path checking and decide to just
not bother.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SH7adM032585 for <[e-mail]>; Thu, 28 Jul 2005 10:07:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SH7aeh032584 for ietf-usefor-skb; Thu, 28 Jul 2005 10:07:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SH7ZkV032577 for <[e-mail]>; Thu, 28 Jul 2005 10:07:35 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6SH7YVw000378 for <[e-mail]>; Thu, 28 Jul 2005 10:07:35 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id B52A6E7928; Thu, 28 Jul 2005 10:07:34 -0700 (PDT)
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
In-Reply-To: <[e-mail]> (Henry Spencer's message of "Thu, 28 Jul 2005 12:58:45 -0400 (EDT)")
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Thu, 28 Jul 2005 10:07:34 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Henry Spencer <[e-mail]> writes:
> On Thu, 28 Jul 2005, Russ Allbery wrote:

>> I did mean what I said, yeah.  MISMATCH implies some degree of checking
>> has happened and the Path failed, which strikes the wrong tone for a
>> site that just doesn't want to bother checking anything at all and has
>> no idea if the Path would have passed or not.  It seems like we have a
>> (fairly common) bit of semantics that we have no way to express.

> Not exactly:  that's the current semantics, and it makes sense (as in
> Charles's latest proposal) to express it with the current syntax, a `!'
> between the names.  Anything *else* should be expressed otherwise.

Hm, yeah, that's a good point.  That might be sufficient (which means that
we can't strongly deprecate ! since there are configurations where people
will continue using it, unless we're intending to require or strongly
recommend that everyone check paths).

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SH7Bwr032550 for <[e-mail]>; Thu, 28 Jul 2005 10:07:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SH7BZU032549 for ietf-usefor-skb; Thu, 28 Jul 2005 10:07:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SH79YH032540 for <[e-mail]>; Thu, 28 Jul 2005 10:07:10 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DyBpy-0007Dz-Ju for [e-mail]; Thu, 28 Jul 2005 19:06:26 +0200
Received: from du-042-165.access.de.clara.net ([213.221.65.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 19:06:26 +0200
Received: from nobody by du-042-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 19:06:26 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text (Hello, Chair?)
Date:  Thu, 28 Jul 2005 19:04:10 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Message-ID:  <[e-mail]>
References:  <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-042-165.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>    IF there is an Injection-Info header THEN
>       IF it includes a "mail-complaints-to" parameter THEN
>          use that address
>       ELSE
>          use "abuse@<path-identity>"
>       FI
>    ELSE
>       Locate the <path-identity> of the injecting agent in the Path
>       header (it should be followed by "POSTED");
>       use "abuse@<path-identity>"
>    FI

Okay, now I think I see the problem:  What you want is in fact
no "MUST abuse@<p-id>", but a "MUST mail-complaints-to" with a
default abuse@<p-id>.  In other words, if abuse@<p-id> exists,
a mail-complaints-to might be omitted, although that's not a
good idea.  Is that so far correct ?

If "yes" what you have is essentially correct.  But it was not
exactly obvious for two or three users here, so maybe it needs
a better explanation / motivation than the "MUST abuse@<p-id>".

                       Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGwvDD031929 for <[e-mail]>; Thu, 28 Jul 2005 09:58:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGwvW9031928 for ietf-usefor-skb; Thu, 28 Jul 2005 09:58:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGwu4o031922 for <[e-mail]>; Thu, 28 Jul 2005 09:58:56 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j6SGwktS028126; Thu, 28 Jul 2005 12:58:46 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j6SGwjhs028125; Thu, 28 Jul 2005 12:58:45 -0400 (EDT)
Date: Thu, 28 Jul 2005 12:58:45 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu, 28 Jul 2005, Russ Allbery wrote:
> I did mean what I said, yeah.  MISMATCH implies some degree of checking
> has happened and the Path failed, which strikes the wrong tone for a site
> that just doesn't want to bother checking anything at all and has no idea
> if the Path would have passed or not.  It seems like we have a (fairly
> common) bit of semantics that we have no way to express.

Not exactly:  that's the current semantics, and it makes sense (as in
Charles's latest proposal) to express it with the current syntax, a `!'
between the names.  Anything *else* should be expressed otherwise. 

His suggestion of using `!!' to indicate what we hope will eventually be
the usual situation -- address verified -- seems good to me.  That's
supposed to be a common case, so it should be terse, yet distinct from the
old common case. 

Exactly how we indicate other situations, I'm less concerned about.

> > ...you should never consider the diagnostic
> > entries when deciding whether or not an article has already passed
> > through a given site... That suggests that it should be immediately 
> > obvious, somehow, which entries are diagnostic and which not...
> 
> I don't know that it matters if you do or not.  I have a hard time seeing
> a scenario where it would realistically make a difference.

I'm inclined to agree, given that any realistic convention *must* be
designed so that sites which don't make the distinction will nevertheless
almost always get the right answer as to whether the article has already
passed through a neighboring site. 

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGhWbT030740 for <[e-mail]>; Thu, 28 Jul 2005 09:43:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGhWut030739 for ietf-usefor-skb; Thu, 28 Jul 2005 09:43:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGhUR7030714 for <[e-mail]>; Thu, 28 Jul 2005 09:43:31 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DyBTf-00030k-6y for [e-mail]; Thu, 28 Jul 2005 18:43:23 +0200
Received: from du-042-165.access.de.clara.net ([213.221.65.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 18:43:23 +0200
Received: from nobody by du-042-165.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 18:43:23 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and components
Date:  Thu, 28 Jul 2005 18:39:14 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 48
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-042-165.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> path-address is any domain, IP address or UUCP-like address,
> and is used for all of path-identity, path-source and
> tail-entry. That might be changed later, but it will do for
> now.

SHOULD be changed.  I'd like to split obs-name and tail-entry
(allowing hyphen) from a proper FQDN ("mailable", no hyphen).

What Bruce, Harald, Russ, and you discuss asks for IP as 3rd
case (or only case ?) in the case of a <path-source>.

> 1. downstream.example.com!123.123.123.123.SEEN!upstream.example.com...
> 2. downstream.example.com!123.123.123.123.MISMATCH!upstream.example.com...
> 3. downstream.example.com!123.123.123.123.MATCH!upstream.example.com...
> 4. downstream.example.com!!upstream.example.com...
> 5. downstream.example.com!upstream.example.com...

> All the diagnostic <path-source>s are immediately
> distinguishable from the <path-identity>s by the presence
> of a big uppercase keyword.

Interesting.  It certainly answers Russ' question.

> Ex2.
[...]
> Some current practice uses exactly that notation.

Not exactly, but similar.

> Ex3.
[...]
> In which case you may ask why it bothered to clutter the Path
> by quoting it in full.

Yes, example 4 and !! is shorter => *.MATCH isn't needed.

> OK, all that is still half baked, but hopefully it shows some
> interesting possibilities.

Yes.  Does somebody really need and want the "*.SEEN" case ?

If Russ' example was meant to demonstrate that ignorants will
do whatever pleases them, then hoping that they adopt "*.SEEN"
would be futile.
                          Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGUYOb029846 for <[e-mail]>; Thu, 28 Jul 2005 09:30:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGUYHV029845 for ietf-usefor-skb; Thu, 28 Jul 2005 09:30:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGUXFf029838 for <[e-mail]>; Thu, 28 Jul 2005 09:30:33 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6SGUWqG021877 for <[e-mail]>; Thu, 28 Jul 2005 09:30:33 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9E0F1E7928; Thu, 28 Jul 2005 09:30:32 -0700 (PDT)
To: [e-mail]
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu, 28 Jul 2005 13:39:48 GMT")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Thu, 28 Jul 2005 09:30:32 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:

> And I read it as meaning exactly what it said - that another keyword (or
> maybe some other syntactic device) might help to indicate exactly what
> the various items in the Path were trying to say. And I saw some merit
> in the idea.

I did mean what I said, yeah.  MISMATCH implies some degree of checking
has happened and the Path failed, which strikes the wrong tone for a site
that just doesn't want to bother checking anything at all and has no idea
if the Path would have passed or not.  It seems like we have a (fairly
common) bit of semantics that we have no way to express.

> One essential difference between a conventional Path entry and a purely
> diagnostic entry is that you should never consider the diagnostic
> entries when deciding whether or not an article has already passed
> through a given site, and therefore need not be relayed back to it. That
> suggests that it should be immediately obvious, somehow, which entries
> are diagnostic and which not (a slight generalization of what Russ was
> wondering about).

I don't know that it matters if you do or not.  I have a hard time seeing
a scenario where it would realistically make a difference.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE8g3027708 for <[e-mail]>; Thu, 28 Jul 2005 09:14:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGE8Aj027707 for ietf-usefor-skb; Thu, 28 Jul 2005 09:14:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE6ZX027676 for <[e-mail]>; Thu, 28 Jul 2005 09:14:07 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-72.midband.mdip.bt.net ([81.144.65.72]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e9044d.dc5.5b for [e-mail]; Thu, 28 Jul 2005 17:14:05 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6SGCFp14190 for [e-mail]; Thu, 28 Jul 2005 17:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22144
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Thu, 28 Jul 2005 15:24:10 GMT
Lines: 151
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes

>>My proposed requirements for "news" and "usenet" are less onerous than for
>>2142. Do you have a problem with that?

My understanding has always been that you used "news"/"usenet" for
technical issues ("Do you realize that articles are looping through your
site?", or "do you realize that you have group X wrongly configured as
moderated (or not)?". Generally, those addresses go to the one news-clueful
person in the organization, and it is counterproductive to smother such
people in spam complaints. However, there is some need to contact those
tech people at both relaying and injecting agents.

OTOH, you use "abuse" for complaints of spam, phishing, etc, and that
address typically goes to some droid totally without clue :-( .

>I'm reading usepro-4 here, which is the one on the IETF site, and this
>whole area is just getting baroque :(

>The basic idea is that someone stands up and takes responsibility for
>articles that are injected into the system. In principle, they can stop
>further articles by cancelling an account, barring a user, manually
>checking future posts or whatever.

Moreover it is up to that organization to designate its preferred "abuse@"
domain, rather that have it tied to some mythical "top level" (yes, if you
send it to the 'wrong' address, it MAY get passed on to the right person
eventually - IF you are lucky).

>The rest of the planet needs to know who that person is and needs to be
>able to send email to them.  Traditionally, one used news@ or usenet@
>but these days abuse@ will reach a specialist team rather than the
>administrators, so that's what most people use.

Right, so the algorithm I am trying to establish for finding that person
is:

   IF there is an Injection-Info header THEN
      IF it includes a "mail-complaints-to" parameter THEN
         use that address
      ELSE
         use "abuse@<path-identity>"
      FI
   ELSE
      Locate the <path-identity> of the injecting agent in the Path
      header (it should be followed by "POSTED");
      use "abuse@<path-identity>"
   FI

Actually, the <path-identity> you find in the Injection-Info is supposed
to be the same as the one you find from the Path, just so there is one
thing less to go wrong.

Question: Clearly injecting agents have to arrange that a working abuse
address can be found from the above algorithm. Do you want that to be a
requirement with the strength of a "MUST"?


>For this purpose we have the Injection-Info: header field.  This field
>is a MUST requirement according to 2.3 (though mysteriously in 3.1 it is
>described as optional and in USEFOR it is said to be optional).

No, I don't see that in 2.3. Certainly, provision of Injection-Info has
always been a SHOULD, so it is not mandatory. If someone wants to change
that, then speak up (though I detect some reluctance to create more
mandatory headers).

>Anyway, we need to have a set of rules for what it says in this header
>field and quite clearly (from above) it needs to be an identity from
>which one can trivially obtain a domain, prepend abuse@, news@ or
>usenet@ and have email delivered to the correct place.

Not quite. I would not expect "news@" to work for every domain name where
"abuse@" worked, or vice versa. "Abuse@" should go to some designated desk
within the organization. Ideally, I would hope that "news@" would work for
every serving, relaying or injecting host identifiable in the Path (that
is what RFC 2142 implies, though I am not insisting on quite that much
in my text).

>-=-=-=-=-


>So I come back to the point made above -- viz: that what's needed is the
>rules for the complainer to follow, then a statement that says that this
>MUST yield a valid email address.  Then drop all the rest of the guff.

Indeed, the text could be recast in that form. But I would like us to
agree on what the complaints procedure is to be, and whether "news/usenet"
needs different treatment from "abuse" (like whether it needs to work at
relaying agents found in the Path) and so on, and which bits of it are
MUST/SHOULD/should/MAY, before I start writing new text.

>>My proposal regarding "abuse" is less onerous than for 2142 insofar as it
>>is not required for relaying agents and it is not required if there is a
>>suitable parameter in Injection-Info, and it is not required for private
>>servers. Do you have a problem with that?

>I have a problem with understanding which part of the Injection-Info
>header field is being talked about,

The "mail-complaints-to" paramater, if present

> and I have a big problem
>understanding why if the injection agent doesn't offer a public service
>they should be excused offering abuse@ ...

It's what our drafts have said for the last N years. If someone wants to
propose a change, then do so, but I suspect that small private sites
currently do not provide "abuse@".


>>My use of RFC 2119 language is consistent with its use to describe the
>>"postmaster" address in RFC 2821 (and note that what is there defined is
>>slightly different from RFC 2142). Do you have a problem with RFC 2821?

>the world is full of people who have problems with the postmaster@
>requirements of 2821. That's a can of worms that is best left alone here

Sure. I was merely pointing out that RFC 2821 used the dreaded "MUST" word
in much the same context as I was trying to use it, and nobody was
complaining about 2821 on that ground.

>>My proposal regarding "abuse" is more onerous that for 2142 insofar as it
>>requires you either to provide an MX record for the <path-identity> used
>>for injection or else to choose a <path-identity> which is already your
>>"top level domain". And it does so with "MUST" wording. Evidently you do
>>have a problem with that.

>yes, and so do I

>write the rules for the complainant, leave how that is made to work
>alone; it's far too complex to describe the general case :(

The MUST relates to providing enough information for my algorithm above to
work. Providing suitable MX records is just one way of achieving that. The
question at issue was whether the "MUST" word could be used at all in the
context of ensuring that a clear route to an abuse address exists.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE6Tl027669 for <[e-mail]>; Thu, 28 Jul 2005 09:14:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGE6fo027667 for ietf-usefor-skb; Thu, 28 Jul 2005 09:14:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE52A027619 for <[e-mail]>; Thu, 28 Jul 2005 09:14:05 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-72.midband.mdip.bt.net ([81.144.65.72]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e9044b.dc5.5a for [e-mail]; Thu, 28 Jul 2005 17:14:03 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6SGCDj14182 for [e-mail]; Thu, 28 Jul 2005 17:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22142
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 28 Jul 2005 13:39:48 GMT
Lines: 110
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>........ I read Russ' statement
>"I wonder if we need another keyword that says 'I haven't bothered to check
>whether the Path is right; here's the IP address just for the hell of it.'"
>as a satirical comment on the silliness of inserting diagnostic information
>(an IP address) w/o the keyword explicitly provided for indication of
>diagnostic information -- that having been your suggestion, Charles.

And I read it as meaning exactly what it said - that another keyword (or
maybe some other syntactic device) might help to indicate exactly what the
various items in the Path were trying to say. And I saw some merit in the
idea.

>Which brings us back to reserving use of IP addresses for diagnostic use as
>discussed a month ago.

It is a bit premature to be reserving certain addresses for diagnostic use
until it has been clarified what "diagnostic uses" are envisioned. At the
moment, the only diagnostic provision in the protocol as set out in USEPRO
is for an address followed by MISMATCH. It is now apparent that people are
including other addresses for diagnostic reasons, and I think we are
agreed that some further provision is needed.

One essential difference between a conventional Path entry and a purely
diagnostic entry is that you should never consider the diagnostic entries
when deciding whether or not an article has already passed through a given
site, and therefore need not be relayed back to it. That suggests that
it should be immediately obvious, somehow, which entries are diagnostic
and which not (a slight generalization of what Russ was wondering about).

So here is an alternative syntax which might achieve that:

   path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF
   path-entry = path-identity [ "!" "POSTED" ] [ "!" / path-source ]
   path-source = path-address ( ".SEEN" / ".MATCH" / ".MISMATCH" )
   path-identity = path-address
   tail-entry = path-address

where path-address is any domain, IP address or UUCP-like address, and is
used for all of path-identity, path-source and tail-entry. That might be
changed later, but it will do for now.

In the following examples, "upstream.example.com" is a site which has
just sent an article (or so it is claimed) to "downstream.example.com".
"123.123.123.123" is the IP address from which downstream received it,
which may or may not be the IP address of upstream. The examples show the
full <path-entry> inserted by downstream, followed by (at least the start
of) the <path-entry> inserted by upstream.

1. downstream.example.com!123.123.123.123.SEEN!upstream.example.com...
2. downstream.example.com!123.123.123.123.MISMATCH!upstream.example.com...
3. downstream.example.com!123.123.123.123.MATCH!upstream.example.com...
4. downstream.example.com!!upstream.example.com...
5. downstream.example.com!upstream.example.com...

All the diagnostic <path-source>s are immediately distinguishable from the
<path-identity>s by the presence of a big uppercase keyword.

Even if you thought 123.123.123.123 was a site to which you were not
supposed to send articles, no current implementation would recognize it as
such in any of those examples.

Ex1. Downstream recorded that 123.123.123.123 was the source of the
article "just for the hell of it". It makes no claim to have verified that
it belonged to upstream.

Ex2. Downstream recorded that 123.123.123.123 was the source of the
article and asserted that it no way matched any known address associated
with upstream. Some current practice uses exactly that notation.

Ex3. Downstream recorded that 123.123.123.123 was the source of the
article and asserted that it was indeed a known address used by upstream.
In which case you may ask why it bothered to clutter the Path by quoting
it in full.

Ex4. Downstream noted the IP (whatever) of the source and asserts that it
was indeed a known address used by upstream. But it did not clutter the
Path with unnecessary detail. That is the notation proposed in the current
drafts, and will hopefully be the commonest case.

Ex5. Downstream made no checks and makes no assertions. That is
essentially current practice which we hope will be replaced by Ex4 over
time.

I have shown no example using the optional "!POSTED", but that would only
be inserted by an injecting agent, in which case any <path-source> shown
would presumably be the posting host.

NOTE: The use of an IP address for the <path-source> in the examples does
not imply that a corresponding domain name could not have been used
instead (indeed, it would be more user-friendly to have done so). So Ex3
could as well have been written
3. downstream.example.com!upstream.example.com.MATCH!upstream.example.com...

Observe that folding is not allowed in the middle of a <path-entry>.

OK, all that is still half baked, but hopefully it shows some interesting
possibilities.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE2kI027600 for <[e-mail]>; Thu, 28 Jul 2005 09:14:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGE2vt027597 for ietf-usefor-skb; Thu, 28 Jul 2005 09:14:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE0Ma027536 for <[e-mail]>; Thu, 28 Jul 2005 09:14:01 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-72.midband.mdip.bt.net ([81.144.65.72]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e90448.dc5.59 for [e-mail]; Thu, 28 Jul 2005 17:14:00 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6SGCH714208 for [e-mail]; Thu, 28 Jul 2005 17:12:17 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22147
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1003 Message-ID issues - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Thu, 28 Jul 2005 15:48:51 GMT
Lines: 45
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Thu July 21 2005 09:59, Harald Tveit Alvestrand wrote:

>> - Charles suggested adding a dot to the examples:
>> 
>> 3.1.3  Message-ID
>> 
>>    <[e-mail]>
>>    <"abcd"@example.com>
>>    <"ab\cd"@example.com>
>> s/abcd/ab.cd/
>> s/"abcd"/"ab.cd"/
>> s/"ab\cd"/"ab.\cd"/
>> 
>> so as to illustrate the <dot-atom-text> bug found by Frank, and to agree
>> with the NNTP draft.
>> 
>> I think that's uncontroversial.

>local-part (and its non-folded equivalent id-left) does not require a dot.
>I don't know what "bug" is being referenced, could you please provide a
>URI or message identifier.

An <id-left> can be a <dot-atom-text> as in <[e-mail]>.

An <id-left> can also be a <quoted-string> as in <"ab.cd"@example.com>

Since those two would be regarded as different by news-servers, it is
necessary to forbid one of them (the 2nd one in fact).

At one time our syntax failed to do that. It has now been fixed to cover
such cases, and the example has been updated to illustrate the problem (as
well as continuing to illustrate the various other forbidden cases).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE2QL027599 for <[e-mail]>; Thu, 28 Jul 2005 09:14:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGE2tA027598 for ietf-usefor-skb; Thu, 28 Jul 2005 09:14:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGE0Rf027529 for <[e-mail]>; Thu, 28 Jul 2005 09:14:01 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-72.midband.mdip.bt.net ([81.144.65.72]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e90444.dc5.58 for [e-mail]; Thu, 28 Jul 2005 17:13:56 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6SGCGM14198 for [e-mail]; Thu, 28 Jul 2005 17:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22145
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 28 Jul 2005 15:31:00 GMT
Lines: 35
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Thu July 21 2005 10:21, Charles Lindsey wrote:

>> The instructions given in USEPRO come in 2 steps:
>> 
>> 9. If there is no Path already present, then you create one with a
>> <tail-entry> (typically "not-for-mail").
>> 
>> 10. You then *prepend* the <path-identity> of the injecting agent,
>> together with a "POSTED", to the Path (which is now guaranteed to be
>> there by the previous step).

>Charles, you have previously claimed that the text is not prescriptive --
>that processing need not occur in discrete step in a specific order so
>long as the end result is consistent; make up your mind.

So? If you follow the steps in the order given, then you encounter a MUST
in Step 10 which tells you to prepend certain things.

If you choose to do things in a different order (for example by combining
Steps 9 and 10 into a single operation in circumstances where that is
possible), then those same things MUST still land up at the head of the
Path.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGDwut027514 for <[e-mail]>; Thu, 28 Jul 2005 09:13:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGDwXp027512 for ietf-usefor-skb; Thu, 28 Jul 2005 09:13:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGDus4027465 for <[e-mail]>; Thu, 28 Jul 2005 09:13:57 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-72.midband.mdip.bt.net ([81.144.65.72]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e90442.dc5.55 for [e-mail]; Thu, 28 Jul 2005 17:13:54 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6SGCHA14204 for [e-mail]; Thu, 28 Jul 2005 17:12:17 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22146
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Thu, 28 Jul 2005 15:40:44 GMT
Lines: 29
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>My proposal regarding "abuse" is less onerous than for 2142

>That is a patently false, and you know better, because it has been
>explained to you multiple times now.

You have made assertions based on reading the first 8 words of the
sentence which are quite nonsensical in the context established by the
remainder of the sentence, which continues:

>> ... insofar as it is not required for relaying agents 

If you intend to deliberately ignore the structure of what is written, and
to pick out arbitrary sequences in the middle of a sentence for criticism,
then I see little point in continuing this exchange.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGDwWa027517 for <[e-mail]>; Thu, 28 Jul 2005 09:13:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGDwTQ027515 for ietf-usefor-skb; Thu, 28 Jul 2005 09:13:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGDuTT027476 for <[e-mail]>; Thu, 28 Jul 2005 09:13:57 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-72.midband.mdip.bt.net ([81.144.65.72]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e90443.dc5.57 for [e-mail]; Thu, 28 Jul 2005 17:13:55 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6SGCCT14172 for [e-mail]; Thu, 28 Jul 2005 17:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22141
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1082 USEFOR 3.2.9 Need more text about Approved header field seman
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Thu, 28 Jul 2005 11:47:50 GMT
Lines: 43
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Alexey Melnikov <[e-mail]> writes:

>Charles Lindsey wrote:

>>The 1st paragraph could usefully mention moderation and control
>>messages as the two most important applications of this header.
>>  
>>
>This seems reasonable to me.

OK, I proposed an actual sentence in response to Frank.

>>There should also be a sentence (maybe in a NOTE) such as the
>>following
>>
>>The presence of a this header implies a claim to have authority
>>to post the article, thus assisting other sites to determine
>>whether to accept or act upon it.
>>
>>in order to explain the semantics of this header.
>>
>>Alternatively, you might want this to be dealt with in USEAGE.
>>  
>>
>Yes, the note belongs to USEAGE.

I have no particular problem with writing it into USEAGE. There was one
response from Frank which could be interpreted as slight support for
leaving it in USEFOR.

Let us wait a day or so for further opinions, with a presumption that it
goes into USEAGE unless we hear otherwise.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGDwWf027516 for <[e-mail]>; Thu, 28 Jul 2005 09:13:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SGDwfp027511 for ietf-usefor-skb; Thu, 28 Jul 2005 09:13:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SGDuCT027455 for <[e-mail]>; Thu, 28 Jul 2005 09:13:57 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-72.midband.mdip.bt.net ([81.144.65.72]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e90442.dc5.56 for [e-mail]; Thu, 28 Jul 2005 17:13:54 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6SGCEg14186 for [e-mail]; Thu, 28 Jul 2005 17:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22143
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 28 Jul 2005 13:47:44 GMT
Lines: 24
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Yes, the same Russ said that he hates CFWS and 2231 (or that's
>how I remember it).

Well we all hate 2231, but Russ did also say that he was no longer going
to oppose the use of MIME-style parameters in Injection-Info, and I think
that sealed the consensus to which we are now working.

Also, we agreed to do away with Complaints-To, and to stick with just mail
addresses for complaints (with room for a future extension parameter for
other possibilities). So I don't think it helps much for people to keep
going back over that ground again.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SB5tD1053041 for <[e-mail]>; Thu, 28 Jul 2005 04:05:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6SB5tsf053040 for ietf-usefor-skb; Thu, 28 Jul 2005 04:05:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6SB5rxR053023 for <[e-mail]>; Thu, 28 Jul 2005 04:05:53 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dy6CV-0000ml-UH for [e-mail]; Thu, 28 Jul 2005 13:05:19 +0200
Received: from c-180-160-233.hh.dial.de.ignite.net ([62.180.160.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 13:05:19 +0200
Received: from nobody by c-180-160-233.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 13:05:19 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: USEPRO 7.9 gateway
Date:  Thu, 28 Jul 2005 12:22:09 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 69
Message-ID:  <[e-mail]>
References:  <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-160-233.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> So in this case you found some software that doesn't accept
> that specific instance of a Message-ID field.

Yes, same order of header fields as in all my other tests.

> Which does not necessarily say anything about *all* fields
> (certainly not ones newly defined in our documents) or about
> other implementations.

Yes, just for fun I now also tested Date before Message-ID,
and 'colon SP HT CRLF SP info' _only_ in the Date:

Date: 	
 Thu, 28 Jul 2005 11:55:52 +0200
Message-ID: <[e-mail]>
From: Frank Ellermann <[e-mail]>
Organization: <URL:http://purl.net/xyzzy>
X-Mailer: Mozilla 3.0 (OS/2; U)
MIME-Version: 1.0
Newsgroups: junk
Subject: SP HT CRLF SP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

for Bruce / USEFOR

This worked modulo some header field sorting:
<http://article.gmane.org/junk:338:raw>

For obscure reasons my browser crashes whenever I try to
save the raw file on disk - I cannot see the SP HT in the
normal "view source" mode.  <sigh>

dosx rxgeturl article.gmane.org/junk:338:raw
unix

Apparently it's there.  The magic SP survived this test.
Please do NOT expect me to test all permutations for all
header fields.   Start your own tests, everybody can use
news://news.spamcop.net/spamcop.test

> Nor does it imply anything about best practice, which
> is what we're supposed to be working on.

"Sometimes 'colon SP HT CRLF SP body' works" is not what I
what to read in a standard.

>> The long-term roadmap is to fix the <msg-id> in a 2822bis for
>> full conformance with what USEFOR will say, because NO-WS-CTL
>> was plain wrong.

> That's an unsubstantiated assertion.

That's a substantiated fact as far as I'm concerned.  I tested
it.  It's in 1036, s-o-1036, 1738, NNTPbis, and common practice.

> "Change every gateway" is perhaps feasible

We're not inventing something new, and they already do what is
necessary.

> "change every UA" is unthinkable

Dito, all newsreaders know how to get it right.  Including all
existing combined mail + news UAs.
                                  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S9oZuT026208 for <[e-mail]>; Thu, 28 Jul 2005 02:50:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6S9oZKg026207 for ietf-usefor-skb; Thu, 28 Jul 2005 02:50:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S9oXiX026188 for <[e-mail]>; Thu, 28 Jul 2005 02:50:34 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dy51w-0008Nf-4N for [e-mail]; Thu, 28 Jul 2005 11:50:20 +0200
Received: from 212.82.251.111 ([212.82.251.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 11:50:20 +0200
Received: from nobody by 212.82.251.111 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 11:50:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Thu, 28 Jul 2005 10:32:20 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 169
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.111
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> 822 does not define anything called "CFWS", much less
> "[CFWS]". Those are defined in 2822.

Please propose a complete Injection-Info, I've just retracted
my proposal.  TTBOMK we inherit tons of CFWS from 2822, incl.
leading and trailing [CFWS] for several values.  We could add
it everywhere for consistency, or remove it everywhere if that
is possible.

Don't forget [CFWS] before and after "verified" in your idea,
and everywhere between the name and the "=".

> Since our "document uses a cite by reference methodology,
> rather than repeating the contents of other" documents, what
> precisely are you suggesting if not a reference?

Anything that's not handled by reference (or differs) has to
be specified, by copying similar constructs like the RfC 3834
Auto-Submitted etc.

==============================================================
 [OT SPF issues]
> No, embraced by spammers

Instruct Ned's spammer, apparently a hard case of rule #3, it's
not yet completely "adopted" by spammers unfortunately (where
adoption means stop forging)

> Harmful to legitimate senders

Hogwash, based on 1,000 backscatter mails per day for 6 months
in 2004 it saved me from giving up "my" xyzzy vanity host, and
if you ever changed your primary address you know what that's
about.  Now 11 months without this backscatter, if you ever had
a modem you might also know why I couldn't afford to handle the
about 11 * 30 * 1000 = 330,000 backscatter mails.

> As discussed in detail elsewhere, and which need not be
> repeated here.

You spread FUD in public, I answer in public.  I have a FAIL
policy for about 15 months now.

> Suffice to say that SPF isn't a good model unless one wants
> a document that will be relegated to Experimental status.

1.000.000 domains (not my estimate) or 85% of all mails (also
not my estimate, I only contributed to reduce this from 95% to
85%) are no "experiment".  That's only a trick to abuse these
policies for another incompatible "anti-phishing" scheme.

The latter is really "experimental".  They found no volunteers,
that's why they want to steal the installed base, and needed
the IESG to "legalize" this blatant abuse as an "experiment".
==============================================================

>> FQDNs are used everywhere in header fields, why should that
>> be different for the posting-host value ?

> Parameter values, unlike domains in other parts of structured
> fields, must be quoted if folded.

Yes, but there are many [FWS] in the unquoted version, just fold
it as needed, and then quote it with embedded FWS:

   foo = "b
 ar"

>> You only need 2231 folding where embedded WSP can be sigificant
>> (file names)

> No, quoting works for that.

In file names WSP is sigificant, you cannot freely replace SP by
FWS, or insert FWS whereeveer you need it.  Therefore you have to
use enumerated quoted strings:

    foo*0 = "b"
    foo*1 = "ar"

> RFC 2231 fragmentation might not be *necessary* in some circumstances,
> but it can still be *used* to split long values.  Without introducing
> ambiguity.

Okay, let's say I buy one "bar", if we'll have security considerations
as proposed elsewhere.  Not "unlikely" plus "gibbous", it's a real PITA.

> As we're talking about domain names, see RFC 1034 (sect. 3.1) and RFC
> 1035 (sect. 2.3.4) as well as RFC 1123 (sect. 2.1).

I'm pretty sure that these standards don't talk about >> 255 for FQDNs.
Forget it, 255 is nothing we need to worry about, and 998 > 255 is
clear for all implementors.

> some IDN advocates claim hat 8-bit stuff (i.e. not encoded) are
> equally> valid

We're not doing I18N for NetNews, the old usefor-07 failed, that idea
was dropped and left as an exercise for a future USEFOR2 WG.  It's a
good strategy, officially we're updating 1036, repeating the complete
Internet history of two decades in one giant jump cannot work.  Some
of us are wooried about UUCP hosts "wolf" and "cafe", others have
serious questions about a "Subject: cmsg", adding I18N is no option,
let's forget it.

> Or encoded.

ACK, I tend to forget this because nobody uses it (and I would see
it, my UA doesn't support 2231):

    title*0*=us-ascii'en'This%20is%20even%20more%20
    title*1*=%2A%2A%2Afun%2A%2A%2A%20
    title*2="isn't it!"

>   filename="foo bar"

ACK, see above and in another article.  That won't fly with my ad-hoc
idea <key-value-pair> instead of <parameter>.

> We could define a structured field that avoids the issues raised
> by trying to put such things in parameters.

If you have a good idea _without_ 2231 I'm very interested.

> So in this case you think that
>   Injection-Info:
>    (continuation line) foo.example.com
> (i.e. SP on first line followed immediately by line folding) is OK?
> Inconsistency detected.

Rough WG consensus, some proposals to fix [CFWS] were rejected.
It is addressed in prose, for any trailing [CFWS] even in 2822.

> 1. unlike something based strictly on 2045/2231/errata, there are
>    no existing implementations which could be adapted

It's the same as 2045 without 2231 (or that was the design idea,
my bad if I didn't get it right).

> 2. if intended to be human-readable ("to assist in tracing"), it
>    fails to provide for specification of charset and language (BCP
>    18), particularly for logging-data

The logging-data is readable for those who insert it, for everybody
else it's opaque.

>    and display name parts of address-lists

Sub-strings reflecting 2047-words are allowed, and the display-name
is irrelevant at best.

> 3.

ACK, see above, x-filename won't work in all weird cases.

> 4. the optional trailing semicolon is a poor design choice

Yes, screw it, I copied the SPF syntax, or as you said "SPF-cruft".

> See the concise and clear syntax of the Received field (recently
> posted separately) for a parameter-less syntax

Yes, I saw it.  It was the 2822 view, not the 2821 view.  Here we
need both, but spliiting these views is a good idea.  Just propose
something.  Complete ABNF for both views if it avoids 2231.  If it
doesn't we already have Charles' version plus some minor nits.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S7c4YL072795 for <[e-mail]>; Thu, 28 Jul 2005 00:38:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6S7c4rU072794 for ietf-usefor-skb; Thu, 28 Jul 2005 00:38:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S7c2M1072777 for <[e-mail]>; Thu, 28 Jul 2005 00:38:03 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dy2xg-0001Vu-4O for [e-mail]; Thu, 28 Jul 2005 09:37:48 +0200
Received: from 212.82.251.111 ([212.82.251.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 09:37:48 +0200
Received: from nobody by 212.82.251.111 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 09:37:48 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Thu, 28 Jul 2005 09:33:41 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 30
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.111
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> More to the point is whether you agree that my method of
> setting out the structure of Injection-Info achieves its
> object of integrating these <parameter>s within the overall
> structure of MIME parameters as set out in 2045/2231.

Let's finish that business, state of the art from my POV:

- <inj-key-value-list> was rejected => 2231-parameters

- replace <mailbox> by <addr-spec> for the sender
- maybe replace <address-list> by a new <addr-spec-list>
  (we need no <display-name> or <group>, we have CFWS)

- maybe replace <dot-atom> by <dot-atom-text> for the host
- use 2234 grouping for "host colon IP" (already agreed)
- do we want the IP in square brackets ?  Copy whatever a
  2821 Received header field does in a "from"-value.

- remove nonsense remarks about "unlikely" and "gibbous"
- remove useless remarks about I18N and non-ASCII, those
  who want it will find it in 2231 and 3066bis
- update the example to show both " => \" and \ => \\,
  add another example showing @ => must be quoted string

- declare #1080 state "text proposed" and let's move on

                            Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S6pOAF053816 for <[e-mail]>; Wed, 27 Jul 2005 23:51:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6S6pO11053815 for ietf-usefor-skb; Wed, 27 Jul 2005 23:51:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S6pM3o053794 for <[e-mail]>; Wed, 27 Jul 2005 23:51:22 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dy2EV-0005vs-59 for [e-mail]; Thu, 28 Jul 2005 08:51:07 +0200
Received: from 212.82.251.111 ([212.82.251.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 08:51:07 +0200
Received: from nobody by 212.82.251.111 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 08:51:07 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1003 Message-ID issues - status
Date:  Thu, 28 Jul 2005 08:47:34 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 49
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.111
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

>> s/"ab\cd"/"ab.\cd"/
>> so as to illustrate the <dot-atom-text> bug found by Frank
[...]
> local-part (and its non-folded equivalent id-left) does not
> require a dot.  I don't know what "bug" is being referenced,
> could you please provide a URI or message identifier.

This example is unrelated to the "dot-bug" in older versions
of <msg-id-core>.  The "dot-bug" was about a local-part in the
forms 1: "." dot-atom-text OR 2: dot-atom-text "." OR 3:
dot-atom-text ".." dot-atom-text (e.g. <".ab..cd."@example>).

If the example wants to cover it it needs a leading, trailing,
or two adjacent dots (requiring a <quoted-string> local part).

> The fundamental problem is the incompatible redefinition;
> the name is irrelevant.

I believe in _small_ interfaces of independent modules (read
"objects" if you prefer that), because that simplifies later
replacements.  Here the minimal interface is the <msg-id>.

Anything else like <id-left> etc. are "implementation details",
they _should_ be invisible to users of the <msg-id> "module".

Unfortunately they are visible, and we modify them (back to
what they really are in all other standards, especially news).

Therefore our "implementation details" should use different
names, because they really are different from 2822 details.

Our semantics of the RHS is "domain", not "domain or whatever".

We have no "semantically invisible backslash" like RfC 2822.

For some horror scenarios what that could do to news-URIs visit
the uri@w3 list (the thread about tag: URIs and local parts of
addresses).

Therefore we need new names for our different <msg-id> details:

"<" <id-local> "@" <id-domain> ">" with <id-quote> instead of
RfC 2822 <no-fold-quote> etc.  "Minimize the interface" is no
new concept, it's at least 25 years old.

                           Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S5nsCE029965 for <[e-mail]>; Wed, 27 Jul 2005 22:49:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6S5nsIH029964 for ietf-usefor-skb; Wed, 27 Jul 2005 22:49:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S5nqPL029945 for <[e-mail]>; Wed, 27 Jul 2005 22:49:52 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dy1Gk-00019S-IJ for [e-mail]; Thu, 28 Jul 2005 07:49:22 +0200
Received: from 212.82.251.111 ([212.82.251.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 07:49:22 +0200
Received: from nobody by 212.82.251.111 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 28 Jul 2005 07:49:22 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Thu, 28 Jul 2005 07:48:22 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.111
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

>>              Fred\ [e-mail]
[...]
> See the errata page,
> http://www.rfc-editor.org/cgi-bin/errata.pl

Oh, John fixed it less than three weeks ago, good.  Apparently
it still works if the author submits errata.  Makes sense, bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S2oirm079045 for <[e-mail]>; Wed, 27 Jul 2005 19:50:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6S2oiaS079043 for ietf-usefor-skb; Wed, 27 Jul 2005 19:50:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6S2ogrR079034 for <[e-mail]>; Wed, 27 Jul 2005 19:50:42 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org (a.shell.peak.org [69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6S2oL0p016622 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 27 Jul 2005 19:50:21 -0700 (PDT)
Date: Wed, 27 Jul 2005 19:50:32 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>My proposed requirements for "news" and "usenet" are less onerous than for
>2142. Do you have a problem with that?

My fault. I added a parenthetical comment in my description of a problem 
which allowed you to latch on to something that isn't an issue and pretend 
that you're discussing the real problem. Knock it off, Charles.

>My proposal regarding "abuse" is less onerous than for 2142

That is a patently false, and you know better, because it has been
explained to you multiple times now.

Mandating an "abuse@" address for an FQDN is EXPLICITELY NOT required by 
RFC2142. RFC2142 says EXPLICITELY that an "abuse@" address is required 
ONLY for the top level domain.

You are requiring an "abuse@" address for the FQDN of an injecting agent.
That is NOT less onerous than RFC2142, it is a direct contradiction of 
RFC2142 and is MUCH STRONGER than the language in RFC2142. 

> ... insofar as it is not required for relaying agents 

RFC2142 does not require it for relaying agents, so you are not less 
onerous w.r.t. relaying agents, at best you are the same. 

> ... and it is not required if there is a suitable parameter in 
> Injection-Info,

Again, RFC2142 says nothing about "injection info", so your text is not 
"less onerous" since it changes NOTHING if the agent inserts a top level 
domain. If the injecting agent inserts a top level domain name as its 
path-identity, it is still required to have a valid abuse@ address for 
that path-identity. Your text is irrelevant, and thus is nether less nor 
more onerous.

> Do you have a problem with that?

With the patent falsehood that your mandate is less onerous than the
explicit statement that the address is optional for anything but a top
level domain? Yes, I have a serious problem with that. Please stop doing 
it.

>My use of RFC 2119 language is consistent with its use to describe the
>"postmaster" address in RFC 2821 ...

No, it is not. "Abuse@" is not a news-specific management or configuration 
address like "postmaster@" is for email. The same kind of mandate that 
says "you must have an address at which management and configuration 
issues for your protocol can be addressed" does NOT apply to "abuse@" a 
news site. It DOES apply to "usenet" and "news", which is why I've already 
told you that those addresses are not the issue and that mandates for 
those are consistent with other standards.

>Do you have a problem with RFC 2821?

Knock it off, Charles. We are not discussing RFC2821 here, this is USEFOR 
and we are discussing USEPRO and USEFOR and USAGE and whatever other NEWS 
standards are being written. 

>My proposal regarding "abuse" is more onerous that for 2142 insofar as it
>requires you either to provide an MX record for the <path-identity> used
>for injection or else to choose a <path-identity> which is already your
>"top level domain". 

That is incomplete and thus deliberately misleading.  The issue has
nothing to do with "provid[ing] an MX record", and your proposal says more
than that. It says that the address "abuse@" the FQDN MUST be mailable.  
The latter is not synonymous with the former. Please read your own text
and come back here when you've figured out what you actually wrote.

>And it does so with "MUST" wording. Evidently you do
>have a problem with that.

Gosh, do you think he finally understands what the problem is, after being 
told a dozen times or more?

>The reason it is so proposed is that it provides a clear and unambiguous
>route to find a working "abuse" address starting from information
>contained in the article's header fields.

A. That is not an interoperability issue supporting the use of RFC2119 
mandate language. I've already told you this, so please stop pretending it 
is.

B. There is no guarantee that the address is "working", only that it be 
"available". It may be routed to /dev/null on the recipient's end, for all 
we know, or for all the sender knows. 

C. It isn't that hard to determine a valid abuse address from the 
information in the headers of a news message, despite your trouble 
identifying what a "top level domain" is. It just doesn't merit any 
additional burden. 

D. We ALREADY mandate "usenet" AND "news", and email regarding abuse can
easily be sent to those addresses. It would be a rare site indeed where
the "usenet" mailbox owner doesn't know (or isn't himself) the person who
deals with abuse issues. If the "usenet@" address goes to someone who 
is abusing the system, the "abuse@" address probably does, too. 

We've been here before, Charles, and covered all of these "reasons". They 
do not read RFC2119 level, nor do they merit any mandate for any 
additional addresses. This is especially true in light of the language of 
RFC2142 which EXPLICITELY says that it is NOT a requirement for anything 
but the top level domain.

You have not even begun to present a sufficient justification for RFC2119 
language or for contradicting an existing standard that is intended to 
deal with address requirements for internet sites. 

The comments of every person I've seen comment on this (other than you) is
that the requirement is not needed and should be removed. That's a 
consensus in my book. If I have to live with results of "consensus" I do 
not like, then YOU ought to live with them too, and not abuse your 
position as editor to keep text in a draft that consensus says remove.

>RFC 2142 fails to provide such a route,

That is patently and deliberately false. "abuse@" the top level domain is
a REQUIREMENT.  That is "providing such a route". We've gone through this 
before, please stop tossing up this old chestnut.

>as evidenced by the fact that when I gave a concrete example that could be
>derived from the article's header fields, different members of this WG
>arrived at different conclusions as to what the correct "abuse" address
>should be.

Poppycock. Three people played your game, as I recall, and all three came 
up with working abuse reporting addresses. That's not proof that such an 
address cannot be found, it is proof that there are often several such 
addresses available, even without your specious mandate for more.

Here we are again: either justify the mandate (in any version or flavor)  
or remove it. You have not done so yet, and I get no impression that you
are capable of doing so. All you do is repeat the same old non-starters.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RJcJYF041624 for <[e-mail]>; Wed, 27 Jul 2005 12:38:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RJcJCH041623 for ietf-usefor-skb; Wed, 27 Jul 2005 12:38:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RJcJTl041616 for <[e-mail]>; Wed, 27 Jul 2005 12:38:19 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id 7417229A01; Wed, 27 Jul 2005 15:38:18 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RJcHVo013465(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 15:38:17 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RJcGo0013464(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 15:38:17 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Date: Wed, 27 Jul 2005 15:38:14 -0400
User-Agent: KMail/1.8.1
Cc: Richard Clayton <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 27 2005 14:00, Richard Clayton wrote:
> 
> In message <[e-mail]>, Bruce Lilly
> <[e-mail]> writes

> >It is desirable to be able to communicate.  Whether the form of communication
> >"needs to be" via email is debatable.
> 
> today, it is -- complaining in the newsgroup is generally frowned on,
> and IRC doesn't generally cut it :(

Those aren't the only alternatives; there's ftp, HTTP, the telephone,...
 
> this is the Real World (TM)  everyone but everyone has email

Not all email systems are reachable via an Internet-style address with
a local-part consisting solely of "abuse".  There's e.g. UUCP, X.400, ...

> don't forget that the abuse@ team also deal with complaints about UDP
> packets

UDP packets are unlikely to emanate from a UUCP site with no Internet
connectivity.

> >I'd go further and permit mechanisms in addition to/alternate to email.
> 
> the main effect of this would be to encourage reporting via web forms

And you have determined that from? Gazing into a crystal ball?
Looking at tea leaves?  Rummaging through entrails?
 
> I can live with that, but I don't think it would be widely seen as being
> realistic in today's climate

In some cases HTTP or other mechanisms are more reliable than email for
reporting abuse.  A common case is reporting a message containing a "virus";
that might not pass through some mail filters, whereas it can be copied
and pasted into a web form or sent via ftp, etc.  Likewise for some
malformed messages.
 
> >> d) pin down whether Injection-Info is or is not mandatory and fix the
> >> text accordingly
> >
> >There doesn't seem to be anything there that warrants making it mandatory.
> >Much is redundant with what is in Path and/or other fields (and easier to
> >extract from Path and/or other fields).
> 
> it's hard to extract from the path if we continue to permit
> 
>         !demon!highwayman.com!richard
> 
> because the correct place to complain is [e-mail], and that's not
> especially easy to write rules as to how to do the extraction :)

That's not relevant to most of what's in Injection-Info; the posting
host can be obtained from Path, sender can be obtained from originator
header fields or placed in the "tail-entry".  Likewise posting account
information could be encoded into the tail-entry.

For complaint information,
  Complaints-To: <mailto:abuse%40beeb.net>
would work fine.  Easy to parse, almost trivial to automate/assist
complaint submission.  Uses mailto URIs which are widely supported.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RJST1J040573 for <[e-mail]>; Wed, 27 Jul 2005 12:28:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RJSTwf040572 for ietf-usefor-skb; Wed, 27 Jul 2005 12:28:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RJSSuD040555 for <[e-mail]>; Wed, 27 Jul 2005 12:28:28 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (internal) with ESMTPA; Wed, 27 Jul 2005 20:28:25 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 Jul 2005 20:28:23 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
CC: [e-mail]
Subject: Re: #1082 USEFOR 3.2.9 Need more text about Approved header field seman
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>#1082 is a ticket created by Alexey, but not formally introduced to this
>list. Its full text is:
>
>Charles wrote:
>
>The 1st paragraph could usefully mention moderation and control
>messages as the two most important applications of this header.
>  
>
This seems reasonable to me.

>There should also be a sentence (maybe in a NOTE) such as the
>following
>
>The presence of a this header implies a claim to have authority
>to post the article, thus assisting other sites to determine
>whether to accept or act upon it.
>
>in order to explain the semantics of this header.
>
>
>The first addition is simply a matter of being helpful to the reader (the
>present text is a bit bare), and should not be controversial.
>
>
>The second addition is less important, but should be considered. There was
>a comparable text in the old draft-13.
>
>Essentially, it is generally considered a serious and LARTable offence to
>forge-approved a moderated article without the permission of the
>moderator. The proposed text respresents, I believe, the original intent
>of the Approved header (now much watered down by years of misuse). But at
>least it would provide some ammunition to use against less clueful ISPs to
>demonstrate that the perpetrator was indeed trying to pass himself off as
>something that he was not.
>
>Alternatively, you might want this to be dealt with in USEAGE.
>  
>
Yes, the note belongs to USEAGE.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RJA9mg038417 for <[e-mail]>; Wed, 27 Jul 2005 12:10:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RJA9BD038416 for ietf-usefor-skb; Wed, 27 Jul 2005 12:10:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RJA7MK038410 for <[e-mail]>; Wed, 27 Jul 2005 12:10:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.145] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 27 Jul 2005 20:10:04 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 Jul 2005 20:10:02 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charles Lindsey <[e-mail]>
CC: [e-mail]
Subject: Re: NEW: USEFOR -05 3.1 Injection-Date was mandatory
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>Ticket please.
>  
>
I've created a ticked # 1088 for this.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RI2TBj031738 for <[e-mail]>; Wed, 27 Jul 2005 11:02:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RI2TxT031737 for ietf-usefor-skb; Wed, 27 Jul 2005 11:02:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RI2QxJ031730 for <[e-mail]>; Wed, 27 Jul 2005 11:02:28 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-30.mail.demon.net with esmtp (Exim 4.42) id 1DxqEY-000PAE-37 for [e-mail]; Wed, 27 Jul 2005 18:02:23 +0000
Message-ID: <[e-mail]>
Date: Wed, 27 Jul 2005 19:00:52 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <7Iw$+3DT77vsrNKLvib+d+vRDe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Bruce Lilly
<[e-mail]> writes

>On Wed July 27 2005 12:04, Richard Clayton wrote:
>
>> The basic idea is that someone stands up and takes responsibility for
>> articles that are injected into the system. In principle, they can stop
>> further articles by cancelling an account, barring a user, manually
>> checking future posts or whatever.
>> 
>> The rest of the planet needs to know who that person is and needs to be
>> able to send email to them.
>
>It is desirable to be able to communicate.  Whether the form of communication
>"needs to be" via email is debatable. 

today, it is -- complaining in the newsgroup is generally frowned on,
and IRC doesn't generally cut it :(

> For "postmaster" and a mail server,
>that is reasonable because after all it *is* a mail server which is obviously
>capable of handling mail.  For Usenet, that does not necessarily apply.

this is the Real World (TM)  everyone but everyone has email

don't forget that the abuse@ team also deal with complaints about UDP
packets and no-one seems to have any real long-term difficulty working
out where to complain about those ! 

>We can try to mandate or recommend that each news server associated with
>responsibility for injection also accept mail and could further mandate or
>recommend specific mail protocols, addressing formats, and/or mailboxes.
>That may adversely affect sites handling news via UUCP, Fidonet, etc.

frankly, I doubt it.  If you could name such a site (which has a Fidonet
feed say, but no globally accessible email address), then your assertion
might carry more weight :(

>IIRC one person objected that some sites which have no
>email capability but which do have HTTP service might actually supply an
>HTTP URI for complainants to use.  Quelle horreur!  

I've got no problem with complaints via HTTP, but the community
currently objects if you cannot complain by email as well (or instead)

>> Anyway, we need to have a set of rules for what it says in this header
>> field
>
>Meaning Path?  Or Injection-Info?  Or something else?

whatever the complaints directing header field is (I was still being
addressing the general principle of what we actually need to do at that
point), I'll live with Injection-Info for the purpose.

>> and quite clearly (from above) it needs to be an identity from 
>> which one can trivially obtain a domain, prepend abuse@, news@ or
>> usenet@

>> So I come back to the point made above -- viz: that what's needed is the
>> rules for the complainer to follow, then a statement that says that this
>> MUST yield a valid email address.  Then drop all the rest of the guff.
>
>I'd go further and permit mechanisms in addition to/alternate to email.

the main effect of this would be to encourage reporting via web forms

I can live with that, but I don't think it would be widely seen as being
realistic in today's climate

>> d) pin down whether Injection-Info is or is not mandatory and fix the
>> text accordingly
>
>There doesn't seem to be anything there that warrants making it mandatory.
>Much is redundant with what is in Path and/or other fields (and easier to
>extract from Path and/or other fields).

it's hard to extract from the path if we continue to permit

        !demon!highwayman.com!richard

because the correct place to complain is [e-mail], and that's not
especially easy to write rules as to how to do the extraction :)

Hence there is significant value in a new field (and making it
mandatory) and it sweeps away the rather-hard-to-machine-parse existing
set of oddments used for the purpose

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQufL1JoAxkTY1oPiEQJ3MACfeQRZjiXLZoMvVq0sH5yhjZY7lOwAn1dE
EoZxyEHssnnUSe7NHzR3tfyo
=CFOX
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RHh8Vb028912 for <[e-mail]>; Wed, 27 Jul 2005 10:43:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RHh80L028911 for ietf-usefor-skb; Wed, 27 Jul 2005 10:43:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RHh7AK028905 for <[e-mail]>; Wed, 27 Jul 2005 10:43:08 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 4B3E2299A8; Wed, 27 Jul 2005 13:43:07 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RHh5ev012820(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 13:43:05 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RHh5pe012819(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 13:43:05 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Date: Wed, 27 Jul 2005 13:43:02 -0400
User-Agent: KMail/1.8.1
Cc: Richard Clayton <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 27 2005 12:04, Richard Clayton wrote:

> The basic idea is that someone stands up and takes responsibility for
> articles that are injected into the system. In principle, they can stop
> further articles by cancelling an account, barring a user, manually
> checking future posts or whatever.
> 
> The rest of the planet needs to know who that person is and needs to be
> able to send email to them.

It is desirable to be able to communicate.  Whether the form of communication
"needs to be" via email is debatable.  For "postmaster" and a mail server,
that is reasonable because after all it *is* a mail server which is obviously
capable of handling mail.  For Usenet, that does not necessarily apply.
We can try to mandate or recommend that each news server associated with
responsibility for injection also accept mail and could further mandate or
recommend specific mail protocols, addressing formats, and/or mailboxes.
That may adversely affect sites handling news via UUCP, Fidonet, etc.

> There's also a need to stop people moaning, and so we let them specify
> exciting alternatives   stopnow@ or whatever, not that anyone is likely
> to notice and to use them -- but it stops people moaning that they just
> cannot cope with everything coming to abuse@
> 
> For this purpose we have the Injection-Info: header field.  This field
> is a MUST requirement according to 2.3 (though mysteriously in 3.1 it is
> described as optional and in USEFOR it is said to be optional).

There was also a Complaints-To proposal, which was never as mired in problems
as Injection-Info.  IIRC one person objected that some sites which have no
email capability but which do have HTTP service might actually supply an
HTTP URI for complainants to use.  Quelle horreur!  Another case of a
personal fetish overriding calm consideration of technical issues, resulting
in a huge waste of time and effort.

> Anyway, we need to have a set of rules for what it says in this header
> field

Meaning Path?  Or Injection-Info?  Or something else?

> and quite clearly (from above) it needs to be an identity from 
> which one can trivially obtain a domain, prepend abuse@, news@ or
> usenet@

Injection info provides for an address-list (which is email- and Internet-
specific), though that has severe syntax problems with the proposed use
of MIME-like parameters.  Complaints-To could have an address-list w/o
syntax problems, or could have a bracketed URI list (permitting an
ordered hierarchy of contact mechanisms), the latter fully encompassing
the capabilities of a mere address-list and providing alternate mechanisms.

> and have email delivered to the correct place.

That presumes that email is available to the complainer and the responsible
party.

> I don't see that we have to have a whole pile of things about FQDNs,
> domains the concept of "mailable" (which only involves two of the three
> destination addresses anyway) or any mixing up of the notion of UUCP
> identities with this part of the format.
> 
> We just need to set out the rules for the complainer and then say that
> the Injecting agent must generate header fields to ensure that these
> rules will work.

Somewhere the concept of voluntary standards passed over somebody's head,
and was replaced by a bizarre ESP-like guess-the-mechanism-and-mailbox
concept, replete with "here's an example; guess the mailbox" games.
There's no guarantee -- even if we write "POSITIVELY, ABSOLUTELY, UNDER
PAIN OF CHASTISEMENT FROM CHARLES, MUST" w.r.t. email support for complaints
that a site will conform.  Far simpler and more sensible to provide a
standardized mechanism which can be used by those who wish to take
responsibility for injection (those who do not will not regardless of what
is written) to do so in accordance with some set of mechanisms that provide
for negotiation of mutually usable communications media between complainer
and responsible party.  Complaints-To with a bracketed URI list would do
just that. Those who wish can still engage in guess-the-mechanism games
(and we can still write SHOULD or even MUST).

[...]
> So I come back to the point made above -- viz: that what's needed is the
> rules for the complainer to follow, then a statement that says that this
> MUST yield a valid email address.  Then drop all the rest of the guff.

I'd go further and permit mechanisms in addition to/alternate to email.
 
> To reiterate, since I fear people skip-read these long messages.
> 
> a) Turn the whole thing around and provide a clear set of rules of how
> to construct an email address to which to send a complaint

Or alternate mechanisms.
 
> b) say that the Injection-Info header field must be built in such a way
> as to have these rules work

Or whatever field is designed to provide the functionality.  Best to
keep separate functionality in separate fields so that e.g. a complainer
doesn't have to wade through difficult syntax for unrelated cruft in
order to file a complaint.
  
> c) say nothing more that that!

Except for necessary registrations and corresponding IANA considerations,
any security issues (obviously, publishing contact information gives
potential attackers a target for DoS or other attacks), etc.
 
> d) pin down whether Injection-Info is or is not mandatory and fix the
> text accordingly

There doesn't seem to be anything there that warrants making it mandatory.
Much is redundant with what is in Path and/or other fields (and easier to
extract from Path and/or other fields).
 
> e) break the unnecessary connection between the data in the Injection-
> Info header field AND that in the Path header field _AND_ (since it is a
> completely different thing) the Xref header field.  Once you do that all
> sorts of SHOULDs disappear, which is a Good Thing :)  Then we can look
> at whether all these complex rules about MX records are needed for the
> Xref and Path header field info (hint: "no")

Sounds good to me.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RGV01v022451 for <[e-mail]>; Wed, 27 Jul 2005 09:31:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RGV0mF022450 for ietf-usefor-skb; Wed, 27 Jul 2005 09:31:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RGV0xi022444 for <[e-mail]>; Wed, 27 Jul 2005 09:31:00 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id D7ECF299AC for <[e-mail]>; Wed, 27 Jul 2005 12:30:59 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RGUxsR012425(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 12:30:59 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RGUwQt012424(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 12:30:58 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Wed, 27 Jul 2005 12:30:55 -0400
User-Agent: KMail/1.8.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 21 2005 10:21, Charles Lindsey wrote:

> The instructions given in USEPRO come in 2 steps:
> 
> 9. If there is no Path already present, then you create one with a
> <tail-entry> (typically "not-for-mail").
> 
> 10. You then *prepend* the <path-identity> of the injecting agent,
> together with a "POSTED", to the Path (which is now guaranteed to be
> there by the previous step).

Charles, you have previously claimed that the text is not prescriptive --
that processing need not occur in discrete step in a specific order so
long as the end result is consistent; make up your mind.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RGNIYJ021814 for <[e-mail]>; Wed, 27 Jul 2005 09:23:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RGNIXC021813 for ietf-usefor-skb; Wed, 27 Jul 2005 09:23:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns2.townisp.com (ns2a.townisp.com [216.195.0.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RGNHec021806 for <[e-mail]>; Wed, 27 Jul 2005 09:23:18 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns2.townisp.com (Postfix) with ESMTP id A370B29951 for <[e-mail]>; Wed, 27 Jul 2005 12:23:17 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RGNGbL012375(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 12:23:17 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RGNGZu012374(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 12:23:16 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1032 USEFOR changes from 1036
Date: Wed, 27 Jul 2005 12:23:13 -0400
User-Agent: KMail/1.8.1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 21 2005 10:11, Harald Tveit Alvestrand wrote:
> 
> I've gotten some off-list comments on the text I cribbed from USEPRO.
> Currently, we may suggest this text:
> 
> o The [RFC 2822] conventions for parenthesis-enclosed <comment>s
> in headers are supported.

s/headers/structured header fields/

>  o Whitespace is permitted in Newsgroups headers

s/headers/header fields/

>  o The syntax of the Path header has been reworked to add multiple
> forms of information

s/header/header field/

>  o MIME is recognized as an integral part of Netnews.

Probably warrants some mention of I18N w.r.t. MIME RFC 2047 as
amended by 2231 and errata as I18N provisions mandated by BCP 18.

>  o There is a new Injection-Date header to facilitate
> the rejection of stale articles.

s/header/header field/

>  o There are several new optional headers defined, notably
>  Archive, Injection-Info, and User-Agent, leading to increased
>  functionality.

s/headers/header fields/
On a related note, it's not clear that we should be worrying about
new functionality in this document at this point (well past multiply-
extended deadline for producing a draft for publication); e.g. there
is still apparently no consensus on Injection-Info.

>  o There are numerous other small changes, clarifications and
>  enhancements

These should probably be documented.  Simply saying "there are numerous
other [...] changes" is little better than saying "figure it out for
yourself".
 
> Is this an acceptable text for "changes from 1036"?

There are additional substantive changes not mentioned.  E.g. lack of
rationale for using the IMF (RFCs 850, 1036 section 2)[1], separation
into format and protocol documents, change of (intended) status from
Informational to Standards Track, necessary IPR and content changes
brought about by process and format revisions.  Probably many others,
some of which we need to implement but have not yet implemented (e.g.
registration templates and IANA considerations for header field
registrations).

The document as currently written moves further from compatibility
with the Internet Message Format than 1036; ideally that should be
changed, but failing that the decreased compatibility should be
noted in detail.

------------
1. While the primary consideration mentioned in 850/1036 remains
   important, developments since the mid-1980s affirm the wisdom
   of the choice and argue for improved compatibility:
   a. there now exist combined-use UAs (Netscape Navigator, Mozilla
      Suite, Mozilla Thunderbird, Microsoft Outlook Express, Pine,
      etc.); these have been enabled by the choice of the IMF and
      have benefitted Usenet enormously (the mentioned UAs are responsible
      for a substantial proportion of postings) 
   b. there now exist protocols for conveying messages which include
      all messaging applications (e.g. IMAP), said protocols being used
      by and with the combined-use UAs mentioned above
   c. much of the rational for differences was based on the limitations
      of 1970s-80s vintage hardware -- processor speed is several orders
      of magnitude greater now, as are system main (random-access) memory
      and storage media capacities, removing the justification for some of
      the differences.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RG5kxJ020183 for <[e-mail]>; Wed, 27 Jul 2005 09:05:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RG5kuq020182 for ietf-usefor-skb; Wed, 27 Jul 2005 09:05:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RG5jdB020174 for <[e-mail]>; Wed, 27 Jul 2005 09:05:45 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1DxoPf-000ISg-Ez for [e-mail]; Wed, 27 Jul 2005 16:05:43 +0000
Message-ID: <[e-mail]>
Date: Wed, 27 Jul 2005 17:04:20 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <396$+jg$77vatOKLkuc+dO76Zc>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes

>The co-existence of "news" and "usenet" is a historical accident, which it
>is too late to fix.
>
>My proposed requirements for "news" and "usenet" are less onerous than for
>2142. Do you have a problem with that?

I'm reading usepro-4 here, which is the one on the IETF site, and this
whole area is just getting baroque :(

The basic idea is that someone stands up and takes responsibility for
articles that are injected into the system. In principle, they can stop
further articles by cancelling an account, barring a user, manually
checking future posts or whatever.

The rest of the planet needs to know who that person is and needs to be
able to send email to them.  Traditionally, one used news@ or usenet@
but these days abuse@ will reach a specialist team rather than the
administrators, so that's what most people use.

There's also a need to stop people moaning, and so we let them specify
exciting alternatives   stopnow@ or whatever, not that anyone is likely
to notice and to use them -- but it stops people moaning that they just
cannot cope with everything coming to abuse@

For this purpose we have the Injection-Info: header field.  This field
is a MUST requirement according to 2.3 (though mysteriously in 3.1 it is
described as optional and in USEFOR it is said to be optional).

Anyway, we need to have a set of rules for what it says in this header
field and quite clearly (from above) it needs to be an identity from
which one can trivially obtain a domain, prepend abuse@, news@ or
usenet@ and have email delivered to the correct place.

I don't see that we have to have a whole pile of things about FQDNs,
domains the concept of "mailable" (which only involves two of the three
destination addresses anyway) or any mixing up of the notion of UUCP
identities with this part of the format.

We just need to set out the rules for the complainer and then say that
the Injecting agent must generate header fields to ensure that these
rules will work.

- -=-=-=-=-

At present, #2.3 confuses the notion of where to complain to with where
the article has come from, viz: the Path: header field.

I can see NO LINKAGE between these two concepts (except in so far as in
many cases they may be the same).  Is the idea that you can match the
entries in the Path with the Injection-Info: material ?  What does this
gain you ? 

!Path: demon!highwayman.com!richard
!Injection-Info: demon; mail-complaints-to=[e-mail]; 12345678

What this means is that if you don't like what I wrote then you complain
to [e-mail] (the beeb happen to use Demon's news server).

I don't any huge advantage to (the wrapped)

!Path: demon!highwayman.com!richard
!Injection-Info: news.demon.co.uk;
                 mail-complaints-to=[e-mail]; 12345678

it means that people may write to [e-mail] (which would
be coped with, but is a nuisance)

In fact, what is the point of this first path field when there's a mail-
complaints-to clause ?  I can see it makes sense for

!Injection-Info: news.demon.co.uk; 12345678

where one writes to [e-mail] or whatever...

So I come back to the point made above -- viz: that what's needed is the
rules for the complainer to follow, then a statement that says that this
MUST yield a valid email address.  Then drop all the rest of the guff.

>My proposal regarding "abuse" is less onerous than for 2142 insofar as it
>is not required for relaying agents and it is not required if there is a
>suitable parameter in Injection-Info, and it is not required for private
>servers. Do you have a problem with that?

I have a problem with understanding which part of the Injection-Info
header field is being talked about, and I have a big problem
understanding why if the injection agent doesn't offer a public service
they should be excused offering abuse@ ...  suppose beeb.net was a
private club; why should you not expect [e-mail] to work when
their article emerged onto the public part of Usenet ?

>My use of RFC 2119 language is consistent with its use to describe the
>"postmaster" address in RFC 2821 (and note that what is there defined is
>slightly different from RFC 2142). Do you have a problem with RFC 2821?

the world is full of people who have problems with the postmaster@
requirements of 2821. That's a can of worms that is best left alone here

>My proposal regarding "abuse" is more onerous that for 2142 insofar as it
>requires you either to provide an MX record for the <path-identity> used
>for injection or else to choose a <path-identity> which is already your
>"top level domain". And it does so with "MUST" wording. Evidently you do
>have a problem with that.

yes, and so do I

write the rules for the complainant, leave how that is made to work
alone; it's far too complex to describe the general case :(


>The reason it is so proposed is that it provides a clear and unambiguous
>route to find a working "abuse" address starting from information
>contained in the article's header fields.

but that's exactly what it currently does NOT do -- you're left to
deduce it :(

>RFC 2142 fails to provide such a route, as evidenced by the fact that when
>I gave a concrete example that could be derived from the article's header
>fields,         different members of this WG arrived at different conclusions 
>as to
>what the correct "abuse" address should be.

and it was agreed that in all cases the complaint would reach someone
who knew what to do with it.  This is not an area that needs fixing.

To reiterate, since I fear people skip-read these long messages.

a) Turn the whole thing around and provide a clear set of rules of how
to construct an email address to which to send a complaint

b) say that the Injection-Info header field must be built in such a way
as to have these rules work

c) say nothing more that that!

d) pin down whether Injection-Info is or is not mandatory and fix the
text accordingly

e) break the unnecessary connection between the data in the Injection-
Info header field AND that in the Path header field _AND_ (since it is a
completely different thing) the Xref header field.  Once you do that all
sorts of SHOULDs disappear, which is a Good Thing :)  Then we can look
at whether all these complex rules about MX records are needed for the
Xref and Path header field info (hint: "no")


As ever, I can write text for this if it's essential to make people
understand it -- but it mitigates against consistency of style :(

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQuewhJoAxkTY1oPiEQLNIgCeO5DUz3c1qbcVmWBLJuNIx55n6DAAoMT+
JGz07njrw98cPx/MQLRTdUb1
=5FDD
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFvfDN019545 for <[e-mail]>; Wed, 27 Jul 2005 08:57:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RFvfSG019544 for ietf-usefor-skb; Wed, 27 Jul 2005 08:57:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns2.townisp.com (ns2a.townisp.com [216.195.0.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFveFA019536 for <[e-mail]>; Wed, 27 Jul 2005 08:57:41 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns2.townisp.com (Postfix) with ESMTP id AF9F9299BF; Wed, 27 Jul 2005 11:57:39 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RFvcRe012173(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 11:57:38 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RFvbgc012172(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 11:57:37 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1003 Message-ID issues - status
Date: Wed, 27 Jul 2005 11:57:34 -0400
User-Agent: KMail/1.8.1
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 21 2005 09:59, Harald Tveit Alvestrand wrote:

> - Charles suggested adding a dot to the examples:
> 
> 3.1.3  Message-ID
> 
>    <[e-mail]>
>    <"abcd"@example.com>
>    <"ab\cd"@example.com>
> s/abcd/ab.cd/
> s/"abcd"/"ab.cd"/
> s/"ab\cd"/"ab.\cd"/
> 
> so as to illustrate the <dot-atom-text> bug found by Frank, and to agree
> with the NNTP draft.
> 
> I think that's uncontroversial.

local-part (and its non-folded equivalent id-left) does not require a dot.
I don't know what "bug" is being referenced, could you please provide a
URI or message identifier.  While adding a dot doesn't hurt, I fail to see
any need to do so.  If the issue of the examples remains to illustrate
quoting, the presence or absence of a dot which is unaffected by the
quoting mechanisms seems irrelevant.

> - Frank still wants to change the RHS name from "id-right" to "id-domain". 
> I have not seen anyone else support this change; I am going to declare 
> consensus on not changing it unless I hear other voices.
> 
> I'm leaving this ticket open until these are settled.
> Comments?

In case it's unclear, I'm in favor of sticking with our professed "cite by
reference methodology" rather than these ABNF games which "result in subtle
differences and interoperability challenges".  The fundamental problem is
the incompatible redefinition; the name is irrelevant.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFiv1M018290 for <[e-mail]>; Wed, 27 Jul 2005 08:44:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RFivHh018289 for ietf-usefor-skb; Wed, 27 Jul 2005 08:44:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFivxo018283 for <[e-mail]>; Wed, 27 Jul 2005 08:44:57 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id D88D529954 for <[e-mail]>; Wed, 27 Jul 2005 11:44:56 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RFiukE012062(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 11:44:56 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RFitqB012061(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 11:44:55 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Date: Wed, 27 Jul 2005 11:44:53 -0400
User-Agent: KMail/1.8.1
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 21 2005 07:36, Charles Lindsey wrote:
> 
> In <[e-mail]> Bruce Lilly <[e-mail]> writes:

> >As the issue does not warrant BCP 14 imperatives (MUST/MUST NOT), I have
> >suggested keywords appropriate to the (lack of) gravity of the situation.
> 
> The issue most certainly _does_ warrant such imperatives. There are severe
> interoperability problems (and not just in "legacy injection agents").

An unsupported assertion.  Specific documentation, please.

> Moreover, that SP is a REQUIRED feature of the new NNTP standard-to-be,
> and there is no way that this WG can produce a standard that will not
> interoperate with the NNTP standard.

Specifics please, including rationale.  If NNTP is supposed to be 8-bit
clean, it's rather silly to require an SP in a particular place in a
header field of a message which is merely transferred -- it would be as
silly as a corresponding requirement in SMTP (and there is not and never
has been one).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFbKVi016931 for <[e-mail]>; Wed, 27 Jul 2005 08:37:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RFbKBa016930 for ietf-usefor-skb; Wed, 27 Jul 2005 08:37:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFbJDK016923 for <[e-mail]>; Wed, 27 Jul 2005 08:37:19 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id 9C27E29953; Wed, 27 Jul 2005 11:37:18 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RFbHhq012033(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 11:37:17 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RFbH6L012032(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 11:37:17 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: FWS-bugs in 2.2, 3.1.3, 3.1.5, 3.1.6, 3.2.3, 3.2.5, 3.2.6, 3.2.7, 3.2.11, 3.3.1
Date: Wed, 27 Jul 2005 11:37:14 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 26 2005 11:59, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > You are in effect proposing writing a complete message syntax
> 
> No, I propose to replace all explicitly forbidden (in prose)
> [FWS] in the explicitly given syntax by a correct *WSP.  The
> syntax is already there, it's only wrong.
> 
> > down to low-level detail
> 
> That's no low-level detail.

FWS/WSP are low-level field components; a detail.  Changing things
at that level also affects higher-level use and amounts to writing
a different message syntax.

> If some servers accept an obs-FWS and others
> ignore any folded info for the [FWS] after the magic SP, then
> it could result in chaos.
[...] 
> Maybe we should limit this "MAY accept obs" in 2.1 somehow.
> 
> First idea "...where it doesn't violate an explicitly stated
> MUST or MUST NOT in this memo".

The goal should be convergence, not divergence.  See separate message
on how to move towards that goal rather than away from it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFVm6C016484 for <[e-mail]>; Wed, 27 Jul 2005 08:31:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RFVmfw016483 for ietf-usefor-skb; Wed, 27 Jul 2005 08:31:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RFVm7N016477 for <[e-mail]>; Wed, 27 Jul 2005 08:31:48 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id A7266299FA for <[e-mail]>; Wed, 27 Jul 2005 11:31:47 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RFVkep011989(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 11:31:47 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RFVkFv011988(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 11:31:46 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: USEPRO 7.9 gateway (was: ABNF remarks hidden in message "Admin: I'm back.....")
Date: Wed, 27 Jul 2005 11:31:44 -0400
User-Agent: KMail/1.8.1
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 26 2005 12:58, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> >> It was rejected, "missing Message-ID".
> 
> > I don't follow your argument; why would a Date field be
> > rejected ostensibly for "missing Message-ID"?
> 
> Because I tested 'colon SP HT CRLF SP info' in all critical
> header fields simultaneously, the Message-ID was the first.

So in this case you found some software that doesn't accept that
specific instance of a Message-ID field.  Which does not necessarily
say anything about *all* fields (certainly not ones newly defined
in our documents) or about other implementations.  Nor does it imply
anything about best practice, which is what we're supposed to be
working on.
 
> > *if* there is an implementation consideration, I have no
> > objection to a suitable implementation note pointing out
> > the specific issue(s), the workaround(s), and the long-term
> > roadmap to full conformance with the Internet Message Format.
> 
> The long-term roadmap is to fix the <msg-id> in a 2822bis for
> full conformance with what USEFOR will say, because NO-WS-CTL
> was plain wrong.

That's an unsubstantiated assertion.  RFC 822 permitted CTLS in a
domain literal, RFC 733 permitted them via qtext, and RFC 724
permitted them in quoted-string (in word in phrase in mach-host-phrase).
So there is a long-established history.  You are of course free as an
individual to argue for a further restriction in an RFC 2822 successor,
but it is not within this WG's scope to make such a change.  It is within
the scope of this WG's work to make specific recommendations for software
related to this WG's work (viz. Usenet software) to bring it into
conformance with the underlying normative Internet Message Format
specification, as well as to specify workarounds for "baby programmer
errors" in Usenet software in the interim.
  
> > You are simply trying to move the problem to gateways.
> 
> LOL, now that would be the very last I do

Any "restriction" which imposes constraints not in the underlying
normative Internet Message Format specification necessarily creates
problems for gateways (perhaps other software as well).  That is why
we should be working hard to minimize the differences, and where
some difference is necessary to clearly document the reasons and
provide a roadmap for Usenet software to migrate to full conformance.

> Gateway operators are used to all kinds of trouble, mail2news
> is a trivial case,

Not at all trivial, for reasons detailed in an earlier message.

> >> bad enough for mail2news gateways, let's not make it worse.
> > You are making it worse for gateways (see above).
> 
> I'm just stating the obvious, it IS bad for mail2news gateways.

Reducing the magnitude of that problem means removing unnecessary
differences.
 
> Where injection-agents silently "fix" a missing SP - compare
> my test results incl. s/HT/SP/ - it hits also mail (behind a
> news2mail gateway), any signature of header fields created by
> the UA could then arrive as trash depending on the algorithm.
> 
> Therefore the UA has to generate the magic SP.

There are (rough estimate) thousands of gateways, tens of thousands
of newsgroups, tens of thousands of news servers, tens of millions
of UAs, tens of billions of messages (including archives).  "Change every
gateway" is perhaps feasible (but you agree that it's not only a
gateway issue), "Change every newsgroup name" or "change every server"
is bad, but "change every UA" is unthinkable; the scope of the change
is three orders of magnitude larger than that required to change
servers.  "Change every message" (which is implicit in in "fixing"
messages) is simply not an option.  "Change every gateway such that it
changes every message" is the second-worst scenario (after change
every server such that it changes every message).  By comparison,
"change every server to conform to the IMF" is
a) orders of magnitude simpler
b) works well with existing messaging protocols (e.g IMAP)
c) works well with existing and potential security mechanisms for
   the IMF
d) is consistent with migration towards (rather than away from) IMF
   conformance/compatibility
e) can be done gradually

Instead of the currently unjustified "SP (space) is REQUIRED) [...]" and
"MUST contain at least one non-whitespace character", a more productive
approach would be
o To stick with the normative IMF, where SP (via [FWS] or [CFWS}) is
  optional and the only whitespace/field line restriction is against
  generation of whitespace-only continuation lines
o to document any specific interoperability issues with widely-deployed
  Usenet software related to those parts of the IMF specification
o to affirm that message modification other than trace fields is not
  conformant with the specification (IIRC there is already something
  related to that)
o to recommend (at most with BCP 14 keywords appropriate for recommendations)
  steps to promote interoperability with widely-deployed software which
  has interoperability issues and/or fails to conform w.r.t. message
  modification.

At most, that would affect only the non-interoperable software and software
currently making message modifications, and would do so in a manner
compatible with gradual improvement consistent with the goal of minimizing
differences from the IMF and compatible with security mechanisms.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6REPGJt010554 for <[e-mail]>; Wed, 27 Jul 2005 07:25:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6REPG0f010553 for ietf-usefor-skb; Wed, 27 Jul 2005 07:25:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6REPF9W010547 for <[e-mail]>; Wed, 27 Jul 2005 07:25:15 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id E1E0E299A6 for <[e-mail]>; Wed, 27 Jul 2005 10:25:14 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6REPEAf011718(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 10:25:14 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6REPDSZ011717(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 10:25:13 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date: Wed, 27 Jul 2005 10:25:11 -0400
User-Agent: KMail/1.8.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 27 2005 08:45, Frank Ellermann wrote:

> Use a better example, e.g. something from RfC 3696 chapter 3:
> 
>              Fred\ [e-mail]
> 
> That's AFAIK wrong, it should be:  "Fred\ Bloggs"@example.com
> resulting in a: sender = "\"Fred\\ Bloggs\"@example.com"

See the errata page, http://www.rfc-editor.org/cgi-bin/errata.pl

> >> An implementor can't ignore 2231 Section 3 based on
> >> "unlikely" and "gibbous".
> 
> > This header will be generated automatically by injecting
> > agents, who can easily avoid the Section 3 stuff if they put
> > their minds to it.  Hence it is most "unlikely" that they
> > will find a case where they really need it.
> 
> Nevertheless it's not illegal, an implementor trying to extract
> the abuse address has to get it right, funny remarks why 90% of
> the necessary code are "unlikely" or "gibbous" wont't speed up
> the conformance testing by a single man month.

An implementer of a parser necessarily must handle everything that
is legal to generate.  Display names in a parameter has no precedent;
it is uncharted territory and is prone to interoperability problems.
Unlike an earlier proposal for a Complaints-To field with a URI (no
parameters, and mailto URIs are widely implemented).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RDuhe5008505 for <[e-mail]>; Wed, 27 Jul 2005 06:56:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RDuh9A008504 for ietf-usefor-skb; Wed, 27 Jul 2005 06:56:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RDuh7k008494 for <[e-mail]>; Wed, 27 Jul 2005 06:56:43 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id 94046299EF for <[e-mail]>; Wed, 27 Jul 2005 09:56:42 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RDuf6Z011481(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 09:56:42 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RDufRi011480(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 09:56:41 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date: Wed, 27 Jul 2005 09:56:38 -0400
User-Agent: KMail/1.8.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 26 2005 11:14, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> >>> [RFC 822], effectively allows [CFWS] to occur both before
> >>> and after the <parameter>, and also on either side of its
> >>> "="
> 
> > Add reference to the Errata page, s/822/2822/.
> 
> It's about 822, we just discussed these issues on the 822 list,
> 2231 and 2045 were written before 2822.

822 does not define anything called "CFWS", much less "[CFWS]". Those
are defined in 2822.

> >> None of these parameters cries for I18N, therefore I propose
> >> to use the SPF syntax <key-value-list> bypassing <parameter>
> 
> > SPF = not a standard of any kind, certainly not a normative
> > reference
> 
> I'm not talking about references, what a strange idea, neither
> normative nor informative, and also no acknowledgements.  It's
> just a place to grab the <key-value-list> idea, and use it for
> the Injection-Info values.

Since our "document uses a cite by reference methodology, rather than
repeating the contents of other" documents, what precisely are you
suggesting if not a reference?

> > SPF is HARMFUL.
> 
> For spammers, they feel forced to respect it.  Poor bastards.

No, embraced by spammers, as it lends them an air of legitimacy.  Harmful
to legitimate senders and to recipients; i.e. to the mail system.  As
discussed in detail elsewhere, and which need not be repeated here.
Suffice to say that SPF isn't a good model unless one wants a document
that will be relegated to Experimental status.
 
> > RFC 2047/2231/errata isn't solely about i18n, it also
> > addresses long parameters which may need to be split and
> > language-tagging.
> [...]
> > A host name can be up to 255 octets, and there are
> > recommended line length limits << 255.
> 
> FQDNs are used everywhere in header fields, why should that be
> different for the posting-host value ?

Parameter values, unlike domains in other parts of structured fields,
must be quoted if folded.
 
> You only need 2231 folding where embedded WSP can be sigificant
> (file names)

No, quoting works for that.

> or when you hit the 997 limit

That is a hard limit; there is also a 78 octet line length recommended
limit (particularly for something which is intended primarily for human
consumption, which seems to be Charles' assertion).

> (excl. URLs, where  
> you can get away with dummy inserted FWS by just specifying it)

If and only if specified in the (necessarily) structured field syntax.

RFC 2231 fragmentation might not be *necessary* in some circumstances, but
it can still be *used* to split long values.  Without introducing
ambiguity.

> Where does this
> magic 255 come from, AFAIK not 2045 / 2231 / 2822

As we're talking about domain names, see RFC 1034 (sect. 3.1) and RFC 1035
(sect. 2.3.4) as well as RFC 1123 (sect. 2.1).

> Only a display name.  Local part or domain are plain US ASCII.

Domain names are supposed to be LDH, though some IDN advocates claim
that 8-bit stuff (i.e. not encoded) are equally valid [IMO, that's for
display (a la the stuff that results from decoding 2047 encoded-words),
with actual on-the-wire content limited to LDH].  Local-part i18n hasn't
yet been standardized, so one cannot definitively state what constraints
might apply.

> Just take the complete valid <mailbox> and stuff it as is into
> the value of the sender-parameter, ready.  A <mailbox> contains
> at least "@", therefore this value has to be a quoted string.

Or encoded.  Mere quoting can introduce ambiguities, and does not
address the length problem.
 
> It starts with a DQUOTE, and it ends with an unescaped DQUOTE.
> Any DQUOTE within it has to be escaped (\"), therefore also
> all backslashes within it have to be escaped (\\).  Other stuff
> works as is, insert FWS when necessary and where it's allowed.

That relies on particular interpretation by parsers:
  filename="foo bar"
means that the space character is part of the parameter value.  You
seem to want to have spaces (and folding) thrown away in some cases;
how do you propose to distinguish (in a parser) the cases where the
space is an integral part of the value vs. where it should be discarded?
 
> While a formerly encoded word sits within a quoted string it is
> no more encoded word, it's just ASCII with peculiar "?" and "="
> characters.  After you have upacked it (undoing any escapes) it
> is again a valid encoded word.  Assuming you started with a
> valid encoded word, it's a garbage in / garbage out procedure.
> Where's the problem ?

That relies on even more implementation specifics, and is unlikely to
be interoperable; the context in the field is not unstructured, a
comment, or a phrase (it is a parameter value), so 2047 encoding
doesn't apply.
 
> If that's too shaky for your tastes we
> could restrict the sender-value to <addr-spec>, nobody needs
> any <display-name> in the Injection-Info.

That still doesn't address the domain name length issue, or CFWS
permitted in addr-spec vs. interpretation of embedded, quoted spaces.

We could define a structured field that avoids the issues raised by
trying to put such things in parameters.

> > local-parts remain to be specified
> 
> They are already specified, but not in RfC 3696 chapter 3.

That Informational document does not specify i18n for local-parts.
 
> > There was a proposal to use a parameter-less (Received-like)
> > syntax some time ago, but there was no traction.
> 
> Yes, the stuff copied from the weird Received-SPF header field.

No, I was not referring to anything related to SPF cruft.
 
> > Feel free to try that again, Frank, if you think it will fly
> > now.
> 
>  injection-info = "Injection-Info:" SP [CFWS] path-identity
>                   [CFWS inj-value-list] CRLF

So in this case you think that
  Injection-Info: 
   (continuation line) foo.example.com
(i.e. SP on first line followed immediately by line folding) is OK?
Inconsistency detected.
 
>  inj-value-list = inj-value-pair
>                   *( ";" [CFWS] inj-value-pair ) [";"]
> 
>  inj-value-pair = inj-key [CFWS] "=" (dot-atom / quoted-string)
> 
>  inj-key        = "posting-host" / "posting-account" /
>                   "sender" / "logging-data" /
>                   "mail-complaints-to" /
>                   ( "x-" *(ALPHA / DIGIT / "-") ALPHA / DIGIT )
> 
>  inj-posting-host = <etc. as in usefor-05, names starting with
>                     "inj-" followed by the name of the inj-key>

That appears something like a parameter list but suffers from several
deficiencies:
1. unlike something based strictly on 2045/2231/errata, there are no
   existing implementations which could be adapted
2. if intended to be human-readable ("to assist in tracing"), it fails
   to provide for specification of charset and language (BCP 18),
   particularly for logging-data and display name parts of address-lists
3. it doesn't address the length issue and related ambiguity regarding
   quoted FWS
4. the optional trailing semicolon is a poor design choice; it raises
   ambiguity about whether the field was prematurely truncated
5. it is poorly specified; "quoted-string" implies one thing whereas
   the details in the usefor specification referenced state syntax
   which is not specifically a quoted-string (nor dot-atom).  See the
   concise and clear syntax of the Received field (recently posted
   separately) for a parameter-less syntax which specifies the necessary
   alternatives (and also provides for a time-stamp).
 
> > The length issues related to mailbox are even wore germane to
> > address-list, as a single address can be a named group, and
> > an address-list can contain multiple comma-separated
> > addresses, possibly with interspersed CFWS.
> 
> Nothing forces you to put a value in one line, or to fold it
> at places where it can't be folded.  The normal folding works:

See above re. ambiguity of interpretation of quoted SP (and folding)
(also display names which are an integral mandatory part of a named
group).
 
> [...] mail-complaints-to = "
>  insert folded escaped address-list here
>  ";sender = "
>  insert folded escaped mailbox here
>  " ;x-foo = bar

That's begging for interoperability problems.  No existing parameter
in any defined field specifies a value containing an address-list --
for good reasons as noted above.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RDnSxM006130 for <[e-mail]>; Wed, 27 Jul 2005 06:49:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RDnSpC006123 for ietf-usefor-skb; Wed, 27 Jul 2005 06:49:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RDnRiE006104 for <[e-mail]>; Wed, 27 Jul 2005 06:49:27 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-73-211.midband.mdip.bt.net ([81.144.73.211]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e790e5.bf82.100 for [e-mail]; Wed, 27 Jul 2005 14:49:25 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6RDlIm28007 for [e-mail]; Wed, 27 Jul 2005 14:47:18 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22122
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 27 Jul 2005 11:27:36 GMT
Lines: 55
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Tue July 26 2005 03:23, Frank Ellermann wrote:
>> 
>> Charles Lindsey wrote:

>> > NOTE: The syntax of <parameter> ([RFC2045] as amended by
>> > [RFC2231]), taken in conjunction with the folding rules of
>> > [RFC 822], effectively allows [CFWS] to occur both before
>> > and after the <parameter>, and also on either side of its "="

>Add reference to the Errata page, s/822/2822/.

Why? RFC 2045/2231 rely on RFC 822 for their folding rules. That NOTE is
my interpretation of how you would view them in RFC 2822 terms (I also got
Keith Moore to confirm that I had interpreted correctly). The NOTE is not
normative, of course.

>RFC 2047/2231/errata isn't solely about i18n, it also addresses
>long parameters which may need to be split and language-tagging.

>> > host-value = dot-atom / [ dot-atom ":" ]
>> >              ( IPv4address / IPv6address ) ;  see [RFC 3986]

>A host name can be up to 255 octets, and there are recommended line
>length limits << 255.

There are no such limits in our drafts. In the unlikely event that such a
host name arises, it is better to leave the long line than to start using
the RFC 2231 splitting.


>> An implementor can't ignore 2231 Section 3
>> based on "unlikely" and "gibbous".

>True.

False. See my reply to Frank. A generating implementor can easily avoid
Section 3. Accepting implementors don't exist (except for ad hoc scripts).

More to the point is whether you agree that my method of setting out the
structure of Injection-Info achieves its object of integrating these
<parameter>s within the overall structure of MIME parameters as set out in
2045/2231.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RDnSkF006131 for <[e-mail]>; Wed, 27 Jul 2005 06:49:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RDnS7E006129 for ietf-usefor-skb; Wed, 27 Jul 2005 06:49:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RDnR2Z006109 for <[e-mail]>; Wed, 27 Jul 2005 06:49:27 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-73-211.midband.mdip.bt.net ([81.144.73.211]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e790e6.bf82.101 for [e-mail]; Wed, 27 Jul 2005 14:49:26 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6RDlJ028011 for [e-mail]; Wed, 27 Jul 2005 14:47:19 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22123
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 27 Jul 2005 11:56:41 GMT
Lines: 47
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>We already demand that both "news" and "usenet" be mailable addresses,
>even though I still have seen no justification for having two. Either
>justify a mandate (of any kind, much less RFC2119) requiring a THIRD
>mailable address for a news host or remove it.

The co-existence of "news" and "usenet" is a historical accident, which it
is too late to fix.

My proposed requirements for "news" and "usenet" are less onerous than for
2142. Do you have a problem with that?

My proposal regarding "abuse" is less onerous than for 2142 insofar as it
is not required for relaying agents and it is not required if there is a
suitable parameter in Injection-Info, and it is not required for private
servers. Do you have a problem with that?

My use of RFC 2119 language is consistent with its use to describe the
"postmaster" address in RFC 2821 (and note that what is there defined is
slightly different from RFC 2142). Do you have a problem with RFC 2821?

My proposal regarding "abuse" is more onerous that for 2142 insofar as it
requires you either to provide an MX record for the <path-identity> used
for injection or else to choose a <path-identity> which is already your
"top level domain". And it does so with "MUST" wording. Evidently you do
have a problem with that.

The reason it is so proposed is that it provides a clear and unambiguous
route to find a working "abuse" address starting from information
contained in the article's header fields.

RFC 2142 fails to provide such a route, as evidenced by the fact that when
I gave a concrete example that could be derived from the article's header
fields,	 different members of this WG arrived at different conclusions as to
what the correct "abuse" address should be.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RCphm9083920 for <[e-mail]>; Wed, 27 Jul 2005 05:51:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RCphYW083918 for ietf-usefor-skb; Wed, 27 Jul 2005 05:51:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RCpfJr083896 for <[e-mail]>; Wed, 27 Jul 2005 05:51:41 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxlN5-0001kH-AQ for [e-mail]; Wed, 27 Jul 2005 14:50:51 +0200
Received: from c-180-160-96.hh.dial.de.ignite.net ([62.180.160.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 27 Jul 2005 14:50:51 +0200
Received: from nobody by c-180-160-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 27 Jul 2005 14:50:51 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Wed, 27 Jul 2005 14:45:41 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 90
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-160-96.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> the intent of this ticket is to arrive at a way of setting
> out the structure of the Injection-Info header field in
> USEFOR that makes it clear that it follows all the rules
> established by RFC 2045/2231.

> It is NOT intended to challenge what I think is the (possibly
> reluctant) consenus that these things are going to look and
> behave just like MIME <parameter>s. If you want to do that,
> then start another ticket for it;

Two tickets for the same issue make no sense, something with
the Injection-Info is not yet ready.

It can be solved somehow with 2231-parameters.  I doubt that it
will get many "fans" (e.g. scripts trying to extract the abuse
address).  It can be solved somehow with key-value-pairs, but
Bruce doubts that folding values only because they "happen" to
allow the insertion of FWS somewhere is sound engineering.

He has a point there.  Specifying why it works for the special
cases of mailbox and address-list is an odd idea.  Admittedly
a _bad_ idea.  Not worse than 2231, but I'm not sure that it's
really better.  If someboday adds an x-filename parameter just
for the fun of it, it breaks without 2231-parameters... :-(

Or Russ' x-complaintsurl, works with 2231, could work without,
but not without an explicit rule to add / remove FWS if needed.

> we have already been around that route.

Yes, the same Russ said that he hates CFWS and 2231 (or that's
how I remember it).

> Better to s/mailbox/addr-spec/, though even that still
> leaves the problem.

At least it eliminates the unnecessary <display-name>, that's
the job of From: or Sender:, not an Injection-Info: parameter.

>> stuff like sender = "<\"\\\\\"@example.com>".
> Yes, I put the example there to warn people.

Your example doesn't include \, and for readers without some
background knowledge with *NIX shells or similar tools it's
not necessarily obvious that they've to escape both " and \.

Use a better example, e.g. something from RfC 3696 chapter 3:

             Fred\ [e-mail]

That's AFAIK wrong, it should be:  "Fred\ Bloggs"@example.com
resulting in a: sender = "\"Fred\\ Bloggs\"@example.com"
Add both forms, original address and correponding sender value.

> USEFOR is written on the (unlikely) assumption that all
> readers have a perfect understanding of RFC 2822, and it
> would spoil the fun to give them too many clues :-( .

Nowhere in 2822 did "you" (see the list of 2822 credits) try
to put a <quoted-string> into another <quoted-string>.  This
madness is a USEFOR-speciality, because unlike 2822 we don't
have the good sense to be independent of MIME.  It's 100% our
fault when we try this stunt.

> And it is not at all clear that you are allowed to use 2047
> stuff inside a <phrase> that is inside a <parameter>.

Any legal <quoted-string> is okay, there's no rule that it
cannot contain some =?..?..?..?= sub-strings.  They are no
<encoded-word>s within a <quoted-string>.  And the sub-string
\"Fred\\ Bloggs\" within a <quoted-string> is also not the
original <local-part> "Fred\ Bloggs", but it's legal and okay.

>> An implementor can't ignore 2231 Section 3 based on
>> "unlikely" and "gibbous".

> This header will be generated automatically by injecting
> agents, who can easily avoid the Section 3 stuff if they put
> their minds to it.  Hence it is most "unlikely" that they
> will find a case where they really need it.

Nevertheless it's not illegal, an implementor trying to extract
the abuse address has to get it right, funny remarks why 90% of
the necessary code are "unlikely" or "gibbous" wont't speed up
the conformance testing by a single man month.

                        Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RCf2dN080044 for <[e-mail]>; Wed, 27 Jul 2005 05:41:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RCf2Ok080043 for ietf-usefor-skb; Wed, 27 Jul 2005 05:41:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RCf2xZ080034 for <[e-mail]>; Wed, 27 Jul 2005 05:41:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id CFFB62995D; Wed, 27 Jul 2005 08:41:00 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6RCexOv011148(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 27 Jul 2005 08:41:00 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6RCexDL011147(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 27 Jul 2005 08:40:59 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
Date: Wed, 27 Jul 2005 08:40:55 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6RCf2xZ080037
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 26 2005 07:24, Charles Lindsey wrote:

> Hmmm! One could go on adding features for ever until we landed up with
> something as complex as the mail Received header :-( .

The syntax for the Received field, which is specified in one of our
normative references, so a Document Editor certainly should be familiar
with it, is:
--------
received        =       "Received:" name-val-list ";" date-time CRLF

name-val-list   =       [CFWS] [name-val-pair *(CFWS name-val-pair)]

name-val-pair   =       item-name CFWS item-value

item-name       =       ALPHA *(["-"] (ALPHA / DIGIT))

item-value      =       1*angle-addr / addr-spec /
                         atom / domain / msg-id
---------
i.e. 5 concise rules, whereas the usefor draft gives the following as
syntax for Injection-Info:

   injection-info  =  "Injection-Info:" SP [CFWS] path-identity
                      *( [CFWS] ";" [CFWS] inj-info-param )
                      [CFWS] CRLF

   inj-info-param  =  post-host-param /
                      post-acct-param /
                      sender-param /
                      logging-param /
                      complainto-param /
                      ext-param
                      ;; At most one of "post-host-param",
                      ;; "post-acct-param", "sender-param",
                      ;; "logging-param" or "complainto-param"
                      ;; is allowed.

   ext-param       = parameter
   [[Should also allow for x-attributes?]]

   post-host-param =  "posting-host" "=" host-value

   host-value      =  dot-atom / [ dot-atom ":" ]
                      ( IPv4address / IPv6address ) ;  see [RFC 3986]

   post-acct-param =  "posting-account" "=" value

   sender-param    =  "sender" "=" sender-value

   sender-value    =  mailbox / "verified"

   logging-param   =  "logging-data" "=" value

   complainto-param=  "mail-complaints-to" "=" address-list

i.e. twice as many rules, many of which are multi-line, complex rules.
It's quite clear which is more complex.

> b) 123.123.123.123 was a genuine independent site (not upstream) which
> inserted it as it passed by (violating a SHOULD NOT by using an IP rather
> than a domain name).

http://www.dictionary.com/search?q=violating

1 entry found for violating.
vi·o·late   Audio pronunciation of "violating"  P   Pronunciation Key  (v-lt)
 tr.v. vi·o·lat·ed, vi·o·lat·ing, vi·o·lates 
 To break or disregard (a law or promise, for example).
 To assault (a person) sexually.
 To do harm to (property or qualities considered sacred); desecrate or defile.
 To disturb rudely or improperly; interrupt: violated our privacy.

As SHOULD NOT is a recommendation, not a law or promise, and involves no harm,
one cannot be meaningfully accused of "violating a SHOULD NOT".  One can be
said to have *disregarded* a SHOULD NOT (iff that is known to be the case)
or it may simply be the case that there were "valid reasons in particular
circumstances to ignore a particular item" (BCP 14).

> c) 123.123.123.123 was put there by the sending agent at upstream (again
> violating that SHOULD NOT).

Again inappropriate use of "violating".  The remote site cannot determine
that "upstream" put text there, only that a site ostensibly *claiming* to
be "upstream: put it there -- that is an important (and obvious) fact.

> (c) is a less likely deduction, for surely the host 123.123.123.123 knows
> upstream.example.com well enough to be able to put a "!!" between them.

No, in the first place, that's not where "!!" appears.  In the second
place, the text may have been placed there by the site claiming to be
"upstream" (said site not actually *being* "upstream"), possibly to
implicate the site with the specified IP address.  Any claims of
"less likely", given the uncertainty of what actually happened, is
completely unsupported.
 
> And (b) is less likely than (a),

An unsupported absolute assertion...

> though you cannot be sure.

...with conflicting evasiveness.  If you're not sure which is or is not
less likely, don't make an assertion about likelihood.  Such conflicting
stuff (avoiding the n-word) doesn't add to the discussion; it decreases
the signal-to-noise ratio.

> So the  
> question is "how important is it to be able to distinguish between these
> various cases"? If it is important, then another keyword might be in
> order.

I read Russ' statement
"I wonder if we need another keyword that says 'I haven't bothered to check
whether the Path is right; here's the IP address just for the hell of it.'"
as a satirical comment on the silliness of inserting diagnostic information
(an IP address) w/o the keyword explicitly provided for indication of
diagnostic information -- that having been your suggestion, Charles.

Which brings us back to reserving use of IP addresses for diagnostic use as
discussed a month ago.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RBNtVU053168 for <[e-mail]>; Wed, 27 Jul 2005 04:23:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6RBNtru053167 for ietf-usefor-skb; Wed, 27 Jul 2005 04:23:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6RBNsa7053153 for <[e-mail]>; Wed, 27 Jul 2005 04:23:54 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-76.midband.mdip.bt.net ([81.144.70.76]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e76ec8.ba7b.101 for [e-mail]; Wed, 27 Jul 2005 12:23:52 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6RBIgx26467 for [e-mail]; Wed, 27 Jul 2005 12:18:42 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22121
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Wed, 27 Jul 2005 11:13:17 GMT
Lines: 92
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>> https://rt.psg.com/Ticket/Display.html?id=1080.

Note that the intent of this ticket is to arrive at a way of setting out
the structure of the Injection-Info header field in USEFOR that makes it
clear that it follows all the rules established by RFC 2045/2231.

It is NOT intended to challenge what I think is the (possibly reluctant)
consenus that these things are going to look and behave just like MIME
<parameter>s. If you want to do that, then start another ticket for it;
but we have already been around that route.

So, in particular, I made no change to the existing definitions of
<host-value> and <sender-value), though your suggestions concerning them
look interesting.


>> host-value = dot-atom / [ dot-atom ":" ]
>>              ( IPv4address / IPv6address ) ;  see [RFC 3986]

>How about <dot-atom-text> here ?  Unless you want the [CFWS]
>of <dot-atom> for consistency with other alues.

Yes, I might buy that idea - it would certainly reduce unnecessary
clutter.

>  It's better
>readable if you use groupings as recommended by 2234(bis):

Yes, I just copied Ken's ABNF as written. I have changed my working copy
of this text.
	

>> sender-value    =  mailbox / "verified"

>If you want to inherit 2822 [CFWS] for all values, you should
>also allow it for "verified":

More clutter. Better to s/mailbox/addr-spec/, though even that still
leaves the problem.


>>      sender = "\"Joe Q. Public\" <[e-mail]>"

>Ugh.  We end up with <quoted-string>s within a <quoted-string>
>and stuff like sender = "<\"\\\\\"@example.com>".

Yes, I put the example there to warn people. But the whole of USEFOR is
written on the (unlikely) assumption that all readers have a perfect
understanding of RFC 2822, and it would spoil the fun to give them too
many clues :-( .


>> NOTE: Should Non-ASCII characters be required in any <value>,
>> the mechanisms described in Section 4 of [RFC 2231] are
>> available.

>That would be very confusing for <mailbox>, where Section 5 or
>rather 2047 could also do the trick.

Actually, it was more "posting account" and "logging data" that I had in
mind. And it is not at all clear that you are allowed to use 2047 stuff
inside a <phrase> that is inside a <parameter>.

>> However, it is unlikely that the more gibbous mechanisms of
>> Section 3 will be needed

>That doesn't help.  An implementor can't ignore 2231 Section 3
>based on "unlikely" and "gibbous".

This header will be generated automatically by injecting agents, who can
easily avoid the Section 3 stuff if they put their minds to it. Hence it
is most "unlikely" that they will find a case where they really need it.

As for decoding it in the unlikely event that it does happen, this will
mostly fall to humans or ad hoc scripts. The humans will be mightily miffed
and send rude complaints to the perpetrators. The ad hoc scripts will
probably just ignore those cases and report to their human masters (q.v.).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QH5BdY047578 for <[e-mail]>; Tue, 26 Jul 2005 10:05:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QH5Bgs047577 for ietf-usefor-skb; Tue, 26 Jul 2005 10:05:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QH5Aq5047570 for <[e-mail]>; Tue, 26 Jul 2005 10:05:10 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxSrN-0004NB-1y for [e-mail]; Tue, 26 Jul 2005 19:04:53 +0200
Received: from c-180-162-50.hh.dial.de.ignite.net ([62.180.162.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 19:04:53 +0200
Received: from nobody by c-180-162-50.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 19:04:53 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  USEPRO 7.9 gateway (was: ABNF remarks hidden in message "Admin: I'm back.....")
Date:  Tue, 26 Jul 2005 18:58:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 76
Message-ID:  <[e-mail]>
References:  <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-162-50.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

>> It was rejected, "missing Message-ID".

> I don't follow your argument; why would a Date field be
> rejected ostensibly for "missing Message-ID"?

Because I tested 'colon SP HT CRLF SP info' in all critical
header fields simultaneously, the Message-ID was the first.

> *if* there is an implementation consideration, I have no
> objection to a suitable implementation note pointing out
> the specific issue(s), the workaround(s), and the long-term
> roadmap to full conformance with the Internet Message Format.

The long-term roadmap is to fix the <msg-id> in a 2822bis for
full conformance with what USEFOR will say, because NO-WS-CTL
was plain wrong.

> You are simply trying to move the problem to gateways.

LOL, now that would be the very last I do, it's also the only
aspect of USEFOR where I can claim some rudimentary knowledge
above "read and understood s-o-1036".   ^^^^^^^^^^^

> A "fix" (i.e. breaking security mechanisms and MIME
> compliance) at a gateway is no better than one at an
> injection agent.

Gateway operators are used to all kinds of trouble, mail2news
is a trivial case, with fido2news it starts to get interesting.

Yes, of course attempts to "fix" something are often a really
bad idea.  There are conditions where it could break.  I've
posted one "impossible" case here, see...

<http://mid.gmane.org/[e-mail]>

...that should be a USEPRO ticket if Harald's procedure works,
the subject was "NEW USEPRO 7.9 gateway (was: LTRU questions)".
So far for your idea that I ignore gateway issues.

>> bad enough for mail2news gateways, let's not make it worse.
> You are making it worse for gateways (see above).

I'm just stating the obvious, it IS bad for mail2news gateways.

Where injection-agents silently "fix" a missing SP - compare
my test results incl. s/HT/SP/ - it hits also mail (behind a
news2mail gateway), any signature of header fields created by
the UA could then arrive as trash depending on the algorithm.

Therefore the UA has to generate the magic SP.

>> I'm not sure why they do this, but I trust that it's not for
>> fun (or for your fetish idea ;-)

> If you're not sure and cannot provide a precise
> specification, then it can't be clear.

Hey, I never operated any news server.  I had a Fido node for
some time, and used Crosspoint some time (that's an UA with a
builtin pseudo-gateway, rfc2Z, fido2Z, even Z2Z because it had
its own vision of the Z-format, and v.v.), I read some German
groups about gateways some time.  I have the grizzly book and
an original 1994 copy of s-o-1036, that's all.  I know nothing
about INN, and I couldn't post with telnet without looking in
the RfC for each and every command.  And my DOS UUCP was mail
only.  So if I don't know why this SP is necessary it proves
only that I don't know it, not that it's a "fetish".

> At the moment, "fetish" is the theory which best fits the
> observable facts.

Don't count my ignorance as supporting this theory.  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QGKXUQ043013 for <[e-mail]>; Tue, 26 Jul 2005 09:20:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QGKXSC043012 for ietf-usefor-skb; Tue, 26 Jul 2005 09:20:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QGKW1L043003 for <[e-mail]>; Tue, 26 Jul 2005 09:20:32 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-74-250.midband.mdip.bt.net ([81.144.74.250]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e662cc.d3b3.1c9 for [e-mail]; Tue, 26 Jul 2005 17:20:28 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6QGCT114421 for [e-mail]; Tue, 26 Jul 2005 17:12:29 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22111
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Tue, 26 Jul 2005 11:24:03 GMT
Lines: 70
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Charles Lindsey <[e-mail]> writes:

>> I don't quite follow there. For sure we don't want sites putting in
>> MISMATCH unless they have actually checked and found something fishy. If
>> they put the sending IP address in without MISMATCH, then they are
>> saying "This is where we got it from; compare it with the next thing in
>> the Path yourself if you are bothered". Just so long as they don't
>> follow it with a "!!" if they have not actually done the check.

>I wonder if we need another keyword that says "I haven't bothered to check
>whether the Path is right; here's the IP address just for the hell of it."

Hmmm! One could go on adding features for ever until we landed up with
something as complex as the mail Received header :-( .

OK, we have a site upstream.example.com, whose IP address is (apparently)
123.123.123.123, and a site downstream.example.com. So the Path might
contain:

    ....!downstream.example.com!!123.123.123.123!upstream.example.com!.....

The 123.123.123.123 was put there "just for the hell of it" by downstream,
and was preceded by "!!" (because for sure it was taken straight from the
packets received). The "!" afterwards indicates "we didn't (bother to)
check whether that is the IP used by upstream.

What can a reader of that Path deduce? The following are possible:

a) 123.123.123.123 was a diagnostic put there by downstream.
b) 123.123.123.123 was a genuine independent site (not upstream) which
inserted it as it passed by (violating a SHOULD NOT by using an IP rather
than a domain name).
c) 123.123.123.123 was put there by the sending agent at upstream (again
violating that SHOULD NOT). Maybe it was the same host as
upstream.example.com, or maybe it passed through both hosts at upstream.

(c) is a less likely deduction, for surely the host 123.123.123.123 knows
upstream.example.com well enough to be able to put a "!!" between them.

And (b) is less likely than (a), though you cannot be sure. So the
question is "how important is it to be able to distinguish between these
various cases"? If it is important, then another keyword might be in
order.

Don't forget that downstream is not precluded from using the domain name
(from a Reverse Lookup, perhaps) of 123.123.123.123 in its diagnostic, so
you might see

    ....!downstream.example.com!!upstream.example.com!upstream.example.com!...
or
    ....!downstream.example.com!!relay.upstream.example.com!upstream.example.com!...

So that gives you several more deducible scenarios corresponding to (a),
(b) or (c). All of which makes the idea on a further keyword a little more
attractive.

OK, let us try to digest all that and figure out all the consequences.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QG31ll041717 for <[e-mail]>; Tue, 26 Jul 2005 09:03:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QG31Zi041716 for ietf-usefor-skb; Tue, 26 Jul 2005 09:03:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QG30Uf041708 for <[e-mail]>; Tue, 26 Jul 2005 09:03:01 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxRsM-00025Y-Sk for [e-mail]; Tue, 26 Jul 2005 18:01:50 +0200
Received: from c-180-162-50.hh.dial.de.ignite.net ([62.180.162.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 18:01:50 +0200
Received: from nobody by c-180-162-50.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 18:01:50 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: FWS-bugs in 2.2, 3.1.3, 3.1.5, 3.1.6, 3.2.3, 3.2.5, 3.2.6, 3.2.7, 3.2.11, 3.3.1
Date:  Tue, 26 Jul 2005 17:59:09 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Message-ID:  <[e-mail]>
References:  <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-162-50.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> You are in effect proposing writing a complete message syntax

No, I propose to replace all explicitly forbidden (in prose)
[FWS] in the explicitly given syntax by a correct *WSP.  The
syntax is already there, it's only wrong.

> down to low-level detail

That's no low-level detail.  Control, Supersedes, Message-ID,
etc. are vital.  If some servers accept an obs-FWS and others
ignore any folded info for the [FWS] after the magic SP, then
it could result in chaos.

Maybe we should limit this "MAY accept obs" in 2.1 somehow.

First idea "...where it doesn't violate an explicitly stated
MUST or MUST NOT in this memo".
                                Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QFX3ov038065 for <[e-mail]>; Tue, 26 Jul 2005 08:33:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QFX26o038064 for ietf-usefor-skb; Tue, 26 Jul 2005 08:33:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QFX108038047 for <[e-mail]>; Tue, 26 Jul 2005 08:33:01 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxRP9-0004kl-2x for [e-mail]; Tue, 26 Jul 2005 17:31:39 +0200
Received: from c-180-162-50.hh.dial.de.ignite.net ([62.180.162.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 17:31:39 +0200
Received: from nobody by c-180-162-50.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 17:31:39 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Tue, 26 Jul 2005 17:14:21 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 138
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-162-50.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

>>> [RFC 822], effectively allows [CFWS] to occur both before
>>> and after the <parameter>, and also on either side of its
>>> "="

> Add reference to the Errata page, s/822/2822/.

It's about 822, we just discussed these issues on the 822 list,
2231 and 2045 were written before 2822.

>> None of these parameters cries for I18N, therefore I propose
>> to use the SPF syntax <key-value-list> bypassing <parameter>

> SPF = not a standard of any kind, certainly not a normative
> reference

I'm not talking about references, what a strange idea, neither
normative nor informative, and also no acknowledgements.  It's
just a place to grab the <key-value-list> idea, and use it for
the Injection-Info values.

> SPF is HARMFUL.

For spammers, they feel forced to respect it.  Poor bastards.

> RFC 2047/2231/errata isn't solely about i18n, it also
> addresses long parameters which may need to be split and
> language-tagging.
[...]
> A host name can be up to 255 octets, and there are
> recommended line length limits << 255.

FQDNs are used everywhere in header fields, why should that be
different for the posting-host value ?

You only need 2231 folding where embedded WSP can be sigificant
(file names) or when you hit the 997 limit (excl. URLs, where
you can get away with dummy inserted FWS by just specifying it)

> A mailbox can be >> 255 octets (local-part, '<', '@', '>',
> CFWS in addition to domain name).

No WSP delimited part exceeds 997, otherwise it won't work in
header fields like From, Sender, or Reply-To.  Where does this
magic 255 come from, AFAIK not 2045 / 2231 / 2822, and if you
are a Pascal-fan I'd be surprised.

>>> Should Non-ASCII characters be required in any <value>,
>>> the mechanisms described in Section 4 of [RFC 2231] are
>>> available.

>> That would be very confusing for <mailbox>, where Section 5
>> or rather 2047 could also do the trick.

> No. RFC 2047 is applicable in precisely 3 contexts: an
> unstructured field (not applicable to this case), in a
> comment in a structured field (also not applicable in this
> case), and as a word in a phrase in a structured field
> (possibly applicable for a display name, but not for
> local-part or domain

Only a display name.  Local part or domain are plain US ASCII.

Just take the complete valid <mailbox> and stuff it as is into
the value of the sender-parameter, ready.  A <mailbox> contains
at least "@", therefore this value has to be a quoted string.

It starts with a DQUOTE, and it ends with an unescaped DQUOTE.
Any DQUOTE within it has to be escaped (\"), therefore also
all backslashes within it have to be escaped (\\).  Other stuff
works as is, insert FWS when necessary and where it's allowed.

While a formerly encoded word sits within a quoted string it is
no more encoded word, it's just ASCII with peculiar "?" and "="
characters.  After you have upacked it (undoing any escapes) it
is again a valid encoded word.  Assuming you started with a
valid encoded word, it's a garbage in / garbage out procedure.

Where's the problem ?  If that's too shaky for your tastes we
could restrict the sender-value to <addr-spec>, nobody needs
any <display-name> in the Injection-Info.

> local-parts remain to be specified

They are already specified, but not in RfC 3696 chapter 3.

> There was a proposal to use a parameter-less (Received-like)
> syntax some time ago, but there was no traction.

Yes, the stuff copied from the weird Received-SPF header field.

> Feel free to try that again, Frank, if you think it will fly
> now.

 injection-info = "Injection-Info:" SP [CFWS] path-identity
                  [CFWS inj-value-list] CRLF

 inj-value-list = inj-value-pair
                  *( ";" [CFWS] inj-value-pair ) [";"]

 inj-value-pair = inj-key [CFWS] "=" (dot-atom / quoted-string)

 inj-key        = "posting-host" / "posting-account" /
                  "sender" / "logging-data" /
                  "mail-complaints-to" /
                  ( "x-" *(ALPHA / DIGIT / "-") ALPHA / DIGIT )

 inj-posting-host = <etc. as in usefor-05, names starting with
                    "inj-" followed by the name of the inj-key>

> The length issues related to mailbox are even wore germane to
> address-list, as a single address can be a named group, and
> an address-list can contain multiple comma-separated
> addresses, possibly with interspersed CFWS.

Nothing forces you to put a value in one line, or to fold it
at places where it can't be folded.  The normal folding works:

[...] mail-complaints-to = "
 insert folded escaped address-list here
 ";sender = "
 insert folded escaped mailbox here
 " ;x-foo = bar

As soon as there's an optional [FWS] at both ends it should
work.  A less ugly style:

[...] mail-complaints-to =
 "insert folded escaped
 address-list
 between DQUOTEs"; sender =
 "insert folded escaped
 mailbox between DQUOTEs"; x-foo = bar

We'd be in trouble if logging-data or posting-account exceeds
995 characters, but otherwise I don't see the problem.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QFHnaZ036736 for <[e-mail]>; Tue, 26 Jul 2005 08:17:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QFHnpV036735 for ietf-usefor-skb; Tue, 26 Jul 2005 08:17:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QFHndj036705 for <[e-mail]>; Tue, 26 Jul 2005 08:17:49 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6QFHhWP089815 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 26 Jul 2005 08:17:43 -0700 (PDT)
Date: Tue, 26 Jul 2005 08:17:43 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1080 - MIME parameters for Injection-Info 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>This ticket was created by Alexey, but not announced to this list.

Yet another case of the tail wagging the dog. Is this mailing list the 
right place to discuss USEFOR issues, or is it the (broken) ticket system?

And why should I have to ask this question a second time, after the first 
incident of magic tickets?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QFBVB6035866 for <[e-mail]>; Tue, 26 Jul 2005 08:11:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QFBVUx035865 for ietf-usefor-skb; Tue, 26 Jul 2005 08:11:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QFBU0T035847 for <[e-mail]>; Tue, 26 Jul 2005 08:11:31 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6QFBPWP087012 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 26 Jul 2005 08:11:25 -0700 (PDT)
Date: Tue, 26 Jul 2005 08:11:25 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Thank you for confirming that I had not said what you had alleged I had 
>said.

What I wrote was sloppy but not fatal, Charles. I left out "that is
inserted by an injecting agent", and I assumed that I had quoted the text
often enough that it would not confuse you. I'm sorry you got confused.  
(No, I know you aren't confused, you know exactly what text is being
discussed and what the problem is. You are just trying every trick you can
think of to avoid discussing the issue.)

>No, if you have a problem, please describe it in terms of what is actually
>being proposed.

I have, Charles, multiple times. I just quoted the problem text VERBATIM,
AGAIN, and was explicit as to what the problem was, in the email you just
responded to, and you have conveniently ignored that. Instead, you
demanded that I tell you the problem text and what the problem is. Stop
playing games.

We already demand that both "news" and "usenet" be mailable addresses,
even though I still have seen no justification for having two. Either
justify a mandate (of any kind, much less RFC2119) requiring a THIRD
mailable address for a news host or remove it. 

Will one of the chairs please step in here? There is a valid issue on the
table (overriding an explicit statement in an existing standard with an
unjustifiable RFC2119 mandate) that has an apparent consensus to remove
the mandate, and the editor is refusing to remove it. The problem text has
been quoted verbatim, and replacement text has been suggested. He's not
even open to a discussion of the problem, it seems, preferring to play
this "ask me again, again" game. It's an abuse of his position as draft
editor, again. I'm sure it pleases you that he does this, but it's time
for it to end.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QDTl2G018773 for <[e-mail]>; Tue, 26 Jul 2005 06:29:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QDTlre018772 for ietf-usefor-skb; Tue, 26 Jul 2005 06:29:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QDTlfS018761 for <[e-mail]>; Tue, 26 Jul 2005 06:29:47 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id 5FB9B299BA; Tue, 26 Jul 2005 09:29:46 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6QDTf0g025728(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Tue, 26 Jul 2005 09:29:43 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6QDTfhn025727(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Tue, 26 Jul 2005 09:29:41 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Date: Tue, 26 Jul 2005 09:29:38 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri July 22 2005 21:41, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
>  
> >> Everybody who knows the 2822 <orig-date> will immediately
> >> see the added SP.
>  
> > But it doesn't say *why* there is an added SP
> 
> Maybe propose some text for the general MUST about this issue.
> I've just tested the very last chance:  ":" SP HT CRLF SP ...
> It was rejected, "missing Message-ID". 

I don't follow your argument; why would a Date field be rejected
ostensibly for "missing Message-ID"?


>  [back to <unstructured>]
> > We disagree on your narrow interpretation
> 
> Apparently.  Your broad interpretation won't work for similar
> cases like <word> and <atom> as discussed in...

There's no similarity there; CFWS is an obviously-capitalized, non-word
abbreviation; "word" is not capitalized, is a word, and is not an
abbreviation.

> You're a special case, you want the RFC 2822 <msg-id> "as is",
> ignoring all boring facts like reality or the USEFOR charter.

No, *if* there is an implementation consideration, I have no objection
to a suitable implementation note pointing out the specific issue(s),
the workaround(s), and the long-term roadmap to full conformance with
the Internet Message Format.  What I object to is violating our stated
(sect. 1.6) and agreed-upon methodology (cite by reference, not rewrite)
and attempts to rewrite a normative reference which is outside our
jurisdiction.
 
> > True but irrelevant.  A UA generating a message cannot
> > readily determine where that message will go
> 
> Yes, that's why it always generates ": " with SP, that works.

No, it doesn't necessarily do so. ":" is the standard message format
field body delimiter (not ": "), and a message using only ":" as the
delimiter is perfectly valid.  Messages may find their way to a gateway
(possibly w/o knowledge of the author or sender), and an artifical
requirement means that a gateway or associated injection agent would have
to:
o modify the message, possibly invalidating security measures
o because the length is increased, take into account any encoded-words
  and re-fold if length changes e.g. from 76 octets to 77 (and in turn
  that presents a problem w.r.t. the other artificial (failing some
  rationale) "MUST contain at least one non-whitespace character" rule)
  or decode and re-encode encoded-words to reduce length (not always
  possible, non-trivial, almost certain to invalidate security measures,
  and may cause minor problems for naive killfile processors).
 
> > in principle altering messages after generation causes
> > problems (e.g. invalidates security mechanisms).
> 
> ACK, therefore we stick to a mandatory SP instead of trusting
> that injection agents could "fix" this if it's missing.

No, no, no.  You are simply trying to move the problem to gateways. RFC
1925:

   (6)  It is easier to move a problem around (for example, by moving
        the problem to a different part of the overall network
        architecture) than it is to solve it.

The problem (caused by the not-justified SP requirement) remains. A
"fix" (i.e. breaking security mechanisms and MIME compliance) at a
gateway is no better than one at an injection agent.

> It's 
> bad enough for mail2news gateways, let's not make it worse.

You are making it worse for gateways (see above).
 
> > up to those who wish to impose the additional SP requirement
> > to specify precisely where the serious issues warranting
> > imperative keywords arise
> 
> As long as injection agents feel obliged to "fix" my articles
> the serious issues are clear.  I'm not sure why they do this,
> but I trust that it's not for fun (or for your fetish idea ;-)

If you're not sure and cannot provide a precise specification, then it
can't be clear.  At the moment, "fetish" is the theory which best fits
the observable facts.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QD42wd009119 for <[e-mail]>; Tue, 26 Jul 2005 06:04:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QD42aF009118 for ietf-usefor-skb; Tue, 26 Jul 2005 06:04:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns2.townisp.com (ns2a.townisp.com [216.195.0.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QD41LE009105 for <[e-mail]>; Tue, 26 Jul 2005 06:04:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns2.townisp.com (Postfix) with ESMTP id 0E07029990; Tue, 26 Jul 2005 09:04:00 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6QD3vFQ025633(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Tue, 26 Jul 2005 09:03:59 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6QD3tqn025632(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Tue, 26 Jul 2005 09:03:56 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: FWS-bugs in 2.2, 3.1.3, 3.1.5, 3.1.6, 3.2.3, 3.2.5, 3.2.6, 3.2.7, 3.2.11, 3.3.1 (was: ABNF remarks hidden in message "Admin: I'm back.....")
Date: Tue, 26 Jul 2005 09:03:53 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 26 2005 06:19, Frank Ellermann wrote:

> If the ABNF says [FWS] with some additional prose elsewhere
> explaining that sometimes [FWS] actually stands for *WSP,
> then that's FUBAR.  It has to be fixed because it's broken.
> And it's no feature, therefore it's a bug.

You are in effect proposing writing a complete message syntax specification
down to low-level detail, one which is not based on 2822 and MIME (as our
work is supposed to be, and as it is claimed (at the moment, falsely) to be
in section 1.6), and which could require a separate parser from those used
for the Internet Message Format, invalidating the primary consideration of
RFCs 850 & 1036: "fit in with existing tools as well as possible". 

> Otherwise we could as well delete all ABNF with the magic SP,

And probably should do so, failing any justification for it, esp. w/ BCP 14
imperative keywords.

> Bruce's objection that *WSP won't allow <obs-FWS> was better.
> 
> OTOH we don't allow the <obs-FWS>,

That's incorrect; usefor states "agents MAY also accept the obsolete syntax
specified in Section 4 of [RFC2822]" whereas you are stating that "we don't
allow" that.

> For the leading [FWS] after the magic SP we MUST say *WSP, it
> affects critical header fields like Control, Supersedes, and
> Distribution.   If a "MAY accept obs" server accepts <obs-FWS>
> it won't work as expected.  That's no ABNF-aesthetical issue,
> that's HAVOC, it's harmful.

Not in the absence of a justification for the "MUST contain at least one non-
whitespace character" statement.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QCqVE2005137 for <[e-mail]>; Tue, 26 Jul 2005 05:52:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QCqVru005136 for ietf-usefor-skb; Tue, 26 Jul 2005 05:52:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QCqULA005123 for <[e-mail]>; Tue, 26 Jul 2005 05:52:31 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id CF80A299AE; Tue, 26 Jul 2005 08:52:29 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6QCqOKF025553(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Tue, 26 Jul 2005 08:52:29 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6QCqOcT025552(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Tue, 26 Jul 2005 08:52:24 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date: Tue, 26 Jul 2005 08:52:22 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6QCqVLA005128
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 26 2005 03:23, Frank Ellermann wrote:
> 
> Charles Lindsey wrote:

> > NOTE: The syntax of <parameter> ([RFC2045] as amended by
> > [RFC2231]), taken in conjunction with the folding rules of
> > [RFC 822], effectively allows [CFWS] to occur both before
> > and after the <parameter>, and also on either side of its "="

Add reference to the Errata page, s/822/2822/.
 
> None of these parameters cries for I18N, therefore I propose 
> to use the SPF syntax <key-value-list> bypassing <parameter>.

SPF = not a standard of any kind, certainly not a normative
reference (and cannot be because it would be an improper
downward reference), and SPF is HARMFUL.

RFC 2047/2231/errata isn't solely about i18n, it also addresses
long parameters which may need to be split and language-tagging.

> > host-value = dot-atom / [ dot-atom ":" ]
> >              ( IPv4address / IPv6address ) ;  see [RFC 3986]

A host name can be up to 255 octets, and there are recommended line
length limits << 255.

> > sender-value    =  mailbox / "verified"

A mailbox can be >> 255 octets (local-part, '<', '@', '>', CFWS in
addition to domain name).
 
> > NOTE: Should Non-ASCII characters be required in any <value>,
> > the mechanisms described in Section 4 of [RFC 2231] are
> > available.
> 
> That would be very confusing for <mailbox>, where Section 5 or
> rather 2047 could also do the trick.

No. RFC 2047 is applicable in precisely 3 contexts: an unstructured
field (not applicable to this case), in a comment in a structured
field (also not applicable in this case), and as a word in a phrase
in a structured field (possibly applicable for a display name, but
not for local-part or domain [of course, the domain should use the
on-the-wire IDN format which is comprised solely of letters, digits
and hyphens plus dots; local-parts remain to be specified]).

Charles' message also mentioned:
>    "posting-account"                     any <value>
>    "logging-data"                        any <value>
>    "mail-complaints-to"                  <address-list>

and Frank remarked:

> An implementor can't ignore 2231 Section 3
> based on "unlikely" and "gibbous".

True.

> Avoid <parameter> at all 
> costs, even dropping the complete Injection-Info is an option
> if <key-value-pair> doesn't work.

There was a proposal to use a parameter-less (Received-like) syntax
some time ago, but there was no traction.  Feel free to try that
again, Frank, if you think it will fly now.

> We don't need I18N in the 
> Injection-Info beyond 2047.

"any <value>" might conceivably need i18n, as well as splitting of long
values and/or language-tagging.  The length issues related to mailbox
are even wore germane to address-list, as a single address can be a
named group, and an address-list can contain multiple comma-separated
addresses, possibly with interspersed CFWS.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QBDc1N063888 for <[e-mail]>; Tue, 26 Jul 2005 04:13:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QBDcZV063887 for ietf-usefor-skb; Tue, 26 Jul 2005 04:13:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QBDaUs063870 for <[e-mail]>; Tue, 26 Jul 2005 04:13:37 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-248.midband.mdip.bt.net ([81.144.65.248]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e61adf.dadd.45 for [e-mail]; Tue, 26 Jul 2005 12:13:35 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6QBCXx10926 for [e-mail]; Tue, 26 Jul 2005 12:12:33 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22109
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 26 Jul 2005 10:49:57 GMT
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>I have NEVER EVER proposed any "MUST regarding an abuse@ address at every
>>FQDN that appears in a path".

>Here is the text that is unacceptable, and that you have repeatedly been 
>unwilling the mandate contained therein:

>   For an injecting agent prepending to a Path header field (7.2.2), the
>   <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable,
>   and if the agent offers its services to the general public the form
>   "abuse@" that FQDN MUST also be available, unless a more specific
>   complaints address has been provided in a <complainto-param> of an
>   Injection-Info header field (F-3.2.14).

>Yes, it does not say "every FQDN", but you know what text is being 
>discussed because I have quoted it to you many times already, INCLUDING an 
>acceptable alternative.

Thank you for confirming that I had not said what you had alleged I had said.

No, if you have a problem, please describe it in terms of what is actually
being proposed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QAkWAf053572 for <[e-mail]>; Tue, 26 Jul 2005 03:46:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6QAkWvY053571 for ietf-usefor-skb; Tue, 26 Jul 2005 03:46:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QAkUOC053547 for <[e-mail]>; Tue, 26 Jul 2005 03:46:31 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxMx3-0005Jq-IK for [e-mail]; Tue, 26 Jul 2005 12:46:21 +0200
Received: from c-180-162-50.hh.dial.de.ignite.net ([62.180.162.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 12:46:21 +0200
Received: from nobody by c-180-162-50.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 12:46:21 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  FWS-bugs in 2.2, 3.1.3, 3.1.5, 3.1.6, 3.2.3, 3.2.5, 3.2.6, 3.2.7, 3.2.11, 3.3.1 (was: ABNF remarks hidden in message "Admin: I'm back.....")
Date:  Tue, 26 Jul 2005 12:19:21 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Message-ID:  <[e-mail]>
References:  <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-162-50.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>> For the trailing [FWS] CRLF it's less clear, Charles
>> admitted that it's a bug in 2822 <unstructured>, therefore
>> it's also a bug in USEFOR:

> Not so. The "Bug" is in 3.2.3 of RFC 2822, but USEFOR
> contains a different text to cover that problem, and the
> USEFOR text has no bug.

If the ABNF says [FWS] with some additional prose elsewhere
explaining that sometimes [FWS] actually stands for *WSP,
then that's FUBAR.  It has to be fixed because it's broken.
And it's no feature, therefore it's a bug.

Otherwise we could as well delete all ABNF with the magic SP,
because USEFOR contains text to cover the magic SP.  Or other
parts of the ABNF fully covered by the prose.  That makes no
sense, your argument doesn't convince me.

Bruce's objection that *WSP won't allow <obs-FWS> was better.

OTOH we don't allow the <obs-FWS>, and at least for the [FWS]
after the magic SP that's no error, it really MUST be *WSP.

For the trailing [FWS] before the CRLF we should say what we
mean, e.g. OFWS = *WSP / obs-FWS, where the <obs-FWS> is only
relevant for servers using the "MAY accept obs" clause in 2.1.

For the leading [FWS] after the magic SP we MUST say *WSP, it
affects critical header fields like Control, Supersedes, and
Distribution.   If a "MAY accept obs" server accepts <obs-FWS>
it won't work as expected.  That's no ABNF-aesthetical issue,
that's HAVOC, it's harmful.
                            Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6Q7QJBx078936 for <[e-mail]>; Tue, 26 Jul 2005 00:26:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6Q7QJQw078935 for ietf-usefor-skb; Tue, 26 Jul 2005 00:26:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6Q7QHKu078915 for <[e-mail]>; Tue, 26 Jul 2005 00:26:17 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxJpJ-0000SY-Hs for [e-mail]; Tue, 26 Jul 2005 09:26:09 +0200
Received: from 212.82.251.101 ([212.82.251.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 09:26:09 +0200
Received: from nobody by 212.82.251.101 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 26 Jul 2005 09:26:09 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Date:  Tue, 26 Jul 2005 09:23:21 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 67
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.101
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> https://rt.psg.com/Ticket/Display.html?id=1080.

Apparently down.

> injection-info  =  "Injection-Info:" SP [CFWS] path-identity
>                    [CFWS] *( ";" parameter ) RLF
 
> NOTE: The syntax of <parameter> ([RFC2045] as amended by
> [RFC2231]), taken in conjunction with the folding rules of
> [RFC 822], effectively allows [CFWS] to occur both before
> and after the <parameter>, and also on either side of its "="

None of these parameters cries for I18N, therefore I propose 
to use the SPF syntax <key-value-list> bypassing <parameter>.

> host-value = dot-atom / [ dot-atom ":" ]
>              ( IPv4address / IPv6address ) ;  see [RFC 3986]

How about <dot-atom-text> here ?  Unless you want the [CFWS]
of <dot-atom> for consistency with other alues.  It's better
readable if you use groupings as recommended by 2234(bis):

  host-value = dot-atom / 
               ( [dot-atom ":"] (IPv4address / IPv6address) )

It doesn't have square brackets this way, we could roll our
own IPaddress for this purpose:

  host-value = dot-atom / ( [dot-atom ":"] "[" IP-address "]" )
  IP-address = ( IPv4address / IPv6address ) ;  see [RFC 3986]

> sender-value    =  mailbox / "verified"

If you want to inherit 2822 [CFWS] for all values, you should
also allow it for "verified":

  sender-value    =  mailbox / ( [CFWS] "verified" [CFWS] )

>      sender = "\"Joe Q. Public\" <[e-mail]>"

Ugh.  We end up with <quoted-string>s within a <quoted-string>
and stuff like sender = "<\"\\\\\"@example.com>".

I've no idea how to avoid it... :-(  This *NIXism has to be
explained, maybe a second example, <"\\"@example.com> results
in sender = "<\"\\\\\"@example.com>".

> NOTE: Should Non-ASCII characters be required in any <value>,
> the mechanisms described in Section 4 of [RFC 2231] are
> available.

That would be very confusing for <mailbox>, where Section 5 or
rather 2047 could also do the trick.  Get rid of <parameter>,
I really don't like it.

> However, it is unlikely that the more gibbous mechanisms of
> Section 3 will be needed

That doesn't help.  An implementor can't ignore 2231 Section 3
based on "unlikely" and "gibbous".  Avoid <parameter> at all
costs, even dropping the complete Injection-Info is an option
if <key-value-pair> doesn't work.  We don't need I18N in the
Injection-Info beyond 2047.
                            Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PI7tfG056501 for <[e-mail]>; Mon, 25 Jul 2005 11:07:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PI7tkM056500 for ietf-usefor-skb; Mon, 25 Jul 2005 11:07:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PI7tsf056494 for <[e-mail]>; Mon, 25 Jul 2005 11:07:55 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6PI7sxd001520 for <[e-mail]>; Mon, 25 Jul 2005 11:07:54 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3EB88E7928; Mon, 25 Jul 2005 11:07:54 -0700 (PDT)
To: [e-mail]
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Mon, 25 Jul 2005 10:56:47 GMT")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 25 Jul 2005 11:07:53 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:
> Russ Allbery <[e-mail]> writes:

>> This reduces to the case where no matching information is stored and
>> all sites are mismatches, which conveniently is generally exactly
>> what's going on with the sites that always embed an IP address, so the
>> only affect of the change that you propose would be to allow one to
>> omit the "MISMATCH" entry.  I guess I don't really care.

> I don't quite follow there. For sure we don't want sites putting in
> MISMATCH unless they have actually checked and found something fishy. If
> they put the sending IP address in without MISMATCH, then they are
> saying "This is where we got it from; compare it with the next thing in
> the Path yourself if you are bothered". Just so long as they don't
> follow it with a "!!" if they have not actually done the check.

I wonder if we need another keyword that says "I haven't bothered to check
whether the Path is right; here's the IP address just for the hell of it."

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PGFtsv042203 for <[e-mail]>; Mon, 25 Jul 2005 09:15:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PGFt8d042202 for ietf-usefor-skb; Mon, 25 Jul 2005 09:15:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PGFs5e042195 for <[e-mail]>; Mon, 25 Jul 2005 09:15:54 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-203.midband.mdip.bt.net ([81.144.67.203]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e51038.9f5f.2f for [e-mail]; Mon, 25 Jul 2005 17:15:52 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6PGCFg28537 for [e-mail]; Mon, 25 Jul 2005 17:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22104
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1080 -  MIME parameters for Injection-Info and Archive header field need more text/updated syntax
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
Date: Mon, 25 Jul 2005 11:49:32 GMT
Lines: 73
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

This ticket was created by Alexey, but not announced to this list. For the
full text, see https://rt.psg.com/Ticket/Display.html?id=1080.

However, that text is a little dated, and the problem has already been
mentioned on this list. Essentially, it is that the current syntax
introducing the various <parameter>s in Injection-Info fails to account
for various features of RFC 2045, for example the necessity to encapsulate
in a <quoted-string>.

Also, the problem no longer arises with the Archive header field, since we
no longer define the "filename" parameter there.

Here is a proposed text to replace the present start of USEFOR 3.2.14:

   injection-info  =  "Injection-Info:" SP [CFWS] path-identity
                      [CFWS] *( ";" parameter ) CRLF

     NOTE: The syntax of <parameter> ([RFC2045] as amended by
     [RFC2231]), taken in conjunction with the folding rules of [RFC
     822], effectively allows [CFWS] to occur both before and after the
     <parameter>, and also on either side of its "=".

   This standard defines <parameter>s for use with this header field as
   listed in the following table. At most one occurrence of each is
   allowed.

   <attribute>                           syntax of <value>
   -------------------------------------------------------

   "posting-host"                        <host-value>
   "posting-account"                     any <value>
   "sender"                              <sender-value>
   "logging-data"                        any <value>
   "mail-complaints-to"                  <address-list>

   where

   host-value      =  dot-atom / [ dot-atom ":" ]
                      ( IPv4address / IPv6address ) ;  see [RFC 3986]
   sender-value    =  mailbox / "verified"

     NOTE: Since each <host-value>, <sender-value> or <address-list>
     also has to be a syntactically correct <value>, it will often be
     necessary to encapsulate is as a <quoted-string>, for example:

     sender = "\"Joe Q. Public\" <[e-mail]>"

   Additionally, <parameter>s whose <attribute> starts with "x-" MAY be
   used where the defined ones appear to be insufficient, but other
   unlisted <parameter>s SHOULD NOT be used unless defined in extensions
   to this standard.

     NOTE: Should Non-ASCII characters be required in any <value>, the
     mechanisms described in Section 4 of [RFC 2231] are available.
     However, it is unlikely that the more gibbous mechanisms of Section
     3 will be needed, given the possibility of folding within
     <quoted-string>s and the lack of any limit on the length of a
     header line short of the maximum 998 characters.


If that last paragraph is a bit too gibbous for your taste, no huge harm
would arise from omitting it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PFI7sG035862 for <[e-mail]>; Mon, 25 Jul 2005 08:18:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PFI7ue035861 for ietf-usefor-skb; Mon, 25 Jul 2005 08:18:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PFI6qQ035836 for <[e-mail]>; Mon, 25 Jul 2005 08:18:06 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6PFI1WP050148 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 25 Jul 2005 08:18:01 -0700 (PDT)
Date: Mon, 25 Jul 2005 08:18:01 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>"Established custom" is how Usenet works, and it is not our job to change
>that. 

What a meaningless statement. We aren't talking about changing 
"established custom." The problem is that "established custom" is totally 
meaningless as a defining limit. 

>It exists; it works.

You say that is if you thought there were just one "established custom", 
and that the one "established custom" was the solution to all our 
problems. There are as many "established customs" on USENET are there are 
newsgroups, I would dare say; perhaps a few less based on the same person 
moderating more than one group. Ok, in the newsgroups I read, the 
established custom is that I can cancel anything I don't want to see. 
Established custom works. Fine business, OM.

>The text I quoted in is USEAGE, and has no normative effect.

It will be in "a standard" and people will quote that standard to justify 
their enforcement of "established custom". 

>>Is there a requirement for globally permanently unique or not? 

>There is, but there is no *mandated* method of achieving it (there is a
>REOMMENDED method).

That's not what we are talking about, either. Read what I quoted you 
writing:

]We are talking here of people who construct <msg-id>s which contain the
]names of other people's domains in their <id-right>. Assuming that they
]have taken care to choose an <id-left> such that the <msg-id> as a whole
]is still globally unique, they are not in breach of USEFOR; nothing will
]break as a result, hence they are not in breach of USEPRO.

If we care about "globally permanently unique", then saying what you just
did is contradictory. You cannot say that it is ok to use someone else's
domain name ("not in breach of USEFOR" and "not in breach of USEPRO") and
even hope for such a condition to exist. I gave just one example;  
[e-mail], given that example.com is not my domain, may be globally
unique today, but it will not be globally unique when someone at
example.com posts their next article.

>It is well known that generating <msg-id>s that can be predicted by the
>Bad Guys is poor practice,

Irrelevant. Either globally permanently unique is the goal, or it is not. 
If it is, then saying what you did is simply ludicrous. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PF4dkF034130 for <[e-mail]>; Mon, 25 Jul 2005 08:04:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PF4d6U034129 for ietf-usefor-skb; Mon, 25 Jul 2005 08:04:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PF4dfp034099 for <[e-mail]>; Mon, 25 Jul 2005 08:04:39 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6PF4XWP043291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 25 Jul 2005 08:04:33 -0700 (PDT)
Date: Mon, 25 Jul 2005 08:04:33 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>I have NEVER EVER proposed any "MUST regarding an abuse@ address at every
>FQDN that appears in a path".

Here is the text that is unacceptable, and that you have repeatedly been 
unwilling the mandate contained therein:

   For an injecting agent prepending to a Path header field (7.2.2), the
   <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable,
   and if the agent offers its services to the general public the form
   "abuse@" that FQDN MUST also be available, unless a more specific
   complaints address has been provided in a <complainto-param> of an
   Injection-Info header field (F-3.2.14).

Yes, it does not say "every FQDN", but you know what text is being 
discussed because I have quoted it to you many times already, INCLUDING an 
acceptable alternative.

Stop pretending that you don't know what text we are talking about. Your 
pretenses are just causing frustration and wasting our time.

>May I suggest that you read USEPRO-04, and then come back here with such
>problems as you may have with what is proposed there.

May I suggest that you justify the mandate that you have created or remove 
it? The clear consensus from discussion about this text in this group is 
that the mandate in unwarranted and should be removed, and unless you 
remove it may I suggest that you step down as draft editor?

>If you cannot even take the trouble to read what is in front of you,

Get off your high horse, Charles. You've been unable to read the simple 
sentence "justify the mandate" and take appropriate action, so don't play 
this "take the trouble to read" game with me.

Either justify the new mandate or get rid of it. It's simple enough. No 
more of this nonsense about it being just like postmaster almost, or some 
hogwash about security issues. Justify a mandate for a THIRD contact 
address at a specific host or lose it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBmTYb073497 for <[e-mail]>; Mon, 25 Jul 2005 04:48:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PBmTcD073496 for ietf-usefor-skb; Mon, 25 Jul 2005 04:48:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBmSLK073478 for <[e-mail]>; Mon, 25 Jul 2005 04:48:28 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-60.midband.mdip.bt.net ([81.144.64.60]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e4d18b.bddb.9d for [e-mail]; Mon, 25 Jul 2005 12:48:27 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6PBl8526166 for [e-mail]; Mon, 25 Jul 2005 12:47:08 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22101
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1032 USEFOR changes from 1036
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Mon, 25 Jul 2005 11:15:49 GMT
Lines: 60
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>--On fredag, juli 22, 2005 16:39:30 +0000 Charles Lindsey 
><[e-mail]> wrote:

>>      o Whitespace is permitted in Newsgroups header fields, permitting
>>        folding of such header fields. Indeed, all header fields can now
>>        be folded.

>Need to be careful here.. we recommend not folding, which is why I toned it 
>down.

Sure. That was in my "Transitional Arrangements", but if those are to
remain in USEPRO, some "toning down" is in order here. Also, As Frank has
pointed out, you can't fold a Message-Id, though that is only because
there is not convenient folding point inside it.

>>      o An enhanced syntax for the Path header field enables the
>>        injection point of and the route taken by an article to be
>>        determined with certainty.

>With respect, that's simply wrong.
>Even with the new syntax, there are half a dozen ways in which a false 
>injection point can be put into a Path header (old-syntax path, compromised 
>server and fooled server being 3 of them).

Actually no. Even if the Bad Guy preloads the Path with a long string,
including a "POSTED", his injection agent will immediately insert a second
POSTED (and two POSTEDs are an immediate cause for suspicion, although
there are a (very) few legitimate uses for them). And the injection agent
will also provide a new Injection-Info.

Therefore, unless an injecting agent goes rogue, or the Bad Guy manages to
hack his way into it, things are much, much safer that they are at present


>>      o There is a new mandatory Injection-Date header field to
>>        facilitate the rejection of stale articles.

>It's not mandatory....

I have already asked for a ticket to look at that.

>> It also needs to be decided where to put the "Transitional Arangements"
>> currently sitting in USEPRO-04.

>I think all of it, except the "don't fold" stuff, goes to USEPRO,...

OK, I can do that.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBmR6B073475 for <[e-mail]>; Mon, 25 Jul 2005 04:48:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PBmRZT073474 for ietf-usefor-skb; Mon, 25 Jul 2005 04:48:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBmQJW073461 for <[e-mail]>; Mon, 25 Jul 2005 04:48:27 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-60.midband.mdip.bt.net ([81.144.64.60]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e4d189.bddb.9b for [e-mail]; Mon, 25 Jul 2005 12:48:25 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6PBlAZ26180 for [e-mail]; Mon, 25 Jul 2005 12:47:10 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22103
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 25 Jul 2005 11:31:12 GMT
Lines: 19
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>For the trailing [FWS] CRLF it's less clear, Charles admitted
>that it's a bug in 2822 <unstructured>, therefore it's also a
>bug in USEFOR:

Not so. The "Bug" is in 3.2.3 of RFC 2822, but USEFOR contains a different
text to cover that problem, and the USEFOR text has no bug.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBmSH8073486 for <[e-mail]>; Mon, 25 Jul 2005 04:48:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PBmSPX073485 for ietf-usefor-skb; Mon, 25 Jul 2005 04:48:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBmRE1073465 for <[e-mail]>; Mon, 25 Jul 2005 04:48:27 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-60.midband.mdip.bt.net ([81.144.64.60]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42e4d18a.bddb.9c for [e-mail]; Mon, 25 Jul 2005 12:48:26 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6PBl9S26174 for [e-mail]; Mon, 25 Jul 2005 12:47:09 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22102
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 25 Jul 2005 11:27:03 GMT
Lines: 35
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>This is nothing more than a green flag to anyone who wants to cancel 
>anything for any reason. "Established custom" is now "third party cancels 
>are authorized", despite existing standard which says otherwise. Third 
>party is third party. 

"Established custom" is how Usenet works, and it is not our job to change
that. It exists; it works. The text I quoted in is USEAGE, and has no
normative effect.

>Is there a requirement for globally permanently unique or not? 

There is, but there is no *mandated* method of achieving it (there is a
REOMMENDED method).

>If I see that you are using a certain newsreader that creates messages 
>id's of the form <[e-mail]>, and I see that you've just 
>posted <[e-mail]>, nothing breaks if I post with an id of 
><[e-mail]>? Would the owner of example.com feel the same way?

It is well known that generating <msg-id>s that can be predicted by the
Bad Guys is poor practice, for a variety of reasons. I have made a note to
include a warning about this in USEAGE.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBcdcD070070 for <[e-mail]>; Mon, 25 Jul 2005 04:38:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6PBcdGT070069 for ietf-usefor-skb; Mon, 25 Jul 2005 04:38:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6PBccuP070050 for <[e-mail]>; Mon, 25 Jul 2005 04:38:39 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-231.midband.mdip.bt.net ([81.144.77.231]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e4cf3d.17de8.35 for [e-mail]; Mon, 25 Jul 2005 12:38:37 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6PBCFC25082 for [e-mail]; Mon, 25 Jul 2005 12:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22100
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Mon, 25 Jul 2005 10:56:47 GMT
Lines: 69
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Charles Lindsey <[e-mail]> writes:

>> What I do not see is what you actually gain by writing in such a "MUST".

>Most other IETF protocols at this level strongly discourage use of IP
>addresses for a variety of reasons: they carry no immediately
>human-readable information, they are generally far more transient than
>domain names in terms of allocation and controlling authority, they cannot
>be "unwound" easily to determine the originating domain the way that
>hostnames can, they often have no publically available record associated
>with them that points to the actual organization responsible for the
>message (as opposed to some service provider that organization has hired),
>and use of IP addresses encourages and facilitates very unuseful behavior
>such as using private IP addresses in public messages or using transient
>DHCP-assigned IP addresses that will quickly be reassigned to some other
>party.

Yes, I agree with all that. It is a classic case calling for "SHOULD NOT",
as in my currently proposed text.

>I believe all of that is sufficient to warrant strongly discouraging use
>of IP addresses for anything other than diagnostic information.  I'm
>ambivalent about SHOULD vs. MUST.


>> But it seems that some sites are currently including the source IP
>> address as a diagnostic even when no mismatch has been detected. ...

>This reduces to the case where no matching information is stored and all
>sites are mismatches, which conveniently is generally exactly what's going
>on with the sites that always embed an IP address, so the only affect of
>the change that you propose would be to allow one to omit the "MISMATCH"
>entry.  I guess I don't really care.

I don't quite follow there. For sure we don't want sites putting in
MISMATCH unless they have actually checked and found something fishy. If
they put the sending IP address in without MISMATCH, then they are saying
"This is where we got it from; compare it with the next thing in the Path
yourself if you are bothered". Just so long as they don't follow it with a
"!!" if they have not actually done the check.

Anyway, if others agree, I can write some wording to indicate that such
"diagnostic" usages are in order, and an IP used here does not violate the
SHOULD (or even MUST) NOT discussed above.

>> Also, the present wording allows just one entry per relaying agent (or
>> two with MISMATCH), and yet some sites (e.g. nntpserver.com and demon)
>> want to put in extra ........

>There's no reason to even discourage it, as such a site would become
>compliant anyway just by adding another internal machine that the traffic
>bounces through.  So long as they follow the other rules for Path entries,
>I don't see any reason why they shouldn't be able to add as many internal
>entries as they want.

OK, I can easily write that in if people are happy.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6NC2Dik083130 for <[e-mail]>; Sat, 23 Jul 2005 05:02:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6NC2Drk083129 for ietf-usefor-skb; Sat, 23 Jul 2005 05:02:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6NC2BDA083111 for <[e-mail]>; Sat, 23 Jul 2005 05:02:12 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DwIhV-0004u6-BL for [e-mail]; Sat, 23 Jul 2005 14:01:53 +0200
Received: from c-180-160-3.hh.dial.de.ignite.net ([62.180.160.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 23 Jul 2005 14:01:53 +0200
Received: from nobody by c-180-160-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 23 Jul 2005 14:01:53 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1032 USEFOR changes from 1036
Date:  Sat, 23 Jul 2005 14:00:05 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-160-3.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

>> Indeed, all header fields can now be folded.

> Need to be careful here.. we recommend not folding,
> which is why I toned it down.

The Message-ID: header field cannot be folded, it has
only two of these misleading [FWS] in the ABNF.  Dito
Supersedes (misleading [FWS] instead of *WSP), and the
deprecated Lines:

I've tested it only for the Message-ID:    Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6NBMs7T069097 for <[e-mail]>; Sat, 23 Jul 2005 04:22:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6NBMssh069096 for ietf-usefor-skb; Sat, 23 Jul 2005 04:22:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6NBMrGt069061 for <[e-mail]>; Sat, 23 Jul 2005 04:22:53 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3353461B49; Sat, 23 Jul 2005 13:22:52 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17105-07; Sat, 23 Jul 2005 13:22:46 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6E4B61AFB; Sat, 23 Jul 2005 13:22:45 +0200 (CEST)
Date: Sat, 23 Jul 2005 13:22:45 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1032 USEFOR changes from 1036
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On fredag, juli 22, 2005 16:39:30 +0000 Charles Lindsey 
<[e-mail]> wrote:

>
> In <[e-mail]> Harald Tveit
> Alvestrand <[e-mail]> writes:
>
>> I've gotten some off-list comments on the text I cribbed from USEPRO.
>
> Eh? There has been no prior mention on this list of your "cribbed text". I
> see now that it is based on USEPRO-03, but there is a more up-to-date
> version, reflecting recent changes, in USEPRO-04.

You're right.... the message I sent out on June 9 didn't have the text I 
suggested cribbing; I thought it had.

I've asked Ken to keep track of the "currently suggested text" for this 
section.

> Here it is in full:
>
>      o The [RFC 2822] conventions for parenthesis-enclosed <comment>s in
>        header fields are supported in all newly defined header fields
>        and in header fields inherited from [RFC 2822].  They are,
>        however, still disallowed for performance and/or compatibility
>        reasons in the Message-ID, Newsgroups, Path, Followup-To,
>        Control, Supersedes, Distribution, Xref and Lines header fields.
>      o Whitespace is permitted in Newsgroups header fields, permitting
>        folding of such header fields. Indeed, all header fields can now
>        be folded.

Need to be careful here.. we recommend not folding, which is why I toned it 
down.

>      o An enhanced syntax for the Path header field enables the
>        injection point of and the route taken by an article to be
>        determined with certainty.

With respect, that's simply wrong.
Even with the new syntax, there are half a dozen ways in which a false 
injection point can be put into a Path header (old-syntax path, compromised 
server and fooled server being 3 of them).

>      o MIME is recognized as an integral part of Netnews.
>      o There is a new Control message 'mvgroup' to facilitate moving a
>        group to a different place (name) in a hierarchy.

USEPRO.

>      o There is a new mandatory Injection-Date header field to
>        facilitate the rejection of stale articles.

It's not mandatory....

>      o There are new optional header fields defined, Archive,
>        Injection-Info and User-Agent, leading to increased
>        functionality.
>      o Certain header fields and Control messages (F-3.3 and Appendix
>        A.3) have been made obsolete.

Control messages go to USEPRO, but header fields go to USEFOR.
I think we should name them.

>      o Distributions are expected to be checked at the receiving end, as
>        well as the sending end, of a relaying link.

USEPRO.

>      o There are numerous other small changes, clarifications and
>        enhancements.
>
> Clearly, if this is to be moved to USEFOR, the points about the 'mvgroup'
> control message, Distributions and obsolete control messages would remain
> in USEPRO. I am slightly surprised that you have removed any mention of
> obsolete header fields.
>
> Apart from that, it is merely a question of how much to say about each
> matter. I see that others have asked for a little more, and have
> identified some possible omissions. There is clearly room for some
> mix'n'matching of the various suggestions.
>
>> Currently, we may suggest this text:
>
>> o The [RFC 2822] conventions for parenthesis-enclosed <comment>s
>> in headers are supported.
>> o Whitespace is permitted in Newsgroups headers
>> o The syntax of the Path header has been reworked to add multiple
>> forms of information
>> o MIME is recognized as an integral part of Netnews.
>> o There is a new Injection-Date header to facilitate
>> the rejection of stale articles.
>> o There are several new optional headers defined, notably
>> Archive, Injection-Info, and User-Agent, leading to increased
>> functionality.
>> o There are numerous other small changes, clarifications and
>> enhancements
>
> It also needs to be decided where to put the "Transitional Arangements"
> currently sitting in USEPRO-04.

I think all of it, except the "don't fold" stuff, goes to USEPRO, and the 
"don't fold" stuff is already in the main body of USEFOR. Do we need to 
repeat it here?

>
> --
> Charles H. Lindsey ---------At Home, doing my own
> thing------------------------ Tel: [phone] Fax: [phone]
> Web: http://www.cs.man.ac.uk/~chl Email: [e-mail]      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
>
>






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IRFk007225 for <[e-mail]>; Fri, 22 Jul 2005 19:18:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6N2IRp0007224 for ietf-usefor-skb; Fri, 22 Jul 2005 19:18:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IQjJ007215 for <[e-mail]>; Fri, 22 Jul 2005 19:18:27 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-230.midband.mdip.bt.net ([81.144.71.230]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e1a8f1.a9f6.a for [e-mail]; Sat, 23 Jul 2005 03:18:25 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6N2CBa26690 for [e-mail]; Sat, 23 Jul 2005 03:12:11 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22086
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1032 USEFOR changes from 1036
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 22 Jul 2005 16:39:30 GMT
Lines: 74
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>I've gotten some off-list comments on the text I cribbed from USEPRO.

Eh? There has been no prior mention on this list of your "cribbed text". I
see now that it is based on USEPRO-03, but there is a more up-to-date
version, reflecting recent changes, in USEPRO-04. Here it is in full:

     o The [RFC 2822] conventions for parenthesis-enclosed <comment>s in
       header fields are supported in all newly defined header fields
       and in header fields inherited from [RFC 2822].  They are,
       however, still disallowed for performance and/or compatibility
       reasons in the Message-ID, Newsgroups, Path, Followup-To,
       Control, Supersedes, Distribution, Xref and Lines header fields.
     o Whitespace is permitted in Newsgroups header fields, permitting
       folding of such header fields. Indeed, all header fields can now
       be folded.
     o An enhanced syntax for the Path header field enables the
       injection point of and the route taken by an article to be
       determined with certainty.
     o MIME is recognized as an integral part of Netnews.
     o There is a new Control message 'mvgroup' to facilitate moving a
       group to a different place (name) in a hierarchy.
     o There is a new mandatory Injection-Date header field to
       facilitate the rejection of stale articles.
     o There are new optional header fields defined, Archive,
       Injection-Info and User-Agent, leading to increased
       functionality.
     o Certain header fields and Control messages (F-3.3 and Appendix
       A.3) have been made obsolete.
     o Distributions are expected to be checked at the receiving end, as
       well as the sending end, of a relaying link.
     o There are numerous other small changes, clarifications and
       enhancements.

Clearly, if this is to be moved to USEFOR, the points about the 'mvgroup'
control message, Distributions and obsolete control messages would remain
in USEPRO. I am slightly surprised that you have removed any mention of
obsolete header fields.

Apart from that, it is merely a question of how much to say about each
matter. I see that others have asked for a little more, and have
identified some possible omissions. There is clearly room for some
mix'n'matching of the various suggestions.

>Currently, we may suggest this text:

>o The [RFC 2822] conventions for parenthesis-enclosed <comment>s
>in headers are supported.
> o Whitespace is permitted in Newsgroups headers
> o The syntax of the Path header has been reworked to add multiple
>forms of information
> o MIME is recognized as an integral part of Netnews.
> o There is a new Injection-Date header to facilitate
>the rejection of stale articles.
> o There are several new optional headers defined, notably
> Archive, Injection-Info, and User-Agent, leading to increased
> functionality.
> o There are numerous other small changes, clarifications and
> enhancements

It also needs to be decided where to put the "Transitional Arangements"
currently sitting in USEPRO-04.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IQVj007217 for <[e-mail]>; Fri, 22 Jul 2005 19:18:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6N2IQCZ007216 for ietf-usefor-skb; Fri, 22 Jul 2005 19:18:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IP16007199 for <[e-mail]>; Fri, 22 Jul 2005 19:18:25 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-230.midband.mdip.bt.net ([81.144.71.230]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e1a8f0.a9f6.9 for [e-mail]; Sat, 23 Jul 2005 03:18:24 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6N2CCY26700 for [e-mail]; Sat, 23 Jul 2005 03:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22088
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1082 USEFOR 3.2.9 Need more text about Approved header field seman
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Fri, 22 Jul 2005 17:02:14 GMT
Lines: 48
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>> (the present text is a bit bare)

>It has two MUST, what's the complete text for 3.2.9 after your
>modification ?  The proposed "Note" is fine, but you're talking
>about _two_ modifications, what's the second addition ?

My first change would augment the 1st paragraph with an extra sentence,
something like:

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 [USEPRO].

The rest is the same until you get to the "Note".

>Or if the "Note" is the second addition, what's the first ?

The "Note" is the second.


>Depends.  I feel entitled to approve my own Cancel messages
>affecting all articles claiming to be "from" me, no matter
>what the status of the groups might be.  But that would be
>of course my own address, and not a forged moderator address.

There is no requirement in USEPRO for an Approved header in a cancel
message, though it is mentioned as a possibility.

USEAGE goes further and says you MUST include it for 3rd party cancels,
and may for 2nd party cancels too.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IPOE007198 for <[e-mail]>; Fri, 22 Jul 2005 19:18:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6N2IPoV007197 for ietf-usefor-skb; Fri, 22 Jul 2005 19:18:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IOao007189 for <[e-mail]>; Fri, 22 Jul 2005 19:18:24 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-230.midband.mdip.bt.net ([81.144.71.230]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e1a8ef.a9f6.7 for [e-mail]; Sat, 23 Jul 2005 03:18:23 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6N2CAa26682 for [e-mail]; Sat, 23 Jul 2005 03:12:10 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22085
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1003 Message-ID issues - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 22 Jul 2005 16:13:13 GMT
Lines: 33
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>In usefor-05, the proposed text was inserted.
>However, there are some outstanding niggles:

>- Some unhappiness with the recommendation on use of domain-literal.
>Current text:

>   If domain literals are used, the syntax found in Section 4.1.3 of
>   [RFC2821] is RECOMMENDED.

Yes, they expect you to say "[IPv6:aaaa:bbbb:cccc:dddd......]"
which is not how IPv6 addresses are represented elsewhere, and it was
reported that even the RFC 2821 people are having 2nd thoughts, and that
implementations do not seem to be implementing it.

So I am unhappy.

>- A question on whether or not the "don't use other people's namespace" 
>belongs here or not. There is current text talking about generation:

I have proposed USEAGE text for this under #1083.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IPVp007208 for <[e-mail]>; Fri, 22 Jul 2005 19:18:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6N2IPHI007207 for ietf-usefor-skb; Fri, 22 Jul 2005 19:18:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N2IOac007191 for <[e-mail]>; Fri, 22 Jul 2005 19:18:25 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-230.midband.mdip.bt.net ([81.144.71.230]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e1a8ef.a9f6.8 for [e-mail]; Sat, 23 Jul 2005 03:18:23 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6N2CCb26696 for [e-mail]; Sat, 23 Jul 2005 03:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22087
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 22 Jul 2005 16:47:32 GMT
Lines: 31
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>Your MUST regarding an abuse@ address at every FQDN that appears in a path
>is for NEWS, and we already require not just one but TWO addresses for
>news administrators to deal with news configuration problems. 
>Interoperability issues for NEWS are solved by using the USENET@ and 
>NEWS@ addresses (although I cannot see why two are required when one 
>would do.) 

Sigh!

I have NEVER EVER proposed any "MUST regarding an abuse@ address at every
FQDN that appears in a path".

If you cannot even take the trouble to read what is in front of you, then
there is little point in continuing this discussion. This WG has more
important things to do that arguing over your strawmen.

May I suggest that you read USEPRO-04, and then come back here with such
problems as you may have with what is proposed there.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N1ftlT003782 for <[e-mail]>; Fri, 22 Jul 2005 18:41:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6N1ftUO003781 for ietf-usefor-skb; Fri, 22 Jul 2005 18:41:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N1fqD3003774 for <[e-mail]>; Fri, 22 Jul 2005 18:41:53 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dw91P-00065d-1e for [e-mail]; Sat, 23 Jul 2005 03:41:47 +0200
Received: from c-134-89-125.hh.dial.de.ignite.net ([62.134.89.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 23 Jul 2005 03:41:47 +0200
Received: from nobody by c-134-89-125.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 23 Jul 2005 03:41:47 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: ABNF remarks hidden in message "Admin: I'm back....."
Date:  Sat, 23 Jul 2005 03:41:23 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 104
Message-ID:  <[e-mail]>
References:  <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-134-89-125.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:
 
>> Everybody who knows the 2822 <orig-date> will immediately
>> see the added SP.
 
> But it doesn't say *why* there is an added SP

Maybe propose some text for the general MUST about this issue.
I've just tested the very last chance:  ":" SP HT CRLF SP ...
It was rejected, "missing Message-ID". 

What we have describes the situation, only the [FWS] is wrong,
it should be *WSP for all instances of <name> ":" SP [FWS] ...

For the trailing [FWS] CRLF it's less clear, Charles admitted
that it's a bug in 2822 <unstructured>, therefore it's also a
bug in USEFOR:

~~~ old ~~~
    unstructured    =  1*( [FWS] utext ) [FWS]
~~~ new ~~~
    unstructured    =  *WSP utext *( [FWS] utext ) *WSP
~~~ end ~~~

The "lost" obs-FWS doesn't affect us, because it's not allowed,
or do I miss something here ?

 [orig-date]
> yet you seem to be happy with _subtle_ modifications to the
> same field w.r.t. zone abbreviations and MUST means MAY but
> MAY means MUST

Now "happy" isn't what I'd say, it was a compromise proposed
by Harald after long disussions, refined several times.

We had the restricted syntax allowing GMT / UT, now we have
only GMT without the syntax.  I proposed to add a deprecated
GMT example, just to be sure that all readers get the drift,
see <http://mid.gmane.org/[e-mail]>.

> Inconsistency detected.

Not really.

 [back to <unstructured>]
> We disagree on your narrow interpretation

Apparently.  Your broad interpretation won't work for similar
cases like <word> and <atom> as discussed in...

<http://mid.gmane.org/[e-mail]>

...I doubt that you'd really want all prose rules for <word>
automagically affect any <atom> outside of <word>.  

>> The rationale for the <msg-id> modifications is quite
>> complete.
 
> No, there is no rationale for excluding NO-WS-CTLs.  We can
> guess that the reason is "Frank doesn't like them"

Good guess, you have to add some RfCs from 1036 up to NNTPbis,
common practice, and my tests with ESC.  In my last count we
are now at 3 : 3 for the <id-domain> vs. <id-right> versions.

You're a special case, you want the RFC 2822 <msg-id> "as is",
ignoring all boring facts like reality or the USEFOR charter.

>> The mandatory SP conforms to the message/rfc822 format, the
>> UA can always generate it.
 
> True but irrelevant.  A UA generating a message cannot
> readily determine where that message will go

Yes, that's why it always generates ": " with SP, that works.

> in principle altering messages after generation causes
> problems (e.g. invalidates security mechanisms).

ACK, therefore we stick to a mandatory SP instead of trusting
that injection agents could "fix" this if it's missing.  It's
bad enough for mail2news gateways, let's not make it worse.

> Your tests seem to indicate that at least some versions of
> one implementation cope fine with no SP

IBTD, it's never "fine" if messages are modified in transit.
You could say that an injection agent is entitled to do this,
like an MSA. 

But don't ask me how this is supposed to work with stuff like
MASS / DKIM / PGP / S/MIME - "fixed" articles can leave news,
e.g. this article posted on GMaNe should reach you as mail.

> up to those who wish to impose the additional SP requirement
> to specify precisely where the serious issues warranting
> imperative keywords arise

As long as injection agents feel obliged to "fix" my articles
the serious issues are clear.  I'm not sure why they do this,
but I trust that it's not for fun (or for your fetish idea ;-)

                          Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N0AZsb097083 for <[e-mail]>; Fri, 22 Jul 2005 17:10:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6N0AZ2h097082 for ietf-usefor-skb; Fri, 22 Jul 2005 17:10:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6N0AYVV097076 for <[e-mail]>; Fri, 22 Jul 2005 17:10:34 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dw7b1-0006wl-Dh for [e-mail]; Sat, 23 Jul 2005 02:10:27 +0200
Received: from c-134-89-125.hh.dial.de.ignite.net ([62.134.89.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 23 Jul 2005 02:10:27 +0200
Received: from nobody by c-134-89-125.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 23 Jul 2005 02:10:27 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: NEW: USEFOR -05 3.1 Injection-Date was mandatory
Date:  Sat, 23 Jul 2005 02:09:26 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 7
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-134-89-125.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 
> This header field was therefore made "MUST generate"

Okay, let's say that my proposal to join it with Injection-Info
is a bad idea.  MUST => mandatory makes sense.  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MN7LQn092902 for <[e-mail]>; Fri, 22 Jul 2005 16:07:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MN7LTA092901 for ietf-usefor-skb; Fri, 22 Jul 2005 16:07:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MN7ItZ092890 for <[e-mail]>; Fri, 22 Jul 2005 16:07:20 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6MN7CWP082943 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 22 Jul 2005 16:07:13 -0700 (PDT)
Date: Fri, 22 Jul 2005 16:07:12 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

> Rather to everyone's surprise, Usenet as a whole hailed him as a hero.

Your memory of this differs from mine. 

   3. Other entities MAY be entitled to issue a cancel message for that
      article, in circumstances where established policy for any
      hierarchy or group in the Newsgroups header, or established custom
      within Usenet, so allows (such policies and customs are not
      defined by this document). ........

This is nothing more than a green flag to anyone who wants to cancel 
anything for any reason. "Established custom" is now "third party cancels 
are authorized", despite existing standard which says otherwise. Third 
party is third party. 

We should NOT authorize willy-nilly cancellation of articles by anyone who 
wants to at any time. We SHOULD limit cancellations to the poster and the 
admin of the site through which he posted. The latter can cancel spam just 
as easily as any other third party, and is already in a position of 
authority over the poster. 

>We are talking here of people who construct <msg-id>s which contain the
>names of other people's domains in their <id-right>. Assuming that they
>have taken care to choose an <id-left> such that the <msg-id> as a whole
>is still globally unique, they are not in breach of USEFOR; nothing will
>break as a result, hence they are not in breach of USEPRO.

Is there a requirement for globally permanently unique or not? 

If I see that you are using a certain newsreader that creates messages 
id's of the form <[e-mail]>, and I see that you've just 
posted <[e-mail]>, nothing breaks if I post with an id of 
<[e-mail]>? Would the owner of example.com feel the same way?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MLcrWx086180 for <[e-mail]>; Fri, 22 Jul 2005 14:38:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MLcrdQ086179 for ietf-usefor-skb; Fri, 22 Jul 2005 14:38:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MLcpot086169 for <[e-mail]>; Fri, 22 Jul 2005 14:38:51 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dw5Cs-0008Aw-Kq for [e-mail]; Fri, 22 Jul 2005 23:37:22 +0200
Received: from c-134-89-125.hh.dial.de.ignite.net ([62.134.89.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 22 Jul 2005 23:37:22 +0200
Received: from nobody by c-134-89-125.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 22 Jul 2005 23:37:22 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
Date:  Fri, 22 Jul 2005 23:31:25 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-134-89-125.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> It of course depends on the actual existence of some
> widely-deployed "foo", rather than SP-after-colon being
> somebody's personal fetish.  After Frank's tests, it's not
> clear that there is a "foo".

My two tests found two "smart foo", they added the fetish SP
on their own behalf.  A "stupid foo" could reject the article.

With header signatures it's far from clear what's "smart" and
what's "stupid", but we're still firmly at square one, the SP
is a required fetish.

Even if all injection agents of the world are "smart" there's
still a mandatory SP after the colon.  I've now also tested
the last chance for a major step forward towards RfC 2822:

<news://news.spamcop.net/[e-mail]>

That was with HT instead of SP.  No luck, the "smart" agent
replaced it by SP.  We're stuck with it, unfortunately.

I'd really love to meet halfway with RfC 2822, replace [FWS]
by MWS ("mandatory white space") and MWS = 1*WSP / obs-FWS

But that's of course only a dream, the mail-extremists (e.g.
you, but you'd say "message-fan") want their [FWS], and the
news-extremists love their fetish SP.

                           Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MLG5EL084692 for <[e-mail]>; Fri, 22 Jul 2005 14:16:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MLG5nk084691 for ietf-usefor-skb; Fri, 22 Jul 2005 14:16:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MLG46K084684 for <[e-mail]>; Fri, 22 Jul 2005 14:16:05 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dw4kS-0007D9-Ew for [e-mail]; Fri, 22 Jul 2005 23:08:00 +0200
Received: from c-134-89-125.hh.dial.de.ignite.net ([62.134.89.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 22 Jul 2005 23:08:00 +0200
Received: from nobody by c-134-89-125.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 22 Jul 2005 23:08:00 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1048 e.a.
Date:  Fri, 22 Jul 2005 22:57:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-134-89-125.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery wrote:

>> Having it as a "posting-date" parameter of Injection-Info
>> was discussed by the WG, and rejected

That's clear.

> The intention is for every news server to parse this field
> instead of Date.  Given that, it should be easy to parse.
> MIME-style parameters are not.

Dito, same reason.  How about this:

~~~ old ~~~
injection-date = "Injection-Date:" SP date-time CRLF

injection-info = "Injection-Info:" SP [CFWS] path-identity
                 *( [CFWS] ";" [CFWS] inj-info-param )
                 [CFWS] CRLF
~~~ new ~~~
injection-info = "Injection-Info:" SP *WSP path-identity
                 1*WSP datetime
                 *( ";" [CFWS] inj-info-param [CFWS] ) CRLF
~~~ end ~~~

The added <date-time> ends with [CFWS], therefore I could join
the two [CFWS] before semicolon or CRLF into one [CFWS] behind
<inj-info-param>.

And I got rid of the first [CFWS] before the <path-identity>.

It won't work with Charles' concept of a "reinjection" keeping
the old <injection-date>, if that's critical forget it, please.

                          Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MILrkl068758 for <[e-mail]>; Fri, 22 Jul 2005 11:21:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MILrS8068757 for ietf-usefor-skb; Fri, 22 Jul 2005 11:21:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MILr4h068751 for <[e-mail]>; Fri, 22 Jul 2005 11:21:53 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id C5B6A29930; Fri, 22 Jul 2005 14:21:51 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6MILppg003377(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 22 Jul 2005 14:21:51 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6MILoTk003376(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 22 Jul 2005 14:21:50 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
Date: Fri, 22 Jul 2005 14:21:47 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri July 22 2005 12:00, Charles Lindsey wrote:

> It ain't broke. Don't fix it.

And then went on to say:
 
> More specifically, the syntax of Netnews is different from that of Email,
> even though large parts of it are in common. We should not disguise that
> fact.

Disguising the differences is precisely what using an established ABNF
rule name with a different definition does.  It is broken, and needs to
be fixed.

> There are rules in Email that are absent from Netnews (most of the 
> obs-syntax). There are rules in Netnews that are absent from Email. And
> there are rules that are plain different. But we are still a strict subset
> of Email, and that needs to be stated clearly.

We're discussing the Internet Message Format, not "Email".  SMTP as a
mail-specific protocol is nearly irrelevant to our work, whereas the
Internet Message Format is a normative reference and is relevant because
messages (news, mail, and other) are handled by various protocols (e.g.
IMAP) which are in widespread use in Usenet.

My preference remains to use implementation notes which clearly explain
*how* things differ, *why* there is a difference, *where* and *when* the
difference matters, and *what* might be done, by *whom*, to minimize the
differences.

RFCs 850 and 1036 (section 2 of both RFCs) very clearly chose to use the
Internet Message Format, replacing an older format, for reasons clearly
explained in those RFCs: to fit in with existing tools.  Each difference
reduces the applicability of existing tools.  The long term goal should
be convergence with the long-standing, widely-used Internet Message
Format which was adopted for use by RFC 850.  Reaching that goal is
facilitated by clearly explaining the how, why, where, when, and what for
each difference, and is impeded by disguising the differences by violating
the methodology which we have stated that we use (usefor sect. 1.6).

A redefinition -- regardless of the name -- is unsatisfactory.  Tools and
protocols deal with messages, and a From field in a message needs to have
precisely one definition.  It's OK to add restrictions on content where
necessary, but having conflicting definitions in ABNF is a problem.
Given a message, it's one thing for a tool or protocol to observe "this
is a From field meeting *the* syntax of RFC 2822, and by the way the field
body of this instance happens to begin with SP" and quite a different matter
to say to IMAP (e.g.) implementers "here are two conflicting definitions of
*the* syntax for a From field; have a nice day".

A redefinition of "from" is the latter and is a problem.  It also has the
unfortunate characteristic of not clearly indicating whether or not the
redefinition is for generation or for parsing or for both; specifically it
is unclear in the redefinition of "from" whether or not parsers are required
to enforce the SP presence, whether they're permitted to reformat hard
drives, etc. if it's absent, etc.  Defining something called "news-gen-from"
that specifies a news-specific generation syntax and something called
"news-parse-from" that specifies a news-specific parse syntax might be one
viable approach, but:
o it does not remove the need for a clear exposition of why, where, when,
  and what
o it requires careful scrutiny to ensure full compatibility
o it is going to require rework when the 2822 successor is published with
  grammar correcting some errors and eliminating [CFWS] [CFWS] ambiguities
  etc.
o it requires additional work for implementers to figure out from ABNF
  precisely what differs and how to deal with the differences
o it's going to require some text to explain how the -gen- and -parse-
  rules are used, and that text is likely to take up as much room as
  an implementation note which would obviate not only that explanatory
  text but dozens of ABNF lines.

It's much simpler, clearer, and overall more concise to say something like:

Implementation note:
  Although there is no requirement regarding a field body first character
  value in RFCs 822 or 2822, widely-deployed software "foo" crashes when
  a field body begins with a character other than SP.  Therefore, for
  backward compatibility with that deployed base, generators of messages
  conforming to this specification MUST begin all field bodies with SP.
  In the interest of compatibility with the Internet Message Format on
  which this specification is based, deployed implementations of foo
  SHOULD be upgraded to accept any legal field bodies permitted by RFC
  2822.

That:
a. explains how, why, where, when, and what, as well as who needs to take
   action
b. avoids a conflicting definition
c. obviates a rewrite when 2822 is updated (except for updating the RFC
   number).

It of course depends on the actual existence of some widely-deployed "foo",
rather than SP-after-colon being somebody's personal fetish.  After Frank's
tests, it's not clear that there is a "foo".



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGSDi4057702 for <[e-mail]>; Fri, 22 Jul 2005 09:28:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MGSDAE057701 for ietf-usefor-skb; Fri, 22 Jul 2005 09:28:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGSDba057690 for <[e-mail]>; Fri, 22 Jul 2005 09:28:13 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6MGSBpX028213 for <[e-mail]>; Fri, 22 Jul 2005 09:28:12 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id B7BE5E791A; Fri, 22 Jul 2005 09:28:11 -0700 (PDT)
To: [e-mail]
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Fri, 22 Jul 2005 15:52:32 GMT")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Fri, 22 Jul 2005 09:28:11 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:

> What I do not see is what you actually gain by writing in such a "MUST".

Most other IETF protocols at this level strongly discourage use of IP
addresses for a variety of reasons: they carry no immediately
human-readable information, they are generally far more transient than
domain names in terms of allocation and controlling authority, they cannot
be "unwound" easily to determine the originating domain the way that
hostnames can, they often have no publically available record associated
with them that points to the actual organization responsible for the
message (as opposed to some service provider that organization has hired),
and use of IP addresses encourages and facilitates very unuseful behavior
such as using private IP addresses in public messages or using transient
DHCP-assigned IP addresses that will quickly be reassigned to some other
party.

I believe all of that is sufficient to warrant strongly discouraging use
of IP addresses for anything other than diagnostic information.  I'm
ambivalent about SHOULD vs. MUST.

> Of more immediate concern, however, is what is meant by "diagnostic
> information". As USEPRO is currently written, the only diagnostic
> information that may be written is when you have detected that the (IP
> address of) the source of the article was different from what the source
> site claimed to be its <path-identity>. And in that case you are
> supposed to put the true IP address (or equivalent domain-name) followed
> by "MISMATCH".

> But it seems that some sites are currently including the source IP
> address as a diagnostic even when no mismatch has been detected. I think
> we should probably reword it to indicate that is allowed (though maybe
> with some discouragement on account of creating unnecessary clutter in
> the Path).

This reduces to the case where no matching information is stored and all
sites are mismatches, which conveniently is generally exactly what's going
on with the sites that always embed an IP address, so the only affect of
the change that you propose would be to allow one to omit the "MISMATCH"
entry.  I guess I don't really care.

> Also, the present wording allows just one entry per relaying agent (or
> two with MISMATCH), and yet some sites (e.g. nntpserver.com and demon)
> want to put in extra identification entries for various plausible
> reasons. We probably ought to permit that too (perhaps with
> discouragement).

There's no reason to even discourage it, as such a site would become
compliant anyway just by adding another internal machine that the traffic
bounces through.  So long as they follow the other rules for Path entries,
I don't see any reason why they shouldn't be able to add as many internal
entries as they want.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGKnmN056769 for <[e-mail]>; Fri, 22 Jul 2005 09:20:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MGKncj056768 for ietf-usefor-skb; Fri, 22 Jul 2005 09:20:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGKmpn056760 for <[e-mail]>; Fri, 22 Jul 2005 09:20:48 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6MGKlOU028886 for <[e-mail]>; Fri, 22 Jul 2005 09:20:48 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id C005EE7CB6; Fri, 22 Jul 2005 09:20:47 -0700 (PDT)
To: [e-mail]
Subject: Re: #1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
In-Reply-To: <[e-mail]> (Harald Tveit Alvestrand's message of "Thu, 21 Jul 2005 14:38:29 +0200")
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Fri, 22 Jul 2005 09:20:47 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand <[e-mail]> writes:

> Personal comment: I don't find the issue very important, since I don't
> find the redefinitions confusing. Your mileage may differ.

> From a formalistic standpoint (and making the ABNF easier to check as an
> extension to the 2822 grammar), I think there's something to be said for
> an intro saying something like:

>   This document defines a number of ABNF productions that are named
>   "news-" and the name of an RFC 2822 production (for instance
>   "news-from"). This is intended to document a restriction in the
>   Netnews article format compared to the RFC 2822 message format; a
>   valid Netnews article will be a valid RFC 2822 message, but will also
>   satisfy the ABNF specified in the "news-" rules.

> And then adding "news" in front of the rules, of course.

> Another alternative is just leaving them as-is.

> Thoughts?

I'm okay with leaving them as-is, since like you, I don't find them
confusing, but there's certainly some appeal in the above.  I think it's a
slightly better option, although I don't know whether it's worth the
additional work.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGJAkk056604 for <[e-mail]>; Fri, 22 Jul 2005 09:19:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MGJArc056603 for ietf-usefor-skb; Fri, 22 Jul 2005 09:19:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGJ9Uw056588 for <[e-mail]>; Fri, 22 Jul 2005 09:19:09 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6MGJ8Gm028427 for <[e-mail]>; Fri, 22 Jul 2005 09:19:08 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 7E41DE791A; Fri, 22 Jul 2005 09:19:08 -0700 (PDT)
To: [e-mail]
Subject: Re: #1048 e.a.
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Fri, 22 Jul 2005 15:16:26 GMT")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Fri, 22 Jul 2005 09:19:08 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:
> Frank Ellermann <[e-mail]> writes:

>> I'd still like to be convinced why we must split the info in
>> two header fields, "because the Injection-Date is no variant
>> header" is only a formal argument, I don't get the idea behind
>> this decision.

> Having it as a "posting-date" parameter of Injection-Info was discussed
> by the WG, and rejected (I don't recall the precise reason, but it is
> all in the archives).

The intention is for every news server to parse this field instead of
Date.  Given that, it should be easy to parse.  MIME-style parameters are
not.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGE59k056141 for <[e-mail]>; Fri, 22 Jul 2005 09:14:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MGE5Cj056139 for ietf-usefor-skb; Fri, 22 Jul 2005 09:14:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGE42i056133 for <[e-mail]>; Fri, 22 Jul 2005 09:14:04 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-217.midband.mdip.bt.net ([81.144.77.217]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e11b4a.50cb.263 for [e-mail]; Fri, 22 Jul 2005 17:14:02 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6MGCGs20670 for [e-mail]; Fri, 22 Jul 2005 17:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22082
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Fri, 22 Jul 2005 15:52:32 GMT
Lines: 64
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>On reviewing, I have found you arguing that systems should be allowed to so 
>identify themselves, citing 4% of messages that have IP addresses in the 
>path. But your analysis of July 5 seemed to indicate that in all cases 
>where it was possible to guess at the purpose, the IP address was injected 
>in the path as "diagnostic information", not in a way that would make you 
>think it was intended to manage propagation.

>I think there's general agreement that IPv4 addresses MUST be allowed to 
>occur in the Path: header (because of current practice and useful 
>diagnostic ability), and more-or-less agreement that IPv6 addresses should 
>be allowed because of being "address format neutral", but I don't see any 
>support in the group for letting people use it as identifiers.

Yes, I think it is agreed that both IPv4 and IPv6 addresses will be there.
The issue is whether they MUST be reserved for "diagnostic information"
only.

What I do not see is what you actually gain by writing in such a "MUST".
It does not make the "dead:beef" problem go away (not that I think that is
a serious problem anyway). There is no change in interoperability, and no
harm that I can see (provided any IP address you use is a 'public' one for
a machine that you own). The only difference it would make, that I can
see, is if you said to your upstream "I shall use my IP address
123.123.123.123 in my Path; please do not send me articles with that
already in the Path", then you upstream should reply "Sorry! The standard
does not allow me to do that". Indeed, I do not think a single line of
code in any implementation would be changed.

There may be good social/political arguments for the retriction, but those
are more usually addressed by "SHOULD" wording than by "MUST".

Of more immediate concern, however, is what is meant by "diagnostic
information". As USEPRO is currently written, the only diagnostic
information that may be written is when you have detected that the (IP
address of) the source of the article was different from what the source
site claimed to be its <path-identity>. And in that case you are supposed
to put the true IP address (or equivalent domain-name) followed by
"MISMATCH".

But it seems that some sites are currently including the source IP address
as a diagnostic even when no mismatch has been detected. I think we should
probably reword it to indicate that is allowed (though maybe with some
discouragement on account of creating unnecessary clutter in the Path).

Also, the present wording allows just one entry per relaying agent (or two
with MISMATCH), and yet some sites (e.g. nntpserver.com and demon) want to
put in extra identification entries for various plausible reasons. We
probably ought to permit that too (perhaps with discouragement).

If people are agreed we need to allow such things, then I can propose
some wording. Probably needs a new ticket.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGE3bu056119 for <[e-mail]>; Fri, 22 Jul 2005 09:14:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MGE3Y4056118 for ietf-usefor-skb; Fri, 22 Jul 2005 09:14:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGE1XF056102 for <[e-mail]>; Fri, 22 Jul 2005 09:14:02 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-217.midband.mdip.bt.net ([81.144.77.217]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e11b48.50cb.261 for [e-mail]; Fri, 22 Jul 2005 17:14:00 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6MGCHQ20674 for [e-mail]; Fri, 22 Jul 2005 17:12:17 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22083
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 22 Jul 2005 16:00:18 GMT
Lines: 37
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>  This document defines a number of ABNF productions that are named
>  "news-" and the name of an RFC 2822 production (for instance
>  "news-from"). This is intended to document a restriction in the Netnews
>  article format compared to the RFC 2822 message format; a valid Netnews
>  article will be a valid RFC 2822 message, but will also satisfy the
>  ABNF specified in the "news-" rules.

>And then adding "news" in front of the rules, of course.

>Another alternative is just leaving them as-is.

>Thoughts?

It ain't broke. Don't fix it.

More specifically, the syntax of Netnews is different from that of Email,
even though large parts of it are in common. We should not disguise that
fact. There are rules in Email that are absent from Netnews (most of the
obs-syntax). There are rules in Netnews that are absent from Email. And
there are rules that are plain different. But we are still a strict subset
of Email, and that needs to be stated clearly.

And of course, we must draw attention where the rules are different (which
we do, usually using the word "restricted").

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGE3rM056127 for <[e-mail]>; Fri, 22 Jul 2005 09:14:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MGE3md056126 for ietf-usefor-skb; Fri, 22 Jul 2005 09:14:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MGE2sP056108 for <[e-mail]>; Fri, 22 Jul 2005 09:14:02 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-217.midband.mdip.bt.net ([81.144.77.217]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42e11b49.50cb.262 for [e-mail]; Fri, 22 Jul 2005 17:14:01 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6MGCFh20665 for [e-mail]; Fri, 22 Jul 2005 17:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22081
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1048 e.a.
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 22 Jul 2005 15:16:26 GMT
Lines: 40
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>If you're doing it in your office hours, and it isn't a part
>of your job.  The Injection-Date is a new header field, it's
>not obvious for normal users.  The same problems as with the
>Injection-Info.

Then you had better be careful, or issue an 'at' job to inject it after
you have left for home.

>I'd still like to be convinced why we must split the info in
>two header fields, "because the Injection-Date is no variant
>header" is only a formal argument, I don't get the idea behind
>this decision.

Having it as a "posting-date" parameter of Injection-Info was discussed by
the WG, and rejected (I don't recall the precise reason, but it is all in
the archives).

>All this "reinjection" stuff in usepro-04 is very confusing,
>maybe it deserves its own "unusual operations" chapter.  Why
>replace Injection-Info but not Injection-Date in this case ?

Because Injection-Date indicates that moment of time when the article
entered the network and started to flood through lots of different routes
in parallel. Some of those routes might have passed through a reinjection
point, and some not, yet they must all be treated the same when detecting
'staleness'; otherwise some site might accept it again after it had
already accepted and expired it once.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MCB7N1006278 for <[e-mail]>; Fri, 22 Jul 2005 05:11:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6MCB7sx006277 for ietf-usefor-skb; Fri, 22 Jul 2005 05:11:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6MCB6Hb006264 for <[e-mail]>; Fri, 22 Jul 2005 05:11:07 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 9E78C29947; Fri, 22 Jul 2005 08:11:05 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6MCB2kf000946(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 22 Jul 2005 08:11:02 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6MCB1Ee000945(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 22 Jul 2005 08:11:02 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Date: Fri, 22 Jul 2005 08:10:55 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 21 2005 11:11, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > See usefor section 1.6 first paragraph.  Either we do what it
> > says we do or we need to change what it says
> 
> We do what it says, not more the complete syntax as in the old
> <http://purl.net/xyzzy/usefor07.htm> but only the _differences_
> from 2822.  No _subtle_ mandatory SP hidden somewhere in prose
> and tons of more or less identical syntax, but as _obvious_ as
> possible, as in (to do) orig-date = "Date:" SP date-time CRLF
> 
> Everybody who knows the 2822 <orig-date> will immediately see
> the added SP.

But it doesn't say *why* there is an added SP, what is affected by
the difference, or what should be modified to bring the specification
into alignment with the Internet Message Format.

And yet you seem to be happy with _subtle_ modifications to the same
field w.r.t. zone abbreviations and MUST means MAY but MAY means MUST
(moreover where the field has no protocol role).  Inconsistency detected.
 
> > The change imposes structure (SP) on an unstructured field.
> 
> That's a weak argument, you could also say that the terminating
> CRLF or the embedded [FWS] is an "imposed structure".

No.  The CRLF terminates the field (or line thereof) and is part of the
overall message structure (the terminating CRLF is not part of the field
body). [FWS] is necessary to allow for whitespace and folding as utext
contains no whitespace characters or CR or LF.
 
> > There is no "erroneous optional trailing FWS" in RFC 2822.
> 
> Of course there is

We disagree on your narrow interpretation which does not recognize that
CFWS ("comments, line folding, and/or whitespace") includes FWS ("line
folding and/or whitespace").

> In usefor-05 we have about 2 * 10 = 20 of the same [FWS] bugs -
> they should be all replaced by *WSP.  But it won't surprise me
> if the final compromise are ten "MUST NOT" in prose:

If we have one implementation note that clearly identifies the issue(s)
and indicates the necessary workaround (and ideally direction for
migration to resolve the issue in a manner conforming to the Message
Format), then we can simply cite by reference those fields defined in
2822, which are bound by the 2822 section 3.2.3 restriction.  Whereas
if we produce conflicting syntax for "from" "orig-date", "message-id",
"references", "subject", "supersedes", etc., then it becomes unclear
whether 2822 3.2.3 applies.

> After the latest "SHOULD NOT RECOMMENDED" stunt I canot trust
> that they'll simply shoot us for this "engineering".  <sigh>

Give it a rest; this isn't MARID or ASRG.
 
> > these should be handled by implementation notes in order to
> > provide a rationale.
> 
> The rationale for the <msg-id> modifications is quite complete.

No, there is no rationale for excluding NO-WS-CTLs.  We can guess that
the reason is "Frank doesn't like them", but that's not a rationale.
There is nothing that indicates what has to be changed in any news
software implementations or protocols to achieve alignment with 2822,
which itself has been restricted (for Usenet-related reasons) from what
has been permitted by 822, 733, and 724.

> >> Posted without SP in all header fields => no problem
> 
> > IIRC, Russ reported that INN;s injection agent rejects such
> > messages.
> 
> `telnet -p 119 news.spamcop.net` says "INN 2.3.2".
> `telnet -p 119 news.gmane.org`   says "INN 2.4.1" (but for that
> server it only means that Lars didn't modify the 200 message)
> 
> I've not tested other servers, these two added the missing SP.

Then we need to reexamine whether the SP is really necessary at all,
and if so, adjust the rationale accordingly.  And if not, simply
drop the difference.
 
> > It's relevant for news/mail (i.e. messaging) UAs that wish to
> > conform to RFC 2822.
> 
> The mandatory SP conforms to the message/rfc822 format, the UA
> can always generate it.

True but irrelevant.  A UA generating a message cannot readily determine
where that message will go, and in principle altering messages after
generation causes problems (e.g. invalidates security mechanisms).

> In addition it must accept all mails 
s/mails/messages/
> without the SP and some weird cases with WSP before the colon.

Yes, this is the main point; any UA that handles messages in a 2822-
conforming manner must handle fields whether or not the first character
of the field body happens to be SP.  Not solely UAs of course, but any
software handling messages in a 2822-conforming manner.  As Mark has
noted, this MUST/REQUIRED to "protect" such software from dreaded fields
with no SP after the colon is silly; it is also unwarranted unless there
is a real problem meeting the BCP 14 criteria for use of imperative
keywords.  "SHOULD"/"RECOMMENDED" would be another matter.

Your tests seem to indicate that at least some versions of one
implementation cope fine with no SP; it remains to be seen precisely
where, if anywhere, there is a real problem warranting a BCP 14
imperative keyword.  As we have agreed on the general principle of
using 2822 except where necessary to deviate, it's up to those who wish
to impose the additional SP requirement to specify precisely where
the serious issues warranting imperative keywords arise; then we can
craft a suitable implementation note that identifies the issues and where
future changes can be applied to address them.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LMnHHL008272 for <[e-mail]>; Thu, 21 Jul 2005 15:49:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LMnHb2008271 for ietf-usefor-skb; Thu, 21 Jul 2005 15:49:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LMnGmi008254 for <[e-mail]>; Thu, 21 Jul 2005 15:49:17 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6LMnBjo024903 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 21 Jul 2005 15:49:11 -0700 (PDT)
Date: Thu, 21 Jul 2005 15:49:11 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>But if that is what RFC 2821 is doing, then that is exactly what my text
>is doing for the mailboxes "news", "usenet" and "abuse".

No it is not. You are attempting to create a new requirement that an 
existing standard explicitly says is NOT required. You are trying to do 
this for a mailbox that is NOT news-specific. USENET@ and NEWS@ are ours 
to describe. ABUSE@ is not.

>Therefore the text gives some more detail of that,

It is highly disengenuous to claim that your text is simply "more 
details" when you know your text makes a new requirement that the existing 
standard is explicit in saying is optional.

>And what you have written above implies that you accept that the "MUST" in
>RFC 2821 is justified, even though you have not indicated any
>interoperability issue. 

The MUST in RFC2821, if it exists, regarding "postmaster", applies to MAIL 
configuration, and it seems patently obvious that anyone who runs a MAIL 
system ought to have an address at which problems with that system which 
can easily affect others can be reached. That's called "interoperability 
issue". But this is irrelevant and you are wasting our time, since RFC2821 
is not the issue and cannot be changed by us no matter what.

Your MUST regarding an abuse@ address at every FQDN that appears in a path
is for NEWS, and we already require not just one but TWO addresses for
news administrators to deal with news configuration problems. 
Interoperability issues for NEWS are solved by using the USENET@ and 
NEWS@ addresses (although I cannot see why two are required when one 
would do.) 

The issue is why an address that is NOT news-specific and has no
interoperability issues is MANDATORY, despite an existing standard that 
clearly says it is optional.

You have yet to justify your mandate. Your attempt at clouding the issue 
by claiming that "it's just like POSTMASTER" is silly. Your claim that you 
are just "providing more details" is patently false. Your claim that it is 
a security issue is patently false. Your claim that RFC2142 applies only 
to ISPs is patently absurd. There simply is no reason to require an abuse 
reporting address for every FQDN that might appear in a path.

>I grant you that what I have written is not _exactly_ what RFC 2142 says

And you have yet to justify the difference, despite repeated requests.

>Is is in some aspects stronger and in some
>aspects weaker, and if people want to promote of demote the various
>instances of "should", "SHOULD" and "MUST", then that is a legitimate
>subject for discussion.

We have discussed it. Everyone other than you that I've seen express an 
opinion says drop the MUST regarding abuse and FQDN. It's not even worth a 
SHOULD, because the existing standard tells us it is OPTIONAL. As long as 
the top level domain is covered, then abuse reports can be sent.

>I have only
>proposed that MUST for injecting agents, and that only because those are
>the ones that people really need to be able to contact, 

USENET and NEWS are already required. There is no need for an abuse
address at every FQDN listed in that path because, unlike you, most people
seem to grok the concept of "top level domain", and even those that don't
are quite capable of figuring out where to send abuse reports anyway.

>But if people want that MUST demoted to SHOULD,
>then that can be discussed.

It's already been discussed. You cannot justify it. 

If you cannot justify it, remove it. 

So, the paragraph in question becomes just:

   For an injecting agent prepending to a Path header field (7.2.2), the
   <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LJ0GQQ090824 for <[e-mail]>; Thu, 21 Jul 2005 12:00:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LJ0GoX090823 for ietf-usefor-skb; Thu, 21 Jul 2005 12:00:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LJ0GII090817 for <[e-mail]>; Thu, 21 Jul 2005 12:00:16 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6LJ0DiJ016460 for <[e-mail]>; Thu, 21 Jul 2005 12:00:13 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id D7E06E791A; Thu, 21 Jul 2005 12:00:12 -0700 (PDT)
To: [e-mail]
Subject: Re: #1021 Newsgroups header ABNF: Status
In-Reply-To: <[e-mail]> (Harald Tveit Alvestrand's message of "Thu, 21 Jul 2005 20:48:06 +0200")
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Thu, 21 Jul 2005 12:00:12 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand <[e-mail]> writes:

> The only comment I have in my memory buffer is the one from Charles
> suggesting adding an explanation for the exceptions:

>      NOTE: "example.*" is reserved for examples in this and other
>      standards; "poster" has a special meaning in the Followup-To header
>      field; "to.*" is reserved for certain point-to-point communications
>      in conjunction with the "ihave" control message [USEPRO];
>      "control.*" and "junk" have special meanings in some news-servers;
>      "all" is used as a wildcard in some implementations; and "ctl" was
>      formerly used to indicate a <control-command> within the Subject
>      header field.

> Is there support for adding this, or opposition to it?
> Leaving this as "text proposed" for now.

I support adding this; I always find this sort of documentation of
exception cases worthwhile.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LImE8M089315 for <[e-mail]>; Thu, 21 Jul 2005 11:48:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LImEu6089314 for ietf-usefor-skb; Thu, 21 Jul 2005 11:48:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LImDo9089307 for <[e-mail]>; Thu, 21 Jul 2005 11:48:13 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A83F061AFB for <[e-mail]>; Thu, 21 Jul 2005 20:48:12 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07401-09 for <[e-mail]>; Thu, 21 Jul 2005 20:48:10 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0674E61B43 for <[e-mail]>; Thu, 21 Jul 2005 20:48:07 +0200 (CEST)
Date: Thu, 21 Jul 2005 20:48:06 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1021 Newsgroups header ABNF: Status
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The only comment I have in my memory buffer is the one from Charles 
suggesting adding an explanation for the exceptions:

     NOTE: "example.*" is reserved for examples in this and other
     standards; "poster" has a special meaning in the Followup-To header
     field; "to.*" is reserved for certain point-to-point communications
     in conjunction with the "ihave" control message [USEPRO]; "control.*"
     and "junk" have special meanings in some news-servers; "all" is used
     as a wildcard in some implementations; and "ctl" was formerly used to
     indicate a <control-command> within the Subject header field.

Is there support for adding this, or opposition to it?
Leaving this as "text proposed" for now.

                Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LH5w0K079728 for <[e-mail]>; Thu, 21 Jul 2005 10:05:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LH5wF6079727 for ietf-usefor-skb; Thu, 21 Jul 2005 10:05:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LH5v39079719 for <[e-mail]>; Thu, 21 Jul 2005 10:05:57 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DveTy-0001oK-Lj for [e-mail]; Thu, 21 Jul 2005 19:05:14 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 19:05:14 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 19:05:14 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1082 USEFOR 3.2.9 Need more text about Approved header field seman
Date:  Thu, 21 Jul 2005 19:03:33 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> (the present text is a bit bare)

It has two MUST, what's the complete text for 3.2.9 after your
modification ?  The proposed "Note" is fine, but you're talking
about _two_ modifications, what's the second addition ?

Or if the "Note" is the second addition, what's the first ?

> Essentially, it is generally considered a serious and
> LARTable offence to forge-approved a moderated article
> without the permission of the moderator.

Depends.  I feel entitled to approve my own Cancel messages
affecting all articles claiming to be "from" me, no matter
what the status of the groups might be.  But that would be
of course my own address, and not a forged moderator address.

> it would provide some ammunition to use against less clueful
> ISPs to demonstrate that the perpetrator was indeed trying
> to pass himself off as something that he was not.

Abusing foreign addresses in Approved is of course evil, same
as anywhere else (From / Sender / Reply-To, modulo what you
said elsewhere about some tolerated spam cancels).

                          Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEher075481 for <[e-mail]>; Thu, 21 Jul 2005 09:14:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LGEhVO075480 for ietf-usefor-skb; Thu, 21 Jul 2005 09:14:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEgVE075472 for <[e-mail]>; Thu, 21 Jul 2005 09:14:42 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-32.midband.mdip.bt.net ([81.144.65.32]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42dfc9f0.14aa8.174 for [e-mail]; Thu, 21 Jul 2005 17:14:40 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6LGCMD04401 for [e-mail]; Thu, 21 Jul 2005 17:12:22 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22057
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Jul 2005 13:56:46 GMT
Lines: 104
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

> >> - What needs to be said in order to "play nice" with the $altz
> "control."
> >> convention (for instance, not to outlaw it)

1. There is a clear requirement [USEFOR/RFC 2822] that message identifiers
be globally unique.

2. It is well known that if you deliberately break that requirement you
can bring about a situation whereby two different versions of what is
ostensibly the same article can propagate, but that any given server will
see only one of them.

3. In general, such deliberate breach of the standard would be regarded as
malpractice, meriting LARTing the perpetrator to his ISP. However, in a
few exceptional situations Usenet (more specifically, the consensus view
of the operators of servers) has consciously decided to turn a "blind eye"
to the breach.

In my opinion, we should leave it that way, by remaining resolutely silent
on the issue, certainly within USEFOR and USEPRO. I have reviewed the
earlier thread on this topic, and I find no calls for any specific action.

On looking at the current text of USEAGE, I find that I have written:

   ..... It is also in order to include
   additional information of significance to the poster within the <id-
   left>, and even to deliberately make a non-unique identifier in cases
   where the identical message is to be posted by several posters (for
   example, a cancel for an article which may also be cancelled by
   others).

I now think that maybe I ought to tone that down somewhat. Opinions?

Here is a little more background on the matter:

Usenet is a strange social phenomenon. There Is No Cabal - there is just
the body of server administrators world wide who, de facto, have ultimate
control.

Shortly after the Green Card affair, when a large number of spammers
started to cause widespread disruption of Usenet, Cancelmoose started to
issue mass cancels for spammed articles. Since such cancels were clearly
against all rules of good order on Usenet, he did so anonymously, through
anon.penet.fi, and I am not aware that, even to this day, his true
identity has ever become known. But he was quite open about it, posting
and discussing in news.admin.misc what he was doing.

Rather to everyone's surprise, Usenet as a whole hailed him as a hero.
There was an apparent consensus to turn a "blind eye", and various people
joined in to refine the process, resulting in the $alz convention, the
syberspam convention, and the Briedbart Index. That is a typical example
of how Usenet governs itself. We should leave it that way.

That is the approach I have taken in USEAGE. There are the usual
definitions of 1st, 2nd and 3rd party cancels, and what it says for 3rd
party cancels is:

   3. Other entities MAY be entitled to issue a cancel message for that
      article, in circumstances where established policy for any
      hierarchy or group in the Newsgroups header, or established custom
      within Usenet, so allows (such policies and customs are not
      defined by this document). ........


>>> - Whether, and if so where, the requirement not to go mess with
> other
> >> people's namespace needs to be documented

We are talking here of people who construct <msg-id>s which contain the
names of other people's domains in their <id-right>. Assuming that they
have taken care to choose an <id-left> such that the <msg-id> as a whole
is still globally unique, they are not in breach of USEFOR; nothing will
break as a result, hence they are not in breach of USEPRO. Nevertheless
the practice is, to say the least, extremely rude and probably constitutes
an attempt to throw doubt on the true origin of the article (since
<msg-id>s are one the places people will regularly look when trying to
trace the origin of an article). Therefore, this could be a proper concern
for USEAGE.

Here is a possible text for USEAGE, though I am not at all sure that it is
worth inclusion:

        NOTE: To use, in the <id-right>, a domain name or IP address not
        associated with the originating site could defeat the object of
        achieving global uniqueness and would, moreover, be an affront
        to the true owner of that domain (perhaps leading people to
        believe the article was somehow associated with that other
        domain). Such practice is therefore deprecated.
[possible text for #1083.]

Opinions?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEghq075471 for <[e-mail]>; Thu, 21 Jul 2005 09:14:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LGEg9l075470 for ietf-usefor-skb; Thu, 21 Jul 2005 09:14:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEf96075457 for <[e-mail]>; Thu, 21 Jul 2005 09:14:41 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-32.midband.mdip.bt.net ([81.144.65.32]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42dfc9ef.14aa8.173 for [e-mail]; Thu, 21 Jul 2005 17:14:39 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6LGCQN04411 for [e-mail]; Thu, 21 Jul 2005 17:12:26 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22059
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Jul 2005 14:47:00 GMT
Lines: 58
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Wed July 20 2005 10:31, Charles Lindsey wrote:
>> 
>> Perhaps it is the same interoperability issue that justifies defining
>> "postmaster" in RFC 2821 with a "MUST". It is related to fighting security
>> issues, and breaches of security count as "harm" in my book.

>RFC 2821 doesn't *define* postmaster "with a MUST"; it simply states that
>a system handling mail via SMTP MUST provide a well-known mailbox as a
>means of communication with the operators of that mail-handling system.

That is not how it is written in RFC 2821 (for example, RFC 2142 is not
even mentioned).

But if that is what RFC 2821 is doing, then that is exactly what my text
is doing for the mailboxes "news", "usenet" and "abuse". "news" and
"usenet" are entirely analogous to "postmaster"; "abuse" is slightly
different because RFC 2142 is less clear as to what domain name it is to
be used with. Therefore the text gives some more detail of that, and also
gives situations where those addresses need not be provided (just as RFC
2821 does for "postmaster").

And what you have written above implies that you accept that the "MUST" in
RFC 2821 is justified, even though you have not indicated any
interoperability issue. Therefore I do not see how you could fail to
accept the same thing in my entirely analogous text.

I grant you that what I have written is not _exactly_ what RFC 2142 says
(but neither is RFC 2821). Is is in some aspects stronger and in some
aspects weaker, and if people want to promote of demote the various
instances of "should", "SHOULD" and "MUST", then that is a legitimate
subject for discussion.


>In addition, requiring Usenet sites -- some of which are not on the
>Internet -- to support mail -- a separate set of protocols -- is
>questionable ....

That does not seem to have stopped RFC 2142 from "requiring" it (at least
in lower case). But in fact I have specifically NOT required it for
relaying sites in general, for just the reason you give. I have only
proposed that MUST for injecting agents, and that only because those are
the ones that people really need to be able to contact, and therefore it
is not an unreasonable imposition to expect them to establish some ability
to receive internet mail. But if people want that MUST demoted to SHOULD,
then that can be discussed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEeZ0075459 for <[e-mail]>; Thu, 21 Jul 2005 09:14:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LGEeev075458 for ietf-usefor-skb; Thu, 21 Jul 2005 09:14:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEdjQ075438 for <[e-mail]>; Thu, 21 Jul 2005 09:14:40 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-32.midband.mdip.bt.net ([81.144.65.32]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42dfc9ee.14aa8.172 for [e-mail]; Thu, 21 Jul 2005 17:14:38 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6LGCLG04395 for [e-mail]; Thu, 21 Jul 2005 17:12:21 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22056
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Date: Thu, 21 Jul 2005 11:36:10 GMT
Lines: 57
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>In this case, I recommend an implementation note rather than renaming
>ABNF rules.  The first bullet point in section 2.2 (usefor-05) could
>easily be converted into such a note.

>Specifically, OLD text:

>   o  All agents MUST generate header fields so that at least one space
>      immediately follows the ':' separating the header field name and
>      the header field body (for compatibility with deployed software).
>      News agents MAY accept header fields which do not contain the
>      required space.

>Suggested NEW text:

>Backward Compatibility Requirements

>   Some legacy injection agents reject messages which do not have an SP
>   character following the colon delimiting a header field name from
>   the field body.

>Implementation Recommendations

>   It is RECOMMENDED that an SP character be the first character of the
>   field body for compatibility with legacy injection agents.  Agents
>   SHOULD accept messages which do not have an SP character as the first
>   character of the field body.  Note that RFC 2822 conformance REQUIRES
>   acceptance of such messages.

Those two texts are mot equivalent in their effects. The first represents
the consensus view of this WG as established almost from day 1 of its
formation. The second does not.

>As the issue does not warrant BCP 14 imperatives (MUST/MUST NOT), I have
>suggested keywords appropriate to the (lack of) gravity of the situation.

The issue most certainly _does_ warrant such imperatives. There are severe
interoperability problems (and not just in "legacy injection agents").
Moreover, that SP is a REQUIRED feature of the new NNTP standard-to-be,
and there is no way that this WG can produce a standard that will not
interoperate with the NNTP standard.

Mark Crispin's suggestion of handling this matter by means of an
implementation note was raised during the discussion of the NNTP drafts,
and was roundly rejected.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEdcd075445 for <[e-mail]>; Thu, 21 Jul 2005 09:14:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LGEdiV075444 for ietf-usefor-skb; Thu, 21 Jul 2005 09:14:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEco8075427 for <[e-mail]>; Thu, 21 Jul 2005 09:14:39 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-32.midband.mdip.bt.net ([81.144.65.32]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42dfc9ed.14aa8.171 for [e-mail]; Thu, 21 Jul 2005 17:14:37 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6LGCOv04405 for [e-mail]; Thu, 21 Jul 2005 17:12:24 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22058
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Jul 2005 14:21:57 GMT
Lines: 45
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>> Charles Lindsey wrote:
>> 
>> > Those words apply to injecting agents only, NOT to all FQDNs
>> > in the path as you claimed.

>The specific text (which Charles has snipped) referred to "The prepended
><path-identity>".  As an injection agent doesn't prepend (there is at
>injection no Path field) and relaying agents do prepend, I can make no
>sense of Charles' comments.

You could perhaps have tried reading the actual text in USEPRO.

In fact, it is not necessarily the case that there is no Path present
prior to injection, as 7.2.1 makes clear.

The instructions given in USEPRO come in 2 steps:

9. If there is no Path already present, then you create one with a
<tail-entry> (typically "not-for-mail").

10. You then *prepend* the <path-identity> of the injecting agent,
together with a "POSTED", to the Path (which is now guaranteed to be
there by the previous step).


>If the text is meant to apply to injection agents, then it should
>avoid the word "prepend" and its derivatives and should clearly state
>that it refers specifically to injection.

Since the text in question is contained with a section entitled "Procedure
to be followed by Injecting Agents", that would hardly seem to be
necessary.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEdlO075436 for <[e-mail]>; Thu, 21 Jul 2005 09:14:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LGEdX4075435 for ietf-usefor-skb; Thu, 21 Jul 2005 09:14:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LGEcYf075424 for <[e-mail]>; Thu, 21 Jul 2005 09:14:38 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-32.midband.mdip.bt.net ([81.144.65.32]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42dfc9ec.14aa8.170 for [e-mail]; Thu, 21 Jul 2005 17:14:36 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6LGCRk04416 for [e-mail]; Thu, 21 Jul 2005 17:12:27 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22060
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1082 USEFOR 3.2.9 Need more text about Approved header field seman
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
Date: Thu, 21 Jul 2005 16:10:51 GMT
Lines: 45
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

#1082 is a ticket created by Alexey, but not formally introduced to this
list. Its full text is:

Charles wrote:

The 1st paragraph could usefully mention moderation and control
messages as the two most important applications of this header.

There should also be a sentence (maybe in a NOTE) such as the
following

The presence of a this header implies a claim to have authority
to post the article, thus assisting other sites to determine
whether to accept or act upon it.

in order to explain the semantics of this header.


The first addition is simply a matter of being helpful to the reader (the
present text is a bit bare), and should not be controversial.


The second addition is less important, but should be considered. There was
a comparable text in the old draft-13.

Essentially, it is generally considered a serious and LARTable offence to
forge-approved a moderated article without the permission of the
moderator. The proposed text respresents, I believe, the original intent
of the Approved header (now much watered down by years of misuse). But at
least it would provide some ammunition to use against less clueful ISPs to
demonstrate that the perpetrator was indeed trying to pass himself off as
something that he was not.

Alternatively, you might want this to be dealt with in USEAGE.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LG47ww074713 for <[e-mail]>; Thu, 21 Jul 2005 09:04:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LG473K074712 for ietf-usefor-skb; Thu, 21 Jul 2005 09:04:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LG46Sh074705 for <[e-mail]>; Thu, 21 Jul 2005 09:04:06 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DvdWI-0007QA-Hu for [e-mail]; Thu, 21 Jul 2005 18:03:34 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 18:03:34 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 18:03:34 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1032 USEFOR changes from 1036
Date:  Thu, 21 Jul 2005 18:01:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 25
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:
 
> o The [RFC 2822] conventions for parenthesis-enclosed
>   <comment>s in headers are supported.

| o The [RFC 2822] conventions for parenthesis-enclosed
|   <comment>s are supported in new header fields and all
|   header fields also used for mail (excl. Message-ID).

> o There are numerous other small changes, clarifications
>   and enhancements

The introduction of a potentially arbitrary <id-right> is
a new concept.  1036 also didn't have the "unique forever".
More stuff mentioned in s-o-1036 that I didn't check:

+ multiple moderators in the Approved header
+ generalization of the Xref rules
+ cancellation authorization based on From, not Sender

We're about to deprecate "Lines:".  We also modified the
"Subject:" (no more SHOULD "Re: ", old "cmsg" removed)

                           Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFnQr5073869 for <[e-mail]>; Thu, 21 Jul 2005 08:49:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LFnQFV073868 for ietf-usefor-skb; Thu, 21 Jul 2005 08:49:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFnPfu073862 for <[e-mail]>; Thu, 21 Jul 2005 08:49:26 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j6LFnGtS029813; Thu, 21 Jul 2005 11:49:16 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j6LFnF8Y029812; Thu, 21 Jul 2005 11:49:15 -0400 (EDT)
Date: Thu, 21 Jul 2005 11:49:15 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1032 USEFOR changes from 1036
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu, 21 Jul 2005, Harald Tveit Alvestrand wrote:
>  o There is a new Injection-Date header to facilitate
> the rejection of stale articles.

Perhaps better as:

 o There is a new Injection-Date header to make the
rejection of stale articles more precise and minimize
spurious rejections.

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFbe3X073189 for <[e-mail]>; Thu, 21 Jul 2005 08:37:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LFbeO7073188 for ietf-usefor-skb; Thu, 21 Jul 2005 08:37:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFbd5J073181 for <[e-mail]>; Thu, 21 Jul 2005 08:37:40 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38EE061B89; Thu, 21 Jul 2005 17:37:39 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04778-08; Thu, 21 Jul 2005 17:37:36 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9156961B43; Thu, 21 Jul 2005 17:37:35 +0200 (CEST)
Date: Thu, 21 Jul 2005 17:37:27 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: "Forrest J. Cavalier III" <[e-mail]>, [e-mail]
Subject: Re: #1030 and #1031
Message-ID: <AF0FA99594C54E5D526583E7@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.1.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Forrest,

the apparent consensus of the WG (as I read it) was that there was no way 
to tell from Bruce's suggestion what changes he intended to bring about 
based on them; one of them certainly was the "header" -> "header field" 
global replace, but from the way Bruce formulated himself, there was no way 
to tell whether that was the whole issue.

He had multiple people tell him that same thing, and chose not to clarify 
(as far as I can tell).

As Chair, I cannot rule consensus on a suggestion where the group cannot 
tell what the suggestion actually means.

                       Harald

--On 21. juli 2005 10:42 -0400 "Forrest J. Cavalier III" 
<[e-mail]> wrote:

> Harald Tveit Alvestrand wrote:
>
>> I've closed these two tickets since there appeared to be no specific
>> suggestions for text changes that could be made from them.
>>
>
> It is deceptive to create tickets as placeholders for "later
> discussion (because there are other things being discussed)" and then
> later close tickets because they had no discussion.
>
> It is wrong to close a ticket because there were no "specific
> suggestions for text changes."
>
> A ticket represents something that needs work.  You can't close
> it just because no one worked on it.
>
>> Some other tickets have been spun off from their discussion.
>
> If other tickets were created that detail all of the same
> issues, closing older duplicate tickets is fine.  There may
> be other reasons to close a ticket too, but the reasons you
> gave are unacceptably weak.
>
>>
>> Subject lines: "Backwards compatibility and handling incompatibilities"
>
> Point of order: 1030 was opened because Bruce indicated that consistent
> terminology was important.  He indicated that specific text would be
> suggested when the Chair ruled on the basic idea.
>
> The 1030 issue text had this sentence:
>
>      "The following sections need to be changed because of that -
>      details to be discussed when the basic change is accepted:
>     (probably 1.4), 2.1, 2.2, (small note in 3.6), 3.1.1, 3.1.2,
>     3.1.3, 3.1.4, 3.2, 3.2.1, 3.2.3, 3.2.5
>
> Did the Chair rule? If so, it was not indicated in any message with
> a subject that started Re: #1030.
>
>
>> "Standard terminology and text" (1031).
>
> That ticket had this text:
>     The following sections of USEFOR version -03 need to be changed
> because
>     of that - details to be discussed when the basic change is accepted:
>     1.4, 1.5, 1.6, 2.1, 2.2, 2.3, 3, 3.1, 3.1.1, 3.1.2, 3.1.3, 3.1,4,
> 3.1.5,
>     3.1.6, 3.1.7, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7,
>     3.2.8, 3.2.9, 3.2.10, 3.2.11, 3.2.12, 3.2.13, 3.3, 3.3.1, maybe 4,
>     probably 5, An IANA Considerations section is missing but REQUIRED
>     (per ID-Guidelines and "Instructions to RFC Authors"), 6.2, Appendix
> A.
>
>     Note that most of the changes are small and could be performed
>     automatically. In other cases, a section needs to be moved (Appendices
>     are supposed to appear before references) or added (IANA
> Considerations).
>     Several of the changes are due to requirements which are not currently
>     met by the draft.
>
> It was my understanding that a lot of what Bruce suggested in that ticket
> was clean-up work.  If the Editor wants help on specific text, then ask.
> Bruce was very specific in reviewing the sections.  Otherwise, how can you
> close it because there was no specific text.
>
> The right way of handling these items in a ticket system was for the chair
> to decide on the basic change, and then have the document editor take a
> shot at it, and provide differences to the list.  Changes to sections
> not controversial in that set should get noted as being accepted, and then
> you create a shorter list of items to work on.  Then you can either track
> it inside of the same ticket, or split out the remaining items to separate
> tickets, and close 1030 as a duplicate.
>
> "Sleight of hand" with the ticket system may help you get a "clean" ticket
> system by some deadline, but it will not result in an acceptable work
> product
> by that deadline.  A ticket system is an approximation of the readiness of
> a document.  Closing tickets does not change the reality.
>
> It is my opinion that not fully addressing the issues in 1030 and 1031
> will
> result in a document that fails Last Call as a matter of fact, not just
> a matter of opinion.
>
>
>






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFaXNw073123 for <[e-mail]>; Thu, 21 Jul 2005 08:36:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LFaXr3073122 for ietf-usefor-skb; Thu, 21 Jul 2005 08:36:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFaXM6073115 for <[e-mail]>; Thu, 21 Jul 2005 08:36:33 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j6LFaNtS029581; Thu, 21 Jul 2005 11:36:23 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j6LFaNiT029580; Thu, 21 Jul 2005 11:36:23 -0400 (EDT)
Date: Thu, 21 Jul 2005 11:36:22 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 , constructs
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu, 21 Jul 2005, Harald Tveit Alvestrand wrote:
>   This document defines a number of ABNF productions that are named
>   "news-" and the name of an RFC 2822 production...
> And then adding "news" in front of the rules, of course.

This seems like a reasonable idea, although I don't have strong feelings
about it either way -- leaving them as-is would work for me too.

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFSurP072525 for <[e-mail]>; Thu, 21 Jul 2005 08:28:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LFSuVh072524 for ietf-usefor-skb; Thu, 21 Jul 2005 08:28:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.epix.net (pine.epix.net [199.224.64.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFStWC072517 for <[e-mail]>; Thu, 21 Jul 2005 08:28:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-199-224-97-120-pppoe.dsl.hrbg.epix.net [199.224.97.120]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j6LFSlgt018798 for <[e-mail]>; Thu, 21 Jul 2005 11:28:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 21 Jul 2005 11:28:48 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: #1083 USEPRO 7.5: Rules for Generating message-ID
References: <26D82FF3BE67DA0CF8597CEB@B50854F0A9192E8EC6CDA126> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.153
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann wrote:
> Generally I'm quite happy with a RECOMMENDED, even in critical
> cases like LTRU SHOULD-Suppress-Script or SPF SHOULD-NOT-PRA,
> but <id-domain> is a fundamental concept, it's no <id-right>.

Since the chair, asked: I agree with Frank's statements on
this.

This WG wasted/spent a bunch of time arguing about this
uniqueness requirement several years ago.  The only sane way
for implementors to attempt uniqueness is by having confidence they don't
step on other people's toes.

"Pavement markings" will help keep all the drivers in their own lanes,
and give drivers the assurance of having the right-of-way in their own
lane.  Calling it 'id-right' may express what the software can
support, but declaring Usenet message IDs to have no lanes at all
is a problem.  Off-roading is no fun when there are that many
drivers you have to watch out for.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFSMNV072482 for <[e-mail]>; Thu, 21 Jul 2005 08:28:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LFSMcO072481 for ietf-usefor-skb; Thu, 21 Jul 2005 08:28:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFSKNo072467 for <[e-mail]>; Thu, 21 Jul 2005 08:28:20 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DvcxE-0007tL-AW for [e-mail]; Thu, 21 Jul 2005 17:27:20 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 17:27:20 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 17:27:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: ABNF remarks hidden in message "Admin: I'm back....."
Date:  Thu, 21 Jul 2005 17:11:33 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 65
Message-ID:  <[e-mail]>
References:  <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> See usefor section 1.6 first paragraph.  Either we do what it
> says we do or we need to change what it says

We do what it says, not more the complete syntax as in the old
<http://purl.net/xyzzy/usefor07.htm> but only the _differences_
from 2822.  No _subtle_ mandatory SP hidden somewhere in prose
and tons of more or less identical syntax, but as _obvious_ as
possible, as in (to do) orig-date = "Date:" SP date-time CRLF

Everybody who knows the 2822 <orig-date> will immediately see
the added SP.

> The change imposes structure (SP) on an unstructured field.

That's a weak argument, you could also say that the terminating
CRLF or the embedded [FWS] is an "imposed structure".

> There is no "erroneous optional trailing FWS" in RFC 2822.

Of course there is, but fortunately only one in <unstructured>,
compare <http://mid.gmane.org/[e-mail]>

In usefor-05 we have about 2 * 10 = 20 of the same [FWS] bugs -
they should be all replaced by *WSP.  But it won't surprise me
if the final compromise are ten "MUST NOT" in prose:

| Note: the leading and trailing [FWS] MUST NOT result in CRLF,
| it's a compromise between the correct *WSP and a 2822 [CFWS],
| let's see what the IESG thinks about this folly, but do not
| implement it.

After the latest "SHOULD NOT RECOMMENDED" stunt I canot trust
that they'll simply shoot us for this "engineering".  <sigh>

> these should be handled by implementation notes in order to
> provide a rationale.

The rationale for the <msg-id> modifications is quite complete.
Only the hidden agenda of "random garbage as <id-right> will do"
is obscured by "commonly derived from <domain>s".

With s/commonly/sometimes/ this part would be clearer.

>> Posted without SP in all header fields => no problem

> IIRC, Russ reported that INN;s injection agent rejects such
> messages.

`telnet -p 119 news.spamcop.net` says "INN 2.3.2".
`telnet -p 119 news.gmane.org`   says "INN 2.4.1" (but for that
server it only means that Lars didn't modify the 200 message)

I've not tested other servers, these two added the missing SP.

> It's relevant for news/mail (i.e. messaging) UAs that wish to
> conform to RFC 2822.

The mandatory SP conforms to the message/rfc822 format, the UA
can always generate it.  In addition it must accept all mails
without the SP and some weird cases with WSP before the colon.

                        Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LEgv2t068532 for <[e-mail]>; Thu, 21 Jul 2005 07:42:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LEgvVt068531 for ietf-usefor-skb; Thu, 21 Jul 2005 07:42:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.epix.net (pine.epix.net [199.224.64.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LEguDQ068524 for <[e-mail]>; Thu, 21 Jul 2005 07:42:57 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-199-224-97-120-pppoe.dsl.hrbg.epix.net [199.224.97.120]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j6LEgagt002108; Thu, 21 Jul 2005 10:42:43 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 21 Jul 2005 10:42:37 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Tveit Alvestrand <[e-mail]>, [e-mail]
Subject: Re: #1030 and #1031
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.153
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> I've closed these two tickets since there appeared to be no specific 
> suggestions for text changes that could be made from them.
> 

It is deceptive to create tickets as placeholders for "later
discussion (because there are other things being discussed)" and then
later close tickets because they had no discussion.

It is wrong to close a ticket because there were no "specific
suggestions for text changes."

A ticket represents something that needs work.  You can't close
it just because no one worked on it.

> Some other tickets have been spun off from their discussion.

If other tickets were created that detail all of the same
issues, closing older duplicate tickets is fine.  There may
be other reasons to close a ticket too, but the reasons you
gave are unacceptably weak.

> 
> Subject lines: "Backwards compatibility and handling incompatibilities" 

Point of order: 1030 was opened because Bruce indicated that consistent
terminology was important.  He indicated that specific text would be
suggested when the Chair ruled on the basic idea.

The 1030 issue text had this sentence:

     "The following sections need to be changed because of that -
     details to be discussed when the basic change is accepted:
    (probably 1.4), 2.1, 2.2, (small note in 3.6), 3.1.1, 3.1.2,
    3.1.3, 3.1.4, 3.2, 3.2.1, 3.2.3, 3.2.5

Did the Chair rule? If so, it was not indicated in any message with
a subject that started Re: #1030.


> "Standard terminology and text" (1031).

That ticket had this text:
    The following sections of USEFOR version -03 need to be changed because
    of that - details to be discussed when the basic change is accepted:
    1.4, 1.5, 1.6, 2.1, 2.2, 2.3, 3, 3.1, 3.1.1, 3.1.2, 3.1.3, 3.1,4, 3.1.5,
    3.1.6, 3.1.7, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7,
    3.2.8, 3.2.9, 3.2.10, 3.2.11, 3.2.12, 3.2.13, 3.3, 3.3.1, maybe 4,
    probably 5, An IANA Considerations section is missing but REQUIRED
    (per ID-Guidelines and "Instructions to RFC Authors"), 6.2, Appendix A.

    Note that most of the changes are small and could be performed
    automatically. In other cases, a section needs to be moved (Appendices
    are supposed to appear before references) or added (IANA Considerations).
    Several of the changes are due to requirements which are not currently
    met by the draft.

It was my understanding that a lot of what Bruce suggested in that ticket
was clean-up work.  If the Editor wants help on specific text, then ask.
Bruce was very specific in reviewing the sections.  Otherwise, how can you
close it because there was no specific text.

The right way of handling these items in a ticket system was for the chair
to decide on the basic change, and then have the document editor take a
shot at it, and provide differences to the list.  Changes to sections
not controversial in that set should get noted as being accepted, and then
you create a shorter list of items to work on.  Then you can either track
it inside of the same ticket, or split out the remaining items to separate
tickets, and close 1030 as a duplicate.

"Sleight of hand" with the ticket system may help you get a "clean" ticket
system by some deadline, but it will not result in an acceptable work product
by that deadline.  A ticket system is an approximation of the readiness of
a document.  Closing tickets does not change the reality.

It is my opinion that not fully addressing the issues in 1030 and 1031 will
result in a document that fails Last Call as a matter of fact, not just
a matter of opinion.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LEBsDK065586 for <[e-mail]>; Thu, 21 Jul 2005 07:11:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LEBsxC065585 for ietf-usefor-skb; Thu, 21 Jul 2005 07:11:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LEBrWu065578 for <[e-mail]>; Thu, 21 Jul 2005 07:11:53 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A88661B89 for <[e-mail]>; Thu, 21 Jul 2005 16:11:52 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03785-10 for <[e-mail]>; Thu, 21 Jul 2005 16:11:50 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C57C61B43 for <[e-mail]>; Thu, 21 Jul 2005 16:11:50 +0200 (CEST)
Date: Thu, 21 Jul 2005 16:11:44 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1032 USEFOR changes from 1036
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I've gotten some off-list comments on the text I cribbed from USEPRO.
Currently, we may suggest this text:

o The [RFC 2822] conventions for parenthesis-enclosed <comment>s
in headers are supported.
 o Whitespace is permitted in Newsgroups headers
 o The syntax of the Path header has been reworked to add multiple
forms of information
 o MIME is recognized as an integral part of Netnews.
 o There is a new Injection-Date header to facilitate
the rejection of stale articles.
 o There are several new optional headers defined, notably
 Archive, Injection-Info, and User-Agent, leading to increased
 functionality.
 o There are numerous other small changes, clarifications and
 enhancements

Is this an acceptable text for "changes from 1036"?

                      Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LE8Bfp065107 for <[e-mail]>; Thu, 21 Jul 2005 07:08:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LE8Blh065106 for ietf-usefor-skb; Thu, 21 Jul 2005 07:08:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LE8ArI065100 for <[e-mail]>; Thu, 21 Jul 2005 07:08:10 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dvbi6-0000f4-BG for [e-mail]; Thu, 21 Jul 2005 16:07:38 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 16:07:38 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 16:07:38 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Date:  Thu, 21 Jul 2005 16:04:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 34
Message-ID:  <[e-mail]>
References:  <26D82FF3BE67DA0CF8597CEB@B50854F0A9192E8EC6CDA126>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> I'm curious..... why is it an USEFOR problem rather than an
> USEPRO problem,

Because everything else related to the <msg-id> semantics and
syntax is in USEFOR:

- the peculiar length limit (not 320= 255+1+64, but only 248)
- the excluded CTL and other excluded quoted-pairs like "\ "
- the case sensitive <id-domain> idea (in my terminology)
- a variant of the STRONGLY DISCOURAGED domain literals
- the second half of the security considerations in chapter 5
- the general "build on 2822" concept pointing to 2822 3.6.4
- 3 of the 9 differences from RfC 2822 are about the <msg-id>
- the future differences from RfC 1036 will cover the major
  steps away from the known <unique@full_domain_name> concept

In contrast USEPRO doesn't talk much about the <msg-id>, it's
the NNTP view, a given identifier, nobody cares whether it has
any "@" or what the right side might be - perfectly okay from
a server's POV, but not the place to introduce the concept of
a "name space" aka <id-domain>.

The real issue is that 2822 says _only_ RECOMMENDED about the
<id-domain>, but it's an implicit MUST in the older standards
(STD 11, 1036, s-o-1036, predecessors).

Generally I'm quite happy with a RECOMMENDED, even in critical
cases like LTRU SHOULD-Suppress-Script or SPF SHOULD-NOT-PRA,
but <id-domain> is a fundamental concept, it's no <id-right>.

                     Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDxB65064389 for <[e-mail]>; Thu, 21 Jul 2005 06:59:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LDxBu5064388 for ietf-usefor-skb; Thu, 21 Jul 2005 06:59:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDxAAl064381 for <[e-mail]>; Thu, 21 Jul 2005 06:59:11 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 364FA61B89 for <[e-mail]>; Thu, 21 Jul 2005 15:59:10 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03785-01 for <[e-mail]>; Thu, 21 Jul 2005 15:59:06 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id C20D061B43 for <[e-mail]>; Thu, 21 Jul 2005 15:59:05 +0200 (CEST)
Date: Thu, 21 Jul 2005 15:59:05 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1003 Message-ID issues - status
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In usefor-05, the proposed text was inserted.
However, there are some outstanding niggles:

- Some unhappiness with the recommendation on use of domain-literal.
Current text:

   If domain literals are used, the syntax found in Section 4.1.3 of
   [RFC2821] is RECOMMENDED.

- A question on whether or not the "don't use other people's namespace" 
belongs here or not. There is current text talking about generation:

   Some software will try to match the <id-right> of a <msg-id> in a
   case-insensitive fashion; some will match it in a case-sensitive
   fashion.  Implementations MUST NOT generate two Message-IDs where the
   only difference is the case of characters in the <id-right> part.

So we need to decide if anything goes here, and if anything, what.

- Charles suggested adding a dot to the examples:

3.1.3  Message-ID

   <[e-mail]>
   <"abcd"@example.com>
   <"ab\cd"@example.com>
s/abcd/ab.cd/
s/"abcd"/"ab.cd"/
s/"ab\cd"/"ab.\cd"/

so as to illustrate the <dot-atom-text> bug found by Frank, and to agree
with the NNTP draft.

I think that's uncontroversial.

- Frank still wants to change the RHS name from "id-right" to "id-domain". 
I have not seen anyone else support this change; I am going to declare 
consensus on not changing it unless I hear other voices.

I'm leaving this ticket open until these are settled.
Comments?

                   Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDiq0R061597 for <[e-mail]>; Thu, 21 Jul 2005 06:44:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LDiq5g061596 for ietf-usefor-skb; Thu, 21 Jul 2005 06:44:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDinIi061572 for <[e-mail]>; Thu, 21 Jul 2005 06:44:51 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B3B0061B89 for <[e-mail]>; Thu, 21 Jul 2005 15:44:48 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03560-03 for <[e-mail]>; Thu, 21 Jul 2005 15:44:47 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0086A61B43 for <[e-mail]>; Thu, 21 Jul 2005 15:44:46 +0200 (CEST)
Date: Thu, 21 Jul 2005 15:44:46 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1030 and #1031
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I've closed these two tickets since there appeared to be no specific 
suggestions for text changes that could be made from them.

Some other tickets have been spun off from their discussion.

Subject lines: "Backwards compatibility and handling incompatibilities" 
(1030) and "Standard terminology and text" (1031).

                      Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDZHrd057986 for <[e-mail]>; Thu, 21 Jul 2005 06:35:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LDZHuC057984 for ietf-usefor-skb; Thu, 21 Jul 2005 06:35:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDZGif057976 for <[e-mail]>; Thu, 21 Jul 2005 06:35:17 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id C60542996D; Thu, 21 Jul 2005 09:35:15 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6LDZDNx014246(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 21 Jul 2005 09:35:15 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6LDZCuU014245(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 21 Jul 2005 09:35:12 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Date: Thu, 21 Jul 2005 09:35:10 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 21 2005 05:40, Frank Ellermann wrote:
> 
> [PEBKAC or re-post, sorry if that article appears twice]
> 
> Bruce Lilly wrote:
> 
> > The rule name "from" appears multiple places in RFC 2822; we
> > have no authority to alter the meaning of RFC 2822.
> 
> We have every authority to do the right thing for NetNews, and
> if it pleaes us we could even try "updates 2822".  But in the
> case of the mandatory SP that's certainly not necessary.

See usefor section 1.6 first paragraph.  Either we do what it says
we do or we need to change what it says (however, what it says is in
fact what we're supposed to do, as established ca. two years ago).

> > E.g. "usefor-from"
> 
> It's an idea for the minor cases, and <news-date> is arguably
> better than <orig-date>.  OTOH <news-subject> etc. is dubious,
> there's nothing special with it, only a mandatory SP, even the
> erroneous optional trailing FWS was copied as is from RfC 2822.

The change imposes structure (SP) on an unstructured field.  There
is no "erroneous optional trailing FWS" in RFC 2822.

> There are several classes of "conflicts":
> 
> 1 - minor changes like the mandatory SP, adding "news-" to the
>     2822 name could make sense, but it's IMHO unecessary.

I'd prefer to see an implementation note and no ABNF (other than
that in our normative references).  As noted in the reference
messages which I supplied yesterday, that clearly indicates *why*
there is a difference, whereas a different ABNF not only doesn't
provide a reason, it adds confusion.
 
> 2 - major changes completely different from 2822 productions
>     like <id-local>, <id-domain>, <id-literal>, and <id-quote>
>     in my terminology - using the same names as in RfC 2822 is
>     IMNSHO _wrong_ (and the 2822 names were already bad).
> 
>     The RfC 2822 "semantical content" for <no-fold-quote> and
>     <no-fold-literal> differs from <id-quote> or <id-literal>.
> 
>     Abusing the old name fools nobody who knows what's this is
>     about, but it could confuse implementors and cause harm.

Again, these should be handled by implementation notes in order to
provide a rationale.
 
> 3 - major changes intended to overload the equivalent concept
>     in 2822, the <msg-id>.  The <references> are a border case.

Ditto.
 
> >| legacy injection agents reject messages which do not have an
> >| SP character following the colon delimiting a header field
> >| name from the field body.
> 
> <news://news.spamcop.net/[e-mail]>
> Posted without SP in all header fields => no problem

IIRC, Russ reported that INN;s injection agent rejects such messages.
 
> > Note that RFC 2822 conformance REQUIRES acceptance of such
> > messages.
> 
> Only relevant for gateways (in usePRO) if they intend to post
> such crap, and their injection agent doesn't fix a missing SP.

No. It's relevant for news/mail (i.e. messaging) UAs that wish to
conform to RFC 2822.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDKHMO052084 for <[e-mail]>; Thu, 21 Jul 2005 06:20:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LDKH3k052083 for ietf-usefor-skb; Thu, 21 Jul 2005 06:20:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LDKGoC052070 for <[e-mail]>; Thu, 21 Jul 2005 06:20:16 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 5727A29930; Thu, 21 Jul 2005 09:20:15 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6LDKAWI014149(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 21 Jul 2005 09:20:14 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6LDKAjm014148(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 21 Jul 2005 09:20:10 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1048 e.a.
Date: Thu, 21 Jul 2005 09:20:06 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 21 2005 02:16, Frank Ellermann wrote:

> If you're doing it in your office hours, and it isn't a part
> of your job.  The Injection-Date is a new header field, it's
> not obvious for normal users.  The same problems as with the
> Injection-Info.
> 
> I'd still like to be convinced why we must split the info in
> two header fields, "because the Injection-Date is no variant
> header" is only a formal argument, I don't get the idea behind
> this decision.

The injection date needs to be examined to avoid propagating "stale"
articles (so the argument goes).  That's reasonable for the
Injection-Date field syntax.  It would be unreasonable to have to
parse the convoluted Injection-Info field (as currently sort-of
defined (the ABNF has major flaws last time I looked)).
 
> All this "reinjection" stuff in usepro-04 is very confusing,
> maybe it deserves its own "unusual operations" chapter.  Why
> replace Injection-Info but not Injection-Date in this case ?

It should be elided.  Only Charles seems to think there is such
a thing.  See John Stanley's relevant comments in yesterday's
messages.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LCcY8N037123 for <[e-mail]>; Thu, 21 Jul 2005 05:38:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LCcYAf037122 for ietf-usefor-skb; Thu, 21 Jul 2005 05:38:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LCcXo2037112 for <[e-mail]>; Thu, 21 Jul 2005 05:38:33 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE74961B4C for <[e-mail]>; Thu, 21 Jul 2005 14:38:32 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02753-02 for <[e-mail]>; Thu, 21 Jul 2005 14:38:30 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 869D661B43 for <[e-mail]>; Thu, 21 Jul 2005 14:38:30 +0200 (CEST)
Date: Thu, 21 Jul 2005 14:38:29 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I've created the following ticket:
----------------------------------------------------
Subject: USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs


>From Bruce Lilly July 20:

 The issue persists in usefor-05:

 from = "From:" SP mailbox-list CRLF

 That differs from RFC 2822:

 from = "From:" mailbox-list CRLF

 The rule name "from" appears multiple places in RFC 2822; we have no
authority to alter the meaning of RFC 2822.
If there is a good reason
to define ABNF -- and AFAICT there is not as the SP issue can be
handled via an implementation note along the lines suggested by Mark
Crispin -- then simply choose a different rule name so that it does
not conflict with rule names used in references. E.g. "usefor-from"
or "blurfl".
------------------------------------------------------

I've noted Frank's comment.

Personal comment: I don't find the issue very important, since I don't find 
the redefinitions confusing. Your mileage may differ.

>From a formalistic standpoint (and making the ABNF easier to check as an 
extension to the 2822 grammar), I think there's something to be said for an 
intro saying something like:

  This document defines a number of ABNF productions that are named
  "news-" and the name of an RFC 2822 production (for instance
  "news-from"). This is intended to document a restriction in the Netnews
  article format compared to the RFC 2822 message format; a valid Netnews
  article will be a valid RFC 2822 message, but will also satisfy the
  ABNF specified in the "news-" rules.

And then adding "news" in front of the rules, of course.

Another alternative is just leaving them as-is.

Thoughts?

                          Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LBv1pH022652 for <[e-mail]>; Thu, 21 Jul 2005 04:57:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6LBv1LF022651 for ietf-usefor-skb; Thu, 21 Jul 2005 04:57:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LBuxjb022638 for <[e-mail]>; Thu, 21 Jul 2005 04:57:00 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E4BB61B4C; Thu, 21 Jul 2005 13:56:59 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02231-03; Thu, 21 Jul 2005 13:56:55 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0894061B43; Thu, 21 Jul 2005 13:56:52 +0200 (CEST)
Date: Thu, 21 Jul 2005 13:56:41 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Message-ID: <26D82FF3BE67DA0CF8597CEB@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On 21. juli 2005 11:32 +0200 Frank Ellermann <[e-mail]> 
wrote:

> For #1003 the problem of abusing foreign name spaces is still
> unresolved, that's a USEFOR problem, last discussed in:
>
> <http://mid.gmane.org/[e-mail]>
> <http://mid.gmane.org/[e-mail]>

I'm curious..... why is it an USEFOR problem rather than an USEPRO problem, 
apart from having been discussed under an USEFOR ticket earlier?

                 Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L9kY9Q078009 for <[e-mail]>; Thu, 21 Jul 2005 02:46:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L9kYmd078007 for ietf-usefor-skb; Thu, 21 Jul 2005 02:46:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gundel.de.clara.net (gundel.de.clara.net [212.82.225.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L9kXI7077991 for <[e-mail]>; Thu, 21 Jul 2005 02:46:33 -0700 (PDT) (envelope-from [e-mail])
Received: from du-001-214.access.de.clara.net ([212.82.227.214] helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1DvXqc-000GIT-NZ for [e-mail]; Thu, 21 Jul 2005 12:00:11 +0200
Message-ID: <[e-mail]>
Date: Thu, 21 Jul 2005 11:40:33 +0200
From: Frank Ellermann <[e-mail]>
Organization: <URL:http://purl.net/xyzzy>
X-Mailer: Mozilla 3.0 (OS/2; U)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

[PEBKAC or re-post, sorry if that article appears twice]

Bruce Lilly wrote:

> The rule name "from" appears multiple places in RFC 2822; we
> have no authority to alter the meaning of RFC 2822.

We have every authority to do the right thing for NetNews, and
if it pleaes us we could even try "updates 2822".  But in the
case of the mandatory SP that's certainly not necessary.

> E.g. "usefor-from"

It's an idea for the minor cases, and <news-date> is arguably
better than <orig-date>.  OTOH <news-subject> etc. is dubious,
there's nothing special with it, only a mandatory SP, even the
erroneous optional trailing FWS was copied as is from RfC 2822.

> or "blurfl".

Nonsense names like <blurf1>, <id-left>, or <id-right> are a
bad idea.  The name should indicate the semantics where that's
possible.

> "from" is not the only instance of such a conflict.

There are several classes of "conflicts":

1 - minor changes like the mandatory SP, adding "news-" to the
    2822 name could make sense, but it's IMHO unecessary.

2 - major changes completely different from 2822 productions
    like <id-local>, <id-domain>, <id-literal>, and <id-quote>
    in my terminology - using the same names as in RfC 2822 is
    IMNSHO _wrong_ (and the 2822 names were already bad).

    The RfC 2822 "semantical content" for <no-fold-quote> and
    <no-fold-literal> differs from <id-quote> or <id-literal>.

    Abusing the old name fools nobody who knows what's this is
    about, but it could confuse implementors and cause harm.

3 - major changes intended to overload the equivalent concept
    in 2822, the <msg-id>.  The <references> are a border case.

>| legacy injection agents reject messages which do not have an
>| SP character following the colon delimiting a header field
>| name from the field body.

<news://news.spamcop.net/[e-mail]>
Posted without SP in all header fields => no problem

<news://news.gmane.org/[e-mail]>
Dito.  Note that the injection agent _added_ the missing
SPs, for all header fields.  That was a "real" newsgroup,
GMaNe's "junk" is unaffected by its gateway tricks.

Same effect in the first test, missing SP _added_ by SC.

Last but not least (but behind GMaNe's gateway magic) see
<http://article.gmane.org/gmane.test/2412/raw>

What I posted was this:

X-Mozilla-Status: 0001
Message-ID:<[e-mail]>
Date:Thu, 21 Jul 2005 09:04:51 +0200
From:Frank Ellermann <[e-mail]>
Newsgroups:gmane.test
Subject:no SP

no SP (2)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Can we now please return from the deserts of wishful thinking
to the reality of NetNews and USEFOR ?  If you want to add a
blurb about how proto-articles without the mandatory SP might
be fixed by injection agents to usePRO it's okay, but it does
not change the article format in useFOR.

> Note that RFC 2822 conformance REQUIRES acceptance of such
> messages.

Only relevant for gateways (in usePRO) if they intend to post
such crap, and their injection agent doesn't fix a missing SP.

And this _is_ in fact a job for posting / followup agents, for
the complete fun visit the planned MASS WG - if other agents
"fix" header fields it could cause havoc for header signatures.

                             Bye, Frank



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L9YuuT074143 for <[e-mail]>; Thu, 21 Jul 2005 02:34:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L9YukQ074142 for ietf-usefor-skb; Thu, 21 Jul 2005 02:34:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L9Yt9n074125 for <[e-mail]>; Thu, 21 Jul 2005 02:34:55 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DvXS0-000294-4K for [e-mail]; Thu, 21 Jul 2005 11:34:44 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 11:34:44 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 11:34:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Date:  Thu, 21 Jul 2005 11:32:13 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery wrote:

  [a <msg-id> determined by the injection agent]
>> Now I'm lost how the posting agent can determine which
>> Message-ID it got, if it's not reported in the 340 or 240
>> POST reply.
 
> It can't, in the general case.

Bad.  Maybe we should address this in USEAGE, something like:

"decent news servers offer vanity domains for their users
 for the creation of valid Message-IDs without collisions".

For #1003 the problem of abusing foreign name spaces is still
unresolved, that's a USEFOR problem, last discussed in:

<http://mid.gmane.org/[e-mail]>
<http://mid.gmane.org/[e-mail]>

                      Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L77kh6015769 for <[e-mail]>; Thu, 21 Jul 2005 00:07:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L77k5a015768 for ietf-usefor-skb; Thu, 21 Jul 2005 00:07:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L77jT4015752 for <[e-mail]>; Thu, 21 Jul 2005 00:07:45 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C44A61B4C; Thu, 21 Jul 2005 09:07:44 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31464-03; Thu, 21 Jul 2005 09:07:42 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DB2461B43; Thu, 21 Jul 2005 09:07:41 +0200 (CEST)
Date: Thu, 21 Jul 2005 09:07:40 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: #1047 Path field delimiters and components (Re: Ticket status, USEFOR)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

(Changing the subject, since this is specific)

--On onsdag, juli 20, 2005 14:22:40 +0000 Charles Lindsey 
<[e-mail]> wrote:

>> 1047 USEFOR 3.1.6: Path field delimiters and components
>> "Text needed"
>
> There is ongoing discussion of section 2.3 of USEPRO which is relevant to
> this. The particular issue which interacts with USEFOR is the extent to
> which servers should be allowed to identity themselves in the Path using
> their IP address. It is agreed that this should be
> discouraged/deprecated/whatever, but I think it would be going too far to
> forbid it entirely.

On reviewing, I have found you arguing that systems should be allowed to so 
identify themselves, citing 4% of messages that have IP addresses in the 
path. But your analysis of July 5 seemed to indicate that in all cases 
where it was possible to guess at the purpose, the IP address was injected 
in the path as "diagnostic information", not in a way that would make you 
think it was intended to manage propagation.

I think there's general agreement that IPv4 addresses MUST be allowed to 
occur in the Path: header (because of current practice and useful 
diagnostic ability), and more-or-less agreement that IPv6 addresses should 
be allowed because of being "address format neutral", but I don't see any 
support in the group for letting people use it as identifiers.

> I would suggest letting that USEPRO discussion proceed (perhaps it needs a
> ticket) and when that is settled the syntax in USEFOR can be adjusted to
> match.

Or the other way around.... yes, the USEPRO discussion needs a ticket.

                        Harald






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L6Hw73094613 for <[e-mail]>; Wed, 20 Jul 2005 23:17:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L6HwDr094612 for ietf-usefor-skb; Wed, 20 Jul 2005 23:17:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L6HvLO094599 for <[e-mail]>; Wed, 20 Jul 2005 23:17:57 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DvUNX-00009T-04 for [e-mail]; Thu, 21 Jul 2005 08:17:55 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 08:17:54 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 08:17:54 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1048 e.a.
Date:  Thu, 21 Jul 2005 08:16:46 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 31
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

>> could be a privacy issue:  Some users - posting when they
>> are supposed to do something else - intentionally use
>> timestamps like 00:00 -0000.  The Injection-Date could
>> defeat these efforts.
 
> What privacy issue? "use timestamps" where and for what
> purpose? Injection-Date records the time of injection; how
> precisely is that a privacy issue?

If you're doing it in your office hours, and it isn't a part
of your job.  The Injection-Date is a new header field, it's
not obvious for normal users.  The same problems as with the
Injection-Info.

I'd still like to be convinced why we must split the info in
two header fields, "because the Injection-Date is no variant
header" is only a formal argument, I don't get the idea behind
this decision.

All this "reinjection" stuff in usepro-04 is very confusing,
maybe it deserves its own "unusual operations" chapter.  Why
replace Injection-Info but not Injection-Date in this case ?

> Privacy (see definition in BCP 36, a.k.a. RFC 2828) is a
> security-related issue.  Privacy issues could be a subsection
> of the security considerations section.

Okay, then that's something for chapter 8 in usepro-05.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L63vHH088521 for <[e-mail]>; Wed, 20 Jul 2005 23:03:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L63vxd088520 for ietf-usefor-skb; Wed, 20 Jul 2005 23:03:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L63uiB088507 for <[e-mail]>; Wed, 20 Jul 2005 23:03:56 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DvU9y-0007kR-9m for [e-mail]; Thu, 21 Jul 2005 08:03:54 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 08:03:54 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 08:03:54 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  #1046 MIME boundary issues (was: Ticket status, USEFOR)
Date:  Thu, 21 Jul 2005 08:02:43 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 
 [1046 USEFOR 5. MIME boundary security considerations]
> There is some proposed wording in the Security Considerations
> of USEPRO to cover this.

These considerations need to be in usefor-06, because they are
a consequence of the "MUST MIME and 2231" in usefor-??, it's no
NetNews protocol problem.  Servers aren't supposed to know what
MIME is, only gateways might be mildly interested.

> I certainly think it is a USEPRO matter

IBTD.

> probably be better to put all the Security Considerations
> into USEPRO, on the grounds that they all deal with things
> that can go wrong with the protocols.

Yes, and these MIME problems are no NetNews protocol problems,
so that part shouldn't go into the next usePRO, it's attached
to several MUSTs in useFOR-05 chapter 2.3.

The part about CTL characters in article bodies could also go
to useFOR-06.  No idea why you mention only bodies, it's not
necessarily better in any displayed header field.

                      Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L5qXIv084157 for <[e-mail]>; Wed, 20 Jul 2005 22:52:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L5qXLI084155 for ietf-usefor-skb; Wed, 20 Jul 2005 22:52:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L5qWTH084147 for <[e-mail]>; Wed, 20 Jul 2005 22:52:32 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j6L5qVLS021992 for <[e-mail]>; Wed, 20 Jul 2005 22:52:32 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9CF8AE791A; Wed, 20 Jul 2005 22:52:31 -0700 (PDT)
To: [e-mail]
Subject: Re: #1083 USEPRO 7.5: Rules for Generating message-ID
In-Reply-To: <[e-mail]> (Frank Ellermann's message of "Thu, 21 Jul 2005 07:34:36 +0200")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 20 Jul 2005 22:52:31 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann <[e-mail]> writes:

> For some time "proposed Message-IDs" were an optional NNTP
> feature, but I don't find it in the new NTP-base RfC ?!

It was dropped for various reasons that I believe are in the list
archives, or rather deferred for someone to document as an extension if
they're so inclined.

> Now I'm lost how the posting agent can determine which Message-ID it
> got, if it's not reported in the 340 or 240 POST reply.

It can't, in the general case.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L5aaLO076141 for <[e-mail]>; Wed, 20 Jul 2005 22:36:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L5aaYI076140 for ietf-usefor-skb; Wed, 20 Jul 2005 22:36:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L5aYeI076121 for <[e-mail]>; Wed, 20 Jul 2005 22:36:35 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DvTjE-0004nj-2A for [e-mail]; Thu, 21 Jul 2005 07:36:16 +0200
Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 07:36:16 +0200
Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 21 Jul 2005 07:36:16 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1083 USEPRO 7.5: Rules for Generating message-ID
Date:  Thu, 21 Jul 2005 07:34:36 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-214.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> generating message-IDs are considered part of what a posting
> agent does (I think)

Or the injection agent if there is no Message-ID in a proto
article.  That's a feature for users without a proper name
space, they can stop to create <local@bogus> Message-IDs and
let the injection agent do it.

For some time "proposed Message-IDs" were an optional NNTP
feature, but I don't find it in the new NTP-base RfC ?!  Now
I'm lost how the posting agent can determine which Message-ID
it got, if it's not reported in the 340 or 240 POST reply.

                             Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L2J9g5045947 for <[e-mail]>; Wed, 20 Jul 2005 19:19:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6L2J9Ye045946 for ietf-usefor-skb; Wed, 20 Jul 2005 19:19:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6L2J8gc045940 for <[e-mail]>; Wed, 20 Jul 2005 19:19:09 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-17.midband.mdip.bt.net ([81.144.71.17]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42df061a.13496.7a for [e-mail]; Thu, 21 Jul 2005 03:19:06 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6L2CBO24378 for [e-mail]; Thu, 21 Jul 2005 03:12:11 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22040
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: NEW: USEFOR -05 3.1 Injection-Date was mandatory
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
Date: Wed, 20 Jul 2005 16:45:35 GMT
Lines: 60
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Ticket please.

In Usefor-03, the Injection-Date header field was mandatory. In Usefor-04
it was made optional without any prior discussion in this WG. I request
that it be restored. The background to this is as follows:

The Injection-Date field was introduced about a year ago following
discussions on this WG.

The reason for introducing Injection-Date was that RFC 2822 had changed
the meaning of Date. It is now the date when the article was written
(which is a Good Thing), whereas much present software actually fills in
the date when it was injected. The date when an article was written may be
quite some time before before it gets injected. Think of a man who writes
an article on his laptop, but does not manage to get to an internet
connection until three days later. By that time, many sites will refuse
the article because their expiry limit is only 3 days.

This header field was therefore made "MUST generate" (and that is what
USEPRO still says). Clearly nobody will be generating this header on Day 1
of the new standard.When people do start generating it, no additional harm
will arise at sites that have not yet upgraded (they just ignore it, like
they do all unknown headers).  There are specific provisions in USEPRO for
sites to fall back to using the Date header when the Injection-Date header
is missing. Thus no compatibility issues (forward or backward) arise.

Since I had written "MUST generate", I therefore put this header into the
"mandatory" class in the old draft-13, and that is how it appeared
initially in USEFOR.

Sites are supposed to check that the Injection-Date (or failing that the
Date) falls within their expiry limits; failure to implement this check
can result in endless loops, which is the ultimate sin on Usenet. Indeed,
all well managed sites already do it (using Date) even though no current
standard tells them to (it's just part of the "folklore" on which Usenet
currently runs).

There are many news features we have introduced which will render existing
implementations technically non-compliant on the day this standard comes
out (folding of Newsgroups header fields, which MUST be accepted, is one
example). However, in all such cases we have carefully arranged that no
immediate harm arises (see the section on "Transitional Arrangements"
currently in USEPRO, though it may finally end up in an Appendix in
USEFOR). It was always considered that implementors would be more likely
to implement the new features more quickly if we wrote a few MUSTs to
encourage them (take your choice as to whether that counts as a carrot or
a stick :-) ). I don't see why this particular case should be treated any
differently, nor do I see any difference in strength between the terms
"mandatory" and "MUST".
 
-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KIgLij004708 for <[e-mail]>; Wed, 20 Jul 2005 11:42:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KIgLgf004707 for ietf-usefor-skb; Wed, 20 Jul 2005 11:42:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KIgK16004689 for <[e-mail]>; Wed, 20 Jul 2005 11:42:20 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6KIgFWP071774 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 20 Jul 2005 11:42:15 -0700 (PDT)
Date: Wed, 20 Jul 2005 11:42:14 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

Using the old "it's in the draft" justification:

>The CHANGED rules (as you call them) were written into the draft about 5
>years ago, 

RFC2142 is dated 1997, which is more than 5 years ago. USEPRO-00 is dated
2004, which is not more than 1 year ago. We deliberately put off
discsussing USEPRO until USEFOR was well on its way, so now it is USEPRO's
turn for scrutiny -- not five years ago. You want the rules of RFC2142
changed. Justify the difference or drop it.

>and even passed unscathed through a Working Group Last Call (an
>argument you are fond of using when it suits your purpose).

Charles, if "passed last call" doesn't apply to changes you want to make,
then I find it particularly hypocritical of you to apply it when you don't
want to remove some pet idea of yours. It doesn't matter if it past a
"last call", it still requires justification. "Because we want to" isn't
good enough. (And I could point out a lot of things that you've changed
unilaterally after multiple last calls, so don't play this game with me. )

I've seen nobody supporting keeping the requirement. I've seen replies 
agreeing it should be removed. Everyone other than you seems to think it 
ought to go. Either justify it (and convince us) or lose it.

>Perhaps it is the same interoperability issue that justifies defining
>"postmaster" in RFC 2821 with a "MUST".

I doubt it, since "postmaster" is an email management issue and "abuse"  
isn't. And since RFC2142 didn't think it was an issue. Either justify the
change or remove it.

>It is related to fighting security
>issues, and breaches of security count as "harm" in my book.

What a load of poppycock. Not having abuse@FQDN as a valid address has 
nothing to do with "security issues". It neither creates nor prevents 
them, your high-sounding gobbldygook notwithstanding.

You can justify neither the mandate nor the difference from RFC2142. If 
the process were operating correctly, that would mean the mandate would 
dissappear. In USEFOR, it means that you'll leave it because you can. I'd 
call that an abuse of the editor's position.

There is no interoperability issue, your security issue is a farce, you 
cannot come up with anything more serious than something like "idiots 
won't be able to complain unless we hold their tiny little hands and tell 
them explicitely where to complain to". That's not an interoperability 
issue justifying an RFC2119 mandate, nor is it an issue serious enough to 
justify overriding RFC2142. You can't figure out what a "top level domain" 
is and can't comprehend sending an abuse report to several places at once 
just to make sure it gets through. THAT certainly isn't an 
interoperability issue, and it certainly isn't a "security" issue.

Either come up with something relevant or remove the mandate. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KHo0x5098638 for <[e-mail]>; Wed, 20 Jul 2005 10:50:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KHo0Kn098636 for ietf-usefor-skb; Wed, 20 Jul 2005 10:50:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns2.townisp.com (ns2a.townisp.com [216.195.0.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KHnxjt098621 for <[e-mail]>; Wed, 20 Jul 2005 10:49:59 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns2.townisp.com (Postfix) with ESMTP id E158529927; Wed, 20 Jul 2005 13:49:58 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6KHnvw8002570(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 20 Jul 2005 13:49:57 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6KHnuZu002569(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 20 Jul 2005 13:49:57 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Wed, 20 Jul 2005 13:49:54 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 20 2005 10:31, Charles Lindsey wrote:
> 
> In <[e-mail]> John Stanley <[e-mail]> writes:

> >I'll ask again, but I don't expect you'll answer: what is the
> >interoperability issue that is being created by RFC2142 and solved by your
> >proposed "MUST",
> 
> Perhaps it is the same interoperability issue that justifies defining
> "postmaster" in RFC 2821 with a "MUST". It is related to fighting security
> issues, and breaches of security count as "harm" in my book.

RFC 2821 doesn't *define* postmaster "with a MUST"; it simply states that
a system handling mail via SMTP MUST provide a well-known mailbox as a
means of communication with the operators of that mail-handling system.
It is not itself a security issue, and RFC 2821 section 4.5.1 specifically
permits blocking mail to postmaster under some security-related conditions.

Invoking 2821 is a bad analogy -- 2821 provides for a mailbox on a mail-
handling system.  The analogy for Usenet would be a site-specific newsgroup
rather than a mailbox.  Because of the way news is distributed, that would
not be terribly useful.

You still haven't answered John's question, viz. what is the specific
interoperability issue with RFC 2142?

In addition, requiring Usenet sites -- some of which are not on the
Internet -- to support mail -- a separate set of protocols -- is
questionable, and you have used the "Usenet is not the Internet" argument
when it has suited your purposes.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKp5c091818 for <[e-mail]>; Wed, 20 Jul 2005 09:20:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KGKpuY091817 for ietf-usefor-skb; Wed, 20 Jul 2005 09:20:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKoG5091811 for <[e-mail]>; Wed, 20 Jul 2005 09:20:50 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-195.midband.mdip.bt.net ([81.144.64.195]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42de78dc.f007.2a1 for [e-mail]; Wed, 20 Jul 2005 17:16:28 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6KGCS817558 for [e-mail]; Wed, 20 Jul 2005 17:12:28 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22037
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Ticket status, USEFOR
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 20 Jul 2005 14:22:40 GMT
Lines: 72
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>1021 USEFOR 3.1.5 Newsgroups header ABNF and description needs cleanup
> "Document updated"

I think this is complete technically, but it needs some explanation of
the forbidden components, etc, in a NOTE.

>1029 USEFOR 3.2.2 References: Should comments be a MUST NOT?
> "No consensus"

I thought we had agreed to leave it as SHOULD NOT. Given that we have
accepted "SHOULD NOT generate" for folded Newsgroups, I don't think we can
justify anything stronger here.

>1030 USEFOR general: Backwards compatibility and handling incompatibilities
> "No consensus" - on June 28, I suggested "No change needed".

Agreed.

>1031 USEFOR general: Standard terminology and text
> "No consensus" - on June 28, I suggested "No change needed".

Agreed.

>1032 USEFOR general: Document changes from RFC 1036
> "Text needed" - this section is still blank in -05

There is suitable text in 3.1 of USEPRO, which should probably be moved to
USEFOR (though a couple of items might remain). The reason I say "probably"
is that the related section on "Transitional Arrangements" is less
obviously a USEFOR matter but, having just reviewed it, many of the items
in that are already covered by "do not do this yet" remarks in USEFOR.

>1046 USEFOR 5. MIME boundary security considerations
> "Text needed"

There is some proposed wording in the Security Considerations of USEPRO to
cover this. All we need to do is decide whether to include it. I certainly
think it is a USEPRO matter and, indeed, it would probably be better to
put all the Security Considerations into USEPRO, on the grounds that they
all deal with things that can go wrong with the protocols.

>1047 USEFOR 3.1.6: Path field delimiters and components
> "Text needed"

There is ongoing discussion of section 2.3 of USEPRO which is relevant to
this. The particular issue which interacts with USEFOR is the extent to
which servers should be allowed to identity themselves in the Path using
their IP address. It is agreed that this should be
discouraged/deprecated/whatever, but I think it would be going too far to
forbid it entirely.

I would suggest letting that USEPRO discussion proceed (perhaps it needs a
ticket) and when that is settled the syntax in USEFOR can be adjusted to
match.

>1048 USEFOR 3.2.1 Injection-date syntax
> "Proposed no change"

Agreed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKn9O091809 for <[e-mail]>; Wed, 20 Jul 2005 09:20:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KGKnqQ091808 for ietf-usefor-skb; Wed, 20 Jul 2005 09:20:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKlZ0091802 for <[e-mail]>; Wed, 20 Jul 2005 09:20:48 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-195.midband.mdip.bt.net ([81.144.64.195]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42de78db.f007.2a0 for [e-mail]; Wed, 20 Jul 2005 17:16:27 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6KGCR817554 for [e-mail]; Wed, 20 Jul 2005 17:12:27 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22036
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Using ABNF to document restrictions
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]>
Date: Wed, 20 Jul 2005 13:41:44 GMT
Lines: 52
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Forrest J. Cavalier III" <[e-mail]> writes:

>Harald Tveit Alvestrand wrote:

>> One note to Bruce: Using ABNF to define a restriction on a production 
>> defined in ABNF elsewhere is *not* creating a conflicting definition, 
>> providing the surrounding text makes it clear that's what's happening.

>Good, then someone please propose that surrounding text, and all the places
>it should go.  I assume the text will have the effect that implementors
>will know they can use RFC2822 for parsing and USEFOR for production of
>header fields.

The 1st para of 2.1 seems to give the ground rules.

Then I see, in the various places where changed ABNF is given:

         ...... As a result, this
         document updates the <unstructured> construct from Section
         3.2.6 of [RFC2822] as follows:
[I grant you that would be better said outside of a NOTE]

   The following news header fields extend those defined in section 3.6
   of [RFC2822]:

   ..... this section therefore restricts the syntax
   of <msg-id> as compared to Section 3.6.4 of [RFC2822]. ...

   The References header field is the same as that specified in Section
   3.6.4 of [RFC2822] with the added restrictions detailed in
   Section 2.2 and those listed below:
   ........
   o  Message identifiers MUST be separated with CFWS.

What more do you want?

I have also suggested, to Ken, adding at the end of the new Appendix C:

   NOTE: The effect of all these differences still preserves the property
   that the articles that Usefor permits to be generated form a proper
   subset of the articles that are required to be acceptable to RFC 2822.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKk9p091800 for <[e-mail]>; Wed, 20 Jul 2005 09:20:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KGKkRH091799 for ietf-usefor-skb; Wed, 20 Jul 2005 09:20:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKjV8091785 for <[e-mail]>; Wed, 20 Jul 2005 09:20:46 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-195.midband.mdip.bt.net ([81.144.64.195]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42de78d9.f007.29e for [e-mail]; Wed, 20 Jul 2005 17:16:25 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6KGCUs17569 for [e-mail]; Wed, 20 Jul 2005 17:12:30 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22039
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: NEW: USEFOR 05 3.2.14 Injection-Info
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
Date: Wed, 20 Jul 2005 15:59:41 GMT
Lines: 43
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Ticket please.

There was a thread entitled Injection-Info issues starting at
http://www.imc.org/ietf-usefor/mail-archive/msg00859.html which never
reached any final conclusion. After reviewing that thread, there are just
a couple of points which still seem worth pursuing.

1. A new parameter for authentication identities.

A new paramater of the form

        "authentication" "=" <value>

The "authentication" parameter identifies the "authentication identity" of
the poster, as used by him to identify himself when injecting the article
(using, for example, the SASL mechanism described in
[draft-ietf-nntpext-authinfo-*.txt]).

There was some discussion of this, and Russ at least seemed happy with it.

2. Privacy issues

I propose adding, at the end of 3.2.14:

   The choice between these various <parameter>s has privacy implications.
   These are discussed in [USEAGE].

If you look in 4.1.4 of USEAGE, you will find the text originally written
when we invented the Injection-Info header way back. We had long arguments
about privacy at that time, which resulted in that text. It would be
useful to put a pointer into USEFOR here in order to prevent us going
through all those same arguments again.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKkIx091792 for <[e-mail]>; Wed, 20 Jul 2005 09:20:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KGKkm5091791 for ietf-usefor-skb; Wed, 20 Jul 2005 09:20:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KGKj5V091783 for <[e-mail]>; Wed, 20 Jul 2005 09:20:45 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-195.midband.mdip.bt.net ([81.144.64.195]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42de78d8.f007.29d for [e-mail]; Wed, 20 Jul 2005 17:16:24 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6KGCTg17562 for [e-mail]; Wed, 20 Jul 2005 17:12:29 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22038
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 20 Jul 2005 14:31:05 GMT
Lines: 29
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>Until you justify the CHANGED rules you aren't supposed to just simply
>"write them into the draft". The fact that you repeatedly DO write your 
>own version of rules into the draft is not a feature of this process, it 
>is a bug. 

The CHANGED rules (as you call them) were written into the draft about 5
years ago, and even passed unscathed through a Working Group Last Call (an
argument you are fond of using when it suits your purpose).

>I'll ask again, but I don't expect you'll answer: what is the
>interoperability issue that is being created by RFC2142 and solved by your
>proposed "MUST",

Perhaps it is the same interoperability issue that justifies defining
"postmaster" in RFC 2821 with a "MUST". It is related to fighting security
issues, and breaches of security count as "harm" in my book.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KFIGXa085933 for <[e-mail]>; Wed, 20 Jul 2005 08:18:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KFIGRZ085932 for ietf-usefor-skb; Wed, 20 Jul 2005 08:18:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KFIFEw085918 for <[e-mail]>; Wed, 20 Jul 2005 08:18:15 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id C67EA2991E; Wed, 20 Jul 2005 11:18:14 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6KFIDhd001733(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 20 Jul 2005 11:18:14 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6KFICj0001732(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 20 Jul 2005 11:18:13 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Wed, 20 Jul 2005 11:18:10 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 20 2005 00:47, Frank Ellermann wrote:
> 
> Charles Lindsey wrote:
> 
> > Those words apply to injecting agents only, NOT to all FQDNs
> > in the path as you claimed.
[...]
> > If you want them to apply to all FQDNs in the Path, that is
> > another matter, but it is not what our draft currently says

The specific text (which Charles has snipped) referred to "The prepended
<path-identity>".  As an injection agent doesn't prepend (there is at
injection no Path field) and relaying agents do prepend, I can make no
sense of Charles' comments.

> If you want to talk about the "top level domain" of the FQDN in
> a <path-identity> (A, AAAA, or MX) in conjunction with RfC 2142
> chapter 2 add a general note below the special MUST valid only
> for the injection agent.

If the text is meant to apply to injection agents, then it should
avoid the word "prepend" and its derivatives and should clearly state
that it refers specifically to injection.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KF2vYB083693 for <[e-mail]>; Wed, 20 Jul 2005 08:02:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KF2v1K083692 for ietf-usefor-skb; Wed, 20 Jul 2005 08:02:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KF2uOP083686 for <[e-mail]>; Wed, 20 Jul 2005 08:02:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id D3B6E2994F; Wed, 20 Jul 2005 11:02:55 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6KF2sW5001641(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 20 Jul 2005 11:02:55 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6KF2rA8001640(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 20 Jul 2005 11:02:54 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1048 e.a. (was: #1040 e.a)
Date: Wed, 20 Jul 2005 11:02:51 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 20 2005 03:03, Frank Ellermann wrote:
> 
> >> 1048 USEFOR 3.2.1 Injection-date
> 
> Sorry, I used an incorrect number in the subject.  This beast
> could be a privacy issue:  Some users - posting when they are
> supposed to do something else - intentionally use timestamps
> like 00:00 -0000.  The Injection-Date could defeat these
> efforts.

What privacy issue? "use timestamps" where and for what purpose?
Injection-Date records the time of injection; how precisely is
that a privacy issue?

> Why are there mandatory "security considerations", mandatory
> "IANA considerations", optional "I18N considerations", but no
> "privacy considerations" - is that something we should invent
> for USEFOR ?

Privacy (see definition in BCP 36, a.k.a. RFC 2828) is a
security-related issue.  Privacy issues could be a subsection
of the security considerations section.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KEqYs6082874 for <[e-mail]>; Wed, 20 Jul 2005 07:52:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KEqYDZ082873 for ietf-usefor-skb; Wed, 20 Jul 2005 07:52:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KEqYl5082867 for <[e-mail]>; Wed, 20 Jul 2005 07:52:34 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id E00A829933; Wed, 20 Jul 2005 10:52:32 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6KEqV8v001523(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 20 Jul 2005 10:52:31 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6KEqUj3001522(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 20 Jul 2005 10:52:30 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Date: Wed, 20 Jul 2005 10:52:27 -0400
User-Agent: KMail/1.8.1
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j6KEqYl5082868
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 20 2005 09:01, Harald Tveit Alvestrand wrote:
> 
> --On onsdag, juli 20, 2005 08:50:06 -0400 Bruce Lilly <[e-mail]> 
> wrote:

> > There has been discussion related to conflicts caused by cases of
> > the form where a normative reference defines some ABNF production
> > rule "foo", and our document gives a different ABNF rule named "foo".
> > That is a conflict, one which can be easily resolved by choosing a
> > different rule name.
> 
> Context, your message from July 3 with subject "Required SP" (didn't 
> realize it was from that long ago):
> 
> > 2822 defines the From field (among others) and its syntax.  If
> > you introduce a different syntax for the same thing, you are
> > either trying to alter that syntax or you are introducing a
> > conflict (in this case with a normative reference).  Best to
> > keep the ABNF grammar as defined in 2822, and introduce notes
> > restricting usage of the full syntax where necessary or
> > recommended.
> 
> Given its age, it was not reasonable of me to comment on it as if it was a 
> presently active discussion. Apologies.

No problem -- just that it's difficult to respond out-of-context.

The issue persists in usefor-05:

   from            =  "From:" SP mailbox-list CRLF

That differs from RFC 2822:

from            =       "From:" mailbox-list CRLF

The rule name "from" appears multiple places in RFC 2822; we have no
authority to alter the meaning of RFC 2822.  If there is a good reason
to define ABNF -- and AFAICT there is not as the SP issue can be
handled via an implementation note along the lines suggested by Mark
Crispin -- then simply choose a different rule name so that it does
not conflict with rule names used in references.  E.g. "usefor-from"
or "blurfl".

As earlier noted, "from" is not the only instance of such a conflict.

In this case, I recommend an implementation note rather than renaming
ABNF rules.  The first bullet point in section 2.2 (usefor-05) could
easily be converted into such a note.

Specifically, OLD text:

   o  All agents MUST generate header fields so that at least one space
      immediately follows the ':' separating the header field name and
      the header field body (for compatibility with deployed software).
      News agents MAY accept header fields which do not contain the
      required space.

Suggested NEW text:

Backward Compatibility Requirements

   Some legacy injection agents reject messages which do not have an SP
   character following the colon delimiting a header field name from
   the field body.

Implementation Recommendations

   It is RECOMMENDED that an SP character be the first character of the
   field body for compatibility with legacy injection agents.  Agents
   SHOULD accept messages which do not have an SP character as the first
   character of the field body.  Note that RFC 2822 conformance REQUIRES
   acceptance of such messages.


As the issue does not warrant BCP 14 imperatives (MUST/MUST NOT), I have
suggested keywords appropriate to the (lack of) gravity of the situation.
See
http://www.imc.org/ietf-usefor/2003/Feb/0554.html
http://www.imc.org/ietf-usefor/2003/Feb/0493.html
http://www.imc.org/ietf-usefor/2003/Feb/0486.html

With the above text, the contradictory ABNF can be removed, avoiding
conflict with a normative reference and with the first paragraph of
section 1.6, and reducing the document length.

Incidentally, usefor-05 also has a self-contradictory definition of "from"
in section 3.1.2:

   from            =  "Date:" SP date-time CRLF

Was the ABNF checked prior to submission of usefor-05 as required by
the ID-Checklist (note that issues with ABNF have previously been noted
and a request was made that ABNF be checked)?  If so, what tool was used
for checking, and how was it used? [if all of the ABNF was input to
checking, a failure to flag conflicting definitions would be a serious
flaw in the tool; if only snippets of ABNF were separately checked, then
the ABNF as a whole wasn't really checked]  See:
http://www.ietf.org/ID-Checklist.html
http://www.imc.org/ietf-usefor/mail-archive/msg00742.html

There remain many other instances of conflicts with section 1.6 and with
RFC 2822, e.g. an attempted redefinition of "unstructured" in section 2.2,
redefinition of "message-id", etc.

At this late stage, we really shouldn't have unchecked ABNF, nor should
we expect dozens of individual WG members to manually have to check ABNF
when there are tools available and ABNF is required to be checked prior
to submission of a draft.  We also shouldn't have ABNF or text which
conflicts with section 1.6 first paragraph, and the document editor should
be (and should have been) pushing back hard against suggestions that
conflict with 1.6.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KEOg2u080245 for <[e-mail]>; Wed, 20 Jul 2005 07:24:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KEOgmk080244 for ietf-usefor-skb; Wed, 20 Jul 2005 07:24:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KEOfmr080238 for <[e-mail]>; Wed, 20 Jul 2005 07:24:41 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6FDF61B71; Wed, 20 Jul 2005 16:24:40 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10907-06; Wed, 20 Jul 2005 16:24:38 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9E17F61B4C; Wed, 20 Jul 2005 16:24:37 +0200 (CEST)
Date: Wed, 20 Jul 2005 16:24:37 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: #1083 USEPRO 7.5: Rules for Generating message-ID
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In accordance with the message posted July 4, I've opened the ticket below:

Subject: USEPRO 7.5: Rules for Generating message-ID


In the discussion of ticket #1003, the following message was posted by
Charles Lindsey:

 In <[e-mail]> "Forrest J. Cavalier III"
<[e-mail]> writes:

 >Harald Tveit Alvestrand wrote:

 >> Two significant issues seem to have been raised with the proposed
>> resolution:
 >>
 >> - What needs to be said in order to "play nice" with the $altz
 "control."
 >> convention (for instance, not to outlaw it)
>> - Whether, and if so where, the requirement not to go mess with
 other
 >> people's namespace needs to be documented

 >If 1003 is makred resolved, what ticket(s) list the above two items?

 I think those items are more USEPRO or UESEAGE.

 It is not completely clear where this should go, but since generating
message-IDs are considered part of what a posting agent does (I
think), this ticket lists section 7.5 of USEPRO. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KD1VP5058673 for <[e-mail]>; Wed, 20 Jul 2005 06:01:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KD1VKt058672 for ietf-usefor-skb; Wed, 20 Jul 2005 06:01:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KD1TQD058652 for <[e-mail]>; Wed, 20 Jul 2005 06:01:30 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2AD161B71 for <[e-mail]>; Wed, 20 Jul 2005 15:01:28 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09648-10 for <[e-mail]>; Wed, 20 Jul 2005 15:01:26 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BA8461B4C for <[e-mail]>; Wed, 20 Jul 2005 15:01:24 +0200 (CEST)
Date: Wed, 20 Jul 2005 15:01:24 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Re: ABNF remarks hidden in message "Admin: I'm back....."
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On onsdag, juli 20, 2005 08:50:06 -0400 Bruce Lilly <[e-mail]> 
wrote:

> On Tue July 19 2005 03:50, Harald Tveit Alvestrand wrote:
>
>> One note to Bruce: Using ABNF to define a restriction on a production
>> defined in ABNF elsewhere is *not* creating a conflicting definition,
>> providing the surrounding text makes it clear that's what's happening.
>>
>> If you find a value that is accepted by the "restrictive" ABNF and not
>> accepted by the "less restrictive" ABNF, you have reason for an
>> objection.  But not just because ABNF is used to define the restriction.
>
> It would help if you would provide some context for your comments.
>
> I can recall no discussion based on "just because ABNF is used".
>
> There has been discussion related to conflicts caused by cases of
> the form where a normative reference defines some ABNF production
> rule "foo", and our document gives a different ABNF rule named "foo".
> That is a conflict, one which can be easily resolved by choosing a
> different rule name.

Context, your message from July 3 with subject "Required SP" (didn't 
realize it was from that long ago):

> 2822 defines the From field (among others) and its syntax.  If
> you introduce a different syntax for the same thing, you are
> either trying to alter that syntax or you are introducing a
> conflict (in this case with a normative reference).  Best to
> keep the ABNF grammar as defined in 2822, and introduce notes
> restricting usage of the full syntax where necessary or
> recommended.

Given its age, it was not reasonable of me to comment on it as if it was a 
presently active discussion. Apologies.

                           Harald






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KCoDcJ054377 for <[e-mail]>; Wed, 20 Jul 2005 05:50:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KCoDdN054376 for ietf-usefor-skb; Wed, 20 Jul 2005 05:50:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KCoDSK054367 for <[e-mail]>; Wed, 20 Jul 2005 05:50:13 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 02274299D3; Wed, 20 Jul 2005 08:50:11 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6KCoAKP000952(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 20 Jul 2005 08:50:11 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6KCo9sV000951(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 20 Jul 2005 08:50:10 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: ABNF remarks hidden in message "Admin: I'm back....."
Date: Wed, 20 Jul 2005 08:50:06 -0400
User-Agent: KMail/1.8.1
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <601268628DF794B0F045EA97@[10.61.81.74]>
In-Reply-To: <601268628DF794B0F045EA97@[10.61.81.74]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 19 2005 03:50, Harald Tveit Alvestrand wrote:

> One note to Bruce: Using ABNF to define a restriction on a production 
> defined in ABNF elsewhere is *not* creating a conflicting definition, 
> providing the surrounding text makes it clear that's what's happening.
> 
> If you find a value that is accepted by the "restrictive" ABNF and not 
> accepted by the "less restrictive" ABNF, you have reason for an objection. 
> But not just because ABNF is used to define the restriction.

It would help if you would provide some context for your comments.

I can recall no discussion based on "just because ABNF is used".

There has been discussion related to conflicts caused by cases of
the form where a normative reference defines some ABNF production
rule "foo", and our document gives a different ABNF rule named "foo".
That is a conflict, one which can be easily resolved by choosing a
different rule name.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K8McZN059114 for <[e-mail]>; Wed, 20 Jul 2005 01:22:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K8Mcdu059113 for ietf-usefor-skb; Wed, 20 Jul 2005 01:22:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K8Malp059090 for <[e-mail]>; Wed, 20 Jul 2005 01:22:37 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv9qO-00076a-0f for [e-mail]; Wed, 20 Jul 2005 10:22:20 +0200
Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 10:22:20 +0200
Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 10:22:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1048 e.a.
Date:  Wed, 20 Jul 2005 10:19:49 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

 [Injection-Date and privacy]
> This may, however, be something that fits better in USEAGE.

Yes, or in USEPRO, it's already very complex.  I just saw that
the rules for Injection-Info and Injection-Date are different:

The former is replaced in the case of a "reinjection", but the
latter is kept as is.  So joining them into one header field
won't work if the "reinjection" rules are correct.  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K7F0Mc032737 for <[e-mail]>; Wed, 20 Jul 2005 00:15:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K7F05k032736 for ietf-usefor-skb; Wed, 20 Jul 2005 00:15:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K7ExbX032723 for <[e-mail]>; Wed, 20 Jul 2005 00:14:59 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC88861B7A; Wed, 20 Jul 2005 09:14:58 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05860-03; Wed, 20 Jul 2005 09:14:56 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8ED8D61B73; Wed, 20 Jul 2005 09:14:56 +0200 (CEST)
Date: Wed, 20 Jul 2005 09:14:55 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1048 e.a. (was: #1040 e.a)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On onsdag, juli 20, 2005 09:03:46 +0200 Frank Ellermann 
<[e-mail]> wrote:

>
>>> 1048 USEFOR 3.2.1 Injection-date
>
> Sorry, I used an incorrect number in the subject.  This beast
> could be a privacy issue:  Some users - posting when they are
> supposed to do something else - intentionally use timestamps
> like 00:00 -0000.  The Injection-Date could defeat these
> efforts.
>
> Why are there mandatory "security considerations", mandatory
> "IANA considerations", optional "I18N considerations", but no
> "privacy considerations" - is that something we should invent
> for USEFOR ?

We can certainly add whatever sections we feel that the document needs.
This may, however, be something that fits better in USEAGE.

                       Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K7DluG032238 for <[e-mail]>; Wed, 20 Jul 2005 00:13:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K7Dlpf032237 for ietf-usefor-skb; Wed, 20 Jul 2005 00:13:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K7DkkG032223 for <[e-mail]>; Wed, 20 Jul 2005 00:13:47 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1257061B7A for <[e-mail]>; Wed, 20 Jul 2005 09:13:46 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05860-02 for <[e-mail]>; Wed, 20 Jul 2005 09:13:44 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2321361B73 for <[e-mail]>; Wed, 20 Jul 2005 09:13:44 +0200 (CEST)
Date: Wed, 20 Jul 2005 09:13:43 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: About relationship to other standards - 2142 in particular
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

One word to remember:

ALL IETF standards are "voluntary compliance".
People choose to implement them (or not).

When we put into our document a statement saying "you MUST implement (some 
other standard)", we are creating a dependency - saying that you must 
implement this other (voluntary) standard in order to fully implement this 
standard. At times, that's a very tough requirement; at other times, it 
means that in order to conform to our standards, multiple departments have 
to change how the deploying enterprise operates - this may be even harder 
than an implementation mandate.

We should do that sparingly, and only if it is necessary for 
interoperability.

It is quite a bit less worrisome if we put statements into the text saying 
things like "If you want to do this particular thing, you can look at RFC 
xxxx for a way to do it" - that's not making the other thing something our 
standards depend on.

In the case of "abuse@", my personal opinion is that our documents should 
document the "news@" and "usenet@" convention (because these are *ours*), 
and only say something like "For other conventions on standard addresses to 
contact for abuse, you might like to consult RFC 2142".

Don't create dependencies and requirements where you don't have to.

                        Harald


 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K74jaR028224 for <[e-mail]>; Wed, 20 Jul 2005 00:04:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K74jdb028223 for ietf-usefor-skb; Wed, 20 Jul 2005 00:04:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K74hmF028209 for <[e-mail]>; Wed, 20 Jul 2005 00:04:44 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv8dH-0006G4-1O for [e-mail]; Wed, 20 Jul 2005 09:04:43 +0200
Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 09:04:43 +0200
Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 09:04:43 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1048 e.a. (was: #1040 e.a)
Date:  Wed, 20 Jul 2005 09:03:46 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

>> 1048 USEFOR 3.2.1 Injection-date

Sorry, I used an incorrect number in the subject.  This beast
could be a privacy issue:  Some users - posting when they are
supposed to do something else - intentionally use timestamps
like 00:00 -0000.  The Injection-Date could defeat these
efforts.

Why are there mandatory "security considerations", mandatory
"IANA considerations", optional "I18N considerations", but no
"privacy considerations" - is that something we should invent
for USEFOR ?
                         Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K6ibCh020232 for <[e-mail]>; Tue, 19 Jul 2005 23:44:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K6ibHZ020230 for ietf-usefor-skb; Tue, 19 Jul 2005 23:44:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K6iZ8F020214 for <[e-mail]>; Tue, 19 Jul 2005 23:44:36 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv8JV-0004Jv-N8 for [e-mail]; Wed, 20 Jul 2005 08:44:17 +0200
Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 08:44:17 +0200
Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 08:44:17 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  #1040 e.a. (was: Ticket status, USEFOR)
Date:  Wed, 20 Jul 2005 08:43:11 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> 1021 USEFOR 3.1.5 Newsgroups header ABNF and description
> needs cleanup  "Document updated"

=> resolved

> 1029 USEFOR 3.2.2 References: Should comments be a MUST NOT?
>  "No consensus"

It's now good enough - I'd still prefer the <msg-id-list> ABNF,
but that's not essential.

> 1042 USEFOR 3.1.5: Newsgroups folding? "Document updated"

=> resolved

> 1048 USEFOR 3.2.1 Injection-date syntax  "Proposed no change"

ACK.  I'm not exactly sure why we don't add this timestamp to
the Injection-Info, maybe because 2822 <date-time> is messy (?)
It would fit nicely between the <path-identity> and the first
semicolon introducing the parameters.

> 1053 USEFOR 2.1 Relationship to RFC 2822
>  "Proposed no change".

Maybe needed in #1028 (3.1.2), otherwise => resolved.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K6LBDc010967 for <[e-mail]>; Tue, 19 Jul 2005 23:21:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K6LBBe010966 for ietf-usefor-skb; Tue, 19 Jul 2005 23:21:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K6L9Ca010950 for <[e-mail]>; Tue, 19 Jul 2005 23:21:10 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv7wy-00023L-7c for [e-mail]; Wed, 20 Jul 2005 08:21:00 +0200
Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 08:21:00 +0200
Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 08:21:00 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  #1028 orig-date (was: Ticket status, USEFOR)
Date:  Wed, 20 Jul 2005 08:19:34 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:
 
> 1028 USEFOR 3.1.2 Date: What zones should be on the MUST
> accept list?  "Document updated"

Yes, but it shouldn't say "from" instead of "orig-date" ;-)

And IIRC we wanted to mention 2.2 _and_ 2.1 in 3.1.2, not
only 2.2, because the "forget obs-" info is in 2.1, and
the "but accept GMT" part of 3.1.2 needs this 2.1 detail.

How about adding an example below the <orig-date> syntax ?  

| This is an example for the deprecated GMT syntax, GMT is
| interpreted as +0000, compare [RFC2822] chapter 4.3: 
|
|      Date: Wed, 20 Jul 2005, 22:33:44 GMT

                         Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K5n1Xf098285 for <[e-mail]>; Tue, 19 Jul 2005 22:49:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K5n10u098284 for ietf-usefor-skb; Tue, 19 Jul 2005 22:49:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K5mxid098271 for <[e-mail]>; Tue, 19 Jul 2005 22:49:00 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv7Rn-0007VB-3G for [e-mail]; Wed, 20 Jul 2005 07:48:47 +0200
Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 07:48:47 +0200
Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 07:48:47 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  #1046 MIME boundary issues (was: Ticket status, USEFOR)
Date:  Wed, 20 Jul 2005 07:46:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> we should aim for getting those 13 tickets to "Text accepted"
> or "No change needed" state within the next 3 weeks, so that
> Ken can generate a hopefully-final USEFOR-06 and submit it 
> for publication just after the IETF meeting.

> 1046 USEFOR 5. MIME boundary security considerations
>  "Text needed"

My last complete proposal was in
<http://mid.gmane.org/[e-mail]>

Bruce proposed another aspect in
<http://article.gmane.org/gmane.ietf.usenet.format/28940>

But that went in the (IMHO) wrong direction of "there's
no real problem unless implementors are too naive":

<http://article.gmane.org/gmane.ietf.usenet.format/28953>

It is a real problem, because 2231 didn't want to screw
the boundaries, so nobody expects this, naive or not.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K5NNtP083018 for <[e-mail]>; Tue, 19 Jul 2005 22:23:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K5NNq8083017 for ietf-usefor-skb; Tue, 19 Jul 2005 22:23:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K5NMVn083004 for <[e-mail]>; Tue, 19 Jul 2005 22:23:22 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv73A-0005JE-OP for [e-mail]; Wed, 20 Jul 2005 07:23:20 +0200
Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 07:23:20 +0200
Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 07:23:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Anyone coming to Paris?
Date:  Wed, 20 Jul 2005 07:22:23 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Message-ID:  <[e-mail]>
References:  <0867368628EB81E154305889@B50854F0A9192E8EC6CDA126> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Scott Hollenbeck wrote:

>> Anyone coming?
> I'll be there.

That could be really interesting, some "NOT RECOMMENDED SHOULD"
engineers at a Paris bar eager to explain the finer points of
conflicting "SHOULD NOT RECOMMENDED" mail experiments... <beg>

Anyway, I hope that you'll find more amusing topics than [FWS],
<id-domain>, or crazy comments between references.  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K4rcI0072317 for <[e-mail]>; Tue, 19 Jul 2005 21:53:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6K4rcbI072316 for ietf-usefor-skb; Tue, 19 Jul 2005 21:53:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6K4rX8j072297 for <[e-mail]>; Tue, 19 Jul 2005 21:53:36 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv6Ya-0002xz-88 for [e-mail]; Wed, 20 Jul 2005 06:51:44 +0200
Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 06:51:43 +0200
Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 20 Jul 2005 06:51:43 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Wed, 20 Jul 2005 06:47:35 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 46
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-132.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> Those words apply to injecting agents only, NOT to all FQDNs
> in the path as you claimed.

I've found the new usepro-04 two hours after that article, and
now I've deleted the old usepro-03.

> If you want them to apply to all FQDNs in the Path, that is
> another matter, but it is not what our draft currently says

Yes, s/,ideally, should/SHOULD/ in 2.3 case 1 (A or AAAA).

Dito in 2.3 case 3 (MX) just to get consistent requirements:
s/MUST be "mailable"/SHOULD be "mailable" (see below)/

> And if you want that MUST for injecting agents to be demoted
> to SHOULD, that too is another matter.

I'd remove the complete convoluted clause at the end of 2.3:

- and if the agent offers its services to the general public
- the form "abuse@" that FQDN MUST also be available, unless a
- more specific complaints address has been provided in a
- <complainto-param> of an Injection-Info header field (F-3.2.14).

Nobody knows to whom it offers its services.  What you want is
apparently "specify your abuse address in a <complaintto-param>
or support abuse@ if you are an injection agent".  IMO we don't
need this conditional and unclear abuse@ MUST, because there's
already an unconditional news@ / usenet@ MUST in the first part
of this statement:

| For an injecting agent prepending to a Path header field
| (7.2.2), the <path-identity> MUST be option 1 or 3 and the
| FQDN MUST be mailable,

Just truncate it there.  It's repeated in 7.2.2 clause 10, no
chance to get it wrong.

If you want to talk about the "top level domain" of the FQDN in
a <path-identity> (A, AAAA, or MX) in conjunction with RfC 2142
chapter 2 add a general note below the special MUST valid only
for the injection agent.
                        Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JNneto049496 for <[e-mail]>; Tue, 19 Jul 2005 16:49:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JNne5s049495 for ietf-usefor-skb; Tue, 19 Jul 2005 16:49:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JNnddN049483 for <[e-mail]>; Tue, 19 Jul 2005 16:49:39 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6JNnXjo088295 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 19 Jul 2005 16:49:33 -0700 (PDT)
Date: Tue, 19 Jul 2005 16:49:33 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Ticket status, USEFOR
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Henry Spencer <henry@xxxxxxxxxxxxx>:

>This is not broken and there is no need to fix it. 

That is your opinion.

> As has been discussed
>many times before, a news standard necessarily imposes a number of extra
>constraints, beyond what RFC2822 demands. 

Of course it does. Nobody has said otherwise. Please respond to the 
point being made and not an irrelevant non-issue.

We've been quite honest about listing those differences in the section
dealing with the References header in USEFOR.  Nobody wanted to list this
as a difference, so it is a bit late to claim that obviously this is a
difference. We chose NOT to impose that constraint when we defined the
header field; don't tell me that it's normal to impose constraints that we
chose not to, or that we HAVE imposed constraints when we explicitely 
chose not to. (I suggested a simple change to the relevant section to 
solve the problem; it was dismissed. That's an explicit statement that the 
difference does not exist.)

We cannot have it both ways. Either it is optional or it is mandatory. 
USEFOR-05 says "see RFC2822", and RFC2822 says "optional". If USEPRO 
contradicts this, then USEPRO is wrong. I would have said that USEFOR was 
wrong, but consensus says it is right. Now I say "be consistent". 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JKx51P034758 for <[e-mail]>; Tue, 19 Jul 2005 13:59:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JKx544034757 for ietf-usefor-skb; Tue, 19 Jul 2005 13:59:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JKx4f6034729 for <[e-mail]>; Tue, 19 Jul 2005 13:59:04 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6JKwwZp084388 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 19 Jul 2005 13:58:59 -0700 (PDT)
Date: Tue, 19 Jul 2005 13:58:58 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Ticket status, USEFOR
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue, 19 Jul 2005, Harald Tveit Alvestrand wrote:

> > Since USEFOR is apparently further ahead in adoption, it would seem that
> > USEPRO is the one standard that is out-of-line. Please nudge it back.
> 
> John,
> 
> the following text is the text that I declared consensus on, and is 
> currently in -05:

It is also in USEPRO-04, so it seems that duplicating efforts is not a 
significant goal of this group. In fact, there are a lot of definitions 
appearing in USEPRO that also appear in USEFOR. 

The definition of a term cannot make something mandatory that has already 
been declared to be optional. A definition tells us what something IS, not 
what it contains. It is the References header section that tells us about 
the use of the References header, and nothing there says anything about 
any difference from RFC2822 as far as optional or mandatory. So the part 
of the "definition" that tells us what  followup contains is contradicted 
by existing standard and our own draft.

> You're reopening a closed subject (#1008) without bringing new technical 
> information. Please don't.

I do not need your permission to point out patent contradictions between 
our draft efforts and existing standard, nor to suggest the means to 
correct those contradictions. If this group does not remove patent 
contradictions when they are pointed out, then it is silly to claim that 
the issue is closed. 

I'll also point out that you are apparently letting this "ticket system" 
drive the discussion here, instead of having the discussion here drive the 
ticket system. Please don't. Either this is the place we discuss USEFOR 
issues or we ought to disband and let the ticket system rule. Before you 
let the ticket system rule, however, it needs to be fixed so it either has 
a valid cert or doesn't use a cert at all.

So, as far as the drafts are concerned, the "normative text" in USEFOR-05
that relates to the References header tells us that the header field is
optional. Since we've gotten "consensus" on that text, then anything we 
produce that says otherwise is clearly not consensus. Or else the 
consensus is to be contradictory, which is amazingly dumb.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JKQ8Lc032110 for <[e-mail]>; Tue, 19 Jul 2005 13:26:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JKQ81N032109 for ietf-usefor-skb; Tue, 19 Jul 2005 13:26:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JKQ7OL032099 for <[e-mail]>; Tue, 19 Jul 2005 13:26:07 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3802261B73; Tue, 19 Jul 2005 22:26:04 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23348-02; Tue, 19 Jul 2005 22:26:02 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E56C61B71; Tue, 19 Jul 2005 22:26:02 +0200 (CEST)
Date: Tue, 19 Jul 2005 22:26:00 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: Ticket status, USEFOR
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On tirsdag, juli 19, 2005 09:53:15 -0700 John Stanley <[e-mail]> 
wrote:

>
>
> Since there is no "ticket" covering the References header section of 05,
> I'll assume that it currently contains the text that this group wants.
>
> If so, then someone needs to open a ticket on USEPRO, since USEPRO is
> trying to claim that the References header is mandatory in followups when
> RFC2822 tells us it is optional, to the point that it even tells us how
> to  deal with replies that don't contain one.
>
> Since USEFOR is apparently further ahead in adoption, it would seem that
> USEPRO is the one standard that is out-of-line. Please nudge it back.

John,

the following text is the text that I declared consensus on, and is 
currently in -05:

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

You're reopening a closed subject (#1008) without bringing new technical 
information. Please don't.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JKCdiC030593 for <[e-mail]>; Tue, 19 Jul 2005 13:12:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JKCdOp030592 for ietf-usefor-skb; Tue, 19 Jul 2005 13:12:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JKCcHL030585 for <[e-mail]>; Tue, 19 Jul 2005 13:12:39 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j6JKCbtS000652; Tue, 19 Jul 2005 16:12:37 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j6JKCVEo000651; Tue, 19 Jul 2005 16:12:31 -0400 (EDT)
Date: Tue, 19 Jul 2005 16:12:31 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: Ticket status, USEFOR
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue, 19 Jul 2005, John Stanley wrote:
> If so, then someone needs to open a ticket on USEPRO, since USEPRO is 
> trying to claim that the References header is mandatory in followups when 
> RFC2822 tells us it is optional, to the point that it even tells us how to 
> deal with replies that don't contain one. 

This is not broken and there is no need to fix it.  As has been discussed
many times before, a news standard necessarily imposes a number of extra
constraints, beyond what RFC2822 demands. 

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JGrOpn009641 for <[e-mail]>; Tue, 19 Jul 2005 09:53:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JGrORr009640 for ietf-usefor-skb; Tue, 19 Jul 2005 09:53:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JGrNGO009619 for <[e-mail]>; Tue, 19 Jul 2005 09:53:23 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6JGrF89062391 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 19 Jul 2005 09:53:18 -0700 (PDT)
Date: Tue, 19 Jul 2005 09:53:15 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Ticket status, USEFOR
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Since there is no "ticket" covering the References header section of 05, 
I'll assume that it currently contains the text that this group wants.

If so, then someone needs to open a ticket on USEPRO, since USEPRO is 
trying to claim that the References header is mandatory in followups when 
RFC2822 tells us it is optional, to the point that it even tells us how to 
deal with replies that don't contain one. 

Since USEFOR is apparently further ahead in adoption, it would seem that 
USEPRO is the one standard that is out-of-line. Please nudge it back.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JGj2d4008737 for <[e-mail]>; Tue, 19 Jul 2005 09:45:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JGj26G008736 for ietf-usefor-skb; Tue, 19 Jul 2005 09:45:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JGj1LW008720 for <[e-mail]>; Tue, 19 Jul 2005 09:45:02 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6JGitFm066208 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 19 Jul 2005 09:44:56 -0700 (PDT)
Date: Tue, 19 Jul 2005 09:44:55 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Exactly. If we write the "simple minded rules" into the draft, then
>everybody will know exactly what is expected of them.

Until you justify the CHANGED rules you aren't supposed to just simply
"write them into the draft". The fact that you repeatedly DO write your 
own version of rules into the draft is not a feature of this process, it 
is a bug. 

I'll ask again, but I don't expect you'll answer: what is the
interoperability issue that is being created by RFC2142 and solved by your
proposed "MUST", and what is the reason for changing how RFC2142 has had
it spelled out for so long? RFC2142 is explicit in contradicting you; now 
YOU be explicit in justifying the contradiction.

Until you can answer those questions satisfactorily, you have no right to 
just "write into the draft" whatever new rules you think ought to exist.

And no, your assertion that idiots won't know how to send complaints
unless we change the rules is simply ludicrous. And this pretense that
"it's written in the draft" is a justification for the change is even more
ludicrous.

>And if you want that MUST for injecting agents to be demoted to SHOULD,
>that too is another matter.

NO! If you want the specific rules of RFC2142 changed it is YOUR 
responsibility to justify it, not everyone else's to keep you from doing 
it.

Alexey, Harald, prime example of unilateral changes that meet no other 
criteria than "Charles thinks it ought to be this way". Is this how the 
draft editor is supposed to operate, and does it please you? (Those 
are rhetorical questions, I already know the answer.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JDwL0g093543 for <[e-mail]>; Tue, 19 Jul 2005 06:58:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JDwLZV093542 for ietf-usefor-skb; Tue, 19 Jul 2005 06:58:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.epix.net (pine.epix.net [199.224.64.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JDwKoR093536 for <[e-mail]>; Tue, 19 Jul 2005 06:58:20 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-108-207-102-pppoe.dsl.hrbg.epix.net [216.108.207.102]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j6JDw9gt009351 for <[e-mail]>; Tue, 19 Jul 2005 09:58:14 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 19 Jul 2005 09:58:08 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Using ABNF to document restrictions
References: <601268628DF794B0F045EA97@[10.61.81.74]>
In-Reply-To: <601268628DF794B0F045EA97@[10.61.81.74]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.135
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> One note to Bruce: Using ABNF to define a restriction on a production 
> defined in ABNF elsewhere is *not* creating a conflicting definition, 
> providing the surrounding text makes it clear that's what's happening.

Good, then someone please propose that surrounding text, and all the places
it should go.  I assume the text will have the effect that implementors
will know they can use RFC2822 for parsing and USEFOR for production of
header fields.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JCmYJ1067980 for <[e-mail]>; Tue, 19 Jul 2005 05:48:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JCmYXq067979 for ietf-usefor-skb; Tue, 19 Jul 2005 05:48:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JCmX30067947 for <[e-mail]>; Tue, 19 Jul 2005 05:48:33 -0700 (PDT) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:64.134.95.36]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 19 Jul 2005 08:48:28 -0400 id 005A81B4.42DCF69C.00000CF2
From: "Scott Hollenbeck" <[e-mail]>
To: "'Harald Tveit Alvestrand'" <[e-mail]>, [e-mail]
Subject: RE: Anyone coming to Paris?
Date: Tue, 19 Jul 2005 08:48:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <0867368628EB81E154305889@B50854F0A9192E8EC6CDA126>
Thread-Index: AcWMQ3q/2MLvozUQS36XFVwwusGRHwAG03Bw
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[e-mail]] 
> Sent: Tuesday, July 19, 2005 5:22 AM
> To: [e-mail]
> Subject: Anyone coming to Paris?
> 
> 
> Folks,
> Alexey and I will be at the Paris IETF.
> We have not scheduled an USEFOR meeting, since it appears 
> that most people 
> won't be there.
> 
> But if someone else is there, we could schedule a "bar BOF" 
> or informal 
> get-together.
> 
> Anyone coming?

I'll be there.

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBl2s8045051 for <[e-mail]>; Tue, 19 Jul 2005 04:47:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JBl2x8045050 for ietf-usefor-skb; Tue, 19 Jul 2005 04:47:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from afir ([12.16.56.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBl0gp044996 for <[e-mail]>; Tue, 19 Jul 2005 04:47:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mail pickup service by afir with Microsoft SMTPSVC; Tue, 19 Jul 2005 07:47:54 -0400
Received: from mail64.messagelabs.com ([216.82.255.51]) by afir with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Jul 2005 16:07:15 -0400
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-15.tower-64.messagelabs.com!1121717152!55538347!1
X-StarScan-Version: 5.4.15; banners=-,-,anspach.com
X-Originating-IP: [132.151.6.71]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MIME_BOUND_NEXTPART,NO_REAL_NAME
Received: (qmail 14915 invoked from network); 18 Jul 2005 20:05:53 -0000
Received: from megatron.ietf.org (132.151.6.71) by server-15.tower-64.messagelabs.com with SMTP; 18 Jul 2005 20:05:53 -0000
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubcx-0007ya-Rr; Mon, 18 Jul 2005 15:50:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubco-0007s2-Ut for [e-mail]; Mon, 18 Jul 2005 15:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10322 for <[e-mail]>; Mon, 18 Jul 2005 15:50:00 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duc6I-0006Wn-G9 for [e-mail]; Mon, 18 Jul 2005 16:20:31 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubcn-0002FX-Dv; Mon, 18 Jul 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 18 Jul 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-usefor-usepro-04.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=subscribe>
X-OriginalArrivalTime: 18 Jul 2005 20:07:15.0390 (UTC) FILETIME=[4AC85DE0:01C58BD4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: News Article Architecture and Protocols
	Author(s)	: C. Lindsey
	Filename	: draft-ietf-usefor-usepro-04.txt
	Pages		: 56
	Date		: 2005-7-18
	
This Draft, together with its companion draft [USEFOR], are
   intended as standards track documents, together obsoleting RFC
   1036, which itself dates from 1987.

   This Standard defines the architecture of Netnews systems and
   specifies the requirements to be met by software which originates,
   distributes, stores and displays Netnews articles.

   Since the 1980s, Usenet has grown explosively, and many Internet and
   non-Internet sites now participate. In addition, the Netnews
   technology is now in widespread use for other purposes.

   Backward compatibility has been a major goal of this endeavour, but
   where this standard and earlier documents or practices conflict, this
   standard should be followed. In most such cases, current practice is
   already compatible with these changes.

   A companion Current Best Practice document [USEAGE], addressing
   requirements which are present for Social rather than Normative
   reasons is in preparation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-usefor-usepro-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


______________________________________________________________________
This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com.
______________________________________________________________________
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-04.txt

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

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBLOvW036219 for <[e-mail]>; Tue, 19 Jul 2005 04:21:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JBLOsv036217 for ietf-usefor-skb; Tue, 19 Jul 2005 04:21:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBLMvK036200 for <[e-mail]>; Tue, 19 Jul 2005 04:21:23 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-139.midband.mdip.bt.net ([81.144.67.139]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42dce231.c15b.14 for [e-mail]; Tue, 19 Jul 2005 12:21:21 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6JBCG427071 for [e-mail]; Tue, 19 Jul 2005 12:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22014
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <yVrvDZBbYD2CFAE$@highwayman.com>  <[e-mail]> <[e-mail]>
Date: Tue, 19 Jul 2005 10:27:23 GMT
Lines: 27
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Richard Clayton <[e-mail]> writes:

>and for the others surely we're hoping that there will be another header
>line specifically relating to where to send complaints to assist them  ?

We are indeed "hoping", but that is not to say that news injectors will
actually do it :-( . Maybe they will say "no need to provide a
mail-complaints-to parameter in Injection-Info because we already provide
abuse@ the standard place (or what we _think_ is the standard place)".

>well, since most of the simple-minded rules -- such as you propose --
>seem to work just fine for your exotic example, I don't see that this is
>something to sweat over

Exactly. If we write the "simple minded rules" into the draft, then
everybody will know exactly what is expected of them.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBLO8g036220 for <[e-mail]>; Tue, 19 Jul 2005 04:21:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JBLOZk036218 for ietf-usefor-skb; Tue, 19 Jul 2005 04:21:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JBLMIt036201 for <[e-mail]>; Tue, 19 Jul 2005 04:21:23 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-139.midband.mdip.bt.net ([81.144.67.139]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42dce232.c15b.15 for [e-mail]; Tue, 19 Jul 2005 12:21:22 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6JBCG127075 for [e-mail]; Tue, 19 Jul 2005 12:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22015
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 19 Jul 2005 10:32:13 GMT
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>>> news@ and usenet@ MUST work for all FQDNs in the path,
>>> that's what usepro-03 says, and I think it's fine, and
>>> for abuse@ see RfC 2142.

>> No, USEPRO DOESN'T say that. It says "ideally should", not
>> MUST.
>                                vvvv            vvvvvvvv
>| The prepended <path-identity> MUST be an FQDN mailable
>| address (a-5.6.2).
>                                ^^^^            ^^^^^^^^
>Lines 1605 and 1606 in draft-ietf-usefor-usepro-03.txt

Those words apply to injecting agents only, NOT to all FQDNs in the path
as you claimed.

If you want them to apply to all FQDNs in the Path, that is another
matter, but it is not what our draft currently says, nor has said for
several years past.

And if you want that MUST for injecting agents to be demoted to SHOULD,
that too is another matter.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JA0QbW005078 for <[e-mail]>; Tue, 19 Jul 2005 03:00:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6JA0Qxk005077 for ietf-usefor-skb; Tue, 19 Jul 2005 03:00:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6JA0Puj005063 for <[e-mail]>; Tue, 19 Jul 2005 03:00:26 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47C5E61B73 for <[e-mail]>; Tue, 19 Jul 2005 12:00:25 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15778-05 for <[e-mail]>; Tue, 19 Jul 2005 12:00:21 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBF4A61B71 for <[e-mail]>; Tue, 19 Jul 2005 12:00:20 +0200 (CEST)
Date: Tue, 19 Jul 2005 12:00:19 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Ticket status, USEFOR
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

There are still 13 open tickets on the USEFOR document (and 2 on USEPRO).

I think we should aim for getting those 13 tickets to "Text accepted" or 
"No change needed" state within the next 3 weeks, so that Ken can generate 
a hopefully-final USEFOR-06 and submit it for publication just after the 
IETF meeting. This should then be able to go to WG Last Call.

The outstanding USEFOR tickets (in numeric order) are:

1003 USEFOR 3.1.3 - Cleanup ABNF for msg-id
 "Document updated"

1021 USEFOR 3.1.5 Newsgroups header ABNF and description needs cleanup
 "Document updated"

1028 USEFOR 3.1.2 Date: What zones should be on the MUST accept list?
 "Document updated"

1029 USEFOR 3.2.2 References: Should comments be a MUST NOT?
 "No consensus"

1030 USEFOR general: Backwards compatibility and handling incompatibilities
 "No consensus" - on June 28, I suggested "No change needed".

1031 USEFOR general: Standard terminology and text
 "No consensus" - on June 28, I suggested "No change needed".

1032 USEFOR general: Document changes from RFC 1036
 "Text needed" - this section is still blank in -05

1042 USEFOR 3.1.5: Newsgroups folding?
 "Document updated"

1046 USEFOR 5. MIME boundary security considerations
 "Text needed"

1047 USEFOR 3.1.6: Path field delimiters and components
 "Text needed"

1048 USEFOR 3.2.1 Injection-date syntax
 "Proposed no change"

1050 USEFOR 3.2.11: Xref field for local use only?
 "No change needed" - I've closed this one, so it'll be gone from my
  next list.

1052 USEFOR general: Document changes from RFC 2822
 "Text proposed" - appendix C of -05.

1053 USEFOR 2.1 Relationship to RFC 2822
 "Proposed no change".

For the ones in "Document updated", Ken has indicated in the tracker that 
the chairs should judge whether the issues are closed or not.

When discussing the specific issues, please include the number in the 
subject header, and STAY ON TOPIC.

Thanks!

                        Harald




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6J9N30Y091370 for <[e-mail]>; Tue, 19 Jul 2005 02:23:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6J9N3pb091369 for ietf-usefor-skb; Tue, 19 Jul 2005 02:23:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6J9N2Fp091357 for <[e-mail]>; Tue, 19 Jul 2005 02:23:02 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCDE261AF5 for <[e-mail]>; Tue, 19 Jul 2005 11:23:01 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15157-09 for <[e-mail]>; Tue, 19 Jul 2005 11:22:58 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 94A4D61B71 for <[e-mail]>; Tue, 19 Jul 2005 11:22:58 +0200 (CEST)
Date: Tue, 19 Jul 2005 11:21:41 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Anyone coming to Paris?
Message-ID: <0867368628EB81E154305889@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Folks,
Alexey and I will be at the Paris IETF.
We have not scheduled an USEFOR meeting, since it appears that most people 
won't be there.

But if someone else is there, we could schedule a "bar BOF" or informal 
get-together.

Anyone coming?

                     Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6J8EGiv066295 for <[e-mail]>; Tue, 19 Jul 2005 01:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6J8EGJw066294 for ietf-usefor-skb; Tue, 19 Jul 2005 01:14:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6J8EFQc066279 for <[e-mail]>; Tue, 19 Jul 2005 01:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32AF861B71 for <[e-mail]>; Tue, 19 Jul 2005 10:14:14 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14397-06 for <[e-mail]>; Tue, 19 Jul 2005 10:14:09 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B6FF61B6E for <[e-mail]>; Tue, 19 Jul 2005 10:14:09 +0200 (CEST)
Date: Tue, 19 Jul 2005 09:50:50 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Admin: I'm back.....
Message-ID: <601268628DF794B0F045EA97@[10.61.81.74]>
X-Mailer: Mulberry/4.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I see that usefor-05 has arrived in my absence, along with 150 messages, 
none of which seem to talk about -05.

I'm currently catching up on mail, and will try to go back to resolving 
tickets when I'm caught up.

One note to Bruce: Using ABNF to define a restriction on a production 
defined in ABNF elsewhere is *not* creating a conflicting definition, 
providing the surrounding text makes it clear that's what's happening.

If you find a value that is accepted by the "restrictive" ABNF and not 
accepted by the "less restrictive" ABNF, you have reason for an objection. 
But not just because ABNF is used to define the restriction.

                       Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IJo29Z037230 for <[e-mail]>; Mon, 18 Jul 2005 12:50:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6IJo2pb037229 for ietf-usefor-skb; Mon, 18 Jul 2005 12:50:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IJo1Gk037222 for <[e-mail]>; Mon, 18 Jul 2005 12:50:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubcn-0002FX-Dv; Mon, 18 Jul 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-usefor-usepro-04.txt 
Message-Id: <[e-mail]>
Date: Mon, 18 Jul 2005 15:50:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: News Article Architecture and Protocols
	Author(s)	: C. Lindsey
	Filename	: draft-ietf-usefor-usepro-04.txt
	Pages		: 56
	Date		: 2005-7-18
	
This Draft, together with its companion draft [USEFOR], are
   intended as standards track documents, together obsoleting RFC
   1036, which itself dates from 1987.

   This Standard defines the architecture of Netnews systems and
   specifies the requirements to be met by software which originates,
   distributes, stores and displays Netnews articles.

   Since the 1980s, Usenet has grown explosively, and many Internet and
   non-Internet sites now participate. In addition, the Netnews
   technology is now in widespread use for other purposes.

   Backward compatibility has been a major goal of this endeavour, but
   where this standard and earlier documents or practices conflict, this
   standard should be followed. In most such cases, current practice is
   already compatible with these changes.

   A companion Current Best Practice document [USEAGE], addressing
   requirements which are present for Social rather than Normative
   reasons is in preparation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-usefor-usepro-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-04.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IJh7K1036379 for <[e-mail]>; Mon, 18 Jul 2005 12:43:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6IJh7xR036378 for ietf-usefor-skb; Mon, 18 Jul 2005 12:43:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IJh6Mh036365 for <[e-mail]>; Mon, 18 Jul 2005 12:43:06 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6IJgtFm061451 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 18 Jul 2005 12:43:00 -0700 (PDT)
Date: Mon, 18 Jul 2005 12:42:55 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

More assertion, no justification.

>OK, so the three people who have answered have given three different
>answers:   
>which does tend to support my contention that some clear statement in our
>draft is needed.

It does nothing of the sort. I'd be as correct in saying that the sun came
up in the east this morning which supports my claim that you need to
justify a difference from RFC2142. You do need to justify the change, but
the sun has nothing to do with it. The fact that three people can come up
with three addresses that do the same thing is somehow a "Bad Thing" that
causes an interoperability issue that YOU need to step down from on high
to fix?

(And, in fact, my first answer included one of the other's, so there are
really only two answers, and the shotgun approach I suggested first would
succeed no matter what.)

>So there is one respected institution that totally ignores RFC 2142 :-( .

The correct response to ignorance of the law is not to create more useless 
laws. But how do we know it ignores RFC2142? I've not sent an email to 
abuse@ the top level domain and had it bounce. Have you?

>Looks like that one might "go unanswered" :-) .

Do you see anything in any RFC that says that a valid email mailbox must 
result in "answers" for it to be valid? I do not. Your comment is 
worthless. Less than worthless, because you intended it to cloud the 
issue. 

>But for an innocent who does not even recognise that it is an academic
>institution, and that "cs" stands for "computer science", and who has 
>never heard of 'whois' or 'nslookup', you need a simple rule that anybody 
>can apply, such as "look at what appears in the Injection-Info, or in 
>front of the 'POSTED' in the Path, and stick "abuse@" in front of it.

And I could argue that someone who is so ignorant of anything to do with 
the net ought not to be wasting anyone's time sending abuse reports. If 
the problem appears in USENET, then there will be an excess of cluefull
people who can deal with the problem. We don't need ten million abuse 
reports for one article, thank you very much. 

RFC2142 covers the issue. RFC 2142 explicitely says the opposite from what
you want. Either you can justify the override of RFC2142 or you cannot.
Please make some attempt at some time soon; these repeated assertions
about what ought to be said are not sufficient.

>OTOH, for an injecting agent, USEPRO currently says you MUST create such
>an MX record (or have the A record listen to port 25), and you MUST
>provide abuse@ as well as the other two (modulo a complaints address in
>Injection-Info).

Yes, we know what you want USEPRO to say currently. (I'm curious how you
"modulo" a complaints address with anything else. Do you mean "sans"? The
two words are different.) When do you think you might get around to some
justification for this difference from existing standards and RFC2119
mandate? Perhaps this week?

>So we are stronger there, because RFC 2142 only requires abuse@ at the
>"top level domain" (figuring out which is the "top level domain" is left
>as an exercise for the student).

Yes, we know what RFC2142 says. It's not much of an exercise. It's really 
not that hard. It's really not an interoperability issue, and it isn't 
even a critical issue, especially for ignoramuses who don't understand 
internet addresses anyway.

>Non-net-savvy people should only need "abuse@", and then only to the
>injecting agent. With double stamping, they would see:
>
>    ...!new15@xxxxxxxxxxxxxx!nntpserver.com!POSTED!not-for-mail

No, they wouldn't. 

> ...so you simply tell them to "use whatever is to the left of the 
>'POSTED'".

Gee, do you really think it is so hard to understand that "nntpserver.com" 
is a "top level domain" and that RFC2142 applies to that top level 
domain? I don't. Do you imagine that many people would bother sending 
abuse reports to "abuse@com", and then, if they do, that they would be 
smart enough to have anything worth listening to if abuse@com even was a 
valid address?

Quick poll: how many people think that someone would send an abuse report 
to abuse@xxxxxxxxxxxxxxx, and if they did, that it would contain any 
information any clued person would bother caring about?

And you do you really not understand that paths can be so trivially forged 
that you cannot trust anything more than what your own server puts there? 
When you see a path like:

	a!b!c!d!e!God-almighty-himself!POSTED!not-for-mail

do you REALLY believe that God Almighty Himself has posted this article? I
mean, it IS "just to the left of the POSTED".



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IHO1A5021897 for <[e-mail]>; Mon, 18 Jul 2005 10:24:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6IHO129021896 for ietf-usefor-skb; Mon, 18 Jul 2005 10:24:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IHNxhf021879 for <[e-mail]>; Mon, 18 Jul 2005 10:24:00 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DuZKh-00066f-01 for [e-mail]; Mon, 18 Jul 2005 19:23:11 +0200
Received: from du-042-047.access.de.clara.net ([213.221.65.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 18 Jul 2005 19:23:10 +0200
Received: from nobody by du-042-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 18 Jul 2005 19:23:10 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Mon, 18 Jul 2005 19:20:54 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-042-047.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>> news@ and usenet@ MUST work for all FQDNs in the path,
>> that's what usepro-03 says, and I think it's fine, and
>> for abuse@ see RfC 2142.

> No, USEPRO DOESN'T say that. It says "ideally should", not
> MUST.
                                vvvv            vvvvvvvv
| The prepended <path-identity> MUST be an FQDN mailable
| address (a-5.6.2).
                                ^^^^            ^^^^^^^^
Lines 1605 and 1606 in draft-ietf-usefor-usepro-03.txt

> ...![e-mail]!nntpserver.com!POSTED!not-for-mail

There's no "@" in a <path-identity> let alone in a host name.
This Internet-Draft will expire in August 2005.  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IElst1000487 for <[e-mail]>; Mon, 18 Jul 2005 07:47:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6IElsks000486 for ietf-usefor-skb; Mon, 18 Jul 2005 07:47:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IElrFu000478 for <[e-mail]>; Mon, 18 Jul 2005 07:47:54 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-33.mail.demon.net with esmtp (Exim 4.42) id 1DuWuF-000FLo-AW; Mon, 18 Jul 2005 14:47:44 +0000
Message-ID: <[e-mail]>
Date: Mon, 18 Jul 2005 15:46:11 +0100
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]> <yVrvDZBbYD2CFAE$@highwayman.com> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <3+3$+vU$77$ZhOKLU+f+dO3Ovp>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes

>OK, so the three people who have answered have given three different
>answers:
>    [e-mail]
>    [e-mail]
>    [e-mail]

all of which will reach within one hop of whoever should deal with the
problem...

>which does tend to support my contention that some clear statement in our
>draft is needed.

which suggests that not a lot is broken here

>>reason to be found at:
>
>><URL:http://www.ripe.net/whois?form_type=simple&full_query_string=&searc
>>htext=130.88.198.1>
>
>   Please email '[e-mail]' for ALL cases of abuse or security
>   issues. Emails to admin or tech individuals regarding abuse may go
>   unanswered.
>
>So there is one respected institution that totally ignores RFC 2142 :-( .

they would only be "ignoring" 2142 if they failed to accept email to
abuse@   and I see nothing in their statement suggesting this to be so

>>>>But the correct answer is [e-mail]. Because they are in charge of
>>>>the man.ac.uk domain, duh! 
>
>Looks like that one might "go unanswered" :-) .
>
>>often pointless complaining to the domain owner, start with the "ISP"
>
>Ah! But which IS the "ISP" (I might argue for [e-mail] on that basis)?

I would expect that to work just fine as well ... there's an MX record
for ac.uk (goes to a JANET host, and I expect Rodney and his team would
be able to use their local knowledge of the *.ac.uk space to work out a
suitable contact in Manchester to discuss the problem with).  So this
isn't broken either

>>Good Game!   does it have a point ?
>
>I think the point is that net-savvy people, such as you find on this list,
>can probably look at a domain name and form a pretty good opinion, just
>from their general knowledge of the conventions used to construct domain
>names, as to what is going on (and even then, they come up with different
>results).

and for the others surely we're hoping that there will be another header
line specifically relating to where to send complaints to assist them  ?

>But for an innocent who does not even recognise that it is an academic
>institution, and that "cs" stands for "computer science", and who has never
>heard of 'whois' or 'nslookup', you need a simple rule that anybody can
>apply, such as "look at what appears in the Injection-Info, or in front of
>the 'POSTED' in the Path, and stick "abuse@" in front of it.

well, since most of the simple-minded rules -- such as you propose --
seem to work just fine for your exotic example, I don't see that this is
something to sweat over

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQtvAs5oAxkTY1oPiEQIapACgrhDuB5keHWZuFIgwjvc2h17ZXx0An3py
G/UJ/Tppgz0rmwZmWv1DSIHt
=WT37
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IE3EZw094735 for <[e-mail]>; Mon, 18 Jul 2005 07:03:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6IE3DmB094732 for ietf-usefor-skb; Mon, 18 Jul 2005 07:03:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IE3Cr6094714 for <[e-mail]>; Mon, 18 Jul 2005 07:03:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-232.midband.mdip.bt.net ([81.144.72.232]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42dbb676.10d22.58f for [e-mail]; Mon, 18 Jul 2005 15:02:30 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6IDteF13015; Mon, 18 Jul 2005 14:55:40 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22008
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <yVrvDZBbYD2CFAE$@highwayman.com>
Date: Mon, 18 Jul 2005 10:53:16 GMT
Lines: 79
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <yVrvDZBbYD2CFAE$@highwayman.com> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes

>>>>Supposing that RFC 2142 is all you have to
>>>>go on, 

>that's hardly realistic is it,

Indeed not, but some here are arguing that RFC 2142 should be followed to
the letter, and the RFC 2142 on its own contains all that needs to be said
on the subject.

What I am trying to show is that RFC 2142 does not give clear enough
directions, and therefore it would be better to decide exctly what we want
and write that into our draft.


>>>>and supposing that there is no mail-complaints-to in the
>>>>Injection-Info, what then is the correct abuse@ address to use, and why?

>myself, I'd use

>        [e-mail]

OK, so the three people who have answered have given three different
answers:
    [e-mail]
    [e-mail]
    [e-mail]
which does tend to support my contention that some clear statement in our
draft is needed.

>reason to be found at:

><URL:http://www.ripe.net/whois?form_type=simple&full_query_string=&searc
>htext=130.88.198.1>

   Please email '[e-mail]' for ALL cases of abuse or security
   issues. Emails to admin or tech individuals regarding abuse may go
   unanswered.

So there is one respected institution that totally ignores RFC 2142 :-( .

>>>But the correct answer is [e-mail]. Because they are in charge of
>>>the man.ac.uk domain, duh! 

Looks like that one might "go unanswered" :-) .

>often pointless complaining to the domain owner, start with the "ISP"

Ah! But which IS the "ISP" (I might argue for [e-mail] on that basis)?


>Good Game!   does it have a point ?

I think the point is that net-savvy people, such as you find on this list,
can probably look at a domain name and form a pretty good opinion, just
from their general knowledge of the conventions used to construct domain
names, as to what is going on (and even then, they come up with different
results).

But for an innocent who does not even recognise that it is an academic
institution, and that "cs" stands for "computer science", and who has never
heard of 'whois' or 'nslookup', you need a simple rule that anybody can
apply, such as "look at what appears in the Injection-Info, or in front of
the 'POSTED' in the Path, and stick "abuse@" in front of it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IE3Eq8094737 for <[e-mail]>; Mon, 18 Jul 2005 07:03:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6IE3Efx094734 for ietf-usefor-skb; Mon, 18 Jul 2005 07:03:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IE3A1T094711 for <[e-mail]>; Mon, 18 Jul 2005 07:03:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-232.midband.mdip.bt.net ([81.144.72.232]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42dbb674.10d22.58d for [e-mail]; Mon, 18 Jul 2005 15:02:28 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6IDuBi13023; Mon, 18 Jul 2005 14:56:11 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22010
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 18 Jul 2005 11:17:22 GMT
Lines: 40
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:
> 
>> the sort of "double stamping" that could be useful, since it
>> singles out the domain at which you guarantee that "news@",
>> "usenet@" and "abuse@" will work.

>It doesn't:  news@ and usenet@ MUST work for all FQDNs in the
>path, that's what usepro-03 says, and I think it's fine, and
>for abuse@ see RfC 2142.

No, USEPRO DOESN'T say that. It says "ideally should", not MUST.

It is RFC 2142 that says "MUST" (or rather "must") for that case.

It is is "double stamped", with

    ...![e-mail]!nntpserver.com!...

then a net savvy person would see at once that "[e-mail]" was
the address to use (I think usenet@ and news@ are for net-savvy people).

Non-net-savvy people should only need "abuse@", and then only to the
injecting agent. With double stamping, they would see:

    ...![e-mail]!nntpserver.com!POSTED!not-for-mail

so you simply tell them to "use whatever is to the left of the 'POSTED'".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IE3E6e094736 for <[e-mail]>; Mon, 18 Jul 2005 07:03:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6IE3E6J094733 for ietf-usefor-skb; Mon, 18 Jul 2005 07:03:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6IE3A6d094710 for <[e-mail]>; Mon, 18 Jul 2005 07:03:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-232.midband.mdip.bt.net ([81.144.72.232]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42dbb675.10d22.58e for [e-mail]; Mon, 18 Jul 2005 15:02:29 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6IDt1c13007; Mon, 18 Jul 2005 14:55:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22009
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 18 Jul 2005 11:06:36 GMT
Lines: 35
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Steve Walker <[e-mail]> writes:

>I have over 30 news servers and each one has it's own path stamp. 
>  Are you saying that Usepro says I have to setup email on every 
>sub-domain?  If so that's just stupid and not likely to happen. 
>Email works for the top level domain and that's more than enough 
>considering there is also an X-Abuse-Report header stamped.

What USEPRO currenty says is that all 30 "ideally should" be mailable
(what USEPRO eventually says is what we are currently discussing).

OTOH, RFC 2142 says that you "MUST" (or "must") create 30 MX records
pointing to some suitable SMTP host (that is for news@ and usenet@).

So we are weaker there.

OTOH, for an injecting agent, USEPRO currently says you MUST create such
an MX record (or have the A record listen to port 25), and you MUST
provide abuse@ as well as the other two (modulo a complaints address in
Injection-Info).

So we are stronger there, because RFC 2142 only requires abuse@ at the
"top level domain" (figuring out which is the "top level domain" is left
as an exercise for the student).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FNPOn1017548 for <[e-mail]>; Fri, 15 Jul 2005 16:25:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6FNPOlH017547 for ietf-usefor-skb; Fri, 15 Jul 2005 16:25:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FNPM98017539 for <[e-mail]>; Fri, 15 Jul 2005 16:25:22 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtZYR-0007y3-GQ for [e-mail]; Sat, 16 Jul 2005 01:25:15 +0200
Received: from 212.82.251.27 ([212.82.251.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 16 Jul 2005 01:25:15 +0200
Received: from nobody by 212.82.251.27 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 16 Jul 2005 01:25:15 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Sat, 16 Jul 2005 01:24:17 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.27
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Steve Walker wrote:

> I have over 30 news servers and each one has it's own path
> stamp.   Are you saying that Usepro says I have to setup
> email on every sub-domain?  If so that's just stupid and not
> likely to happen.

With 30 servers you're also able to setup 2 * 30 aliases and
maybe 30 MX records, if that's how you like it.

> Email works for the top level domain and that's more than
> enough considering there is also an X-Abuse-Report header
> stamped.

| The prepended <path-identity> MUST be an FQDN  mailable
| address (a-5.6.2).

That's hopelessly obsolete, I lost track with the changes
for the <path-identity>, but IIRC that part was undisputed.

Nobody says that you'd need 30 smtpds to do it.  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FMJiNI012802 for <[e-mail]>; Fri, 15 Jul 2005 15:19:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6FMJiUj012801 for ietf-usefor-skb; Fri, 15 Jul 2005 15:19:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FMJhso012794 for <[e-mail]>; Fri, 15 Jul 2005 15:19:44 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1DtYWy-000EKy-8L for [e-mail]; Fri, 15 Jul 2005 22:19:42 +0000
Message-ID: <yVrvDZBbYD2CFAE$@highwayman.com>
Date: Fri, 15 Jul 2005 23:18:03 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <7$7$+rl377$alNKLEyc+d+z+Np>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes

>>>Supposing that RFC 2142 is all you have to
>>>go on, 

that's hardly realistic is it, there's lots of ways of working these
things out

>>>and supposing that there is no mail-complaints-to in the
>>>Injection-Info, what then is the correct abuse@ address to use, and why?

myself, I'd use

        [e-mail]

reason to be found at:

<URL:http://www.ripe.net/whois?form_type=simple&full_query_string=&searc
htext=130.88.198.1>

the IP address having come from a recent DNS check

>>But the correct answer is [e-mail]. Because they are in charge of
>>the man.ac.uk domain, duh! 

often pointless complaining to the domain owner, start with the "ISP"

>>And if they've delegated to anyone below them,
>>they know who and can do something about it.

looking upwards rather than down is usually wiser

>OK, I am going to wait until I see what Frank thinks is the correct answer
>before responding (and there is still time for others to play).

Good Game!   does it have a point ?

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQtg2G5oAxkTY1oPiEQLz/gCeORwKEH2dzsGAULesWqETkNdCky8AoPm/
QbfWyLe65ITv3lvvj2dnEb07
=fHRm
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FMHnhX012666 for <[e-mail]>; Fri, 15 Jul 2005 15:17:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6FMHnGp012665 for ietf-usefor-skb; Fri, 15 Jul 2005 15:17:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nibble.net (mail.nibble.net [64.74.111.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FMHmqj012659 for <[e-mail]>; Fri, 15 Jul 2005 15:17:48 -0700 (PDT) (envelope-from [e-mail])
Received: from [64.74.225.50] (unverified [64.74.225.50])  by griffin.nibble.net (Nibble Mail V2.3) with ESMTP id 22726649  for multiple; Fri, 15 Jul 2005 17:17:48 -0500
Message-ID: <[e-mail]>
Date: Fri, 15 Jul 2005 17:27:32 -0500
From: Steve Walker <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Frank Ellermann <[e-mail]>
CC: [e-mail]
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann wrote:
> Charles Lindsey wrote:
>  
> 
>>the sort of "double stamping" that could be useful, since it
>>singles out the domain at which you guarantee that "news@",
>>"usenet@" and "abuse@" will work.
> 
> 
> It doesn't:  news@ and usenet@ MUST work for all FQDNs in the
> path, that's what usepro-03 says, and I think it's fine, and
> for abuse@ see RfC 2142.
>                             Bye, Frank

I have over 30 news servers and each one has it's own path stamp. 
  Are you saying that Usepro says I have to setup email on every 
sub-domain?  If so that's just stupid and not likely to happen. 
Email works for the top level domain and that's more than enough 
considering there is also an X-Abuse-Report header stamped.

Steve.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FLlXsD010278 for <[e-mail]>; Fri, 15 Jul 2005 14:47:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6FLlXqW010277 for ietf-usefor-skb; Fri, 15 Jul 2005 14:47:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FLlW9q010269 for <[e-mail]>; Fri, 15 Jul 2005 14:47:32 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtY1i-0005NJ-LB for [e-mail]; Fri, 15 Jul 2005 23:47:22 +0200
Received: from 212.82.251.27 ([212.82.251.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 15 Jul 2005 23:47:22 +0200
Received: from nobody by 212.82.251.27 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 15 Jul 2005 23:47:22 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Fri, 15 Jul 2005 23:46:56 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.27
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 
> the sort of "double stamping" that could be useful, since it
> singles out the domain at which you guarantee that "news@",
> "usenet@" and "abuse@" will work.

It doesn't:  news@ and usenet@ MUST work for all FQDNs in the
path, that's what usepro-03 says, and I think it's fine, and
for abuse@ see RfC 2142.
                            Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FLfIgc009676 for <[e-mail]>; Fri, 15 Jul 2005 14:41:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6FLfIVT009674 for ietf-usefor-skb; Fri, 15 Jul 2005 14:41:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FLfGB8009666 for <[e-mail]>; Fri, 15 Jul 2005 14:41:16 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtXvV-0004aQ-05 for [e-mail]; Fri, 15 Jul 2005 23:40:57 +0200
Received: from 212.82.251.27 ([212.82.251.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 15 Jul 2005 23:40:56 +0200
Received: from nobody by 212.82.251.27 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 15 Jul 2005 23:40:56 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Fri, 15 Jul 2005 23:38:58 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 49
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=iso-8859-1
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.27
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 =

> Suppose you have an article which, as evident from its Path
> or its Injection-Info, was injected by
 =

>         wapping.cs.man.ac.uk
 =

> You want to complain about it. Supposing that RFC 2142 is all
> you have to go on, and supposing that there is no
> mail-complaints-to in the Injection-Info, what then is the
> correct abuse@ address to use, and why?

Now, as 2142 says, there MAY be [e-mail] =


OTOH I'm an RFCI-fan (not alway, but often), and therefore
I'd check `rxwhois -a wapping.cs.man.ac.uk` (-a for "abuse"):

wapping.cs.man.ac.uk not found at .rfc-ignorant.org or .multi.surbl.org
whois -h whois.abuse.net wapping.cs.man.ac.uk
[e-mail] (for cs.man.ac.uk)
[e-mail] (for cs.man.ac.uk)

Without rxwhois I'd try `nslookup -q=3Dns wapping.cs.man.ac.uk`:

[...]
| Autorisierte Antworten k=F6nnen gefunden werden in:
| cs.man.ac.uk
[...]

So that also says [e-mail]

> what is the "top level domain" of the relevant organization?

What you get with nslookup -q=3Dns (otherwise you are already at
the "top level domain").  Not exactly straight forward, but it
is the rfc-ignorant.org listing policy for its abuse zone, and
for a _manual_ complaint I want a clear way for an escalation
up to ICANN's WDPRS (whois data problem report system) if it's
a gTLD (not in this ac.uk example).

But I'd avoid to waste time with an [e-mail],
because I couldn't submit it to RFCI.

                          Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FINJcl091401 for <[e-mail]>; Fri, 15 Jul 2005 11:23:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6FINJic091400 for ietf-usefor-skb; Fri, 15 Jul 2005 11:23:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FINIQp091394 for <[e-mail]>; Fri, 15 Jul 2005 11:23:18 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-68-210.midband.mdip.bt.net ([81.144.68.210]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42d7ff14.1065.41a for [e-mail]; Fri, 15 Jul 2005 19:23:16 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6FIL8607462; Fri, 15 Jul 2005 19:21:08 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22001
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 15 Jul 2005 13:23:41 GMT
Lines: 32
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>You want to complain about it. Supposing that RFC 2142 is all you have to
>>go on, and supposing that there is no mail-complaints-to in the
>>Injection-Info, what then is the correct abuse@ address to use, and why?

>If I were completely ignorant, I'd try: [e-mail]. If
>that bounces, [e-mail]. If that bounces, [e-mail]. If
>that bounces, a traceroute to wapping and an email to the admin contact
>for the site upstream from the first man.ac.uk telling them they have a
>client who is in violation of RFCs for the network and that they ought to
>be cut off until they play by the rules.

>But the correct answer is [e-mail]. Because they are in charge of
>the man.ac.uk domain, duh! And if they've delegated to anyone below them,
>they know who and can do something about it.

OK, I am going to wait until I see what Frank thinks is the correct answer
before responding (and there is still time for others to play).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EI2o20061599 for <[e-mail]>; Thu, 14 Jul 2005 11:02:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EI2oFt061598 for ietf-usefor-skb; Thu, 14 Jul 2005 11:02:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EI2n0M061582 for <[e-mail]>; Thu, 14 Jul 2005 11:02:49 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6EI2h89017566 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 14 Jul 2005 11:02:44 -0700 (PDT)
Date: Thu, 14 Jul 2005 11:02:43 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>You want to complain about it. Supposing that RFC 2142 is all you have to
>go on, and supposing that there is no mail-complaints-to in the
>Injection-Info, what then is the correct abuse@ address to use, and why?

If I were completely ignorant, I'd try: [e-mail]. If
that bounces, [e-mail]. If that bounces, [e-mail]. If
that bounces, a traceroute to wapping and an email to the admin contact
for the site upstream from the first man.ac.uk telling them they have a
client who is in violation of RFCs for the network and that they ought to
be cut off until they play by the rules.

But the correct answer is [e-mail]. Because they are in charge of
the man.ac.uk domain, duh! And if they've delegated to anyone below them,
they know who and can do something about it.

It really ain't that hard, Charles. 

Can you justify a mandate over and above RFC2142 or not? If so, please do.
If no, remove it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EGEl2x049803 for <[e-mail]>; Thu, 14 Jul 2005 09:14:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EGElQJ049802 for ietf-usefor-skb; Thu, 14 Jul 2005 09:14:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EGEkBR049779 for <[e-mail]>; Thu, 14 Jul 2005 09:14:47 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-73-100.midband.mdip.bt.net ([81.144.73.100]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42d68f75.5faf.354 for [e-mail]; Thu, 14 Jul 2005 17:14:45 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6EDIUe20231; Thu, 14 Jul 2005 14:18:30 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21997
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 14 Jul 2005 10:18:36 GMT
Lines: 42
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:
> 
>> RFC 2142 says that "only the organization's top level domain
>> [is] required to be valid", but since it nowhere defines what
>> is meant by "top level domain", that tells us precisely
>> nothing.

>It's defined in RfC 2181 chapter 6 "zone cut" and chapter 7
>"SOA RRs", and you normally should get it get by something
>like `nslookup -q=ns a.b.example.com`

Right. I just downloaded RFC 2181, and it is an interesting read. However,
it is of no help in the present discussion, because there are usually
several zone cuts in a given FQDN. You cannot require an ordinary user to
be familiar with the minutiae of the DNS system before he can complain to
an abuse@ address.

Here is an example:

Suppose you have an article which, as evident from its Path or its
Injection-Info, was injected by

	wapping.cs.man.ac.uk

You want to complain about it. Supposing that RFC 2142 is all you have to
go on, and supposing that there is no mail-complaints-to in the
Injection-Info, what then is the correct abuse@ address to use, and why?
Or, to put it another way, what is the "top level domain" of the relevant
organization?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EGEltC049794 for <[e-mail]>; Thu, 14 Jul 2005 09:14:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EGEl0w049793 for ietf-usefor-skb; Thu, 14 Jul 2005 09:14:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EGEjFS049771 for <[e-mail]>; Thu, 14 Jul 2005 09:14:46 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-73-100.midband.mdip.bt.net ([81.144.73.100]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42d68f75.5faf.353 for [e-mail]; Thu, 14 Jul 2005 17:14:45 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6EDI0v20225; Thu, 14 Jul 2005 14:18:00 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21998
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Thu, 14 Jul 2005 10:47:01 GMT
Lines: 35
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Steve Walker <[e-mail]> writes:

>As a side note of something in the real world, we stamp several 
>path stamps.

Yes, a lot of sites seem to do that, and I asked recently whether we should
write it into out standard that it was allowed (MAY) to do that.

>  We first stamp a non-FQDN name that tells us what 
>reseller the post is from.

Though that adds quite a bit to the length of the Path. The current
proposal for the USEPRO draft is that when you have established where it
is from, you check it against what the previous site put in the Path, and
if it agrees you just use a "!!" as the <path-delimiter> instead of the
usual "!". That saves wasting Path space.

>  We then stamp a general 
>nntpserver.com stamp and then we stamp a machine-specific stamps 
>all the way out.

Yes, that is the sort of "double stamping" that could be useful, since it
singles out the domain at which you guarantee that "news@", "usenet@" and
"abuse@" will work.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EGEkb9049781 for <[e-mail]>; Thu, 14 Jul 2005 09:14:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EGEkJD049780 for ietf-usefor-skb; Thu, 14 Jul 2005 09:14:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EGEjf5049766 for <[e-mail]>; Thu, 14 Jul 2005 09:14:45 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-73-100.midband.mdip.bt.net ([81.144.73.100]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42d68f74.5faf.352 for [e-mail]; Thu, 14 Jul 2005 17:14:44 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6EDHXO20221; Thu, 14 Jul 2005 14:17:33 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21999
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: The old mail archives
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
Date: Thu, 14 Jul 2005 10:48:47 GMT
Lines: 13
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The complete set of mail archives from the old landfield site is now
available at www.imc.org/ietf-usefor.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E2I8qC012133 for <[e-mail]>; Wed, 13 Jul 2005 19:18:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6E2I8KP012132 for ietf-usefor-skb; Wed, 13 Jul 2005 19:18:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nibble.net (mail.nibble.net [64.74.111.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E2I8qL012125 for <[e-mail]>; Wed, 13 Jul 2005 19:18:08 -0700 (PDT) (envelope-from [e-mail])
Received: from [64.74.225.50] (unverified [64.74.225.50])  by griffin.nibble.net (Nibble Mail V2.3) with ESMTP id 22663816  for <[e-mail]>; Wed, 13 Jul 2005 21:18:07 -0500
Message-ID: <[e-mail]>
Date: Wed, 13 Jul 2005 21:27:26 -0500
From: Steve Walker <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: [NNTP] 32 bit article counters
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Please disregard my previous email.  It was sent to the wrong 
list by mistake.  It's an NNTP issue not an Usefor issue.

Steve.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E1Z7d2009083 for <[e-mail]>; Wed, 13 Jul 2005 18:35:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6E1Z7SK009082 for ietf-usefor-skb; Wed, 13 Jul 2005 18:35:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E1Z6B2009073 for <[e-mail]>; Wed, 13 Jul 2005 18:35:06 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6E1YxFm002491 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 13 Jul 2005 18:35:00 -0700 (PDT)
Date: Wed, 13 Jul 2005 18:34:59 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Steve Walker <nntp@xxxxxxxxxxxxxx>:

>If two sites use the same pathstamp one will just change. 

If they notice the problem and don't decide to get into a whizzing match 
over who has rights to the name. 

> ... the only way to solve it ...

I'm not claiming it is a problem that needs solving, I'm just pointing out 
that the talk about "unique" and how we are ensuring that these things are
is just hot air. "SHOULD do a, b, c, or d" doesn't ensure anything, even 
if a, b, c, and d were capable of ensuring uniqueness.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DNxK6C003120 for <[e-mail]>; Wed, 13 Jul 2005 16:59:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DNxKog003119 for ietf-usefor-skb; Wed, 13 Jul 2005 16:59:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nibble.net (mail.nibble.net [64.74.111.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DNxIOi003111 for <[e-mail]>; Wed, 13 Jul 2005 16:59:19 -0700 (PDT) (envelope-from [e-mail])
Received: from [64.74.225.50] (unverified [64.74.225.50])  by griffin.nibble.net (Nibble Mail V2.3) with ESMTP id 22660347  for multiple; Wed, 13 Jul 2005 18:59:17 -0500
Message-ID: <[e-mail]>
Date: Wed, 13 Jul 2005 19:08:35 -0500
From: Steve Walker <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Chris Caputo <[e-mail]>, [e-mail]
Subject: Re: [NNTP] 32 bit article counters
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Chris Caputo wrote:
> But I'd also be fine with an extension being defined which allows for 
> numbers greater than 2^32-1.

I think 64 bit counters is the best solution.  I just had a 
conversation with the software developer of one of the most 
popular commercial news client.  He said his client already uses 
64 bit numbers internally.

> Maybe the fix for now should just be to say that client software should 
> assume a 32-bit wrap-around has occurred if the high article number is 
> more than one less than the low article number.  The would allow servers 
> using more than 32-bits to use a MOD 2^32 to create an standards 
> compliant number.  For that to work we'd also have to adjust the draft 
> to say that zero is a valid article number.

While it may work, it's not perfect.  I think it will be prone to 
problems, as some clients will do it correctly and some won't. 
It is certainly better than the current proposed wording which 
basically says Usenet is over in X years and there is no way to 
fix it without whole new RFC being wrote.

RFC977 had no limit, which personally I think is best, but if 
others feel there MUST be a limit, then at least make it 
something reasonable.  A 32bit limit is not reasonable when you 
consider the big picture.

Steve.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DNlFZu002279 for <[e-mail]>; Wed, 13 Jul 2005 16:47:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DNlFUP002278 for ietf-usefor-skb; Wed, 13 Jul 2005 16:47:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nibble.net (mail.nibble.net [64.74.111.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DNlEGZ002272 for <[e-mail]>; Wed, 13 Jul 2005 16:47:14 -0700 (PDT) (envelope-from [e-mail])
Received: from [64.74.225.50] (unverified [64.74.225.50])  by griffin.nibble.net (Nibble Mail V2.3) with ESMTP id 22660059  for <[e-mail]>; Wed, 13 Jul 2005 18:47:13 -0500
Message-ID: <[e-mail]>
Date: Wed, 13 Jul 2005 18:56:28 -0500
From: Steve Walker <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: New USEPRO path-identity text
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

John Stanley wrote:

> I don't see where we ever demand that they be unique. Certainly not in the 
> section that deals with defining a path-identity in USEFOR. And we 
> certainly don't tell someone how to guarantee they be unique when we say 
> that they only SHOULD use one of the four suggested methods. So neither
> unique by mandate nor unique by design. 

As a side note of something in the real world, we stamp several 
path stamps.  We first stamp a non-FQDN name that tells us what 
reseller the post is from.  We then stamp a general 
nntpserver.com stamp and then we stamp a machine-specific stamps 
all the way out.  I've never had any problems with pathstamp name 
space collisions.  It seems to me that a non-existent problem is 
being solved, IMO, "if it's not broke, don't fix it"...

If two sites use the same pathstamp one will just change.  It 
doesn't break anything outside of the two sites so why should the 
protocol for message format care.  If anything, this is more a an 
NNTP article routing issue and the only way to solve it is to set 
up ICAN style registry of Usenet sites, which I think no one wants.

Steve.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DNUCGs001220 for <[e-mail]>; Wed, 13 Jul 2005 16:30:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DNUCU7001219 for ietf-usefor-skb; Wed, 13 Jul 2005 16:30:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nibble.net (mail.nibble.net [64.74.111.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DNUBRx001213 for <[e-mail]>; Wed, 13 Jul 2005 16:30:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [64.74.225.50] (unverified [64.74.225.50])  by griffin.nibble.net (Nibble Mail V2.3) with ESMTP id 22659639  for <[e-mail]>; Wed, 13 Jul 2005 18:30:11 -0500
Message-ID: <[e-mail]>
Date: Wed, 13 Jul 2005 18:39:27 -0500
From: Steve Walker <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann wrote:

> Sure, but we have news@ and usenet@ and the "complaints-to" or
> whatsitsname parameter of the injection-info, the details of
> the abuse@ mailbox as specified in 2142 are irrelevant for us.

I agree, the (X-)Complaints-To header fills any real world needs. 
  Anything else is redundant and a waste of time.

Steve.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DI1tm0064649 for <[e-mail]>; Wed, 13 Jul 2005 11:01:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DI1tG8064648 for ietf-usefor-skb; Wed, 13 Jul 2005 11:01:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DI1sjn064629 for <[e-mail]>; Wed, 13 Jul 2005 11:01:54 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j6DI1dFm032242 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Jul 2005 11:01:41 -0700 (PDT)
Date: Wed, 13 Jul 2005 11:01:39 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>RFC 2142 states that 'the <ABUSE@xxxxxxxxxxx> address "must" be valid',
>but only where COMPANY is an 'Internet service provider' 

[Note to someone who can do something about it: will you PLEASE get this 
damn archive to STOP modifying the messages it archives? I am getting very 
tired of trying to guess what someone has written just because it looks 
like an email address. Since the address shown above has no dot in the 
RHS, it's not a valid address to start with, so it cannot be mandated. 
The statement as it stands is patently absurd: RFC2142 cannot mandate an
invalid address.]

> If you equate "must" with "MUST" (as you appear to do), 

Still putting words in my mouth, eh, Charles? I equate "must" with a
mandatory action as defined in the dictionary. I equate "MUST" with the
RFC2119 language that requires a reason for a mandate, which YOU have not
yet provided. If you think the two are the same, well, you are wrong. Do
not say that I think the two are the same; that's a lie and that's putting
words in my mouth.

> then what I have written is essentially the same. 

You are patently wrong. RFC2142 tells us that ONLY the top level domain
abuse address "must" be valid. YOU tell us that abuse at the FULLY
QUALIFIED DOMAIN NAME as found in the path-identity MUST be valid. That is
NOT the same, and no amount of nonsense you produce will change the
differences.

>{3. You don't have to provide any abuse address at all if you are not an
>ISP, but that is the same in RFC 2142.}

You clearly don't understand the difference between a rule and an example 
of that rule. RFC2142 says:

   For well known names that are not related to specific protocols, only
   the organization's top level domain name are required to be valid.

It does NOT define "organization" to be "only ISP". It uses an example of 
an ISP. Does your news server reject any article that is not from Jerry 
Schwartz? (That's the example from RFC1036). 

>If the "must" is justified, then the "MUST" is justified.

The "must" in RFC2142 applies only to "the top level domain". The "MUST"  
you are trying to force down our throats applies to the FQDN as entered in
the path-identity. They do NOT apply to the same thing, and thus the
justification for one does not cover the other. YOUR "MUST" is much
stronger than RFC2142's, so YOU bear the burden of justifying it.
Furthermore, RFC2142 is an existing standard that we are not free to
modify; USEPRO is a draft that we are tasked with creating.  And finally,
while RFC2142 says it is encouraged, it explicitely says that an abuse
address at anything lower than the top level domain is NOT required.

What is the interoperability issue that is being solved by your MUST? Why
are you overriding RFC2142?  Either produce the argument supporting your
MUST or remove it. This twisted reading of RFC2142 and ridiculous claims 
that you are saying the same thing are just a waste of our time.

>Look carefully at the position of the word "only" in those two sentences.
>They do NOT say the same thing.

"Only the top level domain is required to be valid" says that the only 
requirement is for the top level domain. Other than "top level domain" has 
no requirement. The "only" is the same.

Now, either produce a valid argument for having any mandate regarding the
FQDN abuse address or remove it.  You want to say "SHOULD", that's a 
different story, and I might agree with you. You want to say "MUST" or 
even "must" and I'll demand a justification for your requirement in light 
of RFC2142. It's your burden when you try to supercede an existing 
standard; either do it or do it not.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DCrgu5020307 for <[e-mail]>; Wed, 13 Jul 2005 05:53:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DCrgk0020306 for ietf-usefor-skb; Wed, 13 Jul 2005 05:53:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DCreFb020292 for <[e-mail]>; Wed, 13 Jul 2005 05:53:41 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-73-181.midband.mdip.bt.net ([81.144.73.181]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42d50ed3.8c4a.fb for [e-mail]; Wed, 13 Jul 2005 13:53:39 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6DAXEv00699 for [e-mail]; Wed, 13 Jul 2005 11:33:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21990
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 13 Jul 2005 10:31:43 GMT
Lines: 64
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>   and if the agent offers its services to the general public the form
>>   "abuse@" that FQDN MUST also be available,

>Not just "should", or "ought to be", but a full-blown MUST. RFC2142 has no
>such requirement. You've lept from "no requirement" to "MUST" and have yet
>to justify it. Why is this a MUST? What part of the news system breaks
>when this isn't true?

RFC 2142 states that 'the <[e-mail]> address "must" be valid',
but only where COMPANY is an 'Internet service provider' (whatever that
is). If you equate "must" with "MUST" (as you appear to do), then what I
have written is essentially the same. No need for something to break to
justify that "must", apparently.

In fact, what I have written is weaker that RFC 2142 in two respects
(assuming for the sake of argument that "example.com" is the "top-level",
however that is defined):

1. You don't have to provide [e-mail] if you choose to identify
your injector as news.example.com in the Path, and provide
[e-mail] instead (though you could equally well have chosen
to identify as example.com in the Path).

2. You don't have to provide [e-mail] if you provide an
alternative (say [e-mail]) in your Injection-Info.

{3. You don't have to provide any abuse address at all if you are not an
ISP, but that is the same in RFC 2142.}



>However poorly written you think another RFC is does NOT create an
>interoperability issue that we need to solve. Justify the MUST or remove 
>it.

If the "must" is justified, then the "MUST" is justified.


>>> The news server 
>>>"a.b.example.com" will insert a.b.example.com into the Path, but RFC2142 
>>>requires that only [e-mail] be valid.

>>No, RFC 2142 says that "only the organization's top level domain [is]
>>required to be valid", 

>Don't contradict me and then quote the RFC that proves I'm correct.

Look carefully at the position of the word "only" in those two sentences.
They do NOT say the same thing.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6D1CUrt005474 for <[e-mail]>; Tue, 12 Jul 2005 18:12:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6D1CUJx005473 for ietf-usefor-skb; Tue, 12 Jul 2005 18:12:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6D1CSTL005465 for <[e-mail]>; Tue, 12 Jul 2005 18:12:29 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DsVnL-0000Zu-St for [e-mail]; Wed, 13 Jul 2005 03:12:15 +0200
Received: from 62.80.58.200 ([62.80.58.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Jul 2005 03:12:15 +0200
Received: from nobody by 62.80.58.200 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Jul 2005 03:12:15 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Wed, 13 Jul 2005 03:10:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 34
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 62.80.58.200
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 
> RFC 2142 says that "only the organization's top level domain
> [is] required to be valid", but since it nowhere defines what
> is meant by "top level domain", that tells us precisely
> nothing.

It's defined in RfC 2181 chapter 6 "zone cut" and chapter 7
"SOA RRs", and you normally should get it get by something
like `nslookup -q=ns a.b.example.com`

The SPF adventure was a kind of brainwashing...  Or in other
words, we don't need to mention abuse@ at all, unless it's a
note with a pointer to RfC 2142.

The MUST [e-mail] is utter dubious, just get rid
of it, or replace it by what 2142 does:

| Note:  Supporting the address abuse@<hostname> is a good
| idea, even if that's only required for the top level domain
| of the authoritative zone, see also [RFC2142] and [RFC2181].

> it is still clear that [e-mail] and
> [e-mail] are both valid, and even encouraged.

Sure, but we have news@ and usenet@ and the "complaints-to" or
whatsitsname parameter of the injection-info, the details of
the abuse@ mailbox as specified in 2142 are irrelevant for us.

It really is no MUST for a subdomain, and with two guaranteed
adresses plus optional addresses we don't need the abuse@ MUST.

                       Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CKedc3078467 for <[e-mail]>; Tue, 12 Jul 2005 13:40:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6CKedAN078466 for ietf-usefor-skb; Tue, 12 Jul 2005 13:40:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CKecNu078446 for <[e-mail]>; Tue, 12 Jul 2005 13:40:38 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6CKeV89080233 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 12 Jul 2005 13:40:33 -0700 (PDT)
Date: Tue, 12 Jul 2005 13:40:31 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>I am still waiting for an explanation of where you think what I have
>written overrides RFC 2142.

Ok, I'll quote the section where you override 2142. Oh, wait, I've quoted 
it already. Once again:

>   and if the agent offers its services to the general public the form
>   "abuse@" that FQDN MUST also be available,

Not just "should", or "ought to be", but a full-blown MUST. RFC2142 has no
such requirement. You've lept from "no requirement" to "MUST" and have yet
to justify it. Why is this a MUST? What part of the news system breaks
when this isn't true?

>Because RFC 2142 is badly written, 

However poorly written you think another RFC is does NOT create an
interoperability issue that we need to solve. Justify the MUST or remove 
it.

>and it is not clear whether the common
>names that it defines MUST be provided, or whrther some of them (and if so
>which ones) are optional. 

Regarding ABUSE@, RFC2142 says:

   For example, if an Internet service provider's domain name is
   COMPANY.COM, then the <[e-mail]> address must be valid and
   supported, 

Simple english. "Must be valid and supported". That's not "optional". I 
see no ambiguity. I see no place where you could see ambiguity. 

> It uses undefined words like "must"

Get a better dictionary. Mine contains a clear definition of "must".

 must{1} v.aux. pt. must
    1. used to express compulsion, obligation,
       requirement, or necessity [I know I must pay
       her, I knew I must pay her]

>Hence the wording I wrote is intended to remove those uncertainties by
>specifying MUST for the injectng agent

Your wording does not "remove uncertainty" because there is none to begin 
with. Your wording places an extra RFC2119 mandate upon something that 
RFC2142 does not. Justify the mandate or remove it. 

>> The news server 
>>"a.b.example.com" will insert a.b.example.com into the Path, but RFC2142 
>>requires that only [e-mail] be valid.

>No, RFC 2142 says that "only the organization's top level domain [is]
>required to be valid", 

Don't contradict me and then quote the RFC that proves I'm correct. If the
news server is a.b.example.com, the ONLY required abuse@ address is
[e-mail], for precisely the reason you quoted. Only the name at
the top level domain is required. For a.b.example.com, that's example.com.

> but since it nowhere defines what is meant by "top level domain", 

Oh, please. If someone is creating a subdomain "b" and populating it with 
host "a" under example.com, then the top level domain is example.com. The 
text of 2142 is even clearer in the example than I was.

>And where do you get that "only" from?

The same RFC you just quoted. See the word "only" in what you quoted from 
it? Why do you quote the word and then ask me the source?

>Even if "example.com" is the TLD, it is still clear that
>abuse@xxxxxxxxxxxxxxx and abuse@xxxxxxxxxxxxx are both valid, and even
>encouraged.

Well, were there more than 'x's filling out those addresses, it might be 
clear, but I'll assume you said something like "[e-mail]" and 
"[e-mail]". No, it is NOT clear that both are valid, since it is 
up to the ISP (or domain owner, if you will) to determine what addresses 
OTHER than [e-mail] are valid. The RFC requires only the top 
level domain. 

>Even though RFC 2142 is described as "Standards Track", it is unusable as
>a standard 

Nonsense. That you cannot use it because it does not explicitely define 
every word contained therein does not limit others who understand simple 
english words. Words like "must" and "only". 

> even though it is impossible to discern the letter.

Oh, please. Pretend I own example.com. I run a news server 
a.news.example.com. I am required by the clear statements in RFC2142 to 
maintain and support the address [e-mail], and I need have no 
other abuse@ address within my domain. Period. I need not have 
"[e-mail]", and you have shown no justification for 
overriding RFC2142 on this matter. Either justify the mandate or remove 
it. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CGHAk3053704 for <[e-mail]>; Tue, 12 Jul 2005 09:17:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6CGHAHk053703 for ietf-usefor-skb; Tue, 12 Jul 2005 09:17:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6CGH97t053695 for <[e-mail]>; Tue, 12 Jul 2005 09:17:09 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-74-26.midband.mdip.bt.net ([81.144.74.26]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42d3ed02.1750.118 for [e-mail]; Tue, 12 Jul 2005 17:17:06 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6CCtHl10095; Tue, 12 Jul 2005 13:55:17 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21987
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 12 Jul 2005 10:01:30 GMT
Lines: 56
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>An outstanding request for explanation still stands:

>   and if the agent offers its services to the general public the form
>   "abuse@" that FQDN MUST also be available, unless a more specific
>   complaints address has been provided in a <complainto-param> of an
>   Injection-Info header (F-3.2.14).

>I'm still waiting for an explanation of why we are overriding RFC2142 in 
>this matter.

I am still waiting for an explanation of where you think what I have
written overrides RFC 2142.

>Why is RFC2142 not sufficient, and what interoperability
>issue is involved to justify this "MUST"?

Because RFC 2142 is badly written, and it is not clear whether the common
names that it defines MUST be provided, or whrther some of them (and if so
which ones) are optional. It uses undefined words like "must" in some
places, and "MUST" in others.

Hence the wording I wrote is intended to remove those uncertainties by
specifying MUST for the injectng agent and SHOULD for all other agents in
the Path (the same as it has been in all our drafts for the past 5 years
or so).

> The news server 
>"a.b.example.com" will insert a.b.example.com into the Path, but RFC2142 
>requires that only [e-mail] be valid.

No, RFC 2142 says that "only the organization's top level domain [is]
required to be valid", but since it nowhere defines what is meant by "top
level domain", that tells us precisely nothing. And where do you get that
"only" from? Even if "example.com" is the TLD, it is still clear that
[e-mail] and [e-mail] are both valid, and even
encouraged.

Even though RFC 2142 is described as "Standards Track", it is unusable as
a standard and, as Ned has recently pointed out on this list, it should
really have been a "BCP". That is how I have always tried to treat it,
giving specific rules for use on Usenet, and ensuring that they were
within the spirit of RFC 2142, even though it is impossible to discern the
letter.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BMwIWl095793 for <[e-mail]>; Mon, 11 Jul 2005 15:58:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BMwIuG095792 for ietf-usefor-skb; Mon, 11 Jul 2005 15:58:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BMwFAB095780 for <[e-mail]>; Mon, 11 Jul 2005 15:58:18 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j6BMw989009139 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 11 Jul 2005 15:58:10 -0700 (PDT)
Date: Mon, 11 Jul 2005 15:58:09 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>RFC 1918 make a clear disticntion between the words "public" and "private"
>as regards IP addresses,

But does not define "publicly recognized". Most people publicly recognize 
192.168.0.1 as a "private" address, but they also publicly recognize 
224.something as multicast, too. 

> Again, I would welcome alternative wordings - 

Except from me, it would seem. 

>Yes. Usenet's a minefield. Always has been. So what's new?

We have no business telling an admin to do something and then saying
if he does it he is responsible for all the bad things that happen. Either 
don't tell him to do it, or don't put the blame on him for the bad things 
that happens when he does it.

>However. Bruce is bending my ear to the effect that we MUST provide some
>mechanism to ensure the uniqueness of these names, 

I don't see where we ever demand that they be unique. Certainly not in the 
section that deals with defining a path-identity in USEFOR. And we 
certainly don't tell someone how to guarantee they be unique when we say 
that they only SHOULD use one of the four suggested methods. So neither
unique by mandate nor unique by design. 

An outstanding request for explanation still stands:

   and if the agent offers its services to the general public the form
   "abuse@" that FQDN MUST also be available, unless a more specific
   complaints address has been provided in a <complainto-param> of an
   Injection-Info header (F-3.2.14).

I'm still waiting for an explanation of why we are overriding RFC2142 in 
this matter. Why is RFC2142 not sufficient, and what interoperability 
issue is involved to justify this "MUST"? The news server 
"a.b.example.com" will insert a.b.example.com into the Path, but RFC2142 
requires that only [e-mail] be valid. What interoperability issue 
exists to justify another mandate from us?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGEnOE060423 for <[e-mail]>; Mon, 11 Jul 2005 09:14:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BGEnfH060422 for ietf-usefor-skb; Mon, 11 Jul 2005 09:14:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGElEG060396 for <[e-mail]>; Mon, 11 Jul 2005 09:14:48 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-56.midband.mdip.bt.net ([81.144.75.56]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42d29af6.a37b.18 for [e-mail]; Mon, 11 Jul 2005 17:14:46 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6BGCLX22044 for [e-mail]; Mon, 11 Jul 2005 17:12:21 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21983
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: RFC 2142
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> 	<008301c581f8$86d1dc20$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 11 Jul 2005 11:36:53 GMT
Lines: 51
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:
> 
>> We should try to continue to support RFC 2142.

>No problem with chapter 1, but less obvious with chapter 2,
>i.e. abuse@

You should try reading news.admin.net-abuse.email (the corresponding
.news. group is mostly full of trolls and spam). The people there take a
very dim view of ISPs who do not provide the RFC 2142 abuse@ address. In
our case, we allow them to select a different abuse address in
Injection-Info, so there is no excuse for them not to provide the default
abuse@ if they have neglected to specify an alternative.

>If you have a <path-identity> news.example.com then it's
>okay to expect [e-mail] 

>  BTW, I never got the idea why it's usenet@ _and_ news@,
>  and did the new RfC 977bis drop both addreses ?

Pure history :-( .

>Back to news.example.com, probably a host in the zone of
>example.com, then RfC 2142 only demands [e-mail]
>and [e-mail] might not exist.

Indeed, which is why, as an injecting agent, it SHOULD/MUST put
example.com as its path-identity.

However, it might make sense to put both (if it wants to record which
server belonging to its farm actually handled the article).

So should we allow a site to insert two <path-identity>s if it wants to?
That is currently sort-of deprecated, but is easily changed and would give
extra flexivility for various purposes (e.g. for "demon", who want to
continue using that name for histporical continuity). The only downside
would be that Path headers would be a little longer, so it should not be
done without good cause.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGEnIj060424 for <[e-mail]>; Mon, 11 Jul 2005 09:14:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BGEndg060421 for ietf-usefor-skb; Mon, 11 Jul 2005 09:14:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGEmqv060407 for <[e-mail]>; Mon, 11 Jul 2005 09:14:48 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-56.midband.mdip.bt.net ([81.144.75.56]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42d29af7.a37b.19 for [e-mail]; Mon, 11 Jul 2005 17:14:47 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6BGCM922053 for [e-mail]; Mon, 11 Jul 2005 17:12:22 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21984
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Mon, 11 Jul 2005 13:07:42 GMT
Lines: 54
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes
>>>>
>>>>   4.   Some other (arbitrary) name believed to be unique and registered
>>>>        at least with all other news-servers sending articles directly
>>>>        to the given one. The news-server administrator is responsible
>>>>        for choosing an appropriate name (and will bear the consequences
>>>>        of an inappropriate choice). .....

>>That s[last] entence is just a polite way of saying "Yes, we know that the
>>uniquesness is not enforceable. Tough!".

>we could add similar sentences to almost every paragraph. However, since
>the sentence is wrong (I expect the administrator has been told to use
>the name by the people who set up the company in the late 1980s and see
>no reason to change (and thereby annoy their customers)) and also since
>they will not necessarily see any consequences of an inappropriate
>choice (the users of the server may have slightly less propagation of
>their articles, but may never realise) then the sentence would need
>rewriting to be accurate...  hence my suggestion of dropping it.

I don't see what is wrong. It is not our job to define precisely who is an
"administrator". So far as the standard is concerned it is whoever gets to
make the decisions, and if that goes all the way up to the Managing
Director of Thus plc (or Scottish Telcom, if they are still in the chain),
then that is their problem. If the administrator (he, they, it) becomes
aware that there is another site using the name "demon" (perhaps only in
some obscure hierarchy in Outer Mongolia), then he either has to persuade
the Mongolians to change, or he has to annoy his customers, or he has to
risk losing some articles. All that is part of "bearing the consequences".

Now we all know that there is NO One and Perfect solution to this problem.
There is No Cabal to fix it (and we don't want to establish no cabal).

However. Bruce is bending my ear to the effect that we MUST provide some
mechanism to ensure the uniqueness of these names, or alternatively we
MUST document the lack as a "known technical omission". I don't think we
can ignore the matter entirely, and the words I wrote were intended to
indicate the presence of a "known technical omission". But I am not wedded
to those words; if anyone can suggest some alternative way of pointing out
the limitations of the existing setup, then let us have it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGEl6T060405 for <[e-mail]>; Mon, 11 Jul 2005 09:14:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BGEleW060404 for ietf-usefor-skb; Mon, 11 Jul 2005 09:14:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGEkov060388 for <[e-mail]>; Mon, 11 Jul 2005 09:14:46 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-56.midband.mdip.bt.net ([81.144.75.56]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42d29af5.a37b.17 for [e-mail]; Mon, 11 Jul 2005 17:14:45 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6BGCJn22035 for [e-mail]; Mon, 11 Jul 2005 17:12:19 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21982
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1021 Single component newsgroups (Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <A3144E13755E7D3CACB6EA26@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <78BBACC38DC374725A4EDD07@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 11 Jul 2005 11:25:09 GMT
Lines: 31
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Graham Drabble <[e-mail]> writes:

>On 06 Jul 2005 "Charles Lindsey" <[e-mail]> wrote in
>news:[e-mail]: 

>> Yes, I agree it is an interoperability concern, and so warrants
>> appropriate RFC 2114 language in USEFOR.
> 
>The problem is that we have no way of determing all the different 
>things that will cause trouble.

Sure, but where we _do_ know of a problem, we should fix it. The problem
with all-digit components has been recognized for donkey's years.

> If I were to create news.out locally 
>then I'm pretty sure it would cause Hamster some problems. The 
>solution is that I won't create it even if a newgroup is sent.

And USEPRO will say something like that (I am just waiting for the USEFOR
text on this matter to stabilise before proposing text for USEPRO).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGElY8060397 for <[e-mail]>; Mon, 11 Jul 2005 09:14:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BGElkx060395 for ietf-usefor-skb; Mon, 11 Jul 2005 09:14:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BGEjNa060387 for <[e-mail]>; Mon, 11 Jul 2005 09:14:46 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-56.midband.mdip.bt.net ([81.144.75.56]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.187) id 42d29af4.a37b.16 for [e-mail]; Mon, 11 Jul 2005 17:14:44 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j6BGCOo22062 for [e-mail]; Mon, 11 Jul 2005 17:12:24 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21985
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 11 Jul 2005 13:15:00 GMT
Lines: 46
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
>      3986] - which SHOULD be a publicly recognized address [RFC 1918]
>      for the actual host, as above. This option SHOULD NOT be used if
>      an FQDN for that host is available.

>I publicly recognize 192.168.0.1, but it is not routable and should not be 
>used as a path identity. 

RFC 1918 make a clear disticntion between the words "public" and "private"
as regards IP addresses, and my wording was intended to build on that
distinction. I am open to suggestions as to how to make that clearer.

>Path identities need to be in the public address space and routable, which
>deals not only with private addresses but multicast.

Yes, my first attempt at wording this used the phrase "routing tables", but
I was told that there existed routing tables even inside intranets. Again,
I would welcome alternative wordings - we all know the intent we wish to
convey, but it is not clear how to convey it with total unambiguity.

>   4. Some other (arbitrary) name believed to be unique and registered
>      at least with all other news-servers sending articles directly to
>      the given one. The news-server administrator is responsible for
>      choosing an appropriate name (and will bear the consequences of an
>      inappropriate choice). 

>Dear Admin:

>Here's your minefield, have a nice day.

Yes. Usenet's a minefield. Always has been. So what's new?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BEo6bS052545 for <[e-mail]>; Mon, 11 Jul 2005 07:50:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BEo6u1052544 for ietf-usefor-skb; Mon, 11 Jul 2005 07:50:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BEo5jE052538 for <[e-mail]>; Mon, 11 Jul 2005 07:50:06 -0700 (PDT) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Drzbd-0000N0-Sf; Mon, 11 Jul 2005 10:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-usefor-usefor-05.txt 
Message-Id: <[e-mail]>
Date: Mon, 11 Jul 2005 10:50:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: Netnews Article Format
	Author(s)	: C. Lindsey, et al.
	Filename	: draft-ietf-usefor-usefor-05.txt
	Pages		: 35
	Date		: 2005-7-11
	
This document specifies the syntax of network news (Netnews) articles
   in the context of the "Internet Message Format" (RFC 2822) and
   "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045).  This
   document supersedes RFC 1036, updating it to reflect current practice
   and incorporating incremental changes specified in other documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-usefor-usefor-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usefor-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usefor-05.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j69KJSDT025419 for <[e-mail]>; Sat, 9 Jul 2005 13:19:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j69KJSDU025418 for ietf-usefor-skb; Sat, 9 Jul 2005 13:19:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ID-77355.user.dfncis.de ([82.133.101.159]) by above.proper.com (8.12.11/8.12.9) with SMTP id j69KJQJp025409 for <[e-mail]>; Sat, 9 Jul 2005 13:19:27 -0700 (PDT) (envelope-from [e-mail])
Received: from sjoh1646 ([127.0.0.1]) by sjoh1646 (192.168.254.2) with news-to-mail ; Sat, 09 Jul 2005 21:15:44 +0100
To: [e-mail]
Subject: Re: #1021 Single component newsgroups (Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
From: Graham Drabble <[e-mail]>
References: <A3144E13755E7D3CACB6EA26@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <78BBACC38DC374725A4EDD07@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 09 Jul 2005 21:15:44 +0100
Organization: Home
Message-ID: <[e-mail]>
User-Agent: Xnews/5.04.25 Hamster-Pg/1.24
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On 06 Jul 2005 "Charles Lindsey" <[e-mail]> wrote in
news:[e-mail]: 

> 
> In <[e-mail]> Russ Allbery
> <[e-mail]> writes: 
> 
>>I think it's still an interoperability concern, but I can see the
>>valid point there.
> 
> Yes, I agree it is an interoperability concern, and so warrants
> appropriate RFC 2114 language in USEFOR.
 
The problem is that we have no way of determing all the different 
things that will cause trouble. If I were to create news.out locally 
then I'm pretty sure it would cause Hamster some problems. The 
solution is that I won't create it even if a newgroup is sent. If I 
decide I want the group I'll change software (or try and patch 
hamster). To me it's a far better idea to tell admins to be careful 
what they add (and possibly warn creators of any widespread pitfalls) 
than to try and ban groups that will only cause a problem where the 
admin lets them.


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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68K2jNq044092 for <[e-mail]>; Fri, 8 Jul 2005 13:02:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68K2j0p044091 for ietf-usefor-skb; Fri, 8 Jul 2005 13:02:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68K2iAR044079 for <[e-mail]>; Fri, 8 Jul 2005 13:02:45 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org (a.shell.peak.org [69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j68K2d89023937 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 8 Jul 2005 13:02:39 -0700 (PDT)
Date: Fri, 8 Jul 2005 13:02:39 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers, and a serving agent SHOULD use the same <path-identity> in
   both Path and Xref headers. 

s/headers/header fields/g; Didn't we discuss this already at length and
come to a concensus?

   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
      3986] - which SHOULD be a publicly recognized address [RFC 1918]
      for the actual host, as above. This option SHOULD NOT be used if
      an FQDN for that host is available.

I publicly recognize 192.168.0.1, but it is not routable and should not be 
used as a path identity. 

Path identities need to be in the public address space and routable, which
deals not only with private addresses but multicast.

   4. Some other (arbitrary) name believed to be unique and registered
      at least with all other news-servers sending articles directly to
      the given one. The news-server administrator is responsible for
      choosing an appropriate name (and will bear the consequences of an
      inappropriate choice). 

Dear Admin:

Here's your minefield, have a nice day.

Sincerely, USEFOR Working Group.

        NOTE: The syntax permits the colon character 

Not the last syntax I've seen.

   and if the agent offers its services to the general public the form
   "abuse@" that FQDN MUST also be available, unless a more specific
   complaints address has been provided in a <complainto-param> of an
   Injection-Info header (F-3.2.14).

I'm still waiting for an explanation of why we are overriding RFC2142 in 
this matter. Why is RFC2142 not sufficient, and what interoperability 
issue is involved to justify this "MUST"?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68JnD89042974 for <[e-mail]>; Fri, 8 Jul 2005 12:49:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68JnDHa042973 for ietf-usefor-skb; Fri, 8 Jul 2005 12:49:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68JnCBZ042960 for <[e-mail]>; Fri, 8 Jul 2005 12:49:12 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org (a.shell.peak.org [69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j68Jn2Fm083601 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 8 Jul 2005 12:49:06 -0700 (PDT)
Date: Fri, 8 Jul 2005 12:49:02 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Semantic header (field) Content
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

   The "semantic content" (often abbreviated to just "content" when the
   context is clear) of a header field is its semantic interpretation;
   i.e. what remains after unfolding it and removing its field name with
   its colon and any leading and trailing whitespace and, in the case of
   structured headers only, ignoring comments and other semantically
   invisible items and replacing white space by a single SP.

This is fine, if you do not accept "Re: " or "cmsg" in the encoded part of 
a header field body as meaning ANYTHING special. In fact, it denies any 
special meaning to any encoded content of any field body, since decoding 
isn't part of your conversion from "field body" to "semantic content".



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68IvPV9039039 for <[e-mail]>; Fri, 8 Jul 2005 11:57:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68IvPNO039038 for ietf-usefor-skb; Fri, 8 Jul 2005 11:57:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68IvOU9039024 for <[e-mail]>; Fri, 8 Jul 2005 11:57:24 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j68IvJFm061857 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 8 Jul 2005 11:57:19 -0700 (PDT)
Date: Fri, 8 Jul 2005 11:57:19 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Some people profess great concern that we have not provided a way to
>enforce the uniqueness of these names.

>That sentence is just a polite way of saying "Yes, we know that the
>uniquesness is not enforceable. Tough!".

"That sentence" says nothing of the sort. It's telling the hapless admin 
that even if he does what we tell him to do, there may be "consequences" 
from his "inappropriate" choice. 

If what we tell him to do results in an "inappropriate choice", then I'd
say the only "inappropriate choice" he has made is in listening to us.

Either fix the instruction so it does not result in "inappropriate 
choices" or remove the threat.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68IsT5u038646 for <[e-mail]>; Fri, 8 Jul 2005 11:54:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68IsTt2038645 for ietf-usefor-skb; Fri, 8 Jul 2005 11:54:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68IsSj3038635 for <[e-mail]>; Fri, 8 Jul 2005 11:54:28 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j68IsM89093972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 8 Jul 2005 11:54:22 -0700 (PDT)
Date: Fri, 8 Jul 2005 11:54:02 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly <blilly@xxxxxxxxx>:

>That seems OK; I'm wary of "elide all colons" because dead::beef:cafe
>and dead:beef::cafe mean different things in IPv6-ese.

You cannot "elide all colons" until after you have undone the "double 
colon abbreviation" step for IPv6, because, as you point out, the double 
colons means something different than the single colon.

And once you have elided them, there is no reason to put something else in 
their place. Simply remove the colons. Problem solved. There are no 32 
character UUCP names to conflict with.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68GH4IM023534 for <[e-mail]>; Fri, 8 Jul 2005 09:17:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68GH4Jp023533 for ietf-usefor-skb; Fri, 8 Jul 2005 09:17:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68GH3Rf023526 for <[e-mail]>; Fri, 8 Jul 2005 09:17:03 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-74-139.midband.mdip.bt.net ([81.144.74.139]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cea6fd.adff.2d for [e-mail]; Fri,  8 Jul 2005 17:17:01 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j68GCGt10330 for [e-mail]; Fri, 8 Jul 2005 17:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21973
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Semantic header (field) Content
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Date: Fri, 8 Jul 2005 11:26:10 GMT
Lines: 56
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Charles Lindsey" <[e-mail]> writes:

>In <[e-mail]> Russ Allbery <[e-mail]> writes:

>>Charles Lindsey <[e-mail]> writes:


>>> 2. A followup agent is permitted (MAY) to prepend a "Re: " to the
>>> Subject if there is not one there already. Is it to be permitted to
>>> enclose that "Re: " within an encoded-word ...

>>My reading of RFC 2822 indicates no.

>>> More to the point, however, is whether it is expected to decode an
>>> initial encoded-word before detecting whether an initial "Re: " is there
>>> already (I would not expect that to happen often - has anyone ever seen
>>> such a thing - but you never know).

>>I don't think it should be required, although an implementation should be
>>allowed to do so if it wishes to, I think.

>OK, I agree with all that (and AFAIR that was our position when we last
>discussed it - i.e. we agreed that the only mention/advice should go into
>USEAGE). Frank seems to agree.

>So that is what I shall do unless I hear loud screams otherwise.

I asked for a small clarification regarding the handling of "Re: ". We
discussed the substantive issue ad nauseam last summer and reached a
compromise (Seth's 4 points) that all the participants bar two signed up
to. I therefore regard that whole matter as now closed, and do not intend
to engage in further discussion of it.

So, as regards that one clarification I asked for, the text I now have is
as follows:

   The "semantic content" (often abbreviated to just "content" when the
   context is clear) of a header field is its semantic interpretation;
   i.e. what remains after unfolding it and removing its field name with
   its colon and any leading and trailing whitespace and, in the case of
   structured headers only, ignoring comments and other semantically
   invisible items and replacing white space by a single SP.

That definitions works fine, with a few grammatical tweaks, at all places
in USEPRO where the term "header content" currently appears.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68GCAm6023227 for <[e-mail]>; Fri, 8 Jul 2005 09:12:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68GCAeL023226 for ietf-usefor-skb; Fri, 8 Jul 2005 09:12:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68GC81N023220 for <[e-mail]>; Fri, 8 Jul 2005 09:12:09 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id C9020299C4; Fri,  8 Jul 2005 12:12:07 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j68GC12d015274(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 8 Jul 2005 12:12:05 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j68GBxSf015273(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 8 Jul 2005 12:12:00 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Fri, 8 Jul 2005 12:11:55 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 7 2005 23:02, Frank Ellermann wrote:
> 
> Charles Lindsey wrote:
> 
> > IP addresses DO occur in Paths for a variety of reasons
> 
> Rarely, as you found.  But if Bruce and others think that IPv6
> is a serious problem,

No question it's a backward compatibility issue, as discussed here
at length.

> and if we don't want to ue the "replace 
> all colons by underscore" hack,

That seems OK; I'm wary of "elide all colons" because dead::beef:cafe
and dead:beef::cafe mean different things in IPv6-ese.

> getting rid of domain literals 
> completely is a option.

Also OK by me.
 
> > These occurrences do not necessarily indicate MISMATCHes,
> 
> That was apparently Harald's "diagnostic" proposal, but I doubt
> that it would change anything for Bruce's dead::feed objection.

Presence of a colon would remain a backwards compatibility problem;
limiting it to diagnostics would limit but not remove the potential
for harm.  Minimal further effort (e.g. suitable choice of diagnostic
syntax, such as "(MISMATCH^dead:beef::cafe)") would still be a problem
for legacy implementations, but would clearly position the diagnostic
information as human-readable content as opposed to protocol, and would
allow retention of colon outside of comments as a delimiter for possible
future use.  It also would simplify handling for new implementations,
as the entire comment could be ignored instead of requiring special
handling of magic keywords and IP address literals.  Combining such
syntax with translation would be win-win for new and old.

> > the NOTE after #4 to warn against that is still needed.
> 
> You could at least limit it to four or less hex. letters,
> feedcafe is fine.

*If* such names are retained (as opposed to becoming non-conforming),
that would require some double-standard treatment of some sites;
both "r2d2" and "cafe" were legal under 850/1036 and it seems to be
unreasonable to discriminate against some sites but not others.

[too early for ABNF-wrangling] 
> > If the actual entry in the Path is "newshost-5.example.com",
> > it may be that that actual host does not listen on Port 25.
> > Therefore the admin may well prefer to put just "example.com"
> > as his path-identity, where "example.com" is an MX pointing
> > to mailhost.example.com
> 
> Why doesn't he add MX or CNAME for this effect, or is this a
> way to get a single <path-identity> for several hosts ?

The former would be appropriate, but suboptimal, i.e. an MX record
indicating an appropriate host and preference value for handling
mail with the domain "newshost-5.example.com" (but that provides
no indication for a local-part); OTOH the site can simply specify
the appropriate mailboxes (local-parts and domains) via Injection-Info.

"single ... for several" is inconsistent with the uniqueness
requirement, which is why a primary name or registered alias needs
to be specified.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68BEXwo052116 for <[e-mail]>; Fri, 8 Jul 2005 04:14:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68BEXLm052114 for ietf-usefor-skb; Fri, 8 Jul 2005 04:14:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68BEW9K052090 for <[e-mail]>; Fri, 8 Jul 2005 04:14:32 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1DqqkE-000Bvv-4c for [e-mail]; Fri, 08 Jul 2005 11:10:10 +0000
Message-ID: <[e-mail]>
Date: Fri, 8 Jul 2005 12:12:57 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <v06$+Hgn77vaIMKLgmV+due66g>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes
>
>In <[e-mail]> Richard Clayton <[e-mail]> 
>writes:
>
>>In message <[e-mail]>, Charles Lindsey
>><[e-mail]> writes
>
>>>All right:
>>>
>>>   4.   Some other (arbitrary) name believed to be unique and registered
>>>        at least with all other news-servers sending articles directly
>>>        to the given one. The news-server administrator is responsible
>>>        for choosing an appropriate name (and will bear the consequences
>>>        of an inappropriate choice). .....
>
>>for preference I'd remove the second sentence altogether, it adds
>>nothing of any real significance
>
>Some people profess great concern that we have not provided a way to
>enforce the uniqueness of these names.

it is of great concern ... which is why it isn't being recommended for
anyone who hasn't been using the name for decades... (or as someone
said, several months, by which time the drawbacks of an error will be
obvious or will be being lived with)

Once again I repeat my suggestion of stressing what is to be achieved
and removing (or toning down) the tedious detail about the myriad ways
of managing to reach the goal

>That sentence is just a polite way of saying "Yes, we know that the
>uniquesness is not enforceable. Tough!".

we could add similar sentences to almost every paragraph. However, since
the sentence is wrong (I expect the administrator has been told to use
the name by the people who set up the company in the late 1980s and see
no reason to change (and thereby annoy their customers)) and also since
they will not necessarily see any consequences of an inappropriate
choice (the users of the server may have slightly less propagation of
their articles, but may never realise) then the sentence would need
rewriting to be accurate...  hence my suggestion of dropping it.

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

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQs5fuZoAxkTY1oPiEQJz9wCglb12m6qL4fzLXh/kr1Uw84hhzsUAmwao
pShd+G5bWLua1AyeHyrDbGiP
=rOfk
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68AwlqW045346 for <[e-mail]>; Fri, 8 Jul 2005 03:58:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68AwlTP045345 for ietf-usefor-skb; Fri, 8 Jul 2005 03:58:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68AwjuW045329 for <[e-mail]>; Fri, 8 Jul 2005 03:58:46 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-100.midband.mdip.bt.net ([81.144.71.100]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42ce5c64.15e1f.d2 for [e-mail]; Fri,  8 Jul 2005 11:58:44 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j68Arog06363 for [e-mail]; Fri, 8 Jul 2005 11:53:51 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21970
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Fri, 8 Jul 2005 10:13:28 GMT
Lines: 32
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes

>>All right:
>>
>>   4.   Some other (arbitrary) name believed to be unique and registered
>>        at least with all other news-servers sending articles directly
>>        to the given one. The news-server administrator is responsible
>>        for choosing an appropriate name (and will bear the consequences
>>        of an inappropriate choice). .....

>for preference I'd remove the second sentence altogether, it adds
>nothing of any real significance

Some people profess great concern that we have not provided a way to
enforce the uniqueness of these names.

That sentence is just a polite way of saying "Yes, we know that the
uniquesness is not enforceable. Tough!".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68AwlfP045356 for <[e-mail]>; Fri, 8 Jul 2005 03:58:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j68Awlj3045355 for ietf-usefor-skb; Fri, 8 Jul 2005 03:58:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j68AwkAS045335 for <[e-mail]>; Fri, 8 Jul 2005 03:58:46 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-100.midband.mdip.bt.net ([81.144.71.100]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42ce5c64.15e1f.d3 for [e-mail]; Fri,  8 Jul 2005 11:58:44 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j68ArqX06370 for [e-mail]; Fri, 8 Jul 2005 11:53:52 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21971
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 8 Jul 2005 10:52:25 GMT
Lines: 143
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>> IP addresses DO occur in Paths for a variety of reasons

>Rarely, as you found.

4% is hardly rare. The fact that it was made up of all sorts of different
usages does not alter the fact that it happened.

>But if Bruce and others think that IPv6
>is a serious problem, and if we don't want to ue the "replace
>all colons by underscore" hack, getting rid of domain literals
>completely is a option.

But I don't think you can suddenly chop off 4% of existing asage, and when
used for diagnostic purposes, IP addresses (including MISMATCHes) could be
considered quite sensible.


>That was apparently Harald's "diagnostic" proposal, but I doubt
>that it would change anything for Bruce's dead::feed objection.

Indeed. Allowing them for diagnostic purposes does nothing for the
dead:beef problem, so if you are going to allow them for diagnostics, then
you may as well allow them for everything, but with a SHOULD NOT because
there are usually better ways. Indeed, I currently have SHOULD NOT for
both the IP and arbitrary-name cases, which is at least a consistent
approach.

>> there is a general expectation throughout the Internet
>> (reinforced by provisions in many standards) that an IP
>> address can be used in any context where a domain-name
>> can be used.

>Not in the mail world, they'd want at least square brackets.
>John already rejected the dubious idea to relax the 2821bis
>syntax in this context.  Otherwise, yes...

>> I do not think it should be forbidden entirely.

>...but apparently Bruce and others disagree.  My favourite
>STRONGLY DISCOURAGED found in STD 11 is (again apparently)
>not good enough for all.

The "SHOULD NOT"s in the present text are actually stronger than your
"STRONGLY DISCOURAGED".

>> the NOTE after #4 to warn against that is still needed.

>You could at least limit it to four or less hex. letters,
>feedcafe is fine.

Already done that. Perhaps it is time to repeat my whole text as it
surrently stands, in view of various recent changes:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers, and a serving agent SHOULD use the same <path-identity> in
   both Path and Xref headers.  To ensure that a <path-identity>
   provides a unique identity for the news-server concerned, it should
   be one of:
 
   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record (or an equivalent "CNAME"), which SHOULD identify
      the actual host inserting this <path-identity> and, ideally,
      should also be "mailable" (see below).
 
   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
      3986] - which SHOULD be a publicly recognized address [RFC 1918]
      for the actual host, as above. This option SHOULD NOT be used if
      an FQDN for that host is available.

   3. A fully qualified domain name (FQDN) associated with an "MX"
      record, which MUST be "mailable".

   4. Some other (arbitrary) name believed to be unique and registered
      at least with all other news-servers sending articles directly to
      the given one. The news-server administrator is responsible for
      choosing an appropriate name (and will bear the consequences of an
      inappropriate choice). This option SHOULD NOT be used unless the
      earlier options are unavailable (e.g. because the host in question
      is not connected to the Internet), or unless it is of longstanding
      usage and cessation would be unduly disruptive.

        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within any <path-
        identity> which is in the form of an <IPv6address>.  It would
        therefor be unwise to choose, as such a name, anything composed
        solely from four (or less) hexadecimal digits.

   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@" that FQDN and
   "news@" that FQDN, in conformity with [RFC 2142].

   For an injecting agent prepending to a Path header (7.2.2), the
   <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable,
   and if the agent offers its services to the general public the form
   "abuse@" that FQDN MUST also be available, unless a more specific
   complaints address has been provided in a <complainto-param> of an
   Injection-Info header (F-3.2.14).

[I still think that mention of RFC 1918 needs more thought.  Also, is one
allowed to have a CNAME pointing to an MX record (RFC 2821 seems to think
so), in which case should I be mentioning CNAMEs in #3?]



>> If the actual entry in the Path is "newshost-5.example.com",
>> it may be that that actual host does not listen on Port 25.
>> Therefore the admin may well prefer to put just "example.com"
>> as his path-identity, where "example.com" is an MX pointing
>> to mailhost.example.com

>Why doesn't he add MX or CNAME for this effect, or is this a
>way to get a single <path-identity> for several hosts ?

It could indeed lead to a single <path-identity> for a farm of hosts (and
I don't necessarily think that is a bad thing). Alternatively, I suspect
that some servers actually insert two entries, one identifying the actual
host, and the other the MX record for contact. For sure, one often sees 3
or more entries from a given site, and I am not sure it always means it
actually passed through 3 hosts on that site.

Path: ...![e-mail]!example.com!newsin-3.example.com!...

Also, I suspect that some sites, such as "demon", add that as an arbitrary
name in the midst of the bunch, simply because there are thousands of
sites out there which wrote "demon" into their sys files yonks ago.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j686Phwe040027 for <[e-mail]>; Thu, 7 Jul 2005 23:25:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j686Phn7040025 for ietf-usefor-skb; Thu, 7 Jul 2005 23:25:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j686PeeG039991 for <[e-mail]>; Thu, 7 Jul 2005 23:25:41 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqmIT-0007K9-8S for [e-mail]; Fri, 08 Jul 2005 08:25:13 +0200
Received: from du-001-048.access.de.clara.net ([212.82.227.48]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 08 Jul 2005 08:25:13 +0200
Received: from nobody by du-001-048.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 08 Jul 2005 08:25:13 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: RFC 2142
Date:  Fri, 08 Jul 2005 08:20:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> 	<008301c581f8$86d1dc20$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-048.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 
> We should try to continue to support RFC 2142.

No problem with chapter 1, but less obvious with chapter 2,
i.e. abuse@

If you have a <path-identity> news.example.com then it's
okay to expect [e-mail] 

  BTW, I never got the idea why it's usenet@ _and_ news@,
  and did the new RfC 977bis drop both addreses ?

Back to news.example.com, probably a host in the zone of
example.com, then RfC 2142 only demands [e-mail]
and [e-mail] might not exist.  That's also
the RFCI (rfc-ignorant.org) listing policy, see below,
we should not invent new abuse@ rules conflicting with
RfC 2142 and RFCI.
                     Bye, Frank

Listing policy <http://rfc-ignorant.org/policy-abuse.php>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6835Hmt087387 for <[e-mail]>; Thu, 7 Jul 2005 20:05:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6835HAZ087386 for ietf-usefor-skb; Thu, 7 Jul 2005 20:05:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6835E8E087380 for <[e-mail]>; Thu, 7 Jul 2005 20:05:15 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqjAo-0007jr-3z for [e-mail]; Fri, 08 Jul 2005 05:05:06 +0200
Received: from du-001-048.access.de.clara.net ([212.82.227.48]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 08 Jul 2005 05:05:06 +0200
Received: from nobody by du-001-048.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 08 Jul 2005 05:05:06 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Fri, 08 Jul 2005 05:02:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 71
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-048.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> IP addresses DO occur in Paths for a variety of reasons

Rarely, as you found.  But if Bruce and others think that IPv6
is a serious problem, and if we don't want to ue the "replace
all colons by underscore" hack, getting rid of domain literals
completely is a option.

In the traditional sense as bang-path there should be no IPs,
or at least it would surprise me if that worked as expected.

> These occurrences do not necessarily indicate MISMATCHes,

That was apparently Harald's "diagnostic" proposal, but I doubt
that it would change anything for Bruce's dead::feed objection.

> there is a general expectation throughout the Internet
> (reinforced by provisions in many standards) that an IP
> address can be used in any context where a domain-name
> can be used.

Not in the mail world, they'd want at least square brackets.
John already rejected the dubious idea to relax the 2821bis
syntax in this context.  Otherwise, yes...

> I do not think it should be forbidden entirely.

...but apparently Bruce and others disagree.  My favourite
STRONGLY DISCOURAGED found in STD 11 is (again apparently)
not good enough for all.  I can't judge what's worse

But sometimes you say "a MUST declaring each and every
existing UA on the planet non-conformant is no problem",
so why is this IP in <path-idetiy> case different ?

> the NOTE after #4 to warn against that is still needed.

You could at least limit it to four or less hex. letters,
feedcafe is fine.

>> "Traditional name" has no dots, it can have underscores.

> Actually, the syntax (both Harald's version or mine) is
> ambiguous; that needs to be fixed (probably by a comment
> after ';' in the ABNF).

At the moment you both don't distinguish 2821-FQDN vs. any
traditional name (and the old 2821 syntax will be slightly
modifified in 2821bis).  Vague idea ignoring the IPs for
the moment:

  path-identity = hostname / obs-name
  hostname      = 1*( domainlabel "." ) toplabel
  domainlabel   = alphanum [ *( alphanum / "-" ) alphanum ]
  toplabel      = ALPHA    [ *( alphanum / "-" ) alphanum ]
  alphanum      = ALPHA / DIGIT
  obs-name      = alphanum *( alphanum / "-" / "_" )

With that syntax "mailable hostname" is clear, you could just
say news@<hostname> or similar instead of using ews@<FQDN>.

> If the actual entry in the Path is "newshost-5.example.com",
> it may be that that actual host does not listen on Port 25.
> Therefore the admin may well prefer to put just "example.com"
> as his path-identity, where "example.com" is an MX pointing
> to mailhost.example.com

Why doesn't he add MX or CNAME for this effect, or is this a
way to get a single <path-identity> for several hosts ?  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j681DUUL077571 for <[e-mail]>; Thu, 7 Jul 2005 18:13:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j681DUSf077570 for ietf-usefor-skb; Thu, 7 Jul 2005 18:13:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j681DSw7077559 for <[e-mail]>; Thu, 7 Jul 2005 18:13:28 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqhQc-00069S-WE for [e-mail]; Fri, 08 Jul 2005 03:13:19 +0200
Received: from du-001-048.access.de.clara.net ([212.82.227.48]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 08 Jul 2005 03:13:18 +0200
Received: from nobody by du-001-048.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 08 Jul 2005 03:13:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: News URIs
Date:  Fri, 08 Jul 2005 03:08:33 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 35
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-048.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> A bit off topic for this group, but never mind.

Strictly within the Charter:

| The Group shall also aid and/or oversee the production of
| other Usenet related Internet Drafts and Standards.

For unclear reasons (maybe caused by a Reply-To: [e-mail])
one related article never made it to this list:

<http://article.gmane.org/gmane.org.w3c.uri/545/raw>

> "news:*.test" is the example I usually give.

That matches Russ' idea, integrate * into the syntax, which
is in theory backwards compatible with draft-gilman-news-02

> There is no need to encode "?"

It's "reserved" according to RfC 1738, 2396, 3986 (STD 66),
whatever that means.  And in fact my UA has its own ideas
about stuff like ?part=1.2 in conjunction with an article.

> There is never a requirement to encode "\" in RFC 3986

You have to read it several times to find that it simply
does not mention the characters DQUOTE, "<", ">", "\", "^",
"`", "{", "|", "}" - nowhere.  Whatever the rule for a "\"
might be,, it's the same as for "<", ">", DQUOTE etc.

                         Bye, Frank





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j680fdxS074519 for <[e-mail]>; Thu, 7 Jul 2005 17:41:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j680fdTZ074518 for ietf-usefor-skb; Thu, 7 Jul 2005 17:41:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j680fcwq074507 for <[e-mail]>; Thu, 7 Jul 2005 17:41:39 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j680fXND092858 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 7 Jul 2005 17:41:33 -0700 (PDT)
Date: Thu, 7 Jul 2005 17:41:33 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Semantic header (field) Content
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>2. A followup agent is permitted (MAY) to prepend a "Re: " to the Subject
>if there is not one there already. Is it to be permitted to enclose that
>"Re: " within an encoded-word (I would hope not, because there is no
>benefit in doing so, and it is not done in current practice AFAIK). More
>to the point, however, is whether it is expected to decode an initial
>encoded-word before detecting whether an initial "Re: " is there already
>(I would not expect that to happen often - has anyone ever seen such a
>thing - but you never know).

It is quite proper for a user to enter the "Re: " by hand when modifying 
the Subject, and thus any agent that would normally encode the subject 
text will also encode the "Re: ". Unless it put the text there, it cannot 
tell whether that text is a "followup" marker or anything else. Even so, 
in most cases it will put the text there and then pass the Subject to the 
user, who can edit it, and thus the agent still cannot know if that string 
is a followup marker or not. 

So, logically, if "Re: " is to be used, it has to be detected in encoded 
Subjects. Otherwise you are stuck trying to demand that any agent that 
encodes a subject field body has to make special allowances for any 
potential "Re: " strings.

The same problem exists for your paragraph 1 with 'cmsg', except that 
'cmsg' is less likely to be inserted by hand (but there is still not zero 
chance).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67LWlv4061018 for <[e-mail]>; Thu, 7 Jul 2005 14:32:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67LWlWl061017 for ietf-usefor-skb; Thu, 7 Jul 2005 14:32:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67LWlpl061010 for <[e-mail]>; Thu, 7 Jul 2005 14:32:47 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 2AAB029923; Thu,  7 Jul 2005 17:32:46 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67LWgx7028152(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 17:32:43 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67LWb3e028149(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 17:32:38 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: Style of documentation (Re: #1043 "header": Suggested resolution)
Date: Thu, 7 Jul 2005 17:32:19 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Mon July 4 2005 09:08, Charles Lindsey wrote:
> 
> In <[e-mail]> Bruce Lilly <[e-mail]> writes:
> 
> >Note: Some poorly designed but widely implemented software, Foo Bar,
> >  crashes and burns if an optional space is not present after the
> >  colon delimiting the field name from the field body.  Therefore,
> >  generators of messages which are also news articles SHOULD include
> >  a space after the colon.   Software which cannot handle lack of an
> >  optional space, an HTAB rather than space, etc., SHOULD be upgraded
> >  as soon as practicable.
> 
> No, there is no question of "SHOULD be upgraded as soon as practicable" as
> regards that SP after the colon. We have agreed long ago that was a step
> too far

No, we haven't, as a review of the WG archives makes clear.

> , and that decision is also now hard-coded into the 
> NNTP-standard-to-be which has just passed its IETF Last Call.

Nothing an NNTP draft could possibly say has any bearing on parsing
of the Internet Message Format, much less on whether or not such software
should be brought into conformance with the Internet Message Format
specification.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67K76gh054004 for <[e-mail]>; Thu, 7 Jul 2005 13:07:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67K76Ub054003 for ietf-usefor-skb; Thu, 7 Jul 2005 13:07:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67K75fi053996 for <[e-mail]>; Thu, 7 Jul 2005 13:07:05 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 07 Jul 2005 13:07:02 -0700 (PDT)
Cc: [e-mail], Ned Freed <[e-mail]>
To: Bruce Lilly <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 07 Jul 2005 12:58:04 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: RFC 2142 (was: Re: New USEPRO path-identity text)
In-reply-to: "Your message dated Thu, 07 Jul 2005 15:52:55 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

> On Thu July 7 2005 14:22, Ned Freed wrote:

> > I can name at least a dozen
> > different mail system implementations that provide everything that's needed for
> > a site to conform to every recommendation RFC 2142 makes.

> Maybe; one problem is that it's unclear exactly what is a recommendation
> and what is supposed to be a requirement.  The document uses MUST and
> RECOMMENDED (but w/o reference to RFC 2119), also "must" and phrases
> like "need to".

This document predates by a considerable margin the requirement that these
terms be precisely defined. (In fact it is pretty likely it was approved for
publication before RFC 2119 existed to refer to.)

This is also why the document didn't end up as a BCP - at the time it wasn't
entirely clear when to use BCP and when not to.

> [...]
> > This makes it next to impossible to construct a meaninfgul set of conformance
> > criteria, and absent such a set of criteria to measure implementations against
> > I see no way to advance the document to draft.
> [...]
> > But given how contentious even the simplest mail system operational
> > specifications have become in the IETF, I can also understand there being
> > no interest in reclassifying this document or, if you believe it truly
> > belongs on the proposed-draft-full track, advancing it.

> In its present form, it cannot be advanced.

This is true of the majority of documents we deal with, if for no other reason
than the references need updating and splitting.

> At minimum it would need a
> new I-D with a normative reference to BCP 14 and a substantial rewrite
> to clarify requirements vs. recommendations.  And that might or might
> not warrant recycling at Proposed.

The only thing that would warrant keeping this as proposed and not moving it to
BCP is if it came to specify an actual protocol or format. Since it specifies
nothing of the sort now it is axiomatic that this would be new material and
would require recycling. 

> It would also need to have the
> references classified into normative vs. informative and updated to
> current documents (most are obsolete).  The security considerations
> section would need work.

> Reclassification as Historic would seem feasible...

I for one would strongly object to any such attempt. I believe this document
specifies useful operational policies.

> at one time there
> was supposed to have been an effort towards bulk reclassification of
> documents stuck at PS or DS ("cruft") to historic.

When the effort started I predicted it would at best be marginally successful,
and I was proved right - only a few documents got reclassified. We have a large
number of documents for which the collective will to update doesn't seem to
exist, yet the documents clearly have a constituency behind them. I don't see
this changing, indeed, as the BS requirements continue to pile up, it is only
going to get worse.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67JrFnF051910 for <[e-mail]>; Thu, 7 Jul 2005 12:53:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67JrFcg051909 for ietf-usefor-skb; Thu, 7 Jul 2005 12:53:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67JrECj051902 for <[e-mail]>; Thu, 7 Jul 2005 12:53:14 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 48DC12993B; Thu,  7 Jul 2005 15:53:11 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67Jr8vM027120(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 15:53:08 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67Jr6WP027119(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 15:53:07 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: Bruce Lilly <[e-mail]>
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: RFC 2142 (was: Re: New USEPRO path-identity text)
Date: Thu, 7 Jul 2005 15:52:55 -0400
User-Agent: KMail/1.8.1
Cc: Ned Freed <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 7 2005 14:22, Ned Freed wrote:

> I can name at least a dozen
> different mail system implementations that provide everything that's needed for
> a site to conform to every recommendation RFC 2142 makes.

Maybe; one problem is that it's unclear exactly what is a recommendation
and what is supposed to be a requirement.  The document uses MUST and
RECOMMENDED (but w/o reference to RFC 2119), also "must" and phrases
like "need to".
[...]
> This makes it next to impossible to construct a meaninfgul set of conformance
> criteria, and absent such a set of criteria to measure implementations against
> I see no way to advance the document to draft.
[...]
> But given how contentious even the simplest mail system operational
> specifications have become in the IETF, I can also understand there being
> no interest in reclassifying this document or, if you believe it truly
> belongs on the proposed-draft-full track, advancing it.

In its present form, it cannot be advanced.  At minimum it would need a
new I-D with a normative reference to BCP 14 and a substantial rewrite
to clarify requirements vs. recommendations.  And that might or might
not warrant recycling at Proposed.  It would also need to have the
references classified into normative vs. informative and updated to
current documents (most are obsolete).  The security considerations
section would need work.

Reclassification as Historic would seem feasible...at one time there
was supposed to have been an effort towards bulk reclassification of
documents stuck at PS or DS ("cruft") to historic.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Ij06a045434 for <[e-mail]>; Thu, 7 Jul 2005 11:45:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67Ij0F8045433 for ietf-usefor-skb; Thu, 7 Jul 2005 11:45:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67IixpY045427 for <[e-mail]>; Thu, 7 Jul 2005 11:44:59 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id D3AB729910; Thu,  7 Jul 2005 14:44:58 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67IitO0026513(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 14:44:55 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67IiqBN026512(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 14:44:53 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Date: Thu, 7 Jul 2005 14:44:44 -0400
User-Agent: KMail/1.8.1
Cc: Graham Drabble <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Mon July 4 2005 18:00, Graham Drabble wrote:

> New implementations would have to code exceptions to cater for 
> something that everyone has been told they MUST NOT generate for four 
> years.

Not quite.  Compliance with RFC 2822, or any other RFC is voluntary.
Obviously there is a great deal of software (ca. 23% according to
Russ' analysis) that have not yet chosen to conform to RFC 2822.

> Existing parsing software would not need to change. 

And so why exactly would somebody try coding a parser from scratch
rather than using an existing, tested parser?
 
> The changes are that existing generating software MUST stop generating 
> the zone abreviations (which is in line with what 2822 told them), new 
> parseing sofware can be simpler and people are told what to do with 
> zones they don't recognise.

Let me get this straight.  You seem to think that handling some
46 valid offsets from -1200 to +1400 plus the special case exception
"GMT" is somehow simpler than handling those plus the 9 cases UT
and [ECMP][SD]T?   A hash table implementation can handle all of
those very simply and quickly, probably more so than any other
implementation; and such a hash table implementation already
exists as open source software.  So your argument, if I understand
what you seem to be asserting, simply doesn't hold water.

 > o FAQs and other old material may be periodically reposted with a
> > new 
> >   Injection-Date field, but with a Date field corresponding to the
> >   last change.  That applies to things like a response to "can
> >   somebody please post a copy of..." requests also.
> 
> That comes under the MUST NOT generate from 2822

No, it's not generated as new, just posted anew.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67IXnt9043964 for <[e-mail]>; Thu, 7 Jul 2005 11:33:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67IXn9k043963 for ietf-usefor-skb; Thu, 7 Jul 2005 11:33:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67IXmBc043955 for <[e-mail]>; Thu, 7 Jul 2005 11:33:48 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 07 Jul 2005 11:33:46 -0700 (PDT)
Cc: [e-mail]
To: Bruce Lilly <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 07 Jul 2005 11:22:07 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: RFC 2142 (was: Re: New USEPRO path-identity text)
In-reply-to: "Your message dated Thu, 07 Jul 2005 13:58:08 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <008301c581f8$86d1dc20$[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

> On Wed July 6 2005 03:00, Ruud H.G. van Tol wrote:
> >
> > Russ Allbery:
> >
> > > [abuse@]
> > > Given the amount of crap such mailboxes receive these days, I think
> > > you're fighting a lost battle by trying to perpetuate RFC 2142.  It's
> > > a nice idea that's very hard to implement in practice without taking
> > > up an immense amount of time.
> >
> > All mail to postmaster@ and abuse@, and then some, should be accepted.

> Postmaster, MUST.  The others, maybe (RFC 2142 in 8 years at Proposed
> hasn't gathered enough traction (a mere *two* implementations) to
> advance to Draft).

I read less than nothing into this. The problem here isn't that there are
insufficient "implementations" of RFC 2142 - I can name at least a dozen
different mail system implementations that provide everything that's needed for
a site to conform to every recommendation RFC 2142 makes.

Rather, te problem is that RFC 2142 is misclassified as proposed standard when
it should be a BCP. It specifies operational policies for mail systems having
certain characteristics. It doesn't specify a protocol, message format, or
anything similar, and as far as I can tell it imposes no requirements on mail
system software that aren't already imposed by other standards-track documents.
This makes it next to impossible to construct a meaninfgul set of conformance
criteria, and absent such a set of criteria to measure implementations against
I see no way to advance the document to draft.

Of course it is a separate question as to whether or not the recommendations
RFC 2142 makes are actually Best Current Practice. I tend to think they're
pretty close, but others may disagree.

But given how contentious even the simplest mail system operational
specifications have become in the IETF, I can also understand there being
no interest in reclassifying this document or, if you believe it truly
belongs on the proposed-draft-full track, advancing it.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67IODPO043249 for <[e-mail]>; Thu, 7 Jul 2005 11:24:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67IOD6t043248 for ietf-usefor-skb; Thu, 7 Jul 2005 11:24:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67IOCtR043241 for <[e-mail]>; Thu, 7 Jul 2005 11:24:13 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 1D7CB2992B; Thu,  7 Jul 2005 14:24:12 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67IO3Ax026375(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 14:24:03 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67INxvn026374(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 14:24:00 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Date: Thu, 7 Jul 2005 14:23:34 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 5 2005 15:03, Charles Lindsey wrote:

> I trawled through 17893 articles in my archive, and found 721 (4%) with
> naked IP addresses in them. Of these, 481 were one particular site
> (uni-berlin.de) whose injector routinely inserted the dial-in IP after the
> not-for-mail (the same as the NNTP-Posting-Host in fact). But that still
> leaves 240 (1.3%) with IP addresses in the middle.

1.3% is about the same the fraction of messages still using a subset of
RFC 561/680/724/733/822/2822 time zone abbreviations.

[...]
> But I still think we have to allow it, for a variety of odd cases,

Do try to be consistent.  If that 1.3 percent warrants handling
IP addresses, then surely the same 1.3 percent warrants handling
the [ECMP][DS]T zone abbreviations.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67I8d5d041775 for <[e-mail]>; Thu, 7 Jul 2005 11:08:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67I8dkR041774 for ietf-usefor-skb; Thu, 7 Jul 2005 11:08:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67I8c2n041767 for <[e-mail]>; Thu, 7 Jul 2005 11:08:38 -0700 (PDT) (envelope-from [e-mail])
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id E40E158B3F for <[e-mail]>; Thu,  7 Jul 2005 14:08:37 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j67I8br09783; Thu, 7 Jul 2005 14:08:37 -0400 (EDT)
Date: Thu, 7 Jul 2005 14:08:37 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Bruce Lilly on Thu, 7 Jul 2005 13:31:36 -0400)
Subject: Re: =?us-ascii*la?q?Re:_?= Semantic header (field) Content
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly <[e-mail]> wrote:

["Re"]

> 1. You have maintained that it is Latin,

It is Latin.  It has been borrowed into English and some other
languages as well.

Seth



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67HwT5v040662 for <[e-mail]>; Thu, 7 Jul 2005 10:58:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67HwTsu040661 for ietf-usefor-skb; Thu, 7 Jul 2005 10:58:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns2.townisp.com (ns2a.townisp.com [216.195.0.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67HwSII040653 for <[e-mail]>; Thu, 7 Jul 2005 10:58:29 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns2.townisp.com (Postfix) with ESMTP id C5DC82991D for <[e-mail]>; Thu,  7 Jul 2005 13:58:27 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67HwNxF026171(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 13:58:24 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67HwJVB026170(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 13:58:21 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: RFC 2142 (was: Re: New USEPRO path-identity text)
Date: Thu, 7 Jul 2005 13:58:08 -0400
User-Agent: KMail/1.8.1
References: <[e-mail]> <[e-mail]> <008301c581f8$86d1dc20$[e-mail]>
In-Reply-To: <008301c581f8$86d1dc20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 6 2005 03:00, Ruud H.G. van Tol wrote:
> 
> Russ Allbery:
> 
> > [abuse@]
> > Given the amount of crap such mailboxes receive these days, I think
> > you're fighting a lost battle by trying to perpetuate RFC 2142.  It's
> > a nice idea that's very hard to implement in practice without taking
> > up an immense amount of time.
> 
> All mail to postmaster@ and abuse@, and then some, should be accepted.

Postmaster, MUST.  The others, maybe (RFC 2142 in 8 years at Proposed
hasn't gathered enough traction (a mere *two* implementations) to
advance to Draft).

None of which has any relationship to the Path field, and none of which
is necessary; the Injection-Info field has provision for indicating
where complaints should be sent, and if a site wants complaints to be
sent to "[e-mail]" rather than some mailbox with "abuse" in
the local-part, or to a mailbox with a local-part of "misbruik" instead
of "abuse", that's arguably their business.  If anybody actually goes
through the trouble to manually extract that optional information from
that optional field, they can send complaints to the suggested place.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67HWF1Y038897 for <[e-mail]>; Thu, 7 Jul 2005 10:32:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67HWFYm038896 for ietf-usefor-skb; Thu, 7 Jul 2005 10:32:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67HWEeB038889 for <[e-mail]>; Thu, 7 Jul 2005 10:32:15 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id DFA1F29933; Thu,  7 Jul 2005 13:32:13 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67HW552025937(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 13:32:10 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67HW370025936(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 13:32:05 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: =?us-ascii*la?q?Re:_?= Semantic header (field) Content
Date: Thu, 7 Jul 2005 13:31:36 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j67HWFeB038890
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 6 2005 15:07, Charles Lindsey wrote:

> 1. There are some discouraging remarks concerning the ancient practice of
> using a Subject beginning with "cmsg" to be interpreted as a control
> message (where there is not a genuine Control header as well, of course).
> 
> For this purpose, does the discouragement need to include the case where
> the "cmsg" is hidden inside an encoded-word? I would presume not, since I
> doubt any existing software which tries to interpret "cmsg" in that way
> was smart enough to detect it when inside an encoded-word.

1. "[RFC4096]" covers most of the issues
2. A remaining issue is that the current specification (RFC 1036)
  *requires* interpretation as a control message.  We ought to point
  out that since 1036, that has been found to be problematic (citing
  specifics) and that best *current* (but unpublished) practice has for
  some time been to ignore it, and that the document specification
  continues that practice.

> 2. A followup agent is permitted (MAY) to prepend a "Re: " to the Subject
> if there is not one there already. Is it to be permitted to enclose that
> "Re: " within an encoded-word (I would hope not, because there is no 
> benefit in doing so, and it is not done in current practice AFAIK).

Another falsehood:
1. You have maintained that it is Latin, and best current practice
   (BCP 18, RFC 2277 for Frank) is to indicate language, and RFC 2047
   is the standard method for doing so.  Particularly where the remainder
   of the subject field is *not* Latin, which is the vast majority of
   cases.  That is a clear benefit.  Of course, if you would like to
   retract the "it's Latin" assertion, we can dicuss the implications of
   that change in your position.
2. It has in fact happened in messages here, and you know that to be
   the case because it has been discussed here.
3. Treating some string in an unstructured field as if it were a keyword
   imposes structure on that field; we have had that discussion and the
   WG consensus was that the field is strictly unstructured.
4. There is not any reason to restrict what is put in an "only human-
   readable", "unstructured" field;
   Subject: =?us*la?q?Re:_?= Re: =?us*en?q?_the_note_between_?= Do & Mi
   Subject: =?us*la?q?Re:_?= Re: =?us*en?q?_element_number_?= 75
   Subject: =?us*la?q?Re:_?= RE: Re: =?us*en?q?_The_note_between_?= Do & Mi
     =?_according_to_?= Raoul Edwards
   Subject: cmsg was a really bad idea
   Subject: =?us*en?q?cmsg_was_a_really_bad_idea?=
   Subject: =?us*la?q?Re:_?= =?us*en?q?cmsg_was_a_really_bad_idea?=
   Subject: =?us*la?q?Re:_?= RE: Raoul Edwards
     =?us*en?q?_says_cmsg_was_a_really_bad_idea?=
   are perfectly valid and reasonable.
 
> More 
> to the point, however, is whether it is expected to decode an initial
> encoded-word before detecting whether an initial "Re: " is there already
> (I would not expect that to happen often - has anyone ever seen such a
> thing - but you never know).

As already mentioned, it has happened here and has been discussed here.
Also:
5. The only reason to "detect" anything in an unstructured, only
   human-readable field is to detect an encoded-word, and the only
   reasons to do so are for display and for non-protocol, out-of-scope
   issues where treatment as displayed might be appropriate such as
   killfile processing and sorting by subject.

> Essentially, I can get either interpretation by saying that the "semantic
> content" is what you get after/before decoding any encoded-words.

In neither case do we need any such term.
  
> Note that USEAGE says you SHOULD decode encoded-words before trying to do
> anything clever with a Subject header, but that is just a matter of being
> prudent - we don't necessarily want to write that into USEPRO.

Since by definition ("only human-readable content") unstructured fields
play no role in protocol (as we have agreed by consensus), not only do we
not want to write any such thing in USEPRO, we cannot do so because that
is a protocol document, and there is no protocol issue.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67HOHFA038355 for <[e-mail]>; Thu, 7 Jul 2005 10:24:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67HOHAJ038354 for ietf-usefor-skb; Thu, 7 Jul 2005 10:24:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67HOGUf038340 for <[e-mail]>; Thu, 7 Jul 2005 10:24:16 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j67HOAND025179 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 7 Jul 2005 10:24:11 -0700 (PDT)
Date: Thu, 7 Jul 2005 10:24:10 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>   4.   Some other (arbitrary) name believed to be unique and registered
>        at least with all other news-servers sending articles directly
>        to the given one. The news-server administrator is responsible
>        for choosing an appropriate name (and will bear the consequences
>        of an inappropriate choice). 

Dear USENET admin:

Don't do what we say you can or you might be sorry!

Sincerely,
USEFOR Working Group



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67DLLBK097854 for <[e-mail]>; Thu, 7 Jul 2005 06:21:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67DLL5B097853 for ietf-usefor-skb; Thu, 7 Jul 2005 06:21:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67DLIJ0097825 for <[e-mail]>; Thu, 7 Jul 2005 06:21:18 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id 399AC29937; Thu,  7 Jul 2005 09:21:15 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67DL9DU024221(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 09:21:11 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67DL5OK024220(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 09:21:06 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Thu, 7 Jul 2005 09:20:57 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 7 2005 07:00, Charles Lindsey wrote:
> All right:
> 
>    4.   Some other (arbitrary) name believed to be unique and registered
>         at least with all other news-servers sending articles directly
>         to the given one. The news-server administrator is responsible
>         for choosing an appropriate name (and will bear the consequences
>         of an inappropriate choice). This option SHOULD NOT be used
>         unless the earlier options are unavailable (e.g. because the
>         host in question is not connected to the Internet), or unless it
>         is of longstanding usage and cessation would be unduly
>         disruptive.

All wrong:
a) a belief of uniqueness and uniqueness are two different things.
   Uniqueness is supposedly a requirement, not a mere nicety.
b) "arbitrary" is incorrect; "a!b:c^d@e%f" won't work.
c) while you have added senders, you have removed receivers, and that
   could cause retransmissions, which is harmful. "neighbors" might
   cover both, but might warrant a full explanation at first use.
d) in the case of retransmission, the consequences are also borne by
   the receiving system, so "will bear the consequences" is incorrect
   as it stands.
e) being connected to the Internet is not a requirement for having a
   domain name, and the scope of our documents is the Internet, as it
   is supposed to be an Internet Standards Track specification for a
   format and protocol suite for use on the Internet; what non-Internet
   sites do or do not do is out of scope.
f) the last phrase is vague -- does 1 month count as "longstanding usage";
   it's longer than the TTL of most DNS responses?   In view of the
   uniqueness *requirement*, how much disruption constitutes "unduly
   disruptive"?  We are supposed to be writing a clear specification,
   and we cannot do so using such vague terms as vague is the opposite
   of clear.

We should restrict names to fully-qualified domain names for the purpose
of this specification.  The specification might warrant a note about
names associated with non-Internet sites that leak onto the Internet in
a Path field as the result of a link between a non-Internet site and an
Internet site.

We might possibly go so far as to make such Internet sites responsible
for the uniqueness of their connected non-Internet neighbors, and we
could do so for example by using '@' as the Path separator for Internet
sites, using '!' or '%' for UUCP sites connected to an Internet site,
':' for DECnet sites etc., which is basically how RFC 850/RFC 1036 paths
are formed.  For example, "FQDN.example.net!wolf!hither!yon" in Path,
considering @ as the Internet delimiter means that an article passed
onto the Internet at site FQDN.example.net, which received it from its
neighbor known as "wolf", etc. for tracing purposes.  For abuse-reporting
purposes, as there is no way to contact the administrators of "wolf",
"hither" or "yon" from the Internet, abuse complaint forwarding would
be handled by FQDN.example.com, who presumably knows how to contact
the administrators of "wolf", who presumably know how to contact the
administrators of "hither, etc.   While I could support something like
that, I think it goes farther than is necessary for an Internet
Standards Track specification, as abuse reporting is an operational
issue rather than a technical specification matter.  It might be
something for USEAGE.  If we intend to go that route, we should
consider the syntax, semantics, and protocol implications now, since
our immediate task is finishing the syntax and semantics document.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67CZ8xw079811 for <[e-mail]>; Thu, 7 Jul 2005 05:35:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67CZ880079810 for ietf-usefor-skb; Thu, 7 Jul 2005 05:35:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67CZ7mL079800 for <[e-mail]>; Thu, 7 Jul 2005 05:35:07 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 1DB4929921; Thu,  7 Jul 2005 08:35:05 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67CZ3t4023938(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 08:35:03 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67CZ11G023937(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 08:35:02 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Thu, 7 Jul 2005 08:34:51 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Thu July 7 2005 06:48, Charles Lindsey wrote:
> 
> In <[e-mail]> Bruce Lilly <[e-mail]> writes:
> 
> >On Tue July 5 2005 15:32, Charles Lindsey wrote:
> 
> >> I don't think it really matters for Xref, though one would normally expect
> >> it to be the same. The MUST for the opther two cases is there to give less
> >> scope for trolls and malefactors.
> 
> >BCP 14 says nothing about "trolls and malefactors".  The requirements
> >for use of MUST appear in BCP 14 section 6 (Frank, that's RFC 2119).
> 
> But it says you may use MUST wording to avoid causing harm (such as
> potential security problems).

To be precise, it says "MUST only be used", not "may".   The cases where
an imperative causes harm is illustrated by the case of retransmissions.
Security matters are discussed in BCP 14 section 7, where the additional
onus is placed on a specification writer: "Document authors should take
the time to elaborate the security implications of not following
recommendations or requirements as most implementors will not have had
the benefit of the experience and discussion that produced the 
specification".  Note that the section 6 requirement discusses harm to
the Internet (retransmissions consume everybody's bandwidth), not harm
(security-related or otherwise) which might affect only a non-conforming
system.  Section 7 considerations apply to recommendations as well as
to imperatives.

When you wish to justify use of a BCP 14 imperative, kindly do so
in terms which BCP 14 covers in section 6, with documentary support
for any assertions that you make.  Lacking any supported justification,
at most a recommendation would be warranted.  If you wish to invoke a
security consideration, please also "elaborate the security implications",
preferably in the form of text suitable for inclusion in the document.

And the reason for "MUST" in the proposed text is...? [note that
Injection-Info's defined semantics are for tracing; it plays no role
in protocol or interoperability. also note that BCP 14 section 6
specifically states that imperative keywords "must not be used to try
to impose a particular method on implementors where the method is not
required for interoperability"] 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BwC8j062343 for <[e-mail]>; Thu, 7 Jul 2005 04:58:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67BwC45062342 for ietf-usefor-skb; Thu, 7 Jul 2005 04:58:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BwAR7062322 for <[e-mail]>; Thu, 7 Jul 2005 04:58:11 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1DqV16-000JES-7n; Thu, 07 Jul 2005 11:58:08 +0000
Message-ID: <[e-mail]>
Date: Thu, 7 Jul 2005 12:56:59 +0100
To: Charles Lindsey <[e-mail]>
Cc: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <zZ$$+z3$77$$tPKL26Y+dershQ>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes

>All right:
>
>   4.   Some other (arbitrary) name believed to be unique and registered
>        at least with all other news-servers sending articles directly
>        to the given one. The news-server administrator is responsible
>        for choosing an appropriate name (and will bear the consequences
>        of an inappropriate choice). This option SHOULD NOT be used
>        unless the earlier options are unavailable (e.g. because the
>        host in question is not connected to the Internet), or unless it
>        is of longstanding usage and cessation would be unduly
>        disruptive.

addresses my point, thanks

for preference I'd remove the second sentence altogether, it adds
nothing of any real significance

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

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQs0Yi5oAxkTY1oPiEQLUAACg0rq4j9knAICH9Z4/fywWMJigkaMAn2xc
jcwauQ54JWRgmNWQoz8CeZtv
=uxA3
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw56c062272 for <[e-mail]>; Thu, 7 Jul 2005 04:58:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67Bw5DB062271 for ietf-usefor-skb; Thu, 7 Jul 2005 04:58:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw3Of062238 for <[e-mail]>; Thu, 7 Jul 2005 04:58:04 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-3.midband.mdip.bt.net ([81.144.71.3]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cd18ca.667d.45 for [e-mail]; Thu,  7 Jul 2005 12:58:02 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j67BueU18775 for [e-mail]; Thu, 7 Jul 2005 12:56:40 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21948
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 7 Jul 2005 11:33:08 GMT
Lines: 65
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Bruce Lilly wrote:

>> BCP 14 section 6 (Frank, that's RFC 2119).

>Yep, thanks.  

>> "Sites MUST NOT use an IP address except for diagnostic
>>  purposes in conjunction with the MISMATCH keyword."

>So that's Harald's idea.  Okay, then extracting all IPs
>from the <path-identity> syntax could make sense.  Maybe
>we could also split "traditional name" from mailable FQDN:

It is clear that IP addresses DO occur in Paths for a variety of reasons,
and will continue to do so (and that will inevitably include IPv6
addresses when servers start to use them). These occurrences do not
necessarily indicate MISMATCHes, though I agree that a lot of them are
diagnostic. I doubt current relaying agents treat them any differently
than other path-identities (i.e. if you write in your "sys" file "do not
relay to this IP address", then an article with it already in its Path
won't get relayed).

So there is no interoperability that is going to arise to justify that
MUST NOT; so it seems like a classic case of SHOULD NOT to me - recipients
must not choke on them it they appear, but they still should not be used
because (nearly always) there are better alternatives.

But there is a general expectation throughout the Internet (reinforced by
provisions in many standards) that an IP address can be used in any
context where a domain-name can be used. It may be unwise, and cause for a
SHOULD NOT, but I do not think it should be forbidden entirely.

And the remote possibility of problems labelled "dead" or "beef" will
still be there, even if IPv6 addresses are only used for diagnostic
purposes, so the NOTE after #4 to warn against that is still needed.

>"Traditional name" has no dots, it can have underscores.

Actually, the syntax (both Harald's version or mine) is ambiguous; that
needs to be fixed (probably by a comment after ';' in the ABNF).


>ACK, but I don't see the point of using the MX at all, if
>that's a trick for UUCP hosts at most one of these hosts
>behind the same MX can use it, otherwise they'd clash.

It's nothing to do with UUCP at all. If the actual entry in the Path is
"newshost-5.example.com", it may be that that actual host does not listen on
Port 25. Therefore the admin may well prefer to put just "example.com" as
his path-identity, where "example.com" is an MX pointing to
mailhost.example.com (which understands what to do with "news@",
"usenet@", and even "abuse@").

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw4Nq062258 for <[e-mail]>; Thu, 7 Jul 2005 04:58:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67Bw4Jo062255 for ietf-usefor-skb; Thu, 7 Jul 2005 04:58:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw3fE062216 for <[e-mail]>; Thu, 7 Jul 2005 04:58:03 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-3.midband.mdip.bt.net ([81.144.71.3]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cd18c9.667d.43 for [e-mail]; Thu,  7 Jul 2005 12:58:01 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j67BufV18782 for [e-mail]; Thu, 7 Jul 2005 12:56:41 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21949
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: News URIs (was New USEPRO path-identity text)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]>                 <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 7 Jul 2005 11:43:35 GMT
Lines: 35
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Russ Allbery wrote:

>> Charles (and I) want wildmat in news URLs because existing
>> browsers already support them and the behavior is useful.

>IBTD.  It's very different from the original URL, and I've no
>convincing ideas where I would want a subset of newsgroups in
>a news URL.  Maybe news:de.soc.recht.* or news:*.net-abuse.*

A bit off topic for this group, but never mind.

"news:*.test" is the example I usually give.

>But all the other wild and woderful constructs in a news URL,
>who needs this, which UAs support it ?  "?" has to be encoded
>as %3E.  Comma, backslash, or exclamation mark are also very
>different from RfC 1738, and maybe backslash must be encoded.

There is no need to encode "?" according to my draft.

There is never a requirement to encode "\" in RFC 3986, and not for "," or
"!" unless some scheme goes out of its way to require it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw4sV062256 for <[e-mail]>; Thu, 7 Jul 2005 04:58:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67Bw43n062254 for ietf-usefor-skb; Thu, 7 Jul 2005 04:58:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw32U062221 for <[e-mail]>; Thu, 7 Jul 2005 04:58:03 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-3.midband.mdip.bt.net ([81.144.71.3]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cd18ca.667d.44 for [e-mail]; Thu,  7 Jul 2005 12:58:02 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j67BuhW18793 for [e-mail]; Thu, 7 Jul 2005 12:56:43 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21951
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Semantic header (field) Content
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Date: Thu, 7 Jul 2005 11:54:03 GMT
Lines: 39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Charles Lindsey <[e-mail]> writes:

>> For this purpose, does the discouragement need to include the case where
>> the "cmsg" is hidden inside an encoded-word?

>No.

>> 2. A followup agent is permitted (MAY) to prepend a "Re: " to the
>> Subject if there is not one there already. Is it to be permitted to
>> enclose that "Re: " within an encoded-word ...

>My reading of RFC 2822 indicates no.

>> More to the point, however, is whether it is expected to decode an
>> initial encoded-word before detecting whether an initial "Re: " is there
>> already (I would not expect that to happen often - has anyone ever seen
>> such a thing - but you never know).

>I don't think it should be required, although an implementation should be
>allowed to do so if it wishes to, I think.

OK, I agree with all that (and AFAIR that was our position when we last
discussed it - i.e. we agreed that the only mention/advice should go into
USEAGE). Frank seems to agree.

So that is what I shall do unless I hear loud screams otherwise.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw3b6062235 for <[e-mail]>; Thu, 7 Jul 2005 04:58:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67Bw3gC062234 for ietf-usefor-skb; Thu, 7 Jul 2005 04:58:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67Bw1v2062210 for <[e-mail]>; Thu, 7 Jul 2005 04:58:02 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-71-3.midband.mdip.bt.net ([81.144.71.3]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cd18c8.667d.42 for [e-mail]; Thu,  7 Jul 2005 12:58:00 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j67Bugr18787 for [e-mail]; Thu, 7 Jul 2005 12:56:42 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21950
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: RFC 2142
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> 	<008301c581f8$86d1dc20$[e-mail]> <[e-mail]>
Date: Thu, 7 Jul 2005 11:47:35 GMT
Lines: 33
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Ruud H G van Tol <[e-mail]> writes:

>> So no, I don't agree it's a lost battle. It shouldn't take up extra
>> time, as the line of defense is very much the same as with any other
>> address.

>There's just almost no actual signal and an order of magnitude more junk.
>I appreciate the desire to do the right thing, and I'm not speaking from a
>perspective of what I do personally.  I'm just saying that from a
>practical standpoint, I think the handwriting is already on the wall, even
>if us clued folks can deal with the noise.

I agree with Ruud. We should try to continue to support RFC 2142.

>Given that we get maybe one legitimate message to postmaster every couple
>of weeks, it's hard to justify the time and effort required to make it
>readable.

Maybe that's because your mail service is so well run that nobody ever has
to complain about it :-) .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BuP2r061541 for <[e-mail]>; Thu, 7 Jul 2005 04:56:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67BuPu5061540 for ietf-usefor-skb; Thu, 7 Jul 2005 04:56:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BuOie061531 for <[e-mail]>; Thu, 7 Jul 2005 04:56:25 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 2ED612990F; Thu,  7 Jul 2005 07:56:24 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j67BuMs3023615(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Thu, 7 Jul 2005 07:56:23 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j67BuJdI023614(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 7 Jul 2005 07:56:20 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Thu, 7 Jul 2005 07:55:58 -0400
User-Agent: KMail/1.8.1
Cc: Bill McQuillan <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed July 6 2005 02:41, Bill McQuillan wrote:
> 
> On Tue, 2005-07-05, Bruce Lilly wrote:

> >    Each MX matches a domain name with two pieces of data, a
> >    preference value (an unsigned 16-bit integer), and the name of a
> >    host.  The preference number is used to indicate in what order the
> >    mailer should attempt deliver to the MX hosts, with the lowest
> >    numbered MX being the one to try first.
> 
> From this quote, I understand that an MX "domain" does NOT identify "a
> host" but rather a semi-ordered "set of hosts", any one of which could be
> the actual recipient of an email to the MX "domain".

Each MX record identifies a host (by domain name) and associates an
integer preference value with that host for Mail eXchange purposes.

In a nutshell, mail delivery works with MX resource records as follows:
1. look up MX records for the domain name associated with a mailbox
2. each MX record identifies a host which accepts mail for that domain and
   gives a preference value
3. the sender removes its own host name if present in the list, then
   attempts to contact MX hosts in order of preference

Example:
# nslookup -sil -type=mx ietf.org. ns2.cw.net.
Server:         ns2.cw.net.
Address:        204.70.57.242#53

ietf.org        mail exchanger = 10 ietf-mx.ietf.org.
ietf.org        mail exchanger = 20 mx2.foretec.com.

That lists 2 MX records for the domain ietf.org.  The two MX hosts
are ietf-mx.ietf.org and mx2.foretec.com:
Name:   ietf-mx.ietf.org
Address: 132.151.6.1

Name:   mx2.foretec.com
Address: 65.246.255.50

> Does you mean that only one of the hosts in such a "set of hosts" may run a
> news relay?

No, but the uniqueness requirement and the desirability of making 
diagnostic checks (e.g. for MISMATCH) workable means that each
host needs to use its own host name (which also has an A record).

It probably wouldn't be a good idea to run a news relay and an
SMTP MX MTA on the same host anyway; both services use a lot of
resources.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BFBBM042991 for <[e-mail]>; Thu, 7 Jul 2005 04:15:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67BFB31042988 for ietf-usefor-skb; Thu, 7 Jul 2005 04:15:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BFAFg042971 for <[e-mail]>; Thu, 7 Jul 2005 04:15:10 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-66-114.midband.mdip.bt.net ([81.144.66.114]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cd0ebd.163a7.a7 for [e-mail]; Thu,  7 Jul 2005 12:15:09 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j67BCGc17855 for [e-mail]; Thu, 7 Jul 2005 12:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21947
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Thu, 7 Jul 2005 11:00:41 GMT
Lines: 41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes
>>
>>But can you tell me how to define "traditional" as a technical term?

>you don't -- what you say is something along the lines of what Harald
>wrote; which was that the requirement is for uniqueness, that an FQDN is
>the only thing that will now have a good chance of providing that
>property; but that nevertheless some existing sites have a working
>scheme, loosely based on the UUCP maps and that this means that they
>have to ensure that their direct peers are aware of this

>viz: you are more descriptive and less proscriptive

All right:

   4.   Some other (arbitrary) name believed to be unique and registered
        at least with all other news-servers sending articles directly
        to the given one. The news-server administrator is responsible
        for choosing an appropriate name (and will bear the consequences
        of an inappropriate choice). This option SHOULD NOT be used
        unless the earlier options are unavailable (e.g. because the
        host in question is not connected to the Internet), or unless it
        is of longstanding usage and cessation would be unduly
        disruptive.

That's a bit like Harald's reference to "existing" newsgroup-names with
all-digit components, and the like.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BFBZ6042992 for <[e-mail]>; Thu, 7 Jul 2005 04:15:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j67BFBwT042990 for ietf-usefor-skb; Thu, 7 Jul 2005 04:15:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j67BFAll042967 for <[e-mail]>; Thu, 7 Jul 2005 04:15:10 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-66-114.midband.mdip.bt.net ([81.144.66.114]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cd0ebc.163a7.a6 for [e-mail]; Thu,  7 Jul 2005 12:15:08 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j67BCFK17845 for [e-mail]; Thu, 7 Jul 2005 12:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21946
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 7 Jul 2005 10:48:18 GMT
Lines: 24
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Tue July 5 2005 15:32, Charles Lindsey wrote:

>> I don't think it really matters for Xref, though one would normally expect
>> it to be the same. The MUST for the opther two cases is there to give less
>> scope for trolls and malefactors.

>BCP 14 says nothing about "trolls and malefactors".  The requirements
>for use of MUST appear in BCP 14 section 6 (Frank, that's RFC 2119).

But it says you may use MUST wording to avoid causing harm (such as
potential security problems).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j673I2Zo079858 for <[e-mail]>; Wed, 6 Jul 2005 20:18:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j673I2Cq079857 for ietf-usefor-skb; Wed, 6 Jul 2005 20:18:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j673I2bi079851 for <[e-mail]>; Wed, 6 Jul 2005 20:18:02 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j673I1xU024178 for <[e-mail]>; Wed, 6 Jul 2005 20:18:01 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 238CBE7CB0; Wed,  6 Jul 2005 20:18:01 -0700 (PDT)
To: [e-mail]
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]> (Frank Ellermann's message of "Thu, 07 Jul 2005 05:07:34 +0200")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 06 Jul 2005 20:18:00 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann <[e-mail]> writes:

> IBTD.  It's very different from the original URL, and I've no
> convincing ideas where I would want a subset of newsgroups in
> a news URL.  Maybe news:de.soc.recht.* or news:*.net-abuse.*

Right, this is the part that I care about.

> But all the other wild and woderful constructs in a news URL,
> who needs this, which UAs support it ?  "?" has to be encoded
> as %3E.

Does it?  I thought it did too, but then when I looked I couldn't find any
provision that would actually require it.

> Comma, backslash, or exclamation mark are also very different from RfC
> 1738, and maybe backslash must be encoded.

Personally, I don't really care if all that stuff works.  I just want * to
work, and with the standard semantics, but including wildmat by reference
is a straightforward way of doing that without repeating the
specification.  As you say, I'm not aware of an implementation that
supports ?, !, or comma.

\ is not allowed in wildmats except as part of an INN extension, so you
don't have to worry about it for URLs.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j673APXY078811 for <[e-mail]>; Wed, 6 Jul 2005 20:10:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j673APcJ078809 for ietf-usefor-skb; Wed, 6 Jul 2005 20:10:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j673AMD2078796 for <[e-mail]>; Wed, 6 Jul 2005 20:10:23 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqMmI-0000PH-NM for [e-mail]; Thu, 07 Jul 2005 05:10:18 +0200
Received: from du-001-087.access.de.clara.net ([212.82.227.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 07 Jul 2005 05:10:18 +0200
Received: from nobody by du-001-087.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 07 Jul 2005 05:10:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Thu, 07 Jul 2005 05:07:34 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-087.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery wrote:

> Charles (and I) want wildmat in news URLs because existing
> browsers already support them and the behavior is useful.

IBTD.  It's very different from the original URL, and I've no
convincing ideas where I would want a subset of newsgroups in
a news URL.  Maybe news:de.soc.recht.* or news:*.net-abuse.*

But all the other wild and woderful constructs in a news URL,
who needs this, which UAs support it ?  "?" has to be encoded
as %3E.  Comma, backslash, or exclamation mark are also very
different from RfC 1738, and maybe backslash must be encoded.

STD 66 is not exactly straight forward about some characters,
backslash is one of these cases where I'm not sure.  And it
is an unnecessary pain, no newsgroup name contains e.g. ? and
so \? and the six others \\, \!, \*, \, \[ \] are not needed.

                         Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j672FShO073130 for <[e-mail]>; Wed, 6 Jul 2005 19:15:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j672FSnh073129 for ietf-usefor-skb; Wed, 6 Jul 2005 19:15:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j672FPgX073115 for <[e-mail]>; Wed, 6 Jul 2005 19:15:26 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqLui-0004GI-Kr for [e-mail]; Thu, 07 Jul 2005 04:14:56 +0200
Received: from du-001-087.access.de.clara.net ([212.82.227.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 07 Jul 2005 04:14:56 +0200
Received: from nobody by du-001-087.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 07 Jul 2005 04:14:56 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Semantic header (field) Content
Date:  Thu, 07 Jul 2005 04:12:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: du-001-087.access.de.clara.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> I am now reviewing the definition of semantic content that
> I proposed when revising the mechanisms for constructing
> References headers.

Better stay away from this idea, all you need is CFWS => FWS
in this case.

> does the discouragement need to include the case where
> the "cmsg" is hidden inside an encoded-word? I would presume
> not

ACK, RfC 1036 is much older than RfC 2047 and its predecessors.
Dito the "Re: " business.  In s-o-1036 it's IMO obvious that
"Re: " and "cmsg " are meant as is, not in MIME-encoded forms.

> Essentially, I can get either interpretation by saying that
> the "semantic content" is what you get after/before decoding
> any encoded-words.

Any semantics important for the transport / injection normally
works without decoding MIME-encoded words.  That's AFAIK the
point of MIME, it still works if all agents between the end-
points have no idea what it means.  So they also don't decode
or encode header fields, only a gateway could pull this stunt.

                         Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66Nk4XY056823 for <[e-mail]>; Wed, 6 Jul 2005 16:46:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66Nk4eq056822 for ietf-usefor-skb; Wed, 6 Jul 2005 16:46:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66Nk39l056814 for <[e-mail]>; Wed, 6 Jul 2005 16:46:03 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j66Nk2GY012192 for <[e-mail]>; Wed, 6 Jul 2005 16:46:03 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 934EBE7CB0; Wed,  6 Jul 2005 16:46:02 -0700 (PDT)
To: Usefor Mailing List <[e-mail]>
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]> (Henry Spencer's message of "Wed, 6 Jul 2005 19:38:35 -0400 (EDT)")
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 06 Jul 2005 16:46:02 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Henry Spencer <[e-mail]> writes:
> On Tue, 5 Jul 2005, Russ Allbery wrote:

>>> Does it?  Some mailers insist on MX records, and won't mail to A
>>> records.  (That seems to be happening, anyway.)

>> Please do tell.  Such a mailer would be completely unable to send mail to
>> multiple systems that I run...

> Alas, this seems to be for real... although fortunately it's not common. 

Personally, I'm content for such broken software to simply lose when
attempting to contact a news server administrator to report problems.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66NcgH9056231 for <[e-mail]>; Wed, 6 Jul 2005 16:38:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66NcgMn056230 for ietf-usefor-skb; Wed, 6 Jul 2005 16:38:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66NcfW4056223 for <[e-mail]>; Wed, 6 Jul 2005 16:38:41 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j66NcaF1004925; Wed, 6 Jul 2005 19:38:36 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j66NcacX004924; Wed, 6 Jul 2005 19:38:36 -0400 (EDT)
Date: Wed, 6 Jul 2005 19:38:35 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue, 5 Jul 2005, Russ Allbery wrote:
> > Does it?  Some mailers insist on MX records, and won't mail to A
> > records.  (That seems to be happening, anyway.)
> 
> Please do tell.  Such a mailer would be completely unable to send mail to
> multiple systems that I run...

Alas, this seems to be for real... although fortunately it's not common. 

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66JPfnu035398 for <[e-mail]>; Wed, 6 Jul 2005 12:25:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66JPf5K035397 for ietf-usefor-skb; Wed, 6 Jul 2005 12:25:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66JPc42035386 for <[e-mail]>; Wed, 6 Jul 2005 12:25:41 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail02.peak.org (8.12.10/8.12.8) with ESMTP id j66JPSND042411 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 6 Jul 2005 12:25:33 -0700 (PDT)
Date: Wed, 6 Jul 2005 12:25:23 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>It is clear that routers on the Internet are configured to route packets
>to the sites which officially own the IP addresses as allocated by the
>processes established by ICANN.

I don't think it is so clear. There are a lot of routers that route
packets for a large number of addresses to the wrong place deliberately.
For addresses belonging to domains such as doubleclick.net, for example.
And, of course, many of the routers in China deliberately route a large
number of addresses to the wrong place.

About the best you could say is "an IP address .. that is in the routable 
address blocks as defined in RFCxxxx", where RFCxxx is the RFC that 
defines the non-routable addresses.

>That ticket is still open, and under discussion.

I neither know nor care what discussion is taking place on the "ticket
system". I know and care what discussion is taking place here, and here is
it very quiet concerning the problem. Nobody I've seen has bothered to
mention the lack of a colon in the last proposed text, that indicates a
consensus to me.

>I don't think the world out there is going to accept any encoding of IPv6
>addresses other than the one currently in widespread use (as defined in
>RFC 3986 as well as lots of other places).

Of course they will "accept it". Why wouldn't they? It's not like they 
have to type the thing in every time they post an article.

   2.   An encoding of an IP address - <IPv4address> or <IPv6address> - 
        [RFC 3986] which SHOULD be a publicly recognized address 

I publicly recognize 192.168.0.1, but it is not routable and its use as a 
path-identity is questionable.

                                     To ensure that a <path-identity>
   provides a unique identity for the news-server concerned, it should
   be one of:

>Are people happy with that?

If you are happy that you haven't ensured that the path-identity is 
unique despite your statement to the contrary, I'm happy.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66JLZeV035020 for <[e-mail]>; Wed, 6 Jul 2005 12:21:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66JLZSd035019 for ietf-usefor-skb; Wed, 6 Jul 2005 12:21:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66JLYPk035013 for <[e-mail]>; Wed, 6 Jul 2005 12:21:34 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j66JLXVo029902 for <[e-mail]>; Wed, 6 Jul 2005 12:21:33 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 640FCE7CB0; Wed,  6 Jul 2005 12:21:33 -0700 (PDT)
To: [e-mail]
Subject: Re: Semantic header (field) Content
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Wed, 6 Jul 2005 19:07:15 GMT")
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 06 Jul 2005 12:21:33 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j66JLYPk035014
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:

> 1. There are some discouraging remarks concerning the ancient practice
> of using a Subject beginning with "cmsg" to be interpreted as a control
> message (where there is not a genuine Control header as well, of
> course).

> For this purpose, does the discouragement need to include the case where
> the "cmsg" is hidden inside an encoded-word?

No.

> 2. A followup agent is permitted (MAY) to prepend a "Re: " to the
> Subject if there is not one there already. Is it to be permitted to
> enclose that "Re: " within an encoded-word (I would hope not, because
> there is no benefit in doing so, and it is not done in current practice
> AFAIK).

My reading of RFC 2822 indicates no.

> More to the point, however, is whether it is expected to decode an
> initial encoded-word before detecting whether an initial "Re: " is there
> already (I would not expect that to happen often - has anyone ever seen
> such a thing - but you never know).

I don't think it should be required, although an implementation should be
allowed to do so if it wishes to, I think.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66JHZJB034508 for <[e-mail]>; Wed, 6 Jul 2005 12:17:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66JHZDW034507 for ietf-usefor-skb; Wed, 6 Jul 2005 12:17:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66JHYph034500 for <[e-mail]>; Wed, 6 Jul 2005 12:17:35 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-218.midband.mdip.bt.net ([81.144.77.218]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cc2e4c.669a.9d for [e-mail]; Wed,  6 Jul 2005 20:17:32 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j66JGJb07271 for [e-mail]; Wed, 6 Jul 2005 20:16:20 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21934
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Semantic header (field) Content
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
Mime-Version: 1.0
Date: Wed, 6 Jul 2005 19:07:15 GMT
Lines: 41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I am now reviewing the definition of semantic content that I proposed when
revising the mechanisms for constructing References headers. I want to
make the definition as simple as possible, consistent with its achieving
the intended effect. I have come across two cases where I need some
guidance.

1. There are some discouraging remarks concerning the ancient practice of
using a Subject beginning with "cmsg" to be interpreted as a control
message (where there is not a genuine Control header as well, of course).

For this purpose, does the discouragement need to include the case where
the "cmsg" is hidden inside an encoded-word? I would presume not, since I
doubt any existing software which tries to interpret "cmsg" in that way
was smart enough to detect it when inside an encoded-word.

2. A followup agent is permitted (MAY) to prepend a "Re: " to the Subject
if there is not one there already. Is it to be permitted to enclose that
"Re: " within an encoded-word (I would hope not, because there is no
benefit in doing so, and it is not done in current practice AFAIK). More
to the point, however, is whether it is expected to decode an initial
encoded-word before detecting whether an initial "Re: " is there already
(I would not expect that to happen often - has anyone ever seen such a
thing - but you never know).

Essentially, I can get either interpretation by saying that the "semantic
content" is what you get after/before decoding any encoded-words.

Note that USEAGE says you SHOULD decode encoded-words before trying to do
anything clever with a Subject header, but that is just a matter of being
prudent - we don't necessarily want to write that into USEPRO.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66GLpnc082960 for <[e-mail]>; Wed, 6 Jul 2005 09:21:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66GLp0B082959 for ietf-usefor-skb; Wed, 6 Jul 2005 09:21:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66GLpSD082950 for <[e-mail]>; Wed, 6 Jul 2005 09:21:51 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j66GLnpS002080 for <[e-mail]>; Wed, 6 Jul 2005 09:21:50 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id E4DCFE7CB0; Wed,  6 Jul 2005 09:21:48 -0700 (PDT)
To: [e-mail]
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]> (Frank Ellermann's message of "Wed, 06 Jul 2005 17:30:44 +0200")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 06 Jul 2005 09:21:48 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann <[e-mail]> writes:
> Russ Allbery wrote:
 
>> Accordingly, not using the same path identity can't actually
>> break anything.  I think it's a SHOULD to avoid confusion.

> Depends, you have some strange ideas about "Xref-slaving",

Which doesn't use the path identity.

> I have funny visions about nntp-URLs, and Charles wants a
> "wildmat" in news-URLs only because you said it's cute ;-)

Charles (and I) want wildmat in news URLs because existing browsers
already support them and the behavior is useful.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66GE8lN080604 for <[e-mail]>; Wed, 6 Jul 2005 09:14:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66GE8I6080603 for ietf-usefor-skb; Wed, 6 Jul 2005 09:14:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66GE7Sd080583 for <[e-mail]>; Wed, 6 Jul 2005 09:14:08 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-68-164.midband.mdip.bt.net ([81.144.68.164]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cc034e.13417.dc for [e-mail]; Wed,  6 Jul 2005 17:14:06 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j66GCTc04956 for [e-mail]; Wed, 6 Jul 2005 17:12:29 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21927
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Wed, 6 Jul 2005 11:55:15 GMT
Lines: 56
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Charles Lindsey <[e-mail]> writes:
>> Bruce Lilly <[e-mail]> writes:
>>> On Mon July 4 2005 10:54, Charles Lindsey wrote:

>>>>    An injecting agent MUST identify itself with the same
>>>>    <path-identity> in both Path and Injection-Info

>>> What about Xref?

>> I don't think it really matters for Xref, though one would normally
>> expect it to be the same.

>The path-identity in Xref serves no protocol purpose and is only there as
>a form of human-readable documentation and debugging information.
>Accordingly, not using the same path identity can't actually break
>anything.  I think it's a SHOULD to avoid confusion.

Not entirely convinced, but I have now put such a SHOULD there:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers, and a serving agent SHOULD use the same <path-identity> in
   both Path and Xref headers.  To ensure that a <path-identity>
   provides a unique identity for the news-server concerned, it should
   be one of:

Are people happy with that?


>> As for CNAMEs, they have never been included in our earlier drafts, but
>> I see no reason why they should not be included in #1. Would anybody
>> else have a problem with that?

>I'm in favor of making that change.

   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record (or an equivalent "CNAME"), which SHOULD identify
      the actual host inserting this <path-identity> and, ideally,
      should also be "mailable" (see below).

Is that OK?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66GE8bO080590 for <[e-mail]>; Wed, 6 Jul 2005 09:14:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66GE8Ad080589 for ietf-usefor-skb; Wed, 6 Jul 2005 09:14:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66GE6ux080581 for <[e-mail]>; Wed, 6 Jul 2005 09:14:07 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-68-164.midband.mdip.bt.net ([81.144.68.164]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cc034d.13417.db for [e-mail]; Wed,  6 Jul 2005 17:14:05 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j66GCRI04952 for [e-mail]; Wed, 6 Jul 2005 17:12:27 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21926
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 6 Jul 2005 11:47:57 GMT
Lines: 45
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Seth Breidbart <[e-mail]> writes:

>Russ Allbery <[e-mail]> wrote:
>>
>> Why not just forbid RFC 1918 addresses?

>Not strong enough; what about sites that use other people's addresses
>internally?  (Sure, they're not supposed to; but we don't want them
>putting those addresses on the path even if they do.)

Well it's a start. I now have:

   2.   An encoding of an IP address - <IPv4address> or <IPv6address> - 
        [RFC 3986] which SHOULD be a publicly recognized address [RFC
        1918] for the actual host, as above. This option SHOULD NOT be
        used if an FQDN for that host is available.

which I think is getting nearer, but probably still needs more work.

>> Why are requiring that there be an MX record for the path identity
>> rather than just requiring that it be mailable?  Suppose I want to
>> use for my path identity the name of the system that handles mail
>> for my domain, for some obscure reason?  It doesn't need an MX
>> record -- it *is* the mail server.  Everything still works.

>Does it?  Some mailers insist on MX records, and won't mail to A
>records.  (That seems to be happening, anyway.)

I am sure I have read somewhere that, if you want your A record to receive
mail, you are supposed to create an MX record as well, although the A
record SHOULD work if you do not.

Looking further, I think it was RFC 2821 - section 5 seems the most
relevant.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66FxYrd076460 for <[e-mail]>; Wed, 6 Jul 2005 08:59:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66FxYDX076459 for ietf-usefor-skb; Wed, 6 Jul 2005 08:59:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66FxW8F076448 for <[e-mail]>; Wed, 6 Jul 2005 08:59:33 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqCI3-0005xy-RY for [e-mail]; Wed, 06 Jul 2005 17:58:23 +0200
Received: from c-180-160-101.hh.dial.de.ignite.net ([62.180.160.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 06 Jul 2005 17:58:23 +0200
Received: from nobody by c-180-160-101.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 06 Jul 2005 17:58:23 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: required SP
Date:  Wed, 06 Jul 2005 17:54:24 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-160-101.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

>> And that includes any intended or unintended abuse of
>> foreign RHS name spaces.

> Eh? Which "Charles' version" is that?

There's only one "Charles' version", and that's where you said
that a "long random string with an @ in the middle" could be
okay if it follows the syntax.  It could be also my RHS, and
then it's not okay.  Or it could be one of the "@oemcomputer"
RHS, the latter is probably more realistic and more dangerous.

> I have declined to go back to the slightly more restrictive
> rule in RFC 822.

Or 1036, 1738, s-o-1036.  The restriction is necessary to make
it work for everybody, it's almost the same problem as for the
<path-identity> - we can't have too many "oemcomputer".  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66FWXcY072176 for <[e-mail]>; Wed, 6 Jul 2005 08:32:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66FWXrA072175 for ietf-usefor-skb; Wed, 6 Jul 2005 08:32:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66FWWGv072169 for <[e-mail]>; Wed, 6 Jul 2005 08:32:32 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqBsg-0001Ld-Is for [e-mail]; Wed, 06 Jul 2005 17:32:10 +0200
Received: from c-180-160-101.hh.dial.de.ignite.net ([62.180.160.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 06 Jul 2005 17:32:10 +0200
Received: from nobody by c-180-160-101.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 06 Jul 2005 17:32:10 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Wed, 06 Jul 2005 17:30:44 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-160-101.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery wrote:
 
> The path-identity in Xref serves no protocol purpose and is
> only there as a form of human-readable documentation and
> debugging information.

You could (ab)use it to construct nntp-URLs.  It doesn't work
with my browser, maybe your UA can handle it:

Xref: news.gmane.org gmane.ietf.usenet.format:29444

<nntp://news.gmane.org/gmane.ietf.usenet.format/29444> or
<nntp://news.gmane.org/gmane.ietf.usenet.format:29444> 

Not a general concept, but essentially the same idea:

<http://article.gmane.org/gmane.ietf.usenet.format/29444>

> Accordingly, not using the same path identity can't actually
> break anything.  I think it's a SHOULD to avoid confusion.

Depends, you have some strange ideas about "Xref-slaving",
I have funny visions about nntp-URLs, and Charles wants a
"wildmat" in news-URLs only because you said it's cute ;-)

                       Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66FEwuo070277 for <[e-mail]>; Wed, 6 Jul 2005 08:14:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66FEvIm070276 for ietf-usefor-skb; Wed, 6 Jul 2005 08:14:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66FEutO070268 for <[e-mail]>; Wed, 6 Jul 2005 08:14:56 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqBba-0006nU-Ok for [e-mail]; Wed, 06 Jul 2005 17:14:30 +0200
Received: from c-180-160-101.hh.dial.de.ignite.net ([62.180.160.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 06 Jul 2005 17:14:30 +0200
Received: from nobody by c-180-160-101.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 06 Jul 2005 17:14:30 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Wed, 06 Jul 2005 17:12:26 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 33
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-180-160-101.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> BCP 14 section 6 (Frank, that's RFC 2119).

Yep, thanks.  

> "Sites MUST NOT use an IP address except for diagnostic
>  purposes in conjunction with the MISMATCH keyword."

So that's Harald's idea.  Okay, then extracting all IPs
from the <path-identity> syntax could make sense.  Maybe
we could also split "traditional name" from mailable FQDN:

FQDN is the normal ldh-string stuff as in 2396, at least
one dot, toplabel, no underscore, with news@ and usenet@.  

"Traditional name" has no dots, it can have underscores.
IP only to the left of !MISMATCH!, but not elsewhere (?)

>> an MX record does not identify a host,
> That unsupported assertion is a falsehood.  RFC 974:

It doesn't identify "the" host in question, only "a" host.
Actually a strange idea, why do we need to sanction this ?
Is it just another case of a "traditional name" ?

> of course the domain name associated with an MX host is
> "mailable" and fully qualified.

ACK, but I don't see the point of using the MX at all, if
that's a trick for UUCP hosts at most one of these hosts
behind the same MX can use it, otherwise they'd clash.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66BDDLb099049 for <[e-mail]>; Wed, 6 Jul 2005 04:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66BDDJV099048 for ietf-usefor-skb; Wed, 6 Jul 2005 04:13:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66BDCYY099026 for <[e-mail]>; Wed, 6 Jul 2005 04:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-205.midband.mdip.bt.net ([81.144.77.205]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cbbcc7.11e4f.d5 for [e-mail]; Wed,  6 Jul 2005 12:13:11 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j66BAZN00577 for [e-mail]; Wed, 6 Jul 2005 12:10:35 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21925
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Wed, 6 Jul 2005 11:02:50 GMT
Lines: 43
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Charles Lindsey <[e-mail]> writes:


>I would expect most (successful) mismatch handling to be done via manual
>configuration.

I agree. But sites with lots of peers might try to automate the process.
And they might also automate some procedure for dealing with peers who
suddenly start using a new path-identity without telling them (e.g. they
suddenly bring an additional server with a brand new IP address on
stream).

>>    The FQDN of a news-server is "mailable" if its administrators can be
>>    reached by email using both of the forms "usenet@" that FQDN and
>>    "news@" that FQDN, in conformity with [RFC 2142].

>> and similarly for "abuse@".

>Given the amount of crap such mailboxes receive these days, I think you're
>fighting a lost battle by trying to perpetuate RFC 2142.  It's a nice idea
>that's very hard to implement in practice without taking up an immense
>amount of time.

Yes, abuse of abuse addresses is a great shame. But if some site somewhere
(especially an injecting agent) is configured in such a way as to be
causing loops or spews or whatever, then it is highly desirable for
someone to be able to mail usenet@ that site what is going on (because it
may not have noticed the effects itself). If that site does not accept
mail to the RFC 2142 addresses, they you have to start chasing it through
its peers, and that soon gets very complicated.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66BDDZ6099034 for <[e-mail]>; Wed, 6 Jul 2005 04:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66BDD4B099033 for ietf-usefor-skb; Wed, 6 Jul 2005 04:13:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66BDBIo099012 for <[e-mail]>; Wed, 6 Jul 2005 04:13:12 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-205.midband.mdip.bt.net ([81.144.77.205]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cbbcc6.11e4f.d4 for [e-mail]; Wed,  6 Jul 2005 12:13:10 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j66BAXZ00573 for [e-mail]; Wed, 6 Jul 2005 12:10:33 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21924
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 6 Jul 2005 10:50:20 GMT
Lines: 42
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
>      3986] which SHOULD, according to the routeing tables [Ref needed]
>      identify the actual host, as above. This option SHOULD NOT be used
>      if an FQDN for that host is available.
> 
>Since the latest public version of USEFOR text concerning path-identity
>([e-mail]) no longer allows
>colons in the path-identity, we can no longer use RFC3896 to define how to 
>encode an IPv6address. That's fine, we aren't looking for URIs in paths, 
>just a path-identity, and colons are not necessary. There is no reason to 
>use RFC3986 encoding. I've already suggested one simple encoding that 
>seems to lack problems.

That ticket is still open, and under discussion.

I don't think the world out there is going to accept any encoding of IPv6
addresses other than the one currently in widespread use (as defined in
RFC 3986 as well as lots of other places).


>        NOTE: The syntax permits the colon character 

>Ummm, no, I don't think so. Not the syntax last presented here by our 
>Chair. And I don't recall anyone correcting him to include it.

Well I did for a start. As I said, discussion is continuing (see my last
reply to Russ).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66BDCf9099022 for <[e-mail]>; Wed, 6 Jul 2005 04:13:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j66BDC1h099021 for ietf-usefor-skb; Wed, 6 Jul 2005 04:13:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66BDAgZ099005 for <[e-mail]>; Wed, 6 Jul 2005 04:13:11 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-77-205.midband.mdip.bt.net ([81.144.77.205]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cbbcc5.11e4f.d3 for [e-mail]; Wed,  6 Jul 2005 12:13:09 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j66BAWf00567 for [e-mail]; Wed, 6 Jul 2005 12:10:32 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21923
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1021 Single component newsgroups (Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <A3144E13755E7D3CACB6EA26@B50854F0A9192E8EC6CDA126> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> 	<78BBACC38DC374725A4EDD07@B50854F0A9192E8EC6CDA126> 	<[e-mail]> <[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> 	<[e-mail]> 	<[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Wed, 6 Jul 2005 10:43:50 GMT
Lines: 25
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>I think Graham's point is that they won't break the server unless the
>server creates the group, and a server with such a constraint shouldn't
>allow the group to be created.

Yes, USEPRO will make suitably discouraging noises of that nature as soon
as USEFOR has settled on the list of what is to be forbidden/whatever.

>I think it's still an interoperability concern, but I can see the valid
>point there.

Yes, I agree it is an interoperability concern, and so warrants
appropriate RFC 2114 language in USEFOR.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66883Al030965 for <[e-mail]>; Wed, 6 Jul 2005 01:08:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j668830I030964 for ietf-usefor-skb; Wed, 6 Jul 2005 01:08:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66881Fi030946 for <[e-mail]>; Wed, 6 Jul 2005 01:08:02 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1Dq4wp-000IoX-6X for [e-mail]; Wed, 06 Jul 2005 08:07:59 +0000
Message-ID: <[e-mail]>
Date: Wed, 6 Jul 2005 09:06:50 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <XMx$+nOb77forOKLvef+dO9VXO>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes
>
>In <[e-mail]> Richard Clayton <[e-mail]> 
>writes:
>
>>In message <[e-mail]>, Charles Lindsey
>><[e-mail]> writes
>
>>>and that arbitrary names are to be
>>>dioscouraged even more. 
>
>>if they are not traditional, then yes
>
>But can you tell me how to define "traditional" as a technical term?

you don't -- what you say is something along the lines of what Harald
wrote; which was that the requirement is for uniqueness, that an FQDN is
the only thing that will now have a good chance of providing that
property; but that nevertheless some existing sites have a working
scheme, loosely based on the UUCP maps and that this means that they
have to ensure that their direct peers are aware of this

viz: you are more descriptive and less proscriptive

I can attempt words if you'd prefer; but Harald's already done that and
you don't seem to used many of them. Nevertheless I will try if you
think that it would be useful

>>you have put a SHOULD NOT against UUCP names ... reducing the level of
>>compliance of some of the oldest systems there are :(
>
>Maybe having used a name for many years past and having it known as yours
>to myriads of sites is a sufficient reason for violating a SHOULD.

mayhap, but it still reduces the level of compliance that can be claimed
and since nothing has broken why is it necessary to, effectively,
disparage their activity ?

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

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQsuRGpoAxkTY1oPiEQITYACg1SiXdNpKU0E/cmPy2NiTTSOz570AoL0Y
eLNDeJm0Ckh00+c0hNfpedUp
=A2hG
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j667a1BJ018385 for <[e-mail]>; Wed, 6 Jul 2005 00:36:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j667a1rd018384 for ietf-usefor-skb; Wed, 6 Jul 2005 00:36:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j667a1TM018376 for <[e-mail]>; Wed, 6 Jul 2005 00:36:01 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j667a0uI021959 for <[e-mail]>; Wed, 6 Jul 2005 00:36:00 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3283DE7CB0; Wed,  6 Jul 2005 00:36:00 -0700 (PDT)
To: <[e-mail]>
Subject: Re: RFC 2142
In-Reply-To: <008301c581f8$86d1dc20$[e-mail]> (Ruud H. G. van Tol's message of "Wed, 6 Jul 2005 09:00:46 +0200")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008301c581f8$86d1dc20$[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 06 Jul 2005 00:36:00 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Ruud H G van Tol <[e-mail]> writes:

> So no, I don't agree it's a lost battle. It shouldn't take up extra
> time, as the line of defense is very much the same as with any other
> address.

There's just almost no actual signal and an order of magnitude more junk.
I appreciate the desire to do the right thing, and I'm not speaking from a
perspective of what I do personally.  I'm just saying that from a
practical standpoint, I think the handwriting is already on the wall, even
if us clued folks can deal with the noise.

Given that we get maybe one legitimate message to postmaster every couple
of weeks, it's hard to justify the time and effort required to make it
readable.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6671XTo004119 for <[e-mail]>; Wed, 6 Jul 2005 00:01:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6671XPm004118 for ietf-usefor-skb; Wed, 6 Jul 2005 00:01:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6671VU5004071 for <[e-mail]>; Wed, 6 Jul 2005 00:01:32 -0700 (PDT) (envelope-from [e-mail])
Received: from isop10 (velvet.isolution.nl [194.109.164.102]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.3/8.13.3) with ESMTP id j6671JBY046678 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 6 Jul 2005 09:01:26 +0200 (CEST) (envelope-from [e-mail])
Message-ID: <008301c581f8$86d1dc20$[e-mail]>
From: "Ruud H.G. van Tol" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]><[e-mail]> <[e-mail]>
Subject: RFC 2142 (was: Re: New USEPRO path-identity text)
Date: Wed, 6 Jul 2005 09:00:46 +0200
Organization: Chaos rules.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Virus-Scanned: by XS4ALL Virus Scanner
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery:

> [abuse@]
> Given the amount of crap such mailboxes receive these days, I think
> you're fighting a lost battle by trying to perpetuate RFC 2142.  It's
> a nice idea that's very hard to implement in practice without taking
> up an immense amount of time.

All mail to postmaster@ and abuse@, and then some, should be accepted.
But there can be no guarantee that it will all be read. With a
combination of RBL/DNSBL (not to SMTP-reject, but to tag the message),
and SpamAssassin, and limited whitelisting, for example, you can sort
that mail rather effectively. Any Sender should make sure to send from a
host that is known not to be listed in the important BLs.

A hole in this, is that spammers can start sending spam with postmaster@
between the recipients of all messages, for every domain of the other
recipients, to prevent RBL/DNSBL. So who uses RBL/DNSBL even for
messages addressed to postmaster/abuse/etc., has my blessing. There is a
very small risk that you will end up in the zones of
http://www.rfc-ignorant.org/ but that will most likely only happen if
you are unlucky with your choice of RBL/DNSBL-sources.

So no, I don't agree it's a lost battle. It shouldn't take up extra
time, as the line of defense is very much the same as with any other
address.

-- 
Grtz, Ruud



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j666fIp5095400 for <[e-mail]>; Tue, 5 Jul 2005 23:41:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j666fIMJ095399 for ietf-usefor-skb; Tue, 5 Jul 2005 23:41:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j666fH19095386 for <[e-mail]>; Tue, 5 Jul 2005 23:41:18 -0700 (PDT) (envelope-from [e-mail])
Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id CB0922395; Wed,  6 Jul 2005 02:41:07 -0400 (EDT)
Received: from MCQWP2 (ip68-7-159-196.sd.sd.cox.net [68.7.159.196]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 69C028D; Wed,  6 Jul 2005 02:41:06 -0400 (EDT)
Date: Tue, 5 Jul 2005 23:41:14 -0700
From: Bill McQuillan <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Usenet <[e-mail]>
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j666fI19095392
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue, 2005-07-05, Bruce Lilly wrote:

> On Tue July 5 2005 15:32, Charles Lindsey wrote:

>> No, because an MX record does not identify a host,

> That unsupported assertion is a falsehood.  RFC 974:

>    Each MX matches a domain name with two pieces of data, a
>    preference value (an unsigned 16-bit integer), and the name of a
>    host.  The preference number is used to indicate in what order the
>    mailer should attempt deliver to the MX hosts, with the lowest
>    numbered MX being the one to try first.

>From this quote, I understand that an MX "domain" does NOT identify "a
host" but rather a semi-ordered "set of hosts", any one of which could be
the actual recipient of an email to the MX "domain".

Does you mean that only one of the hosts in such a "set of hosts" may run a
news relay?

-- 
Bill McQuillan <[e-mail]>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j664Ov4j045074 for <[e-mail]>; Tue, 5 Jul 2005 21:24:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j664OvC3045073 for ietf-usefor-skb; Tue, 5 Jul 2005 21:24:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j664OuNt045059 for <[e-mail]>; Tue, 5 Jul 2005 21:24:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id 9450D2992A; Wed,  6 Jul 2005 00:24:55 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j664OskL012109(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 6 Jul 2005 00:24:54 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j664OpAJ012108(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 6 Jul 2005 00:24:52 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Wed, 6 Jul 2005 00:24:44 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Tue July 5 2005 15:32, Charles Lindsey wrote:

> I don't think it really matters for Xref, though one would normally expect
> it to be the same. The MUST for the opther two cases is there to give less
> scope for trolls and malefactors.

BCP 14 says nothing about "trolls and malefactors".  The requirements
for use of MUST appear in BCP 14 section 6 (Frank, that's RFC 2119).

> I would be grateful if someone
> can [...] explain how best to get the intended concept
> across.

"Sites MUST NOT use an IP address except for diagnostic purposes in
conjunction with the MISMATCH keyword."

> >>    3. A fully qualified domain name (FQDN) associated with an "MX"
> >>       record, which MUST be "mailable".
> 
> >Perhaps combine with #1, probably also allow CNAMEs.
> 
> No, because an MX record does not identify a host,

That unsupported assertion is a falsehood.  RFC 974:

   Each MX matches a domain name with two pieces of data, a
   preference value (an unsigned 16-bit integer), and the name of a
   host.  The preference number is used to indicate in what order the
   mailer should attempt deliver to the MX hosts, with the lowest
   numbered MX being the one to try first.

Note the words "host" and "hosts", the latter occurring in "MX hosts".

> though it ought to 
> identify the administrators of the host in question.

Having just finished claiming that MX records do not identify hosts,
you then proceed to make another unsubstantiated claim about "the
administrators of the host" -- which "host" would that be; the one
that the MX record supposedly has nothing to do with?

> Maybe that should be 
> expressed somehow.

No, we should stick to truth and sensible statements.  And, we don't
need the department of redundancy department; since MX records are at
the very heart of mail delivery and the DNS is a rooted tree hierarchy,
of course the domain name associated with an MX host is "mailable"
and fully qualified.  The Instructions to Authors document says "To
simply specify a necessary logical relationship; the normal lower-case
words should be used" rather than capitalized BCP 14 keywords such as
MUST.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j663KvHC040888 for <[e-mail]>; Tue, 5 Jul 2005 20:20:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j663KvJw040887 for ietf-usefor-skb; Tue, 5 Jul 2005 20:20:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j663Kus8040881 for <[e-mail]>; Tue, 5 Jul 2005 20:20:56 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j663Ktbk015926 for <[e-mail]>; Tue, 5 Jul 2005 20:20:55 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 585E4E7CB0; Tue,  5 Jul 2005 20:20:55 -0700 (PDT)
To: [e-mail]
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]> (Seth Breidbart's message of "Tue, 5 Jul 2005 22:50:39 -0400 (EDT)")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Tue, 05 Jul 2005 20:20:55 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Seth Breidbart <[e-mail]> writes:

> Does it?  Some mailers insist on MX records, and won't mail to A
> records.  (That seems to be happening, anyway.)

Please do tell.  Such a mailer would be completely unable to send mail to
multiple systems that I run, including the mailing list management system
that hosts the IETF NNTP working group, but I have never heard a single
complaint.

Such a mailer would also be in blatant violation of RFC 2821:

   [...]
   The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found instead, the resulting name is
   processed as if it were the initial name.  If no MX records are found,
   but an A RR is found, the A RR is treated as if it was associated with
   an implicit MX RR, with a preference of 0, pointing to that host.
   [...]

I have no intention of adding MX records for systems that don't need them.
It's just DNS noise.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662oeMs038529 for <[e-mail]>; Tue, 5 Jul 2005 19:50:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662oeKk038528 for ietf-usefor-skb; Tue, 5 Jul 2005 19:50:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662oe3V038522 for <[e-mail]>; Tue, 5 Jul 2005 19:50:40 -0700 (PDT) (envelope-from [e-mail])
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 5996B58B30 for <[e-mail]>; Tue,  5 Jul 2005 22:50:39 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j662odF28325; Tue, 5 Jul 2005 22:50:39 -0400 (EDT)
Date: Tue, 5 Jul 2005 22:50:39 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ Allbery on Tue, 05 Jul 2005 19:37:28 -0700)
Subject: Re: New USEPRO path-identity text
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery <[e-mail]> wrote:
> Charles Lindsey <[e-mail]> writes:

>> It is clear that routers on the Internet are configured to route packets
>> to the sites which officially own the IP addresses as allocated by the
>> processes established by ICANN. What happens on private routers within
>> intranets is another matter of course. So the concept we need is clearly
>> there - just a matter of how to express it.
>
> Why not just forbid RFC 1918 addresses?

Not strong enough; what about sites that use other people's addresses
internally?  (Sure, they're not supposed to; but we don't want them
putting those addresses on the path even if they do.)

> Why are requiring that there be an MX record for the path identity
> rather than just requiring that it be mailable?  Suppose I want to
> use for my path identity the name of the system that handles mail
> for my domain, for some obscure reason?  It doesn't need an MX
> record -- it *is* the mail server.  Everything still works.

Does it?  Some mailers insist on MX records, and won't mail to A
records.  (That seems to be happening, anyway.)

Seth



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662mLp8038338 for <[e-mail]>; Tue, 5 Jul 2005 19:48:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662mLYo038337 for ietf-usefor-skb; Tue, 5 Jul 2005 19:48:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662mLCT038331 for <[e-mail]>; Tue, 5 Jul 2005 19:48:21 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j662mKqd019285 for <[e-mail]>; Tue, 5 Jul 2005 19:48:20 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 5571FE7CB0; Tue,  5 Jul 2005 19:48:20 -0700 (PDT)
To: [e-mail]
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]> (Russ Allbery's message of "Tue, 05 Jul 2005 19:37:28 -0700")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Tue, 05 Jul 2005 19:48:20 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery <[e-mail]> writes:

> The path-identity in Xref serves no protocol purpose and is only there
> as a form of human-readable documentation and debugging information.
> Accordingly, not using the same path identity can't actually break
> anything.  I think it's a SHOULD to avoid confusion.

Oh... *heh*.  I just realized that using a Path identity of:

    example:34

as the path-identity in Xref could break various things in rather
interesting ways.  Mostly just because of simplified coding taking
advantage of the fact that colons do not appear in the path identity,
since it's frequently desirable to just quietly skip any malformed Xref
header entries, and once you've done that, why skip the path identity
specially rather than just letting the same code handle it?

No valid IPv6 address would have only a single colon, however.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662bUIO036826 for <[e-mail]>; Tue, 5 Jul 2005 19:37:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662bU6a036825 for ietf-usefor-skb; Tue, 5 Jul 2005 19:37:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662bTFa036819 for <[e-mail]>; Tue, 5 Jul 2005 19:37:29 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j662bTuC017902 for <[e-mail]>; Tue, 5 Jul 2005 19:37:29 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id E2232E7CB0; Tue,  5 Jul 2005 19:37:28 -0700 (PDT)
To: [e-mail]
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Tue, 5 Jul 2005 19:32:55 GMT")
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Tue, 05 Jul 2005 19:37:28 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:
> Bruce Lilly <[e-mail]> writes:
>> On Mon July 4 2005 10:54, Charles Lindsey wrote:

>>>    An injecting agent MUST identify itself with the same
>>>    <path-identity> in both Path and Injection-Info

>> What about Xref?

> I don't think it really matters for Xref, though one would normally
> expect it to be the same.

The path-identity in Xref serves no protocol purpose and is only there as
a form of human-readable documentation and debugging information.
Accordingly, not using the same path identity can't actually break
anything.  I think it's a SHOULD to avoid confusion.

> It is clear that routers on the Internet are configured to route packets
> to the sites which officially own the IP addresses as allocated by the
> processes established by ICANN. What happens on private routers within
> intranets is another matter of course. So the concept we need is clearly
> there - just a matter of how to express it.

Why not just forbid RFC 1918 addresses?

>>>    3. A fully qualified domain name (FQDN) associated with an "MX"
>>>       record, which MUST be "mailable".

>> Perhaps combine with #1, probably also allow CNAMEs.

> No, because an MX record does not identify a host, though it ought to
> identify the administrators of the host in question. Maybe that should
> be expressed somehow.

Why are requiring that there be an MX record for the path identity rather
than just requiring that it be mailable?  Suppose I want to use for my
path identity the name of the system that handles mail for my domain, for
some obscure reason?  It doesn't need an MX record -- it *is* the mail
server.  Everything still works.

> As for CNAMEs, they have never been included in our earlier drafts, but
> I see no reason why they should not be included in #1. Would anybody
> else have a problem with that?

I'm in favor of making that change.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662WE8M036459 for <[e-mail]>; Tue, 5 Jul 2005 19:32:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662WERS036457 for ietf-usefor-skb; Tue, 5 Jul 2005 19:32:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662WEjZ036450 for <[e-mail]>; Tue, 5 Jul 2005 19:32:14 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j662WDRn025192 for <[e-mail]>; Tue, 5 Jul 2005 19:32:13 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id DCD27E7CB0; Tue,  5 Jul 2005 19:32:12 -0700 (PDT)
To: [e-mail]
Subject: Re: New USEPRO path-identity text
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Tue, 5 Jul 2005 20:45:08 GMT")
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Tue, 05 Jul 2005 19:32:12 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:

> I swapped them to bring the two cases where you identified an actual
> host together. What happens in the case of an MX record when it comes to
> detecting MISMATCHes is an interesting question. Usually, the actual
> host will be a subdomain of the MX record, or something pretty close to
> that.  So a site that is doing MISMATCH checks will need to build a
> cache of all the IP addresses used by the site which owns the MX
> record. It may be possible to do that mechanically using reverse
> lookups, etc. But if the MX record is not obviously related to the IP
> address, then either you need some human assistance with building the
> cache, or you just label it a MISMATCH anyway.

I would expect most (successful) mismatch handling to be done via manual
configuration.  It's common practice to exchange path identities when
setting up peering relationships.  The path identity can then go into a
configuration file associated with the authentication information for the
peer and any peer that authenticates according to that information will
not be marked with mismatch if it uses that path identity.

That very simple system would be sufficient for the degree of security
warranted here.

> FQDN is defined under #1. But I seem to have omitted to make the change
> promised in an earlier reply to you. I now have:

>    The FQDN of a news-server is "mailable" if its administrators can be
>    reached by email using both of the forms "usenet@" that FQDN and
>    "news@" that FQDN, in conformity with [RFC 2142].

> and similarly for "abuse@".

Given the amount of crap such mailboxes receive these days, I think you're
fighting a lost battle by trying to perpetuate RFC 2142.  It's a nice idea
that's very hard to implement in practice without taking up an immense
amount of time.  We stopped allowing external mail to
[e-mail] a while back (need to do something about the
backscatter as soon as I can find a free moment), and I think I'm the only
person left who even looks at [e-mail] (and I use an
incredibly aggressive killfile to process it).

I read news and usenet, after bogofilter, but I bet a lot of sites don't,
and it's getting increasingly hard to justify requiring it.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662M5UL035654 for <[e-mail]>; Tue, 5 Jul 2005 19:22:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662M52g035652 for ietf-usefor-skb; Tue, 5 Jul 2005 19:22:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662M4hl035641 for <[e-mail]>; Tue, 5 Jul 2005 19:22:04 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j662M3Tl015712 for <[e-mail]>; Tue, 5 Jul 2005 19:22:03 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6CB6DE7CB0; Tue,  5 Jul 2005 19:22:03 -0700 (PDT)
To: [e-mail]
Subject: Re: #1021 Single component newsgroups (Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Tue, 5 Jul 2005 20:49:52 GMT")
References: <A3144E13755E7D3CACB6EA26@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <78BBACC38DC374725A4EDD07@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Tue, 05 Jul 2005 19:22:03 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:

> No, all digit components can actually break things so long as servers
> are implemented the way they usually are (see reply by Russ a week or so
> back). It is unreasonable to expect those servers to change their
> implementations because too many user agents depend on them being the
> way they are.

I think Graham's point is that they won't break the server unless the
server creates the group, and a server with such a constraint shouldn't
allow the group to be created.

I think it's still an interoperability concern, but I can see the valid
point there.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662FjLO034928 for <[e-mail]>; Tue, 5 Jul 2005 19:15:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662Fj4k034927 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fh1A034890 for <[e-mail]>; Tue, 5 Jul 2005 19:15:44 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ecb.17747.c1 for [e-mail]; Wed,  6 Jul 2005 03:15:39 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CDa24972 for [e-mail]; Wed, 6 Jul 2005 03:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21912
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 19:32:55 GMT
Lines: 80
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Mon July 4 2005 10:54, Charles Lindsey wrote:
>>    News-servers need to identify themselves by inserting their public
>>    name, in the form of a <path-identity> (F-3.1.6), into Path,
>>    Injection-Info and Xref headers.

>Header fields.

Yes, Yes. That will get fixed when I do my grand trawl throught the whole
of USEPRO to change those cases.

>>    An injecting agent MUST identify 
>>    itself with the same <path-identity> in both Path and Injection-Info

>What about Xref?

I don't think it really matters for Xref, though one would normally expect
it to be the same. The MUST for the opther two cases is there to give less
scope for trolls and malefactors.

>>    2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
>>       3986] which SHOULD, according to the routeing tables [Ref needed]

>Whose "routeing [sic] tables"?  My routing tables point here for the IP
>address 127.0.0.1; if yours also point here, you have a problem. Likewise
>for IP addresses which cannot be routed (RFC 1918).

It is clear that routers on the Internet are configured to route packets
to the sites which officially own the IP addresses as allocated by the
processes established by ICANN. What happens on private routers within
intranets is another matter of course. So the concept we need is clearly
there - just a matter of how to express it. I presume there exists some
RFC that specifies how it is all done, so I would be grateful if someone
can point me at it, or explain how best to get the intended concept
across.
> 
>>       identify the actual host, as above. This option SHOULD NOT be used
>>       if an FQDN for that host is available.

>For IPv6 and the Path field, and unless Frank's or John's suggestions
>for replacing colons are used, there is an interoperability issue,
>therefore s/SHOULD NOT/MUST NOT/, at least for IPv6.

No, I belioeve the general view here is that the possible glitch is so
minor that we do not need to say that. I have added a NOTE warning sites
to avoid the problem.
>  
>>    3. A fully qualified domain name (FQDN) associated with an "MX"
>>       record, which MUST be "mailable".

>Perhaps combine with #1, probably also allow CNAMEs.

No, because an MX record does not identify a host, though it ought to
identify the administrators of the host in question. Maybe that should be
expressed somehow.

As for CNAMEs, they have never been included in our earlier drafts, but I
see no reason why they should not be included in #1. Would anybody else
have a problem with that?
> 
>>    4. An arbitrary name believed to be unique and registered at least
>>       with all other news-servers receiving articles directly from the
>>       given one.

>But not registered with senders?

I think you may be right there, but I see somebody else has raised it, so
I will deal with it when replying to him.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fix3034920 for <[e-mail]>; Tue, 5 Jul 2005 19:15:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662Fi35034919 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fhr3034903 for <[e-mail]>; Tue, 5 Jul 2005 19:15:43 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ecd.17747.c2 for [e-mail]; Wed,  6 Jul 2005 03:15:41 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CGG24990 for [e-mail]; Wed, 6 Jul 2005 03:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21915
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 20:45:08 GMT
Lines: 111
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>> Comments?

>> "A" or "AAAA" record, which SHOULD identify the actual host

>Why only SHOULD, isn't it a !MISMATCH! otherwise ?

Yes, but MISMATCHes happen (they SHOULD NOT, of course).

Note that this text is describing how sites should identitfy *themselves*
in the Path. The business of checking and recording MISMATCHes comes
later on in USEPRO.

>> An encoding of an IP address - <IPv4address> or <IPv6address
>> [RFC 3986] which SHOULD, according to the routeing tables
>> [Ref needed] identify the actual host, as above.

>Maybe delete ", according to the routeing tables [Ref needed]".

I think something needs to be said there (because what an IP address
identifies within an intranet may differ from what it identifies from
outside, on the public Internet).  Obviously, it was the "public" routing
tables that were meant, but I am still not sure how to express that.

>Why not a MUST, nobody's interested in an "identity" 127.0.0.1.

It's the same as the SHOULD in #1.

>> 3. A fully qualified domain name (FQDN) associated with an
>>    "MX" record, which MUST be "mailable".

>Why did you swap (2) and (3) ?  What's the effect of (3) wrt a
>!MISMATCH! ?

I swapped them to bring the two cases where you identified an actual host
together. What happens in the case of an MX record when it comes to
detecting MISMATCHes is an interesting question. Usually, the actual host
will be a subdomain of the MX record, or something pretty close to that.
So a site that is doing MISMATCH checks will need to build a cache of all
the IP addresses used by the site which owns the MX record. It may be
possible to do that mechanically using reverse lookups, etc. But if the MX
record is not obviously related to the IP address, then either you need
some human assistance with building the cache, or you just label it a
MISMATCH anyway. I see that many of the MISMATCHes currently reported by
DNews sites are like that - they appear not to be MISMATCHes when you look
at them closely, but the admin of the receiving site never looked closely
:-( .

But more to the point, I think that text at least needs to say that the MX
record SHOULD give you a mailable address for the site that sent the
article. I would welcome suggestions for how to express that.

>>| NOTE: The syntax permits the colon character (which, prior
>>| to this standard, was a <path-delimiter>) within a
>>| <path-identity>, but only within an <IPv6address>.  It would
>>| therefor be unwise to choose, as the arbitrary name,
>>| anything composed solely of hexadecimal digits.

>   NOTE: The syntax permits the colon character within an
>   <Ip6address>, and the colon was handled as <path-delimiter>
>   in [RFC 1036] before [s-o-1036].  It would therefore be
>   unwise to choose, as an arbitrary name, four or less
>   hexadecimal digits, or any name matching an <IPv4Address>.

There is no need to mention <IPv4address>es, becaue (see reply to Seth) #4
now excludes anything covered in #1-3. And I don't think it necessary to
mention 1036 etc explicitly, because it is stated elsewhere in the draft
that those were "prior to this standard". And it is not *our* syntax that
permits a colon character within an <Ip6address>. I now have:

        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within any <path-
        identity> which is in the form of an <IPv6address>.  It would
        therefor be unwise to choose, as such a name, anything composed
        solely from four (or less) hexadecimal digits.

>> "usenet@<FQDN>" and "news@<FQDN>"

><FQDN> is no defined term.

FQDN is defined under #1. But I seem to have omitted to make the change
promised in an earlier reply to you. I now have:

   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@" that FQDN and
   "news@" that FQDN, in conformity with [RFC 2142].

and similarly for "abuse@".

>> "abuse@<FQDN>" MUST also be available

>....  Better get rid of abuse@, the RFCI
>rule is that abuse@ must only exist at the "zone cut", and we
>will not discuss the finer points of nslookup -q=ns or -q=soa.

Eh? Where do you get that rule, and what is a "zone cut"? What I have
written seems perfectly consistent with RFC 2142.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662FfPJ034894 for <[e-mail]>; Tue, 5 Jul 2005 19:15:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662FeVv034893 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fdnj034867 for <[e-mail]>; Tue, 5 Jul 2005 19:15:40 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3eca.17747.c0 for [e-mail]; Wed,  6 Jul 2005 03:15:38 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CCH24964 for [e-mail]; Wed, 6 Jul 2005 03:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21910
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 19:03:02 GMT
Lines: 51
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Charles Lindsey <[e-mail]> writes:

>> Yes, but the path-address (IPv[46]address) is NOT "just diagnopstic
>> information" . It is in fairly widespread current use, with the intent
>> of avoiding duplicate propagation to the site which inserted it.

>Huh, really?  I'm not saying you're wrong, since I've not checked, but
>I've not personally seen anyone use an IP address as their actual path
>identity (as opposed to having it added by their peers as diagnostic
>information).

Well there is certainly a lot of IP addresses followed by ".MISMATCH", but
discounting those there are still a lot of IP addresses to be found

I trawled through 17893 articles in my archive, and found 721 (4%) with
naked IP addresses in them. Of these, 481 were one particular site
(uni-berlin.de) whose injector routinely inserted the dial-in IP after the
not-for-mail (the same as the NNTP-Posting-Host in fact). But that still
leaves 240 (1.3%) with IP addresses in the middle. 202 of these were three
sites (small.news.tele.dk, cyclone-sf.pbi.net and worldnet.att.net) which
seem sytematically to insert the IP from which it received the message
(but they did not appear to be MISMATCHes).

news-uk.onetel.net.uk seemed to insert its own IP address, followed by the
posting host (and no-not-for-mail) when injecting (30 0f those). Which
left a small core of other odds and ends.

So yes, a lot of it seems to be down to a small number of sites adding
their peer's IP as you said, but also some mavericks who do odd things when
injecting.

But I still think we have to allow it, for a variety of odd cases, and I
still think <path-identity> ought to include them for the purposes for
which I use it in USEPRO. But clearly the SHOULD NOT use IP addresses when
you have a perfectly good domain-name, in my latest proposed text, is
still OK (and most people seem already to be following it). Note that the
text I have written applies to sites identifying themselves - MISMATCHes
are dealt with elsewhere in USEPRO.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662FeTq034875 for <[e-mail]>; Tue, 5 Jul 2005 19:15:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662FeI9034874 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662FcjS034858 for <[e-mail]>; Tue, 5 Jul 2005 19:15:39 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ec9.17747.bf for [e-mail]; Wed,  6 Jul 2005 03:15:37 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CF024984 for [e-mail]; Wed, 6 Jul 2005 03:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21914
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 19:56:20 GMT
Lines: 51
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Seth Breidbart <[e-mail]> writes:

>"Charles Lindsey" <[e-mail]> wrote:

>>   4. An arbitrary name believed to be unique and registered at least
>>      with all other news-servers receiving articles directly from the
>>      given one. The news-server administrator is responsible for
>>      choosing an appropriate name (and must bear the consequences of an
>>      inappropriate choice). This option SHOULD NOT be used unless the
>>      earlier options are unavailable (e.g. because the host in question
>>      is not connected to the Internet).

>Rather than "must bear the consequences" (response: "Make me") I
>prefer "will bear the consequences" (response: "Oops, I'd better
>rethink that choice").

OK, I buy that.

>What does "registered [at least] with" mean?  Why does it matter?
>(NNTP thinks those _sending to_ me should know my name(s) for
>efficiency, but those _receiving from_ me don't have to care who I
>claim to be today, do they?)

Yes, I think I got that back-to-front.

>This appears to say (but doesn't) that the "arbitrary name" isn't an
>FQDN that doesn't qualify under (1) or (3), but is used with
>permission of the owner of the namespace.

OK, I now have:

   4.   Some other (arbitrary) name believed to be unique and registered
        at least with all other news-servers sending articles directly
        to the given one. The news-server administrator is responsible
        for choosing an appropriate name (and will bear the consequences
        of an inappropriate choice). This option SHOULD NOT be used
        unless the earlier options are unavailable (e.g. because the
        host in question is not connected to the Internet).

That probaly still needs further work, particularly regarding the SHOULD NOT.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fdmm034865 for <[e-mail]>; Tue, 5 Jul 2005 19:15:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662FdE1034864 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fc3i034849 for <[e-mail]>; Tue, 5 Jul 2005 19:15:38 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ec9.17747.be for [e-mail]; Wed,  6 Jul 2005 03:15:37 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CAn24950 for [e-mail]; Wed, 6 Jul 2005 03:12:10 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21908
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: required SP
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 16:33:05 GMT
Lines: 45
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Forrest J. Cavalier III" <[e-mail]> writes:

>Russ Allbery wrote:

>> We're trying to reuse portions of a normative reference while overriding
>> other portions.  It's not a particularly difficult or unusual concept, and
>> it should be immediately familiar to anyone who's done object-oriented
>> programming.
>> 

>It is dishonest to imply that this is ever done by redefining the API (i.e. types
>of function parameters and return values.).

>The only sane way of overlaying an operational restriction in object-oriented
>programming is to apply the restriction and then call the base class implementation.
>It is NOT OK to re-implement it in the derived class.

Indeed that is good practice. In this case RFC 2822 is the base class. If
some message of the base class (a syntax rule in our case) is different in
the derived class (USEFOR) (e.g. because some [CFWS] has changed to a
mandatory SP), then you give the new rule. If the rule in the derived
class is the same as in the base class, then you do not repeat it.

But that is exactly what has been done in USEFOR, with no exception that I
can think of. So what is your problem? The object-oriented analogy seems
to work pretty well in this case.


>Although REPEATING text from normative references is often "merely" clutter,
>REWRITING and PARAPHRASING text and ABNF from normative references is a big
>problem:

In such cases, the wording needs to be clear that what is written is not
normative.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fc4I034856 for <[e-mail]>; Tue, 5 Jul 2005 19:15:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662FciQ034855 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fbm7034840 for <[e-mail]>; Tue, 5 Jul 2005 19:15:37 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ec8.17747.bd for [e-mail]; Wed,  6 Jul 2005 03:15:36 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CGr24994 for [e-mail]; Wed, 6 Jul 2005 03:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21916
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1021 Single component newsgroups (Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <A3144E13755E7D3CACB6EA26@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <78BBACC38DC374725A4EDD07@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 20:49:52 GMT
Lines: 23
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Graham Drabble <[e-mail]> writes:

>My view is that certainly all digit components should go to USEAGE 
>and possibly others. All digit components only hurt a server whose 
>admin has added the group, it doesn't harm if it is in a Newsgroups 
>header or a Control header.

No, all digit components can actually break things so long as servers are
implemented the way they usually are (see reply by Russ a week or so
back). It is unreasonable to expect those servers to change their
implementations because too many user agents depend on them being the way
they are.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fb8O034847 for <[e-mail]>; Tue, 5 Jul 2005 19:15:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662FbSq034846 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662FaCG034818 for <[e-mail]>; Tue, 5 Jul 2005 19:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ec7.17747.bc for [e-mail]; Wed,  6 Jul 2005 03:15:35 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CBJ24958 for [e-mail]; Wed, 6 Jul 2005 03:12:11 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21909
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: required SP
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 16:42:51 GMT
Lines: 33
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Bruce Lilly wrote:

>> Can a subset of what is permitted by the RFC 2822 syntax
>> work, or is an incompatible superset required?

><id-local> "@" <id-domain> and Charles' <id-left> "@" <id-right>
>are syntactically both subsets of 2822 <id-left> "@" <id-right>

>Semantically Charles' version is apparently a superset, he
>wants to allow any unique random <msg-id>.  And that includes
>any intended or unintended abuse of foreign RHS name spaces.

Eh? Which "Charles' version" is that? I have proposed various texts which
pick up on the RECOMMENDATION in RFC 2822 (though I think Harald's text is
something yet again). I have declined to go back to the slightly more
restrictive rule in RFC 822.

Abuse of other people's name spaces is not a matter for a format document,
but it could be a proper matter for USEAGE, and maybe even USEPRO (see my
text for path-identity).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Faox034836 for <[e-mail]>; Tue, 5 Jul 2005 19:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662FagA034834 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662FZKs034816 for <[e-mail]>; Tue, 5 Jul 2005 19:15:35 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ec5.17747.ba for [e-mail]; Wed,  6 Jul 2005 03:15:33 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CCG24968 for [e-mail]; Wed, 6 Jul 2005 03:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21911
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1003 Message-ID text: Resolving
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 19:16:22 GMT
Lines: 17
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>The name <id-right> is a severe security violation.

Since using a particular name for a syntax rule can have no effect on what
is allowed, how can it possibly be the cause of any security violation?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662Fai6034837 for <[e-mail]>; Tue, 5 Jul 2005 19:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j662FaqX034835 for ietf-usefor-skb; Tue, 5 Jul 2005 19:15:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j662FZNS034817 for <[e-mail]>; Tue, 5 Jul 2005 19:15:35 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-223.midband.mdip.bt.net ([81.144.70.223]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42cb3ec6.17747.bb for [e-mail]; Wed,  6 Jul 2005 03:15:34 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j662CEV24976 for [e-mail]; Wed, 6 Jul 2005 03:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21913
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 5 Jul 2005 19:49:12 GMT
Lines: 34
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Richard Clayton <[e-mail]> writes:

>In message <[e-mail]>, Charles Lindsey
><[e-mail]> writes

>>and that arbitrary names are to be
>>dioscouraged even more. 

>if they are not traditional, then yes

But can you tell me how to define "traditional" as a technical term?

>you have put a SHOULD NOT against UUCP names ... reducing the level of
>compliance of some of the oldest systems there are :(

Maybe having used a name for many years past and having it known as yours
to myriads of sites is a sufficient reason for violating a SHOULD.

>this provision seems unnecessary since they aren't creating a problem

And there is Bruce asking me to make it a MUST :-( .

OK, I need to hear more opinions on this one.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65HrXSK098426 for <[e-mail]>; Tue, 5 Jul 2005 10:53:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j65HrXIG098425 for ietf-usefor-skb; Tue, 5 Jul 2005 10:53:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65HrWC1098413 for <[e-mail]>; Tue, 5 Jul 2005 10:53:32 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j65HrNDC014195 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 5 Jul 2005 10:53:24 -0700 (PDT)
Date: Tue, 5 Jul 2005 10:53:23 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: RE: New USEPRO path-identity text
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers.

s/headers/header fields/;

   An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers. 

ditto.

   To ensure that a <path-identity> provides a unique identity
   for the news-server concerned, it should be one of:

You cannot ensure anything if the mandate is only "should".

   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
      3986] which SHOULD, according to the routeing tables [Ref needed]
      identify the actual host, as above. This option SHOULD NOT be used
      if an FQDN for that host is available.
 
Since the latest public version of USEFOR text concerning path-identity
([e-mail]) no longer allows
colons in the path-identity, we can no longer use RFC3896 to define how to 
encode an IPv6address. That's fine, we aren't looking for URIs in paths, 
just a path-identity, and colons are not necessary. There is no reason to 
use RFC3986 encoding. I've already suggested one simple encoding that 
seems to lack problems.

Someone else has already pointed out that "routing tables" don't define a
host.

   4. An arbitrary name believed to be unique and registered at least
      with all other news-servers receiving articles directly from the
      given one. The news-server administrator is responsible for
      choosing an appropriate name (and must bear the consequences of an
      inappropriate choice).

We're bordering on this "idiot" fellow again.  If we tell someone that the 
name he picks must be "believed to be unique ... with all other servers 
receiving articles directly" from him, and he follows our rules, then 
there ought to be no consequences with which to threaten him. 

        NOTE: The syntax permits the colon character 

Ummm, no, I don't think so. Not the syntax last presented here by our 
Chair. And I don't recall anyone correcting him to include it.

    and if the agent offers its services to the general public the form
   "abuse@<FQDN>" MUST also be available, 

What is our rationale for the difference from RFC2142 here? Is this an
interoperability issue that needs to be discussed?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j654PHtH065108 for <[e-mail]>; Mon, 4 Jul 2005 21:25:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j654PH4w065107 for ietf-usefor-skb; Mon, 4 Jul 2005 21:25:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j654PFfX065098 for <[e-mail]>; Mon, 4 Jul 2005 21:25:16 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpezN-0001mp-3u for [e-mail]; Tue, 05 Jul 2005 06:24:53 +0200
Received: from 212.82.251.219 ([212.82.251.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 06:24:53 +0200
Received: from nobody by 212.82.251.219 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 06:24:53 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1003 USEFOR 3.1.3 msg-id issues - attempt to focus
Date:  Tue, 05 Jul 2005 06:21:51 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Message-ID:  <[e-mail]>
References:  <[e-mail]> <12403.9609371268$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.219
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

> Message-ID: <"\"@xyzzy.claranet.de>
> Date: Wed, 29 Jun 2005 20:24:33 +0200
> Newsgroups: alt.test

> <http://purl.net/msgid/[e-mail]>

It really didn't make it, but the URL was wrong, correction:

<http://purl.net/net/msgid/[e-mail]> or
<http://groups.google.de/groups?selm=%22\%1B[7;[e-mail]>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6546T4o064105 for <[e-mail]>; Mon, 4 Jul 2005 21:06:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6546TZv064104 for ietf-usefor-skb; Mon, 4 Jul 2005 21:06:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6546RCP064095 for <[e-mail]>; Mon, 4 Jul 2005 21:06:28 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpehU-0007oA-Hy for [e-mail]; Tue, 05 Jul 2005 06:06:24 +0200
Received: from 212.82.251.219 ([212.82.251.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 06:06:24 +0200
Received: from nobody by 212.82.251.219 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 06:06:24 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1003 Message-ID text: Resolving
Date:  Tue, 05 Jul 2005 06:03:24 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.219
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> I think those items are more USEPRO or UESEAGE.

The RHS semantics is reflected in the syntax of 1036 and 1738:

1036: <unique@full_domain_name>

1738: 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host

The RHS semantics is reflected in my msg-id.txt and news-uri:

| msg-id       =  "<" id-local "@" id-domain ">"

| message-id   = unique "@" host                ; see RFC 1036

The name <id-right> is a severe security violation.  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j653hGAX062709 for <[e-mail]>; Mon, 4 Jul 2005 20:43:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j653hGhB062708 for ietf-usefor-skb; Mon, 4 Jul 2005 20:43:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j653hFNX062700 for <[e-mail]>; Mon, 4 Jul 2005 20:43:15 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpeKt-0006Ik-L1 for [e-mail]; Tue, 05 Jul 2005 05:43:03 +0200
Received: from 212.82.251.219 ([212.82.251.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 05:43:03 +0200
Received: from nobody by 212.82.251.219 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 05:43:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: required SP
Date:  Tue, 05 Jul 2005 05:28:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.219
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> Can a subset of what is permitted by the RFC 2822 syntax
> work, or is an incompatible superset required?

<id-local> "@" <id-domain> and Charles' <id-left> "@" <id-right>
are syntactically both subsets of 2822 <id-left> "@" <id-right>

Semantically Charles' version is apparently a superset, he
wants to allow any unique random <msg-id>.  And that includes
any intended or unintended abuse of foreign RHS name spaces.

My version is semantically like (2)822.  One minor point that
could be fixed if needed:  Charles allows <whatever@[}>, and
my version insists on a non-empty domain-literal.  Otherwise
they are syntactically equivalent and semantically different.

>> Why are we even still discussing that question?
> Because there is not yet a satisfactory resolution.

Alexey and Harald proposed that it's clear.  IMHO that's not
correct, Charles' version is dangerous and confusing.  Bye.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j653AdVV059671 for <[e-mail]>; Mon, 4 Jul 2005 20:10:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j653Ad0D059670 for ietf-usefor-skb; Mon, 4 Jul 2005 20:10:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j653AakH059649 for <[e-mail]>; Mon, 4 Jul 2005 20:10:37 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpdpT-0004EQ-8i for [e-mail]; Tue, 05 Jul 2005 05:10:35 +0200
Received: from 212.82.251.219 ([212.82.251.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 05:10:35 +0200
Received: from nobody by 212.82.251.219 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Jul 2005 05:10:35 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: New USEPRO path-identity text
Date:  Tue, 05 Jul 2005 05:07:54 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 46
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.219
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> Comments?

> "A" or "AAAA" record, which SHOULD identify the actual host

Why only SHOULD, isn't it a !MISMATCH! otherwise ?

> An encoding of an IP address - <IPv4address> or <IPv6address
> [RFC 3986] which SHOULD, according to the routeing tables
> [Ref needed] identify the actual host, as above.

Maybe delete ", according to the routeing tables [Ref needed]".

Why not a MUST, nobody's interested in an "identity" 127.0.0.1.

> 3. A fully qualified domain name (FQDN) associated with an
>    "MX" record, which MUST be "mailable".

Why did you swap (2) and (3) ?  What's the effect of (3) wrt a
!MISMATCH! ?

>| NOTE: The syntax permits the colon character (which, prior
>| to this standard, was a <path-delimiter>) within a
>| <path-identity>, but only within an <IPv6address>.  It would
>| therefor be unwise to choose, as the arbitrary name,
>| anything composed solely of hexadecimal digits.

   NOTE: The syntax permits the colon character within an
   <Ip6address>, and the colon was handled as <path-delimiter>
   in [RFC 1036] before [s-o-1036].  It would therefore be
   unwise to choose, as an arbitrary name, four or less
   hexadecimal digits, or any name matching an <IPv4Address>.

> "usenet@<FQDN>" and "news@<FQDN>"

<FQDN> is no defined term.

> "abuse@<FQDN>" MUST also be available

<FQDN> is no defined term.  Better get rid of abuse@, the RFCI
rule is that abuse@ must only exist at the "zone cut", and we
will not discuss the finer points of nslookup -q=ns or -q=soa.

                           Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64MJbNI035160 for <[e-mail]>; Mon, 4 Jul 2005 15:19:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64MJbYe035159 for ietf-usefor-skb; Mon, 4 Jul 2005 15:19:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ID-77355.user.dfncis.de ([82.133.101.159]) by above.proper.com (8.12.11/8.12.9) with SMTP id j64MJZF3035153 for <[e-mail]>; Mon, 4 Jul 2005 15:19:36 -0700 (PDT) (envelope-from [e-mail])
Received: from sjoh1646 ([127.0.0.1]) by sjoh1646 (192.168.254.2) with news-to-mail ; Mon, 04 Jul 2005 23:05:43 +0100
To: [e-mail]
Subject: Re: #1003 USEFOR 3.1.3 Message-ID: Proposed text
From: Graham Drabble <[e-mail]>
References: <[e-mail]>
Date: Mon, 04 Jul 2005 23:05:43 +0100
Organization: Home
Message-ID: <[e-mail]>
User-Agent: Xnews/5.04.25 Hamster-Pg/1.24
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On 29 Jun 2005 Harald Tveit Alvestrand <[e-mail]> wrote
in news:[e-mail]: 

> NEW:
> 
>    Some software will try to match the <id-right> of a msg-id in
>    a case-insensitive fashion; some will match it in a case
>    sensitive fashion. Implementations MUST NOT generate two
>    message-IDs where the only difference is the case of characters
>    in the <id-right> part. 

Should we give some guidance on what we would like people to do about 
matching? Given the efficiency of case sensitive comparison maybe 
something like:

Some software will try to match the <id-right> of a msg-id in a case-
insensitive fashion; some will match it in a case sensitive fashion 
(which is to be preferred). Implementations MUST NOT generate two
message-IDs where the only difference is the case of characters
in the <id-right> part.

That would alow a future standard to move to remove the restriction 
on generating MIDs differing just in case.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64MJZYt035151 for <[e-mail]>; Mon, 4 Jul 2005 15:19:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64MJZuN035150 for ietf-usefor-skb; Mon, 4 Jul 2005 15:19:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ID-77355.user.dfncis.de ([82.133.101.159]) by above.proper.com (8.12.11/8.12.9) with SMTP id j64MJXar035144 for <[e-mail]>; Mon, 4 Jul 2005 15:19:34 -0700 (PDT) (envelope-from [e-mail])
Received: from sjoh1646 ([127.0.0.1]) by sjoh1646 (192.168.254.2) with news-to-mail ; Mon, 04 Jul 2005 23:02:11 +0100
To: [e-mail]
Subject: Re: #1021 Single component newsgroups (Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
From: Graham Drabble <[e-mail]>
References: <A3144E13755E7D3CACB6EA26@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <78BBACC38DC374725A4EDD07@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> <[e-mail]>
Date: Mon, 04 Jul 2005 23:02:11 +0100
Organization: Home
Message-ID: <[e-mail]>
User-Agent: Xnews/5.04.25 Hamster-Pg/1.24
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On 30 Jun 2005 "Charles Lindsey" <[e-mail]> wrote in
news:[e-mail]: 

> 
> In <AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> Harald
> Tveit Alvestrand <[e-mail]> writes: 
> 
>>I think that's the consensus of the group at the moment:
> 
>>It's not sensible for the article *format* standard to say
>>anything about single component newsgroup names. They should be
>>permitted in syntax. 
> 
>>We'll return to the topic with USEAGE (if we get that far).
> 
> OK, I could take the single-component newsgroup-names to USEAGE,
> but it seems that the intent of Harald's latest proposal is to
> leave the rest of these "funny" newsgroup-names (control.*,
> junk.*, to.*, all-digit-components, etc.) in USEFOR.  Is that
> understanding correct? 

My view is that certainly all digit components should go to USEAGE 
and possibly others. All digit components only hurt a server whose 
admin has added the group, it doesn't harm if it is in a Newsgroups 
header or a Control header.

I don't understand what happens if you post to the others well enough 
to be able to comment.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64MJXJP035142 for <[e-mail]>; Mon, 4 Jul 2005 15:19:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64MJXCV035141 for ietf-usefor-skb; Mon, 4 Jul 2005 15:19:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ID-77355.user.dfncis.de ([82.133.101.159]) by above.proper.com (8.12.11/8.12.9) with SMTP id j64MJVsN035133 for <[e-mail]>; Mon, 4 Jul 2005 15:19:32 -0700 (PDT) (envelope-from [e-mail])
Received: from sjoh1646 ([127.0.0.1]) by sjoh1646 (192.168.254.2) with news-to-mail ; Mon, 04 Jul 2005 23:00:12 +0100
To: [e-mail]
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
From: Graham Drabble <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 04 Jul 2005 23:00:11 +0100
Organization: Home
Message-ID: <[e-mail]>
User-Agent: Xnews/5.04.25 Hamster-Pg/1.24
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On 01 Jul 2005 Bruce Lilly <[e-mail]> wrote in
news:[e-mail]: 

> On Thu June 30 2005 18:01, Graham Drabble wrote:
> 
>> FWIW I'm quite happy to allow them to do so. Nothing critical is
>> likely to break because something has the time +-12hrs so making
>> people code exceptions for things that were declared obsolete
>> (and MUST NOT generate) four years a go seems silly.
> 
> A few points to bear in mind:
> o if we paid due attention to backward compatibility, existing
> software 
>   will be largely conforming, and we're not making people code
>   exceptions because the 822 2- and 3-letter zone abbreviations
>   have long been required

New implementations would have to code exceptions to cater for 
something that everyone has been told they MUST NOT generate for four 
years. Existing parsing software would not need to change.

The changes are that existing generating software MUST stop generating 
the zone abreviations (which is in line with what 2822 told them), new 
parseing sofware can be simpler and people are told what to do with 
zones they don't recognise.


> o there exist archived messages (e.g. Frank's favorite non-Netnews
> but news-like mailing list interface gmane).  Many are more than
> four years old

The worst that happens is that something thinks they are 12 hours older 
/ younger than they are. In a old archive that is unlikely to matter.

> o FAQs and other old material may be periodically reposted with a
> new 
>   Injection-Date field, but with a Date field corresponding to the
>   last change.  That applies to things like a response to "can
>   somebody please post a copy of..." requests also.

That comes under the MUST NOT generate from 2822 which I haven't seen 
anyone arguing against.

> o combined mail/news UAs (the norm; Communicator, Thunderbird,
> Outlook 
>   Express, pine, etc.) need to deal with standard 2822 semantics
>   for the standard 2- and 3-letter zone abbreviations.

Such a beast would be conformant with what I proposed.

> o of course, "GMT" was also declared obsolete four years ago...

If you read my proposal carefully I don't mention GMT at all. However 
anyone not recognising it would still treat it correctly as they are 
told to assume -0000 (which is close enough to +0000 for it to not 
matter). Given that the only reason to special case it would be the 
amount that it is used and that it is in the middle of what can occur 
that seems reasonable to me.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64LxYgQ033908 for <[e-mail]>; Mon, 4 Jul 2005 14:59:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64LxYBF033907 for ietf-usefor-skb; Mon, 4 Jul 2005 14:59:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ID-77355.user.dfncis.de ([82.133.101.159]) by above.proper.com (8.12.11/8.12.9) with SMTP id j64LxV3k033899 for <[e-mail]>; Mon, 4 Jul 2005 14:59:32 -0700 (PDT) (envelope-from [e-mail])
Received: from sjoh1646 ([127.0.0.1]) by sjoh1646 (192.168.254.2) with news-to-mail ; Mon, 04 Jul 2005 22:52:08 +0100
To: [e-mail]
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
From: Graham Drabble <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 04 Jul 2005 22:52:08 +0100
Organization: Home
Message-ID: <[e-mail]>
User-Agent: Xnews/5.04.25 Hamster-Pg/1.24
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On 30 Jun 2005 "Forrest J. Cavalier III" <[e-mail]>
wrote in news:[e-mail]: 

> 
> I say that implementing an RFC2822-compliant date parser is "good
> enough" to reuse in netnews.  I disagree with forcing implementors
> should have to read this draft, and then wonder "gee, now that I
> read this tortured usefor-usefor-04 prose with references and
> modifications to RFC2822, do I have to do anything different, or
> can I just reuse my RFC2822 parsedate?" 

An RFC2822 date parser would be compatible with what I proposed. I 
suggested that they MAY implement the obs-zones and an RFC2822 parser 
will do so.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64JOrQg021699 for <[e-mail]>; Mon, 4 Jul 2005 12:24:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64JOrGM021698 for ietf-usefor-skb; Mon, 4 Jul 2005 12:24:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64JOqjO021692 for <[e-mail]>; Mon, 4 Jul 2005 12:24:52 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j64JOpTX004629 for <[e-mail]>; Mon, 4 Jul 2005 12:24:51 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6B89AE7CB0; Mon,  4 Jul 2005 12:24:51 -0700 (PDT)
To: [e-mail]
Subject: Re: required SP
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Mon, 4 Jul 2005 15:17:25 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 04 Jul 2005 12:24:51 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly <[e-mail]> writes:

> If the differences result in a subset of RFC 2822 format, then there
> already exist parsers: open source, closed source, validating,
> non-validating, C, C++, Perl, Python, etc.  Many have been tested
> extensively.

And are not suitable for use on Usenet in places where they need to block
the message IDs that are problematic.  If I'm going to write a message ID
parser for innd, I'm going to use the Usenet ABNF, not the mail ABNF and
then hack on additional scans for restrictions.

> If you mean a generator, ABNF might or might not help.

Thanks.  I've written enough parsers by now to know when it helps and when
it doesn't, but I appreciate your concern.

> In either case (generator or parser) Forrest is quite correct that a
> conflicting ABNF resets the conformance testing odometer.  Now if we
> were developing a new, incompatible format and accompanying protocol,
> that wouldn't matter as there would be no base.  But we are updating a
> specification for an existing, deployed format and protocols, where
> there is a substantial base of software that may need to be updated.

Currently, valid Usenet message IDs have no ABNF, so there's no odometer
to reset.

> In the unlikely event that there were a necessity to define ABNF, for
> crying out loud choose a different name for the different rule to
> avoid conflict with 2822.

As I've said multiple times, I don't care what the productions are called.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64JHesm021162 for <[e-mail]>; Mon, 4 Jul 2005 12:17:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64JHeEk021161 for ietf-usefor-skb; Mon, 4 Jul 2005 12:17:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64JHeBt021154 for <[e-mail]>; Mon, 4 Jul 2005 12:17:40 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 63AFF29919; Mon,  4 Jul 2005 15:17:39 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j64JHaQT014460(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Mon, 4 Jul 2005 15:17:37 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j64JHZRb014459(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Mon, 4 Jul 2005 15:17:36 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: required SP
Date: Mon, 4 Jul 2005 15:17:25 -0400
User-Agent: KMail/1.8.1
Cc: Russ Allbery <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Mon July 4 2005 14:19, Russ Allbery wrote:
> 
> Bruce Lilly <[e-mail]> writes:

> > The field or the component?  Can a subset of what is permitted by the
> > RFC 2822 syntax work, or is an incompatible superset required?  If a
> > subset is OK, why -- specifically -- *must* we redefine rather than
> > apply specific additional restrictions via normative text?
> 
> Because we actually want to help people write parsers

If the differences result in a subset of RFC 2822 format, then there
already exist parsers: open source, closed source, validating,
non-validating, C, C++, Perl, Python, etc.  Many have been tested
extensively.

[non-sequitur snipped]
> which means that 
> producing an actual working ABNF that incorporates the required
> restrictions is pretty useful.

If you really mean a parser, see Forrest's points about testing and
reuse, as well as the above comments.  Indeed, the primary point of
changing from the incompatible A news format to one based on RFC 822
(as noted in RFCs 850 and 1036) was to take advantage of existing
tools.

If you mean a generator, ABNF might or might not help.  ABNF isn't
needed to use fprintf etc.; simple normative text saying "do X, don't
do Y" is likely to be more useful to somebody writing generator software.
I doubt that many authors of generation software are going to go
through the trouble to write a formal grammar-based parser in order
to be able to generate fields.  I know of exactly one implementation
that works that way, and in that case generation is an add-on bonus
to the primary function of parsing with validation.

In either case (generator or parser) Forrest is quite correct that
a conflicting ABNF resets the conformance testing odometer.  Now if
we were developing a new, incompatible format and accompanying
protocol, that wouldn't matter as there would be no base.  But we
are updating a specification for an existing, deployed format and
protocols, where there is a substantial base of software that may
need to be updated.

In the unlikely event that there were a necessity to define ABNF, for
crying out loud choose a different name for the different rule to
avoid conflict with 2822.  That seems common sense; if you were to
write a children's story about a pet rabbit having nothing to do
with whales or whaling, it wouldn't be a good idea to title it
"Moby Dick", as that would likely cause confusion (possibly among
other undesirable side-effects).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IpXAn019298 for <[e-mail]>; Mon, 4 Jul 2005 11:51:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64IpXHK019297 for ietf-usefor-skb; Mon, 4 Jul 2005 11:51:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IpWdj019290 for <[e-mail]>; Mon, 4 Jul 2005 11:51:32 -0700 (PDT) (envelope-from [e-mail])
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 729479D9F2 for <[e-mail]>; Mon,  4 Jul 2005 14:51:31 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j64IpVQ01352; Mon, 4 Jul 2005 14:51:31 -0400 (EDT)
Date: Mon, 4 Jul 2005 14:51:31 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: New USEPRO path-identity text
References:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> wrote:

>   4. An arbitrary name believed to be unique and registered at least
>      with all other news-servers receiving articles directly from the
>      given one. The news-server administrator is responsible for
>      choosing an appropriate name (and must bear the consequences of an
>      inappropriate choice). This option SHOULD NOT be used unless the
>      earlier options are unavailable (e.g. because the host in question
>      is not connected to the Internet).

Rather than "must bear the consequences" (response: "Make me") I
prefer "will bear the consequences" (response: "Oops, I'd better
rethink that choice").

What does "registered [at least] with" mean?  Why does it matter?
(NNTP thinks those _sending to_ me should know my name(s) for
efficiency, but those _receiving from_ me don't have to care who I
claim to be today, do they?)

This appears to say (but doesn't) that the "arbitrary name" isn't an
FQDN that doesn't qualify under (1) or (3), but is used with
permission of the owner of the namespace.

Seth



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IkIEW018996 for <[e-mail]>; Mon, 4 Jul 2005 11:46:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64IkIaq018995 for ietf-usefor-skb; Mon, 4 Jul 2005 11:46:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IkHmK018989 for <[e-mail]>; Mon, 4 Jul 2005 11:46:17 -0700 (PDT) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1DpVxP-000AHE-FL for [e-mail]; Mon, 04 Jul 2005 18:46:15 +0000
Message-ID: <[e-mail]>
Date: Mon, 4 Jul 2005 19:44:42 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: New USEPRO path-identity text
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <LH6$+Lrj77PqENKLDCU+d+Q5go>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <[e-mail]>, Charles Lindsey
<[e-mail]> writes
>
>Following recent discussions, it seems agreed that IP addresses in
><path-identity>s are to be discouraged, 

yes

>and that arbitrary names are to be
>dioscouraged even more. 

if they are not traditional, then yes

>I have therefore modified the proposed USEPRO
>texts to take account of this. Comments?

you have put a SHOULD NOT against UUCP names ... reducing the level of
compliance of some of the oldest systems there are :(

this provision seems unnecessary since they aren't creating a problem

>   4. An arbitrary name believed to be unique and registered at least
>      with all other news-servers receiving articles directly from the
>      given one. The news-server administrator is responsible for
>      choosing an appropriate name (and must bear the consequences of an
>      inappropriate choice). This option SHOULD NOT be used unless the
>      earlier options are unavailable (e.g. because the host in question
>      is not connected to the Internet).

ie: the last sentence is unnecessary and doesn't follow from Harald's
proposal (see thread starting with <URL: http://www.imc.org/ietf-
usefor/mail-archive/msg01573.html>)

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

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQsmDmpoAxkTY1oPiEQId+wCfQkr4BUn3+IzrvPisskcA+QA+XkEAoP0m
WLGnyT2qh6djphRECaao5EOg
=Njcd
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IZ0Vi017886 for <[e-mail]>; Mon, 4 Jul 2005 11:35:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64IZ0il017885 for ietf-usefor-skb; Mon, 4 Jul 2005 11:35:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IYxfw017867 for <[e-mail]>; Mon, 4 Jul 2005 11:35:00 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j64IYxxL023229 for <[e-mail]>; Mon, 4 Jul 2005 11:34:59 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 1B225E7CB0; Mon,  4 Jul 2005 11:34:59 -0700 (PDT)
To: [e-mail]
Subject: Re: #1047 Path-identity: A proposal (perhaps)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Mon, 4 Jul 2005 13:16:18 GMT")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 04 Jul 2005 11:34:59 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey <[e-mail]> writes:

> Yes, but the path-address (IPv[46]address) is NOT "just diagnopstic
> information" . It is in fairly widespread current use, with the intent
> of avoiding duplicate propagation to the site which inserted it.

Huh, really?  I'm not saying you're wrong, since I've not checked, but
I've not personally seen anyone use an IP address as their actual path
identity (as opposed to having it added by their peers as diagnostic
information).

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IXrKe017519 for <[e-mail]>; Mon, 4 Jul 2005 11:33:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64IXrR8017518 for ietf-usefor-skb; Mon, 4 Jul 2005 11:33:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IXq5u017510 for <[e-mail]>; Mon, 4 Jul 2005 11:33:52 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j64IXqRB030573 for <[e-mail]>; Mon, 4 Jul 2005 11:33:52 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id C70DDE7CB0; Mon,  4 Jul 2005 11:33:51 -0700 (PDT)
To: [e-mail]
Subject: Re: required SP
In-Reply-To: <[e-mail]> (Forrest J. Cavalier, III's message of "Mon, 04 Jul 2005 08:44:03 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 04 Jul 2005 11:33:51 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Forrest J Cavalier <[e-mail]> writes:

> The only sane way of overlaying an operational restriction in
> object-oriented programming is to apply the restriction and then call
> the base class implementation.  It is NOT OK to re-implement it in the
> derived class.

This is way more absolute than is actually the case in practice.
Sometimes you want to use all of another object except one area that you
need to replace completely.  It's certainly not the preferred way of doing
things, but it can also be far cleaner (and require far less internal
knowledge of the parent class) to completely replace part of the
implementation rather than trying to selectively override things deep in
the internals.

Anyway, we may have reached the limit of utility for this particular
analogy, since standards are a lot more transparent to other documents
than object classes.

> Although REPEATING text from normative references is often "merely"
> clutter, REWRITING and PARAPHRASING text and ABNF from normative
> references is a big problem:

>     1. Already discussed the problem of subtle mismatches in understanding,
>        leading to incompatible implementations.

So be clear.  *shrug*.

>     2. Different text (and especially different ABNF productions) precludes
>        reuse.  If one could take off-the-shelf software that was already
>        known to be RFC2822 compliant for processing "From", a different
>        ABNF in USEFOR-USEFOR-04 would require review of that software
>        for compliance in all ways all over again.

You have to review all of your generators.  That's the whole POINT.

For the parsers, that's where we make a statement that the reformulation
is a strict subset, and then we *stick* to that, and check that very
carefully, so that software authors can rely on that statement.  It may be
worth an RFC 1036-style statement that any place where we mess up and
don't make things a strict subset, people should treat it that way anyway,
but really, we should just get it right.

>     3. All software requires validation and maintenance.  More software
>        requires increases validation and maintaince.  Reuse is important.

Yes, yes, we all agree that it would be great if we could use RFC 2822
as-is.  Also, I'd like a pony.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IPfNM016017 for <[e-mail]>; Mon, 4 Jul 2005 11:25:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64IPf72016016 for ietf-usefor-skb; Mon, 4 Jul 2005 11:25:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IPe6F016010 for <[e-mail]>; Mon, 4 Jul 2005 11:25:40 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j64IPde7022199 for <[e-mail]>; Mon, 4 Jul 2005 11:25:40 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9F7E2E7CB0; Mon,  4 Jul 2005 11:25:39 -0700 (PDT)
To: [e-mail]
Subject: Re: NEW: USEFOR -04 3.2.11 Xref vs. transport
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Mon, 4 Jul 2005 11:57:59 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 04 Jul 2005 11:25:39 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly <[e-mail]> writes:
> On Wed June 29 2005 12:55, Russ Allbery wrote:

>> You can't Xref-slave against more than one server at the same time, nor
>> can you assign numbers locally.  In an Xref slaving configuration, B
>> will perform its normal injection agent duties and then rather than
>> storing the article locally will immediately relay it to A *without*
>> assigning article numbers.  It will then wait for A to send it back
>> with article numbers assigned before storing it locally.

> More clarification please: Does B (slave) modify the Path field, or does
> that happen only at A?  When it comes back from A, does B then modify
> the Path field, or not?

Those are interesting questions.  The second one is simpler than the
first; yes, B always modifies the Path field to add its path identity when
receiving the article.

For the first, in general, no, B does not modify the Path field except to
create the field with its terminal element (almost always "not-for-mail")
if it doesn't already exist.  There is an exception in INN only when
running in virtual hosting mode, in which B will insert the Path identity
of the virtual host before sending the article to A -- in this mode, the
virtual host should not match the "real" Path identity of the server, and
is included partly as tracing information so that one can quickly see
which virtual server the article was injected through.

> What about Injection-Date and Injection-Info?

Nothing actually supports either yet, but adding those headers would be
part of the job of the injection agent, and hence would be added by B
before sending the message to A.  The B -> A connection is a relaying
connection, and therefore A will not do anything that it wouldn't do with
any other relayed message.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IJxu3015623 for <[e-mail]>; Mon, 4 Jul 2005 11:19:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64IJxBf015622 for ietf-usefor-skb; Mon, 4 Jul 2005 11:19:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64IJwaZ015616 for <[e-mail]>; Mon, 4 Jul 2005 11:19:58 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j64IJvZ8028975 for <[e-mail]>; Mon, 4 Jul 2005 11:19:57 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 603F6E7CB0; Mon,  4 Jul 2005 11:19:57 -0700 (PDT)
To: [e-mail]
Subject: Re: required SP
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Mon, 4 Jul 2005 10:07:27 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 04 Jul 2005 11:19:57 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly <[e-mail]> writes:

> Whether you're referring to the Message-ID field or to the msg-id field
> component, you'll have to do more than simply assert "we have to
> redefine"...

We have.  At great length.  At this point, I'm going to assume that it can
be taken as a given, no matter what you say, and stop repeating myself.

> The field or the component?  Can a subset of what is permitted by the
> RFC 2822 syntax work, or is an incompatible superset required?  If a
> subset is OK, why -- specifically -- *must* we redefine rather than
> apply specific additional restrictions via normative text?

Because we actually want to help people write parsers rather than just
concern ourselves with theoretical acts of purity, which means that
producing an actual working ABNF that incorporates the required
restrictions is pretty useful.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64HXlfS011796 for <[e-mail]>; Mon, 4 Jul 2005 10:33:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64HXl63011795 for ietf-usefor-skb; Mon, 4 Jul 2005 10:33:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.townisp.com (ns3a.townisp.com [216.195.0.136]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64HXknM011788 for <[e-mail]>; Mon, 4 Jul 2005 10:33:46 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns3.townisp.com (Postfix) with ESMTP id 67D9029937; Mon,  4 Jul 2005 13:33:44 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j64HXfdx013645(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Mon, 4 Jul 2005 13:33:41 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j64HXd6f013644(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Mon, 4 Jul 2005 13:33:39 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: New USEPRO path-identity text
Date: Mon, 4 Jul 2005 13:33:30 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Mon July 4 2005 10:54, Charles Lindsey wrote:
>    News-servers need to identify themselves by inserting their public
>    name, in the form of a <path-identity> (F-3.1.6), into Path,
>    Injection-Info and Xref headers.

Header fields.

>    An injecting agent MUST identify 
>    itself with the same <path-identity> in both Path and Injection-Info

What about Xref?

>    headers.

Header fields.

[...]
>    2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
>       3986] which SHOULD, according to the routeing tables [Ref needed]

Whose "routeing [sic] tables"?  My routing tables point here for the IP
address 127.0.0.1; if yours also point here, you have a problem. Likewise
for IP addresses which cannot be routed (RFC 1918).
 
>       identify the actual host, as above. This option SHOULD NOT be used
>       if an FQDN for that host is available.

For IPv6 and the Path field, and unless Frank's or John's suggestions
for replacing colons are used, there is an interoperability issue,
therefore s/SHOULD NOT/MUST NOT/, at least for IPv6.
  
>    3. A fully qualified domain name (FQDN) associated with an "MX"
>       record, which MUST be "mailable".

Perhaps combine with #1, probably also allow CNAMEs.
 
>    4. An arbitrary name believed to be unique and registered at least
>       with all other news-servers receiving articles directly from the
>       given one.

But not registered with senders?

[...]
>    For an injecting agent prepending to a Path header (7.2.2), the

field

>    <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable,
>    and if the agent offers its services to the general public the form
>    "abuse@<FQDN>" MUST also be available, unless a more specific
>    complaints address has been provided in a <complainto-param> of an
>    Injection-Info header (F-3.2.14).

field



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEOSA036523 for <[e-mail]>; Mon, 4 Jul 2005 09:14:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEOLu036521 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GENN9036501 for <[e-mail]>; Mon, 4 Jul 2005 09:14:24 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c9605e.1421b.71 for [e-mail]; Mon,  4 Jul 2005 17:14:22 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCta01070 for [e-mail]; Mon, 4 Jul 2005 17:12:55 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21886
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: New USEPRO path-identity text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
Date: Mon, 4 Jul 2005 14:54:46 GMT
Lines: 61
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Following recent discussions, it seems agreed that IP addresses in
<path-identity>s are to be discouraged, and that arbitrary names are to be
dioscouraged even more. I have therefore modified the proposed USEPRO
texts to take account of this. Comments?

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers.  To ensure that a <path-identity> provides a unique identity
   for the news-server concerned, it should be one of:
 
   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record, which SHOULD identify the actual host inserting
      this <path-identity> and, ideally, should also be "mailable" (see
      below).
 
   2. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
      3986] which SHOULD, according to the routeing tables [Ref needed]
      identify the actual host, as above. This option SHOULD NOT be used
      if an FQDN for that host is available.
 
   3. A fully qualified domain name (FQDN) associated with an "MX"
      record, which MUST be "mailable".
 
   4. An arbitrary name believed to be unique and registered at least
      with all other news-servers receiving articles directly from the
      given one. The news-server administrator is responsible for
      choosing an appropriate name (and must bear the consequences of an
      inappropriate choice). This option SHOULD NOT be used unless the
      earlier options are unavailable (e.g. because the host in question
      is not connected to the Internet).
 
        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within a <path-identity>,
        but only within an <IPv6address>.  It would therefor be unwise
        to choose, as the arbitrary name, anything composed solely of
        hexadecimal digits.
 
   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@<FQDN>" and
   "news@<FQDN>", in conformity with [RFC 2142].

   For an injecting agent prepending to a Path header (7.2.2), the
   <path-identity> MUST be option 1 or 3 and the FQDN MUST be mailable,
   and if the agent offers its services to the general public the form
   "abuse@<FQDN>" MUST also be available, unless a more specific
   complaints address has been provided in a <complainto-param> of an
   Injection-Info header (F-3.2.14).


-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GENIF036509 for <[e-mail]>; Mon, 4 Jul 2005 09:14:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GENhh036508 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEMDG036481 for <[e-mail]>; Mon, 4 Jul 2005 09:14:23 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c9605d.1421b.70 for [e-mail]; Mon,  4 Jul 2005 17:14:21 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GClO01045 for [e-mail]; Mon, 4 Jul 2005 17:12:47 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21881
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1021 USEFOR Newsgroups header - resolution proposed
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:42:48 GMT
Lines: 47
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>--On torsdag, juni 30, 2005 18:26:15 +0000 Charles Lindsey 
><[e-mail]> wrote:


>Makes no sense to me whatsoever. This may, however, be because the terms 
>"generated" and "accepted" are not defined.

>"accept" should be straightforward - if I send you a message, and you act 
>on it according to normal procedures, you have accepted it.

>"generate" may either mean "send" or mean "construct from component 
>pieces". The text I proposed used it as "send", and put the onus on 
>injecting agents for policing that they don't appear before there's a 
>standadr for them.

I guess it means "send", since it you construct a malformed article but
don't try to send it beyond your own machine, then who really cares?

And indeed, injecting agents have to do a lot of policing, but in
practical terms we can't expect them to catch _every_ conceivable error.


>I would be happier if we had "user agent" and "server" as the only terms in 
>the USEFOR description of the Netnews architecture, and put all the various 
>agents into USEPRO. But if USEFOR is going to have *any* context to its 
>description, I think it needs to have at least *some* terms defined.



>"example" is strictly a standards-definer's privillege junket.
>"junk" and "control" will (I think) cause things to break.

Actually, nothing breaks, but it adds to the spread of FUD, which is
indeed unwelcome. So I could live with SHOULD NOT for those.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEMcv036498 for <[e-mail]>; Mon, 4 Jul 2005 09:14:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEMl2036495 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GELCI036466 for <[e-mail]>; Mon, 4 Jul 2005 09:14:22 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c9605c.1421b.6f for [e-mail]; Mon,  4 Jul 2005 17:14:20 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GChg01030 for [e-mail]; Mon, 4 Jul 2005 17:12:44 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21878
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:16:18 GMT
Lines: 47
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>--On torsdag, juni 30, 2005 19:47:58 +0000 Charles Lindsey 
><[e-mail]> wrote:

>>    path-identity   =  ( ALPHA / DIGIT )
>>>                      *( ALPHA / DIGIT / "-" / "." / "_" )
>>
>>>   path-keyword    = "POSTED" / "MISMATCH"
>>
>>
>>>   path-address    =  IPv4address / no-fold-literal ; see [RFC2373]
>>
>> A good idea, but the term <path-identity> needs to include everything that
>> may occur in the list, except the two keywords, because it is used with
>> that meaning in many places.

>8 times in usefor, 10 times in usepro....

>If a path-address is really diagnostic information, this separation is in 
>fact useful, since you do NOT want those diagnostics where a real 
>path-identity is desired; I'd argue that the Xref header and the 
>Injection-info header should not need to contain a path-address.

Yes, but the path-address (IPv[46]address) is NOT "just diagnopstic
information"	. It is in fairly widespread current use, with the intent of
avoiding duplicate propagation to the site which inserted it.

OTOH, the keywords POSTED and MISMATCH, plus the double "!!" delimiter
_are_ for purely diagnostice purposes, and those are the things I want
excluded from <path-identity>.


>I think you've just strengthened the argument for separating the two....

I hope I have just strengthened the argument for keeping them together.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GELjP036477 for <[e-mail]>; Mon, 4 Jul 2005 09:14:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GELUX036476 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEKXJ036452 for <[e-mail]>; Mon, 4 Jul 2005 09:14:21 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c9605b.1421b.6e for [e-mail]; Mon,  4 Jul 2005 17:14:19 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCj501035 for [e-mail]; Mon, 4 Jul 2005 17:12:45 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21879
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:26:05 GMT
Lines: 42
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Fri July 1 2005 15:50, Charles Lindsey wrote:
>> 
>> In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>> >The ABNF implies that
>> >  Path: MISMATCH!tail-entry
>> >and
>> >  Path: MISMATCH!MISMATCH!tail-entry
>> >are legal, which I believe is not the intended use of the keywords.
>> 
>> The procedures for constructing a Path entry are contained in my suggested
>> USEPRO text posted here a week or so ago. It makes it clear exactly where
>> and when those two keywords may appear, so it is hardly necessary to
>> complicate the syntax with such matters (and there is no particular need
>> for agents to take note of those keywords when parsing).

>We *could* simply say
> path = "Path: " *text CRLF
>but that would hardly provide clarity about what is in the field.

Indeed, but all what a relaying agent needs (and has time) to do is to
identify the <path-delimiter>s and the <path-identity>s, so that it can
determine whether it is about to send to a site whose <path-identity> is
already listed. So that is all that the ABNF needs to cover.

All the rest is adequately described by the text which tells you how/when
to insert POSTED/MISMATCH, etc. If you ignore that text and put those
keywords in places where they should not be, then relaying agents won't
care, though humans might well be confused.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEJmn036449 for <[e-mail]>; Mon, 4 Jul 2005 09:14:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEJ08036448 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEIe0036410 for <[e-mail]>; Mon, 4 Jul 2005 09:14:19 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c96059.1421b.6c for [e-mail]; Mon,  4 Jul 2005 17:14:17 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCov01055 for [e-mail]; Mon, 4 Jul 2005 17:12:50 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21883
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1003 Message-ID text: Resolving
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 4 Jul 2005 13:53:01 GMT
Lines: 43
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:


>However, the text seems to have support as "better than what we have now".

Agreed.


> NEW:

> The Message-ID header contains a single unique message identifier.
> News is more dependent on msg-id uniqueness and fast comparision
>than
> email is, and some news software would have trouble with the full
>range
> of possible msg-ids permitted by RFC 2822;

I have already pointed out that it is more that "some" news software. It
is also the new NNTP standard-to-be.


> NEW:

> Some software will try to match the <id-right> of a msg-id in
> a case-insensitive fashion; some will match it in a case sensitive
> fashion. Implementations MUST NOT generate two message-IDs where
> the only difference is the case of characters in the <id-right> part.

> If domain literals are used, the syntax found in [RFC2821] section
> 4.1.3 is RECOMMENDED.

I think some people had a problem with that last sentence.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEKcw036459 for <[e-mail]>; Mon, 4 Jul 2005 09:14:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEKDI036458 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEJ9E036434 for <[e-mail]>; Mon, 4 Jul 2005 09:14:20 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c9605a.1421b.6d for [e-mail]; Mon,  4 Jul 2005 17:14:18 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCdg01015 for [e-mail]; Mon, 4 Jul 2005 17:12:40 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21876
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Style of documentation (Re: #1043 "header": Suggested resolution)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:04:53 GMT
Lines: 34
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>Forrest,

>somewhat flippantly, I'll assign half a point to Charles and half a point 
>to you.

>Most of the readers of the document will not bother to read all the 
>supporting documentation in detail.
>But - most of those readers are NOT implementors They seek a general 
>understanding, or want to clarify a particular point, they don't need to 
>understand all of it fully. And even more - most of the time, those readers 
>who ARE implementors can be well served by the "surface meaning" of the 
>words, and they will have little reason to dig into the references 
>(normative or not).

>Only in SOME cases will people have reason to dig into the documents to 
>clarify *exactly* what is meant by some point or prohibition.
>And it's our job as standards writers to make sure that in *those* cases, 
>the path back is clear.

Since I agree 100% with what you say, your half point is accepted with
gratitude.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEJjx036430 for <[e-mail]>; Mon, 4 Jul 2005 09:14:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEJUf036429 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEHZe036393 for <[e-mail]>; Mon, 4 Jul 2005 09:14:18 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c96059.1421b.6b for [e-mail]; Mon,  4 Jul 2005 17:14:17 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCrt01064 for [e-mail]; Mon, 4 Jul 2005 17:12:53 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21885
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:56:22 GMT
Lines: 30
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:
> 
>>> 5. Agents MAY remove comments from References.
>> Aaarrrrrrrrggggggggghhhhhhhhh! No!

>For followup-agents it's perfectly okay.  For other UAs or even
>gateways it's tricky.  Looking again at it, actually it should
>be "followup-agents MAY replace CFWS by FWS", we don't want an
><a@b>(c)<d@e> to <a@b><d@e> effect, but <a@b> <d@e> is okay in
>a followup.  In fact it's better.

Indeed, for followup agents, it is fine, but most certainly not for others.

However, the currently proposed USEPRO wording allows all you could
possibly want as regards removing/inserting comments by followup-agents.



-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEI25036401 for <[e-mail]>; Mon, 4 Jul 2005 09:14:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEIvY036400 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEH7h036384 for <[e-mail]>; Mon, 4 Jul 2005 09:14:17 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c96058.1421b.6a for [e-mail]; Mon,  4 Jul 2005 17:14:16 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCfA01023 for [e-mail]; Mon, 4 Jul 2005 17:12:41 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21877
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Style of documentation (Re: #1043 "header": Suggested resolution)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:08:48 GMT
Lines: 25
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>Note: Some poorly designed but widely implemented software, Foo Bar,
>  crashes and burns if an optional space is not present after the
>  colon delimiting the field name from the field body.  Therefore,
>  generators of messages which are also news articles SHOULD include
>  a space after the colon.   Software which cannot handle lack of an
>  optional space, an HTAB rather than space, etc., SHOULD be upgraded
>  as soon as practicable.

No, there is no question of "SHOULD be upgraded as soon as practicable" as
regards that SP after the colon. We have agreed long ago that was a step
too far, and that decision is also now hard-coded into the
NNTP-standard-to-be which has just passed its IETF Last Call.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEHT5036391 for <[e-mail]>; Mon, 4 Jul 2005 09:14:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEHSp036390 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEGj0036359 for <[e-mail]>; Mon, 4 Jul 2005 09:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c96057.1421b.69 for [e-mail]; Mon,  4 Jul 2005 17:14:15 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCkZ01040 for [e-mail]; Mon, 4 Jul 2005 17:12:46 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21880
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1003 USEFOR 3.1.3 Message-ID: Proposed text
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:32:06 GMT
Lines: 23
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>I guess you haven't been in that many NAT discussions....

>The fact is - a machine has no way of being sure his IPv4 address is 
>"uniquely his" or not.

If an IP packet sent from Timbuktu using that address arives at your
machine (and only at your machine), then it was "uniquely yours" at that
moment. IOW, which IP addresses are suited for use in <msg-id>s (and
<path-identity>s too for that matter), is ultimately determined by the
routeing tables.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEGkp036382 for <[e-mail]>; Mon, 4 Jul 2005 09:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEGUN036381 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEFPe036350 for <[e-mail]>; Mon, 4 Jul 2005 09:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c96056.1421b.68 for [e-mail]; Mon,  4 Jul 2005 17:14:14 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCpD01059 for [e-mail]; Mon, 4 Jul 2005 17:12:51 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21884
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1003 Message-ID text: Resolving
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Mon, 4 Jul 2005 13:54:00 GMT
Lines: 26
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Forrest J. Cavalier III" <[e-mail]> writes:

>Harald Tveit Alvestrand wrote:

>> Two significant issues seem to have been raised with the proposed 
>> resolution:
>> 
>> - What needs to be said in order to "play nice" with the $altz "control." 
>> convention (for instance, not to outlaw it)
>> - Whether, and if so where, the requirement not to go mess with other 
>> people's namespace needs to be documented

>If 1003 is makred resolved, what ticket(s) list the above two items?

I think those items are more USEPRO or UESEAGE.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEGkU036367 for <[e-mail]>; Mon, 4 Jul 2005 09:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64GEGGN036365 for ietf-usefor-skb; Mon, 4 Jul 2005 09:14:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64GEFs0036342 for <[e-mail]>; Mon, 4 Jul 2005 09:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-73.midband.mdip.bt.net ([81.144.64.73]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c96055.1421b.67 for [e-mail]; Mon,  4 Jul 2005 17:14:13 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j64GCm001049 for [e-mail]; Mon, 4 Jul 2005 17:12:48 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21882
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1021 USEFOR Newsgroups header - not quite resolved
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 4 Jul 2005 13:45:54 GMT
Lines: 29
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:


> Groups starting with the component "to"
> Groups starting with the component "control"
> Groups containing the component "all"
> Groups containing the component "ctl"
> The group "junk"

> This includes the groups "to", "control", "ctl" and "all".

I would suggest:

  Groups whose first (or only) component is "foo".

(just for those who cannot distinguish between subsets and proper subsets).

Also, what about some wording describing the reasons for the exclusions?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64FwG35020273 for <[e-mail]>; Mon, 4 Jul 2005 08:58:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64FwGSg020272 for ietf-usefor-skb; Mon, 4 Jul 2005 08:58:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64FwF1Y020229 for <[e-mail]>; Mon, 4 Jul 2005 08:58:16 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id BCE9D29959; Mon,  4 Jul 2005 11:58:14 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j64Fw8Km013113(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Mon, 4 Jul 2005 11:58:10 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j64Fw7PM013112(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Mon, 4 Jul 2005 11:58:08 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: NEW: USEFOR -04 3.2.11 Xref vs. transport
Date: Mon, 4 Jul 2005 11:57:59 -0400
User-Agent: KMail/1.8.1
Cc: Russ Allbery <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed June 29 2005 12:55, Russ Allbery wrote:
> 
> Bruce Lilly <[e-mail]> writes:
> > On Tue June 28 2005 22:46, Russ Allbery wrote:

> >> This is wrong for Xref slaving.  The serving agent does not remove the
> >> Xref header when Xref slaving is being used.
> 
> > Russ, I think I need some clarification:
> 
> > Are you saying that the "server-name" part remains unchanged?
> 
> Yup.
[...]
> The whole point of Xref slaving is to try to make things look the same to
> the connecting client.  However, the connecting client isn't the only
> point of view or the only connection that we have to think about.  It's
> completely different from the perspective of the serving agents
> themselves.
[...]
> You can't Xref-slave against more than one server at the same time, nor
> can you assign numbers locally.  In an Xref slaving configuration, B will
> perform its normal injection agent duties and then rather than storing the
> article locally will immediately relay it to A *without* assigning article
> numbers.  It will then wait for A to send it back with article numbers
> assigned before storing it locally.

More clarification please: Does B (slave) modify the Path field, or does
that happen only at A?  When it comes back from A, does B then modify
the Path field, or not?  What about Injection-Date and Injection-Info?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64EnInF043941 for <[e-mail]>; Mon, 4 Jul 2005 07:49:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64EnIdW043940 for ietf-usefor-skb; Mon, 4 Jul 2005 07:49:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64EnHOR043877 for <[e-mail]>; Mon, 4 Jul 2005 07:49:18 -0700 (PDT) (envelope-from [e-mail])
Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j64EnEF1029442; Mon, 4 Jul 2005 10:49:15 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j64EnE2q029441; Mon, 4 Jul 2005 10:49:14 -0400 (EDT)
Date: Mon, 4 Jul 2005 10:49:14 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Wed, 29 Jun 2005, Seth Breidbart wrote:
> It has _always_ been the case that the choice of which groups to carry
> is a local option, made on whatever basis (technical, financial,
> political, religious, . . .) the local admin decides.  Even if the
> syntax _permits_ such an article, all that means is that the server
> shouldn't fall over when it sees it; it's allowed to drop it on the
> floor for any or no reason.

There is a difference, however, between discarding groups because the
*local admin* wants them discarded, and discarding them because the
*software* is unable to cope with them.  The former is an issue of local
policy; the latter is an interoperability problem.  It is definitely
within our scope to put constraints on formats and protocols to avoid
known interoperability problems.

                                                          Henry Spencer
                                                       [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64E7pxs093875 for <[e-mail]>; Mon, 4 Jul 2005 07:07:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64E7phx093868 for ietf-usefor-skb; Mon, 4 Jul 2005 07:07:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64E7nlI093783 for <[e-mail]>; Mon, 4 Jul 2005 07:07:49 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id 6B7512992F; Mon,  4 Jul 2005 10:07:48 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j64E7d9L011729(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Mon, 4 Jul 2005 10:07:43 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j64E7bNl011728(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Mon, 4 Jul 2005 10:07:38 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: required SP
Date: Mon, 4 Jul 2005 10:07:27 -0400
User-Agent: KMail/1.8.1
Cc: Russ Allbery <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Sun July 3 2005 18:49, Russ Allbery wrote:
> Let's not get too worried about objections;
> let's worry about getting it right.

Assuming the objections are substantive -- and I have no reason to
believe otherwise -- there is little distinction; if we "get it right"
(i.e. clear with no conflicts with normative references and other
standards track protocols) there won't be any substantive objections
on those issues.
 
> We have to redefine message ID.

Whether you're referring to the Message-ID field or to the msg-id field
component,  you'll have to do more than simply assert "we have to
redefine"...

> The version in RFC 2822 doesn't work on 
> Usenet.

The field or the component?  Can a subset of what is permitted by the
RFC 2822 syntax work, or is an incompatible superset required?  If a
subset is OK, why -- specifically -- *must* we redefine rather than
apply specific additional restrictions via normative text?

> Why are we even still discussing that question? 

Because there is not yet a satisfactory resolution.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64CiHZO084153 for <[e-mail]>; Mon, 4 Jul 2005 05:44:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j64CiHDc084152 for ietf-usefor-skb; Mon, 4 Jul 2005 05:44:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.epix.net (pine.epix.net [199.224.64.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j64CiG3R084141 for <[e-mail]>; Mon, 4 Jul 2005 05:44:17 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-223-138-pppoe.dsl.hrbg.epix.net [216.37.223.138]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j64Chwgt000266 for <[e-mail]>; Mon, 4 Jul 2005 08:44:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 04 Jul 2005 08:44:03 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: required SP
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.154
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ Allbery wrote:

> Bruce Lilly <[e-mail]> writes:
> 
> 
>>2822 defines the From field (among others) and its syntax.  If
>>you introduce a different syntax for the same thing, you are
>>either trying to alter that syntax or you are introducing a
>>conflict (in this case with a normative reference).
> 
> 
> We're trying to reuse portions of a normative reference while overriding
> other portions.  It's not a particularly difficult or unusual concept, and
> it should be immediately familiar to anyone who's done object-oriented
> programming.
> 

It is dishonest to imply that this is ever done by redefining the API (i.e. types
of function parameters and return values.).

The only sane way of overlaying an operational restriction in object-oriented
programming is to apply the restriction and then call the base class implementation.
It is NOT OK to re-implement it in the derived class.

Anyone who overrides a base class implementation by REPEATING and REWRITING
it is totally missing the point of reuse.

Now most people on this list are going to roll their eyes at this point and say
"no big deal -- we just get a bulkier implementation, no harm in that."

They are wrong.  You cannot write specified software or standards specifications
that way.

Although REPEATING text from normative references is often "merely" clutter,
REWRITING and PARAPHRASING text and ABNF from normative references is a big
problem:
    1. Already discussed the problem of subtle mismatches in understanding,
       leading to incompatible implementations.

    2. Different text (and especially different ABNF productions) precludes
       reuse.  If one could take off-the-shelf software that was already known to be
       RFC2822 compliant for processing "From", a different ABNF in USEFOR-USEFOR-04
       would require review of that software for compliance in all ways all over again.

       One ABNF production + restrictions allows review of software just for compliance
       with the restrictions.  That's a really obvious difference that all careful
       implementors already understand.

    3. All software requires validation and maintenance.  More software requires
       increases validation and maintaince.  Reuse is important.

Programmers who are happy operating at CMM level 1 or below shouldn't even be part of
writing a standard.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j641AMjA001888 for <[e-mail]>; Sun, 3 Jul 2005 18:10:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j641ALCC001886 for ietf-usefor-skb; Sun, 3 Jul 2005 18:10:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j641AJTC001837 for <[e-mail]>; Sun, 3 Jul 2005 18:10:20 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpFTO-0001Gh-Ub for [e-mail]; Mon, 04 Jul 2005 03:10:10 +0200
Received: from 62.80.58.76 ([62.80.58.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 04 Jul 2005 03:10:10 +0200
Received: from nobody by 62.80.58.76 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 04 Jul 2005 03:10:10 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: required SP
Date:  Mon, 04 Jul 2005 03:07:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 62.80.58.76
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> I suspect, based on comments made by Mark Crispin two years
> ago here, that there will be a problem at Last Call.  Unless
> of course we avoid the problem by not trying to contradict
> 2822.

With that "unless" it couldn't fly.  Not that the IESG has any
problems to approve contradicting drafts intentionally, but as
you said there will be a proper "last call".  And a Message-ID
concept incompatible with RFC 977bis, 1036, s-o-1036, and 1738
would be too obvious.  All potential "last call" problems with
our fixed <msg-id> are limited to some objections against the
misleading <id-right> etc. production names, no big deal.  Bye




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63MnHUt065259 for <[e-mail]>; Sun, 3 Jul 2005 15:49:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j63MnHMO065258 for ietf-usefor-skb; Sun, 3 Jul 2005 15:49:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63MnGBs065252 for <[e-mail]>; Sun, 3 Jul 2005 15:49:16 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j63MnFux007125 for <[e-mail]>; Sun, 3 Jul 2005 15:49:16 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 87215E7CB0; Sun,  3 Jul 2005 15:49:15 -0700 (PDT)
To: [e-mail]
Subject: Re: required SP
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Sun, 3 Jul 2005 18:28:04 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Sun, 03 Jul 2005 15:49:15 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly <[e-mail]> writes:

> A redefinition of msg-id is going to cause problems, no matter
> whose it is.
 
> I suspect, based on comments made by Mark Crispin two years ago
> here, that there will be a problem at Last Call.  Unless of course
> we avoid the problem by not trying to contradict 2822.

That's nice.  Mark objected to things in the NNTP standard too, and it's
been approved by the IESG.  Let's not get too worried about objections;
let's worry about getting it right.

We have to redefine message ID.  The version in RFC 2822 doesn't work on
Usenet.  Why are we even still discussing that question?

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63MSHtt040849 for <[e-mail]>; Sun, 3 Jul 2005 15:28:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j63MSHED040848 for ietf-usefor-skb; Sun, 3 Jul 2005 15:28:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63MSGaR040809 for <[e-mail]>; Sun, 3 Jul 2005 15:28:16 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id 05D9E29914; Sun,  3 Jul 2005 18:28:14 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j63MSCj4009387(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Sun, 3 Jul 2005 18:28:13 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j63MS9VF009386(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Sun, 3 Jul 2005 18:28:10 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: required SP
Date: Sun, 3 Jul 2005 18:28:04 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Sun July 3 2005 15:44, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > If you introduce a different syntax for the same thing
> 
> We're not "introducing" a single bit apart from Injection-Info
> and backwards compatible (modulo IPv6 colon) Path improvements.

s/introduce/specify/

> What we do is to describe the things as they are.  And they are
> different from RFC 2822.  Handwaving, weasel words, and wishful
> thinking to pretend equality are no option.  It's our job to
> describe the differences.  And this mandatoy SP _is_ different.

Fine, but don't try to redefine From, orig-date, zone, msg-id,
unstructured, etc.  One definition is OK; two conflicting
definitions will cause confusion.
 
> If you think that saying [FWS] in places where folding is not
> allowed by not less than a MUST NOT is okay we disagree - I'd
> prefer to say *WSP instead of lying in syntax.

We need not and should not provide ABNF for grammar productions
defined in RFC 2822:

   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.
 
> Some days ago you complained about a 2822 obs-MUST that is a
> MAY in USEFOR, with two exceptions where it's again a MUST.
> What about all those funny [FWS] that are in fact only *WSP ?

One or more notes detailing the issue and the added restriction.
 
> Your maximal demands are counterproductive.  In the case of the
> <id-right> semantics where you did not support my <id-domain>
> what you'll get is exactly what you didn't want, Charles' idea
> of (among others) a random case insensitive RHS.

A redefinition of msg-id is going to cause problems, no matter
whose it is.
 
I suspect, based on comments made by Mark Crispin two years ago
here, that there will be a problem at Last Call.  Unless of course
we avoid the problem by not trying to contradict 2822.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63K6jV0082687 for <[e-mail]>; Sun, 3 Jul 2005 13:06:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j63K6jfj082686 for ietf-usefor-skb; Sun, 3 Jul 2005 13:06:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63K6hbp082667 for <[e-mail]>; Sun, 3 Jul 2005 13:06:44 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpAjd-0007H7-CR for [e-mail]; Sun, 03 Jul 2005 22:06:37 +0200
Received: from 62.80.58.76 ([62.80.58.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 03 Jul 2005 22:06:37 +0200
Received: from nobody by 62.80.58.76 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 03 Jul 2005 22:06:37 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: required SP
Date:  Sun, 03 Jul 2005 21:44:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 55
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 62.80.58.76
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> If you introduce a different syntax for the same thing

We're not "introducing" a single bit apart from Injection-Info
and backwards compatible (modulo IPv6 colon) Path improvements.

What we do is to describe the things as they are.  And they are
different from RFC 2822.  Handwaving, weasel words, and wishful
thinking to pretend equality are no option.  It's our job to
describe the differences.  And this mandatoy SP _is_ different.

> Best to keep the ABNF grammar as defined in 2822, and
> introduce notes restricting usage of the full syntax where
> necessary or recommended.

If you think that saying [FWS] in places where folding is not
allowed by not less than a MUST NOT is okay we disagree - I'd
prefer to say *WSP instead of lying in syntax.

Some days ago you complained about a 2822 obs-MUST that is a
MAY in USEFOR, with two exceptions where it's again a MUST.
What about all those funny [FWS] that are in fact only *WSP ?

Sorry Bruce, I haven't invented this SP *WSP stuff.  But it
doesn't go away by lying in the syntax, and [FWS] is certainly
not better.  FWS could be nice, but without a time machine we
have no way to "introduce a different syntax" in news or mail:

"Each header line consists of a keyword, a colon, a blank, and
 some additional information.  This is a subset of the Internet
 standard, simplified to allow simpler software to handle it."

> It's not required by the normative reference

If you wish to discuss the WG Charter with Alexey and Harald
go ahead.  I have no serious problems with it, the additional
bit about a "proper subset" or "simplified" (claimed by 1036)
is clear.

Your maximal demands are counterproductive.  In the case of the
<id-right> semantics where you did not support my <id-domain>
what you'll get is exactly what you didn't want, Charles' idea
of (among others) a random case insensitive RHS.

It will be the same problem with the SP, instead of fixing the
bogus SP [FWS] we'll end up with a foul compromise of SP [FWS]
instead of the correct SP *WSP, no chance for a transition plan
to 1*WSP.  IMHO you make it worse with your maximal demands. :-(

                         Bye. Frank

P.S.:  The References are a case where 2822 indirectly allows
       [CFWS] [CFWS].  Our CFWS in the <msg-id-list> is better.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63JHPZN029073 for <[e-mail]>; Sun, 3 Jul 2005 12:17:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j63JHPEn029067 for ietf-usefor-skb; Sun, 3 Jul 2005 12:17:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63JHM8o028943 for <[e-mail]>; Sun, 3 Jul 2005 12:17:22 -0700 (PDT) (envelope-from [e-mail])
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j63JHKkw019667 for <[e-mail]>; Sun, 3 Jul 2005 12:17:20 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 697EBE7CB0; Sun,  3 Jul 2005 12:17:20 -0700 (PDT)
To: [e-mail]
Subject: Re: required SP
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Sun, 3 Jul 2005 14:31:51 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Sun, 03 Jul 2005 12:17:20 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly <[e-mail]> writes:

> 2822 defines the From field (among others) and its syntax.  If
> you introduce a different syntax for the same thing, you are
> either trying to alter that syntax or you are introducing a
> conflict (in this case with a normative reference).

We're trying to reuse portions of a normative reference while overriding
other portions.  It's not a particularly difficult or unusual concept, and
it should be immediately familiar to anyone who's done object-oriented
programming.

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63IWBvv077317 for <[e-mail]>; Sun, 3 Jul 2005 11:32:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j63IWBur077316 for ietf-usefor-skb; Sun, 3 Jul 2005 11:32:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63IWA5p077246 for <[e-mail]>; Sun, 3 Jul 2005 11:32:10 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id 2FF9B29921; Sun,  3 Jul 2005 14:32:09 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j63IW3r2008487(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Sun, 3 Jul 2005 14:32:06 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j63IW0tV008486(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Sun, 3 Jul 2005 14:32:01 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: required SP (was: Style of documentation)
Date: Sun, 3 Jul 2005 14:31:51 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Sun July 3 2005 13:43, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> >> we have to show the modified syntax.
> > we have no authority to modify RFC 2822
> 
> Nobody proposed "updates 2822",

2822 defines the From field (among others) and its syntax.  If
you introduce a different syntax for the same thing, you are
either trying to alter that syntax or you are introducing a
conflict (in this case with a normative reference).  Best to
keep the ABNF grammar as defined in 2822, and introduce notes
restricting usage of the full syntax where necessary or
recommended.

> > poorly designed but widely implemented software, Foo Bar,
> > crashes and burns if an optional space is not present after
> > the colon delimiting the field name from the field body.
> 
> Optional is not the same as required.

It's not required by the normative reference.  Or its
predecessor.  Or that specification's predecessor...
s/an optional space /a space character/ if it makes you happy.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63Hkx3o024959 for <[e-mail]>; Sun, 3 Jul 2005 10:46:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j63HkxRT024957 for ietf-usefor-skb; Sun, 3 Jul 2005 10:46:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63HkueM024814 for <[e-mail]>; Sun, 3 Jul 2005 10:46:57 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dp8YA-0003iL-EL for [e-mail]; Sun, 03 Jul 2005 19:46:39 +0200
Received: from 62.80.58.76 ([62.80.58.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 03 Jul 2005 19:46:38 +0200
Received: from nobody by 62.80.58.76 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 03 Jul 2005 19:46:38 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  required SP (was: Style of documentation)
Date:  Sun, 03 Jul 2005 19:43:25 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 31
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 62.80.58.76
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce Lilly wrote:

> RFC 2822: April, 2001 = this millenium

Really "nn", I used to get this wrong.

>> we have to show the modified syntax.
> we have no authority to modify RFC 2822

Nobody proposed "updates 2822", just stick to the plan
as defined in the Charter, anything that's required in
NetNews and a proper subset of 2822 is simply REQUIRED.

> poorly designed but widely implemented software, Foo Bar,
> crashes and burns if an optional space is not present after
> the colon delimiting the field name from the field body.

Optional is not the same as required.  I tested SP => FWS,
and it's not good enough.  Let alone SP => [CFWS] to get
pure 2822.

I have not yet tested to replace the dubious SP [FWS] by
1*WSP allowing at least HT where folding clearly does not
work.  IIRC somebody (Charles, Henry, Russ, or maybe all)
said that HT doesn't work.

And I tried to replace the erroneous SP [FWS] by a correct
SP *WSP, nobody but Charles cared, and he didn't like it.
Check the old SP [FWS] and [FWS] CRLF thread - apparently
that's left to a hot *WSP fix in the IETF last call.  Bye.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63C1qBP092808 for <[e-mail]>; Sun, 3 Jul 2005 05:01:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j63C1qS1092801 for ietf-usefor-skb; Sun, 3 Jul 2005 05:01:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j63C1pQc092732 for <[e-mail]>; Sun, 3 Jul 2005 05:01:51 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id 3806429954; Sun,  3 Jul 2005 08:01:48 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j63C1efo006792(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Sun, 3 Jul 2005 08:01:44 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j63C1cB6006791(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Sun, 3 Jul 2005 08:01:39 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: Style of documentation (Re: #1043 "header": Suggested resolution)
Date: Sun, 3 Jul 2005 08:01:32 -0400
User-Agent: KMail/1.8.1
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Sat July 2 2005 00:48, Frank Ellermann wrote:
> 1 - I'm Joe Usenet User and want to understand the spec. - no
>     problem with some prerequisites and keeping it as short as
>     possible, but it must make sense where it differs from any
>     plausible expectation (especially 1036, s-o-1036, 2822)
[...]
> The reader,
> implementor or not, can be 15 years old, and (s)he has a right
> to know absolutely nothing about Usenet in the past millennium.

RFC 2822: April, 2001 = this millenium
The others: "the reader, implementer or not..."
 
> > We have a lot of ABNF repeats of RFC2822.  Why?  E.g. in
> > 3.1.1 we have
> 
> >       from            =  "From:" SP mailbox-list CRLF
> 
> Just compare it with 2822, it is *different*, and that's why we
> have to show the modified syntax.

No, we have no authority to modify RFC 2822 or what it defines.
Attempting to do so by redefining syntax will confuse readers
(implementers or not).  It provides no clue as to *why* there is
a difference or which of the two conflicting specifications has
precedence (unlike 1036, which clearly deferred to 822 in the case
of conflict).  We can provide an implementation note such as:

Note: Some poorly designed but widely implemented software, Foo Bar,
  crashes and burns if an optional space is not present after the
  colon delimiting the field name from the field body.  Therefore,
  generators of messages which are also news articles SHOULD include
  a space after the colon.   Software which cannot handle lack of an
  optional space, an HTAB rather than space, etc., SHOULD be upgraded
  as soon as practicable.

Keeping the syntax as it is defined in the normative reference, i.e.
general, and dealing with specific issues n implementations notes
provides clarity for readers (implementers or not).  It explains clearly
*what* issue exists, *how* to work around that issue, *where* and
*when* to do so, *who* should do so, and it introduces no grammar
inconsistencies.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j626uZ6T015725 for <[e-mail]>; Fri, 1 Jul 2005 23:56:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j626uZ4f015724 for ietf-usefor-skb; Fri, 1 Jul 2005 23:56:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j626uXtS015681 for <[e-mail]>; Fri, 1 Jul 2005 23:56:34 -0700 (PDT) (envelope-from [e-mail])
Received: from isop10 (velvet.isolution.nl [194.109.164.102]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.3/8.13.3) with ESMTP id j626uR47025611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sat, 2 Jul 2005 08:56:32 +0200 (CEST) (envelope-from [e-mail])
Message-ID: <060d01c57ed3$2d127230$[e-mail]>
From: "Ruud H.G. van Tol" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)
Date: Sat, 2 Jul 2005 08:50:32 +0200
Organization: Chaos rules.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Virus-Scanned: by XS4ALL Virus Scanner
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey:
> Forrest J. Cavalier III:

>> 5. Agents MAY remove comments from References.
>
> [...]
> There is a limited provision for injecting agents to "mend" things
> that are incomplete [...]

Incomplete in the sense of 'unfinished'. :)


> I don't really think this one is a good candidate even for that,
> though.

Of course such header fields MUST NOT change in 'public' transit. 
A followup-agent "MAY replace CFWS by FWS" (as Frank says).

-- 
Grtz, Ruud



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j626aT7l088042 for <[e-mail]>; Fri, 1 Jul 2005 23:36:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j626aTqj088041 for ietf-usefor-skb; Fri, 1 Jul 2005 23:36:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j626aRCn088019 for <[e-mail]>; Fri, 1 Jul 2005 23:36:28 -0700 (PDT) (envelope-from [e-mail])
Received: from isop10 (velvet.isolution.nl [194.109.164.102]) (authenticated bits=0) by smtp-vbr8.xs4all.nl (8.13.3/8.13.3) with ESMTP id j626aKrx076537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sat, 2 Jul 2005 08:36:26 +0200 (CEST) (envelope-from [e-mail])
Message-ID: <05d801c57ed0$5df6a630$[e-mail]>
From: "Ruud H.G. van Tol" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: #1021 USEFOR Newsgroups header - resolution proposed
Date: Sat, 2 Jul 2005 08:30:46 +0200
Organization: Chaos rules.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Virus-Scanned: by XS4ALL Virus Scanner
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey:
> Charles Lindsey:
>> Harald Tveit Alvestrand:

>>> Groups starting with the component "to"
>>> Groups containing the component "all"
>>> Groups containing the component "ctl"
>>
>>  Groups starting with the component "control"

>>> The group "control"
>>
>> But you can omit that, because it is already excluded because its
>> first (& only) component is excluded.
>
> Thinking further about this, you could also word those cases as:
>    Groups starting with (or consisting of) the component "to"
> just for the removal of all doubt.

Groups starting with, or solely consisting of, one of these components:
"a", "b", "c".
(s/one/any/)

And for the others:
Groups containing any of these components: "d", "e", "f".

-- 
Affijn, Ruud



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6254VhW004766 for <[e-mail]>; Fri, 1 Jul 2005 22:04:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6254V7c004765 for ietf-usefor-skb; Fri, 1 Jul 2005 22:04:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6254TVD004736 for <[e-mail]>; Fri, 1 Jul 2005 22:04:30 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Doa3K-0006Ew-D1 for [e-mail]; Sat, 02 Jul 2005 06:56:30 +0200
Received: from 212.82.251.33 ([212.82.251.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 02 Jul 2005 06:56:30 +0200
Received: from nobody by 212.82.251.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 02 Jul 2005 06:56:30 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)
Date:  Sat, 02 Jul 2005 07:03:16 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.33
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
 
>> 5. Agents MAY remove comments from References.
> Aaarrrrrrrrggggggggghhhhhhhhh! No!

For followup-agents it's perfectly okay.  For other UAs or even
gateways it's tricky.  Looking again at it, actually it should
be "followup-agents MAY replace CFWS by FWS", we don't want an
<a@b>(c)<d@e> to <a@b><d@e> effect, but <a@b> <d@e> is okay in
a followup.  In fact it's better.
                                    Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j624oCA3002811 for <[e-mail]>; Fri, 1 Jul 2005 21:50:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j624oCkp002810 for ietf-usefor-skb; Fri, 1 Jul 2005 21:50:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j624o9uj002804 for <[e-mail]>; Fri, 1 Jul 2005 21:50:10 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DoZpa-0005Xk-2Q for [e-mail]; Sat, 02 Jul 2005 06:42:18 +0200
Received: from 212.82.251.33 ([212.82.251.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 02 Jul 2005 06:42:18 +0200
Received: from nobody by 212.82.251.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 02 Jul 2005 06:42:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Style of documentation (Re: #1043 "header": Suggested resolution)
Date:  Sat, 02 Jul 2005 06:48:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 45
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.33
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Forrest J. Cavalier III wrote:
 
> If Joe Usenet User wants to read a specification written for
> implementors, WE HAVE NO CONCERN FOR HIM.

1 - I'm Joe Usenet User and want to understand the spec. - no
    problem with some prerequisites and keeping it as short as
    possible, but it must make sense where it differs from any
    plausible expectation (especially 1036, s-o-1036, 2822)
  
2 - the spec. is not only for implementors, it's also for news
    admins, gateway operators, moderators, and cases like (1) 
    
> Let someone else paraphrase and write "USEFOR for dummies."

3 - Yes, this "someone" also has to get the drift of the spec.

> this isn't an excuse to be less clear and less verbose, it is
> the only way to be more concise and more clear.

Concise and clear is fine, but not beyond recognition.

> But there is more! later on it is RESTATED AGAIN!
>     Each <path-identity> in the <path-list> (excluding the
>     one in the <tail-entry>) indicates, from right to left,
[...]

Yes, that could be simplified, besides it's now wrong, we have
separated <path-identity> and <tail-entry>, and excluding the
latter makes no more sense.  

But it's perfectly okay to say that this beast was once a bang-
path, otherwise "not-for-mail" would be gibberish.  The reader,
implementor or not, can be 15 years old, and (s)he has a right
to know absolutely nothing about Usenet in the past millennium.

> We have a lot of ABNF repeats of RFC2822.  Why?  E.g. in
> 3.1.1 we have

>       from            =  "From:" SP mailbox-list CRLF

Just compare it with 2822, it is *different*, and that's why we
have to show the modified syntax.
                                  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j620qITd069851 for <[e-mail]>; Fri, 1 Jul 2005 17:52:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j620qIsf069850 for ietf-usefor-skb; Fri, 1 Jul 2005 17:52:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail01.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j620pjQ5069561 for <[e-mail]>; Fri, 1 Jul 2005 17:52:15 -0700 (PDT) (envelope-from [e-mail])
Received: from a.shell.peak.org ([69.59.192.81]) by mail01.peak.org (8.12.10/8.12.8) with ESMTP id j620pcDC065969 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 1 Jul 2005 17:51:39 -0700 (PDT)
Date: Fri, 1 Jul 2005 17:51:38 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>   News-servers need to identify themselves by inserting their public
>   name, in the form of a <path-identity> (F-3.1.6), into Path,
>   Injection-Info and Xref headers. An injecting agent MUST identify
>   itself with the same <path-identity> in both Path and Injection-Info
>   headers.  To ensure that a <path-identity> provides a unique identity
>   for the news-server concerned, it SHOULD be one of: ..........

s/headers/header fields/g;

>>Global uniqueness is an interoperability requirement ("to work properly");
>>s/must/MUST/ would make that clear.

>I think the USEPRO text above covers that.

There is no MUST regarding uniqueness. There is only a SHOULD as to what 
it is "one of".




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61MpmeT015058 for <[e-mail]>; Fri, 1 Jul 2005 15:52:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61Mpm7X015057 for ietf-usefor-skb; Fri, 1 Jul 2005 15:51:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns5.townisp.com (ns5a.townisp.com [216.195.0.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61MpfEw015027 for <[e-mail]>; Fri, 1 Jul 2005 15:51:47 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns5.townisp.com (Postfix) with ESMTP id 3DCD929905; Fri,  1 Jul 2005 18:51:41 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j61Mpe3f030357(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 1 Jul 2005 18:51:40 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j61MpbQb030356(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 1 Jul 2005 18:51:38 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Date: Fri, 1 Jul 2005 18:51:28 -0400
User-Agent: KMail/1.8.1
Cc: "Charles Lindsey" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri July 1 2005 15:50, Charles Lindsey wrote:
> 
> In <[e-mail]> Bruce Lilly <[e-mail]> writes:

> >The ABNF implies that
> >  Path: MISMATCH!tail-entry
> >and
> >  Path: MISMATCH!MISMATCH!tail-entry
> >are legal, which I believe is not the intended use of the keywords.
> 
> The procedures for constructing a Path entry are contained in my suggested
> USEPRO text posted here a week or so ago. It makes it clear exactly where
> and when those two keywords may appear, so it is hardly necessary to
> complicate the syntax with such matters (and there is no particular need
> for agents to take note of those keywords when parsing).

We *could* simply say
 path = "Path: " *text CRLF
but that would hardly provide clarity about what is in the field.  There
are two related issues:
1. the text appears to be wrong about the description, particularly w.r.t.
   MISMATCH
2. the ABNF should be consistent with the text, and should work with the
   text to provide a *clear* specification

> >>   NOTE: The path-address contains characters that some systems consider
> >>      path-delimiters. This can cause problems; path-address should
> >>      therefore only be used when absolutely necessary.
> >>      See [USEPRO] for details on when to use them.
> 
> 
> >Because of the backward compatibility/interoperability problem
> >s/should/MUST/.
> 
> No, because there are plenty of hosts around that have IP addresses but no
> domain name. The text proposed for USEPRO makes it clear that IP addresses
> are the least desirable alternative.

That goes against Harald's "diagnostic stuff" suggestion.  A host with
an IP address but no domain name could, I suppose, concoct one in
in-addr.arpa.  The big problem is that many IP addresses are not unique,
and I suspect that the ones with unique ones have a domain name, especially
if they're running a news server, if for no other reason than to comply
with RFC 2142.  *If* they have no other choice, then that would meet the
"when absolutely necessary" condition, so there's no problem with MUST.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkHdY040892 for <[e-mail]>; Fri, 1 Jul 2005 13:46:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61KkHxj040891 for ietf-usefor-skb; Fri, 1 Jul 2005 13:46:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkEid040760 for <[e-mail]>; Fri, 1 Jul 2005 13:46:16 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-126.midband.mdip.bt.net ([81.144.65.126]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c5ab95.b4b4.14a for [e-mail]; Fri,  1 Jul 2005 21:46:13 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j61KaxX22336 for [e-mail]; Fri, 1 Jul 2005 21:36:59 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21839
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Fri, 1 Jul 2005 19:50:04 GMT
Lines: 67
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Bruce Lilly <[e-mail]> writes:

>On Wed June 29 2005 08:33, Harald Tveit Alvestrand wrote:
>>   A path-identity identifies an agent. For the news system to work
>>   properly, the path-identity must be globally unique.

>If we mean "public name" we should probably say so: s/identifies/is a
>public name identifying/

Well it is really the text in USEPRO that should say that, but it is a
good point, so the proposed USEPRO text now starts:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers.  To ensure that a <path-identity> provides a unique identity
   for the news-server concerned, it SHOULD be one of: ..........

>Global uniqueness is an interoperability requirement ("to work properly");
>s/must/MUST/ would make that clear.

I think the USEPRO text above covers that.


>Because of the global uniqueness requirement, s/should/MUST/.  Add
>something to address Frank's concern about unauthorized use.

And the proposed USEPRO text also covers that, though it could be
strengthened.


>The ABNF implies that
>  Path: MISMATCH!tail-entry
>and
>  Path: MISMATCH!MISMATCH!tail-entry
>are legal, which I believe is not the intended use of the keywords.

The procedures for constructing a Path entry are contained in my suggested
USEPRO text posted here a week or so ago. It makes it clear exactly where
and when those two keywords may appear, so it is hardly necessary to
complicate the syntax with such matters (and there is no particular need
for agents to take note of those keywords when parsing).

>>   NOTE: The path-address contains characters that some systems consider
>>      path-delimiters. This can cause problems; path-address should
>>      therefore only be used when absolutely necessary.
>>      See [USEPRO] for details on when to use them.


>Because of the backward compatibility/interoperability problem
>s/should/MUST/.

No, because there are plenty of hosts around that have IP addresses but no
domain name. The text proposed for USEPRO makes it clear that IP addresses
are the least desirable alternative.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkEJG040753 for <[e-mail]>; Fri, 1 Jul 2005 13:46:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61KkEnA040750 for ietf-usefor-skb; Fri, 1 Jul 2005 13:46:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkCw4040656 for <[e-mail]>; Fri, 1 Jul 2005 13:46:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-126.midband.mdip.bt.net ([81.144.65.126]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c5ab93.b4b4.148 for [e-mail]; Fri,  1 Jul 2005 21:46:11 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j61Kb6E22369 for [e-mail]; Fri, 1 Jul 2005 21:37:06 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21842
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Fri, 1 Jul 2005 20:17:37 GMT
Lines: 45
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Frank Ellermann <[e-mail]> writes:
>> Russ Allbery wrote:

>The military time zones were deprecated by RFC 1123, and more tellingly,
>they also don't appear in practice.  I have no problem getting rid of them
>except insofar as it adds wording complexity.  But I *do* have a problem
>going straight from RFC 1036 to allowing servers to not even parse the
>North American time zones, which are still in use (albeit not heavily).

I think the likely harm is pretty minimal. User agents might present
articles in a funny order if some dates were interpreted 5 hours out, but
then the majority of user agents are also mail agents, so they are still
bound by RFC 2822.

And if some articles get considered as "stale" 5 hours too early, it is
not a huge deal.

I think the principles to establish are that:

1. We don't distinguish between Injection-Date and the other headers in
what we write.

2. The only options available to us are:

2a. As Harald's wording (only GMT is MUST accept)
2b. Accept all of <obs-zone> (probably apart from the military ones).

Whilst I still prefer 2a, I grant you there is an arguable case for 2b.


As regards IMAP, which Bruce raised, if an IMAP implementation sees "EST",
it should do whatever the IMAP standards say. That is not our concern.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkDuJ040693 for <[e-mail]>; Fri, 1 Jul 2005 13:46:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61KkDed040689 for ietf-usefor-skb; Fri, 1 Jul 2005 13:46:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkBGb040633 for <[e-mail]>; Fri, 1 Jul 2005 13:46:12 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-126.midband.mdip.bt.net ([81.144.65.126]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c5ab93.b4b4.147 for [e-mail]; Fri,  1 Jul 2005 21:46:11 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j61Kb0N22340 for [e-mail]; Fri, 1 Jul 2005 21:37:00 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21840
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 1 Jul 2005 20:02:43 GMT
Lines: 39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Frank Ellermann <[e-mail]> writes:


So I have s/SHOULD/should/. I tried other wordings, but that seemed to fit
best.

>>| The FQDN of a news-server is "mailable" if its
>>| administrators can be reached by email using both of the
>>| forms "usenet@<FQDN>" and "news@<FQDN>", in conformity
>>| with [RFC 2142].

>Maybe say 'forms "usenet@" and "news@" at the FQDN represented
>by the <path-identity>, in conformity with [RFC 2142].'  Issue:
>I'm not sure about using <FQDN> if that's no term in the ABNF.

OK, I have done that:

   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@" and "news@"
   followed by that FQDN, in conformity with [RFC 2142].


>Some of Bruce's points are not yet covered, MISMATCH!MISMATCH
>etc., maybe we have to declare these beasts as special cases
>of a path-delimiter, brain-storming:

See my reply to Bruce. USEPRO gives clear instructions how to construct
them, and that is probably enough.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkCbx040660 for <[e-mail]>; Fri, 1 Jul 2005 13:46:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61KkCE5040657 for ietf-usefor-skb; Fri, 1 Jul 2005 13:46:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkBtI040611 for <[e-mail]>; Fri, 1 Jul 2005 13:46:11 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-126.midband.mdip.bt.net ([81.144.65.126]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c5ab92.b4b4.146 for [e-mail]; Fri,  1 Jul 2005 21:46:10 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j61KavJ22326 for [e-mail]; Fri, 1 Jul 2005 21:36:57 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21838
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1029: USEFOR 3.2.2 References: Should comments be a MUST NOT? (fwd)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 1 Jul 2005 19:12:21 GMT
Lines: 27
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Forrest J. Cavalier III" <[e-mail]> writes:

>5. Agents MAY remove comments from References.

Aaarrrrrrrrggggggggghhhhhhhhh! No!

It is a fundamental principle of everything we have done that agents do
NOT change articles in transit. Usenet is a distributed database, and we
want a given article to the the same (modulo variant headers) wherever it
it stored.

There is a limited provision for injecting agents to "mend" things that
are incomplete (and we spent a lot of time a few years back reaching a
consensus on exactly how "limited" that was to be).

I don't really think this one is a good candidate even for that, though.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkBeP040635 for <[e-mail]>; Fri, 1 Jul 2005 13:46:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61KkBDD040634 for ietf-usefor-skb; Fri, 1 Jul 2005 13:46:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkADk040597 for <[e-mail]>; Fri, 1 Jul 2005 13:46:10 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-126.midband.mdip.bt.net ([81.144.65.126]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c5ab91.b4b4.145 for [e-mail]; Fri,  1 Jul 2005 21:46:09 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j61KauH22322 for [e-mail]; Fri, 1 Jul 2005 21:36:56 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21837
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 1 Jul 2005 18:46:24 GMT
Lines: 26
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Forrest J. Cavalier III" <[e-mail]> writes:

>I'm mostly with Bruce.  I object to specific text mentioning allowing GMT to be
>treated as -0000, because in fact RFC2822 says to treat it as +0000 already.
>Why clutter the draft by repeating what RFC2822 says?

Hold on! I didn't see any text allowing GMT to be treated as -0000.

I did see text allowing ABC to be treated as -0000, and even for EST to be
treated as -0000 if you had not availed yourself of the "MAY accept"
applicable to the rest of <obs-zone>.

>I object to any phrasing "unknown timezone."  It's ambiguous.

"unrecognized timezone" would be better.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61KkA2I040600 for <[e-mail]>; Fri, 1 Jul 2005 13:46:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61KkAVn040599 for ietf-usefor-skb; Fri, 1 Jul 2005 13:46:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61Kk9Kl040582 for <[e-mail]>; Fri, 1 Jul 2005 13:46:09 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-65-126.midband.mdip.bt.net ([81.144.65.126]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.186) id 42c5ab90.b4b4.143 for [e-mail]; Fri,  1 Jul 2005 21:46:08 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j61Kb2r22344 for [e-mail]; Fri, 1 Jul 2005 21:37:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:21841
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1021 USEFOR Newsgroups header - resolution proposed
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Fri, 1 Jul 2005 20:06:08 GMT
Lines: 32
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Charles Lindsey" <[e-mail]> writes:

>In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:


>> Groups starting with the component "to"
>> Groups containing the component "all"
>> Groups containing the component "ctl"

>  Groups starting with the component "control"

>> The group "control"

>But you can omit that, because it is already excluded because its first
>(& only) component is excluded.

Thinking further about this, you could also word those cases as:

   Groups starting with (or consisting of) the component "to"

just for the removal of all doubt.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61GE1wM064373 for <[e-mail]>; Fri, 1 Jul 2005 09:14:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61GE119064372 for ietf-usefor-skb; Fri, 1 Jul 2005 09:14:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61GE0WA064353 for <[e-mail]>; Fri, 1 Jul 2005 09:14:01 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 431D161B03 for <[e-mail]>; Fri,  1 Jul 2005 18:14:00 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24237-04 for <[e-mail]>; Fri,  1 Jul 2005 18:13:59 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D94861AFD for <[e-mail]>; Fri,  1 Jul 2005 18:13:59 +0200 (CEST)
Date: Fri, 01 Jul 2005 18:13:57 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1021 USEFOR Newsgroups header - not quite resolved
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

There have been a number of suggestions for format changes, but most people 
seem to be mostly happy with the text (Charles excepted).
I think the language on _ / + / - needs another pass when we know what to 
do about "agents" - USEFOR should either have all of them defined or not 
mention them at all, and the term "generate" has proved tricky.

But let's insert this text into -05, and put in a marker for the issue.

The current text of the list of groups:

The following newsgroup names have been used for specific purposes in
various implementations and protocols, and MUST therefore not be used
for the names of normal newsgroups. They MAY be used for their
specific
purpose, or by local agreement.

 Groups starting with the component "to"
 Groups starting with the component "control"
 Groups containing the component "all"
 Groups containing the component "ctl"
 The group "junk"

 This includes the groups "to", "control", "ctl" and "all".






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61G980w058708 for <[e-mail]>; Fri, 1 Jul 2005 09:09:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61G98Bb058671 for ietf-usefor-skb; Fri, 1 Jul 2005 09:09:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lentil.epix.net (lentil.epix.net [199.224.64.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61G94Fn058495 for <[e-mail]>; Fri, 1 Jul 2005 09:09:06 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-212-116-pppoe.dsl.hrbg.epix.net [216.37.212.116]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j61G8lMB017150 for <[e-mail]>; Fri, 1 Jul 2005 12:08:54 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 01 Jul 2005 12:08:49 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: #1003 Message-ID text: Resolving
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.153
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> Two significant issues seem to have been raised with the proposed 
> resolution:
> 
> - What needs to be said in order to "play nice" with the $altz "control." 
> convention (for instance, not to outlaw it)
> - Whether, and if so where, the requirement not to go mess with other 
> people's namespace needs to be documented

If 1003 is makred resolved, what ticket(s) list the above two items?





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61G1iEm051127 for <[e-mail]>; Fri, 1 Jul 2005 09:01:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61G1iYF051126 for ietf-usefor-skb; Fri, 1 Jul 2005 09:01:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61G1h79051105 for <[e-mail]>; Fri, 1 Jul 2005 09:01:43 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D2C9761B03 for <[e-mail]>; Fri,  1 Jul 2005 18:01:42 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23959-09 for <[e-mail]>; Fri,  1 Jul 2005 18:01:41 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 424E261AFD for <[e-mail]>; Fri,  1 Jul 2005 18:01:39 +0200 (CEST)
Date: Fri, 01 Jul 2005 18:01:39 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Will have to stop there....
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I won't get to reviewing #1023-#1051 before I leave.

The editor and my co-chair will have to use their best judgment on these.

                   Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61G0tID050437 for <[e-mail]>; Fri, 1 Jul 2005 09:00:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61G0tik050436 for ietf-usefor-skb; Fri, 1 Jul 2005 09:00:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61G0r3v050424 for <[e-mail]>; Fri, 1 Jul 2005 09:00:54 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21F8061B03 for <[e-mail]>; Fri,  1 Jul 2005 18:00:53 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23959-08 for <[e-mail]>; Fri,  1 Jul 2005 18:00:51 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AF5C61AFD for <[e-mail]>; Fri,  1 Jul 2005 18:00:51 +0200 (CEST)
Date: Fri, 01 Jul 2005 18:00:49 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1022 USEFOR 2.1 obs-phrase: Resolution
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Debate showed that messing with the first paragraph is not easy.
This is moved to #1053, which addresses the specific issue.
However, the resolution of the obs-phrase issue seems clear.

I have placed this as "text accepted".

Resolution:

OLD:

 News articles MUST conform to the syntax specified in Section 3 of
 [RFC2822]. Netnews agents MAY also accept the obsolete syntax
 specified in Section 4 of [RFC2822], but they MUST NOT generate
 productions of such syntax.

NEW:

 News articles MUST conform to the syntax specified in Section 3 of
 [RFC2822]. Netnews agents MAY also accept the obsolete syntax
 specified in Section 4 of [RFC2822], but they MUST NOT generate
 productions of such syntax.

 Agents MUST accept the obs-phrase construct (use of a phrase like
 "John Q. Public" without the use of quotes, see [RFC2822]
 section 4.1) but they MUST NOT generate productions of such syntax.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61FXgsx022123 for <[e-mail]>; Fri, 1 Jul 2005 08:33:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61FXgGH022122 for ietf-usefor-skb; Fri, 1 Jul 2005 08:33:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61FXf8x022102 for <[e-mail]>; Fri, 1 Jul 2005 08:33:42 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EB8661B03 for <[e-mail]>; Fri,  1 Jul 2005 17:33:40 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23662-03 for <[e-mail]>; Fri,  1 Jul 2005 17:33:38 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id D1DF461AFD for <[e-mail]>; Fri,  1 Jul 2005 17:33:37 +0200 (CEST)
Date: Fri, 01 Jul 2005 17:33:35 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1003 Message-ID text: Resolving
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Two significant issues seem to have been raised with the proposed 
resolution:

- What needs to be said in order to "play nice" with the $altz "control." 
convention (for instance, not to outlaw it)
- Whether, and if so where, the requirement not to go mess with other 
people's namespace needs to be documented

However, the text seems to have support as "better than what we have now".

So I'm declaring consensus and moving this to "Text accepted", for the 
following text (the change is deleting the last paragraph, which might 
interfere with the $altz convention):

OLD (start of section):

 The Message-ID header contains a single unique message identifier.
 This document updates the <msg-id> construct from Section 3.6.4 of
 [RFC2822] so as to ensure that Internet Message Format Message-IDs
 are usable in widely deployed news software. The global uniqueness
 requirement for <msg-id> in [RFC2822] is to be understood as
applying
 across all protocols using such message identifiers, and across
both
 Email and Netnews in particular. A revised syntax for <msg-id> is
 given below, but the requirements and descriptive text from Section
 3.6.4 of [RFC2822] still apply.

 NEW:

 The Message-ID header contains a single unique message identifier.
 News is more dependent on msg-id uniqueness and fast comparision
than
 email is, and some news software would have trouble with the full
range
 of possible msg-ids permitted by RFC 2822; this section therefore
 restricts the syntax of <msg-id> compared to Section 3.6.4 of
 [RFC2822].
 The global uniqueness
 requirement for <msg-id> in [RFC2822] is to be understood as
applying
 across all protocols using such message identifiers, and across
both
 Email and Netnews in particular.

 OLD (ABNF):

 no-fold-quote = DQUOTE
 ( "." mqtext /
 *mqtext "." /
 *mqtext mqspecial *mqtext )
 DQUOTE

 NEW:

 no-fold-quote = DQUOTE
 ( "." *mqtext /
 *mqtext "." /
 *mqtext mqspecial *mqtext )
 DQUOTE


 OLD (end of section):

 NOTE: It is RECOMMENDED in [RFC2822] that, for ensuring global
 uniqueness, the <id-right> be some domain identifier within
 whose
 scope the uniqueness of the <id-left> can be guaranteed. When
 following this recommendation, any <dot-atom-text> or <no-fold-
 literal> used for the <id-right> are to be interpreted as
 <domain>s as described in Section 3.4.1 of [RFC2822].

 NEW:

 Some software will try to match the <id-right> of a msg-id in
 a case-insensitive fashion; some will match it in a case sensitive
 fashion. Implementations MUST NOT generate two message-IDs where
 the only difference is the case of characters in the <id-right> part.

 If domain literals are used, the syntax found in [RFC2821] section
 4.1.3 is RECOMMENDED.

 NOTE: [RFC2822] section 3.6.4 recommends that the <id-right>
 should be a domain name or a domain literal. Domain literals are
 troublesome since many IP addresses are not globally unique;
 domain names are
 more likely to generate unique message-IDs.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61F8iqI095950 for <[e-mail]>; Fri, 1 Jul 2005 08:08:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61F8iWe095949 for ietf-usefor-skb; Fri, 1 Jul 2005 08:08:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.townisp.com (ns4a.townisp.com [216.195.0.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61F8hCN095935 for <[e-mail]>; Fri, 1 Jul 2005 08:08:44 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns4.townisp.com (Postfix) with ESMTP id A25CD29939; Fri,  1 Jul 2005 11:08:42 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j61F8f3e027043(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 1 Jul 2005 11:08:41 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j61F8cW6027042(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 1 Jul 2005 11:08:39 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Date: Fri, 1 Jul 2005 11:08:32 -0400
User-Agent: KMail/1.8.1
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri July 1 2005 07:38, Harald Tveit Alvestrand wrote:

> > The WG discussion has been focused on comparisons of date-time in
> > Injection-Date, whereas blanket statements about zone abbreviations
> > affect legacy Date and Expires fields as well as any RFC 2822 and
> > extension fields which may arrive via gateways.
> 
> I fail to see the support for this assertion....
> Last 2 months' postings:
> 
> injection-date: mentioned in 14 messages
> zone: mentioned in 93 messages
> 
> If this period is anything to go by, the discussion has been about date in 
> general, not injection-date.

Harald, the discussion has been about comparisons for the purpose of
rejecting "stale" articles, which is the purpose served by the
Injection-Date field, whether or not it is mentioned by name in
the discussions.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61F0lqV088563 for <[e-mail]>; Fri, 1 Jul 2005 08:00:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61F0lp6088562 for ietf-usefor-skb; Fri, 1 Jul 2005 08:00:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61F0i83088450 for <[e-mail]>; Fri, 1 Jul 2005 08:00:45 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 851EF61B03; Fri,  1 Jul 2005 17:00:40 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23136-07; Fri,  1 Jul 2005 17:00:35 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A42061AFD; Fri,  1 Jul 2005 17:00:34 +0200 (CEST)
Date: Fri, 01 Jul 2005 17:00:33 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1021 USEFOR Newsgroups header - resolution proposed
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On torsdag, juni 30, 2005 18:26:15 +0000 Charles Lindsey 
<[e-mail]> wrote:

>
> In <[e-mail]> Harald Tveit
> Alvestrand <[e-mail]> writes:
>
>> OK, here's my "proposed text" again, incorporating feedback.
>
>> ---- restricting syntax; there are no changes to the ABNF -----
>
>> 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
>                                        ^
>                           created prior to this standard

Absolutely not. Sanity is not going to rule the world after this document 
comes out.

>> 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 insensiteve
>>    matching of newsgroup names.
>
>> ----- restricting use of specific characters ------------
>
>> Components beginning with underline ("_") are reserved for use by
>> future versions of this standard and MUST NOT be generated by
>> posting agents (whether in Newsgroups headers or in newgroup control
>> messages [USEPRO]). However, such names MUST be accepted by
>> relaying and serving agents.
>
> s/by posting agents//
>
> (I.e. MUST NOT be generated; period. And also removes any argument about
> what injecting agents do if they see one).
>
> s/by relaying and serving agents/all agents/

Makes no sense to me whatsoever. This may, however, be because the terms 
"generated" and "accepted" are not defined.

"accept" should be straightforward - if I send you a message, and you act 
on it according to normal procedures, you have accepted it.

"generate" may either mean "send" or mean "construct from component 
pieces". The text I proposed used it as "send", and put the onus on 
injecting agents for policing that they don't appear before there's a 
standadr for them.

> (Not so sure there, since it apparently restricts the right of injecting
> agents to reject them. OTOH, all mentions, esp. normative ones, of the
> various different kinds of agent are probaly best removed from USEFOR).

I would be happier if we had "user agent" and "server" as the only terms in 
the USEFOR description of the Netnews architecture, and put all the various 
agents into USEPRO. But if USEFOR is going to have *any* context to its 
description, I think it needs to have at least *some* terms defined.

> Also s/(Whether ...)//, since it does not actually add anything.
>
>> Components beginning with "+" and "-" are reserved for private
>> use and MUST NOT be generated by posting agents (whether in
>> Newsgroups headers or in newgroup control
>> messages [USEPRO]) without a private prior agreement to do so.
>> However, such names MUST be accepted by
>> relaying and serving agents.
>
> Same suggestions as above, for the same reasons. So I would suggest:
>
>    MUST NOT be generated without a private prior agreement with the
>    intended recipients (such as between a news-server and its clients).

Same comment about defining "generate".

>> ---- restricting component names ----
>
>> The following newsgroup names are reserved, and MUST NOT be used as
>> the name of a newsgroup:
>
>> Groups starting with the component "example"
>> The group "poster"
>
>> The following newsgroup names have been used for specific purposes in
>> various implementations and protocols, and MUST therefore not be used
>> for the names of normal newsgroups. They MAY be used for their specific
>> purpose, or by local agreement.
>
>> Groups starting with the component "junk"
>
> No, I think you can omit that one ("junk.foo is bizarre, but not harmful)
>
>> Groups starting with the component "to"
>> Groups containing the component "all"
>> Groups containing the component "ctl"
>
>   Groups starting with the component "control"
>
>> The group "control"
>
> But you can omit that, because it is already excluded because its first
> (& only) component is excluded.
>
>> The group "junk"
>> The group "to"
>
> And you can omit that, because it is already excluded as above.

Anything worth doing is worth overdoing :)
seriously, there have been people who have argued that a phrase like "A 
contains B" implies that there are more things in A than just B...

> OTOH, I am not sure your classification into two categories is the right
> one. Surely the distinction should be between the things which will cause
> things to break (poster, to, all, ctl) and the things which flout accepted
> conventions (example, junk, control, and even single-component names,
> though it now seems agreed not to mention these here).

"example" is strictly a standards-definer's privillege junket.
"junk" and "control" will (I think) cause things to break.

> Anyway, it is still necessary to give _reasons_ for all these exclusions,
> probably in a NOTE, because that is how you handled the reasons for
> all-digit groups, etc. Here are some texts that might be useful:
>
> ctl:
> because it formerly caused such articles to be interpreted as control
> messages
>
> all:
> because it is used as a wildcard in some implementations
>
> to:
> because of its special meaning to route certain control messages on a
> point-to-point basis [USEPRO]
>
> poster:
> because of its special meaning in the Followup-To header
>
> control:
> used by many serving agents for pseudo-newgroups to hold control
> messages
>
> junk:
> used by many serving agents to store invalid articles
>
> example:
> reserved for examples in this and other standards
>
>> NOTE: Some newsgroups violating these restrictions exist. It is not a
>> protocol violation to use these names to access those newsgroups.
>
>
> --
> Charles H. Lindsey ---------At Home, doing my own
> thing------------------------ Tel: [phone] Fax: [phone]
> Web: http://www.cs.man.ac.uk/~chl Email: [e-mail]      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
>
>






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61ESqiJ054927 for <[e-mail]>; Fri, 1 Jul 2005 07:28:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61ESq4U054926 for ietf-usefor-skb; Fri, 1 Jul 2005 07:28:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61ESpo3054911 for <[e-mail]>; Fri, 1 Jul 2005 07:28:52 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 53DDB61B03 for <[e-mail]>; Fri,  1 Jul 2005 16:28:50 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22817-07 for <[e-mail]>; Fri,  1 Jul 2005 16:28:48 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7889C61AFD for <[e-mail]>; Fri,  1 Jul 2005 16:28:47 +0200 (CEST)
Date: Fri, 01 Jul 2005 16:28:47 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Re: #1053 USEFOR 2.1 Relationship to RFC 2822 (NEW: blanket statements vs. the law of unintended consequences, also Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On fredag, juli 01, 2005 08:41:14 -0400 Bruce Lilly <[e-mail]> 
wrote:

> No, I said:
>   I propose eliminating the blanket
>   statement in section 2.1 (i.e. the second sentence of the first
> paragraph),   with the understanding that that does not preclude adding
> limited-scope   relaxation of specific parts of 2822 obs-syntax parsing
> requirements   where appropriate and where justifiable.
>
> What you quoted was background information, not a proposal.  The hint
> is the words, "I propose", which was perhaps too subtle; I apologize
> for any confusion such subtlety might have caused.

I copied your whole message into the ticket. I was commenting on your 
"background information", which, to me, seems to state the issue you want 
solved rather than how to solve it, which is why I chose to quote that.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61DfIUq095027 for <[e-mail]>; Fri, 1 Jul 2005 06:41:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61DfIqw095026 for ietf-usefor-skb; Fri, 1 Jul 2005 06:41:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.epix.net (pine.epix.net [199.224.64.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61DfH3t094994 for <[e-mail]>; Fri, 1 Jul 2005 06:41:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-212-116-pppoe.dsl.hrbg.epix.net [216.37.212.116]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j61Df8gt009915 for <[e-mail]>; Fri, 1 Jul 2005 09:41:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 01 Jul 2005 09:41:11 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Style of documentation (Re: #1043 "header": Suggested resolution)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 199.224.89.152
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand wrote:

> Forrest,
> 
> somewhat flippantly, I'll assign half a point to Charles and half a point 
> to you.

I didn't think we were competing.  If you think that you need to assign
Charles a half point to keep him happy, we have a big problem.

There is no "agreeing to differ" on the makeup of our audience.  It is
a matter of decision, not opinion, and all WG participants must agree
to cooperate to write for that audience.
I agree with reuse and multi-purposing and even "suface reading", but
not for standards work.  Standards have no need to be written for
careless people.

If Joe Usenet User wants to read a specification written for implementors,
WE HAVE NO CONCERN FOR HIM.  Let someone else paraphrase and write
"USEFOR for dummies."

People who do "surface reading" are not implementors who can claim
conformance.  I thought it was self-evident.

Look, this isn't an excuse to be less clear and less verbose, it is
the only way to be more concise and more clear.  It is the only way
to finish, and avoid the "paraphrased meaning mismatch" problems
recently discussed.

Maybe some concrete examples are in order.

1. USEFOR-USEFOR 3.2.1 has this text, which is unnecessary if you
assume implementors can read, or necessary if you assume they
are lazy.  Which is it?
    See the remarks under Section 3.1.2  regarding the syntax of date-
    time and the requirements and recommendations to which it is subject.

2. See also 3.2.4 (Expires)

3. USEFOR-USEFOR 3.1.6 has this text,
     The Path header indicates the route taken by an article since its
     injection into the Netnews system.

That's fine and enough for USEFOR, but we seem to be writing for
people who do not understand a simple statement, so we beat them
over the head with more.....
                                        Each agent that processes an
    article is required to prepend one (or more) identities to this
    header.  This is primarily to enable relaying agents to avoid sending
    articles to sites already known to have them, in particular the site
    they came from, and additionally to permit tracing the route articles
    take in moving over the network, and for gathering Usenet statistics.

All of that will just repeat some text from USEPRO or USEAGE, and
we have to assume implementors can read those documents.

But there is more! later on it is RESTATED AGAIN!
    Each <path-identity> in the <path-list> (excluding the one in the
    <tail-entry>) indicates, from right to left, the successive agents
    through which the article has passed.

And not content with deferring construction to USEPRO, we get yet another
reference to USEPRO
    The full procedure for constructing a Path header
    as well as the specific format and use of <path-identity> and <tail-
    entry> are discussed in [USEPRO].

4. We have a lot of ABNF repeats of RFC2822.  Why?  E.g. in 3.1.1 we
    have

      from            =  "From:" SP mailbox-list CRLF

    My point is that who can understand that without reading RFC2822 for
    "mailbox-list"?  And if implementors have to read RFC2822, then they
    have to read RFC2822 which has the ABNF already.

    Sure, you may argue that a "surface reader" wants the ABNF in USEFOR,
    but there is a cost.

    The problem of "subtle differences" in ABNF terms
    has already been raised.  If we state ABNF in USEFOR-USEFOR, then careful
    implementors will be forced to COMPARE the ABNF in USEFOR-USEFOR with
    what is in RFC2822, instead of saying "OK, my RFC2822 code for From will
    be fine."

    Not only that, but sometimes we are the same, and sometimes not.  (E.g.
    Message-ID....I also think there is a big problem in redoing all the
    Message-ID ABNF instead of restricting the ABNF that is in 2822 already.)


USEPRO is way worse, but not a subject we are allowed to discuss yet.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61CfUYn020499 for <[e-mail]>; Fri, 1 Jul 2005 05:41:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61CfUNB020498 for ietf-usefor-skb; Fri, 1 Jul 2005 05:41:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61CfTrq020461 for <[e-mail]>; Fri, 1 Jul 2005 05:41:30 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 2017529971; Fri,  1 Jul 2005 08:41:29 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j61CfQLp026364(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 1 Jul 2005 08:41:27 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j61CfOEV026363(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 1 Jul 2005 08:41:25 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1053 USEFOR 2.1 Relationship to RFC 2822 (NEW: blanket statements vs. the law of unintended consequences, also Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Date: Fri, 1 Jul 2005 08:41:14 -0400
User-Agent: KMail/1.8.1
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri July 1 2005 07:27, Harald Tveit Alvestrand wrote:
> 
> Bruce,
> 
> as I've said about your previous attempts to raise general issues (#1030, 
> #1031), a statement of an issue that is so unclear that it's impossible to 
> tell whether or not we agree on its meaning is not good for forward 
> progress.
> 
> I'm assigning this as ticket #1053 with title "Relationship to RFC 2822", 
> in the belief that the actionable part of your message is that you want it 
> made clear:
> 
> > While the 2.1 text says "MAY" it doesn't specifically say that it
> > overrides 2822, so it's not 100% clear.  It's unclear what the order
> > of precedence is in interpreting 2822 vs. 2.1 vs. the presumably
> > agreed-upon obs-phrase text, etc.

No, I said:
  I propose eliminating the blanket
  statement in section 2.1 (i.e. the second sentence of the first paragraph),
  with the understanding that that does not preclude adding limited-scope
  relaxation of specific parts of 2822 obs-syntax parsing requirements
  where appropriate and where justifiable.

What you quoted was background information, not a proposal.  The hint
is the words, "I propose", which was perhaps too subtle; I apologize
for any confusion such subtlety might have caused.

Harald, as I've said before, if you believe something is unclear, just
ask a question, on-list or off-list, and I'll do my best to clarify.

More background explanation:
The text and proposed text for the 2.1 MUST means MAY except when is means
MUST is far too convoluted and (IMO) hasn't been thought through carefully.
As a result, there are all sorts of unexpected problems that will cause
trouble for unsuspecting implementers, e.g. the phrases in obs-references
in existing messages.  To recap that for those who haven't been following:
o it has been conjectured that a comment in a References field, e.g.
    References: <[e-mail]> (EDT) <[e-mail]>
  would spell doom for the Internet by causing interoperability problems
  because some hypothetical UA wouldn't be able to figure out what to do
  with the comment "(EDT)".  That in turn, if true, would warrant MUST NOT
  language regarding comments.
o Apparently however, by some mysterious mechanism yet to be explained,
  only comments in *new* messages would cause trouble; those in existing
  messages would apparently somehow be benign.
o because MUST means MAY except when it means MUST, UAs would not be required
  to be able to correctly parse obs-references, which permits a phrase,
  even though that was part of RFC 822 syntax and remains required for
  parsing the Internet Message Format (RFC 2822)
o there exist messages such as
  http://article.gmane.org/gmane.ietf.usenet.format/9644/raw
  (that example contains:
  References: Seth Breidbart's message of "Thu, 11 Jun 1998 22:20:30 -0400  (EDT)" <[e-mail]> <l03110701b1a6dd2075a3@[206.222.209.12]>
  ).  Although somehow (it's not clear *exactly* how) the presence of
  an "(EDT)" comment free-standing is supposed to wreak havoc, it seems
  to be conjectured that somehow a phrase containing exactly the same
  characters (as well as others) will be completely benign.  That
  stretches credulity beyond the breaking point.

It is my considered opinion that no amount of convolution is going to
be able to deal with all of the complexities and still remain comprehensible
to readers of the specification and its normative references.  I also
believe that we haven't the time to go through all of RFC 2822 and all
of USEFOR and USEPRO (which are incomplete) to find all places where a
blanket statement would lead to problems (and would therefore require
more convolution to make an exception to the exception to the exception).
It is my further opinion that the most practical way to deal with the
situation is to start from the position that our primary normative
reference, viz. RFC 2822, applies in full, and that we make specific,
limited-scope exceptions such as may be necessary, after due deliberation
to ensure that the exception is not harmful.  And so I have proposed.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61CHh7m091696 for <[e-mail]>; Fri, 1 Jul 2005 05:17:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61CHgb4091669 for ietf-usefor-skb; Fri, 1 Jul 2005 05:17:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61CHfMX091600 for <[e-mail]>; Fri, 1 Jul 2005 05:17:41 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B3E9461B03; Fri,  1 Jul 2005 14:17:40 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21328-05; Fri,  1 Jul 2005 14:17:39 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB7BE61AFD; Fri,  1 Jul 2005 14:17:38 +0200 (CEST)
Date: Fri, 01 Jul 2005 14:17:37 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1003 USEFOR 3.1.3 Message-ID: Proposed text
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On torsdag, juni 30, 2005 16:21:33 +0000 Charles Lindsey 
<[e-mail]> wrote:

> The only genuine not-globally-unique IP addresses are the ones set aside
> for local use (127.0.0.1 is the best-known). Even IP addresses obtained on
> a DHCP lease are uniquely yours so long as you hold them. Hence
> s/many/some/.

I guess you haven't been in that many NAT discussions....

The 10.0.0.1 set-asides are just one example of addresses that are 
simultaneously in use by multiple machines at multiple times.
Other examples are internal networks using addresses assigned to others 
(yes, they exist) and multihomed hosts.

The fact is - a machine has no way of being sure his IPv4 address is 
"uniquely his" or not.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61CChvm086092 for <[e-mail]>; Fri, 1 Jul 2005 05:12:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61CChvX086091 for ietf-usefor-skb; Fri, 1 Jul 2005 05:12:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61CCfmE086045 for <[e-mail]>; Fri, 1 Jul 2005 05:12:42 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D2B661B03 for <[e-mail]>; Fri,  1 Jul 2005 14:12:41 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21328-01 for <[e-mail]>; Fri,  1 Jul 2005 14:12:37 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E7B761AFD for <[e-mail]>; Fri,  1 Jul 2005 14:12:37 +0200 (CEST)
Date: Fri, 01 Jul 2005 14:12:36 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: ADMIN: Plans for the next 2 weeks
Message-ID: <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

As I've mentioned earlier, I'm going on holiday for 2 weeks, starting 
tomorrow (at 6 in the morning).

Our plan was to close as many tickets as possible by today, allowing Ken to 
produce a clean -05 draft reflecting those resolutions, in preparation for 
a WG Last Call on the usefor document.

Given the number of issues that Bruce and others have raised and re-raised, 
this seems somewhat optimistic - but my judgment is that the discussion is 
best served by emitting a new document at this time anyway.

So I'm asking the editor to prepare an usefor-05 draft next week, with the 
resolutions so far in the tracker and edits making sure the text is 
consistent (such as the replacing of most occurences of "header" with 
"header field"). Where tickets are still open, I'm asking him to insert a 
marker in the text like [[Open issue #nnnn]] to show that we know that 
there is an open issue here.

Where the state of the ticket is "Text accepted" or "No change needed", Ken 
will close the ticket when he's sent out the edited draft.

Alexey will reopen closed issues as needed, and open new ones, if 
discussion warrants. Then we'll see where we stand.

                             Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BtwWn067544 for <[e-mail]>; Fri, 1 Jul 2005 04:55:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61Btwtf067543 for ietf-usefor-skb; Fri, 1 Jul 2005 04:55:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BtvFT067515 for <[e-mail]>; Fri, 1 Jul 2005 04:55:58 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18E4661B43; Fri,  1 Jul 2005 13:55:57 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21080-02; Fri,  1 Jul 2005 13:55:55 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id E0C6361AFD; Fri,  1 Jul 2005 13:55:54 +0200 (CEST)
Date: Fri, 01 Jul 2005 13:55:53 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On torsdag, juni 30, 2005 19:47:58 +0000 Charles Lindsey 
<[e-mail]> wrote:

>    path-identity   =  ( ALPHA / DIGIT )
>>                      *( ALPHA / DIGIT / "-" / "." / "_" )
>
>>   path-keyword    = "POSTED" / "MISMATCH"
>
>
>>   path-address    =  IPv4address / no-fold-literal ; see [RFC2373]
>
> A good idea, but the term <path-identity> needs to include everything that
> may occur in the list, except the two keywords, because it is used with
> that meaning in many places.

8 times in usefor, 10 times in usepro....

If a path-address is really diagnostic information, this separation is in 
fact useful, since you do NOT want those diagnostics where a real 
path-identity is desired; I'd argue that the Xref header and the 
Injection-info header should not need to contain a path-address.

USEPRO uses the term in the IHAVE/SENDME messages and in the description of 
handling of the Path header; in both cases, it seems to me useful to draw a 
distinction between diagnostic information and a real server name - indeed, 
the only place where I can see the need to use a path-address is in the 
part about verification of address:

   1. It MUST establish the trusted identity of the source of the
      article and compare it with the leftmost <path-identity> of the
      Path header's content. If it matches it MUST then prepend its own
      <path-identity> and a '/' <path-delimiter> to that content; this
      SHOULD then be followed by CRLF and WSP if it would otherwise
      result in a line longer than 79 characters.  If it does not match
      then it prepends instead two entries to that content; firstly the
      true established <path-identity> of the source followed by a '?'
      <path-delimiter>, and then, to the left of that, its own <path-
      identity> followed by a '/' <path-delimiter> as usual. This
      prepending of two entries SHOULD NOT be done if the provided and
      established identities match.  See a-5.6.4 for the significance of
      the various <path-delimiter>s.

I think you've just strengthened the argument for separating the two....



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BiQk3054061 for <[e-mail]>; Fri, 1 Jul 2005 04:44:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61BiQmx054060 for ietf-usefor-skb; Fri, 1 Jul 2005 04:44:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BiQ6W054049 for <[e-mail]>; Fri, 1 Jul 2005 04:44:26 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 8D916299A5 for <[e-mail]>; Fri,  1 Jul 2005 07:44:25 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j61BiNkG025871(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Fri, 1 Jul 2005 07:44:23 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j61BiL9v025870(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 1 Jul 2005 07:44:21 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Date: Fri, 1 Jul 2005 07:44:12 -0400
User-Agent: KMail/1.8.1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

On Fri July 1 2005 01:28, Henry Spencer wrote:

> Backward compatibility is a technical issue, not a compliance issue.  It
> does not require us to permanently endorse every old mistake, only to
> provide a transition path, so that software can move toward future full
> compliance while remaining interoperable with the old mistakes for now. 

Which is what my proposed text does, as everyone can see 
from my previous postings.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BhWtX053073 for <[e-mail]>; Fri, 1 Jul 2005 04:43:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61BhWa4053071 for ietf-usefor-skb; Fri, 1 Jul 2005 04:43:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BhVra053059 for <[e-mail]>; Fri, 1 Jul 2005 04:43:32 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED14761B03; Fri,  1 Jul 2005 13:43:30 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20866-06; Fri,  1 Jul 2005 13:43:28 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 662D161AFD; Fri,  1 Jul 2005 13:43:26 +0200 (CEST)
Date: Fri, 01 Jul 2005 13:43:26 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: #1047 Path-identity: A proposal (perhaps)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On torsdag, juni 30, 2005 08:26:25 -0700 John Stanley <[e-mail]> 
wrote:

> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> There are only 3 ways I see to get rid of the : character:
>
>> - Stop putting domain-literals in Path: at all (seems unacceptable)
>> - Encode IPv6 addresses differently (seems unacceptable)
>> - Treat IPv6 and IPv4 differently (seems unacceptable)
>
>> If you've eliminated the impossible, what you're left with.....
>
> How did we leap from "seems unacceptable" to "impossible"?

sorry, I was quoting Sherlock Holmes without using quotation marks.... the 
full sentence is "when you have excluded the impossible, whatever remains, 
however improbable, must be the truth" - see 
<http://en.wikiquote.org/wiki/Sherlock_Holmes> for references.

> Let's see. We're stuck with legacy apps that are unlikely to change their
> method of parsing a Path header overnight, all based on a pesky colon. But
> the "standard" means of representing an IPv6 address uses colons. What do
> we do?
>
> Hmmm. How about simply eliminating the colons (and the effects) from the
> IPv6 address literal? Bingo -- a 16 character "path-identity" without
> any punctuation. No need for the :: shorthand, people aren't typing it in
> over and over again.

That's option 2 above, one particular variant. Any callers?
(It was tried when discussing IPv6 literals in URIs. Lost there.)





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BcH7K047419 for <[e-mail]>; Fri, 1 Jul 2005 04:38:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61BcHCd047417 for ietf-usefor-skb; Fri, 1 Jul 2005 04:38:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BcGfV047398 for <[e-mail]>; Fri, 1 Jul 2005 04:38:17 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4140061B03 for <[e-mail]>; Fri,  1 Jul 2005 13:38:16 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20739-08 for <[e-mail]>; Fri,  1 Jul 2005 13:38:14 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9C0961AFD for <[e-mail]>; Fri,  1 Jul 2005 13:38:12 +0200 (CEST)
Date: Fri, 01 Jul 2005 13:38:12 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On torsdag, juni 30, 2005 11:59:18 -0400 Bruce Lilly <[e-mail]> 
wrote:

>> My reading of the text and the discussion is that the group wishes to
>> allow  a parser to NOT recognize "EST" as anything more valid than "ABC".
>> (Otherwise, the whole fuss about requiring handling of "GMT" would be
>> completely meaningless.)
>
> The WG discussion has been focused on comparisons of date-time in
> Injection-Date, whereas blanket statements about zone abbreviations
> affect legacy Date and Expires fields as well as any RFC 2822 and
> extension fields which may arrive via gateways.

I fail to see the support for this assertion....
Last 2 months' postings:

injection-date: mentioned in 14 messages
zone: mentioned in 93 messages

If this period is anything to go by, the discussion has been about date in 
general, not injection-date.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BRtIv035501 for <[e-mail]>; Fri, 1 Jul 2005 04:27:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61BRtxg035500 for ietf-usefor-skb; Fri, 1 Jul 2005 04:27:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BRstV035480 for <[e-mail]>; Fri, 1 Jul 2005 04:27:54 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E26861B03 for <[e-mail]>; Fri,  1 Jul 2005 13:27:53 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20739-03 for <[e-mail]>; Fri,  1 Jul 2005 13:27:49 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8537461AFD for <[e-mail]>; Fri,  1 Jul 2005 13:27:49 +0200 (CEST)
Date: Fri, 01 Jul 2005 13:27:48 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1053 USEFOR 2.1 Relationship to RFC 2822 (NEW: blanket statements vs. the law of unintended consequences, also Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce,

as I've said about your previous attempts to raise general issues (#1030, 
#1031), a statement of an issue that is so unclear that it's impossible to 
tell whether or not we agree on its meaning is not good for forward 
progress.

I'm assigning this as ticket #1053 with title "Relationship to RFC 2822", 
in the belief that the actionable part of your message is that you want it 
made clear:

> While the 2.1 text says "MAY" it doesn't specifically say that it
> overrides 2822, so it's not 100% clear.  It's unclear what the order
> of precedence is in interpreting 2822 vs. 2.1 vs. the presumably
> agreed-upon obs-phrase text, etc.

I have no idea how to turn the following into actionable text:

> So MUST means MAY except where (e.g. obs-phrase) MAY means MUST. Unless
> of course MUST means MAY again.

So I'm going to ignore it.

                    Harald



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BKs55027863 for <[e-mail]>; Fri, 1 Jul 2005 04:20:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61BKsSP027862 for ietf-usefor-skb; Fri, 1 Jul 2005 04:20:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BKr7P027850 for <[e-mail]>; Fri, 1 Jul 2005 04:20:53 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA0D061B03; Fri,  1 Jul 2005 13:20:52 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20555-09; Fri,  1 Jul 2005 13:20:51 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id E3F8461AFD; Fri,  1 Jul 2005 13:20:50 +0200 (CEST)
Date: Fri, 01 Jul 2005 13:20:49 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Bruce Lilly <[e-mail]>, [e-mail]
Subject: Re: Decision procedures
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <119CB22DD798D0073C9ACE7A@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Bruce,

the IETF works by giving considerable latitude to the working group chairs 
- exactly because of the difficulty of giving exact rules for this type.
Still, I'll answer this one.

--On torsdag, juni 30, 2005 12:51:14 -0400 Bruce Lilly <[e-mail]> 
wrote:

> But back to the issue: where do we stand on the matter of the means
> of determining consensus?

> Do unsupported assertions count?

Yes. They count slightly less than assertions that "as everyone can see 
from my previous postings, this is true", and slightly less than "it's 
obvious from the mailing list archives going back 5 years that this is 
true".
They count a good bit less than "this is true for the reasons given in RFC 
xxx section 3.14, paragraph 5", and a good bit less than "this is true 
because of the following logic:"

> Do false statements count?

The statement "pi is equal to 3" will not be counted.
An unsupported statement that another statement is false counts - see above.

>  Is "I'm in favor of x, but I couldn't care
> less" weighed the same as "x will spell doom for the Internet"?

No. But it's of course far more easy to support the first assertion than 
the second (indeed, the fact that the first statement is made is usually 
counted as enough support to consider it true).

                         Harald





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BDmjK020360 for <[e-mail]>; Fri, 1 Jul 2005 04:13:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61BDmZY020359 for ietf-usefor-skb; Fri, 1 Jul 2005 04:13:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61BDlIL020337 for <[e-mail]>; Fri, 1 Jul 2005 04:13:47 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6867E61B03; Fri,  1 Jul 2005 13:13:46 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20555-03; Fri,  1 Jul 2005 13:13:44 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 311FC61AFD; Fri,  1 Jul 2005 13:13:44 +0200 (CEST)
Date: Fri, 01 Jul 2005 13:13:43 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: "Forrest J. Cavalier III" <[e-mail]>
Cc: [e-mail]
Subject: Style of documentation (Re: #1043 "header": Suggested resolution)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Forrest,

somewhat flippantly, I'll assign half a point to Charles and half a point 
to you.

Most of the readers of the document will not bother to read all the 
supporting documentation in detail.
But - most of those readers are NOT implementors They seek a general 
understanding, or want to clarify a particular point, they don't need to 
understand all of it fully. And even more - most of the time, those readers 
who ARE implementors can be well served by the "surface meaning" of the 
words, and they will have little reason to dig into the references 
(normative or not).

Only in SOME cases will people have reason to dig into the documents to 
clarify *exactly* what is meant by some point or prohibition.
And it's our job as standards writers to make sure that in *those* cases, 
the path back is clear.

                    Harald

--On torsdag, juni 30, 2005 17:58:48 -0400 "Forrest J. Cavalier III" 
<[e-mail]> wrote:

> Charles Lindsey wrote:
>
>> In <[e-mail]> "Forrest J. Cavalier III"
>> <[e-mail]> writes:
>>
>>
>>> Charles Lindsey wrote:
>>>
>>>> I pointed out that in the real world implementors and other readers DO
>>>> take shortcute when reading documents. That is a fact of life. You
>>>> have to live with it.
>>
>>
>>> No I do not have to live with it.  As has been said so many times: we
>>> need a clear, complete, unambiguous specification that is as easy to
>>> read as possible, BUT WE HAVE NO CONCERN for people who refuse to read
>>> and understand NORMATIVE references.  We can totally ignore such people
>>> when writing, because they are irrelevant.
>>
>>
>> To describe a substantial part of your audience as "irrelevant" is no way
>> to write any document, whether technical or otherwise.
>>
>> If that is your attitude, then we will just have to agree to differ.
>>
> No, we don't have to agree to differ on this either.
>
> I request the chairs issue a clear statement that we will use RFC2119
> imperatives and when used we expect ALL implementors to understand them as
> defined in RFC2119.  We will also expect them to understand English.
>
> I request the chairs issue a clear statement that we expect all
> implementors
> claiming conformance are expected to read and understand NORMATIVE
> references.
> (I thought we already had that declaration of the obvious, but guess
> not...)
>
> I request the chairs issue a clear statement that we will repeat and
> highlight
> text from NORMATIVE references only when we have reason to believe that
> our
> draft text is so difficult to write clearly that it is likely to mislead
> an implementor into violating a normative reference.
>
>






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61B3j1X011649 for <[e-mail]>; Fri, 1 Jul 2005 04:03:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j61B3jRt011648 for ietf-usefor-skb; Fri, 1 Jul 2005 04:03:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j61B3h6p011609 for <[e-mail]>; Fri, 1 Jul 2005 04:03:44 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CECC661B03; Fri,  1 Jul 2005 13:03:41 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20362-04; Fri,  1 Jul 2005 13:03:39 +0200 (CEST)
Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id D8F6D61AFD; Fri,  1 Jul 2005 13:03:38 +0200 (CEST)
Date: Fri, 01 Jul 2005 13:03:38 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1021 Single component newsgroups (Re: Definition of "private" (Re: #1021: USEFOR 3.1.5 Newsgroups - suggested texts)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <A3144E13755E7D3CACB6EA26@B50854F0A9192E8EC6CDA126>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]>  <78BBACC38DC374725A4EDD07@B50854F0A9192E8EC6CDA126>  <[e-mail]> <[e-mail]>  <[e-mail]>  <[e-mail]> <AEF08FC6BEDD4E5AABF1F47A@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On torsdag, juni 30, 2005 20:29:24 +0000 Charles Lindsey 
<[e-mail]> wrote:

>> I think that's the consensus of the group at the moment:
>
>> It's not sensible for the article *format* standard to say anything
>> about  single component newsgroup names. They should be permitted in
>> syntax.
>
>> We'll return to the topic with USEAGE (if we get that far).
>
> OK, I could take the single-component newsgroup-names to USEAGE, but it
> seems that the intent of Harald's latest proposal is to leave the rest of
> these "funny" newsgroup-names (control.*, junk.*, to.*,
> all-digit-components, etc.) in USEFOR.  Is that understanding correct?

That is correct. People have argued (with arguments that seem to me 
reasonable) that trying to use these as normal newsgroup names will in fact 
cause technical problems for at least part of the existing USENET; this is 
not the case for the single-component newsgroup name.

                 Harald