Re: #1047 Path field delimiters and syntax - status

[Harald Tveit Alvestrand <[e-mail]>]

--On mandag, august 22, 2005 11:58:32 +0000 Charles Lindsey 
<[e-mail]> wrote:

>> Saying that giving a name to your system is REQUIRED by the standards is
>> a  Good Thing, and allows us to positively refuse to allow such idiocies
>> as  using an IP address to identify your server in injection-info.
>
> Why is it an "idiocy"? We are talking about globally routable IP addresses
> which are allocated according to a very well defined procedure. So, in
> fact, they would actually be safer than "barewords".

RFC 1958 section 4.1:

   4.1 Avoid any design that requires addresses to be hard coded or
   stored on non-volatile storage (except of course where this is an
   essential requirement as in a name server or configuration server).
   In general, user applications should use names rather than addresses.

That's been an Internet architectural principle for 10 years, and we have 
LOTS of experience in what happens when you violate that principle.
I stand by "idiocy".

                        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 j8169j1l094257; Wed, 31 Aug 2005 23:09:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8169j0J094256; Wed, 31 Aug 2005 23:09: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 j8169gYt094249 for <[e-mail]>; Wed, 31 Aug 2005 23:09:43 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EAiFC-0000wX-K5 for [e-mail]; Thu, 01 Sep 2005 08:08:14 +0200
Received: from c-134-88-106.hh.dial.de.ignite.net ([62.134.88.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 01 Sep 2005 08:08:14 +0200
Received: from nobody by c-134-88-106.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 01 Sep 2005 08:08:14 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and syntax - status
Date:  Thu, 01 Sep 2005 08:06:35 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Message-ID:  <[e-mail]>
References:  <[e-mail]>  <[e-mail]> <E0D0148C6A5969AC5BD4BCEA@B50854F0A9192E8EC6CDA126> <[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-88-106.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:

> I stand by "idiocy".

| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

Here's "Tough consensus", not only 10 years, STD 11 was 1982.

The 2822 syntax is (almost) perfect, but its semantics is
sometimes a bit vague.
                            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 j7VAfLWf088075; Wed, 31 Aug 2005 03:41:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VAfLXp088074; Wed, 31 Aug 2005 03:41:21 -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 j7VAfJOG088068 for <[e-mail]>; Wed, 31 Aug 2005 03:41:20 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67E2232008D; Wed, 31 Aug 2005 12:41: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 13878-07; Wed, 31 Aug 2005 12:40:58 +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 2B898320089; Wed, 31 Aug 2005 12:40:58 +0200 (CEST)
Date: Wed, 31 Aug 2005 12:41:15 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <E0D0148C6A5969AC5BD4BCEA@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: by 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 mandag, august 22, 2005 11:58:32 +0000 Charles Lindsey 
<[e-mail]> wrote:

>> Saying that giving a name to your system is REQUIRED by the standards is
>> a  Good Thing, and allows us to positively refuse to allow such idiocies
>> as  using an IP address to identify your server in injection-info.
>
> Why is it an "idiocy"? We are talking about globally routable IP addresses
> which are allocated according to a very well defined procedure. So, in
> fact, they would actually be safer than "barewords".

RFC 1958 section 4.1:

   4.1 Avoid any design that requires addresses to be hard coded or
   stored on non-volatile storage (except of course where this is an
   essential requirement as in a name server or configuration server).
   In general, user applications should use names rather than addresses.

That's been an Internet architectural principle for 10 years, and we have 
LOTS of experience in what happens when you violate that principle.
I stand by "idiocy".

                        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 j7V7QLHv072098; Wed, 31 Aug 2005 00:26:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7V7QLDr072097; Wed, 31 Aug 2005 00:26:21 -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 j7V7QKUE072087 for <[e-mail]>; Wed, 31 Aug 2005 00:26:21 -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 j7V7Plw3010637 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 31 Aug 2005 00:25:50 -0700 (PDT)
Date: Wed, 31 Aug 2005 00:26:11 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

> stop misrepresenting what I said.

Since I didn't quote you or say you said anything I am at a loss as to 
what this admonition refers to.

>When you tried to interpret my ruling on this subject as making the 
>question out of scope for USEAGE too, I said that you were wrong. 
>Repeatedly.

The poll you conducted on this matter said absolutely nothing about it 
being specific to USEPRO. AFTER the poll was over you tried claiming that 
it applied to only USEPRO, but you also said, as I recall, that it applied 
to 'the USEFOR document'. I'm working off your own poll where the 
consensus was clearly for 'no mention'.

Trying to limit the scope of a consensus after the consensus is determined 
(without any stated limits) is, well, I'm ignoring that attempt at 
twisting the result, not 'misinterpreting' what you said. I'm simply 
trying to live with the results of your own poll. 

It is STUPID to rehash this same debate again and again after such a clear 
result. Either Charles can justify a new mandate and the attempt at 
overriding an existing standard or he cannot. That he could not do it for 
USEPRO is clear indication that he cannot do it for USAGE.

If you want to waste the time again, fine. I'm happy to keep asking for a 
justification for this mandate, and I'm sure that Charles is happy to keep 
avoiding giving an answer. He's apparently quite happy trying to insert 
his pet mandates into our drafts hoping that one or more of them will 
stick. I'm not happy with that.

It:s time to stop this nonsense. We, as a group, did something unusual and 
came to a near unanimous consensus. Why do you refuse to accept that and 
think we need more debate on the same thing?

>It is IN scope for us to discuss this related to USEAGE , but USEAGE is 
>not presently on our schedule of things to discuss.

Tell this to Charles, who is posting proposed text for USAGE to initiate 
discussion. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U9tmdk044167; Tue, 30 Aug 2005 02:55:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U9tmET044166; Tue, 30 Aug 2005 02:55: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 j7U9tl3i044159 for <[e-mail]>; Tue, 30 Aug 2005 02:55:48 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D47F1320098; Tue, 30 Aug 2005 11:55: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 06242-01; Tue, 30 Aug 2005 11:55:25 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D2F67320097; Tue, 30 Aug 2005 11:55:24 +0200 (CEST)
Date: Tue, 30 Aug 2005 10:55:14 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: #1093 Email addresses - conclusion
Message-ID: <D3188F645FE1F527BF21A880@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========8DC4D0A156CC593E2EB3=========="
X-Virus-Scanned: by 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>

--==========8DC4D0A156CC593E2EB3==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

John,

stop misrepresenting what I said.

When you tried to interpret my ruling on this subject as making the=20
question out of scope for USEAGE too, I said that you were wrong.=20
Repeatedly.

It is IN scope for us to discuss this related to USEAGE , but USEAGE is not =

presently on our schedule of things to discuss.

               Harald

--On 29. august 2005 11:59 -0700 John Stanley <[e-mail]> wrote:

>
>
> "Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:
>
>    The administrators MUST ensure that
>    that email address is valid and deliverable (and naturally, any
>    <path-identity> involved would have to be an FQDN).
>
> We went round this circle already.
>
> This is not group consensus.
>
> Do we want to go round this circle again, or will the chair actually
> enforce his own rulings?
>
> 'No mention' is  a simple concept.
>
>
>




--==========8DC4D0A156CC593E2EB3==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)

iD8DBQFDFB70OMj+2+WY0F4RAu+7AKDTZh7a1ejXiqpC/kblWPkVxSK2fQCeKIYh
mxfYAROczE9lbQXGIGQ5xRk=
=nore
-----END PGP SIGNATURE-----

--==========8DC4D0A156CC593E2EB3==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U28hu1097223; Mon, 29 Aug 2005 19:08:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U28h76097222; Mon, 29 Aug 2005 19:08:43 -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 j7U28ej1097213 for <[e-mail]>; Mon, 29 Aug 2005 19:08:43 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.254.1.2] (unverified [10.254.1.2])  by griffin.nibble.net (Nibble Mail V2.3) with ESMTP id 24127916  for multiple; Mon, 29 Aug 2005 21:08:40 -0500
Message-ID: <[e-mail]>
Date: Mon, 29 Aug 2005 21:08:37 -0500
From: Steve Walker <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Stanley <[e-mail]>
CC: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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>

John Stanley wrote:
> 
> "Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:
> 
>    The administrators MUST ensure that
>    that email address is valid and deliverable (and naturally, any
>    <path-identity> involved would have to be an FQDN).
> 
> We went round this circle already. 
> 
> This is not group consensus.
> 
> Do we want to go round this circle again, or will the chair actually 
> enforce his own rulings?
> 
> 'No mention' is  a simple concept.
> 

For what it's worth, I also think foolish to try to force FQDN 
path stamps and it's a major change from common practice.  A very 
large number of path stamps are not FQDN's, and even a larger 
number will not have email services setup regardless of what any 
new RFC mandates.

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 j7U1DmCM093459; Mon, 29 Aug 2005 18:13:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U1DmHo093458; Mon, 29 Aug 2005 18:13:48 -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 j7U1DjAP093451 for <[e-mail]>; Mon, 29 Aug 2005 18:13:46 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E9ug5-0003J7-CN for [e-mail]; Tue, 30 Aug 2005 03:12:41 +0200
Received: from c-180-161-85.hh.dial.de.ignite.net ([62.180.161.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 30 Aug 2005 03:12:41 +0200
Received: from nobody by c-180-161-85.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 30 Aug 2005 03:12:41 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  #1101 empty body (was: Next steps - please concentrate on USEFOR again)
Date:  Tue, 30 Aug 2005 03:10:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 64
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-161-85.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:

  [Charles said:]
>> 1. Son-of-1036 said that article bodies SHOULD NOT be empty
>> (it broke some implementations).

>> All our earlier drafts re-iterated that provision.

>> For some reason, it never got into USEFOR (though not
>> including it was never discussed). Please can we decide
>> now whether or not be want to retain that restriction?
 
> #1101

One of my (in)famous tests proving nothing at best:
<news://news.gmane.org/[e-mail]>

I could apparently post an article "without" body
resulting in an interesting Lines: 1

Checking what really happened, first my UA warned me:
"no text and no attachment, send anyway ?"  I clicked
"yes" and what my MUA did was this (ASCII screen shots):

=== one ===
Subject: #1101^M^J
^M^J
^M^J
=== two ===
Xref: news.gmane.org junk:341^M^J
^M^J
^M^J
=== end ===

Apparently my UA doesn't believe in really empty
bodies.  Next test, forcing it by editing "outbox",
see also <http://article.gmane.org/junk/343/raw>

Same effect, Lines: 1 

"Something" (I'm not sure what) added a 3rd CrLf
at the end.  Apparently that's like the "magic SP":

There "MUST" be a body, minimally CrLf.  And 2822
says "optionally", so that would go to appendix C
(differences from 2822).

Apparently 1036 doesn't talk about this, and its
default was 822... [LOL, 822 mentions '("headers")']
...also "optionally" (822 chapter 3.1)

Add this also to appendix B, differences from 1036 ?

Bruce would SCREAM.  Let's say that UAs generating
empty bodies without warning are stupid, but servers
or UAs breaking when they meet an article without
body are FUBAR.

Apparently s-o-1036 also doesn't require a body in 4.1
or 4.3.1, it only talks about "UAs SHOULD warn", okay,
that's USEAGE, not USEFOR.

Reject #1101 ?  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 j7TIxfXG034096; Mon, 29 Aug 2005 11:59:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TIxfI5034095; Mon, 29 Aug 2005 11:59:41 -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 j7TIxecr034083 for <[e-mail]>; Mon, 29 Aug 2005 11:59:40 -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 j7TIwxHV090928 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 29 Aug 2005 11:59:00 -0700 (PDT)
Date: Mon, 29 Aug 2005 11:59:34 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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 administrators MUST ensure that
   that email address is valid and deliverable (and naturally, any
   <path-identity> involved would have to be an FQDN).

We went round this circle already. 

This is not group consensus.

Do we want to go round this circle again, or will the chair actually 
enforce his own rulings?

'No mention' is  a simple concept.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R2ZMBV085419; Fri, 26 Aug 2005 19:35:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R2ZM9h085418; Fri, 26 Aug 2005 19:35:22 -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 j7R2ZKCu085411 for <[e-mail]>; Fri, 26 Aug 2005 19:35:21 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C93F320089 for <[e-mail]>; Sat, 27 Aug 2005 04:35: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 00464-09 for <[e-mail]>; Sat, 27 Aug 2005 04:35:00 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC593320084 for <[e-mail]>; Sat, 27 Aug 2005 04:34:55 +0200 (CEST)
Date: Fri, 26 Aug 2005 12:28:20 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Reminder: injection-info poll (#1080)
Message-ID: <B8EA5E4A10C1DBF128AC4836@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========0080E2294EE47F30B7B5=========="
X-Virus-Scanned: by 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>

--==========0080E2294EE47F30B7B5==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So far, I have seen opinions from Russ, Frank and Charles in reply to my=20
Aug 21 poll about Injection-Info.

That's not a lot....

                    Harald

--==========0080E2294EE47F30B7B5==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)

iD8DBQFDD21ZOMj+2+WY0F4RAhyIAKDquLy9gJKO087iO7iiQ9fyrFvlWACg1DAx
wgcM+BdqSuO7YrStDRJSGc0=
=8y9l
-----END PGP SIGNATURE-----

--==========0080E2294EE47F30B7B5==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QGn2aQ025563; Fri, 26 Aug 2005 09:49:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QGn2AX025562; Fri, 26 Aug 2005 09:49: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 j7QGn2Z2025555 for <[e-mail]>; Fri, 26 Aug 2005 09:49: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 j7QGmxel013650 for <[e-mail]>; Fri, 26 Aug 2005 09:48:59 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 209B5E7BCE; Fri, 26 Aug 2005 09:48:59 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Fri, 26 Aug 2005 14:08:56 GMT")
Organization: The Eyrie
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> <[e-mail]> <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> <[e-mail]> <C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 26 Aug 2005 09:48:59 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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, that is the article I remembered, and I was assuming that the
> "news.stanford.edu" that you mentioned was engaged mainly in relaying
> (since 2 days expiry seemed extraordinarily short for a serving agent).

Ah.  Yes, the key is that news.stanford.edu is only ever fed articles in
groups that it carries, so the memory of old articles isn't particularly
interesting.  I made that change years ago when I was having disk space
trouble with the partition containing the history file.

> The laptop man writes his article on day-1, and injects it on day-3, at
> a site which does not yet do "Injection-Date". It arrives at your
> transit server well within the 7 days, so it is accepted (it might well
> expire off there a day later, but the history file - or something - will
> still remember its message-id for 7 days in case it belatedly comes
> around again).

> In the meantime, it is passed to your leaf system which does not perform
> any staleness check of its own (which might have failed, given that
> ancient Date header), because it has been instructed to accept
> everything sent from your transit server without question.

Right.

This is definitely not a best practices configuration; it's a "I know what
I'm doing" configuration.  It's also not a very good example in retrospect
(critiquing myself of a year and a half ago), since it violates the
equality between history retention and old Date rejection, which probably
should be a MUST.  (I can prove that it doesn't matter in this case, but
this is not something I would recommend other people try at home.)

A better example would be a site with multiple transit servers, one with a
ton of peers and a lot of load and extremely restrictive rules about Date
headers that's designed to carry the majority of traffic as fast as
possible, and a second transit server with fewer peers and a much longer
history retention that serves as a backup to catch slow articles.  People
do things like this from time to time.

But, for the normal case, I would recommend either 7 or 10 days as good
time intervals to keep previously rejected or expired articles and to use
for Date staleness checks.

> There is no figure given for staleness in other circumstances, except
> that it MUST be no later than the amount of history you keep (e.g. 7
> days for your transit server). We probably ought to put a figure for
> this in USEAGE, and it looks like 7 or 10 days would be about right.

Yup.

-- 
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 j7QFZcVX017724; Fri, 26 Aug 2005 08:35:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QFZcW1017722; Fri, 26 Aug 2005 08:35: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 j7QFZanZ017707 for <[e-mail]>; Fri, 26 Aug 2005 08:35:37 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-207.midband.mdip.bt.net ([81.144.67.207]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430f36c7.6275.35 for [e-mail]; Fri, 26 Aug 2005 16:35:35 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7QFUSW09594 for [e-mail]; Fri, 26 Aug 2005 16:30:28 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22454
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> 	<[e-mail]> 	<8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> 	<[e-mail]> 	<C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126> 	<[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 26 Aug 2005 14:08:56 GMT
Lines: 84
Sender: [e-mail]
Precedence: 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 think you're half-remembering something I said and mixing up a few of
>the details.  Let's try to put this issue firmly to bed.

>In the original thread, you had made the statement that history entries
>were kept for at least 14 days.  I explained that it was configurable and
>that some servers kept history for a very short period of time, as low as
>a couple of days.  In fact, here's what I actually said:

>| I've run reader systems with considerably reduced history expiration
>| times for articles that aren't in the spool for years, and my
>| understanding is that this is not uncommon.  news.stanford.edu expires
>| old history entries after two days, for example.
>| 
>| The only operational requirement is that one's history retention time
>| matches one's cutoff limit for Date headers.  As long as that's true,
>| people can and do run history with cutoff times as low as two days or
>| lower.

>Note that there are various special cases that one might want to tune for.
>news.stanford.edu, as mentioned above, is a leaf system that is only fed
>by my transit server.  My transit server has a retention of 7 days and
>takes care of suppressing duplicates so that my reader server doesn't have
>to.  In that situation, there's very little need for the records of
>expired or rejected articles on my reader server and I retain only a
>couple of days worth, just in case.

Yes, that is the article I remembered, and I was assuming that the
"news.stanford.edu" that you mentioned was engaged mainly in relaying
(since 2 days expiry seemed extraordinarily short for a serving agent).

So, let me see if I understand:

The laptop man writes his article on day-1, and injects it on day-3, at a
site which does not yet do "Injection-Date". It arrives at your transit
server well within the 7 days, so it is accepted (it might well expire off
there a day later, but the history file - or something - will still remember
its message-id for 7 days in case it belatedly comes around again).

In the meantime, it is passed to your leaf system which does not perform
any staleness check of its own (which might have failed, given that
ancient Date header), because it has been instructed to accept everything
sent from your transit server without question.

>I'm not at all sure where the three day figure came from.  My guess is
>that you got it from the following message from me:

No, it was probably a mis-remembering of the "two days".

>| Charles Lindsey <[e-mail]> writes:
>|
>| > Anyway, the purpose of this discussion is to decide what number to
>| > write in for how stale an article could be allowed to be at the
>| > injector. John Stanley said 24 hours was too short. I suggested 72
>| > hours as a possible answer. There has to be _some_ number there. I am
>| > waiting for further suggestions or agreements.

In USEPRO, the only mention of 24 hours is how far into the future
articles are allowed to be before you reject them as bogus (one needs some
allowance, since clocks on the various agents can be in error - that 24
hours is an upper limit).

It also mentions 72 hours (into the past) as a lower limit at which you
MAY reject articles when _reinjecting_ and with no Injection-Date to help
you.

There is no figure given for staleness in other circumstances, except that
it MUST be no later than the amount of history you keep (e.g. 7 days for
your transit server). We probably ought to put a figure for this in
USEAGE, and it looks like 7 or 10 days would be about right.

-- 
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 j7QFZbqo017715; Fri, 26 Aug 2005 08:35:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QFZbYA017714; Fri, 26 Aug 2005 08:35:37 -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 j7QFZaZ1017699 for <[e-mail]>; Fri, 26 Aug 2005 08:35:37 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-207.midband.mdip.bt.net ([81.144.67.207]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430f36c6.6275.34 for [e-mail]; Fri, 26 Aug 2005 16:35:34 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7QFUTg09600 for [e-mail]; Fri, 26 Aug 2005 16:30:29 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22455
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Meta-level thought: Expectations of interworking?
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <9BD6B3E4D0CE93EA4847F5DD@B50854F0A9192E8EC6CDA126>
Date: Fri, 26 Aug 2005 14:16:45 GMT
Lines: 38
Sender: [e-mail]
Precedence: 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 <9BD6B3E4D0CE93EA4847F5DD@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>--On 23. august 2005 13:37 +0000 Charles Lindsey <[e-mail]> 
>wrote:

>> My concern is that we seem to agrree that this header MUST be inserted
>> (but not in proto articles of course) and yet we baulk at saying it is
>> mandatory.

>I balk at it because:

>1) we MUST handle messages from old servers
>2) we DO NOT specify handling of messages that do not conform to the syntax

>So if it's mandatory, we have said that we do not specify handling of ANY 
>old messages. And I think that is a mistake.

Right! Now I see where you are coming from. In that case, I suggest a NOTE
in USEFOR under the Injection-Date something like the following:

     NOTE: [USEPRO] REQUIRES this header field to be inserted whenever as
     article in injected into the network. However, since it is newly
     introduced in this standard, agents MUST continue to accept articles
     generated by earlier systems which do not include it. For this
     reason, it has not formally been designated as "mandatory".

BTW, I am on holiday all next week.

-- 
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 j7PJZ3nL046616; Thu, 25 Aug 2005 12:35:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJZ3dX046615; Thu, 25 Aug 2005 12:35:03 -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 j7PJZ2Kb046607 for <[e-mail]>; Thu, 25 Aug 2005 12:35:02 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E8NTS-00028b-8v for [e-mail]; Thu, 25 Aug 2005 21:33:18 +0200
Received: from 62.80.58.232 ([62.80.58.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 25 Aug 2005 21:33:18 +0200
Received: from nobody by 62.80.58.232 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 25 Aug 2005 21:33:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Meta-level thought: Expectations of interworking?
Date:  Thu, 25 Aug 2005 21:31:56 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <9BD6B3E4D0CE93EA4847F5DD@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: 62.80.58.232
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:
 
> 1) we MUST handle messages from old servers
> 2) we DO NOT specify handling of messages that do not conform
>    to the syntax
 
> So if it's mandatory, we have said that we do not specify
> handling of ANY old messages. And I think that is a mistake.

Oops, point taken.  RECOMMENDED 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 j7PJGo9S045055; Thu, 25 Aug 2005 12:16:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJGocv045053; Thu, 25 Aug 2005 12:16:50 -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 j7PJGnCQ045045 for <[e-mail]>; Thu, 25 Aug 2005 12:16:49 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E057132008A; Thu, 25 Aug 2005 21:16:33 +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 18150-10; Thu, 25 Aug 2005 21:16:30 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BB9B320084; Thu, 25 Aug 2005 21:16:28 +0200 (CEST)
Date: Thu, 25 Aug 2005 12:05:33 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: Meta-level thought: Expectations of interworking?
Message-ID: <9BD6B3E4D0CE93EA4847F5DD@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 23. august 2005 13:37 +0000 Charles Lindsey <[e-mail]> 
wrote:

>> No "perhaps" about it, if those headers are officially mandatory.  Given
>> that existing software does not generate them, and will continue that way
>> for a while yet, interoperability absolutely requires either (a) making
>> them optional (whether or not they are strongly recommended), or (b)
>> saying *both* "MUST generate" and "MUST NOT demand".
>
> Yes I agree. There are a couple of places in USEPRO where I would have to
> say that, and if Injection-Date is reverted to being mandatory I would
> make the necessary change.
>
> My concern is that we seem to agrree that this header MUST be inserted
> (but not in proto articles of course) and yet we baulk at saying it is
> mandatory.

I balk at it because:

1) we MUST handle messages from old servers
2) we DO NOT specify handling of messages that do not conform to the syntax

So if it's mandatory, we have said that we do not specify handling of ANY 
old messages. And I think that is a mistake.

                             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 j7PHmViN036406; Thu, 25 Aug 2005 10:48:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PHmVvM036405; Thu, 25 Aug 2005 10:48:31 -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 j7PHmUAp036399 for <[e-mail]>; Thu, 25 Aug 2005 10:48:30 -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 j7PHmSbr028118 for <[e-mail]>; Thu, 25 Aug 2005 10:48:28 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 548E3E7BCE; Thu, 25 Aug 2005 10:48:28 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu, 25 Aug 2005 10:34:53 GMT")
Organization: The Eyrie
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> <[e-mail]> <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> <[e-mail]> <C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]>
Date: Thu, 25 Aug 2005 10:48:28 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> This issue came up when we were inventing the Injection-Date header
> about 18 months ago. I recall pointing out that servers typically kept
> at least the Message-IDs in their history files for 14 days (that being
> the default in CNews, which I use). But I was told be someone (and I
> think it was you, Russ) that modern transit servers worked to a figure
> more like three days, and so that is the figure I have been quoting ever
> since. (I have not delved into the archives to find the message, but I
> could do so if necessary.)

I think you're half-remembering something I said and mixing up a few of
the details.  Let's try to put this issue firmly to bed.

In the original thread, you had made the statement that history entries
were kept for at least 14 days.  I explained that it was configurable and
that some servers kept history for a very short period of time, as low as
a couple of days.  In fact, here's what I actually said:

| I've run reader systems with considerably reduced history expiration
| times for articles that aren't in the spool for years, and my
| understanding is that this is not uncommon.  news.stanford.edu expires
| old history entries after two days, for example.
| 
| The only operational requirement is that one's history retention time
| matches one's cutoff limit for Date headers.  As long as that's true,
| people can and do run history with cutoff times as low as two days or
| lower.

Note that there are various special cases that one might want to tune for.
news.stanford.edu, as mentioned above, is a leaf system that is only fed
by my transit server.  My transit server has a retention of 7 days and
takes care of suppressing duplicates so that my reader server doesn't have
to.  In that situation, there's very little need for the records of
expired or rejected articles on my reader server and I retain only a
couple of days worth, just in case.

I'm not at all sure where the three day figure came from.  My guess is
that you got it from the following message from me:

| Charles Lindsey <[e-mail]> writes:
|
| > Anyway, the purpose of this discussion is to decide what number to
| > write in for how stale an article could be allowed to be at the
| > injector. John Stanley said 24 hours was too short. I suggested 72
| > hours as a possible answer. There has to be _some_ number there. I am
| > waiting for further suggestions or agreements.
| 
| How about we guarantee that 24 hours is safe (thus requiring sites to
| keep at least 24 hours of history, which I think is reasonable and proof
| against at least the forseeable future), and then explain why setting it
| to longer than that may cause articles not to propagate but leave it up
| to sites to make their own decisions?  We can't anticipate what this
| setting is going to be in another ten years.
| 
| Right now, my guess is that three days is almost certainly safe, five
| days is mostly okay but may cause problems, and ten days is going to
| almost definitely hit significant issues.
| 
| There is an interoperability issue here, so I agree that we have to say
| something, but there isn't actually a hard upper limit that one can
| justify.  Really, all the numbers we might come up with are magic and
| completely arbitrary.

Reading the above carefully, what I'm saying is that I don't believe there
are any significant transit servers with less than three day retention,
very few with less than five day retention, but quite a few with less than
ten day retention.  This is very different from saying that three days is
a "quite common" configuration for transit server history retention.

What I *am* saying is that it's very hard to anticipate how this
configuration may change in the future, particularly since the trend is
towards a more tightly connected Usenet with fewer propagation delays and
considerably more traffic.  CNews used 14 days, after all, which is
probably fairly rare now.  We therefore didn't want to write any tight
assumptions into the *standard* (but they're certainly fair game for best
practices, since it's more reasonable for best practices to change over
time).

-- 
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 j7PBGUOR043683; Thu, 25 Aug 2005 04:16:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PBGUrl043680; Thu, 25 Aug 2005 04:16:30 -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 j7PBGSnR043663 for <[e-mail]>; Thu, 25 Aug 2005 04:16:29 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-211.midband.mdip.bt.net ([81.144.75.211]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430da88b.9dcf.70 for [e-mail]; Thu, 25 Aug 2005 12:16:27 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7PBCOe29625 for [e-mail]; Thu, 25 Aug 2005 12:12:24 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22450
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> 	<[e-mail]> 	<8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> 	<[e-mail]> 	<C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126> <[e-mail]>
Date: Thu, 25 Aug 2005 10:34:53 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]> Russ Allbery <[e-mail]> writes:

>Harald Tveit Alvestrand <[e-mail]> writes:
>> Charles Lindsey <[e-mail]> wrote:

>> can someone who runs news services confirm this - that they not only
>> erase articles from the spool after 3 days, but expunge the message-ID
>> from the database of seen messages, and/or refuse to relay articles with
>> a Date: header more than 3 days in the past?

>People have done it in the past, but it's not best practice and people who
>use an expiration window that short tend to not get a lot of sympathy in
>news.software.nntp.  INN has defaulted to 10 days for a long time, and if
>I were writing best-practice documentation, I would recommend no less than
>7 days.  I haven't done a comprehensive survey, but my guess is that most
>people run INN with the default, and among those who change the default,
>increasing it is more common than decreasing it.

This issue came up when we were inventing the Injection-Date header about
18 months ago. I recall pointing out that servers typically kept at least
the Message-IDs in their history files for 14 days (that being the default
in CNews, which I use). But I was told be someone (and I think it was you,
Russ) that modern transit servers worked to a figure more like three days,
and so that is the figure I have been quoting ever since. (I have not
delved into the archives to find the message, but I could do so if
necessary.)

But bear in mind that the man who keeps an article on his laptop for 3
days before injecting it is not quite so badly off as I may have implied.
His article may well be rejected by the fastest relayers on the net, but
the flooding algorithm may well find a route through smaller servers that
keep things for 10 days or so, and so most of the net will still get a
chance to see it, but the propagation will be slow.

>One can certainly expire the articles off the server faster than that (one
>of my transit servers expires articles in about a day), but history should
>be retained for longer than that.

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


-- 
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 j7OJp440036688; Wed, 24 Aug 2005 12:51:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OJp4YF036687; Wed, 24 Aug 2005 12:51: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 j7OJp3Aa036681 for <[e-mail]>; Wed, 24 Aug 2005 12:51: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 j7OJp2X5029718 for <[e-mail]>; Wed, 24 Aug 2005 12:51:03 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8684EE7BCE; Wed, 24 Aug 2005 12:51:02 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Frank Ellermann's message of "Wed, 24 Aug 2005 15:54:26 +0200")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 24 Aug 2005 12:51:02 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

>> It's interesting (and rather eye-opening) to hear that
>> UUCP-only sites apparently don't have to check the syntax 
>> of messages

> Where do you see that ?  It would be very wrong...

That's what Charles just said.  He said that there's nothing in USEFOR
that requires relaying agents to verify the syntactic validity of
articles, even at a very basic level.

News to me, but thankfully not very relevant to me since all the servers I
care about speak NNTP.

> ...yes.  Did you read "relaying" == NNTP ?

No.

-- 
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 j7OJnqQb036591; Wed, 24 Aug 2005 12:49:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OJnqhc036590; Wed, 24 Aug 2005 12:49:52 -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 j7OJnpja036582 for <[e-mail]>; Wed, 24 Aug 2005 12:49:51 -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 j7OJnn50003265 for <[e-mail]>; Wed, 24 Aug 2005 12:49:50 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8DFE5E7BCE; Wed, 24 Aug 2005 12:49:49 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Wed, 24 Aug 2005 10:05:01 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 24 Aug 2005 12:49:49 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> Does it? I see where it says that servers and clients MUST accept
> well-formed articles, but where does it say they MUST reject malformed
> ones? Surely they can use "garbage in, garbage out" if they don't
> actually fall over in the process.

3.6.  Articles

   [...]
   For the purposes of this specification, articles are required to
   conform to the rules in this section and clients and servers MUST
   correctly process any article received from the other that does so.

Don't let the MUST in the second half of the sentence blind you to the
first half of the sentence.  Articles sent to another server are required
to conform to the specification of what an article is in the NNTP standard
or the server is violating the NNTP protocol.  This means that a server
can accept malformed junk if it doesn't send it to another server, but at
some point it has to verify the syntactic correctness of the article if it
plans on ever doing anything else with it, including transferring it to
another server or serving it to clients.

Also note all of the other MUST and MUST NOT provisions in the rest of
that section.

> In any case, well-formed in the NNTP-sense means little more than that
> the header has a name, a ':' a SP and a CRLF at the end and uses the
> folding rules properly. No requirement to check detailed USEFOR syntax.

I never said that there was a requirement to check the detailed USEFOR
syntax.  I said that the server has to traverse the entire article headers
regardless in order to verify that the article is syntactically valid.
(For that matter, it has to traverse the body as well.)

> Note that the present USEPRO requirement for relaying agents was changed
> to "SHOULD check for the presence of all the mandatory headers" fairly
> recently as a result of discussions on this list. It used to be rather
> stronger.

Not particularly relevant to the discussion we were having.

-- 
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 j7OG2T6V015425; Wed, 24 Aug 2005 09:02:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OG2TSd015424; Wed, 24 Aug 2005 09:02:29 -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 j7OG2SJ5015417 for <[e-mail]>; Wed, 24 Aug 2005 09:02:28 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A159320095; Wed, 24 Aug 2005 18:02: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 06949-10; Wed, 24 Aug 2005 18:02:08 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F23F320097; Wed, 24 Aug 2005 18:02:02 +0200 (CEST)
Date: Wed, 24 Aug 2005 07:57:38 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Russ Allbery <[e-mail]>, [e-mail]
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Message-ID: <5DCF416CA3DD541B6DAE7773@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> <[e-mail]> <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> <[e-mail]> <C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 23. august 2005 23:58 -0700 Russ Allbery <[e-mail]> wrote:

> People have done it in the past, but it's not best practice and people who
> use an expiration window that short tend to not get a lot of sympathy in
> news.software.nntp.  INN has defaulted to 10 days for a long time, and if
> I were writing best-practice documentation, I would recommend no less than
> 7 days.  I haven't done a comprehensive survey, but my guess is that most
> people run INN with the default, and among those who change the default,
> increasing it is more common than decreasing it.

Thanks, Russ!

Seems that if we ever get around to USEAGE, we should recommend keeping 
history for at least 10 days... and correspondingly, if we mention this 
problem, we should use 10 days in the examples....

                      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 j7OFYGDR011592; Wed, 24 Aug 2005 08:34:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OFYGL7011591; Wed, 24 Aug 2005 08:34:16 -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 j7OFYFJM011582 for <[e-mail]>; Wed, 24 Aug 2005 08:34:15 -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 j7OFYCtS027170; Wed, 24 Aug 2005 11:34:12 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7OFYCKt027169; Wed, 24 Aug 2005 11:34:12 -0400 (EDT)
Date: Wed, 24 Aug 2005 11:34:12 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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 24 Aug 2005, Kai Henningsen wrote:
> But if you're doing news propagation and the intermediate site is supposed  
> to see the article, it goes through rnews - which, in the case of INN,  
> does NNTP, I believe, though not necessarily over IP, and thus certainly  
> checks. I expect C news did similar stuff.

C News went the opposite route:  where all INN's incoming paths ultimately
go via NNTP, all of C News's ultimately went via a disk spool area (very
much in the style of UUCP).  The injection path did rigorous checking and
fixups (e.g. adding Date) on user-posted articles before dropping them in
the spool area.  The UUCP and NNTP incoming paths dropped data in the
spool area without examining it.  The server/relayer code picked up from
the spool area, and for speed, did only the most basic sanity checks --
superficial parse of all the headers, check for presence of mandatory
headers, detailed parse only for headers it actually cared about. 

                                                          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 j7OEqrBf006477; Wed, 24 Aug 2005 07:52:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OEqrh5006476; Wed, 24 Aug 2005 07:52: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 j7OEqqWk006468 for <[e-mail]>; Wed, 24 Aug 2005 07:52:52 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7wXL-0000UK-Up for [e-mail]; Wed, 24 Aug 2005 16:47:32 +0200
Received: from 212.82.251.137 ([212.82.251.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 24 Aug 2005 16:47:31 +0200
Received: from nobody by 212.82.251.137 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 24 Aug 2005 16:47:31 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Date:  Wed, 24 Aug 2005 16:43:12 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Message-ID:  <[e-mail]>
References:  <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> <[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.137
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:

> Please read section 2.2 of USEPRO

Yes, that's okay, but let's join P-A + F-A => P-A.
 
>> Or we move all these details to USEPRO where talking about
>> the different agents makes more sense. ...
 
> Yes, that was the intention behind my proposal not to use
> those terms in USEFOR.

Okay, not as Russ wanted it, but better for USEFOR, and if we
have the sets "UA" (P-A, R-A) and "news server" (I-A, R-A, S-A)
resulting in 3 + 4 terms, then using the two collective terms
is USEFOR, and the five specific terms + gateway in USEPRO is
not too bad.

> If USEFOR introduces and uses just "user agent" and
> "news-server", then it could well point out that USEPRO
> introduces a more detailed classification.

Maybe we need I-A in addition to "news server" in USEFOR at
some places (e.g. because R-As are not interested in some
rules for I-As).  In that case we could say something like:

      The news server (injection agent) MUST do...

I'm not yet sure that this is really the best idea.  Another
way would be to get rid of all specific UAs, posting, reading,
followup-ping, who cares, it's the UA.  But keep I-A vs. R-A
and UA vs. gateway, because these beasts are functionally
different, with different duties depending on their role.

                          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 j7OElETm005886; Wed, 24 Aug 2005 07:47:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OElEm1005883; Wed, 24 Aug 2005 07:47:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from colo.khms.westfalen.de ([e-mail] [213.239.196.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OElDG5005871 for <[e-mail]>; Wed, 24 Aug 2005 07:47:13 -0700 (PDT) (envelope-from [e-mail])
Received: from khms.vpn ([10.172.192.2]:41422 helo=khms.westfalen.de ident=Debian-exim) by colo.khms.westfalen.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1E7wWc-0004cw-GG for [e-mail]; Wed, 24 Aug 2005 16:46:46 +0200
Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.50) id 1E7v4g-0005nP-KE for [e-mail]; Wed, 24 Aug 2005 15:13:51 +0200
Received: by khms.westfalen.de (CrossPoint v3.12d.kh15 R/C435); 24 Aug 2005 14:48:44 +0200
Date: 24 Aug 2005 14:20:00 +0200
From: [e-mail] (Kai Henningsen)
To: [e-mail]
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
X-Mailer: CrossPoint v3.12d.kh15 R/C435
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Organisation? Me?! Are you kidding?
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-No-Junk-Mail: I do not want to get *any* junk mail.
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
X-Fix-Your-Modem: +++ATS2=255&WO1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

[e-mail] (Henry Spencer)  wrote on 22.08.05 in <[e-mail]>:

> On Mon, 22 Aug 2005, Charles Lindsey wrote:
> > >...This application has both the time and the incentive to use an
> > >adaptive hashing algorithm that customizes itself to the particular set
> > >of data so it can build a collision-free table.
> >
> > ...I would have imagined that if you construct a tailor-made
> > algorithm for some set of peers, then that algorithm will be so
> > complicated (i.e. consume so many cpu cycles) that you would be better
> > off with a simpler algorithm...
>
> Not necessarily.  One technique is to use a fixed basic algorithm
> containing some arbitrary constants -- e.g., for each character,
> exclusive-or it with K, multiply the current hash value by L, and add the
> two together, all done modulo M -- and do a brute-force search for a set
> of values for the constants which yields no collisions for the specified
> table contents.  The search is expensive, but the resulting hash algorithm
> can be simple and fast.

For a concrete example, look at gperf.

MfG Kai



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OElEKQ005889; Wed, 24 Aug 2005 07:47:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OElE2B005888; Wed, 24 Aug 2005 07:47:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from colo.khms.westfalen.de ([e-mail] [213.239.196.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OElDWf005872 for <[e-mail]>; Wed, 24 Aug 2005 07:47:13 -0700 (PDT) (envelope-from [e-mail])
Received: from khms.vpn ([10.172.192.2]:41422 helo=khms.westfalen.de ident=Debian-exim) by colo.khms.westfalen.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1E7wWe-0004cw-7j for [e-mail]; Wed, 24 Aug 2005 16:46:48 +0200
Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.50) id 1E7v4h-0005nP-Fc for [e-mail]; Wed, 24 Aug 2005 15:13:51 +0200
Received: by khms.westfalen.de (CrossPoint v3.12d.kh15 R/C435); 24 Aug 2005 14:48:44 +0200
Date: 24 Aug 2005 14:36:00 +0200
From: [e-mail] (Kai Henningsen)
To: [e-mail]
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
X-Mailer: CrossPoint v3.12d.kh15 R/C435
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Organisation? Me?! Are you kidding?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-No-Junk-Mail: I do not want to get *any* junk mail.
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
X-Fix-Your-Modem: +++ATS2=255&WO1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

[e-mail] (Russ Allbery)  wrote on 23.08.05 in <[e-mail]>:

> Charles Lindsey <[e-mail]> writes:
> > Russ Allbery <[e-mail]> writes:
>
> >> You have to scan the entire article header anyway in order to verify
> >> the syntactical correctness of the article, and it's simple to note the
> >> location of the Path header as you pass it.  Putting it first really
> >> wouldn't save any noticable time in practice.
>
> > Not if you are a relaying agent. All USEPRO says is that it SHOULD check
> > for the presence of all the mandatory headers.
>
> *NNTP* says that you can't send malformed junk, and verifying that what
> you received is not malformed junk requires scanning the entire headers.
> It's interesting (and rather eye-opening) to hear that UUCP-only sites
> apparently don't have to check the syntax of messages, but it's not
> particularly relevant to the real world.

I don't see how that would work, anyway - as someone currently doing some  
UUCP and previously doing all-UUCP.

It's true you can ship files from A to B through C without C doing any  
kind of analysis of the file, but that means that C can't do anything with  
the file except sending it on.

That is, an intermediate site behaves pretty much exactly like a router  
does with TCP. That router doesn't (usually) do any article syntax check,  
either.

But if you're doing news propagation and the intermediate site is supposed  
to see the article, it goes through rnews - which, in the case of INN,  
does NNTP, I believe, though not necessarily over IP, and thus certainly  
checks. I expect C news did similar stuff.

As for mail, where this middle man stuff need not apply, the behaviour is  
essentially the same as with SMTP is you put the "real" message inside a  
message/rfc822 part - it won't be touched either. That is, the UUCP has a  
different kind of envelope/contents separation than SMTP, and thus is  
interested in different things being ok ... and of course, the original  
UUCP rmail version, just like the original Unix mail version, did not  
include any kind of MTA at all.

These days, any UUCP mail I do is BSMTP and goes directly to the MTA, with  
all the usual checks. (Well, "rsmtp" is what UUCP actually calls it.)

> I really don't see any useful purpose served by optimizing the article for
> faster processing by lazy UUCP-only sites.

I don't see how that'd work anyway.

MfG Kai



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OE20oR089174; Wed, 24 Aug 2005 07:02:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OE20j6089173; Wed, 24 Aug 2005 07:02:00 -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 j7OE1wI8089146 for <[e-mail]>; Wed, 24 Aug 2005 07:01:59 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7vla-0003EL-Tg for [e-mail]; Wed, 24 Aug 2005 15:58:10 +0200
Received: from 212.82.251.137 ([212.82.251.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 24 Aug 2005 15:58:10 +0200
Received: from nobody by 212.82.251.137 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 24 Aug 2005 15:58:10 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and syntax - status
Date:  Wed, 24 Aug 2005 15:54:26 +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]> <[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.137
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:

> It's interesting (and rather eye-opening) to hear that
> UUCP-only sites apparently don't have to check the syntax 
> of messages

Where do you see that ?  It would be very wrong...

> but it's not particularly relevant to the real world.

...yes.  Did you read "relaying" == NNTP ?  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 j7OBFkfI023532; Wed, 24 Aug 2005 04:15:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OBFkrc023530; Wed, 24 Aug 2005 04:15:46 -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 j7OBFidm023494 for <[e-mail]>; Wed, 24 Aug 2005 04:15:45 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-121.midband.mdip.bt.net ([81.144.75.121]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430c56df.13bd6.af for [e-mail]; Wed, 24 Aug 2005 12:15:43 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7OBCEV19651 for [e-mail]; Wed, 24 Aug 2005 12:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22438
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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: Wed, 24 Aug 2005 10:05:01 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:

>Charles Lindsey <[e-mail]> writes:

>> Not if you are a relaying agent. All USEPRO says is that it SHOULD check
>> for the presence of all the mandatory headers.

>*NNTP* says that you can't send malformed junk,

Does it? I see where it says that servers and clients MUST accept
well-formed articles, but where does it say they MUST reject malformed
ones? Surely they can use "garbage in, garbage out" if they don't actually
fall over in the process.

In any case, well-formed in the NNTP-sense means little more than that the
header has a name, a ':' a SP and a CRLF at the end and uses the folding
rules properly. No requirement to check detailed USEFOR syntax.

Note that the present USEPRO requirement for relaying agents was changed
to "SHOULD check for the presence of all the mandatory headers" fairly
recently as a result of discussions on this list. It used to be rather
stronger.

-- 
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 j7OBFjCd023515; Wed, 24 Aug 2005 04:15:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OBFjkO023513; Wed, 24 Aug 2005 04: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 j7OBFins023488 for <[e-mail]>; Wed, 24 Aug 2005 04:15:44 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-121.midband.mdip.bt.net ([81.144.75.121]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430c56df.13bd6.ae for [e-mail]; Wed, 24 Aug 2005 12:15:43 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7OBCDZ19641 for [e-mail]; Wed, 24 Aug 2005 12:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22437
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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: Wed, 24 Aug 2005 09:44:59 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]> "Charles Lindsey" <[e-mail]> writes:

>Not if you are a relaying agent. All USEPRO says is that it SHOULD check
>for the presence of all the mandatory headers. Clearly, it needs to
>identify the Newsgroups, Path, Message-ID and Injection-Date (or Date)
>headers, because those affect what it has to do next. I don't think there
>is much point in its worrying about a missing Subject.

I omitted Distribution from that list and, since that header is usually
absent that will usually mean scanning right down to the end of the
headers, just to be sure it isn't there.

I grant you that some relayers will know they don't need to look at
Distribution. But note that they are all supposed to refuse to pass on
"Distribution: local", so strictly speaking they should all be checking for
that (however, it might be reasonable to assume that such articles would
already have been weeded out by an injecting agent).

-- 
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 j7OBFj6K023514; Wed, 24 Aug 2005 04:15:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OBFjYm023512; Wed, 24 Aug 2005 04: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 j7OBFhV6023485 for <[e-mail]>; Wed, 24 Aug 2005 04:15:44 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-121.midband.mdip.bt.net ([81.144.75.121]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430c56de.13bd6.ad for [e-mail]; Wed, 24 Aug 2005 12:15:42 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7OBCF319655 for [e-mail]; Wed, 24 Aug 2005 12:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22439
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 24 Aug 2005 10:09:24 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]> Henry Spencer <[e-mail]> writes:

>On Tue, 23 Aug 2005, Charles Lindsey wrote:
>> Consider a man who writes an article (Date: = day-1) on his laptop and
>> then carries it around for three days before finding an internet
>> connection where he can inject it. If the injecting site does not add an
>> Injection-Date: (= day-3), then subsequent relaying agents might reject it
>> as 'stale' (3 days is quite a common delay after which some relaying
>> agents erase all trace of an article, so they regard anything >3 days old
>> as stale). So his article fails to propagate...

>Mind you, for the near future that must be assumed anyway, because old
>servers will look only at Date for such decisions. 

Indeed. That is the main reason why Injection-Date was invented, and the
"MUST" is there to prevent the "harm" of losing the laptop user's
articles.

-- 
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 j7O6wqfi032127; Tue, 23 Aug 2005 23:58:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O6wq06032125; Tue, 23 Aug 2005 23:58:52 -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 j7O6wp5c032114 for <[e-mail]>; Tue, 23 Aug 2005 23:58: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 j7O6wnfo021815 for <[e-mail]>; Tue, 23 Aug 2005 23:58:49 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id D2EADE7BCE; Tue, 23 Aug 2005 23:58:48 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
In-Reply-To: <C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126> (Harald Tveit Alvestrand's message of "Tue, 23 Aug 2005 23:07:38 -0700")
Organization: The Eyrie
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> <[e-mail]> <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> <[e-mail]> <C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126>
Date: Tue, 23 Aug 2005 23:58:48 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:
> Charles Lindsey <[e-mail]> wrote:

>> Consider a man who writes an article (Date: = day-1) on his laptop and
>> then carries it around for three days before finding an internet
>> connection where he can inject it. If the injecting site does not add
>> an Injection-Date: (= day-3), then subsequent relaying agents might
>> reject it as 'stale' (3 days is quite a common delay after which some
>> relaying agents erase all trace of an article, so they regard anything
>> >3 days old as stale).

> can someone who runs news services confirm this - that they not only
> erase articles from the spool after 3 days, but expunge the message-ID
> from the database of seen messages, and/or refuse to relay articles with
> a Date: header more than 3 days in the past?

People have done it in the past, but it's not best practice and people who
use an expiration window that short tend to not get a lot of sympathy in
news.software.nntp.  INN has defaulted to 10 days for a long time, and if
I were writing best-practice documentation, I would recommend no less than
7 days.  I haven't done a comprehensive survey, but my guess is that most
people run INN with the default, and among those who change the default,
increasing it is more common than decreasing it.

One can certainly expire the articles off the server faster than that (one
of my transit servers expires articles in about a day), but history should
be retained for longer than that.

-- 
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 j7O6Ke2u015442; Tue, 23 Aug 2005 23:20:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O6Ke4X015441; Tue, 23 Aug 2005 23:20: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 j7O6KduU015419 for <[e-mail]>; Tue, 23 Aug 2005 23:20:39 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC97732008E; Wed, 24 Aug 2005 08:20:24 +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 27253-03; Wed, 24 Aug 2005 08:20:20 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1AB8532008F; Wed, 24 Aug 2005 08:20:19 +0200 (CEST)
Date: Tue, 23 Aug 2005 23:07:38 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Message-ID: <C4F0F9613908E367D0BED802@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126>  <[e-mail]> <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 23. august 2005 13:27 +0000 Charles Lindsey <[e-mail]> 
wrote:

> Consider a man who writes an article (Date: = day-1) on his laptop and
> then carries it around for three days before finding an internet
> connection where he can inject it. If the injecting site does not add an
> Injection-Date: (= day-3), then subsequent relaying agents might reject it
> as 'stale' (3 days is quite a common delay after which some relaying
> agents erase all trace of an article, so they regard anything >3 days old
> as stale).

can someone who runs news services confirm this - that they not only erase 
articles from the spool after 3 days, but expunge the message-ID from the 
database of seen messages, and/or refuse to relay articles with a Date: 
header more than 3 days in the past?

It seems like a quite short window to me.... in a world of servers run on a 
more-or-less volunteer basis, I can easily see a news server go belly-up on 
Friday afternoon and only get back online mid-Monday, thereafter happily 
announcing to the world all the "new" articles that it got on Friday 
morning, 3 days before....

                       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 j7O2HQgt004286; Tue, 23 Aug 2005 19:17:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O2HQg8004284; Tue, 23 Aug 2005 19:17: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 j7O2HO8j004268 for <[e-mail]>; Tue, 23 Aug 2005 19:17:25 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-89.midband.mdip.bt.net ([81.144.70.89]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430bd8b3.15949.2a for [e-mail]; Wed, 24 Aug 2005 03:17:23 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7O2C9116746 for [e-mail]; Wed, 24 Aug 2005 03:12:09 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22430
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1093 Email addresses - conclusion
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <BF9529995E07CE370AB932FE@B50854F0A9192E8EC6CDA126> <[e-mail]>
Date: Tue, 23 Aug 2005 19:19:41 GMT
Lines: 77
Sender: [e-mail]
Precedence: 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 <BF9529995E07CE370AB932FE@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>>As WG chair, I conclude that it's possible that the working group can come 
>>to consensus on excluding these requirements from the USEFOR standard 
>>document. (I don't see any strong arguments against putting in a NOTE 
>>saying that these practices exist, however - that's not normative).


>In the meantime, I shall rewrite those USEPRO texts and we can debate them
>as part of the Path debate (whose issue number escapes me just at the
>moment). From what you have said, a NOTE pointing out that these path
>identities are also used for sending email, with a pointer to USEAGE
>and/or RFC 2142, would be in order.

OK, I have now been through USEPRO and removed all mention of those
"abuse", "usenet" and "news" addresses, and the start of the text on
"Identification of news-servers" now reads as follows (note that I have
taken on board Harald's suggestion of a NOTE):

   In order to record the passage of articles through the network,
   news-servers need to identify themselves by means of a <path-
   identity> (F-3.1.6), which can appear in 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).
[Maybe that last sentence moves elsewhere.]
 
        NOTE: Such <path-identity>s may also be suitable for sending
        email to news-server administrators (see [USEAGE]).

The paragraphs following that are awaiting the outcome of the
identity/diagnostics discussions.

I have also written the following tentative piece for USEAGE (I think it
is useful to prepare a text whilst the matter is fresh in our minds - I
will accept comments on it now, but major discussion will come later when
USEAGE is fully on topic):

   The injecting agent bears a responsibility towards the rest of the
   network for ensuring both that the articles it injects are compliant
   with [USEFOR] (and so [USEPRO] imposes a duty on it to check articles
   for compliance rather thoroughly), and that they conform with the
   general expectations of the network as to what constitutes "proper
   behaviour". Its administrators therefore have a duty to be responsive
   to complaints concerning the behaviour of those posters who are
   permitted to use it.
 
   Complaints by such people should normally be sent to the email
   address specified in any "mail-complaints-to" <parameter> of its
   Injection-Info header field or, in the absence of that <parameter>,
   to "abuse@" followed by the <path-identity> in that field (or the
   <path-identity> that is inserted in the Path header field - the one
   immediately to the left of the "POSTED" <keyword> - if no Injection-
   Info header field is provided). The administrators MUST ensure that
   that email address is valid and deliverable (and naturally, any
   <path-identity> involved would have to be an FQDN).

        NOTE: These arrangements are an alternative to the "abuse"
        address recommended by [RFC 2142] (strict adherence to that RFC
        is not a requirement of [USEPRO]).  However, such complaints or
        abuse addresses are for matters concerning the behaviour of
        posters. Emails concerning technical matters should still be
        addressed to "usenet@" or "news@" followed by one of those
        <path-identity>s, following the recommendations in [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 j7NKgnNp006586; Tue, 23 Aug 2005 13:42:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NKgns0006585; Tue, 23 Aug 2005 13:42:49 -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 j7NKgm9v006558 for <[e-mail]>; Tue, 23 Aug 2005 13:42:48 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E30732008A; Tue, 23 Aug 2005 22:42:34 +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 07080-08; Tue, 23 Aug 2005 22:42:29 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCB5D320084; Tue, 23 Aug 2005 22:42:27 +0200 (CEST)
Date: Tue, 23 Aug 2005 10:58:06 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Henry Spencer <[e-mail]>, Usefor Mailing List <[e-mail]>
Subject: Re: Injection-* (was Re: Meta-level...)
Message-ID: <C94D96995407C811D5D344B3@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 23. august 2005 11:19 -0400 Henry Spencer <[e-mail]> wrote:

>
> On Tue, 23 Aug 2005, Charles Lindsey wrote:
>> ...My concern is that we seem to agrree that this header MUST be inserted
>> (but not in proto articles of course) and yet we baulk at saying it is
>> mandatory.
>
> Yes, that does seem inconsistent.

actually "MUST generate / MUST NOT require" is not much more inconsistent 
than "MUST accept / MUST NOT generate", which we have quite a few examples 
of.

                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 j7NGO9Ij065948; Tue, 23 Aug 2005 09:24:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NGO9Bu065947; Tue, 23 Aug 2005 09:24:09 -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 j7NGO97s065933 for <[e-mail]>; Tue, 23 Aug 2005 09:24: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 j7NGO5P0004115 for <[e-mail]>; Tue, 23 Aug 2005 09:24:06 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8DF8BE7CB5; Tue, 23 Aug 2005 09:24:05 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Tue, 23 Aug 2005 10:45:16 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 23 Aug 2005 09:24:05 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

>> You have to scan the entire article header anyway in order to verify
>> the syntactical correctness of the article, and it's simple to note the
>> location of the Path header as you pass it.  Putting it first really
>> wouldn't save any noticable time in practice.

> Not if you are a relaying agent. All USEPRO says is that it SHOULD check
> for the presence of all the mandatory headers.

*NNTP* says that you can't send malformed junk, and verifying that what
you received is not malformed junk requires scanning the entire headers.
It's interesting (and rather eye-opening) to hear that UUCP-only sites
apparently don't have to check the syntax of messages, but it's not
particularly relevant to the real world.

I really don't see any useful purpose served by optimizing the article for
faster processing by lazy UUCP-only sites.

-- 
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 j7NG8Q5u056447; Tue, 23 Aug 2005 09:08:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NG8QBU056446; Tue, 23 Aug 2005 09:08:26 -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 j7NG8P3v056372 for <[e-mail]>; Tue, 23 Aug 2005 09:08:25 -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 j7NG82ig067846 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 23 Aug 2005 09:08:03 -0700 (PDT)
Date: Tue, 23 Aug 2005 09:08:19 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
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>:

>There is a standard notation for writing both IPv4- and IPv6-addresses,
>and the world will not thank us for not using them

There is a standard for what abuse reporting address must be valid, but
you felt we could change that. There is a standard for the syntax of a
message id, but we feel we can change that.

We have a known incompatibility with a specific way of representing an 
IPv6 address (IPv4 is irrelevant to this discussion). Like I said, there 
is no immutable rule that says we must do it the same way. I won't waste 
my time looking it up, but I expect that the "standard" in question does 
not use the RFC2119 mandates that would make the use anything more than a 
suggestion.

Specifically, if the use of IPv6 literals is limited to "diagnostic" 
purposes (which I've not yet seen well defined) then the only people 
entering them are a few admins who are doing something special in the 
first place. "The world" isn't involved in this, so pretending that this 
would be some hardship for "the world" is just more flummery.

And even if a site chooses to use its IPv6 address, then the amount of 
typing involved is 32 characters, one time, and only the feed sites are 
involved.

>So it is a choice of requiring the world to use a non-standard IPv6 
>notation 

Nonsense. Most of the world will never see, nor care, what appears in the 
path header. They will never have to "use" it. 

>or of accepting the small risk that some sites
>might try to use barewords such as "dead" and "beef", which old
>implementations might do strange things with.

We can either solve the problem permanently or we can waste more time 
arguing about what is "small risk" and why we should have to accept any 
risk at all. I see that you fall into the "waste more time arguing about 
it" camp. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NFJiwk027382; Tue, 23 Aug 2005 08:19:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NFJiBY027381; Tue, 23 Aug 2005 08:19:44 -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 j7NFJhrH027360 for <[e-mail]>; Tue, 23 Aug 2005 08:19:43 -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 j7NFJXtS007930; Tue, 23 Aug 2005 11:19:33 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7NFJXkD007929; Tue, 23 Aug 2005 11:19:33 -0400 (EDT)
Date: Tue, 23 Aug 2005 11:19:33 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Injection-* (was Re: Meta-level...)
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, 23 Aug 2005, Charles Lindsey wrote:
> ...My concern is that we seem to agrree that this header MUST be inserted
> (but not in proto articles of course) and yet we baulk at saying it is
> mandatory.

Yes, that does seem inconsistent.

                                                          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 j7NFF6MB024884; Tue, 23 Aug 2005 08:15:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NFF6ag024883; Tue, 23 Aug 2005 08:15:06 -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 j7NFF5Uh024865 for <[e-mail]>; Tue, 23 Aug 2005 08:15:05 -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 j7NFEttS007876; Tue, 23 Aug 2005 11:14:55 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7NFEtbT007875; Tue, 23 Aug 2005 11:14:55 -0400 (EDT)
Date: Tue, 23 Aug 2005 11:14:55 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
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, 23 Aug 2005, Charles Lindsey wrote:
> Consider a man who writes an article (Date: = day-1) on his laptop and
> then carries it around for three days before finding an internet
> connection where he can inject it. If the injecting site does not add an
> Injection-Date: (= day-3), then subsequent relaying agents might reject it
> as 'stale' (3 days is quite a common delay after which some relaying
> agents erase all trace of an article, so they regard anything >3 days old
> as stale). So his article fails to propagate...

Mind you, for the near future that must be assumed anyway, because old
servers will look only at Date for such decisions. 

                                                          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 j7NF9FLf021786; Tue, 23 Aug 2005 08:09:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NF9FSu021785; Tue, 23 Aug 2005 08:09:15 -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 j7NF9F7R021770 for <[e-mail]>; Tue, 23 Aug 2005 08:09:15 -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 j7NF95tS007841; Tue, 23 Aug 2005 11:09:05 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7NF94Ys007840; Tue, 23 Aug 2005 11:09:04 -0400 (EDT)
Date: Tue, 23 Aug 2005 11:09:04 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Injection-Date (was Re: Meta-level...)
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, 23 Aug 2005, Charles Lindsey wrote:
> >It would seem reasonable to omit Injection-Date if composition time and
> >injection time are the same, which is sometimes exactly true and often
> >approximately true...
> 
> Yes we might have said that, but that would have meant defining some
> official meaning for "approximately"...

No, I don't think that's necessary.  My thought was that the spec would
simply say that Injection-Date can be omitted if its content would be
*identical* to that of Date.  (As it very likely would be, for articles
whose composition and injection happen on the same machine.)

A lazy implementer might decide that being within a few seconds is close
enough, but that's his decision, not ours.

                                                          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 j7NErf20012210; Tue, 23 Aug 2005 07:53:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NErfOZ012209; Tue, 23 Aug 2005 07:53:41 -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 j7NErXUx012097 for <[e-mail]>; Tue, 23 Aug 2005 07:53:33 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-69-218.midband.mdip.bt.net ([81.144.69.218]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.191) id 430b386b.41ad.54 for [e-mail]; Tue, 23 Aug 2005 15:53:31 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NEo2J11949 for [e-mail]; Tue, 23 Aug 2005 15:50:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22427
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: merit (was Re: #1084 Names for ABNF productions - closing)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 23 Aug 2005 12:17:01 GMT
Lines: 20
Sender: [e-mail]
Precedence: 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:

>Read the discussion on ticket 1084.  There is NO OPPOSITION to this change, and
>ONLY SUGGESTIONS for it, which are based on merit.

Not so. I have been consistently opposing such changes (notably in
discussions with Frank concerning <id-left> and <id-right>) for a long
time. It seems even Frank does not want changes on the scale that Bruce
seems to envisage.

-- 
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 j7NErc9c012177; Tue, 23 Aug 2005 07:53:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NErbYc012176; Tue, 23 Aug 2005 07:53:37 -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 j7NErah5012165 for <[e-mail]>; Tue, 23 Aug 2005 07:53:37 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-69-218.midband.mdip.bt.net ([81.144.69.218]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.191) id 430b386f.41ad.59 for [e-mail]; Tue, 23 Aug 2005 15:53:35 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NEo3711955 for [e-mail]; Tue, 23 Aug 2005 15:50:03 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22428
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126>  <[e-mail]> <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126>
Date: Tue, 23 Aug 2005 13:27:20 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 <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>--On 22. august 2005 14:28 +0000 Charles Lindsey <[e-mail]> 
>wrote:

>> [Now you are going to ask why the present network does not exhibit that
>> problem. The answer is that the meaning of the Date header has changed -
>> according to RFC 2822, it is now the time of compositon of the article,
>> not the time of injection).]

>I don't understand this.
>By that definition, Date: would always be earlier than Injection-Date (if 
>it  is not erroneous), and would cause the article to stop propagating 
>earlier.

Indeed, Date will always be earlier than Injection-Date. But it is the
Injection-Date (when present) that is used to stop propagation.

Consider a man who writes an article (Date: = day-1) on his laptop and
then carries it around for three days before finding an internet
connection where he can inject it. If the injecting site does not add an
Injection-Date: (= day-3), then subsequent relaying agents might reject it
as 'stale' (3 days is quite a common delay after which some relaying
agents erase all trace of an article, so they regard anything >3 days old
as stale). So his article fails to propagate. Which is why we want to
REQUIRE Injection-Date.

>How can limiting an article's propagation cause loops?

Actually, there can be no permanent loops (if the protocol for
Injection-Date is followed correctly), but there are circumstances where
an article might be accepted a second time by a server that has already
seen it once, even if Injection-Date is used. See
www.imc.org.ietf-usefor/2004/May/0092.html for a possible (if improbable)
example.

-- 
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 j7NErZKa012158; Tue, 23 Aug 2005 07:53:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NErZQX012157; Tue, 23 Aug 2005 07:53:35 -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 j7NErYEx012133 for <[e-mail]>; Tue, 23 Aug 2005 07:53:35 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-69-218.midband.mdip.bt.net ([81.144.69.218]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.191) id 430b386d.41ad.57 for [e-mail]; Tue, 23 Aug 2005 15:53:33 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NEnxr11928 for [e-mail]; Tue, 23 Aug 2005 15:49:59 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22424
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]>
Date: Tue, 23 Aug 2005 11:23:14 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:

>OTOH Russ said we should use the same terms in both texts -
>it's impossible to follow both strategies at the same time :-(

>My gut feeling, for some time I had serious difficulties to
>understand who's who wrt I-A and P-A.  And yesterday I didn't
>know the term S-A.  That's a bad sign, the terminology is not
>clear.  No good idea how to fix it, but minimally 1.5 should
>be complete listing all six agents, defining a "news server"
>as the set I-A, R-A, and S-A 

Please read section 2.2 of USEPRO, which defines all those *-agent terms
in the context of the overall architecture (which it would be impossible
to do in USEFOR). It also defines "user agent" and "news-server" as the
appropriate groupings of *-agents.

(Note that 2.1 of USEPRO would be removed, since it just
duplicates the definitions in USEFOR.)

>Or we move all these details to USEPRO where talking about the
>different agents makes more sense. ...

Yes, that was the intention behind my proposal not to use those terms in
USEFOR.

If USEFOR introduces and uses just "user agent" and "news-server", then it
could well point out that USEPRO introduces a more detailed
classification.

-- 
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 j7NEraD3012167; Tue, 23 Aug 2005 07:53:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NEract012166; Tue, 23 Aug 2005 07:53:36 -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 j7NErZUK012151 for <[e-mail]>; Tue, 23 Aug 2005 07:53:36 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-69-218.midband.mdip.bt.net ([81.144.69.218]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.191) id 430b386e.41ad.58 for [e-mail]; Tue, 23 Aug 2005 15:53:34 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NEo0o11937 for [e-mail]; Tue, 23 Aug 2005 15:50:00 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22425
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Meta-level thought: Expectations of interworking?
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> <[e-mail]>
Date: Tue, 23 Aug 2005 12:06:38 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]> "Forrest J. Cavalier III" <[e-mail]> writes:

>Harald Tveit Alvestrand wrote:

>> Based on this, it's an obvious conclusion that Injection-info and 
>> Injection-date HAVE to be optional in the format (since otherwise a 
>> conformant server would still be conformant if it chose to reject all 
>> articles that did not have them).

>USEPRO says that an injecting agent MUST REMOVE the Injection-Info header field
>for re-injection, (which is a really bad idea to bless.)  It means that a reader
>cannot look at the header field and determine anything about the origin of an article
>with certainty.  That makes Injection-Info easy to construct, but basically
>unreliable information at the Reader end.

Yes, but there is only supposed to be one Injection-Info header in any
article, and that needs to be the latest one if re-injection has occurred.
And you carefully omitted to mention the advice given (right next to that
"MUST REMOVE") to rename the old header with something like
X-Injection-Info.


>As for the other parts of Injection-Info, it is my understanding that the
>sub-fields are going to be used as inputs to automatic spam detectors.

They can be used for whatever ad-hoc scripts people want to use them for.
For that reason, they need to have a reasonably well-defined syntax. But
mostly humans will just read them and extract whatever information they
need manually.

-- 
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 j7NErZ2D012146; Tue, 23 Aug 2005 07:53:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NErZtr012145; Tue, 23 Aug 2005 07:53:35 -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 j7NErXvu012114 for <[e-mail]>; Tue, 23 Aug 2005 07:53:34 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-69-218.midband.mdip.bt.net ([81.144.69.218]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.191) id 430b386d.41ad.56 for [e-mail]; Tue, 23 Aug 2005 15:53:33 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NEo4W11959 for [e-mail]; Tue, 23 Aug 2005 15:50:04 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22429
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Meta-level thought: Expectations of interworking?
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 23 Aug 2005 13:37:50 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]> Henry Spencer <[e-mail]> writes:

>On Mon, 22 Aug 2005, Charles Lindsey wrote:
>> 
>> ...Yes, I can see that some "MUST accept articles with missing mandatory
>> Injection-* header fields" wording should perhaps be written...

>No "perhaps" about it, if those headers are officially mandatory.  Given
>that existing software does not generate them, and will continue that way
>for a while yet, interoperability absolutely requires either (a) making
>them optional (whether or not they are strongly recommended), or (b) saying
>*both* "MUST generate" and "MUST NOT demand". 

Yes I agree. There are a couple of places in USEPRO where I would have to
say that, and if Injection-Date is reverted to being mandatory I would
make the necessary change.

My concern is that we seem to agrree that this header MUST be inserted
(but not in proto articles of course) and yet we baulk at saying it is
mandatory.

-- 
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 j7NErYv7012132; Tue, 23 Aug 2005 07:53:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NErYc9012130; Tue, 23 Aug 2005 07:53:34 -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 j7NErXDP012106 for <[e-mail]>; Tue, 23 Aug 2005 07:53:33 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-69-218.midband.mdip.bt.net ([81.144.69.218]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.191) id 430b386c.41ad.55 for [e-mail]; Tue, 23 Aug 2005 15:53:32 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NEo1111941 for [e-mail]; Tue, 23 Aug 2005 15:50:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22426
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Meta-level thought: Expectations of interworking?
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 23 Aug 2005 12:12:00 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]> Henry Spencer <[e-mail]> writes:

>It would seem reasonable to omit Injection-Date if composition time and
>injection time are the same, which is sometimes exactly true and often
>approximately true.  (The major case where it's not even approximately
>true is gatewaying.)

Yes we might have said that, but that would have meant defining some
official meaning for "approximately". And since we really want to
encourage Date as meaning "when I wrote this" (it is always useful to see
the time of composition to get the context of a message in a rapidly
evolving discussion), having a separate and visible Injection-Date header
will help towards 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 j7NBHGLR057338; Tue, 23 Aug 2005 04:17:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NBHGn0057337; Tue, 23 Aug 2005 04:17: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 j7NBHFLe057314 for <[e-mail]>; Tue, 23 Aug 2005 04:17:15 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-108.midband.mdip.bt.net ([81.144.64.108]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430b05ba.18375.13 for [e-mail]; Tue, 23 Aug 2005 12:17:14 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NBCGl10697 for [e-mail]; Tue, 23 Aug 2005 12:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22423
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> <[e-mail]>
Date: Tue, 23 Aug 2005 11:11:34 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]> Richard Clayton <[e-mail]> writes:

>I have a feeling that changing the terms will make much more of a meal
>of a paragraph such as this one:

>   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 header fields or in newgroup control
>   messages [USEPRO]).  However, such names MUST be accepted by relaying
>   and serving agents.

As Harald has already explained, s/posting agents/user agents/ and
s/relaying and serving agents/news-servers/.

OTOH, that change would suggest that injecting agents MUST now accept that
"_", and I am not sure that is what we want

>BTW: Mind you, now I look at it, I have a question about this paragraph,
>does this mean that it is currently proper for an injection agent to
>generate an underline? and that a followup agent can fail to accept it ?
>Why not say what I suspect is intended "However, such names MUST be
>accepted by all agents."

Yes, I think we need to make up our minds there. For sure, no agent
(posting or injecting) should be generating that "_" until some future
standard says so. Whether injecting agents (in their role as protectors of
Usenet against invalid stuff) should throw them out is worth discussing.
If we are changing that paragraph in the course of removing all those
*-agent terms from USEFOR, then we should fix any such problems at the same
time.


>Looking at the definitions in #1.5, these would benefit from being
>presented in a better order, the "message identifier" definition refers
>forward to a term not yet defined.

Some pairs of definitions are mutually self referring.

See USEPRO 2.2 for the intended detailed definitions of the *-agent terms,
which introduces them in the context of the overall architecture.

-- 
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 j7NBHF2Z057319; Tue, 23 Aug 2005 04:17:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NBHFEu057318; Tue, 23 Aug 2005 04:17:15 -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 j7NBHEDJ057290 for <[e-mail]>; Tue, 23 Aug 2005 04:17:14 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-108.midband.mdip.bt.net ([81.144.64.108]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430b05b9.18375.12 for [e-mail]; Tue, 23 Aug 2005 12:17:13 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NBCEK10687 for [e-mail]; Tue, 23 Aug 2005 12:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22421
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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, 23 Aug 2005 10:45:16 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]> Russ Allbery <[e-mail]> writes:

>Charles Lindsey <[e-mail]> writes:
>> Seth Breidbart <[e-mail]> writes:

>>> Putting the Path header on top would save more CPU cycles (to avoid
>>> scanning the header list for it) than scanning the Path header for
>>> peers takes.

>You have to scan the entire article header anyway in order to verify the
>syntactical correctness of the article, and it's simple to note the
>location of the Path header as you pass it.  Putting it first really
>wouldn't save any noticable time in practice.

Not if you are a relaying agent. All USEPRO says is that it SHOULD check
for the presence of all the mandatory headers. Clearly, it needs to
identify the Newsgroups, Path, Message-ID and Injection-Date (or Date)
headers, because those affect what it has to do next. I don't think there
is much point in its worrying about a missing Subject.

OTOH, injecting agents are expected to do more thorough checks (the idea
then being that subsequent agents should not need to repeat them). Also,
we require serving agents to do thorough checks on the grounds tha they
should not be providing invalid articles to their clients (though I could
be persuaded that SHOULD would suffice there also).

So if we are going to recommend any particular ordering of headers, then
putting the variant and mandatory headers first would appear to be the
proper thing to do, so that a relaying agent could stop scanning as soon
as it has seen the ones it needed.

-- 
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 j7NBHEoG057302; Tue, 23 Aug 2005 04:17:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NBHEP1057301; Tue, 23 Aug 2005 04:17:14 -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 j7NBHDTY057281 for <[e-mail]>; Tue, 23 Aug 2005 04:17:14 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-108.midband.mdip.bt.net ([81.144.64.108]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 430b05b8.18375.11 for [e-mail]; Tue, 23 Aug 2005 12:17:12 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7NBCF810693 for [e-mail]; Tue, 23 Aug 2005 12:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22422
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 23 Aug 2005 10:53:47 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]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>Provided use of ':' is limited to IPv6Addresses only, I believe our view
>>is that the number of problems will be acceptably low (but we need to
>>point out the danger of using "dead", "beef", etc.).

>We can either solve the problem altogether or argue about what value of 
>"low" is "acceptably low". Why not just solve the problem altogether? 
>There is no immutable reason that colons must be allowed as anything but 
>separators. There is already a proposal on the table for how to deal with 
>IPv6 addresses that solves the dead::beef problem. Why is it not used?

There is a standard notation for writing both IPv4- and IPv6-addresses,
and the world will not thank us for not using them (cf. the resistance to
the IPv6 notation introduced by RFC 2821). So it is a choice of requiring
the world to use a non-standard IPv6 notation (which it might not do in
spite of what we write) or of accepting the small risk that some sites
might try to use barewords such as "dead" and "beef", which old
implementations might do strange things with.

-- 
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 j7N1HVsh076844; Mon, 22 Aug 2005 18:17:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N1HVQ2076841; Mon, 22 Aug 2005 18:17:31 -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 j7N1HUim076828 for <[e-mail]>; Mon, 22 Aug 2005 18:17:30 -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 j7N1HJZp009448 for <[e-mail]>; Mon, 22 Aug 2005 18:17:27 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id CD050E7CB5; Mon, 22 Aug 2005 18:17:19 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: merit
In-Reply-To: <[e-mail]> (Forrest J. Cavalier, III's message of "Mon, 22 Aug 2005 14:33:13 -0400")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]>
Date: Mon, 22 Aug 2005 18:17:19 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> That isn't what he wrote, and I privately thanked him for the
> clarification, but the whole thing is ridiculous, as if the posted
> reasoned opinions of Henry, Russ, Bruce, and Frank are not enough to
> outweigh an editor who constantly whines "But editing is work" when the
> change in question would take 5 minutes and could be automatically
> checked, and would save EVERY IMPLEMENTOR MANY TIMES THAT AMOUNT OF
> TIME.

Well, I don't remember exactly what I said, but I hope it was something
along the lines of "it sounds like a reasonable idea, but I don't really
care a lot."  The problem with renaming productions is that you then have
to make sure that you caught every place where they were referenced in
other productions, and while the additional clarity sounds nice, I'm not
sure that it really ends up accomplishing a tremendous amount.

-- 
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 j7MLKWN8050794; Mon, 22 Aug 2005 14:20:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MLKWAV050792; Mon, 22 Aug 2005 14:20:32 -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 j7MLKVCd050785 for <[e-mail]>; Mon, 22 Aug 2005 14:20:31 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MLKUaC023444 for <[e-mail]>; Mon, 22 Aug 2005 17:20:30 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 17:20:35 -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: Admin: Editor clarification (Re: merit (was Re: #1084 Names for ABNF productions - closing))
References: <[e-mail]> <[e-mail]> <65405821D5C9A70AEDA40C2E@B50854F0A9192E8EC6CDA126>
In-Reply-To: <65405821D5C9A70AEDA40C2E@B50854F0A9192E8EC6CDA126>
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>

Harald Tveit Alvestrand wrote:
> 
> --On 22. august 2005 14:33 -0400 "Forrest J. Cavalier III" 
> <[e-mail]> wrote:
> 
> 
>>Henry, if this were a contentious issue, then I can see that me calling
>>for
>>"decisions based on merit" would just be rhetoric for "I'm right, you
>>are wrong."  In this case it isn't rhetorical.  THERE ARE NO VALID
>>REASONS FOR
>>AVOIDING THIS CHANGE.
>>
>>If we had an editor interested in finishing, this #1084 would never have
>>even been a ticket.  It's just THAT obvious.
> 
> 
> Point of order:
> 
> The editor of the USEFOR document is Ken Murchison.
> 
> Insulting Ken because of something Charles wrote is .... bizarre.

I should not have written that, for a number of reasons.  It is totally
unsupported.

I apologize.

Charles was the author of most of the text of USEFOR, until the split
a year ago.  Much of the text remains his.

I have not observed Ken taking much editorial control over USEFOR,
nor participating in discussion on any topic here recently.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MKpO82041070; Mon, 22 Aug 2005 13:51:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MKpOwr041069; Mon, 22 Aug 2005 13: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 j7MKpN4g041062 for <[e-mail]>; Mon, 22 Aug 2005 13:51:23 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7JER-0007qG-VW for [e-mail]; Mon, 22 Aug 2005 22:49:24 +0200
Received: from c-134-88-160.hh.dial.de.ignite.net ([62.134.88.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 22:49:23 +0200
Received: from nobody by c-134-88-160.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 22:49:23 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Date:  Mon, 22 Aug 2005 22:43:39 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Message-ID:  <[e-mail]>
References:  <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <BFF1A5073D4A3EFFD54C5023@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: c-134-88-160.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:
 
> The 20-line Perl script that I use to make monthly postings
> to comp.os.linux.misc is a posting-agent that isn't a
> forwarding-agent..... obviously a special case.

Okay, it's a bot that never creates followups.  Some bots do,
article validators in test groups waiting for users who don't
say "ignore noreply" somewhere in the subject.  Adding some
lines you could turn your P-A in an F-A, this distinction is
artificial.

You just said "forwarding-agent" instead of "followup-agent",
maybe it's not only me who doesn't see why F-A is a necessary
term for a distinct set of functions.

                           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 j7MKV2vD039316; Mon, 22 Aug 2005 13:31:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MKV2bD039315; Mon, 22 Aug 2005 13:31:02 -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 j7MKV1RO039303 for <[e-mail]>; Mon, 22 Aug 2005 13:31:01 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65C6732008E; Mon, 22 Aug 2005 22:30: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 32625-02; Mon, 22 Aug 2005 22:30:43 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0E7B32008D; Mon, 22 Aug 2005 22:30:42 +0200 (CEST)
Date: Mon, 22 Aug 2005 13:20:10 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: "Forrest J. Cavalier III" <[e-mail]>, Usefor Mailing List <[e-mail]>
Subject: Admin: Editor clarification (Re: merit (was Re: #1084 Names for ABNF productions - closing))
Message-ID: <65405821D5C9A70AEDA40C2E@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 22. august 2005 14:33 -0400 "Forrest J. Cavalier III" 
<[e-mail]> wrote:

> Henry, if this were a contentious issue, then I can see that me calling
> for
> "decisions based on merit" would just be rhetoric for "I'm right, you
> are wrong."  In this case it isn't rhetorical.  THERE ARE NO VALID
> REASONS FOR
> AVOIDING THIS CHANGE.
>
> If we had an editor interested in finishing, this #1084 would never have
> even been a ticket.  It's just THAT obvious.

Point of order:

The editor of the USEFOR document is Ken Murchison.

Insulting Ken because of something Charles wrote is .... bizarre.

                   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 j7MK2Ud9037040; Mon, 22 Aug 2005 13:02:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MK2UcF037039; Mon, 22 Aug 2005 13:02:30 -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 j7MK2TGe037032 for <[e-mail]>; Mon, 22 Aug 2005 13:02:30 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCC79320084; Mon, 22 Aug 2005 22:02: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 31929-06; Mon, 22 Aug 2005 22:02:12 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F63932008D; Mon, 22 Aug 2005 22:02:08 +0200 (CEST)
Date: Mon, 22 Aug 2005 11:42:13 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Message-ID: <8867DEDC03E7BDC41E455637@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 22. august 2005 14:28 +0000 Charles Lindsey <[e-mail]> 
wrote:

> BTW, Injection-Info is currently only "SHOULD generate" as things stand,
> and there is no proposal on the table to change that. Injection-Date is
> "MUST generate" in USEPRO because there exist circumstances (possibly
> rare) where omitting it can cause looping.
>
> [Now you are going to ask why the present network does not exhibit that
> problem. The answer is that the meaning of the Date header has changed -
> according to RFC 2822, it is now the time of compositon of the article,
> not the time of injection).]

I don't understand this.
By that definition, Date: would always be earlier than Injection-Date (if 
it  is not erroneous), and would cause the article to stop propagating 
earlier.

How can limiting an article's propagation cause loops?

(Not that I want to reopen the "MUST generate" debate. I just want to 
understnad.)

             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 j7MK2RE8037029; Mon, 22 Aug 2005 13:02:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MK2Rw5037028; Mon, 22 Aug 2005 13:02:27 -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 j7MK2Qn1037021 for <[e-mail]>; Mon, 22 Aug 2005 13:02:26 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2EE5D320084; Mon, 22 Aug 2005 22:02:13 +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 31880-08; Mon, 22 Aug 2005 22:02:07 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF1ED32008A; Mon, 22 Aug 2005 22:02:06 +0200 (CEST)
Date: Mon, 22 Aug 2005 11:39:06 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Message-ID: <BFF1A5073D4A3EFFD54C5023@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 22. august 2005 19:37 +0200 Frank Ellermann <[e-mail]> 
wrote:

> Or we move all these details to USEPRO where talking about the
> different agents makes more sense.  Especially F-A vs. P-A is
> highly artificial or in other words utter dubious - any piece
> of software claiming to be only a P-A but no F-A (or v.v.) is
> most probably broken.

The 20-line Perl script that I use to make monthly postings to 
comp.os.linux.misc is a posting-agent that isn't a forwarding-agent..... 
obviously a special case.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MJxMtq036803; Mon, 22 Aug 2005 12:59:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MJxMTg036802; Mon, 22 Aug 2005 12:59: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 j7MJxKfl036793 for <[e-mail]>; Mon, 22 Aug 2005 12:59:21 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7IPK-0001UU-FH for [e-mail]; Mon, 22 Aug 2005 21:56:36 +0200
Received: from c-134-88-160.hh.dial.de.ignite.net ([62.134.88.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 21:56:34 +0200
Received: from nobody by c-134-88-160.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 21:56:34 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: merit
Date:  Mon, 22 Aug 2005 21:46:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 58
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: c-134-88-160.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>

Forrest J. Cavalier III wrote:

> Read the discussion on ticket 1084.  There is NO OPPOSITION
> to this change, and ONLY SUGGESTIONS for it, which are based
> on merit.

IIRC I mumbled something in the direction of "maybe possible,
but not necessary and not desirable", and then I was more
interested in the details how to fix the erroneous Date.  If
you represent that as "no opposition" IBTD.

Adding the collected ABNF of MESSFOR and USEFOR and run it
through Bill's parser would of course require different names.

But that's nothing you need in practice as implementor, you
trust that at least the ABNF is correct.  You want to parse
this stuff in your implementation.  A hypothetical combined
ABNF is useless, each valid <msg-id-news> is also a valid
<msg-id-2822>, that's the idea.

For NetNews implementations it's irrelevant that some invalid
<msg-id-news> might be valid <msg-id-2822>.  For a MUA or a
combined UA you'd generate <msg-id-news> because that's always
okay.  So the "real" <msg-id> is <msg-id-news> if you generate
them, or if you check them as Injection-Agent.  Anything else
is dubious, be tolerant in what you accept etc.

I don't see a real need for a combined ABNF, except from the
required validations for each I-D.  But then you can also add
USEFOR after MESSFOR, and remove anything that's redefined.

As Harald said it's easy to find, everything in USEFOR is new.

OTOH I agree that we should minimize the interface, the same
name for header field productions is okay, in the case of the
<msg-id> it's even desirable.

The same name for stuff like <unstructured> where it's only a
minor difference caused by NetNews idiosyncrasies like the
"magic SP" is also okay.

The same name for details like <no-fold-quote> that are _very_
different, even the MESSFOR rules about the "semantic content"
are not more applicable, is fundamentally flawed.

The same name when the old name was an excessively poor choice
like <id-right>, and we have an obvious excuse to change this,
because our syntax is different, is also bad, that should be
<id-domain>.

So that's my opinion, whatever it might be, wrong, minority,
okay, it's different from your, Bruce's, Charles', or Seth's
opinions.

Ignoring the internal rules of <msg-id> for the moment Charles
isn't alone, I also don't like clumsy <unstructured-news> etc.
names.  Above all I want to fix the silly <msg-id-2822>.  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 j7MJinD4035023; Mon, 22 Aug 2005 12:44:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MJinsa035022; Mon, 22 Aug 2005 12:44:49 -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 j7MJimsR035016 for <[e-mail]>; Mon, 22 Aug 2005 12:44:48 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MJieaC029639 for <[e-mail]>; Mon, 22 Aug 2005 15:44:47 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 15:44:46 -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: #1084 Names for ABNF productions - closing
References: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126> <[e-mail]> <E9ADB21C23FB115DEEB16455@B50854F0A9192E8EC6CDA126>
In-Reply-To: <E9ADB21C23FB115DEEB16455@B50854F0A9192E8EC6CDA126>
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>

Harald Tveit Alvestrand wrote:

> 
> 
> --On 22. august 2005 06:36 -0400 "Forrest J. Cavalier III" 
> <[e-mail]> wrote:
> 
> 
>>USEFOR grabs a whole bunch of production names from RFC2822.  How is
>>an implementor supposed to know which ones are different without
>>keeping track of a mental list?
> 
> 
> All of the ones that appear on the left hand side of a production are 
> different. That's a rather simple rule.....

"Jump 200 feet in the air" is a simple rule too.

We aren't trying to simplify writing USEFOR, we are trying to simplify
implemention of conforming software.

It's bizarre to be having a discussion about optimizing how easy it
is to write something rather than trying to optimize how clear it
is to read.

This isn't supposed to be a diary, written by someone just figuring out
how Usenet works.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MJIas3032570; Mon, 22 Aug 2005 12:18:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MJIavx032569; Mon, 22 Aug 2005 12:18:36 -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 j7MJIZUk032557 for <[e-mail]>; Mon, 22 Aug 2005 12:18:35 -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 j7MJI73v074142 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 22 Aug 2005 12:18:11 -0700 (PDT)
Date: Mon, 22 Aug 2005 12:18:23 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
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>:

>Provided use of ':' is limited to IPv6Addresses only, I believe our view
>is that the number of problems will be acceptably low (but we need to
>point out the danger of using "dead", "beef", etc.).

We can either solve the problem altogether or argue about what value of 
"low" is "acceptably low". Why not just solve the problem altogether? 
There is no immutable reason that colons must be allowed as anything but 
separators. There is already a proposal on the table for how to deal with 
IPv6 addresses that solves the dead::beef problem. Why is it not used?

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx> writes:

>Yes, IP addresses will occur in Path. They already do (v4), and any system 
>that doesn't pass on articles that contain them is so broken that it's got 
>no business passing itself off as an USENET server.

Let's see if I understand your position correctly. The PATH header is 
intended to prevent dups from wasting time and resources, so any server
that passes them on is causing harm to the net. But if one of the path 
identities happens to contain the string ":dead:beef:" and if one of the 
peers of this server is named "dead", then the server must ignore the 
rules about not passing dups on to its neighbors, otherwise it is "so 
broken that it's got no business passing itself off as a[n] USENET 
server."

Does that about cover it? "Here's your new USENET standard. It's double
plus good. Have a nice day."

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>However, having a different syntax for "identification names" and 
>"diagnostic names" is an additional complication which gives you no extra
>benefit (in particular, it does not affect the dead/beef problem, which is
>already present on account of the diagnostic usage).

Only if you adamantly demand that colons become anything other than a 
delimiter, which is not backwards compatible with existing servers. It is 
TRIVIAL to remove the problem. Why are we still arguing about 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 j7MJG8Us032241; Mon, 22 Aug 2005 12:16:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MJG84K032240; Mon, 22 Aug 2005 12:16:08 -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 j7MJG6mF032232 for <[e-mail]>; Mon, 22 Aug 2005 12:16:07 -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 j7MJG3tS022069; Mon, 22 Aug 2005 15:16:03 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7MJG24Z022068; Mon, 22 Aug 2005 15:16:02 -0400 (EDT)
Date: Mon, 22 Aug 2005 15:16:02 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: Meta-level thought: Expectations of interworking?
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 Mon, 22 Aug 2005, Charles Lindsey wrote:
> >Based on this, it's an obvious conclusion that Injection-info and 
> >Injection-date HAVE to be optional in the format (since otherwise a 
> >conformant server would still be conformant if it chose to reject all 
> >articles that did not have them).
> 
> ...Yes, I can see that some "MUST accept articles with missing mandatory
> Injection-* header fields" wording should perhaps be written...

No "perhaps" about it, if those headers are officially mandatory.  Given
that existing software does not generate them, and will continue that way
for a while yet, interoperability absolutely requires either (a) making
them optional (whether or not they are strongly recommended), or (b) saying
*both* "MUST generate" and "MUST NOT demand". 

> ...Injection-Date is
> "MUST generate" in USEPRO because there exist circumstances (possibly
> rare) where omitting it can cause looping.
> [Now you are going to ask why the present network does not exhibit that
> problem. The answer is that the meaning of the Date header has changed -
> according to RFC 2822, it is now the time of compositon of the article,
> not the time of injection).]

It would seem reasonable to omit Injection-Date if composition time and
injection time are the same, which is sometimes exactly true and often
approximately true.  (The major case where it's not even approximately
true is gatewaying.)

                                                          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 j7MIkhJ7023871; Mon, 22 Aug 2005 11:46:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MIkhbo023870; Mon, 22 Aug 2005 11:46: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 j7MIkfet023845 for <[e-mail]>; Mon, 22 Aug 2005 11:46:42 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7HHa-0007NN-Tb for [e-mail]; Mon, 22 Aug 2005 20:44:31 +0200
Received: from c-134-88-160.hh.dial.de.ignite.net ([62.134.88.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 20:44:30 +0200
Received: from nobody by c-134-88-160.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 20:44:30 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: merit
Date:  Mon, 22 Aug 2005 20:41:30 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
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: c-134-88-160.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>

Henry Spencer wrote:

> "obviously I'm right and you're wrong,
>  so we should do it my way".

Yes, using this simple principle I got:

msg-id          =>   msg-id          (revised 2822)
id-left         =>   id-local        (subset of 2822)
id-right        =>   id-domain       (subset of 2822)
dot-atom-text   ==   dot-atom-text   (same as 2822)
no-fold-quote   =>   id-quote        (subset of 2822)
no-fold-literal =>   id-literal      (subset of 2822)
mqtext          =>   id-text         (NOT qtext)
mqspecial       =>   id-special      (NOT quoted-pair)
atext           ==   atext           (same as 2822)
mdtext          =>   n/a             (NOT dtext)

                     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 j7MIZSeF017144; Mon, 22 Aug 2005 11:35:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MIZSGU017143; Mon, 22 Aug 2005 11:35:28 -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 j7MIZRik017128 for <[e-mail]>; Mon, 22 Aug 2005 11:35:27 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MIZPaC015903 for <[e-mail]>; Mon, 22 Aug 2005 14:35:26 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 14:35:31 -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: #1084 Names for ABNF productions - closing
References: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126> <[e-mail]> <[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>

Alexey Melnikov wrote:

> Forrest J. Cavalier III wrote:
> 
> 
>>Harald Tveit Alvestrand wrote:
>>
>>
>>>I found no consensus for change - one loud voice (Bruce) and a lot of 
>>>comments indicating that they did not see a big difference (meaning 
>>>that Bruce did not convince them) does not make a consensus.
>>>
>>>So unless there are other people arguing strongly for changing the 
>>>ABNF production names from "msg-id", "subject", "comments" and so on 
>>>to "news-msg-id", "news-subject", "news-comments" and so on, I'll 
>>>declare this ticket closed.
>>
>>[...]
>>We must not ignore that implementors want to adapt RFC2822-compliant
>>software to usefor, not write from scratch.  Having ABNF production names
>>be different when they are different makes it possible to inventory
>>everything that must be reviewed for compliance.
> 
> 
> Having an explicit list of changed ABNF productions addresses this as 
> well. I don't see much difference between the two approaches, but 
> renaming productions might introduce errors in the document, IMHO.

I think you have that backwards.  Not renaming productions might introduce
errors in the document.

How else do you run this mess through an ABNF checker but by concatenating
RFC2822 grammar and the USEFOR grammar?

Try doing that with colliding ABNF production names.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MIXG8t015779; Mon, 22 Aug 2005 11:33:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MIXGBY015777; Mon, 22 Aug 2005 11:33:16 -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 j7MIXFGQ015762 for <[e-mail]>; Mon, 22 Aug 2005 11:33:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MIX7aC015245 for <[e-mail]>; Mon, 22 Aug 2005 14:33:14 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 14:33:13 -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: merit (was Re: #1084 Names for ABNF productions - closing)
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>

Henry Spencer wrote:
> On Mon, 22 Aug 2005, Forrest J. Cavalier III wrote:
> 
>>Changes should be accepted or rejected on their merits, not how many
>>people advocate them.
> 
> 
> "Merits" as determined how, exactly?
> 
> Very occasionally a change is an obvious non-starter -- internally
> contradictory or otherwise ridiculous.  But in almost all other cases, its
> "merits" are a judgement call -- a matter of opinion -- and the only way
> to assess them is to see what the WG members think.
> 
> Calling for something to be assessed "on its merits" tends to be a code
> phrase for "obviously I'm right and you're wrong, so we should do it my way".

Yes Henry, "merit" is subjective, and sometimes needs a poll.

Read the discussion on ticket 1084.  There is NO OPPOSITION to this change, and
ONLY SUGGESTIONS for it, which are based on merit.

Actually, there is ONLY ONE PERSON who says it isn't broken and he isn't
planning to fix it.  And IN THE SAME MESSAGE CHARLES ADMITS WE HAVE A DUTY TO
MAKE THE DIFFERENCES FROM RFC2822 CLEAR.  (How he holds contradictory
opinions is amazing.)

Bruce and others already expressed the opinion I had, so I saw no need
to post a /me too.

So it shocked me that a non-reasoned, internally contradictory opinion from
the editor can direct the chair with so much ease.....But Hey, that's
Usefor.

Harald later posted that when he wrote "I saw no consensus for this
change, I am closing it" he meant to write "he was asking for other opinions."

That isn't what he wrote, and I privately thanked him for the clarification,
but the whole thing is ridiculous, as if the posted reasoned opinions of Henry,
Russ, Bruce, and Frank are not enough to outweigh an editor who constantly whines
"But editing is work" when the change in question would take 5 minutes and could
be automatically checked, and would save EVERY IMPLEMENTOR MANY TIMES THAT AMOUNT OF
TIME.

Henry, if this were a contentious issue, then I can see that me calling for
"decisions based on merit" would just be rhetoric for "I'm right, you
are wrong."  In this case it isn't rhetorical.  THERE ARE NO VALID REASONS FOR
AVOIDING THIS CHANGE.

If we had an editor interested in finishing, this #1084 would never have
even been a ticket.  It's just THAT obvious.

Charles wasted more time writing an objection (which actually supported
the contrary opinion) than it would have taken to make the change.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MIAaQB001173; Mon, 22 Aug 2005 11:10:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MIAa5f001172; Mon, 22 Aug 2005 11:10: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 j7MIAZmj001166 for <[e-mail]>; Mon, 22 Aug 2005 11:10:35 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7GiZ-0005E5-9C for [e-mail]; Mon, 22 Aug 2005 20:08:19 +0200
Received: from c-134-88-160.hh.dial.de.ignite.net ([62.134.88.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 20:08:19 +0200
Received: from nobody by c-134-88-160.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 20:08:19 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and syntax - status
Date:  Mon, 22 Aug 2005 20:05:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 13
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <E0D0148C6A5969AC5BD4BCEA@B50854F0A9192E8EC6CDA126> <[e-mail]> <BB0D2769D09AF44EC60C5131@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: c-134-88-160.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:

> but I totally despair of getting any consensus in this group
> within this year on exactly what the format should be.

Plan B, documented "bugs" are "features", we list the critical
IPv6-colon in appendix B.  Dito the possibility of IPs in the
Path as part of diagnostics - formally 1036 wanted "name", if
we list IPs as new "feature" then it appears to be "generous",
and not as arbitrary "restriction".

                      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 j7MHh6KW083936; Mon, 22 Aug 2005 10:43:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MHh62c083934; Mon, 22 Aug 2005 10:43:06 -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 j7MHh4nP083901 for <[e-mail]>; Mon, 22 Aug 2005 10:43:05 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7GHW-0005OT-9G for [e-mail]; Mon, 22 Aug 2005 19:40:22 +0200
Received: from c-134-88-160.hh.dial.de.ignite.net ([62.134.88.160]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 19:40:22 +0200
Received: from nobody by c-134-88-160.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 19:40:22 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Date:  Mon, 22 Aug 2005 19:37:36 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 38
Message-ID:  <[e-mail]>
References:  <990B5932BFDC2E7A45C35B9E@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: c-134-88-160.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>

Richard Clayton wrote:

>| such names MUST be accepted by relaying and serving agents.

Oh, here's the missing part, something talking with "reading
agents" is a "serving agent".  If we keep this terminology
we should explain in 1.5 who's who.  For P-A, F-A, and R-A
there's a summary, "collectively known as UA" (or similar),
we should add 'or "news reader" (the client of news servers)'.

We need a similar summary for I-A, R-A, and S-A: 'also known
as "news server"'.  Maybe in USEPRO instead of USEFOR.  But
Forrest said that we might need another terminology in USEPRO
later, and therefore we should use general terms like UA and
server in USEFOR.

OTOH Russ said we should use the same terms in both texts -
it's impossible to follow both strategies at the same time :-(

My gut feeling, for some time I had serious difficulties to
understand who's who wrt I-A and P-A.  And yesterday I didn't
know the term S-A.  That's a bad sign, the terminology is not
clear.  No good idea how to fix it, but minimally 1.5 should
be complete listing all six agents, defining a "news server"
as the set I-A, R-A, and S-A 

Or we move all these details to USEPRO where talking about the
different agents makes more sense.  Especially F-A vs. P-A is
highly artificial or in other words utter dubious - any piece
of software claiming to be only a P-A but no F-A (or v.v.) is
most probably broken.  The functions are also almost identical,
creating no References at all is a special case of creating
proper References, that's a chapter in USEPRO, not a separate
"followup-agent".  And we don't want something that is _only_
a "posting-agent", if it can't create followups it's wrong.

                         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 j7MHTHXg074855; Mon, 22 Aug 2005 10:29:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MHTHfD074854; Mon, 22 Aug 2005 10:29:17 -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 j7MHTG7P074836 for <[e-mail]>; Mon, 22 Aug 2005 10:29:17 -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 j7MHTDtS020322; Mon, 22 Aug 2005 13:29:13 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7MHTDl1020321; Mon, 22 Aug 2005 13:29:13 -0400 (EDT)
Date: Mon, 22 Aug 2005 13:29:11 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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>

Charles Lindsey <[e-mail]> writes:
> Seth Breidbart <[e-mail]> writes:
>> Construct a tree; nodes are prefixes of peer names.  At a given node,
>> for each character, there's a next node (simple table lookup)...  The
>> processing for each character in the Path is a table lookup, O(1)...
>
> But if the next node says "there are still one or more peers with this
> prefix", then you have to descend to the next level of the tree, and if
> there are N peers, then the depth of the tree will be O(log(N)).

Yes, but that descent is spread over the processing of log(N) characters
in the path, and no matter what algorithm you use, it's going to have to
process the same characters.

Realistically, *no* algorithm can be O(M), where M is the number of
entries in the path, because you can't even divide the path up into
entries in O(M) time.  There is always an O(P) component, where P is the
number of *characters* in the path.  And Seth's algorithm does a constant
amount of work per character to do the complete path check, so it is O(P). 

Seth's tree of tables is, in effect, a DFA regular-expression matcher for
a specialized subset of regular expressions. 

This is about as good as a perfect hash, perhaps better depending on
details of implementation.  The work needed for each character is not
greatly different from that done by a typical hash function.  And the
data structure is less work to build.

                                                          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 j7MGh391045946; Mon, 22 Aug 2005 09:43:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGh3W4045945; Mon, 22 Aug 2005 09:43:03 -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 j7MGh2ta045929 for <[e-mail]>; Mon, 22 Aug 2005 09:43:02 -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 j7MGgwtS019877; Mon, 22 Aug 2005 12:42:58 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7MGgw38019876; Mon, 22 Aug 2005 12:42:58 -0400 (EDT)
Date: Mon, 22 Aug 2005 12:42:57 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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 Mon, 22 Aug 2005, Charles Lindsey wrote:
> >...This application has both the time and the incentive to use an
> >adaptive hashing algorithm that customizes itself to the particular set of
> >data so it can build a collision-free table. 
> 
> ...I would have imagined that if you construct a tailor-made
> algorithm for some set of peers, then that algorithm will be so
> complicated (i.e. consume so many cpu cycles) that you would be better
> off with a simpler algorithm...

Not necessarily.  One technique is to use a fixed basic algorithm
containing some arbitrary constants -- e.g., for each character,
exclusive-or it with K, multiply the current hash value by L, and add the
two together, all done modulo M -- and do a brute-force search for a set
of values for the constants which yields no collisions for the specified
table contents.  The search is expensive, but the resulting hash algorithm
can be simple and fast. 

                                                          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 j7MGWqaE039750; Mon, 22 Aug 2005 09:32:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGWqJv039749; Mon, 22 Aug 2005 09:32:52 -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 j7MGWpQn039733 for <[e-mail]>; Mon, 22 Aug 2005 09:32:51 -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 j7MGWos8016898 for <[e-mail]>; Mon, 22 Aug 2005 09:32:50 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 7B952E7CB5; Mon, 22 Aug 2005 09:32:50 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Mon, 22 Aug 2005 11:06:18 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 22 Aug 2005 09:32:50 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:
> Seth Breidbart <[e-mail]> writes:

>> Construct a tree; nodes are prefixes of peer names.  At a given node,
>> for each character, there's a next node (simple table lookup); the next
>> node might be "ain't gonna find a peer, so go ahead to the next
>> delimiter".  The processing for each character in the Path is a table
>> lookup, O(1).  Constructing the tree is O(total length of peer list).

> But if the next node says "there are still one or more peers with this
> prefix", then you have to descend to the next level of the tree, and if
> there are N peers, then the depth of the tree will be O(log(N)). That
> was what I had in mind when I suggested that, for M path entries and N
> peers, an algorithm O(M * log(N)) should be possible.

It doesn't really matter.  Since you know all of your peers in advance,
you can construct a perfect hash, which is a more general solution.  I
just had this one completely wrong.  It really is O(M) if you do a bit of
one-time data structure setup work up-front.  (You may not care enough to
go to the work to construct a perfect hash, but it's clearly possible.)

>> Putting the Path header on top would save more CPU cycles (to avoid
>> scanning the header list for it) than scanning the Path header for
>> peers takes.

You have to scan the entire article header anyway in order to verify the
syntactical correctness of the article, and it's simple to note the
location of the Path header as you pass it.  Putting it first really
wouldn't save any noticable time in practice.

-- 
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 j7MGKl6F032194; Mon, 22 Aug 2005 09:20:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGKlEt032193; Mon, 22 Aug 2005 09:20:47 -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 j7MGKkT2032177 for <[e-mail]>; Mon, 22 Aug 2005 09:20:46 -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 D39C3596D0 for <[e-mail]>; Mon, 22 Aug 2005 12:20:45 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j7MGKjE08369; Mon, 22 Aug 2005 12:20:45 -0400 (EDT)
Date: Mon, 22 Aug 2005 12:20:45 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: #1047 Path field delimiters and syntax - status
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>

"Charles Lindsey" <[e-mail]> wrote:
> In <[e-mail]> Seth Breidbart <[e-mail]> writes:

>>Construct a tree; nodes are prefixes of peer names.  At a given node,
>>for each character, there's a next node (simple table lookup); the
>>next node might be "ain't gonna find a peer, so go ahead to the next
>>delimiter".   The processing for each character in the Path is a table
>>lookup, O(1).  Constructing the tree is O(total length of peer list).
>
> But if the next node says "there are still one or more peers with this
> prefix", then you have to descend to the next level of the tree,

Yes, by eating one character from the Path header.

> and if
> there are N peers, then the depth of the tree will be O(log(N)).

The depth of the tree is the length of the longest peer name.  But
that doesn't matter; when you see a separator, you start over at the
root.  Otherwise, you descend one node per Path character.

> That was what I had in mind when I suggested that, for M path
> entries and N peers, an algorithm O(M * log(N)) should be possible.

You need to consider name lengths; consider the case of one peer with
a very long name, and a Path with 3 very long entries.

>>Putting the Path header on top would save more CPU cycles (to avoid
>>scanning the header list for it) than scanning the Path header for
>>peers takes.
>
> Currently we do not recommend putting the Path (and variant headers in
> general) at the top. Should we be saying that?

If the time to process the Path header to check for peers is really
significant, then that optimization is noticeable.

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 j7MGGPdc029335; Mon, 22 Aug 2005 09:16:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGPCu029334; Mon, 22 Aug 2005 09:16: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 j7MGGO2i029310 for <[e-mail]>; Mon, 22 Aug 2005 09:16:25 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa57.132a2.3e for [e-mail]; Mon, 22 Aug 2005 17:16:23 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCMn03456 for [e-mail]; Mon, 22 Aug 2005 17:12:22 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22381
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Meta-level thought: Expectations of interworking?
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126>
Date: Mon, 22 Aug 2005 14:28:01 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 <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>I *think* (based on the discussion here) that people expect that 
>USEFOR-conformant UAs and servers will be plugged into the existing USENET 
>without any great disruption - the conformant UAs will see most articles in 
>the existing USENET, the conformant servers will pass most existing 
>articles, and the "old" (non-conformant, but reasonably implemented) 
>servers will pass most or all articles coming from the "new" UAs and 
>servers.

Yes. We seek an orderly transition.


>But I wonder if we should make it explicit, for instance by adding to 
>section 1.2 (or a new section below it it) something like the following:

I think what needs to be said is broadly covered in section 3.2
(Transitional Arrangements) of USEPRO. I think we agreed to leave that in
USEPRO, but that is not to say that its wording might not be improved.


>Based on this, it's an obvious conclusion that Injection-info and 
>Injection-date HAVE to be optional in the format (since otherwise a 
>conformant server would still be conformant if it chose to reject all 
>articles that did not have them).

But there I disagree with you. I do not see a problem if much existing
software becomes technically non-compliant on the day our standard appears
- just provided that care is taken to ensure that the new standard will
still interwork with articles adhering to the previous practice (which we
have been careful to do). That, surely, is what is meant by "backwards
compatibility"?

Yes, I can see that some "MUST accept articles with missing mandatory
Injection-* header fields" wording should perhaps be written, but what I
do NOT want to say is that compliant servers can continue to omit such
headers indefinitely far into the future.

BTW, Injection-Info is currently only "SHOULD generate" as things stand,
and there is no proposal on the table to change that. Injection-Date is
"MUST generate" in USEPRO because there exist circumstances (possibly
rare) where omitting it can cause looping.

[Now you are going to ask why the present network does not exhibit that
problem. The answer is that the meaning of the Date header has changed -
according to RFC 2822, it is now the time of compositon of the article,
not the time of injection).]

-- 
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 j7MGGOtE029317; Mon, 22 Aug 2005 09:16:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGO9B029316; Mon, 22 Aug 2005 09:16: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 j7MGGNTx029290 for <[e-mail]>; Mon, 22 Aug 2005 09:16:24 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa56.132a2.3d for [e-mail]; Mon, 22 Aug 2005 17:16:22 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCFr03418 for [e-mail]; Mon, 22 Aug 2005 17:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22376
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <E0D0148C6A5969AC5BD4BCEA@B50854F0A9192E8EC6CDA126>
Date: Mon, 22 Aug 2005 11:58:32 GMT
Lines: 49
Sender: [e-mail]
Precedence: 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 <E0D0148C6A5969AC5BD4BCEA@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>(politeness off)
No need. What you write is as polite as ever.

>Yes, IP addresses will occur in Path. They already do (v4), and any system 
>that doesn't pass on articles that contain them is so broken that it's got 
>no business passing itself off as an USENET server.

>> You are bolting the
>> stable door after the horse has bolted (so I shall nip it in the bud :-)
>> ). [Sorry, joke might be hard for Norwegians, but Englishmen with a
>> smattering of Irish politics should get it.]

>Your own statistics proved positively that using IP addresses for 
>IDENTIFYING YOUR OWN SYSTEM is a very rare occurence, if it occurs at all; 
>we have no idea why those IP addresses you couldn't divine a purpose of 
>were in the Path: of the articles you looked at.

Agreed, but there is a significant use for diagnostics.

However, having a different syntax for "identification names" and
"diagnostic names" is an additional complication which gives you no extra
benefit (in particular, it does not affect the dead/beef problem, which is
already present on account of the diagnostic usage).

So what is the justification for the restriction? To say there is no
existing usage does not seem sufficient justification to me (though I have
no problem with writing verbiage to discourage its use without good
reason, on the grounds that domain names are much better).

>Saying that giving a name to your system is REQUIRED by the standards is a 
>Good Thing, and allows us to positively refuse to allow such idiocies as 
>using an IP address to identify your server in injection-info.

Why is it an "idiocy"? We are talking about globally routable IP addresses
which are allocated according to a very well defined procedure. So, in
fact, they would actually be safer than "barewords".

-- 
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 j7MGGOCA029297; Mon, 22 Aug 2005 09:16:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGOuU029296; Mon, 22 Aug 2005 09:16: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 j7MGGMn6029272 for <[e-mail]>; Mon, 22 Aug 2005 09:16:23 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa55.132a2.3c for [e-mail]; Mon, 22 Aug 2005 17:16:21 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCEs03410 for [e-mail]; Mon, 22 Aug 2005 17:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22374
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <D33901E32DCA24FFA98D738C@[10.61.81.201]> <[e-mail]>
Date: Mon, 22 Aug 2005 11:35:02 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]> Bruce Lilly <[e-mail]> writes:

>There are several distinct issues involved:
>1. in the time of RFC 1036, there was a "UUCP mapping project" which was
>   intended to provide a uniqueness guarantee for unqualified names.  It
>   failed to provide such a guarantee and no longer exists.  That affects
>   use of unqualified names (no guarantee of uniqueness, such a guarantee
>   being necessary to the proper functioning of the use of the Path field
>   for suppression of redundant retransmissions w/o adversely affecting
>   normal propagation) and keywords (which are indistinguishable from
>   unqualified names).

I believe our view is that the number of problems arising from lack of an
absolute guarantee will be acceptably low. Naturally, use of the keywords
as barewords is a Bad Thing (do we really need explicit deprecation for
something so obvious?).

>2. use of IP address literals, which seems to be of use only for
>   diagnostics.  IPv6 address literals as currently defined in text form
>   are incompatible with long-standing use of ':' as a delimiter,
>   especially in conjunction with use of unqualified names.

Provided use of ':' is limited to IPv6Addresses only, I believe our view
is that the number of problems will be acceptably low (but we need to
point out the danger of using "dead", "beef", etc.).

>3. diagnostics (currently (RFC 1036) no provision).

USEPRO has provision for MISMATCH. I believe we are agreed this should be
extended somewhat (with or without revised syntax).

>4. known security weaknesses in the existing protocol

The weakness is well known (it is even used constructively for some
purposes such as the 'cyberspam' convention). But the weakness will be
largely removed by introduction of the 'POSTED' keyword.

-- 
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 j7MGGNBC029279; Mon, 22 Aug 2005 09:16:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGNcc029278; Mon, 22 Aug 2005 09:16: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 j7MGGLc7029263 for <[e-mail]>; Mon, 22 Aug 2005 09:16:22 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa54.132a2.3b for [e-mail]; Mon, 22 Aug 2005 17:16:20 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCI603436 for [e-mail]; Mon, 22 Aug 2005 17:12:18 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22379
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1080 - Poll about "injection-info"
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <55FCE5290C1A6DE66EE3D5A9@B50854F0A9192E8EC6CDA126>
Date: Mon, 22 Aug 2005 13:56:16 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 <55FCE5290C1A6DE66EE3D5A9@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>1) SHOULD THERE BE SUBSTANTIAL CHANGES TO INJECTION-INFO?
>  1a) No, we should keep approximately the current syntax
>  1b) Yes, we should pick a substantially different solution
>  1c) None of the above

1a

>2) IF SUBSTANTIAL CHANGES ARE MADE, WHAT FORM SHOULD IT BE?
>  2a) Multiple header fields
>  2b) A single header field with a syntax different from
>      the "name=value" syntax

2b

>3) IF THE SYNTAX IS KEPT, HOW SHOULD WE DESCRIBE IT?
>  3a) Keep the current definition; it's good enough.
>  3b) Specify ABNF for a "name=value" list, don't refer to
>      "parameter"
>  3c) Use the "parameter" definition, but add a non-normative
>      description in modern ABNF
>  3d) Use the "parameter", give an ABNF for each parameter
>      value we define, but don't add an overall ABNF
>  3e) Something else

[not 3a, which is definitely erroneous].

3d (assuming it is what I suggested, namely a list of <parameter>s as in
RFC 2045, with an accompanying list of the attribute/value pairs that we
recognize, with ABNF for what goes inside the <value> as needed;
otherwise 3e).

>4) SHOULD THE FIELD ALLOW RFC 2231 CONSTRUCTS?
>  4a) Yes
>  4b) No
>  4c) Something else

4a (possibly with a NOTE to discourage the multiline stuff).

But I might not object to 4b (assuming that means we just use what is in
2045).

But 4b leaves us without any I18N, so one might explicitly choose also to
allow encoded-words within quoted-strings within values (but not with much
hope that user agents would decode them, hence my 1st choice is 4a).

-- 
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 j7MGGMR8029270; Mon, 22 Aug 2005 09:16:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGMEm029269; Mon, 22 Aug 2005 09:16: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 j7MGGKXs029251 for <[e-mail]>; Mon, 22 Aug 2005 09:16:21 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa50.132a2.3a for [e-mail]; Mon, 22 Aug 2005 17:16:16 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCHG03430 for [e-mail]; Mon, 22 Aug 2005 17:12:17 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22378
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <79D5DBCEF80F0747A03033F0@B50854F0A9192E8EC6CDA126>
Date: Mon, 22 Aug 2005 13:35:37 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 <79D5DBCEF80F0747A03033F0@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>--On 16. august 2005 21:31 +0000 Charles Lindsey <[e-mail]> 
>wrote:

>> "Articles must conform to the ABNF specified in RCFC 2822, except insofar
>> as it is superseded/extended/modified by this specification/standard.
>> Observe that the forms permitted by this specification/standard
>> nevertheless remain a strict subset of those permitted by RFC 2822."

>Since there are no extensions or modifications, just restrictions:

I think restrictions are a subset of modifications (i.e. things modified
wrt 2822).

>Articles must conform to the ABNF specified in RFC 2822.
>Articles must also conform to the restrictions specified here, both those 
>that are expressed as text and those that are expressed as ABNF.

Indeed, but since the rewrite of the present bare text is for the purpose
of user friendliness, then I think it is useful to draw attention to the
fact that our articles are a strict subset of 2822 messages.

-- 
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 j7MGGIBa029225; Mon, 22 Aug 2005 09:16:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGIrD029223; Mon, 22 Aug 2005 09:16: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 j7MGGHLE029195 for <[e-mail]>; Mon, 22 Aug 2005 09:16:17 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa50.132a2.39 for [e-mail]; Mon, 22 Aug 2005 17:16:16 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCG803422 for [e-mail]; Mon, 22 Aug 2005 17:12:16 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22377
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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, 22 Aug 2005 13:31:46 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]> Seth Breidbart <[e-mail]> writes:

>Bruce Lilly <[e-mail]> wrote:

>>> All of which is why we removed <comment>s from the Path quite some
>> time ago.
>>
>> "we" didn't remove them.  It was a one-person, non-consensus, unilateral
>> action based on flawed reasoning.

>OK, who put comments _into_ Path?

I was wrong. It is the Control header from which comments were removed
relatively recently. They were removed from Message-ID in 2002, but they
have been absent from Newsgroups, Path and Distribution since at least
article-03 in 2000, which is the earliest draft I have on file.

So it would seem they were never there. Nor were they in Son-of-1036, nor
in 1036 itself, nor has anyone ever seen one in the wild, nor does any
known relaying agent handle 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 j7MGGHpn029211; Mon, 22 Aug 2005 09:16:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGHK0029210; Mon, 22 Aug 2005 09:16: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 j7MGGG57029183 for <[e-mail]>; Mon, 22 Aug 2005 09:16:16 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa4f.132a2.38 for [e-mail]; Mon, 22 Aug 2005 17:16:15 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCFO03414 for [e-mail]; Mon, 22 Aug 2005 17:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22375
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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, 22 Aug 2005 11:44: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]> Richard Clayton <[e-mail]> writes:

>BTW: Usenet is not all that big -- I identified 2556 servers as being
>part of a "peering core" (from my vantage point). The other 8500
>machines were merely feeding into that core.

Interesting figures. The 2556 peering core is much as expected (I would
have guessed somewhat more than that), but the other 8500 feeding sites is
way below (I would have guessed something more like 100,000).

If Usenet really is that small, then persuading the great bulk of servers
to upgrade to our new standard on a shortish timescale becomes almost a
feasible proposition (as opposed to persuading all the user agents, of
which there must be many millions).

-- 
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 j7MGGGiO029192; Mon, 22 Aug 2005 09:16:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGGZi029191; Mon, 22 Aug 2005 09:16: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 j7MGGFtA029175 for <[e-mail]>; Mon, 22 Aug 2005 09:16:16 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa49.132a2.37 for [e-mail]; Mon, 22 Aug 2005 17:16:09 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCJO03441 for [e-mail]; Mon, 22 Aug 2005 17:12:19 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22380
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>
Date: Mon, 22 Aug 2005 14:01:36 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 <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>Charles has suggested that USEFOR be changed to use the terms "server" and 
>"user agent" rather than the current list of "agents" that are more-or-less 
>backported from USEPRO.

>I have not seen any debate on it; I tend to sympathize from the viewpoint 
>of making a simpler and more well-known terminology; on the other hand, 
>it's a bit of work for the editor, and at this hopefully-late stage, it's a 
>big change to digest.

The various sub-categories of agent are useful when it comes to defining
the protocol, but have little impact on just the format of articles.

If people are happy with the general principle, I would be happy to
propose a detailed list of changes to implement 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 j7MGGBIK029126; Mon, 22 Aug 2005 09:16:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGGBfa029125; Mon, 22 Aug 2005 09:16:11 -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 j7MGGAla029097 for <[e-mail]>; Mon, 22 Aug 2005 09:16:10 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-64-157.midband.mdip.bt.net ([81.144.64.157]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309fa49.132a2.36 for [e-mail]; Mon, 22 Aug 2005 17:16:09 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MGCDb03400 for [e-mail]; Mon, 22 Aug 2005 17:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22373
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 22 Aug 2005 11:13:00 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]> Henry Spencer <[e-mail]> writes:

>On Fri, 19 Aug 2005, Charles Lindsey wrote:
>> 
>> It depends on the number of clashes arising from your hash algorithm.

>Zero.  This application has both the time and the incentive to use an
>adaptive hashing algorithm that customizes itself to the particular set of
>data so it can build a collision-free table. 

Yes, I was aware such hashing algorithms existed, but I know nothing about
how they work.

However, I would have imagined that if you construct a tailor-made
algorithm for some set of peers, then that algorithm will be so
complicated (i.e. consume so many cpu cycles) that you would be better
off with a simpler algorithm and accepted the cost of dealing with the
clashes.

-- 
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 j7MGBsfw026499; Mon, 22 Aug 2005 09:11:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGBsLj026498; Mon, 22 Aug 2005 09:11:54 -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 j7MGBrJf026482 for <[e-mail]>; Mon, 22 Aug 2005 09:11:53 -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 120CD9DA9C for <[e-mail]>; Mon, 22 Aug 2005 12:11:53 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j7MGBqx09786; Mon, 22 Aug 2005 12:11:52 -0400 (EDT)
Date: Mon, 22 Aug 2005 12:11:52 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: #1084 Names for ABNF productions - closing
References: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126> <[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>

"Forrest J. Cavalier III" <[e-mail]> wrote:

> USEFOR grabs a whole bunch of production names from RFC2822.  How is
> an implementor supposed to know which ones are different without
> keeping track of a mental list?  It's bad enough there are header
> fields which have more restrictive grammar but the same names.  But
> that cannot be avoided.
>
> We must not ignore that implementors want to adapt RFC2822-compliant
> software to usefor, not write from scratch.  Having ABNF production
> names be different when they are different makes it possible to
> inventory everything that must be reviewed for compliance.

Ideally, ABNF production names that use the same ABNF but have
additional restrictions in the text should be noted some way, for the
same purpose of making it easier to inventory the additional
compliance checks.

I'd suggest some standard way of renaming those productions to
indicate that.

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 j7MG4uZN022025; Mon, 22 Aug 2005 09:04:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MG4u7b022024; Mon, 22 Aug 2005 09:04:56 -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 j7MG4t3H022007 for <[e-mail]>; Mon, 22 Aug 2005 09:04: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 j7MG4rtS019163; Mon, 22 Aug 2005 12:04:53 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7MG4rRE019162; Mon, 22 Aug 2005 12:04:53 -0400 (EDT)
Date: Mon, 22 Aug 2005 12:04:52 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: Meta-level thought: Expectations of interworking?
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 Mon, 22 Aug 2005, Frank Ellermann wrote:
> > But the WG may want something else....
> 
> ...not me, I like your explicit statement about the design goals...

I go along with Frank on this one:  the wording may perhaps need some
touchup, but having an explicit statement about this is a good idea. 

                                                          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 j7MG2d0p020627; Mon, 22 Aug 2005 09:02:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MG2d6w020626; Mon, 22 Aug 2005 09:02: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 j7MG2cFU020611 for <[e-mail]>; Mon, 22 Aug 2005 09:02:38 -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 j7MG2ZtS019144; Mon, 22 Aug 2005 12:02:35 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7MG2ZXS019143; Mon, 22 Aug 2005 12:02:35 -0400 (EDT)
Date: Mon, 22 Aug 2005 12:02:33 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: merit (was Re: #1084 Names for ABNF productions - closing)
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 Mon, 22 Aug 2005, Forrest J. Cavalier III wrote:
> Changes should be accepted or rejected on their merits, not how many
> people advocate them.

"Merits" as determined how, exactly?

Very occasionally a change is an obvious non-starter -- internally
contradictory or otherwise ridiculous.  But in almost all other cases, its
"merits" are a judgement call -- a matter of opinion -- and the only way
to assess them is to see what the WG members think.

Calling for something to be assessed "on its merits" tends to be a code
phrase for "obviously I'm right and you're wrong, so we should do it my way".

                                                          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 j7MDdK7D018199; Mon, 22 Aug 2005 06:39:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MDdK6r018196; Mon, 22 Aug 2005 06:39:20 -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 j7MDdJpC018172 for <[e-mail]>; Mon, 22 Aug 2005 06:39:19 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.16.2.131] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 22 Aug 2005 14:39:13 +0100
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 14:39:12 +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
To: "Forrest J. Cavalier III" <[e-mail]>
CC: [e-mail]
Subject: Re: #1084 Names for ABNF productions - closing
References: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
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>

Forrest J. Cavalier III wrote:

> Harald Tveit Alvestrand wrote:
>
>> I found no consensus for change - one loud voice (Bruce) and a lot of 
>> comments indicating that they did not see a big difference (meaning 
>> that Bruce did not convince them) does not make a consensus.
>>
>> So unless there are other people arguing strongly for changing the 
>> ABNF production names from "msg-id", "subject", "comments" and so on 
>> to "news-msg-id", "news-subject", "news-comments" and so on, I'll 
>> declare this ticket closed.
>
> [...]
> We must not ignore that implementors want to adapt RFC2822-compliant
> software to usefor, not write from scratch.  Having ABNF production names
> be different when they are different makes it possible to inventory
> everything that must be reviewed for compliance.

Having an explicit list of changed ABNF productions addresses this as 
well. I don't see much difference between the two approaches, but 
renaming productions might introduce errors in the document, IMHO.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MDOGwg004818; Mon, 22 Aug 2005 06:24:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MDOGDu004817; Mon, 22 Aug 2005 06:24: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 j7MDOGGX004793 for <[e-mail]>; Mon, 22 Aug 2005 06:24:16 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51F8532007B; Mon, 22 Aug 2005 15:24:03 +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 22041-10; Mon, 22 Aug 2005 15:23:58 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EE2132008A; Mon, 22 Aug 2005 15:23:53 +0200 (CEST)
Date: Mon, 22 Aug 2005 06:14:37 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: "Forrest J. Cavalier III" <[e-mail]>, [e-mail]
Subject: ADMIN: About consensus and merit (Re: #1084 Names for ABNF productions - closing)
Message-ID: <5C1E33A9375B5A0E0721251D@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 I want to reply to the point about accepting 
ideas on merit:

--On 22. august 2005 06:36 -0400 "Forrest J. Cavalier III" 
<[e-mail]> wrote:

>
> Harald Tveit Alvestrand wrote:
>> I found no consensus for change - one loud voice (Bruce) and a lot of
>> comments indicating that they did not see a big difference (meaning that
>> Bruce did not convince them) does not make a consensus.
>>
>> So unless there are other people arguing strongly for changing the ABNF
>> production names from "msg-id", "subject", "comments" and so on to
>> "news-msg-id", "news-subject", "news-comments" and so on, I'll declare
>> this  ticket closed.
>>
>
> Changes should be accepted or rejected on their merits, not how many
> people advocate them.  Maybe you are suggesting we post "Me too" for
> every post we agree with?

Sometimes that's appropriate. Mostly it's not. In this case, I was 
explicitly trying to find if there were anyone who wanted to send "me too" 
posts, and got one so far (yours).

Remember - the chairs have been reviled a number of times for allowing 
stuff to get into the documents that only one person agrees with. Rejecting 
ideas that fail to convince other people is one tool to use when 
"evaluating on merit"; if I did not consider what other people think, I'd 
be arbitrating based on my personal taste.

You can't have it both ways.

                  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 j7MDOCRF004728; Mon, 22 Aug 2005 06:24:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MDOCWI004726; Mon, 22 Aug 2005 06:24:12 -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 j7MDOAJs004689 for <[e-mail]>; Mon, 22 Aug 2005 06:24:11 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D636032008F; Mon, 22 Aug 2005 15:23: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 22041-09; Mon, 22 Aug 2005 15:23:52 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 455F832008E; Mon, 22 Aug 2005 15:23:51 +0200 (CEST)
Date: Mon, 22 Aug 2005 06:09:45 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <BB0D2769D09AF44EC60C5131@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>	 <[e-mail]> <E0D0148C6A5969AC5BD4BCEA@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 22. august 2005 07:02 +0200 Frank Ellermann <[e-mail]> 
wrote:

>> IP addresses will occur in Path. They already do (v4), and
>> any system that doesn't pass on articles that contain them
>> is so broken that it's got no business passing itself off
>> as an USENET server.
>
> In other words, you propose to drop ideas where we'd protect
> those servers with ugly tricks like "add dot plus keyword to
> the IP, and if it's IPv6 replace colon by underscore".

Actually I kind of like the idea of those tricks (festooning the bare IP 
address with stuff before or after to show exactly what we think of it), 
but I totally despair of getting any consensus in this group within this 
year on exactly what the format should be.

So saying "don't blow up if you see strange stuff, just assume it's a 
diagnostic and get on with life" is, to my mind, a fine thing to say in 
USEFOR.

                 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 j7MDOCHb004732; Mon, 22 Aug 2005 06:24:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MDOCd5004731; Mon, 22 Aug 2005 06:24:12 -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 j7MDOBkw004696 for <[e-mail]>; Mon, 22 Aug 2005 06:24:11 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5825632008E; Mon, 22 Aug 2005 15:23: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 22186-08; Mon, 22 Aug 2005 15:23:51 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E43632007B; Mon, 22 Aug 2005 15:23:48 +0200 (CEST)
Date: Mon, 22 Aug 2005 06:03:48 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: "Forrest J. Cavalier III" <[e-mail]>, [e-mail]
Subject: Re: #1084 Names for ABNF productions - closing
Message-ID: <E9ADB21C23FB115DEEB16455@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 22. august 2005 06:36 -0400 "Forrest J. Cavalier III" 
<[e-mail]> wrote:

> USEFOR grabs a whole bunch of production names from RFC2822.  How is
> an implementor supposed to know which ones are different without
> keeping track of a mental list?

All of the ones that appear on the left hand side of a production are 
different. That's a rather simple rule.....



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MDO6hD004625; Mon, 22 Aug 2005 06:24:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MDO6ae004618; Mon, 22 Aug 2005 06:24:06 -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 j7MDO4sl004594 for <[e-mail]>; Mon, 22 Aug 2005 06:24:05 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26A4032008F; Mon, 22 Aug 2005 15:23: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 22041-08; Mon, 22 Aug 2005 15:23:47 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62F7F32008D; Mon, 22 Aug 2005 15:23:45 +0200 (CEST)
Date: Mon, 22 Aug 2005 06:00:42 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Meta-level thought: Expectations of interworking?
Message-ID: <D931AF577ED000AD5C375592@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 22. august 2005 08:35 +0200 Frank Ellermann <[e-mail]> 
wrote:

> Harald Tveit Alvestrand wrote:
>
>> But the WG may want something else....
>
> ...not me, I like your explicit statement about the design
> goals.  "2004-vintage" sounds odd, and "vintage 2004" can't
> be much better, how about "legacy" ?  And maybe a pointer
> to appendix B (differences from 1036).

I started writing "current" rather than "2004-vintage", but then thought of 
how that statement will look to a reader in 2010.....

A pointer to appendix B is a good idea.







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MDO1kb004543; Mon, 22 Aug 2005 06:24:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MDO15Q004541; Mon, 22 Aug 2005 06:24: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 j7MDO0OW004511 for <[e-mail]>; Mon, 22 Aug 2005 06:24:01 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0FD8132008A; Mon, 22 Aug 2005 15:23:47 +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 22041-07; Mon, 22 Aug 2005 15:23:42 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C44E832007B; Mon, 22 Aug 2005 15:23:41 +0200 (CEST)
Date: Mon, 22 Aug 2005 05:52:57 -0700
From: Harald Tveit Alvestrand <[e-mail]>
To: Richard Clayton <[e-mail]>
Cc: [e-mail]
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Message-ID: <A27064914EE3CCCB6A3C3153@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 22. august 2005 11:25 +0100 Richard Clayton <[e-mail]> 
wrote:

> I have a feeling that changing the terms will make much more of a meal
> of a paragraph such as this one:
>
>    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 header fields or in newgroup control
>    messages [USEPRO]).  However, such names MUST be accepted by relaying
>    and serving agents.
>
> which is at least reasonably concise at present!
>
> BTW: Mind you, now I look at it, I have a question about this paragraph,
> does this mean that it is currently proper for an injection agent to
> generate an underline? and that a followup agent can fail to accept it ?
> Why not say what I suspect is intended "However, such names MUST be
> accepted by all agents."

it would, I think, change to

   Components beginning with underline ("_") are reserved for use by
   future versions of this standard and MUST NOT be generated by user
   agents (whether in Newsgroups header fields or in newgroup control
   messages [USEPRO]).  However, such names MUST be accepted by servers.

Which would answer your questions......







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MBQArm001289; Mon, 22 Aug 2005 04:26:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MBQAkw001286; Mon, 22 Aug 2005 04:26:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from soy.epix.net (soy.epix.net [199.224.64.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MBQ9iH001267 for <[e-mail]>; Mon, 22 Aug 2005 04:26:09 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by soy.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MBQ775006507 for <[e-mail]>; Mon, 22 Aug 2005 07:26:08 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 07:26:14 -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: Meta-level thought: Expectations of interworking?
References: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126>
In-Reply-To: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126>
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>

Harald Tveit Alvestrand wrote:

> Based on this, it's an obvious conclusion that Injection-info and 
> Injection-date HAVE to be optional in the format (since otherwise a 
> conformant server would still be conformant if it chose to reject all 
> articles that did not have them).

USEPRO says that an injecting agent MUST REMOVE the Injection-Info header field
for re-injection, (which is a really bad idea to bless.)  It means that a reader
cannot look at the header field and determine anything about the origin of an article
with certainty.  That makes Injection-Info easy to construct, but basically
unreliable information at the Reader end.

I think this is a part of USEPRO that needs major work.  Since we can't discuss
USEPRO right now, we can't know the final purpose of Injection-Info.  Without knowing
the purpose, how can we have any opinions on syntax, except legalistic ones about
whether encoded words are allowed in comments?  (Not that the legalistic concerns
are unfruitful.  They can be used to eliminate a lot of poll choices.)

Since Complaints-To is an injection info parameter since USEFOR-03 (which
was a bad idea I think) it will have some kind of complaints-to indication
to enable automatic generating of complaints (which is a another BAD thing,
in my opinion, so I would recommend to any admin to avoid its use.)  Since
UAs don't support Injection-Info initially, it should be human-parseable so
someone can dig through it to find the complaints contact information that
they used to easily find in an X- header, (in case they decide that emailing
[e-mail] and [e-mail] and abuse@tld for every path-identity
wasn't good enough.)

As for the other parts of Injection-Info, it is my understanding that the
sub-fields are going to be used as inputs to automatic spam detectors.

I'd say spam detection is hardly interoperability.  There are way too many
"non-spam" (I would not say "legitimate", since it mostly is copyrighted
content) multi-part posters on fast connections that exceed any
reasonable posts-per-unit-time threshold triggers.  So I doubt that it
gets used much.  When people were on dialup and not posting gigabytes of
CDs and DVDs, it might have made some sense.  That isn't now.

So, all in all, there are no interworking concerns on Injection-Info.
It might as well be unstructured.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MBGl96093095; Mon, 22 Aug 2005 04:16:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MBGl3A093093; Mon, 22 Aug 2005 04:16: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 j7MBGk89093064 for <[e-mail]>; Mon, 22 Aug 2005 04:16:47 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-68-161.midband.mdip.bt.net ([81.144.68.161]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4309b41a.169d9.4e for [e-mail]; Mon, 22 Aug 2005 12:16:42 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7MBCC401589 for [e-mail]; Mon, 22 Aug 2005 12:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22372
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 22 Aug 2005 11:06:18 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]> Seth Breidbart <[e-mail]> writes:

>Construct a tree; nodes are prefixes of peer names.  At a given node,
>for each character, there's a next node (simple table lookup); the
>next node might be "ain't gonna find a peer, so go ahead to the next
>delimiter".   The processing for each character in the Path is a table
>lookup, O(1).  Constructing the tree is O(total length of peer list).

But if the next node says "there are still one or more peers with this
prefix", then you have to descend to the next level of the tree, and if
there are N peers, then the depth of the tree will be O(log(N)). That was
what I had in mind when I suggested that, for M path entries and N peers,
an algorithm O(M * log(N)) should be possible.


>Putting the Path header on top would save more CPU cycles (to avoid
>scanning the header list for it) than scanning the Path header for
>peers takes.

Currently we do not recommend putting the Path (and variant headers in
general) at the top. Should we be saying 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 j7MAvH0J075674; Mon, 22 Aug 2005 03:57:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MAvHvL075672; Mon, 22 Aug 2005 03:57: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 j7MAvGrK075646 for <[e-mail]>; Mon, 22 Aug 2005 03:57:16 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MAv7sv012489; Mon, 22 Aug 2005 06:57:12 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 06:57:13 -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]
CC: Harald Tveit Alvestrand <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
References: <[e-mail]> <[e-mail]> <D33901E32DCA24FFA98D738C@[10.61.81.201]> <[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>

Bruce Lilly wrote:
> Providing diagnostics in the Path field is going to cause some degree of
> interoperability problems no matter what.  We need to decide whether or
> not any putative benefit of such diagnostics outweighs the interoperability
> problems.

This statement is not technically true.  I agree that diagnostics in Path
AS CURRENTLY DRAFTED causes some degree of interoperability problems.
Comments in path is disastrous for interoperability.

But "!.", ".." and "!!" are sequences which can be used without
interoperability problems and never appear now.

That allows things like:

     !badhost.com..MISMATCH

And even

      !.reservedkeyword.path-identity
such as

    !.v6.dead_beef

or
    !..Unreserved extension keyword.path-identity

And there will be no interoperability problems.








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MAgeM4062899; Mon, 22 Aug 2005 03:42:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MAgex0062898; Mon, 22 Aug 2005 03:42:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from soy.epix.net (soy.epix.net [199.224.64.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MAgdEO062879 for <[e-mail]>; Mon, 22 Aug 2005 03:42:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by soy.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MAgZ75000138; Mon, 22 Aug 2005 06:42:36 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 06:42:41 -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]>
CC: [e-mail]
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
References: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>
In-Reply-To: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>
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>

Harald Tveit Alvestrand wrote:

> Charles has suggested that USEFOR be changed to use the terms "server" and 
> "user agent" rather than the current list of "agents" that are more-or-less 
> backported from USEPRO.
> 
> I have not seen any debate on it; I tend to sympathize from the viewpoint 
> of making a simpler and more well-known terminology; on the other hand, 
> it's a bit of work for the editor, and at this hopefully-late stage, it's a 
> big change to digest.
> 
> Do people have any thought on this subject?

Yes.

All the different agent designations in USEPRO are mostly artificial,
arbitrary, and unnecessary.  Real-world software does not fit clearly in any
one category, and performs multiple agent roles.

USEPRO would be a lot clearer if it dismissed with all the language of "Duty"
and used definitions of cause and effect.

Since USEPRO is not finished, and USEPRO changes have been declared
unacceptable topics for discussion, it is a mistake to make USEFOR
confusing in order to be consistent with an unfinished document that we
all know needs substantial revision.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MAak5q057694; Mon, 22 Aug 2005 03:36:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MAakeQ057693; Mon, 22 Aug 2005 03:36:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from soy.epix.net (soy.epix.net [199.224.64.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MAajqC057672 for <[e-mail]>; Mon, 22 Aug 2005 03:36:46 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-229-226-pppoe.dsl.hrbg.epix.net [216.37.229.226]) by soy.epix.net (8.12.10/2004120601/PL) with ESMTP id j7MAab75029312 for <[e-mail]>; Mon, 22 Aug 2005 06:36:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 06:36:43 -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: #1084 Names for ABNF productions - closing
References: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126>
In-Reply-To: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126>
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>

Harald Tveit Alvestrand wrote:
> I found no consensus for change - one loud voice (Bruce) and a lot of 
> comments indicating that they did not see a big difference (meaning that 
> Bruce did not convince them) does not make a consensus.
> 
> So unless there are other people arguing strongly for changing the ABNF 
> production names from "msg-id", "subject", "comments" and so on to 
> "news-msg-id", "news-subject", "news-comments" and so on, I'll declare this 
> ticket closed.
> 

Changes should be accepted or rejected on their merits, not how many
people advocate them.  Maybe you are suggesting we post "Me too" for
every post we agree with?

I am with Bruce.  The change is simple and adds clarity and makes
the job of auditing software for compliance easier.

USEFOR grabs a whole bunch of production names from RFC2822.  How is
an implementor supposed to know which ones are different without
keeping track of a mental list?  It's bad enough there are header fields
which have more restrictive grammar but the same names.  But that
cannot be avoided.

We must not ignore that implementors want to adapt RFC2822-compliant
software to usefor, not write from scratch.  Having ABNF production names
be different when they are different makes it possible to inventory
everything that must be reviewed for compliance.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MAWfEu054036; Mon, 22 Aug 2005 03:32:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MAWfr0054035; Mon, 22 Aug 2005 03:32:41 -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 j7MAWe0T054006 for <[e-mail]>; Mon, 22 Aug 2005 03:32:40 -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 1E79am-0003Ek-29; Mon, 22 Aug 2005 10:31:58 +0000
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 11:25:39 +0100
To: Harald Tveit Alvestrand <[e-mail]>
Cc: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
References: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>
In-Reply-To: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <HW4$+PqP77P6COKLKOV+dOUw+N>
Sender: [e-mail]
Precedence: 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 <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <[e-mail]> writes
>
>Charles has suggested that USEFOR be changed to use the terms "server" and 
>"user agent" rather than the current list of "agents" that are more-or-less 
>backported from USEPRO.
>
>I have not seen any debate on it; I tend to sympathize from the viewpoint 
>of making a simpler and more well-known terminology; on the other hand, 
>it's a bit of work for the editor, and at this hopefully-late stage, it's a 
>big change to digest.
>
>Do people have any thought on this subject?

since different agents are permitted to do different things there is
value in giving them different names, especially when these names are
used in other documents as well...

I have a feeling that changing the terms will make much more of a meal
of a paragraph such as this one:

   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 header fields or in newgroup control
   messages [USEPRO]).  However, such names MUST be accepted by relaying
   and serving agents.

which is at least reasonably concise at present!

BTW: Mind you, now I look at it, I have a question about this paragraph,
does this mean that it is currently proper for an injection agent to
generate an underline? and that a followup agent can fail to accept it ?
Why not say what I suspect is intended "However, such names MUST be
accepted by all agents."

- -=-=-=-=-

If we keep the names (and I think we should) then some tidying up of
definitions and usage is called for.

Looking at the definitions in #1.5, these would benefit from being
presented in a better order, the "message identifier" definition refers
forward to a term not yet defined.

Also there are no definitions for "serving agent" or "relaying agent"

Also, in the rest of the document for generic terms for all of the
entities I find "agent" "news agent" and "netnews agent". I would
suggest just "agent" would suffice.

I'd also suggest hyphenating the terms (ie: "posting-agent" etc) because
this makes it far more clear when you meet sentences that say

   ... new agent ...

that the agent is merely meant to be a novel one :) and it isn't a typo

- -- 
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/AwUBQwmoI5oAxkTY1oPiEQI5kwCfRpXeWx6Eh/fx8pkCwi5nJkZDXJ4AoIbd
1go54BDmptvF1bHjkviMcuAv
=6E3A
-----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 j7M7JoBu096641; Mon, 22 Aug 2005 00:19:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M7JoBh096640; Mon, 22 Aug 2005 00:19:50 -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 j7M7Jm56096608 for <[e-mail]>; Mon, 22 Aug 2005 00:19:49 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E76YT-0005wz-FW for [e-mail]; Mon, 22 Aug 2005 09:17:13 +0200
Received: from c-134-88-204.hh.dial.de.ignite.net ([62.134.88.204]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 09:17:13 +0200
Received: from nobody by c-134-88-204.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 09:17:13 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 - Poll about "injection-info"
Date:  Mon, 22 Aug 2005 09:14:52 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Message-ID:  <[e-mail]>
References:  <55FCE5290C1A6DE66EE3D5A9@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: c-134-88-204.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:

> 1b

With an option to return to what we have (1A) if some
unforeseen major obstacles show up.

> 2b

With an option to extract some Complaints-To (that's
not an unforeseen major obstacle, it's a known issue)
  
> 3

Pass.

> 4c

The 2231 part about language tags in encoded words is okay.
The parameter stuff is a headache (see also ticket #1046).

                       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 j7M6bs13056728; Sun, 21 Aug 2005 23:37:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M6bs9D056727; Sun, 21 Aug 2005 23:37: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 j7M6bq18056698 for <[e-mail]>; Sun, 21 Aug 2005 23:37:53 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E75vG-0005q7-8O for [e-mail]; Mon, 22 Aug 2005 08:36:42 +0200
Received: from c-134-88-204.hh.dial.de.ignite.net ([62.134.88.204]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 08:36:42 +0200
Received: from nobody by c-134-88-204.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 08:36:42 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Meta-level thought: Expectations of interworking?
Date:  Mon, 22 Aug 2005 08:35:04 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Message-ID:  <[e-mail]>
References:  <AB9781E26765F8AE1222F6C2@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: c-134-88-204.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:

> But the WG may want something else....

...not me, I like your explicit statement about the design
goals.  "2004-vintage" sounds odd, and "vintage 2004" can't
be much better, how about "legacy" ?  And maybe a pointer
to appendix B (differences from 1036).

                           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 j7M6Nl1Q043712; Sun, 21 Aug 2005 23:23:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M6NlI2043711; Sun, 21 Aug 2005 23:23:47 -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 j7M6Njd3043675 for <[e-mail]>; Sun, 21 Aug 2005 23:23:46 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E75hR-0003C5-Js for [e-mail]; Mon, 22 Aug 2005 08:22:25 +0200
Received: from c-134-88-204.hh.dial.de.ignite.net ([62.134.88.204]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 08:22:25 +0200
Received: from nobody by c-134-88-204.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 08:22:25 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1102 Suggestion to use "server" and "UA" in USEFOR
Date:  Mon, 22 Aug 2005 08:19:18 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 37
Message-ID:  <[e-mail]>
References:  <990B5932BFDC2E7A45C35B9E@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: c-134-88-204.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:

>> Do people have any thought on this subject?

I'd like "news server" but...

> I find the long list of agents confusing, but I would find
> switching between one set of terminology in the format
> document to a different set of terminology in the protocol
> document even more confusing.

...that makes sense, unfortunately.  We now have this clumsy
"header field" etc. terminology, keeping the various "agents"
is at least the same correct style, whether I like it or not.

> we should probably live with the complexity.

There's a note in 1.5:

   Posting, reading and followup agents (which are usually just
   different services provided by the same piece of software)
   are known collectively as "user agents".

Let's say:
                             "user agents" or "news reader"
  (the client of a news server, see below).

The next paragraph in 1.5 defines the "injection agent" using
the (undefined but obvious) term relaying agent.  We could add:

  Combinations of injection and relaying agents are also known
  as "news server".

Or similar, less DEnglish if possible.  Strange, we have so
many agents, but not one of them offers to _get_ articles ;-)
Who talks with a "reading agent" ?  No serious question, 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 j7M5qvmK014426; Sun, 21 Aug 2005 22:52:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M5qvVm014424; Sun, 21 Aug 2005 22:52: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 j7M5qund014385 for <[e-mail]>; Sun, 21 Aug 2005 22:52:56 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E75Dv-0006e6-B8 for [e-mail]; Mon, 22 Aug 2005 07:51:55 +0200
Received: from c-134-88-204.hh.dial.de.ignite.net ([62.134.88.204]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 07:51:55 +0200
Received: from nobody by c-134-88-204.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 07:51:55 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1053 Relationship to RFC 2822 - suggestion
Date:  Mon, 22 Aug 2005 07:50:17 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
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-134-88-204.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:

> I merely want to point out (in parenthesis or a NOTE) that
> it is not actually an "obsolete" feature in RFC 2822

There is already a note about this in 2822, I see no reason
to copy this to USEFOR, we're interested in the differences
from 1036 and 2822, not identical stuff.

> might even become "MAY generate" at some future date

Maybe not.  IMHO it's an utter dubious "feature", not much
better than bare CR, bare LF, NUL, or NO-WS-CTL.  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 j7M5bt7o099375; Sun, 21 Aug 2005 22:37:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M5btk3099374; Sun, 21 Aug 2005 22:37: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 j7M5brAM099353 for <[e-mail]>; Sun, 21 Aug 2005 22:37:54 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E7505-0004Oq-1U for [e-mail]; Mon, 22 Aug 2005 07:37:37 +0200
Received: from c-134-88-204.hh.dial.de.ignite.net ([62.134.88.204]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 07:37:37 +0200
Received: from nobody by c-134-88-204.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 07:37:37 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1053 Relationship to RFC 2822 - suggestion
Date:  Mon, 22 Aug 2005 07:34:40 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
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-134-88-204.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:

> Please reread RFC 2822 section 3.6.4, in particular:

That doesn't talk about mailing lists doing odd and different
things to a mail - they arrive in different forms with the
same Message-ID, and for a gateway there's no reliable way
to determine the "original" form without manual configuration
of the "particular mailing list oddity".  And sometimes these
oddities depend on text/* vs. multipart/*, it's messy.

For a gateway operator the 2822 ideals are pure fantasies :-(

>| subsequent revisions to the message each receive new
>| message identifiers.

Mailing lists mangling the bodies and consequently using new
Message-IDs would be a nightmare.  It's bad enough as it is.

>> That roadmap is _ready_ for the <msg-id>, you find (a
>> variant of) it in the Usefor draft.  2822bis will copy it
>> as is for its future "chapter 3", moving NO-WS-CTL and other
>> creatures to its future obs-chapter where they can die.
 
> Do you have evidence to support that claim, or is it wishful
> thinking?

No, I consulted my crystal ball.  You also try this sometimes,
when you have certain ideas what will or will not (future) pass
"IESG muster".
                            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 j7M5Aqhg073217; Sun, 21 Aug 2005 22:10:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M5Aqrx073213; Sun, 21 Aug 2005 22:10:52 -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 j7M5Ao9E073164 for <[e-mail]>; Sun, 21 Aug 2005 22:10:50 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E74XB-0006tg-NG for [e-mail]; Mon, 22 Aug 2005 07:07:50 +0200
Received: from c-134-88-204.hh.dial.de.ignite.net ([62.134.88.204]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 07:07:44 +0200
Received: from nobody by c-134-88-204.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 22 Aug 2005 07:07:44 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and syntax - status
Date:  Mon, 22 Aug 2005 07:02:09 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 31
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <E0D0148C6A5969AC5BD4BCEA@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: c-134-88-204.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:

> IP addresses will occur in Path. They already do (v4), and
> any system that doesn't pass on articles that contain them
> is so broken that it's got no business passing itself off
> as an USENET server.

In other words, you propose to drop ideas where we'd protect
those servers with ugly tricks like "add dot plus keyword to
the IP, and if it's IPv6 replace colon by underscore".

And systems styling themselves as "dead", "beef", or similar
should discuss this issue with their peers, and better stay
away from any "B news" systems.  I can certainly live with
this solution.

> Saying that giving a name to your system is REQUIRED by the
> standards is a Good Thing, and allows us to positively
> refuse to allow such idiocies as using an IP address to
> identify your server in injection-info.

Also fine from my POV, my unnamed "Web cam in trouble" example
might wish to post, but it's no news server / injection agent.

> That horse has not yet escaped

s-o-1036 says "name", either FQDN or name.  No IP, no problem
(eyes wide shut, so I didn't see "case sensitive", shudder ;-)

1036 also says "name".  So that part should work, 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 j7LJfZo1044941; Sun, 21 Aug 2005 12:41:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJfZu9044940; Sun, 21 Aug 2005 12:41:35 -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 j7LJfYu9044919 for <[e-mail]>; Sun, 21 Aug 2005 12:41:34 -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 8F113595B4 for <[e-mail]>; Sun, 21 Aug 2005 15:41:33 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j7LJfXQ15442; Sun, 21 Aug 2005 15:41:33 -0400 (EDT)
Date: Sun, 21 Aug 2005 15:41:33 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Bruce Lilly on Sun, 21 Aug 2005 11:45:38 -0400)
Subject: Re: #1047 Path field delimiters and syntax - status
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>

Bruce Lilly <[e-mail]> wrote:

> Note that there are any number of ways to do so which do not require
> parsing the Path field more than once, or other than left-to-right,
> at any given server.  It necessarily means comparing M non-comment,
> non- diagnostic, non-keyword, non-bogus path entries to N peer names
> (although clearly the tests can be short-circuited once a match for
> a specific peer is found). For an article with M valid path entries
> and at a site with N peers, none of which are listed in the path
> field, that is a minimum complexity of O(N*M).

We just had that discussion.  It's O(N+M), where M is the length of
the Path header and N is the sum of the lengths of the peer names.

"I can't think of a faster way" does not imply "minimum complexity";
complexity theory is non-trivial.

> 1. skipping from '(' to the matching unquoted ')' is outside of the
>   loop; it is one-time field parsing and none of the skipped content
>   is checked against any peer names.  Nor does it affect the number
>   of non-comment entries to be checked.

If there's a simple (O(1)) way to determine what is or isn't part of a
comment as you read the Path header, then the overall complexity is
still O(N+M).  (Note that this doesn't imply that "commentness" is a
regular expression, deterministic context-free is good enough, so
nested comments aren't a problem.)

>> All of which is why we removed <comment>s from the Path quite some
> time ago.
>
> "we" didn't remove them.  It was a one-person, non-consensus, unilateral
> action based on flawed reasoning.

OK, who put comments _into_ Path?

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 j7LJZg66042928; Sun, 21 Aug 2005 12:35:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJZgqS042927; Sun, 21 Aug 2005 12:35:42 -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 j7LJZf8K042921 for <[e-mail]>; Sun, 21 Aug 2005 12:35:41 -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 j7LJZeBl032069 for <[e-mail]>; Sun, 21 Aug 2005 12:35:40 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 362B8E7CB5; Sun, 21 Aug 2005 12:35:40 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1102 Suggestion to use "server" and "UA" in USEFOR
In-Reply-To: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126> (Harald Tveit Alvestrand's message of "Sun, 21 Aug 2005 20:41:05 +0200")
Organization: The Eyrie
References: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>
Date: Sun, 21 Aug 2005 12:35:40 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> Charles has suggested that USEFOR be changed to use the terms "server" and 
> "user agent" rather than the current list of "agents" that are more-or-less 
> backported from USEPRO.

> I have not seen any debate on it; I tend to sympathize from the viewpoint 
> of making a simpler and more well-known terminology; on the other hand, 
> it's a bit of work for the editor, and at this hopefully-late stage, it's a 
> big change to digest.

> Do people have any thought on this subject?

I find the long list of agents confusing, but I would find switching
between one set of terminology in the format document to a different set
of terminology in the protocol document even more confusing.

If we're going to change the format document, we should change USEPRO as
well.  If we're not going to change USEPRO, we should probably live with
the complexity.

-- 
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 j7LJQg9W042122; Sun, 21 Aug 2005 12:26:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJQg8r042121; Sun, 21 Aug 2005 12:26: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 j7LJQfuJ042115 for <[e-mail]>; Sun, 21 Aug 2005 12:26:41 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D924A320084 for <[e-mail]>; Sun, 21 Aug 2005 21:26: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 24207-09 for <[e-mail]>; Sun, 21 Aug 2005 21:26:26 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A802232007B for <[e-mail]>; Sun, 21 Aug 2005 21:26:20 +0200 (CEST)
Date: Sun, 21 Aug 2005 21:09:37 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1084 Names for ABNF productions - closing
Message-ID: <263D25DDA34B1EB4DF1A88D9@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 found no consensus for change - one loud voice (Bruce) and a lot of 
comments indicating that they did not see a big difference (meaning that 
Bruce did not convince them) does not make a consensus.

So unless there are other people arguing strongly for changing the ABNF 
production names from "msg-id", "subject", "comments" and so on to 
"news-msg-id", "news-subject", "news-comments" and so on, I'll declare this 
ticket closed.

                            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 j7LJQase042112; Sun, 21 Aug 2005 12:26:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJQaN6042111; Sun, 21 Aug 2005 12:26:36 -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 j7LJQZ1m042105 for <[e-mail]>; Sun, 21 Aug 2005 12:26:36 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC341320089 for <[e-mail]>; Sun, 21 Aug 2005 21:26:23 +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 24207-08 for <[e-mail]>; Sun, 21 Aug 2005 21:26:17 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F2EBF320084 for <[e-mail]>; Sun, 21 Aug 2005 21:26:12 +0200 (CEST)
Date: Sun, 21 Aug 2005 20:57:35 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Meta-level thought: Expectations of interworking?
Message-ID: <AB9781E26765F8AE1222F6C2@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 debate about ticket #1088 (whether or not injection-info should be 
optional) leads me to think that we could benefit from a better definition 
of what we expect to happen when this standard is fielded.....

I *think* (based on the discussion here) that people expect that 
USEFOR-conformant UAs and servers will be plugged into the existing USENET 
without any great disruption - the conformant UAs will see most articles in 
the existing USENET, the conformant servers will pass most existing 
articles, and the "old" (non-conformant, but reasonably implemented) 
servers will pass most or all articles coming from the "new" UAs and 
servers.

We certainly envision some non-interworking happening; we have explicitly 
decided that it's permitted for a server to not accept an article that uses 
EST in its "timezone" field, for instance.

But I wonder if we should make it explicit, for instance by adding to 
section 1.2 (or a new section below it it) something like the following:

  In developing this standard for the format of messages, backwards
  compatibility was given a high priority. We expect that most
  reasonably-correct messages generated by 2004-vintage Netnews
  clients and servers will be accepted by servers checking messages
  against this syntax, and we expect that most messages generated
  according to this syntax will be accepted by 2004-vintage Netnews
  clients and servers.

Based on this, it's an obvious conclusion that Injection-info and 
Injection-date HAVE to be optional in the format (since otherwise a 
conformant server would still be conformant if it chose to reject all 
articles that did not have them).

But the WG may want something else....

                     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 j7LJQQYK042100; Sun, 21 Aug 2005 12:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJQQhn042099; Sun, 21 Aug 2005 12:26: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 j7LJQPCd042093 for <[e-mail]>; Sun, 21 Aug 2005 12:26:25 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 29A5C32007B for <[e-mail]>; Sun, 21 Aug 2005 21:26:13 +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 24207-07 for <[e-mail]>; Sun, 21 Aug 2005 21:26:09 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 356CC320084 for <[e-mail]>; Sun, 21 Aug 2005 21:26:03 +0200 (CEST)
Date: Sun, 21 Aug 2005 20:41:05 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1102 Suggestion to use "server" and "UA" in USEFOR
Message-ID: <990B5932BFDC2E7A45C35B9E@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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>

Charles has suggested that USEFOR be changed to use the terms "server" and 
"user agent" rather than the current list of "agents" that are more-or-less 
backported from USEPRO.

I have not seen any debate on it; I tend to sympathize from the viewpoint 
of making a simpler and more well-known terminology; on the other hand, 
it's a bit of work for the editor, and at this hopefully-late stage, it's a 
big change to digest.

Do people have any thought on this subject?

               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 j7LJQHNc042087; Sun, 21 Aug 2005 12:26:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJQHBj042086; Sun, 21 Aug 2005 12:26: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 j7LJQGaj042080 for <[e-mail]>; Sun, 21 Aug 2005 12:26:17 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63DFF32008A; Sun, 21 Aug 2005 21: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 23954-07; Sun, 21 Aug 2005 21:26:00 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5034320084; Sun, 21 Aug 2005 21:25:54 +0200 (CEST)
Date: Sun, 21 Aug 2005 20:21:50 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Message-ID: <79D5DBCEF80F0747A03033F0@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 16. august 2005 21:31 +0000 Charles Lindsey <[e-mail]> 
wrote:

>>   The text below uses ABNF to specify restrictions on the syntax
>>   specified in [RFC2822]; this grammar is intended to be more restrictive
>>   than the RFC 2822 grammar.
>>   Articles must conform to both the ABNF specified in RFC 2822 and to the
>>   ABNF specified here, as applicable.
>
> Various people have commented on this.
>
> "Articles must conform to the ABNF specified in RCFC 2822, except insofar
> as it is superseded/extended/modified by this specification/standard.
> Observe that the forms permitted by this specification/standard
> nevertheless remain a strict subset of those permitted by RFC 2822."

Since there are no extensions or modifications, just restrictions:

Articles must conform to the ABNF specified in RFC 2822.
Articles must also conform to the restrictions specified here, both those 
that are expressed as text and those that are expressed as ABNF.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LJQ0M2042063; Sun, 21 Aug 2005 12:26:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJQ0MD042062; Sun, 21 Aug 2005 12:26: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 j7LJPvxd042055 for <[e-mail]>; Sun, 21 Aug 2005 12:25:57 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 126A232007B; Sun, 21 Aug 2005 21:25:45 +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 23954-06; Sun, 21 Aug 2005 21:25:41 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 685F9320084; Sun, 21 Aug 2005 21:25:34 +0200 (CEST)
Date: Sun, 21 Aug 2005 19:28:20 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <E0D0148C6A5969AC5BD4BCEA@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 16. august 2005 22:05 +0000 Charles Lindsey <[e-mail]> 
wrote:

>> - Permit : in "diagnostics", not in "identities", and add some
>> appropriate  note with warnings on what will happen to DEAD:BEEF:CAFE
>
> But given that the "dead/beef" problem has not been eliminated by your
> proposal, what do you actually gain by forbidding IP-addresses in
> "identities"? The cat is already out of the bag.

(politeness off)
Yes, IP addresses will occur in Path. They already do (v4), and any system 
that doesn't pass on articles that contain them is so broken that it's got 
no business passing itself off as an USENET server.

> You are bolting the
> stable door after the horse has bolted (so I shall nip it in the bud :-)
> ). [Sorry, joke might be hard for Norwegians, but Englishmen with a
> smattering of Irish politics should get it.]

Your own statistics proved positively that using IP addresses for 
IDENTIFYING YOUR OWN SYSTEM is a very rare occurence, if it occurs at all; 
we have no idea why those IP addresses you couldn't divine a purpose of 
were in the Path: of the articles you looked at.

Saying that giving a name to your system is REQUIRED by the standards is a 
Good Thing, and allows us to positively refuse to allow such idiocies as 
using an IP address to identify your server in injection-info.

That horse has not yet escaped, but not because we've been flogging it to 
death in this group (proving that I can mix metaphors too, but otherwise an 
useless addition to this message).

                        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 j7LJPqMD042051; Sun, 21 Aug 2005 12:25:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJPqvZ042050; Sun, 21 Aug 2005 12:25: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 j7LJPoVQ042043 for <[e-mail]>; Sun, 21 Aug 2005 12:25:51 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 251DC320089 for <[e-mail]>; Sun, 21 Aug 2005 21:25:37 +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 24207-04 for <[e-mail]>; Sun, 21 Aug 2005 21:25:31 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E52D32007B for <[e-mail]>; Sun, 21 Aug 2005 21:25:26 +0200 (CEST)
Date: Sun, 21 Aug 2005 19:21:00 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1080 - Poll about "injection-info"
Message-ID: <55FCE5290C1A6DE66EE3D5A9@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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>

After reading through the comments on my August 15 posting, I'm going to 
attempt a poll, concerning section 3.2.14 of USEFOR.
Note the way the questions are divided up; I expect people to have opinions 
at multiple levels, so that saying "I think we shouldn't change the syntax, 
but if we change it, we should go for alternative X" is something that you 
can say.

I'll summarize the poll results on or after Wednesday, August 25.

If you have no opinion on a question, please say so.

1) SHOULD THERE BE SUBSTANTIAL CHANGES TO INJECTION-INFO?
  1a) No, we should keep approximately the current syntax
  1b) Yes, we should pick a substantially different solution
  1c) None of the above

2) IF SUBSTANTIAL CHANGES ARE MADE, WHAT FORM SHOULD IT BE?
  2a) Multiple header fields
  2b) A single header field with a syntax different from
      the "name=value" syntax

3) IF THE SYNTAX IS KEPT, HOW SHOULD WE DESCRIBE IT?
  3a) Keep the current definition; it's good enough.
  3b) Specify ABNF for a "name=value" list, don't refer to
      "parameter"
  3c) Use the "parameter" definition, but add a non-normative
      description in modern ABNF
  3d) Use the "parameter", give an ABNF for each parameter
      value we define, but don't add an overall ABNF
  3e) Something else

4) SHOULD THE FIELD ALLOW RFC 2231 CONSTRUCTS?
  4a) Yes
  4b) No
  4c) Something else

-----------------------------------------------------------
Notes to the poll, gleaned from discussion:

1:

As I understand it, this is revisiting a previous WG
decision to pursue the current definition. That's something that we should 
not do lightly.

3:

The current definition has some stuff to the right hand side of the equals 
sign that doesn't conform to "parameter". We should either change this or 
make a NOTE saying it's deliberate.

Redefining "parameter" properly may not be trivial. Alternative 3d) could 
have a NOTE saying such things as "allow CFWS around the equals sign"; not 
saying anything would leave the mess for implementors to sort out.

Note also that putting stuff which allows encoded-words (such as 
"address-list") inside quotes puts the encoded-words out of reach of 
2822-conformant decoders....

4:

- If any fields need internationalization or extended character sets, RFC 
2231 may be needed.
- Long field values (x-filename?) may need RFC 2231






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LHAvuo075704; Sun, 21 Aug 2005 10:10:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LHAvNb075703; Sun, 21 Aug 2005 10:10: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 j7LHAuCI075688 for <[e-mail]>; Sun, 21 Aug 2005 10:10: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 j7LHAtxg023339 for <[e-mail]>; Sun, 21 Aug 2005 10:10:55 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 39DBDE7CD4; Sun, 21 Aug 2005 10:10:55 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Sun, 21 Aug 2005 11:22:15 -0400")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <D33901E32DCA24FFA98D738C@[10.61.81.201]> <[e-mail]>
Date: Sun, 21 Aug 2005 10:10:54 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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 Thu August 18 2005 08:50, Harald Tveit Alvestrand wrote:
>> --On 17. august 2005 07:57 -0700 Russ Allbery <[e-mail]> wrote:

>> > There are no performance issues with comments provided that servers are
>> > allowed to treat them as Path entries and the ()s as delimiters.
>> 
>> I think having a Path: sent.from!(not sent to sams.server)!not-for-mail
>> resulting in "sams.server" not getting the message is an interoperability 
>> problem.....

> Perhaps, but under a strict interpretation of Russ' remarks that's not
> what would happen; "not sent to sams.server" would not receive the
> message, but since no system name can contain a space character, there
> is in fact no excluded system.

Spaces are also currently treated as delimiters, so Harald is correct.

-- 
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 j7LGgKwU058710; Sun, 21 Aug 2005 09:42:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LGgK1i058709; Sun, 21 Aug 2005 09:42:20 -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 j7LGgJGI058694 for <[e-mail]>; Sun, 21 Aug 2005 09:42: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 ns3.townisp.com (Postfix) with ESMTP id 1013429954; Sun, 21 Aug 2005 12:42:19 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7LGgDS7015544(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, 21 Aug 2005 12:42:18 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7LGgCmd015543(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, 21 Aug 2005 12:42:12 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Date: Sun, 21 Aug 2005 12:42:10 -0400
User-Agent: KMail/1.8.2
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 August 17 2005 03:16, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > If article syntax is fully conformant and compatible with
> > RFC 2822, there is no need for even a gateway to perform any
> > modifications.
> 
> That's of course wrong, A <-- gateway --> B.  The gateway has
> to transform A-format into B-format (or vice versa), and it
> only gets away with no modifications for a proper subset A'
> of A which happens to be also a subset of B.

If the syntax is fully conformant and compatible, there is no need for any
transformation; that and its associated problems only arise when
incompatibilities are introduced.

> Similar problems in the opposite direction, watch the magic SP,

That's an example of an incompatibility.

---

> That has some consequences if the "same" Message-ID arrives
> at different times in different lists.  Unlike Usenet a mail
> Message-ID doesn't guarantee identity,

Please reread RFC 2822 section 3.6.4, in particular:

   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it (see below).  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.

> > The best thing to do is to minimize the differences from
> > 2822 to the absolute minimum, with rationale for each and
> > a roadmap to full compatibility.
> 
> That roadmap is _ready_ for the <msg-id>, you find (a variant
> of) it in the Usefor draft.  2822bis will copy it as is for
> its future "chapter 3", moving NO-WS-CTL and other creatures
> to its future obs-chapter where they can die.

Do you have evidence to support that claim, or is it wishful thinking?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LGYLfp053631; Sun, 21 Aug 2005 09:34:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LGYLM9053630; Sun, 21 Aug 2005 09:34: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 j7LGYLa8053624 for <[e-mail]>; Sun, 21 Aug 2005 09:34:21 -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 5C7442993B; Sun, 21 Aug 2005 12:34:20 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7LGYJAD015513(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, 21 Aug 2005 12:34:19 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7LGYEbU015512(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, 21 Aug 2005 12:34:19 -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: Sun, 21 Aug 2005 12:34:11 -0400
User-Agent: KMail/1.8.2
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 Wed August 17 2005 10:29, Charles Lindsey wrote:
> 
> In <[e-mail]> Frank Ellermann <[e-mail]> writes:
> 
> ><http://article.gmane.org/gmane.ietf.usenet.format/27216>
> 
> >What do you think of it ?  It avoids RfC 2231.  What are the
> >disadvantages ?
> 
> Essentially, it is a different format for the same wheel. It has pairs of
> names and values separated by CFWS. The values are 1*angle-addr /
> addr-spec / atom / domain / msg-id, some of which are appropriate for our
> needs and some not.

Since the Injection-Info field is optional, there is no "need".  Even if
field were mandatory, the components (other than the identifier of the
injecting systems (i.e. "domain")) are optional.  So, your claim, Charles,
in untrue.

> It provides nothing obviously suitable for the 
> posting-account and logging-data parameters,

angle-addr or addr-spec or atom, and atom or msg-id, respectively, are
suitable.  Another untrue claim, Charles.  Moreover, as already discussed,
"logging-data" is a waste of bandwidth and disk space, as it is only
meaningful at the injection site; it is therefore pointless to transmit it
to thousands of systems where it will occupy valuable disk space -- it
need only be associated with the article (via msg-id) at the injecting site.
Ditto for posting-account.

> and it makes no provision for 
> any parameters which might contain whitespace within themselves

Untrue; angle-addr, addr-spec, and domain may all contain whitespace.
Also, there is a conflict between RFCs 2821 and 2822 w.r.t. quoted-strings
(allowed in 2821 but omitted from 2822); if that is resolved in favor of
2821, that is another mechanism. [incidentally, both angle-addr and addr-spec
already include quoted-sting via local-part, but 2822 as written does not
permit a stand-alone quoted-string as an item-value]

> , or for 
> I18N (both of which might well arise for the two parameters mentioned).

More untrue assertions; look up "IDN".  Also, "atom" includes things such as
=?us*en?q?foo?= (indeed, RFC 2047/2231 encoded-words are intentionally
designed to be RFC 822 atoms); however that is somewhat unclear as MIME
(2047/2231) is based on 822 rather than 2822, and 2822 neglects mention of
MIME encoded-words.  While RFC 2047 contains a curious prohibition against
encoded-words in the Received field, that obviously would not apply to a
new field (i.e. different field name) using similar field body syntax. 

> So 
> there is no way that a value could be folded.

A patently and obviously false claim; all item-value constructs explicitly
permit folding, and folding is allowed between an item-name and item-value as
well as between name-val-pairs.  As the syntax is modeled on the Received
field syntax and Received fields are commonly folded, there is no excuse for
making such a false claim.

> It makes no provision for display-names to go with addr-specs (which are
> not essential, but I can see they might be handy).

Nor does use of 2231 parameters; indeed that was recently discussed as a
serious problem with that proposed scheme vs. a separate Complaints-To
field.
 
> It makes no provision for future parameters in extensions (to be ignored 
> in the meanwhile),

Yet another falsehood; the syntax provides for any item-name which meets
the syntax requirements.

> nor for ad-hoc parametets with x-names.

That is a feature. [though names beginning with "x-" match the item-name
syntax and could therefore be used if we wanted to open that Pandora's box]

> By the time you have fixed all those things, you are more or less back at
> MIME parameters.

Absolutely untrue.  There are not the parsing complexities of MIME parameters,
no quoting vs. encoded-word issues, and existing reusable code (vs. having to
write code from scratch including handling RFC 2045/2047/2231 issues).

> That would bring up the dreaded 2231, of course, but at 
> least you get semi-decent I18N that way

See IDN and RFC 2047/2231.

> (the only thing wrong with the 
> 2231 I18N is that it is different from all the other I18N fixes that have
> been invented over the years).

Another falsehood; Q encoding is essentially the same as that used in URIs
and differs from that used in encoded-words only in the choice of the initial
character ('%' vs. '='), and there is evidence that the latter difference
was not originally intended.

> So the only problem left is the line 
> splitting feature of 2231, which I agree we do not want, and could happily
> deprecate.

More falsehoods.  We have no authority to modify RFC 2231.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LGPxLZ048063; Sun, 21 Aug 2005 09:25:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LGPx3A048062; Sun, 21 Aug 2005 09:25:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LGPw2r048041 for <[e-mail]>; Sun, 21 Aug 2005 09:25:58 -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-35.mail.demon.net with esmtp (Exim 4.42) id 1E6sZ6-0007qO-Hg for [e-mail]; Sun, 21 Aug 2005 16:20:57 +0000
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 17:24:44 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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 <HH9$+L+L77frGOKLbeU+dOQlcs>
Sender: [e-mail]
Precedence: 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

>> All of which is why we removed <comment>s from the Path quite some time ago.
>
>"we" didn't remove them.  It was a one-person, non-consensus, unilateral
>action based on flawed reasoning.

About a year ago I parsed about four months worth of articles from a
fairly complete feed (not the labelled binary groups, but I'd doubt that
made any difference since I don't think they form a disjoint set of
servers) ...  There were about 27,400,000 articles in the set.

By splitting at "!" characters I identified 11,063 "servers" (ie:
fragments of Path: header fields which lie to the left of an indication
of injection (such as "not-for-mail", but in fact there's a few dozen
others of interest that you need to handle).

I identified ZERO comments at that time -- and looking at the list of
servers now, none seem to be anything other than machine identities

So I'm not sure they were there to be removed, or that, for interop
reasons, adding them would be in the least bit wise :-(

- -=-=-=-=-=-=-=-

BTW: Usenet is not all that big -- I identified 2556 servers as being
part of a "peering core" (from my vantage point). The other 8500
machines were merely feeding into that core.

The algorithm was to start from 'news.maxwell.syr.edu' and see if any
article arrived that had been given any articles by this machine. If so
then they were added to the core and a check made to see if there were
now other machines to which articles had been given...  iterate.

Looking now at those 2556 servers -- which are, at least from my vantage
point, somewhat more important than the rest -- I find that 218 of them
have chosen to use an identity that is a bare word, and I'd say that
half of those look to be UUCP names.

- -- 
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/AwUBQwiqzJoAxkTY1oPiEQKhrgCg53vRj58VxR8nBvr4oZ61jOoKs+gAoJtu
+Nq9DzLc27q6T/ETWdkATUWC
=Gp8c
-----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 j7LFmjnb025843; Sun, 21 Aug 2005 08:48:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LFmjQe025842; Sun, 21 Aug 2005 08:48:45 -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 j7LFmi9n025827 for <[e-mail]>; Sun, 21 Aug 2005 08:48: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 ns3.townisp.com (Postfix) with ESMTP id BF07D2999B; Sun, 21 Aug 2005 11:48:43 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7LFmckR015288(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, 21 Aug 2005 11:48:42 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7LFmbHw015287(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, 21 Aug 2005 11:48:38 -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: Sun, 21 Aug 2005 11:48:33 -0400
User-Agent: KMail/1.8.2
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 Wed August 17 2005 10:36, Charles Lindsey wrote:

> Actually, you could allow encoded-words within quoted-strings

No.  RFC 2047, section 5:

   + An 'encoded-word' MUST NOT appear within a 'quoted-string'.

> Note that I neither propose nor oppose this idea - I merely point out that
> it is possible.

You are mistaken.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LFjmZd024088; Sun, 21 Aug 2005 08:45:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LFjmGF024087; Sun, 21 Aug 2005 08:45:48 -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 j7LFjmNW024072 for <[e-mail]>; Sun, 21 Aug 2005 08:45: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 ns1.townisp.com (Postfix) with ESMTP id B71F029AED; Sun, 21 Aug 2005 11:45: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 j7LFjfqT015254(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, 21 Aug 2005 11:45:46 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7LFjeQX015253(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, 21 Aug 2005 11:45:41 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Sun, 21 Aug 2005 11:45:38 -0400
User-Agent: KMail/1.8.2
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 August 18 2005 09:52, Charles Lindsey wrote:
> 
> In <[e-mail]> Russ Allbery <[e-mail]> writes:
> 
> >Bruce Lilly <[e-mail]> writes:
> 
> >> No, we have not; there are no "sever interoperability" issues which are
> >> any different than are introduced by MISMATCH, POSTED, "!!", etc. --
> >> those are changes, and there will be some interoperability issues.
> >> Introducing ':' as other than a delimiter (its long-standing use) will
> >> introduce severe interoperability issues.  There are no performance
> >> issues with introducing comments; that is a red herring.
> 
> >There are no performance issues with comments provided that servers are
> >allowed to treat them as Path entries and the ()s as delimiters.  There
> >are (mild) performance issues if servers are expected to ignore them.
> >There are (mostly mild but more annoying) performance issues if the full
> >RFC 2822 CFWS syntax is expected to be supported.
> 
> I don't think it is as simple as that. If someone puts "(demon)" in the
> middle of the Path, then it is quite possible that demon customers will
> never get to see the article.

Iff it's not treated as a comment.  Ditto for !POSTED! vs posted customers,
!MISMATCH! vs mismatch customers, and !dead:beef::cafe! vs dead, beef, and
cafe customers.

> So I think servers would have to ignore 
> them, which means matching pairs of "(...)" inside them.

Yes; trivial.
 
> Bearing in mind that every relaying agent is supposed to locate the Path
> header within each article,

Invariant.

> scan it for valid entries (i.e. things between 
> delimiters/WSP/folds,

Invariant.

> but not the <tail-entry>)

Invariant (and also rather pointless, as that entry serves no purpose).

> and check each entry found  
> against the name(s) of the peer it is considering sending it to. Repeat
> for every peer.

Note that there are any number of ways to do so which do not require
parsing the Path field more than once, or other than left-to-right, at
any given server.  It necessarily means comparing M non-comment, non-
diagnostic, non-keyword, non-bogus path entries to N peer names (although
clearly the tests can be short-circuited once a match for a specific
peer is found). For an article with M valid path entries and at a site
with N peers, none of which are listed in the path field, that is a
minimum complexity of O(N*M). 

> any extra work put into
> that loop is going to impact performance

1. skipping from '(' to the matching unquoted ')' is outside of the
   loop; it is one-time field parsing and none of the skipped content
   is checked against any peer names.  Nor does it affect the number
   of non-comment entries to be checked.  O(N*M) still applies.
2. skipping over comments is trivial (compared to e.g. parsing 2231
   parameters or comparing keywords to a (possibly long) list of peer
   names)

> All of which is why we removed <comment>s from the Path quite some time ago.

"we" didn't remove them.  It was a one-person, non-consensus, unilateral
action based on flawed reasoning.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LFMUXl009003; Sun, 21 Aug 2005 08:22:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LFMUCp009002; Sun, 21 Aug 2005 08:22:30 -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 j7LFMTx9008987 for <[e-mail]>; Sun, 21 Aug 2005 08:22: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 ns4.townisp.com (Postfix) with ESMTP id 7B12B2992B; Sun, 21 Aug 2005 11:22:28 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7LFMQZm015120(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, 21 Aug 2005 11:22:27 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7LFMMpI015119(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, 21 Aug 2005 11:22:26 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Sun, 21 Aug 2005 11:22:15 -0400
User-Agent: KMail/1.8.2
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <[e-mail]> <[e-mail]> <D33901E32DCA24FFA98D738C@[10.61.81.201]>
In-Reply-To: <D33901E32DCA24FFA98D738C@[10.61.81.201]>
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 August 18 2005 08:50, Harald Tveit Alvestrand wrote:
> 
> --On 17. august 2005 07:57 -0700 Russ Allbery <[e-mail]> wrote:

> > There are no performance issues with comments provided that servers are
> > allowed to treat them as Path entries and the ()s as delimiters.
> 
> I think having a Path: sent.from!(not sent to sams.server)!not-for-mail
> resulting in "sams.server" not getting the message is an interoperability 
> problem.....

Perhaps, but under a strict interpretation of Russ' remarks that's not
what would happen; "not sent to sams.server" would not receive the message,
but since no system name can contain a space character, there is in fact no
excluded system.

One should also be wary of declaring interoperability problems in all cases.
a field
  Path: sent.from!!sams.server!foo
may have been injected at "sent.from", with a bogus "sams.server" entry
deliberately inserted to prevent propagation to that specific site.  This
is a known form of attack.  Indeed, USEFOR inexplicably says that "[e]ach
agent" "is required to prepend one (or more) identities", whereas that
(specifically the "(or more)") is an explicit loophole permitting the sort
of abuse described.  The specific attack is alluded to in one of the
subsections of the USEPRO security considerations section.

The Path field as currently defined in RFC 1036 has as delimiters the set
of characters in "!:@^%,", has no magic keywords and no provision for 
diagnostics.  Current draft text has provision for diagnostics using
keywords and changes ':' from a delimiter to a non-delimiter, both of which
cause interoperability problems.

Avoiding interoperability problems with deployed software means no keywords
(no diagnostics) and no change in status of ':' as a delimiter (no IPv6
address literals).

There are several distinct issues involved:
1. in the time of RFC 1036, there was a "UUCP mapping project" which was
   intended to provide a uniqueness guarantee for unqualified names.  It
   failed to provide such a guarantee and no longer exists.  That affects
   use of unqualified names (no guarantee of uniqueness, such a guarantee
   being necessary to the proper functioning of the use of the Path field
   for suppression of redundant retransmissions w/o adversely affecting
   normal propagation) and keywords (which are indistinguishable from
   unqualified names).
2. use of IP address literals, which seems to be of use only for
   diagnostics.  IPv6 address literals as currently defined in text form
   are incompatible with long-standing use of ':' as a delimiter,
   especially in conjunction with use of unqualified names.
3. diagnostics (currently (RFC 1036) no provision).
4. known security weaknesses in the existing protocol

If we require use of fully-qualified domain names, the issues with
unqualified names vs. keywords and of IPv6 address literal text format
disappear.  The necessary uniqueness property is guaranteed by the DNS.

Providing diagnostics in the Path field is going to cause some degree of
interoperability problems no matter what.  We need to decide whether or
not any putative benefit of such diagnostics outweighs the interoperability
problems.

The "design" of the Path field and protocols is currently and as proposed
lacking in security mechanisms; indeed, it facilitates some forms of attack
as noted above (note that in the example, it is not possible for any site
after "sent.from" to determine that in fact "sent.from" has forged a Path
entry for "sams.server".  Correcting the security problems would almost
certainly result in some degree of interoperability problems (e.g. some
new secure mechanism for duplicate transmission suppression which is
necessarily unsupported by deployed implementations).  Note in particular
that neither the proposed "!!" nor keywords provides any security against
attacks against the duplicate transmission suppression mechanism (as per
the example above).

If the duplicate transmission suppression mechanism is redesigned with
security in mind, the protocol will stand a better chance of advancement
on the Standards Track, some existing security loopholes can be removed,
and provision for diagnostics can be designed in.  But it will of course
be an interoperability issue with deployed software.  Conversely, slavishly
following interoperability with deployed implementations will leave major
security loopholes (which may be a problem for Standards Track advancement)
and precludes provision for diagnostics (and IPv6 address literals in
unmodified text format).

It may be possible to design a new mechanism while retaining the old
insecure Path method (and syntax) for legacy systems.  That would
necessarily require extra effort for new implementations, and would have to
be carefully designed to interoperate with existing implementations (which
necessarily would not use the new mechanism).

To date the discussion has focused on a particular scheme which introduces
interoperability problems without addressing the real security loopholes.
Maybe we should step back and look at the security problems and come up
with a solution that will provide a real improvement rather than
introducing interoperability problems with no real benefits.
  
> >  There
> > are (mild) performance issues if servers are expected to ignore them.
> > There are (mostly mild but more annoying) performance issues if the full
> > RFC 2822 CFWS syntax is expected to be supported.
> 
> Are there interoperability issues with old servers?

As noted above, there are interoperability problems unless we avoid
diagnostics and IPv6 address literals in the Path 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 j7JJpt2d096625; Fri, 19 Aug 2005 12:51:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JJptus096624; Fri, 19 Aug 2005 12:51:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7JJpsmB096609 for <[e-mail]>; Fri, 19 Aug 2005 12:51:54 -0700 (PDT) (envelope-from [e-mail])
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 92B1013A778 for <[e-mail]>; Fri, 19 Aug 2005 15:51:53 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j7JJprM08279; Fri, 19 Aug 2005 15:51:53 -0400 (EDT)
Date: Fri, 19 Aug 2005 15:51:53 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> ([e-mail])
Subject: Re: #1047 Path field delimiters and syntax - status
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>

"Charles Lindsey" <[e-mail]> wrote:

> It depends on the number of clashes arising from your hash
> algorithm.

You don't need hashing at all.

> With a sufficiently large number of peers (millions), you would be
> back at O(Path-length * nsites), but for sensible numbers (hundreds)
> it should work.

Construct a tree; nodes are prefixes of peer names.  At a given node,
for each character, there's a next node (simple table lookup); the
next node might be "ain't gonna find a peer, so go ahead to the next
delimiter".   The processing for each character in the Path is a table
lookup, O(1).  Constructing the tree is O(total length of peer list).

> But whichever way, it is still going to acount for a significant
> proportion of the CPU cycles expended by the server.

Putting the Path header on top would save more CPU cycles (to avoid
scanning the header list for it) than scanning the Path header for
peers takes.

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 j7JIh1gJ075168; Fri, 19 Aug 2005 11:43:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JIh1ww075167; Fri, 19 Aug 2005 11:43:01 -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 j7JIh09X075143 for <[e-mail]>; Fri, 19 Aug 2005 11:43:01 -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 j7JIgvtS028182; Fri, 19 Aug 2005 14:42:57 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7JIgvqF028181; Fri, 19 Aug 2005 14:42:57 -0400 (EDT)
Date: Fri, 19 Aug 2005 14:42:56 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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, 19 Aug 2005, Charles Lindsey wrote:
> >...With a
> >well-crafted hash table -- and since any news server is processing many,
> >many articles between changes of peer configuration, you can put a lot of
> >effort into building a good one -- the hash-table lookup is O(1)...
> 
> It depends on the number of clashes arising from your hash algorithm.

Zero.  This application has both the time and the incentive to use an
adaptive hashing algorithm that customizes itself to the particular set of
data so it can build a collision-free table. 

                                                          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 j7JGIfr5038422; Fri, 19 Aug 2005 09:18:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7JGIfpA038421; Fri, 19 Aug 2005 09:18:41 -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 j7JGId35038415 for <[e-mail]>; Fri, 19 Aug 2005 09:18:40 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-76-108.midband.mdip.bt.net ([81.144.76.108]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4306065e.4dd2.33 for [e-mail]; Fri, 19 Aug 2005 17:18:38 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7JGHQV13166 for [e-mail]; Fri, 19 Aug 2005 17:17:26 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22354
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Fri, 19 Aug 2005 15:40:43 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]> Henry Spencer <[e-mail]> writes:

>Change "list of peer and Path identity pairs" to "hash table of peer and
>Path identity pairs, hashed by Path identity".  You make *one* pass over
>the Path header, looking up each identity from it in the hash table, and
>when you get a hit, you mark that table entry as "don't send".  With a
>well-crafted hash table -- and since any news server is processing many,
>many articles between changes of peer configuration, you can put a lot of
>effort into building a good one -- the hash-table lookup is O(1), so the
>whole process is O(length(Path)).

It depends on the number of clashes arising from your hash algorithm. With
a sufficiently large number of peers (millions), you would be back at
O(Path-length * nsites), but for sensible numbers (hundreds) it should
work.

Alternatively, you could probably construct an O(Path-length *
log(nsites)) algorithm that would even hold over the millions.

But whichever way, it is still going to acount for a significant
proportion of the CPU cycles expended by the server.

-- 
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 j7IIrXWM052226; Thu, 18 Aug 2005 11:53:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IIrXFs052225; Thu, 18 Aug 2005 11:53: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 j7IIrWKt052219 for <[e-mail]>; Thu, 18 Aug 2005 11:53:32 -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 j7IIr7tS011156; Thu, 18 Aug 2005 14:53:07 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7IIr6Jr011155; Thu, 18 Aug 2005 14:53:06 -0400 (EDT)
Date: Thu, 18 Aug 2005 14:53:06 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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, 18 Aug 2005, Russ Allbery wrote:
> >> O(length(Path) * nSites)
> > Pre-process the Sites list (since that doesn't change very often), and
> > the scan is then O(length(Path)).
> 
> My input is an article with a Path header and a list of peer and Path
> identity pairs.  My output is a list of peers to which I should send the
> article.  Could you describe the pre-processing of the peer list that
> would allow me to do this in O(length(Path))?  I'm not seeing it.

Change "list of peer and Path identity pairs" to "hash table of peer and
Path identity pairs, hashed by Path identity".  You make *one* pass over
the Path header, looking up each identity from it in the hash table, and
when you get a hit, you mark that table entry as "don't send".  With a
well-crafted hash table -- and since any news server is processing many,
many articles between changes of peer configuration, you can put a lot of
effort into building a good one -- the hash-table lookup is O(1), so the
whole process is O(length(Path)).

(There are also some O(nSites) steps before and after the header scan, but
that's true of any scheme that does the job.)

                                                          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 j7IIfepc050914; Thu, 18 Aug 2005 11:41:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IIfeAs050913; Thu, 18 Aug 2005 11:41:40 -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 j7IIfdSP050907 for <[e-mail]>; Thu, 18 Aug 2005 11:41:39 -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 j7IIfcMM029402 for <[e-mail]>; Thu, 18 Aug 2005 11:41:38 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 98D6FE7BCC; Thu, 18 Aug 2005 11:41:38 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Russ Allbery's message of "Thu, 18 Aug 2005 11:21:52 -0700")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 18 Aug 2005 11:41:38 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> My input is an article with a Path header and a list of peer and Path
> identity pairs.  My output is a list of peers to which I should send the
> article.  Could you describe the pre-processing of the peer list that
> would allow me to do this in O(length(Path))?  I'm not seeing it.

Oh, right, hash the identities of all of the peers, mark all the peers as
receiving the article, and then walk the Path header, unmarking any peer
that is returned as a result of a hash lookup on the Path header entry.

Never mind.

I take back my original message; the cost of additional parsing complexity
is on the same order, roughly, as the cost of additional sites; none of
those steps particularly dominates.

-- 
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 j7IILu2c049492; Thu, 18 Aug 2005 11:21:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IILuh3049491; Thu, 18 Aug 2005 11:21:56 -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 j7IILuV4049485 for <[e-mail]>; Thu, 18 Aug 2005 11:21: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 j7IILqIa021456 for <[e-mail]>; Thu, 18 Aug 2005 11:21:55 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id BF351E7BCC; Thu, 18 Aug 2005 11:21:52 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Seth Breidbart's message of "Thu, 18 Aug 2005 13:58:25 -0400 (EDT)")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 18 Aug 2005 11:21:52 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:
> Russ Allbery <[e-mail]> wrote:

>>> and check each entry found against the name(s) of the peer it is
>>> considering sending it to. Repeat for every peer.

>> O(length(Path) * nSites)

> Pre-process the Sites list (since that doesn't change very often), and
> the scan is then O(length(Path)).

My input is an article with a Path header and a list of peer and Path
identity pairs.  My output is a list of peers to which I should send the
article.  Could you describe the pre-processing of the peer list that
would allow me to do this in O(length(Path))?  I'm not seeing it.

Now, you can preprocess the Path information for each article, hash it for
instance, and then reduce the lookup to O(nSites), but then you have to do
extra work in advance for each article.  I'd have to actually experiment
to see which ways the tradeoffs would break for the average article and an
average number of sites; my guess would be that a linear scan is probably
about as fast.

Regardless, my point is that more complex Path parsing is a non-zero but
not particularly significant performance impact, which I think still
stands regardless.

-- 
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 j7IHwQOl047812; Thu, 18 Aug 2005 10:58:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IHwQoA047811; Thu, 18 Aug 2005 10:58:26 -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 j7IHwPcm047805 for <[e-mail]>; Thu, 18 Aug 2005 10:58:26 -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 EC15958899 for <[e-mail]>; Thu, 18 Aug 2005 13:58:24 -0400 (EDT)
Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j7IHwPk07028; Thu, 18 Aug 2005 13:58:25 -0400 (EDT)
Date: Thu, 18 Aug 2005 13:58:25 -0400 (EDT)
Message-Id: <[e-mail]>
From: Seth Breidbart <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Russ Allbery on Thu, 18 Aug 2005 08:06:47 -0700)
Subject: Re: #1047 Path field delimiters and syntax - status
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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:

>> Bearing in mind that every relaying agent is supposed to locate the Path
>> header within each article,
>
> O(length(Header))
>
>> scan it for valid entries (i.e. things between delimiters/WSP/folds, but
>> not the <tail-entry>)
>
> O(length(Path))
>
>> and check each entry found against the name(s) of the peer it is
>> considering sending it to. Repeat for every peer.
>
> O(length(Path) * nSites)

Pre-process the Sites list (since that doesn't change very often), and
the scan is then O(length(Path)).  The pre-processing isn't very
expensive, either.

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 j7IF6pSB036009; Thu, 18 Aug 2005 08:06:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IF6o32036008; Thu, 18 Aug 2005 08:06:50 -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 j7IF6oB4036002 for <[e-mail]>; Thu, 18 Aug 2005 08:06:50 -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 j7IF6lGG029507 for <[e-mail]>; Thu, 18 Aug 2005 08:06:49 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 1537EE7BCC; Thu, 18 Aug 2005 08:06:47 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu, 18 Aug 2005 13:52:01 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 18 Aug 2005 08:06:47 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:
>> Bruce Lilly <[e-mail]> writes:

>>> No, we have not; there are no "sever interoperability" issues which
>>> are any different than are introduced by MISMATCH, POSTED, "!!",
>>> etc. -- those are changes, and there will be some interoperability
>>> issues.  Introducing ':' as other than a delimiter (its long-standing
>>> use) will introduce severe interoperability issues.  There are no
>>> performance issues with introducing comments; that is a red herring.

>> There are no performance issues with comments provided that servers are
>> allowed to treat them as Path entries and the ()s as delimiters.  There
>> are (mild) performance issues if servers are expected to ignore them.
>> There are (mostly mild but more annoying) performance issues if the
>> full RFC 2822 CFWS syntax is expected to be supported.

> I don't think it is as simple as that. If someone puts "(demon)" in the
> middle of the Path, then it is quite possible that demon customers will
> never get to see the article.

I was only addressing the performance part, not the question of backward
compatible syntax, which is another matter entirely.

> Bearing in mind that every relaying agent is supposed to locate the Path
> header within each article,

O(length(Header))

> scan it for valid entries (i.e. things between delimiters/WSP/folds, but
> not the <tail-entry>)

O(length(Path))

> and check each entry found against the name(s) of the peer it is
> considering sending it to. Repeat for every peer.

O(length(Path) * nSites)

This element dwarfs the others for pretty much any site large enough to be
worried about performance.

> Yes, a smart implementor can probably improve on that approach, but that
> is within the critical loop of the server, and any extra work put into
> that loop is going to impact performance (though there is good news too,
> because we now have only one delimiter to check for).

I'm not really worried about the performance impact of a more complex Path
parse, since that part is dwarfed by other issues.  Backwards
compatibility is a much more serious problem.

Basically, I'm between you and Bruce.  I don't agree with the assertion
that there is no performance impact, but I also don't think that's the
significant counter-argument.

-- 
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 j7IEop4m034283; Thu, 18 Aug 2005 07:50:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IEopVf034282; Thu, 18 Aug 2005 07:50:51 -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 j7IEooP6034268 for <[e-mail]>; Thu, 18 Aug 2005 07:50:50 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-68-213.midband.mdip.bt.net ([81.144.68.213]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4304a049.ce1d.1e for [e-mail]; Thu, 18 Aug 2005 15:50:49 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7IEm5t03471 for [e-mail]; Thu, 18 Aug 2005 15:48:05 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22346
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
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, 18 Aug 2005 13:52:01 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:

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

>> No, we have not; there are no "sever interoperability" issues which are
>> any different than are introduced by MISMATCH, POSTED, "!!", etc. --
>> those are changes, and there will be some interoperability issues.
>> Introducing ':' as other than a delimiter (its long-standing use) will
>> introduce severe interoperability issues.  There are no performance
>> issues with introducing comments; that is a red herring.

>There are no performance issues with comments provided that servers are
>allowed to treat them as Path entries and the ()s as delimiters.  There
>are (mild) performance issues if servers are expected to ignore them.
>There are (mostly mild but more annoying) performance issues if the full
>RFC 2822 CFWS syntax is expected to be supported.

I don't think it is as simple as that. If someone puts "(demon)" in the
middle of the Path, then it is quite possible that demon customers will
never get to see the article. So I think servers would have to ignore
them, which means matching pairs of "(...)" inside them.

Bearing in mind that every relaying agent is supposed to locate the Path
header within each article, scan it for valid entries (i.e. things between
delimiters/WSP/folds, but not the <tail-entry>) and check each entry found
against the name(s) of the peer it is considering sending it to. Repeat
for every peer.

Yes, a smart implementor can probably improve on that approach, but that
is within the critical loop of the server, and any extra work put into
that loop is going to impact performance (though there is good news too,
because we now have only one delimiter to check for).

All of which is why we removed <comment>s from the Path quite some time 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 j7IEoojg034275; Thu, 18 Aug 2005 07:50:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IEoogc034274; Thu, 18 Aug 2005 07:50:50 -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 j7IEonpJ034267 for <[e-mail]>; Thu, 18 Aug 2005 07:50:49 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-68-213.midband.mdip.bt.net ([81.144.68.213]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4304a048.ce1d.1d for [e-mail]; Thu, 18 Aug 2005 15:50:48 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7IEm3003463 for [e-mail]; Thu, 18 Aug 2005 15:48:03 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22345
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 18 Aug 2005 13:36:04 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]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>> s/obs-phrase/<obs-phrase>/
>> and maybe mention that it is really an extended-phrase,
>> and RFC 2822bis will undoubtedly rename it.

>NAK, that's an 2822-oddity, we have more than enough own
>oddities, renaming <obs-phrase> isn't our job.

Sure. I don't want to change any ABNF. I merely want to point out (in
parenthesis or a NOTE) that it is not actually an "obsolete" feature in
RFC 2822 (it was a new invention in 2822, and might even become "MAY
generate" at some future date).

-- 
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 j7IEYKIQ032887; Thu, 18 Aug 2005 07:34:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IEYKiX032886; Thu, 18 Aug 2005 07:34:20 -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 j7IEYK91032880 for <[e-mail]>; Thu, 18 Aug 2005 07:34:20 -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 j7IEYEfk019289 for <[e-mail]>; Thu, 18 Aug 2005 07:34:19 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 12995E7BCD; Thu, 18 Aug 2005 07:34:14 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <D33901E32DCA24FFA98D738C@[10.61.81.201]> (Harald Tveit Alvestrand's message of "Thu, 18 Aug 2005 14:50:14 +0200")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D33901E32DCA24FFA98D738C@[10.61.81.201]>
Date: Thu, 18 Aug 2005 07:34:13 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:
> --On 17. august 2005 07:57 -0700 Russ Allbery <[e-mail]> wrote:

>> There are (mild) performance issues if servers are expected to ignore
>> them.  There are (mostly mild but more annoying) performance issues if
>> the full RFC 2822 CFWS syntax is expected to be supported.

> Are there interoperability issues with old servers?

Oh, yes.  Tons.

-- 
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 j7ICoNSt002266; Thu, 18 Aug 2005 05:50:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ICoNOE002265; Thu, 18 Aug 2005 05:50:23 -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 j7ICoMUB002245 for <[e-mail]>; Thu, 18 Aug 2005 05:50:23 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84C8A320062; Thu, 18 Aug 2005 14:50:11 +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 21775-10; Thu, 18 Aug 2005 14:50:06 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB34832009B; Thu, 18 Aug 2005 14:50:05 +0200 (CEST)
Date: Thu, 18 Aug 2005 14:50:14 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Russ Allbery <[e-mail]>, [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <D33901E32DCA24FFA98D738C@[10.61.81.201]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 17. august 2005 07:57 -0700 Russ Allbery <[e-mail]> wrote:

>> No, we have not; there are no "sever interoperability" issues which are
>> any different than are introduced by MISMATCH, POSTED, "!!", etc. --
>> those are changes, and there will be some interoperability issues.
>> Introducing ':' as other than a delimiter (its long-standing use) will
>> introduce severe interoperability issues.  There are no performance
>> issues with introducing comments; that is a red herring.
>
> There are no performance issues with comments provided that servers are
> allowed to treat them as Path entries and the ()s as delimiters.

I think having a Path: sent.from!(not sent to sams.server)!not-for-mail
resulting in "sams.server" not getting the message is an interoperability 
problem.....

>  There
> are (mild) performance issues if servers are expected to ignore them.
> There are (mostly mild but more annoying) performance issues if the full
> RFC 2822 CFWS syntax is expected to be supported.

Are there interoperability issues with old servers?







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7I2HniK014771; Wed, 17 Aug 2005 19:17:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7I2HncR014770; Wed, 17 Aug 2005 19:17: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 j7I2HlGI014764 for <[e-mail]>; Wed, 17 Aug 2005 19:17:48 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-104.midband.mdip.bt.net ([81.144.75.104]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4303efca.173ae.f for [e-mail]; Thu, 18 Aug 2005 03:17:46 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7I2CBE26919 for [e-mail]; Thu, 18 Aug 2005 03:12:11 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22342
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1080 Injection-info - poll design?
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 17 Aug 2005 16:20:28 GMT
Lines: 63
Sender: [e-mail]
Precedence: 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:


>PROPOSALS I'VE HEARD

>- Junk the current definition, go for multiple header fields

That's the "header zoo". Lacks extensibility, separates related concepts
(information about the injection process), and provides no convenient
mechanism for the injecting admin to tailor his own.

>- Junk the current definition, go for a single Received:-like header field

See my response to Frank.

The remainder are just ways of improving the present text, which I think
all agree has problems as it stands.

>- Remove the dependence on "parameter", specify all ABNF ourselves.
>  Stop accepting 2231 constructs.

Actually, the I18N part of 2231 isn't too bad.

>- As above, but continue accepting 2231 constructs

>- Keep importing "parameter", but clarify what we think it means in
>  modern ABNF. Sort out the ambiguities with the non-parameter pieces.

Actually, this was the way it was done in the old draft-13 (the syntax
provided was not normative). It tackled the specification of the
individual parameters much as I have recently proposed, but with more
verbiage.

>- Change the ABNF to just a parameter-list, and give a table of parameter
>  attribute names with corresponding syntax for values, sidestepping the
>  question of how "parameter" is represented in ABNF

That is what I propose (though with some NOTEs to point out how the
"sidestepped" issues should be appraoched). Note also that the discussion
threw up a few requests for changes (e.g. s/dot-atom/dot-atom-text/),
which are really orthogonal to fixing the descriptive method.

>First question: Is that a reasonable summary of the alternatives that have 
>been proposed?

Yes, I think so.

>(I *think* that the 4 last pieces are a matter of changing how the syntax 
>of the Injection-info parameter is described. The 2 first ones would be 
>throwing out the existing Injection-info and starting over.)

Indeed so.

-- 
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 j7HGIi7F063209; Wed, 17 Aug 2005 09:18:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HGIiat063208; Wed, 17 Aug 2005 09:18: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 j7HGIgXc063198 for <[e-mail]>; Wed, 17 Aug 2005 09:18:43 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-82.midband.mdip.bt.net ([81.144.67.82]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 43036361.17c69.18 for [e-mail]; Wed, 17 Aug 2005 17:18:41 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7HGCEP21269 for [e-mail]; Wed, 17 Aug 2005 17:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22335
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Next steps - please concentrate on USEFOR again
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: Wed, 17 Aug 2005 15:55:47 GMT
Lines: 82
Sender: [e-mail]
Precedence: 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 lørdag, august 13, 2005 22:15:50 +0000 Charles Lindsey 
><[e-mail]> wrote:

>> 2. I propose that the individual terms [reading, posting, followup] agent
>> and [injecting, relaying, serving] agent be defined in and used only in
>> USEPRO. And that in USEFOR the terms "user agent" and "news-server" be
>> used for those two groups (I have not checked in detail, but I think there
>> would be no problem changing USEFOR in that way). All the remaining
>> definitions are already pretty much the same now in USEFOR and USEPRO, and
>> would therefore appear only in USEFOR.

>btw... the term "agent" occurs (in various contexts) 70 times in USEFOR.

Yes, I ought to have examined the implications in more detail before
malking my proposal. I have now looked through the useage of the term in
USEFOR, and I find:

posting agent.

12 occurrences, of which 4 are in definitions that would disappear, and
the remainder could happily be replaced by "user agent".

reading agent.

4 occurrences, of which 3 are in definitions that would disappear, and the
remaining one could happily be replaced by "user agent".

followup agent.

3 occurrences, of which 2 would disappear, but the other, in 3.2.3,
would need some rewording (e.g. "a user agent, when constructing a
followup").

user agent.

5 occurrences, of which 1 would disappear, and the rest would remain
as-is.

injecting agent.

11 occurrences, of which 1 would disappear, 2 (in 3.2.1. and 3.2.14) would
need some rewording, and the remainder could happily be replaced by
"news-server" (though several of these in 3.2.14 might be affected by the
rewording).

relaying agent.

11 occurrences, of which 2 would disappear, and the remainder could
happily be replaced by "news-server".

serving agent.

10 occurrences, of which 1 would disappear, 3 (in 3.2.11) would need some
rewording, and the remainder could happily be replaced by "news-server".

news agent, netnews agent, or just agent.

15 occurrences, of which 5 (in 3.1.6) would be better as "news-server".

Syntactic element <user-agent>.

3 occurrences, to remain as-is.

I make that a total of 74 occurrences (but I was probably counting
slightly differently).

Note that "happily replaced" might well include a slight polishing of the
text for better readability - it is not just a matter of letting a text
editor have its way.

-- 
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 j7HGIgIT063200; Wed, 17 Aug 2005 09:18:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HGIglY063199; Wed, 17 Aug 2005 09:18: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 j7HGIfGr063184 for <[e-mail]>; Wed, 17 Aug 2005 09:18:42 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-82.midband.mdip.bt.net ([81.144.67.82]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 43036360.17c69.17 for [e-mail]; Wed, 17 Aug 2005 17:18:40 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7HGCC521249 for [e-mail]; Wed, 17 Aug 2005 17:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22332
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 17 Aug 2005 14:29:50 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:

><http://article.gmane.org/gmane.ietf.usenet.format/27216>

>What do you think of it ?  It avoids RfC 2231.  What are the
>disadvantages ?

Essentially, it is a different format for the same wheel. It has pairs of
names and values separated by CFWS. The values are 1*angle-addr /
addr-spec / atom / domain / msg-id, some of which are appropriate for our
needs and some not. It provides nothing obviously suitable for the
posting-account and logging-data parameters, and it makes no provision for
any parameters which might contain whitespace within themselves, or for
I18N (both of which might well arise for the two parameters mentioned). So
there is no way that a value could be folded.

It makes no provision for display-names to go with addr-specs (which are
not essential, but I can see they might be handy).

It makes no provision for future parameters in extensions (to be ignored
in the meanwhile), nor for ad-hoc parametets with x-names.

By the time you have fixed all those things, you are more or less back at
MIME parameters. That would bring up the dreaded 2231, of course, but at
least you get semi-decent I18N that way (the only thing wrong with the
2231 I18N is that it is different from all the other I18N fixes that have
been invented over the years). So the only problem left is the line
splitting feature of 2231, which I agree we do not want, and could happily
deprecate.

-- 
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 j7HGIfh7063191; Wed, 17 Aug 2005 09:18:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HGIfDo063190; Wed, 17 Aug 2005 09:18: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 j7HGIeTI063183 for <[e-mail]>; Wed, 17 Aug 2005 09:18:41 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-82.midband.mdip.bt.net ([81.144.67.82]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4303635f.17c69.16 for [e-mail]; Wed, 17 Aug 2005 17:18:39 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7HGCDW21258 for [e-mail]; Wed, 17 Aug 2005 17:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22333
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: Wed, 17 Aug 2005 14:36:54 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]> Bruce Lilly <[e-mail]> writes:

>On Thu August 11 2005 23:45, Frank Ellermann wrote:

>> So 2045 rules about <parameter> don't enter the picture.  If we
>> want <quoted-string> all of <qtext> is okay, incl. "=" and "?".

>Fine as text in a quoted-string, but encoded-words never appear in
>quoted-strings, only in unstructured fields, words in a phrase
>(specifically excluding the other component of phrase), and within
>parenthesized comments.

Actually, you could allow encoded-words within quoted-strings (since a
quoted-string is just an opaque collection of ASCII characters). For sure,
the reader would see them in all their ugliness, because reading agents
would not decode them (unless we go to a lot of trouble to allow that
explicitly, which I would not recommend). OTOH, if a user were to do a
simple copy-and-paste of, say, a mail-complaints-to value into the To:
field of a new email, the encoded word would magically become valid again
and the mail would be sent to the correct destination.

Note that I neither propose nor oppose this idea - I merely point out that
it is possible.

-- 
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 j7HGIe0K063180; Wed, 17 Aug 2005 09:18:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HGIe1j063179; Wed, 17 Aug 2005 09:18: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 j7HGIdj9063173 for <[e-mail]>; Wed, 17 Aug 2005 09:18:39 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-67-82.midband.mdip.bt.net ([81.144.67.82]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 4303635e.17c69.14 for [e-mail]; Wed, 17 Aug 2005 17:18:38 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7HGCEL21265 for [e-mail]; Wed, 17 Aug 2005 17:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22334
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: USEFOR cite by reference vs. rewriting syntax
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 17 Aug 2005 14:45:55 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]> Bruce Lilly <[e-mail]> writes:

>On Fri August 12 2005 00:27, Frank Ellermann wrote:
>> 
>> Apparently they forgot the other issues, NO-WS-CTL and ">" and
>> some kind of "canonical" <msg-id>.

>Then please explain (in a form suitable for an implementation note)
>precisely why such changes are necessary (or specifically which
>existing (not hypothetical) brain-dead implementations get handling
>of msg-ids wrong, and why we shouldn't simply treat such brain-dead
>implementations as non-conforming and move on).

I am not aware of ANY widely deployed news-servers that would operate with
<msg-id>s exactly as defined in RFC 2822. So if you want to characterize
all the people who have implemented such servers over the years (and
expended much time and effort in making them work efficiently) as
"brain-dead", then go ahead.

Or could you please fine ONE example of a news-server that could so cope,
or ONE competent and experienced implementer who would be prepared to
write such a server?

-- 
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 j7HEvOvG055528; Wed, 17 Aug 2005 07:57:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HEvOwI055527; Wed, 17 Aug 2005 07:57:24 -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 j7HEvNMW055520 for <[e-mail]>; Wed, 17 Aug 2005 07:57:23 -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 j7HEvMv7003915 for <[e-mail]>; Wed, 17 Aug 2005 07:57:23 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9C310E7BCC; Wed, 17 Aug 2005 07:57:22 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Wed, 17 Aug 2005 05:27:12 -0400")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 17 Aug 2005 07:57:22 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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 Tue August 16 2005 18:08, Charles Lindsey wrote:

>> We have already agreed to forbid <comment>s in the Path, on account of
>> severe interoperability and performance reasons.

> No, we have not; there are no "sever interoperability" issues which are
> any different than are introduced by MISMATCH, POSTED, "!!", etc. --
> those are changes, and there will be some interoperability issues.
> Introducing ':' as other than a delimiter (its long-standing use) will
> introduce severe interoperability issues.  There are no performance
> issues with introducing comments; that is a red herring.

There are no performance issues with comments provided that servers are
allowed to treat them as Path entries and the ()s as delimiters.  There
are (mild) performance issues if servers are expected to ignore them.
There are (mostly mild but more annoying) performance issues if the full
RFC 2822 CFWS syntax is expected to be supported.

-- 
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 j7HEmpGg054651; Wed, 17 Aug 2005 07:48:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HEmpNS054650; Wed, 17 Aug 2005 07:48:51 -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 j7HEmoUO054641 for <[e-mail]>; Wed, 17 Aug 2005 07:48:51 -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 j7H2L5tS014871; Tue, 16 Aug 2005 22:21:05 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7H2L5Zr014870; Tue, 16 Aug 2005 22:21:05 -0400 (EDT)
Date: Tue, 16 Aug 2005 22:21:04 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: USEFOR cite by reference vs. rewriting syntax
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, 16 Aug 2005, Bruce Lilly wrote:
> ...250 is hopelessly irrational...

The rational (unfortunate, but rational) reasons for that limit have been
explained to you repeatedly, the first time on 25 Feb 2003.

                                                          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 j7H9RPkT046752; Wed, 17 Aug 2005 02:27:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H9RPK8046751; Wed, 17 Aug 2005 02:27:25 -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 j7H9ROW3046734 for <[e-mail]>; Wed, 17 Aug 2005 02:27:24 -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 2AFB5299FF; Wed, 17 Aug 2005 05:27:23 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7H9RIWj003232(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, 17 Aug 2005 05:27:22 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7H9RHUN003231(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, 17 Aug 2005 05:27:17 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Wed, 17 Aug 2005 05:27:12 -0400
User-Agent: KMail/1.8.2
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 August 16 2005 18:08, Charles Lindsey wrote:

> We have already agreed to forbid <comment>s in the Path, on account of
> severe interoperability and performance reasons.

No, we have not; there are no "sever interoperability" issues which are
any different than are introduced by MISMATCH, POSTED, "!!", etc. -- those
are changes, and there will be some interoperability issues.  Introducing
':' as other than a delimiter (its long-standing use) will introduce severe
interoperability issues.  There are no performance issues with introducing
comments; that is a red herring.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7H7psrx012490; Wed, 17 Aug 2005 00:51:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H7ps1U012489; Wed, 17 Aug 2005 00:51: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 j7H7pr7M012475 for <[e-mail]>; Wed, 17 Aug 2005 00:51:53 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5Igr-0007ia-Ok for [e-mail]; Wed, 17 Aug 2005 09:50:25 +0200
Received: from du-001-121.access.de.clara.net ([212.82.227.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 17 Aug 2005 09:50:25 +0200
Received: from nobody by du-001-121.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 17 Aug 2005 09:50:25 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1053 Relationship to RFC 2822 - suggestion
Date:  Wed, 17 Aug 2005 09:48:52 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
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-121.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:

> Saying nothing at all would fulfil that aim.

ACK so far.

> s/obs-phrase/<obs-phrase>/
> and maybe mention that it is really an extended-phrase,
> and RFC 2822bis will undoubtedly rename it.

NAK, that's an 2822-oddity, we have more than enough own
oddities, renaming <obs-phrase> isn't our job.

> mention that "GMT" is extracted from <obs-zone>.

The proposal is for the intro, chapter 2.1, the details
+ rationale for GMT are explained in 3.1.2, doing this
twice doesn't help.  The "message" of chapter 2.1 is
"2822 minus obs, but keeping two popular obs-ceneties".

Details would be a destraction at this point (in 2.1).

                   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 j7H7Rxq7002208; Wed, 17 Aug 2005 00:27:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H7Rxhl002207; Wed, 17 Aug 2005 00:27: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 j7H7Rw3D002184 for <[e-mail]>; Wed, 17 Aug 2005 00:27:58 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5IJh-0002jp-4s for [e-mail]; Wed, 17 Aug 2005 09:26:29 +0200
Received: from du-001-121.access.de.clara.net ([212.82.227.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 17 Aug 2005 09:26:29 +0200
Received: from nobody by du-001-121.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 17 Aug 2005 09:26:29 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1053 Relationship to RFC 2822 - suggestion
Date:  Wed, 17 Aug 2005 09:16:16 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 75
Message-ID:  <[e-mail]>
References:  <[e-mail]> <C2222176E2EB0FD360CC09C2@B50854F0A9192E8EC6CDA126> <[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-121.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:

> If article syntax is fully conformant and compatible with
> RFC 2822, there is no need for even a gateway to perform any
> modifications.

That's of course wrong, A <-- gateway --> B.  The gateway has
to transform A-format into B-format (or vice versa), and it
only gets away with no modifications for a proper subset A'
of A which happens to be also a subset of B.

So if it gets a valid 8bit NetNews article and sends it to a
mailing list it might have to modify it for 7bit as needed.

If the news article was in MIME format there's even a serious
chance to get it right.  One of the reasons why we say "MUST
support MIME", and why s-o-1036 pushed for MIME 11 years ago.

Similar problems in the opposite direction, watch the magic SP,
modify In-Reply-To to References if there are none, create a
Message-ID if there is none (but take care with that detail),
the works.

You can even operate Fido <--> RfC gateways, the special case
Internet / mail <--> news / Usenet is relatively simple.  The
most difficult part is to deter idiots from causing havoc, it's
not as trivial as "garbage in garbage out" (GiGo was a broken
gateway product a decade ago).

> once you (yes, you Frank) insist on a difference from 2822,

There _are_ differences, I didn't _invent_ them.  I was a Fido
user when Henry wrote s-o-1036.  And he also didn't _invent_
them, he found them, trying to minimize them.  Same procedure
as now 11 years later.

> gateways are forced into making modifications

That's the definition of a gateway, yes.

> (or being anal retentive and rejecting submitted messages)

Sure, before you cause havoc reject.  That's not "anal", that's
your responsibilty as gateway operator.  Or as an admin of any
public server.

> Wasn't it also you, Frank, who pointed to gmane as an example
> of a "gateway" that specifically made msg-id modifications?

Yes, and it's no problem in this case, GMaNe isn't a mailing
lists <--> UseNet gateway, it's mailing lists <--> News, only
on its own server.  GMaNe "pretends" that mailing lists are
moderated newsgroups using its own gmane.all newsgropus names.

That has some consequences if the "same" Message-ID arrives
at different times in different lists.  Unlike Usenet a mail
Message-ID doesn't guarantee identity, if list A did this
with the mail, and list B did that with the same mail, then
what GMaNe sees are in fact slightly different articles with
the same Message-ID.  Therefore it has to do something about
it in this case.  It's mostly transparent for the users.

> The best thing to do is to minimize the differences from
> 2822 to the absolute minimum, with rationale for each and
> a roadmap to full compatibility.

That roadmap is _ready_ for the <msg-id>, you find (a variant
of) it in the Usefor draft.  2822bis will copy it as is for
its future "chapter 3", moving NO-WS-CTL and other creatures
to its future obs-chapter where they can die.

Maybe it won't adopt the less convincing idea to forbid ">" or
the length limit, but after another iteration we might end up
with one syntactically identical concept for both worlds.  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 j7H7Fu86097734; Wed, 17 Aug 2005 00:15:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H7Fusi097733; Wed, 17 Aug 2005 00:15:56 -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 j7H7Ft1K097718 for <[e-mail]>; Wed, 17 Aug 2005 00:15:56 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7CDF32009C for <[e-mail]>; Wed, 17 Aug 2005 09:15:45 +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 06436-05 for <[e-mail]>; Wed, 17 Aug 2005 09:15: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 E91FD320096 for <[e-mail]>; Wed, 17 Aug 2005 09:15:41 +0200 (CEST)
Date: Wed, 17 Aug 2005 09:15:47 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Re: #1080 Injection-info - poll design?
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: by 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, august 16, 2005 20:13:18 -0400 Bruce Lilly <[e-mail]> 
wrote:

>> This introduces some oddities, including ambiguity on whether or not
>> spaces  are allowed around the equal signs,
>
> That's not ambiguous. 2045 and 2231 are based on 822, and spaces (and tabs
> and comments and line folding) are allowed on either side of the '='

It's not ambiguous whether spaces are allowed around the equal signs in 
"parameter".

But if the ABNF as given was intended as modern ABNF, this:

   sender-param    =  "sender" "=" sender-value

doesn't allow spaces around the equal sign. I can't tell whether that was 
intentional or a mistake. If it's intentional, it's inconsistent with 
"parameter"; if it's a mistake, it needs fixing.

                      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 j7H656Nk068884; Tue, 16 Aug 2005 23:05:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H656DY068883; Tue, 16 Aug 2005 23:05:06 -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 j7H654XJ068860 for <[e-mail]>; Tue, 16 Aug 2005 23:05:05 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E5H2s-0003FB-7f for [e-mail]; Wed, 17 Aug 2005 08:05:02 +0200
Received: from du-001-121.access.de.clara.net ([212.82.227.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 17 Aug 2005 08:05:02 +0200
Received: from nobody by du-001-121.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 17 Aug 2005 08:05:02 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 Injection-info - poll design?
Date:  Wed, 17 Aug 2005 08:02:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 37
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: du-001-121.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:
 
> You may be conflating MIME encoded-words
[...]
> with MIME parameters

Yes, your "unified ABNF" is about the former.
  
>> Maybe the last could also work for Bruce's Received-concept.

> The last = "sidestepping [actual specification]" won't pass
> IETF Last Call.

I don't see why that should be a problem.  A general syntax
for the list, either *( name "=" value ) or *( name value ),
the latter is the variant for your concept, a set of names,
name = "for" / "from" / "by" or similar for your concept, or
name = "posting-host" / etc.

Either value = quoted-string or what you propose.  Specific
syntax for various values:  from-value = id-domain etc.

In your variants #2 and #3 you have a general value-syntax.

> I support the separate Injection-Date field as that provides
> the simplest possible parsing and doesn't mix protocol
> information with human-readable tracing trivia.

Fine, so I don't need to say that we should reserve the right
to reopen the Injection-Date ticket if your concept (number 2
on Harald's list) is used for the rest of this zoo.

In the case of Harald's 1 another way to get a similar effect
would be to use Injection-* field names.  The purpose is to
get rid of the complete zoo for the obscure "re-injection":
Kill all old Injection-*, insert new Injection-*.  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 j7H396uo027185; Tue, 16 Aug 2005 20:09:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H396qn027184; Tue, 16 Aug 2005 20:09:06 -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 j7H396cG027177 for <[e-mail]>; Tue, 16 Aug 2005 20:09:06 -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 j7H393fD009709 for <[e-mail]>; Tue, 16 Aug 2005 20:09:05 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 1598AE7BCC; Tue, 16 Aug 2005 20:09:03 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Sun, 14 Aug 2005 09:10:07 -0400")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]>
Date: Tue, 16 Aug 2005 20:09:03 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> That fails to indicate *why* syntax is specified to be "more
> restrictive" (in the case of "GMT" it is in fact *less* restrictive,
> which is inconsistent with the claim of being "more restrictive").  It
> also fails to provide a roadmap to full conformance with the Internet
> Message Format, which we are agreed is desirable.

Desireable, maybe.  It's only going to be possible if the Internet Message
Format gets considerably more restrictive about message IDs, to name one
major issue.  Until that happens, we won't ever be completely identical to
the RFC 2822 (or successor) format.

-- 
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 j7H2NB20023739; Tue, 16 Aug 2005 19:23:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H2NBXd023738; Tue, 16 Aug 2005 19:23: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 j7H2NAaC023729 for <[e-mail]>; Tue, 16 Aug 2005 19:23:10 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-66-144.midband.mdip.bt.net ([81.144.66.144]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 43029f8c.10336.36 for [e-mail]; Wed, 17 Aug 2005 03:23:08 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7H2CA413905 for [e-mail]; Wed, 17 Aug 2005 03:12:10 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22320
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 16 Aug 2005 21:31:44 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]> Harald Tveit Alvestrand <[e-mail]> writes:

>Current text from 2.1:

Yes, I agree the current text is a bit too terse. The new one is better,
but maybe needs a little polishing.


>Suggested, expanded text:

>2.1  Base

>   An article is said to be conformant to this specification if it
>   conforms to the format specified in RFC 2822 section 3 and to the
>   additional requirements of this specification.

"An article is conformant ...".

>   An article that uses the obsolete syntax specified in section 4 of
>   [RFC2822], except for the two exceptions mentioned below, is NOT
>   conformant to this specification.

Might be simpler to give the two exceptions, bulleted, at this point, to
save people having to backtrack later.

>   This document, and specifications that build upon it, specifies how
>   to handle conformant articles. Handling of non-conformant articles
>   is outside the scope of this specification; agents may choose
>   to accept such articles, reject such articles or modify such articles.

That "modify" has attracted much comment.

The current situation, within USEPRO, is that articles may only be
modified in three circumstances (variant headers apart):

1. Injecting agents are permitted a heavily circumscribed list of changes
(that list was heavily fought over long long ago, so please do not reopen
it now).

Observe that "fixing" things that are broken is NOT in that list, and the
consensus in the recent discussion seems to be that it should not be. An
injecting agent is near enough to the original poster to be able to get
an error message back to him. So you reject the malformed article and
invite him to fix it.

2. Moderators have a limited authority to change things.

3. Gateways are permitted to change whatever is necessary to make the
article suitable for the new medium (and detailed examples of likely
problems are discussed). Beyond that, they should leave things alone.

Observe that relaying and serving agents have only two options open to
them. Either accept the article as is (warts and alleged brokenness and
all - then it becomes someone else's proplem), or else drop it on the
floor silently.

So whatever you say about modification, make sure that it is only
modifications explicitly permitted by our standard or its extensions.
Saying nothing at all would fulfil that aim.

>   Agents conforming to this specification MUST generate only conformant
>   articles.

Care is needed with the meaning of "generate", as others have mentioned.
Agents involved in transport are not obliged to check everything, and may
thus (inadvertently or by design) pass articles that are dubious (someone
else's problem - see above). So I think "generate" only applies strictly
to posting agents, or other places where modifications (incl. variant
headers) are made.

>   Articles are conformant if they use 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.

"...but productions of such syntax MUST NOT be generated."
s/obs-phrase/<obs-phrase>/
and maybe mention that it is really an extended-phrase, and RFC 2822bis
will undoubtedly rename it.

>   Articles are conformant if they use the "GMT" timezone, as specified
>   in section 3.1.2.

mention that "GMT" is extracted from <obs-zone>.

>   The text below uses ABNF to specify restrictions on the syntax
>   specified in [RFC2822]; this grammar is intended to be more restrictive
>   than the RFC 2822 grammar.
>   Articles must conform to both the ABNF specified in RFC 2822 and to the
>   ABNF specified here, as applicable.

Various people have commented on this.

"Articles must conform to the ABNF specified in RCFC 2822, except insofar
as it is superseded/extended/modified by this specification/standard.
Observe that the forms permitted by this specification/standard
nevertheless remain a strict subset of those permitted by RFC 2822."

Observe that there are two 's's in "superseded" :-) .

-- 
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 j7H2NAZ0023731; Tue, 16 Aug 2005 19:23:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H2NA60023730; Tue, 16 Aug 2005 19:23: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 j7H2N85r023714 for <[e-mail]>; Tue, 16 Aug 2005 19:23:09 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-66-144.midband.mdip.bt.net ([81.144.66.144]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 43029f8b.10336.35 for [e-mail]; Wed, 17 Aug 2005 03:23:07 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7H2CCv13919 for [e-mail]; Wed, 17 Aug 2005 03:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22322
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 16 Aug 2005 22:05:46 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:

>At the moment, I have

>- My suggestion to separate "diagnostic information" from "identities"; in 
>the syntax, the result is that parsers need to expect both.

This is where USEPRO and USEFOR interact, so we need to fix both together.

At present, the word "diagnostic" is not used, so it would need
definition. The only examples of "diagnostic" mentioned to date have been
where an agent inserts into the Path the observed origin of an article
(which may be different from the claimed identity inserted by the sending
site). Are there any other "diagnostics" people have in mind? Currently,
the only example permitted is in conjunction with the MISMATCH keyword,
but I think we are agreed that other cases should be explicitly allowed
(with or without extra syntax such as SEEN/MATCH/MISMATCH).

>- A lot of debate on where and why IP addresses occur in the path, 
>including some ideas from Charles about annotating the IP addresses with 
>extra syntax that allows some more intelligent guessing on why they were 
>added

>My current suggestion for SYNTAX (that is, what goes into USEFOR)

>- Specify "identities" as domain-names or barewords, period

>- Specify that "diagnostics" are PERMITTED in the path, and that this 
>standard does not restrict the format of diagnostics very much (in fact, 
>permit all of [A-Za-z0-9.:], and then shut up)

But that allows ":" in all sorts of places where they are not needed. The
beauty of your earlier proposal was that ":" could ONLY occur within an
<IPv6Address> (and I think we are agreed that IP-addresses are going to be
present, at least as diagnostics, in which case there are going to be
<Ipv6Addresses> whether we like it or not).

But if <Ipv6Address>es are going to be present, then the <bareword>s
"dead", "beef", etc. are going to cause trouble with agents that still
think ":" is a delimiter (not that I think this "trouble" is a serious
showstopper). But if you allow ":"s anywhere within diagnostics, then the
"trouble" (such as it is) could also occur with innocent <bareword>s such
as "wolf" and "demon".

>- Permit : in "diagnostics", not in "identities", and add some appropriate 
>note with warnings on what will happen to DEAD:BEEF:CAFE

But given that the "dead/beef" problem has not been eliminated by your
proposal, what do you actually gain by forbidding IP-addresses in
"identities"? The cat is already out of the bag. You are bolting the
stable door after the horse has bolted (so I shall nip it in the bud :-)
). [Sorry, joke might be hard for Norwegians, but Englishmen with a
smattering of Irish politics should get it.]

I grant you that, if IP-addresses are permitted in identities, there are
grounds for deprecating them (as there are for <bareword>s), but not at a
level justifying "MUST" wording.

And note also that an <Ipv4Address> is a <bareword> :-( .

>Does this make sense?

Not really.

-- 
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 j7H2N8cl023720; Tue, 16 Aug 2005 19:23:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H2N8AV023719; Tue, 16 Aug 2005 19:23: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 j7H2N77N023704 for <[e-mail]>; Tue, 16 Aug 2005 19:23:08 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-66-144.midband.mdip.bt.net ([81.144.66.144]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 43029f8a.10336.34 for [e-mail]; Wed, 17 Aug 2005 03:23:06 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7H2CBT13913 for [e-mail]; Wed, 17 Aug 2005 03:12:11 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22321
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 16 Aug 2005 21:36:52 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]> Bruce Lilly <[e-mail]> writes:

>That fails to indicate *why* syntax is specified to be "more restrictive"
>(in the case of "GMT" it is in fact *less* restrictive, which is
>inconsistent with the claim of being "more restrictive").  It also fails
>to provide a roadmap to full conformance with the Internet Message Format,
>which we are agreed is desirable.  There is also the issue of field and
>field component naming conflicts with 2822.  And any remaining differences
>are going to have to be dealt with by gateways, so we ought to take time
>to carefully review the implications and relevant USEPRO text regarding
>gateways before finalizing USEFOR.

On the contrary, we have NOT agreed that a roadmap to full conformance
with the Internet Message Format is desirable. Indeed, there are some
differences which are intended to remain permanently different from RFC
2822, except insofar as some RFC 2822bis may agree to an adjustment (which
many of us will be pressing for at the proper time).

-- 
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 j7H2N8HO023711; Tue, 16 Aug 2005 19:23:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H2N8FB023710; Tue, 16 Aug 2005 19:23: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 j7H2N7Oq023703 for <[e-mail]>; Tue, 16 Aug 2005 19:23:07 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-66-144.midband.mdip.bt.net ([81.144.66.144]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 43029f8a.10336.33 for [e-mail]; Wed, 17 Aug 2005 03:23:06 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7H2CDO13923 for [e-mail]; Wed, 17 Aug 2005 03:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22323
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 16 Aug 2005 22:08:40 GMT
Lines: 21
Sender: [e-mail]
Precedence: 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:

>We then need to specify clearly how diagnostics are distinguished from
>"identities" (and keywords, unless keywords are eliminated).  One
>possible mechanism would be to put diagnostics in RFC 2822 comments,
>in which case they are clearly separated into human-readable but
>semantically invisible content, and there is no need for keywords.

We have already agreed to forbid <comment>s in the Path, on account of
severe interoperability and performance reasons.

-- 
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 j7H0waF7016458; Tue, 16 Aug 2005 17:58:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H0waBk016457; Tue, 16 Aug 2005 17:58:36 -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 j7H0wZW2016451 for <[e-mail]>; Tue, 16 Aug 2005 17:58:35 -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 j7H0wWNb022575 for <[e-mail]>; Tue, 16 Aug 2005 17:58:33 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6F7F1E7BCC; Tue, 16 Aug 2005 17:58:32 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: USEFOR cite by reference vs. rewriting syntax
In-Reply-To: <[e-mail]> (Bruce Lilly's message of "Tue, 16 Aug 2005 20:49:33 -0400")
Organization: The Eyrie
References: <601268628DF794B0F045EA97@[10.61.81.74]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 16 Aug 2005 17:58:32 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> NNTP (RFC 977) has a limit of ca. 500 octets.  Lower than the 997 octets
> imposed by 2822, but not hopelessly irrationally low (i.e. it's not
> lower than the longest legal domain name).  250 is hopelessly
> irrational; do you suppose that no DNS experts will notice the problem
> during IETF Last Call?

The NNTP draft currently sitting in the RFC Editor's queue imposes a limit
of 250 characters.  Neither two IETF Last Calls nor an IESG review turned
up any objections.  Please see the extensive previous discussion in this
list that was behind the original decision.  Yes, it's an arbitrary
number; it's also a *safe* arbitrary number already imposed by deployed
software that poses no difficulties in practice.

>> That also explains other details like VCHAR excl. ">", and why there
>> can't be different Message-IDs with the same semantics.

> No, RFC 977 says none of those things.

I assure you that RFC 977 will be obsoleted by the time USEFOR manages to
publish.

-- 
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 j7H0nfCr015455; Tue, 16 Aug 2005 17:49:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H0nfJw015454; Tue, 16 Aug 2005 17:49:41 -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 j7H0negc015447 for <[e-mail]>; Tue, 16 Aug 2005 17:49: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 ns4.townisp.com (Postfix) with ESMTP id 1FA86299DD; Tue, 16 Aug 2005 20:49:40 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7H0nbVN005856(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, 16 Aug 2005 20:49:39 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7H0na2o005855(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, 16 Aug 2005 20:49:37 -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
Date: Tue, 16 Aug 2005 20:49:33 -0400
User-Agent: KMail/1.8.2
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 Mon August 15 2005 17:03, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > please explain (in a form suitable for an implementation
> > note) precisely why such changes are necessary (or
> > specifically which existing (not hypothetical) brain-dead
> > implementations get handling of msg-ids wrong
> 
> I've already proposed pure ABNF, it's IMHO obvious.

Changed ABNF doesn't explain *why*, *who*, or *how* to get to convergence
with other Internet Message Format applications.

> For 
> the limit 250 we'll have a reference to the NNTP standard.

NNTP (RFC 977) has a limit of ca. 500 octets.  Lower than the 997 octets
imposed by 2822, but not hopelessly irrationally low (i.e. it's not lower
than the longest legal domain name).  250 is hopelessly irrational; do you
suppose that no DNS experts will notice the problem during IETF Last Call?

> That also explains other details like VCHAR excl. ">", and
> why there can't be different Message-IDs with the same
> semantics.

No, RFC 977 says none of those things.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7H0egOA014393; Tue, 16 Aug 2005 17:40:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H0egfE014392; Tue, 16 Aug 2005 17:40:42 -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 j7H0efVF014384 for <[e-mail]>; Tue, 16 Aug 2005 17:40: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 6C40C29986; Tue, 16 Aug 2005 20:40:40 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7H0eb3J003462(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, 16 Aug 2005 20:40:37 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7H0easK003445(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, 16 Aug 2005 20:40:37 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1080 Injection-info - poll design?
Date: Tue, 16 Aug 2005 20:40:30 -0400
User-Agent: KMail/1.8.2
Cc: Frank Ellermann <[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 Mon August 15 2005 12:35, Frank Ellermann wrote:

> Bruce has a kind of "unified message syntax" integrating
> MIME, and it's IMHO difficult to get this right.

You may be conflating MIME encoded-words (RFC 2047 as amended by 2231
and errata) with MIME parameters (2045 as expected to eventually be
amended by a missing-in-action erratum-to-be and by 2231 and errata).
There is an ABNF grammar that incorporates a simplification of 2822
with the former, but it does not address the latter, which is orthogonal
to 2822.

> > I *think* that the 4 last pieces are a matter of changing
> > how the syntax of the Injection-info parameter is described.
> 
> Maybe the last could also work for Bruce's Received-concept.

The last = "sidestepping [actual specification]" won't pass IETF
Last Call.
 
> I don't like the first idea (header field zoo), but OTOH if
> we are not smart enough to find a good working combination
> (or unable to agree on one, or need another year for it),
> then we better pick a zoo of simple header fields.  After
> all that's as it is today.

A good carpenter or other craftsman has a toolbox consisting of many
tools, each of which does one thing (or a very few things) well.  A
Swiss Army knife is convenient for emergency use (e.g. hacking a tree
limb into a splint to stabilize a broken bone), but is no substitute
for a craftsman's toolbox; it is not as efficient for any one use as
the corresponding dedicated craftsman's tool.  We should be crafting
a well-designed format and protocol, not hacking things together (or
encouraging such hacking (e.g. x- values).

The reason that there is a separate Injection-Date field is to serve
a particular purpose in a manner which is amenable to efficient
implementation (i.e. w/o having to handle all of the gory 2231
syntax).  Even though it's possible to avoid 2231 contortions and
still combine the injection timestamp with other information (as is
done with the Received field (a.k.a. time stamp line), in the case
of news protocols the injection timestamp is used automatically and
frequently, whereas the Received fields "are primarily intended for
humans tracing" information.  So, while I'm not opposed to combining
the time stamp with other information provided it can be parsed
easily and efficiently, I support the separate Injection-Date field
as that provides the simplest possible parsing and doesn't mix
protocol information with human-readable tracing trivia.

Or to return to your "zoo" analogy; I prefer animals with familiar
but distinct characteristics.  You are free to try to cross a cow with
a bird to get a flying cow, but personally I wouldn't want to be
underneath your critter when it's flying and defecating at the same
time.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7H0DbRW012104; Tue, 16 Aug 2005 17:13:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H0Db4D012103; Tue, 16 Aug 2005 17:13:37 -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 j7H0Dahn012096 for <[e-mail]>; Tue, 16 Aug 2005 17:13:37 -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 8022C299DD; Tue, 16 Aug 2005 20:13:35 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7H0DUVO027309(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, 16 Aug 2005 20:13:31 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7H0DS7s027306(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, 16 Aug 2005 20:13:30 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1080 Injection-info - poll design?
Date: Tue, 16 Aug 2005 20:13:18 -0400
User-Agent: KMail/1.8.2
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 Mon August 15 2005 06:33, Harald Tveit Alvestrand wrote:
> 
> No, I'm not going to run a poll on this one yet.
> First, I have to figure out what alternatives are on, near or off the 
> table...
> 
> CURRENT: Section 3.2.14 specifies an ABNF for the field that includes a 
> number of parameter definitions, in "name=value" format, and allows the 
> "parameter" ABNF entry.
> "parameter" is imported from 2045+2231, according to section 1.4.
> This introduces some oddities, including ambiguity on whether or not spaces 
> are allowed around the equal signs,

That's not ambiguous. 2045 and 2231 are based on 822, and spaces (and tabs
and comments and line folding) are allowed on either side of the '='
[confirmed by correspondence with one of the RFC authors].

> and one RHS that isn't a "value"  
> (posting-host contains :)

Problems with use of address-list have also been identified.
  
> PROPOSALS I'VE HEARD
> 
> - Junk the current definition, go for multiple header fields
> 
> - Junk the current definition, go for a single Received:-like header field

It would be more accurate to state that the current text *is* junk (i.e. has
many known technical problems), and that it is "the current definition" only
because it is a document editor's personal idea; other ideas have not been
included by the document editor, and the document editor has not withdrawn his
problematic proposal.

The above two items are not necessarily mutually exclusive; e.g. Complaints-To
could be used for a specific purpose enabling UA assistance in preparation of
complaint messages, while purely human readable trace information could be in
a separate field.
 
> - Remove the dependence on "parameter", specify all ABNF ourselves.
>   Stop accepting 2231 constructs.

I believe that Frank suggested that at one point but has subsequently
withdrawn that proposal.
 
> - As above, but continue accepting 2231 constructs

1. Good luck; it's not easy
2. section 1.6: "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."
 
> - Keep importing "parameter", but clarify what we think it means in
>   modern ABNF. Sort out the ambiguities with the non-parameter pieces.

Not significantly different from the above.

> - Change the ABNF to just a parameter-list, and give a table of parameter
>   attribute names with corresponding syntax for values, sidestepping the
>   question of how "parameter" is represented in ABNF

a) that won't help with issues like address-list containing possible encoded-words,
   comments, etc.
b) if the IESG is doing its job, that won't pass IESG muster as it will be an
   incomplete (viz. insufficient for interoperability) specification; it will
   certainly generate negative comments during IETF Last Call.
 
> First question: Is that a reasonable summary of the alternatives that have 
> been proposed?

Modulo "spin", Frank's possibly retracted proposal, redundant (duplicate)
descriptions of the same thing,...



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GN7bwu006755; Tue, 16 Aug 2005 16:07:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GN7b65006754; Tue, 16 Aug 2005 16:07:37 -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 j7GN7aV4006748 for <[e-mail]>; Tue, 16 Aug 2005 16:07:36 -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 B5AC729912; Tue, 16 Aug 2005 19:07:34 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7GN7Xtw009378(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, 16 Aug 2005 19:07:33 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7GN7WdK009375(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, 16 Aug 2005 19:07:33 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Date: Tue, 16 Aug 2005 19:07:23 -0400
User-Agent: KMail/1.8.2
Cc: Frank Ellermann <[e-mail]>
References: <[e-mail]> <C2222176E2EB0FD360CC09C2@B50854F0A9192E8EC6CDA126> <[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 August 15 2005 11:21, Frank Ellermann wrote:

[off-topic digression]
> It could be like the CRLF in 2234bis:  Bruce proposed to say
> [CR] LF, maybe ( [CR] LF ) / CR would be more accurate.  But
> the best solution it to stick to CRLF as the only "line end"
> in ABNF.

As both of the implementations cited in the so-called interoperability
report for ABNF in fact implement what was proposed for possible
corrections to the specification (one does one thing, the other does
the other), *and* as actual drafts and RFCs using ABNF do not contain
CRLF unless modified from their native form in the IETF repository,
the ABNF specification as written really has a problem that ought to
be addressed (several problems actually, that's just one of them).

We now return to on-topic issues...
 
> "message modification" is a real taboo.
> 
> Of course some gateway operators will know it better, but for
> those who don't know it the more important message is "never
> try to 'fix' messages".

If article syntax is fully conformant and compatible with RFC 2822, there
is no need for even a gateway to perform any modifications.  But once you
(yes, you Frank) insist on a difference from 2822, then gateways are
forced into making modifications (or being anal retentive and rejecting
submitted messages).  Wasn't it also you, Frank, who pointed to gmane as
an example of a "gateway" that specifically made msg-id modifications?
Sorry Frank, you can't have your cake and eat it too.
 
> > We don't want to open the pandora's box of specifying which
> > changes are OK and which are not.
> 
> Yes, only the specified modifications are allowed.  All other
> modifications are formally illegal - they can have dangerous
> side effects.  E.g. destroy header signatures.  Or with our
> funny length limit for the <msg-id> and other less obscure
> restrictions, whatever a mai2news gateway decides to do with
> an invalid <msg-id>, it will be wrong.  The least damage is
> probably "reject" depending on the gateway.

The best thing to do is to minimize the differences from 2822 to the
absolute minimum, with rationale for each and a roadmap to full
compatibility.
 
> > The situation I'd like to handle cleanly:
> >  - Person A: Person B's server mangled my article!
> >  - Person B: Person A's article was broken - I repaired it!
> >  - Person A: But the standard says you can't change articles!
>  
> > I'd like Person B to say "Your article was broken, so it's
> > outside the rules", and Person A to say "OK, I agree the
> > standard says that, I'll fix my UA and stop whining" (or
> > whatever).
> 
> Tricky.  How do you define "repair" for a broken / missing
> <msg-id>, or utter dubious MESSFOR-minus-USEFOR <msg-id>s ?

During transport, only Path should be modified, and only in 
specified ways.  In the given example, I'd expect "B" to say "OK, I
agree that articles shouldn't be modified (other than trace fields) in
transit, and I'll fix my server accordingly; it will silently drop
broken [non-]articles".
 
> A mail2news gateway will be hit by stuff legal in mail but
> not news.  There are many ways to (try to) "fix" problems,
> and for most wannabe-solutions you'd find cases where they
> fail miserably making it worse.

Again, the best way to minimize that problem is to minimize the
differences from 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 j7GGfOll073117; Tue, 16 Aug 2005 09:41:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GGfOD4073116; Tue, 16 Aug 2005 09:41: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 j7GGfNnv073109 for <[e-mail]>; Tue, 16 Aug 2005 09:41:23 -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 j7GGf13u074598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 16 Aug 2005 09:41:01 -0700 (PDT)
Date: Tue, 16 Aug 2005 09:41:17 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: ADMIN: Please refrain from the insults
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>

I responded more fully offlist, but a public correction to a public 
mistatement is required.

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>1) Please stop insulting other participants. It's not useful.
>2) Even when being insulting, we have a responsibility to read the 
>postings we're replying to.

Considering the subject of this article, the second admonition is 
particularly insulting. Not the words directly, but the implication.

> Frank's "somebody" is you, John.

I know that. I said as much. It's kind of obvious.

>Frank's pointing out that Bruce is using an elided identity ("your 
>$somebody") to refer to Charles.

Bruce didn't use "elided identities", Frank did. Frank was consistent in
removing not Charles's name but mine. Pretending that Frank was referring
to Charles when he did it is simply ridiculous, and a sign that someone
has not read the article, much less the thread in which it appeared.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GCj6VI027950; Tue, 16 Aug 2005 05:45:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GCj6Lm027949; Tue, 16 Aug 2005 05:45:06 -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 j7GCj5o8027928 for <[e-mail]>; Tue, 16 Aug 2005 05:45:06 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 106DB32009C; Tue, 16 Aug 2005 14:44:56 +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 06757-10; Tue, 16 Aug 2005 14:44:53 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA56232009B; Tue, 16 Aug 2005 14:44:33 +0200 (CEST)
Date: Tue, 16 Aug 2005 12:13:52 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: ADMIN: Please refrain from the insults (Re: #1080 - MIME parameters for Injection-Info)
Message-ID: <B7EEA7DC338905CE133F0040@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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>

1) Please stop insulting other participants. It's not useful.
2) Even when being insulting, we have a responsibility to read the postings 
we're replying to.

--On 15. august 2005 11:34 -0700 John Stanley <[e-mail]> wrote:

> Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:
>
>> In that case it's tricky, your $Somebody is the editor or his
>> co-author.
>
> That "somebody" you keep eliding is me. No, I am not the editor or his
> co-author. Where you got the idea I was either is beyond comprehension.

Frank's "somebody" is you, John. Frank's pointing out that Bruce is using 
an elided identity ("your $somebody") to refer to Charles.

                 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 j7G6gQ4n096282; Mon, 15 Aug 2005 23:42:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G6gQJY096281; Mon, 15 Aug 2005 23:42: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 j7G6gPDu096266 for <[e-mail]>; Mon, 15 Aug 2005 23:42:25 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 22E1632009B; Tue, 16 Aug 2005 08:42: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 31568-04; Tue, 16 Aug 2005 08:42:12 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF6F3320099; Tue, 16 Aug 2005 08:42:11 +0200 (CEST)
Date: Tue, 16 Aug 2005 08:12:59 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: "Forrest J. Cavalier III" <[e-mail]>, [e-mail]
Subject: Re: #1080 Injection-info - poll design?
Message-ID: <933F071A164865A86FAE3D1B@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by 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 15. august 2005 13:06 -0400 "Forrest J. Cavalier III" 
<[e-mail]> wrote:

>> Harald has already indicated that the issue with Injection-Date is
>> closed. Let's not reopen it.
>>
>
> Do you mean that closing (dropping) the header field Injection-Date means
> omitting the injection date from the Injection-Info header field too?

Can't parse this, so I'll explain what I think the facts are instead.

What I meant was that in discussion of ticket #1048, which was closed with 
"No change needed", Frank suggested moving the injection-date into 
injection-info.
After discussion on the list, I decided that there was no strong support 
for doing this, and closed the ticket (which was originally about something 
else).

                        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 j7FL6qam006711; Mon, 15 Aug 2005 14:06:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FL6qCZ006710; Mon, 15 Aug 2005 14:06:52 -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 j7FL6orL006702 for <[e-mail]>; Mon, 15 Aug 2005 14:06:50 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4m8P-0001BC-LE for [e-mail]; Mon, 15 Aug 2005 23:04:41 +0200
Received: from c-180-160-193.hh.dial.de.ignite.net ([62.180.160.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 23:04:41 +0200
Received: from nobody by c-180-160-193.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 23:04:41 +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:  Mon, 15 Aug 2005 23:03:25 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 25
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-193.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:

> please explain (in a form suitable for an implementation
> note) precisely why such changes are necessary (or
> specifically which existing (not hypothetical) brain-dead
> implementations get handling of msg-ids wrong

I've already proposed pure ABNF, it's IMHO obvious.  For
the limit 250 we'll have a reference to the NNTP standard.
That also explains other details like VCHAR excl. ">", and
why there can't be different Message-IDs with the same
semantics.

Charles' version needs more prose because it isn't obvious
for some details:  What's an <id-right>, why can't I just
use whatever I like, what's a collision, how can I calculate
the probability, what's a name space owner, can I cancel
abuses of my name space, can I sue the offending party, is
software using random IDs broken by design, can I sue the
vendor, etc.  BTW, I'd say "yes" for the last four points.

[Your point about gateways addressed in a reply to Harald]

                           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 j7FIpGDt096225; Mon, 15 Aug 2005 11:51:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FIpGet096224; Mon, 15 Aug 2005 11:51:16 -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 j7FIpFHQ096211 for <[e-mail]>; Mon, 15 Aug 2005 11:51:15 -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 j7FIotB0056658 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 15 Aug 2005 11:50:55 -0700 (PDT)
Date: Mon, 15 Aug 2005 11:51:10 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>>"Both" and "as applicable" are contradictions. "Both" means both apply,
>>and there is no "if" or "as".

>If, for a particular ABNF construct, only one ABNF exists, only one can 
>apply.

Then "both" is not correct. You cannot have a "both" when only one exists.

> Better term for saying that than "as applicable"?

"Articles must conform to the ABNF specified in RFC2822 unless superceded
by ABNF in this standard."

(It is assumed that conforming implementations will conform to the ABNF
we list here; it is only the RFC2822 ABNF that we need an explicit link 
to.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FIYe3I095051; Mon, 15 Aug 2005 11:34:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FIYeTF095050; Mon, 15 Aug 2005 11:34: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 j7FIYdTi095038 for <[e-mail]>; Mon, 15 Aug 2005 11:34:39 -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 j7FIYJB0050946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 15 Aug 2005 11:34:19 -0700 (PDT)
Date: Mon, 15 Aug 2005 11:34:34 -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>

Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:

>In that case it's tricky, your $Somebody is the editor or his
>co-author. 

That "somebody" you keep eliding is me. No, I am not the editor or his 
co-author. Where you got the idea I was either is beyond comprehension.

>> Reread
>[Somebody's]
>> messages.

>No, thank you.  I think that $Somebody is not interested in
>any progress or WG output.  No big deal if I'm wrong.

Other than spreading a lie, no big deal.

Charles's penchant for putting his own ideas into our drafts is not
progress. Progress is when mutually agreeable, non-contradictory,
justifiable text is put into the draft. WG output is fine, as long as
it is the output of the group and not just the editor. Of course, you
know that, but it's more fun to pretend otherwise.

> ... I won't opt-in for something worse.

Be very careful. Someone might think you are opposing progress. Oh, wait,
when YOU don't opt-in it IS progress, when I don't opt-in it's opposing
progress. I forgot. Sorry, my bad.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FIGwLH093803; Mon, 15 Aug 2005 11:16:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FIGw3O093802; Mon, 15 Aug 2005 11:16:58 -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 j7FIGvVv093791 for <[e-mail]>; Mon, 15 Aug 2005 11:16:57 -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 j7FIGVB0043964 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 15 Aug 2005 11:16:37 -0700 (PDT)
Date: Mon, 15 Aug 2005 11:16:46 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>Reality interrupt....

You mean "irrelevancy interrupt".

>Real programs will do what the people who implement them program.
>Real implementors listen to customers.

We are talking about how a specific software system is supposed to 
function. It is irrelevant if people write software that is 
non-conforming. 

Either you are talking to NEWS systems and assume they conform to the 
standard, or you are talking to /dev/random and have NO hope of knowing 
just what kind of gibberish is being handed to you.

If this "real programs" nonsense is going to be the driving force of this
working group, then we might as well stop now, since we will be unable to
require any specific behaviour or have any idea of what the incoming 
"news" message is going to look like. After all, "real implementors" 
listen to customers and not the standards, don't they?

>If they conclude that their support costs are minimized by article 
>mangling on broken articles, article mangling will be written into server 
>software.

And the first time someone writes an ARMM demon they learn that "fixing"
things isn't as simple as they thought.

>But mandating something that we know will be ignored...? Not fun.

What lunacy. We certainly can say how a conforming application operates,
and that non-conforming applications are OUTSIDE THE SCOPE OF THIS GROUP.
Once you say they are OUTSIDE THE SCOPE OF THIS GROUP, you've lost any
right to specify HOW they operate. Non-conforming agents (which are thus
NOT news agents) can do whatever they please with articles, except call 
them news articles. Conforming agents MUST NOT "fix" broken articles, 
because "broken articles" do not exist.

Would you like a simple example of why not? Ok, two agents out there in
"real space" decide they want to implement message id's differently, and 
both also happen to feel that truncating the path is ok. "Hey, A, your 
message id is bogus, I'll 'fix' it by inserting one of my own." "Hey,
B, your message id is bogus, I'll 'fix' it... and I'll fix the Date: 
while I'm at it, to make sure this fixed version propogates." Do the words 
"message loop" mean anything?

Henry Spencer <henry@xxxxxxxxxxxxx>:

>The best solution really is to outlaw all such (post-injection,
>non-Path/Xref) changes, whether the article is conforming or not. 

If it is non-conforming, it is not an article. As a non-article, you do 
not know what it contains, and "fixing" it is impossible. That's why
Henry is right -- "fixing" is prohibited.

Path is a known "modification" that we define, it is not a "fix". XRef is 
a known modification that we define, it is not a "fix". OTH, converting
the text from HTML into simple text is NOT a modification we define, and
thus it is a "fix" and thus prohibited.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FH6rlP087003; Mon, 15 Aug 2005 10:06:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FH6rKl087002; Mon, 15 Aug 2005 10:06:53 -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 j7FH6q56086994 for <[e-mail]>; Mon, 15 Aug 2005 10:06:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-222-243-113-pppoe.dsl.hrbg.epix.net [216.222.243.113]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j7FH6cBI000763 for <[e-mail]>; Mon, 15 Aug 2005 13:06:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 13:06:43 -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: #1080 Injection-info - poll design?
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.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>

Alexey Melnikov wrote:

>>One of Frank's concerns was that injection date needed to be easy
>>to find with simple parsing.  I believe that requiring it to be
>>first was proposed in conjunction with one of the schemes.  Perhaps
>>the poll taking should include gathering votes on the parsing of
>>injection date.
> 
> 
> Harald has already indicated that the issue with Injection-Date is 
> closed. Let's not reopen it.
> 

Do you mean that closing (dropping) the header field Injection-Date means
omitting the injection date from the Injection-Info header field too?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGxT9r086283; Mon, 15 Aug 2005 09:59:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FGxTZl086282; Mon, 15 Aug 2005 09:59: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 j7FGxQD5086271 for <[e-mail]>; Mon, 15 Aug 2005 09:59:27 -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; Mon, 15 Aug 2005 17:59:14 +0100
Message-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 17:58:56 +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
To: "Forrest J. Cavalier III" <[e-mail]>
CC: [e-mail]
Subject: Re: #1080 Injection-info - poll design?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
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>

Forrest J. Cavalier III wrote:

> Harald Tveit Alvestrand wrote:
>
>> PROPOSALS I'VE HEARD
>
>
> When or if this becomes a poll, can it include examples and a summary of
> what objections have been raised to each?  I think some of those options
> should be removed based on valid objections.

The suggestion seems sensible to me.

> One of Frank's concerns was that injection date needed to be easy
> to find with simple parsing.  I believe that requiring it to be
> first was proposed in conjunction with one of the schemes.  Perhaps
> the poll taking should include gathering votes on the parsing of
> injection date.

Harald has already indicated that the issue with Injection-Date is 
closed. Let's not reopen 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 j7FGfGsw085002; Mon, 15 Aug 2005 09:41:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FGfGZi085000; Mon, 15 Aug 2005 09:41: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 j7FGfEB9084992 for <[e-mail]>; Mon, 15 Aug 2005 09:41:15 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4hyM-00012j-Az for [e-mail]; Mon, 15 Aug 2005 18:38:02 +0200
Received: from c-134-88-19.hh.dial.de.ignite.net ([62.134.88.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 18:38:02 +0200
Received: from nobody by c-134-88-19.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 18:38:02 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1080 Injection-info - poll design?
Date:  Mon, 15 Aug 2005 18:35:13 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 54
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-88-19.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:
 
> PROPOSALS I'VE HEARD
[...]
> - Remove the dependence on "parameter", specify all ABNF
>   ourselves.  Stop accepting 2231 constructs.

That failed for a hypothetical x-filename.  Bruce's idea
also won't allow file names, but he never claimed that his
proposal allows to add this kind of "x-token".

If we'd want to be free to add almost anything 2231 would
be the way to go.  I think we don't need this flexibility.

> - Keep importing "parameter", but clarify what we think
>   it means in modern ABNF.

That's not trivial.  While I see no problem in redefining
the <msg-id>, because it's at the core of NetNews and we
found a minimal modification (modulo names reflecting the
semantics), I don't think that it's our job to mess with
the 2231-parameter syntax.

A non-normative clarification might be okay.  I changed my
mind about this:  For obvious reasons we're already forced
to mess with MESSFOR, let's not also mess with MIME.

Bruce has a kind of "unified message syntax" integrating
MIME, and it's IMHO difficult to get this right.  Maybe a
future WG could tackle it, "everything we always wanted to
fix in 2822 / MIME / USEFOR (adding yenc just for fun)".
[...]
 
> Is that a reasonable summary of the alternatives that 
> have been proposed?

Yes, but I think the two quoted alternatives were already
identified as less desirable.

> I *think* that the 4 last pieces are a matter of changing
> how the syntax of the Injection-info parameter is described.

Maybe the last could also work for Bruce's Received-concept.

> The 2 first ones would be throwing out the existing
> Injection-info and starting over.

I don't like the first idea (header field zoo), but OTOH if
we are not smart enough to find a good working combination
(or unable to agree on one, or need another year for it),
then we better pick a zoo of simple header fields.  After
all that's as it is today.
                             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 j7FFQbVO079373; Mon, 15 Aug 2005 08:26:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FFQbTI079372; Mon, 15 Aug 2005 08:26: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 j7FFQZRM079365 for <[e-mail]>; Mon, 15 Aug 2005 08:26:35 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4go2-0001Kl-86 for [e-mail]; Mon, 15 Aug 2005 17:23:18 +0200
Received: from c-134-88-19.hh.dial.de.ignite.net ([62.134.88.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 17:23:18 +0200
Received: from nobody by c-134-88-19.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 17:23:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1053 Relationship to RFC 2822 - suggestion
Date:  Mon, 15 Aug 2005 17:21:06 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 58
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <C2222176E2EB0FD360CC09C2@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: c-134-88-19.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:
 
> I wonder at the value of trying to keep this skeleton in
> the closet.

It could be like the CRLF in 2234bis:  Bruce proposed to say
[CR] LF, maybe ( [CR] LF ) / CR would be more accurate.  But
the best solution it to stick to CRLF as the only "line end"
in ABNF.

What the IETF ftp servers really do with I-Ds containing any
ABNF is beside the point for this issue.  This CRLF is a real
fetish, and "message modification" is a real taboo.

Of course some gateway operators will know it better, but for
those who don't know it the more important message is "never
try to 'fix' messages".

> We don't want to open the pandora's box of specifying which
> changes are OK and which are not.

Yes, only the specified modifications are allowed.  All other
modifications are formally illegal - they can have dangerous
side effects.  E.g. destroy header signatures.  Or with our
funny length limit for the <msg-id> and other less obscure
restrictions, whatever a mai2news gateway decides to do with
an invalid <msg-id>, it will be wrong.  The least damage is
probably "reject" depending on the gateway.

> The situation I'd like to handle cleanly:
>  - Person A: Person B's server mangled my article!
>  - Person B: Person A's article was broken - I repaired it!
>  - Person A: But the standard says you can't change articles!
 
> I'd like Person B to say "Your article was broken, so it's
> outside the rules", and Person A to say "OK, I agree the
> standard says that, I'll fix my UA and stop whining" (or
> whatever).

Tricky.  How do you define "repair" for a broken / missing
<msg-id>, or utter dubious MESSFOR-minus-USEFOR <msg-id>s ?

A mail2news gateway will be hit by stuff legal in mail but
not news.  There are many ways to (try to) "fix" problems,
and for most wannabe-solutions you'd find cases where they
fail miserably making it worse.

Person B could say "if I don't try to 'fix' it I'm forced
to reject it".  Person A could insist on rejecting it.  It
is a can of worms, and near to non-technical legal trouble.

 [the M-word]
> are we best served by not mentioning it?

IANAL.  I'd stay away from it, out of scope is out of scope.

                           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 j7FEv9iL077378; Mon, 15 Aug 2005 07:57:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FEv9NI077377; Mon, 15 Aug 2005 07:57:09 -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 j7FEv8UE077370 for <[e-mail]>; Mon, 15 Aug 2005 07:57:08 -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 j7FEv6tS019803; Mon, 15 Aug 2005 10:57:06 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7FEv5XU019802; Mon, 15 Aug 2005 10:57:05 -0400 (EDT)
Date: Mon, 15 Aug 2005 10:57:05 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
In-Reply-To: <C2222176E2EB0FD360CC09C2@B50854F0A9192E8EC6CDA126>
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 Mon, 15 Aug 2005, Harald Tveit Alvestrand wrote:
> There are cases where software DOES modify articles (outside of the Path 
> and Xref headers), and where it will continue to do so. We don't want to 
> open the pandora's box of specifying which changes are OK and which are not.

Correct:  we want to forbid them all.  That software is *broken*.

"Neglect of duty does not cease, by repetition, to be neglect of duty."
(Napoleon)

For one thing, the user doesn't necessarily get feedback that such changes
are happening.  For another, they potentially bollix up the "same message ID
means identical article" principle.  For a third, people who write servers
that mangle articles often have only the vaguest notion of what's conforming
and what's non-conforming.

The best solution really is to outlaw all such (post-injection,
non-Path/Xref) changes, whether the article is conforming or 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 j7FCwIZM044463; Mon, 15 Aug 2005 05:58:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FCwI9b044462; Mon, 15 Aug 2005 05:58:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from soy.epix.net (soy.epix.net [199.224.64.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FCwH2N044451 for <[e-mail]>; Mon, 15 Aug 2005 05:58:17 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-222-243-113-pppoe.dsl.hrbg.epix.net [216.222.243.113]) by soy.epix.net (8.12.10/2004120601/PL) with ESMTP id j7FCw8gE000383 for <[e-mail]>; Mon, 15 Aug 2005 08:58:13 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 08:58:13 -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: #1080 Injection-info - poll design?
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:
> PROPOSALS I'VE HEARD

When or if this becomes a poll, can it include examples and a summary of
what objections have been raised to each?  I think some of those options
should be removed based on valid objections.

One of Frank's concerns was that injection date needed to be easy
to find with simple parsing.  I believe that requiring it to be
first was proposed in conjunction with one of the schemes.  Perhaps
the poll taking should include gathering votes on the parsing of
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 j7FAY2A2090593; Mon, 15 Aug 2005 03:34:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FAY2TH090592; Mon, 15 Aug 2005 03:34:02 -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 j7FAY12S090577 for <[e-mail]>; Mon, 15 Aug 2005 03:34:02 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5EC8832009A for <[e-mail]>; Mon, 15 Aug 2005 12:33: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 29035-02 for <[e-mail]>; Mon, 15 Aug 2005 12:33: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 31BE2320099 for <[e-mail]>; Mon, 15 Aug 2005 12:33:50 +0200 (CEST)
Date: Mon, 15 Aug 2005 12:33:55 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1080 Injection-info - poll design?
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: by 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>

No, I'm not going to run a poll on this one yet.
First, I have to figure out what alternatives are on, near or off the 
table...

CURRENT: Section 3.2.14 specifies an ABNF for the field that includes a 
number of parameter definitions, in "name=value" format, and allows the 
"parameter" ABNF entry.
"parameter" is imported from 2045+2231, according to section 1.4.
This introduces some oddities, including ambiguity on whether or not spaces 
are allowed around the equal signs, and one RHS that isn't a "value" 
(posting-host contains :)

PROPOSALS I'VE HEARD

- Junk the current definition, go for multiple header fields

- Junk the current definition, go for a single Received:-like header field

- Remove the dependence on "parameter", specify all ABNF ourselves.
  Stop accepting 2231 constructs.

- As above, but continue accepting 2231 constructs

- Keep importing "parameter", but clarify what we think it means in
  modern ABNF. Sort out the ambiguities with the non-parameter pieces.

- Change the ABNF to just a parameter-list, and give a table of parameter
  attribute names with corresponding syntax for values, sidestepping the
  question of how "parameter" is represented in ABNF

First question: Is that a reasonable summary of the alternatives that have 
been proposed?

(I *think* that the 4 last pieces are a matter of changing how the syntax 
of the Injection-info parameter is described. The 2 first ones would be 
throwing out the existing Injection-info and starting over.)

                     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 j7F9TdKL067986; Mon, 15 Aug 2005 02:29:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7F9Tdjq067985; Mon, 15 Aug 2005 02:29:39 -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 j7F9TchG067973 for <[e-mail]>; Mon, 15 Aug 2005 02:29:38 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F1E632009A; Mon, 15 Aug 2005 11:29: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 27734-03; Mon, 15 Aug 2005 11:29:27 +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 61304320099; Mon, 15 Aug 2005 11:29:26 +0200 (CEST)
Date: Mon, 15 Aug 2005 11:29:33 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
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: by 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, august 12, 2005 15:02:20 -0700 John Stanley <[e-mail]> 
wrote:

>>  Articles are conformant if they use 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.
>
> How do article generate "productions" of syntax? Perhaps you mean "agents
> MUST NOT generate".

Yes. Thanks.

>>  Articles must conform to both the ABNF specified in RFC 2822 and to the
>>  ABNF specified here, as applicable.
>
> "Both" and "as applicable" are contradictions. "Both" means both apply,
> and there is no "if" or "as".

If, for a particular ABNF construct, only one ABNF exists, only one can 
apply. Better term for saying that than "as applicable"?





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7F9Qw9q066972; Mon, 15 Aug 2005 02:26:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7F9QwLx066971; Mon, 15 Aug 2005 02:26: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 j7F9QvtN066954 for <[e-mail]>; Mon, 15 Aug 2005 02:26:58 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6925032009A; Mon, 15 Aug 2005 11:26:49 +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 27691-02; Mon, 15 Aug 2005 11:26: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 0F70D320099; Mon, 15 Aug 2005 11:26:45 +0200 (CEST)
Date: Mon, 15 Aug 2005 11:26:51 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
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: by 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, august 12, 2005 15:02:20 -0700 John Stanley <[e-mail]> 
wrote:

>>    agents may choose
>>  to accept such articles, reject such articles or modify such articles.
>
> "Agents", in the general sense, should NEVER be allowed to modify
> non-conforming articles, unless there is a specific modification to
> correct something specific and the correction is well defined. If a
> relaying agent, e.g., gets a non-conforming article, the only correct
> assumption a conforming agent can make is that the article was mangled in
> transit and it MUST be dropped. It must assume that the agents next to it
> are operating correctly and would not create non-conforming articles; thus
> the only way it became non-conforming is through some error in transit.
>
> Further, agents, in the general sense, MUST NOT accept non-conforming
> articles, for precisely the same reason. All that is left is "reject".

Reality interrupt....

Real programs will do what the people who implement them program.
Real implementors listen to customers.
Real customers for server software want to minimize their support costs.

If they conclude that their support costs are minimized by article mangling 
on broken articles, article mangling will be written into server software.
(real implementors who wish to tell me otherwise.. please speak up!)

We can tell people "if you do this, you're on your own". Telling people 
"you can't do this" when we know perfectly well that they will do it is not 
particularly helpful. Telling people "you must not do this when you don't 
have to" (when the article is OK) gives implementors a tool to push back on 
broken requests - which might be good.

I'm reasonably happy with saying nothing, and happier with saying 
explicitly "it's your business, standard won't help you here".

But mandating something that we know will be ignored...? Not fun.

                    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 j7F8jmme052062; Mon, 15 Aug 2005 01:45:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7F8jmEO052061; Mon, 15 Aug 2005 01:45: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 j7F8jl6g052051 for <[e-mail]>; Mon, 15 Aug 2005 01:45:47 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52369320097; Mon, 15 Aug 2005 10:45: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 26595-04; Mon, 15 Aug 2005 10:45:35 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2ED532009A; Mon, 15 Aug 2005 10:45:31 +0200 (CEST)
Date: Mon, 15 Aug 2005 10:22:12 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Message-ID: <C2222176E2EB0FD360CC09C2@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: by 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 12. august 2005 22:57 +0200 Frank Ellermann <[e-mail]> 
wrote:

>| Handling of non-conformant articles is outside the scope of
>>| this specification; agents may choose to accept such
>>| articles, reject such articles
>
> So far it's fine...
>
>>| or modify such articles.
>
> ...but that's one of the things I'd not say in a standard, even
> if it's true.  Let's say "may" ... "accept such articles", not
> more.  Obviously there's an implicit "maybe not" (= reject),
> don't talk about it, and there's also a very hidden implicit
> "how they accept it is their business" (= modify), but don't
> say it, it's out of scope.

I wonder at the value of trying to keep this skeleton in the closet.

There are cases where software DOES modify articles (outside of the Path 
and Xref headers), and where it will continue to do so. We don't want to 
open the pandora's box of specifying which changes are OK and which are not.

The situation I'd like to handle cleanly:

 - Person A: Person B's server mangled my article!
 - Person B: Person A's article was broken - I repaired it!
 - Person A: But the standard says you can't change articles!

I'd like Person B to say "Your article was broken, so it's outside the 
rules", and Person A to say "OK, I agree the standard says that, I'll fix 
my UA and stop whining" (or whatever).

If that's a laudable goal (is it?), are we best served by mentioning the M 
word (modify) in our description of what can happen to non-conformant 
articles (because it's beyond the scope of the standard), or are we best 
served by not mentioning 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 j7F8jjuG052043; Mon, 15 Aug 2005 01:45:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7F8jjmc052041; Mon, 15 Aug 2005 01:45: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 j7F8ji9M052024 for <[e-mail]>; Mon, 15 Aug 2005 01:45:44 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B0228320096; Mon, 15 Aug 2005 10:45:35 +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 26595-03; Mon, 15 Aug 2005 10:45:32 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7804E320099; Mon, 15 Aug 2005 10:45:30 +0200 (CEST)
Date: Mon, 15 Aug 2005 10:09:57 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Message-ID: <F15933F86D4B35E0F6337F35@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: by 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 12. august 2005 22:44 +0200 Frank Ellermann <[e-mail]> 
wrote:

>> - Specify that "diagnostics" are PERMITTED in the path,
>>   and that this standard does not restrict the format of
>>   diagnostics very much (in fact, permit all of
>>   [A-Za-z0-9.:], and then shut up)
>
> 2119 + PERMITTED ?  <g>
>

:-)

I was using UPPER CASE for EMPHASIS, for once......





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7F32weg037988; Sun, 14 Aug 2005 20:02:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7F32wFo037987; Sun, 14 Aug 2005 20:02: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 j7F32tGN037981 for <[e-mail]>; Sun, 14 Aug 2005 20:02:56 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4VFE-0006Pz-WC for [e-mail]; Mon, 15 Aug 2005 05:02:37 +0200
Received: from c-180-161-139.hh.dial.de.ignite.net ([62.180.161.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 05:02:36 +0200
Received: from nobody by c-180-161-139.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 15 Aug 2005 05:02:36 +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:  Mon, 15 Aug 2005 04:55:51 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 154
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-161-139.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:

>>  [Somebody]
> =
[...]  My killfile is a mental thing.  As long as $Somebody
and me are not obliged to recognize each other this works
as expected (incl. "not so well").

> The problem isn't with the specific idea, it's with getting
> ideas into (and in some cases out of) our documents when they
> happen to not coincide (or to coincide) with one person's
> preferences.

In that case it's tricky, your $Somebody is the editor or his
co-author.  In that case you're forced to handle it through
others or the Chair.

> Reread
[Somebody's]
> messages.

No, thank you.  I think that $Somebody is not interested in
any progress or WG output.  No big deal if I'm wrong.

> There was a poll and striking results several years ago.

Probably I missed it.  I only know a rather small part of the
WG history, mainly the first "last-last-last-call" (the old
draft -07 or -08) and Ralph Babel's poll, where you found that
there was no consensus for the UTF-8 stuff, and then again
last year (?) after the decision to split the document.

Which was a good idea, although I didn't like it for some time.

> because of one person's fetish, we're still discussing
> problems with Injection-Info, and that's holding up progress.

I'm disussing it because I have problems with 2231, but there
is some "progress", I won't opt-in for something worse.  So if
we really want or need most features of 2231 then let's use it.
If that's not the case let's avoid it.

It's no fetish for me.  I like the idea of one header field
instead of a header field zoo, and I like a complaint address
instead of URLs.

At the moment we have two Injection-* header fields.  With your
idea we'd get Complaints-To plus something-like-Received, also
two header fields, so far not worse or better.

Your idea allows URLs.  While I hate this I know that Alexey and
Russ might like it, so ignore me.  And _if_ you can avoid 2231
that's much more important than the minor complaint URL issue.

But you have to make sure that even simple-minded algorithms
find the timestamp.  That's critical, unlike the URL business.

Your option #3 and maybe also #2 addreses this point.  So far
your proposal is apparently better from my POV.

> IMO, we need to select syntax that avoids the many problems
> with parameters (as noted, there have been such proposals)

ACK so far...

> or yank the entire field out (as it's not an existing field)
> leaving it for a future extension

...but NAK here.

> We're way behind schedule

Yes, let's focus on real alternatives and then decide it.  I've
already said all I can contribute to this issue.  If the result
is "let's keep it as it is" I can live with it.  But we cannot
kill Injection-* without proper replacement, that's just wrong.

> if we don't resolve this issue and move on, the IESG would be
> justified in disbanding the WG

Following the procedures listed in RfC 2048 chapter 4.  Are you
perhaps interested in my unpublished "3710 is obsolete" I-D ?

>> I can't tell what you want
> I don't see why not

Simply put I'm not sure whether you want any result, because it
won't be what you like in several points like the magic SP, and
a few other NetNews oddities.  You care about the holy grail
"Internet message format", I care about NetNews.  Different
priorities, your number one is my number two (and vice versa).

> I've been clear about proposals for unproblematic fields for
> injection information and about Complaints-To.

It would be easier for me to second it if it's complete ABNF
ready to replace the Injection-*.  Or if Russ or Henry or both
like it.  By my appointment they can "veto" everything I say -
at least when they more or less agree.

A somewhat unreliable oracle, IIRC both refused to comment the
<id-right> vs. <id-domain> issue.  But it's also interesting
when they say nothing.

>> I don't like 2231, but draw the line at inventing something
>> that's not really better.

> No need to invent; we can reuse existing field syntax that is
> known not to have problems with parameters (borrowing syntax
> from Received and List-Post for injection and complaint-
> reporting information).

Okay, see above.  Get support from some relevant contributors.
As you said we're late, we can't discuss this for another year,
we need concrete proposals, not vague or abstract ideas.

 [Goedel Escher Bach]
> But you wanted to put address-lists in a parameter

No, I wanted something like 'name "=" value' with a <quoted-
string> as a value, same idea as in Received-SPF.  We already
agree that it was a bad idea, but it was precisely to avoid
the MIME <parameter> syntax.

> at which time any encoded-words in display names would cease
> to be encoded-words, creating a mess.

It's not messy.  a = "b" ; c = "d" ; e = "f" is simply a list
of names and values separated by semicolon, and at this moment
it's irrelevant what b d f are outside of a quoted-string.

Your idea results in a b c d e f, we have to make sure that
we can parse b and d and f in this form, even if b is in fact
b' c' d' resulting in a b' c' d' c d e f.  The parser has to
identify c' d' as belongig to b'.  With quoted strings that's
obvious: a = "b' c' d'" ; c = "d" ; e = "f".

> Conforming parsers will never see them as comments or
> encoded-words.

Okay, so we agree about that detail, a <quoted-string> can be
almost anything, as long as all DQUOTE and "\" within it are
escaped.

 [bchars]
> Backslash is irrelevant in that case; it's a mechanism for
> putting DQUOTE in a quoted-string.  bchars doesn't permit
> DQUOTE, so you're right about the third example not being a
> legal boundary value (for the wrong reason).

Neither DQUOTE nor "\" are allowed, we're both right.  Unless
you think that "\\hcaB rehcsE ledeoG\\" is a legal boundary,
then it would be only me who's 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 j7EMHt7W010623; Sun, 14 Aug 2005 15:17:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EMHtYk010622; Sun, 14 Aug 2005 15:17:55 -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 j7EMHttn010614 for <[e-mail]>; Sun, 14 Aug 2005 15:17:55 -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 3519A299B6; Sun, 14 Aug 2005 18:17:54 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7EMHmg5001143(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, 14 Aug 2005 18:17:51 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7EMHlwS001140(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, 14 Aug 2005 18:17:48 -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: Sun, 14 Aug 2005 18:17:36 -0400
User-Agent: KMail/1.8.2
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 August 14 2005 16:10, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
>  [Somebody]
= John
> > has identified the persistently recurring problem

And others have mentioned the problem, on list and off, for years.

> Okay, if you think that there are serious problems with your
> idea

The problem isn't with the specific idea, it's with getting ideas
into (and in some cases out of) our documents when they happen to
not coincide (or to coincide) with one person's preferences.

> > Consider the fourth definition of NIH
> 
> Yes, I know NIH.  Neither 2231 nor 2822-Received was invented
> here, for definitions of "here = NetNews" or "here = USEFOR".

"Here = USEFOR [WG]" isn't the issue; several options for injection
information fields have been discussed here.  Reread John's
messages.
 
> > one person's fetish for parameters despite WG consensus
> > against their use.
> 
> I'm not sure about a consensus, so far I'd _guess_ that Russ
> doesn't like the parameter-solution.

There was a poll and striking results several years ago.  That was
mentioned and discussed more recently, and finally (after repeated
directions from the Chair) most of the parameters are gone.  But
because of one person's fetish, we're still discussing problems
with Injection-Info, and that's holding up progress.

IMO, we need to select syntax that avoids the many problems with
parameters (as noted, there have been such proposals) or yank the
entire field out (as it's not an existing field), leaving it for a
future extension.  We're way behind schedule, and if we don't
resolve this issue and move on, the IESG would be justified in
disbanding the WG (which has produced none of its chartered
deliverable work products after 8 years, 4 months, and 4 days
(and counting)).

> I can't tell what you 
> want

I don't see why not; I've been clear about proposals for unproblematic
fields for injection information and about Complaints-To.

> and I don't like 2231, but draw the line at inventing 
> something that's not really better.

No need to invent; we can reuse existing field syntax that is known
not to have problems with parameters (borrowing syntax from Received
and List-Post for injection and complaint-reporting information).
 
> >> SPECIALS : " ( ) , .   : ; <   >   @ [ \ ]
> >> TSPECIALS: " ( ) ,   / : ; < = > ? @ [ \ ]
> 
> > Anything with any tspecial has to be quoted.
> 
> For a 2045-parameter value.  Not in say local parts.

But you wanted to put address-lists in a parameter, at which time
any encoded-words in display names would cease to be encoded-words,
creating a mess.

[...]
> E.g. "(" and ")" are only relevant for comments, but there are
> no comments within a <quoted-string>.  If you take "something"
> containing comments and quote it, then the "quoted something"
> does not more contain a comment.

Another reason why an address-list (which can of course contain
comments) is a very bad idea for a parameter.

> "(I am no comment while quoted)"
> "=?us-ascii?q?I_am_no_encoded_word_while_quoted?="
> "\"Goedel Escher Bach was fun\""
[...]

> > Consequently one cannot have an RFC 2047/2231 encoded-word in
> > an RFC 2045/2231 parameter.
> 
> If you really think than one or more of my three examples is
> an invalid / illegal <parameter> value I'd be very surprised.

They are legal quoted-strings which could appear as parameter values.
However, they are then exactly that -- parameter values -- and cease to
be comments (first example) and encoded-words (second example).
Conforming parsers will never see them as comments or encoded-words.

> Only for parameters, 2045 and 2231, not for boundary strings:
> 
> <bchars> has no "\" for <quoted-pair>, so the Goedel-example
> is no legal boundary.

Backslash is irrelevant in that case; it's a mechanism for putting
DQUOTE in a quoted-string.  bchars doesn't permit DQUOTE, so you're
right about the third example not being a legal boundary value (for
the wrong reason).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7EKIMjO097227; Sun, 14 Aug 2005 13:18:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EKIMuI097225; Sun, 14 Aug 2005 13:18: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 j7EKIJ3C097166 for <[e-mail]>; Sun, 14 Aug 2005 13:18:20 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E4Ouq-0001ev-T5 for [e-mail]; Sun, 14 Aug 2005 22:17:08 +0200
Received: from c-180-161-139.hh.dial.de.ignite.net ([62.180.161.139]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 14 Aug 2005 22:17:08 +0200
Received: from nobody by c-180-161-139.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 14 Aug 2005 22:17:08 +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:  Sun, 14 Aug 2005 22:10:19 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 69
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-161-139.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:

 [Somebody]
> has identified the persistently recurring problem

Okay, if you think that there are serious problems with your
idea, then we can as well use 2231 instead of rolling our own.

> Consider the fourth definition of NIH

Yes, I know NIH.  Neither 2231 nor 2822-Received was invented
here, for definitions of "here = NetNews" or "here = USEFOR".

> one person's fetish for parameters despite WG consensus
> against their use.

I'm not sure about a consensus, so far I'd _guess_ that Russ
doesn't like the parameter-solution.  I can't tell what you
want, and I don't like 2231, but draw the line at inventing
something that's not really better.

>> SPECIALS : " ( ) , .   : ; <   >   @ [ \ ]
>> TSPECIALS: " ( ) ,   / : ; < = > ? @ [ \ ]

> Anything with any tspecial has to be quoted.

For a 2045-parameter value.  Not in say local parts.  It's
beside the point, we were talking about a <quoted-string>,
and the only characters you've to worry about in this context
are DQUOTE and "\", maybe some CTL, but not "/", "=", "?", or
<specials>.

DQUOTE and "\" are relevant for all arbitrary <quoted-string>s,
other <specials> or <tspecials> are only relevant if it's in
a context where they mean something.

E.g. "(" and ")" are only relevant for comments, but there are
no comments within a <quoted-string>.  If you take "something"
containing comments and quote it, then the "quoted something"
does not more contain a comment.

"(I am no comment while quoted)"
"=?us-ascii?q?I_am_no_encoded_word_while_quoted?="
"\"Goedel Escher Bach was fun\""

> And encoded-words are not permitted in quoted-strings.

Exactly that's the point, there simply are no <encoded-word>s
in a <quoted-string>, that's no question of legal vs. illegal
or a _permission_ , it's the _definition_ of a <quoted-string>.

They are not permitted as parameter-value in an unquoted form.
But of course you can use any <quoted-string> - including the
three examples shown above.

> Consequently one cannot have an RFC 2047/2231 encoded-word in
> an RFC 2045/2231 parameter.

If you really think than one or more of my three examples is
an invalid / illegal <parameter> value I'd be very surprised.
We could ask Keith and Ned what they think about it.

Only for parameters, 2045 and 2231, not for boundary strings:

<bchars> has no "\" for <quoted-pair>, so the Goedel-example
is no legal boundary.  But AFAIK it's a legal parameter value.

                       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 j7EIjavZ052455; Sun, 14 Aug 2005 11:45:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EIjaKf052452; Sun, 14 Aug 2005 11:45:36 -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 j7EIjYXJ052410 for <[e-mail]>; Sun, 14 Aug 2005 11:45:35 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B51C432008F for <[e-mail]>; Sun, 14 Aug 2005 20:45:26 +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 00887-09 for <[e-mail]>; Sun, 14 Aug 2005 20:45:23 +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 A63FB32008A for <[e-mail]>; Sun, 14 Aug 2005 20:45:22 +0200 (CEST)
Date: Sun, 14 Aug 2005 20:45:29 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Posters for the last 7 days (Re: #1047 Path field delimiters and syntax - status)
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=iso-8859-1; format=flowed
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7EIjaXJ052429
Sender: [e-mail]
Precedence: 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 søndag, august 14, 2005 08:40:56 -0400 Bruce Lilly <[e-mail]> 
wrote:

> What, no "posters for the week" statistics? :-,
>

Since you asked....

Searching for msgs since 07-Aug-2005
  1   18  24.32 Harald Tveit Alvestrand <[e-mail]>
  2   15  44.59 John Stanley <[e-mail]>
  3   13  62.16 "Charles Lindsey" <[e-mail]>
  4   10  75.68 Frank Ellermann <[e-mail]>
  5    5  82.43 Bruce Lilly <[e-mail]>
  6    4  87.84 Richard Clayton <[e-mail]>
  7    4  93.24 "Forrest J. Cavalier III" <[e-mail]>
  8    3  97.30 Russ Allbery <[e-mail]>
  9    2 100.00 Henry Spencer <[e-mail]>

It appears that a few people are either on holiday or quiet...





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7EE4Pum092840; Sun, 14 Aug 2005 07:04:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EE4Pr5092839; Sun, 14 Aug 2005 07:04: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 j7EE4OFV092829 for <[e-mail]>; Sun, 14 Aug 2005 07:04:24 -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 1C27E299E1; Sun, 14 Aug 2005 10:04:23 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7EE4MBf031168(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, 14 Aug 2005 10:04:22 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7EE4KEh031167(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, 14 Aug 2005 10:04:21 -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: Sun, 14 Aug 2005 10:04:15 -0400
User-Agent: KMail/1.8.2
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 August 11 2005 23:45, Frank Ellermann wrote:

> Otherwise it's very much like "Received", apparently 
> you want to use some of the same <item-name>.
> 
> It doesn't use 2231 <parameter>, it uses 2822 <name-val-list>
> with <item-name> and <item-value>.  Fine, so why don't we do
> it this way ?

John has identified the persistently recurring problem in messages
<[e-mail]> and
<[e-mail]>.

Consider the fourth definition of NIH at
http://www.acronymfinder.com/af-query.asp?p=dict&String=exact&Acronym=NIH
The answer to your question is NICHL; one person's fetish for
parameters despite WG consensus against their use.

> > I'd still do Complaints-To as a bracketed URI list.  Same
> > general form as List-Post; plenty of reusable code for that.
> 
> Okay, I like your #1..#3 idea, and maybe it's then better to
> go back to a separate Complaints-To.
> 
> ~~~  
> >> Yes. = and ? are no specials, but if there's a blank =>
> >> quoted.
>  
> > Remember that RFC 2045 that I suggested rereading?  Look up
> > "tspecial".
> 
> Sure, I know it.
> SPECIALS : " ( ) , .   : ; <   >   @ [ \ ]
> TSPECIALS: " ( ) ,   / : ; < = > ? @ [ \ ]

Anything with any tspecial has to be quoted.  '?' is a tspecial.
therefore any parameter with '?' has to be quoted.  And encoded-words
are not permitted in quoted-strings.  Consequently one cannot have an
RFC 2047/2231 encoded-word in an RFC 2045/2231 parameter.

> We discussed solutions without <parameter> like <name-val-list>
> or a similar construct in the Received-SPF header field IIRC.
> 
> So 2045 rules about <parameter> don't enter the picture.  If we
> want <quoted-string> all of <qtext> is okay, incl. "=" and "?".

Fine as text in a quoted-string, but encoded-words never appear in
quoted-strings, only in unstructured fields, words in a phrase
(specifically excluding the other component of phrase), and within
parenthesized comments.

> In essence what you propose is to replace all 'name = "value"'
> by 'name value'.  CFWS separated words.  So far that's KISS and
> better than 2231, where are the problems ?

See above and John'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 j7EE1UIP091772; Sun, 14 Aug 2005 07:01:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EE1UBj091771; Sun, 14 Aug 2005 07:01:30 -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 j7EE1Th4091759 for <[e-mail]>; Sun, 14 Aug 2005 07:01:29 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0993B320084; Sun, 14 Aug 2005 16:01:22 +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 28461-05; Sun, 14 Aug 2005 16:01:19 +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 414C3320082; Sun, 14 Aug 2005 16:01:18 +0200 (CEST)
Date: Sun, 14 Aug 2005 16:01:24 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: Next steps - please concentrate on USEFOR again
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=iso-8859-1; format=flowed
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7EE1Th4091765
Sender: [e-mail]
Precedence: 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 lørdag, august 13, 2005 22:15:50 +0000 Charles Lindsey 
<[e-mail]> wrote:

> 2. I propose that the individual terms [reading, posting, followup] agent
> and [injecting, relaying, serving] agent be defined in and used only in
> USEPRO. And that in USEFOR the terms "user agent" and "news-server" be
> used for those two groups (I have not checked in detail, but I think there
> would be no problem changing USEFOR in that way). All the remaining
> definitions are already pretty much the same now in USEFOR and USEPRO, and
> would therefore appear only in USEFOR.

btw... the term "agent" occurs (in various contexts) 70 times in USEFOR.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7EE0NLM091315; Sun, 14 Aug 2005 07:00:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EE0N6Z091314; Sun, 14 Aug 2005 07:00:23 -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 j7EE0MkC091299 for <[e-mail]>; Sun, 14 Aug 2005 07:00:22 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 02A1B320084; Sun, 14 Aug 2005 16:00:15 +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 28461-04; Sun, 14 Aug 2005 16:00:11 +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 876DC320082; Sun, 14 Aug 2005 16:00:11 +0200 (CEST)
Date: Sun, 14 Aug 2005 16:00:17 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: Next steps - please concentrate on USEFOR again
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=iso-8859-1; format=flowed
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7EE0NkC091308
Sender: [e-mail]
Precedence: 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 lørdag, august 13, 2005 22:15:50 +0000 Charles Lindsey 
<[e-mail]> wrote:

>
> In <[e-mail]> Harald Tveit
> Alvestrand <[e-mail]> writes:
>
>> Given that our first task is to finish USEFOR, I'll ask people to hold
>> off  discussion on USEPRO issues until we've finished this round of
>> USEFOR  updates.
>
> Well there are some issues where both the USEPRO and USEFOR aspects need
> to be considered together (the syntax and construction of the Path are a
> case in point).
>
> As for USEFOR, I have a couple of issues:
>
> 1. Son-of-1036 said that article bodies SHOULD NOT be empty (it broke some
> implementations).
>
> All our earlier drafts re-iterated that provision.
>
> For some reason, it never got into USEFOR (though not including it was
> never discussed). Please can we decide now whether or not be want to
> retain that restriction?

#1101

> 2. I propose that the individual terms [reading, posting, followup] agent
> and [injecting, relaying, serving] agent be defined in and used only in
> USEPRO. And that in USEFOR the terms "user agent" and "news-server" be
> used for those two groups (I have not checked in detail, but I think there
> would be no problem changing USEFOR in that way). All the remaining
> definitions are already pretty much the same now in USEFOR and USEPRO, and
> would therefore appear only in USEFOR.
>
> This idea has been mentioned eariler, and a few people expressed support.
> It would make my job in USEPRO somewhat simpler, on account of the way I
> currently introuce those terma as part of an overview of the general
> architecture.

#1102
>
> Please can we have tickets for these?
>

Done.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7EDTmhZ079427; Sun, 14 Aug 2005 06:29:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EDTmws079426; Sun, 14 Aug 2005 06:29:48 -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 j7EDTlbD079410 for <[e-mail]>; Sun, 14 Aug 2005 06:29: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 ns1.townisp.com (Postfix) with ESMTP id 1C6FA29943; Sun, 14 Aug 2005 09:29: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 j7EDTjpS016253(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, 14 Aug 2005 09:29:45 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7EDTiEl016250(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, 14 Aug 2005 09:29:44 -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
Date: Sun, 14 Aug 2005 09:29:39 -0400
User-Agent: KMail/1.8.2
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 August 12 2005 00:27, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > Usenetters requested elimination of CFWS (but no other
> > changes) to accommodate news software.  That change was made
> > to the syntax (but no change to semantics of the RHS)
> > accordingly.
> 
> Apparently they forgot the other issues, NO-WS-CTL and ">" and
> some kind of "canonical" <msg-id>.

Then please explain (in a form suitable for an implementation note)
precisely why such changes are necessary (or specifically which
existing (not hypothetical) brain-dead implementations get handling
of msg-ids wrong, and why we shouldn't simply treat such brain-dead
implementations as non-conforming and move on).

> > Given the fact that a domain name can be up to 255 octets,
> > limiting a msg-id (domain name plus local-part plus '<', '@',
> > and '>') simply isn't rational.
> 
> I could justify 322, and a limit is rational.

There is an inherent limit of 997 octets imposed by lack of folding.

> By some accident 
> we inherit 250.

No consensus work from which to "inherit" that. It's not in 724, 733,
822, 850, 1036, or 2822.

> It's ugly like hell, but replacing it by 322 
> if that breaks existing software everywhere makes no sense.

If you can prove that it "breaks existing software everywhere", i.e.
that there is not one implementation that can handle >= 251 octets
for a msg-id, I'll agree.
 
> Except from the stolen RfC 2822 names I'm happy with the fixed
> syntax.  Syntactically Charles' and my version are identical -
> we didn't talk for months about it without any results.

Neither you nor Charles has addressed how gateways are going to
handle the differences from RFC 2822 that you wish to impose.
That is necessary before locking down any such proposal.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7EDAHve072069; Sun, 14 Aug 2005 06:10:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7EDAHJb072067; Sun, 14 Aug 2005 06:10:17 -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 j7EDAG7R072054 for <[e-mail]>; Sun, 14 Aug 2005 06:10: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 ns2.townisp.com (Postfix) with ESMTP id B636C299C4; Sun, 14 Aug 2005 09:10: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 j7EDADmC007966(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, 14 Aug 2005 09:10:13 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7EDADHE007965(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, 14 Aug 2005 09:10:13 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
Date: Sun, 14 Aug 2005 09:10:07 -0400
User-Agent: KMail/1.8.2
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 Fri August 12 2005 07:23, Harald Tveit Alvestrand wrote:
> 
> We've been around the bush of relationship to RFC 2822 a number of times.
> This impacts #1052 (changes from RFC 2822), #1084 (Names for ABN 
> forpductios redefining 2822 constructs).
[...]
> Suggested, expanded text:
> 
> 2.1  Base
> 
>    An article is said to be conformant to this specification if it
>    conforms to the format specified in RFC 2822 section 3 and to the
>    additional requirements of this specification.
> 
>    An article that uses the obsolete syntax specified in section 4 of
>    [RFC2822], except for the two exceptions mentioned below, is NOT
>    conformant to this specification.
>
>    This document, and specifications that build upon it, specifies how
>    to handle conformant articles. Handling of non-conformant articles
>    is outside the scope of this specification; agents may choose
>    to accept such articles, reject such articles or modify such articles.

Does USEPRO build upon "this specification" (presumably USEFOR, though you
didn't say so)?  UsePRO is going to have to deal with acceptance/rejection
of proto-articles/articles, and modifications (by gateways).
 
>    Agents conforming to this specification MUST generate only conformant
>    articles.

"generate" is ambiguous; if a non-conforming article is received by a
transport agent which then modifies Path and retransmits the modified
article (but w/o changing whatever caused the article to be non-conformant),
does that constitute conforming behavior?  John says no, the non-conformant
article MUST be rejected, and I tend to agree with his reasoning.

>    Articles are conformant if they use 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.

I agree with John's comments.  I would add that it's rather silly to make
an exception for something which is hardly necessary *and* which is
expressly forbidden by any article generators.
 
>    Articles are conformant if they use the "GMT" timezone, as specified
>    in section 3.1.2.

That is a silly, inconsistent, and unnecessary difference from 2822.  It is
silly because it singles out one alphabetic zone abbreviation from many,
all of which are in current use in Usenet, and all of which are treated
uniformly by RFCs 561, 724, 733, 822, 850, 1036, and 2822.  The
inconsistency is explained below.  I believe that the lack of necessity is
evident from past discussion as well as the fact that there is no such
exception for any other use of the Internet Message Format.

>    The text below uses ABNF to specify restrictions on the syntax
>    specified in [RFC2822]; this grammar is intended to be more restrictive
>    than the RFC 2822 grammar.
>    Articles must conform to both the ABNF specified in RFC 2822 and to the
>    ABNF specified here, as applicable.

That fails to indicate *why* syntax is specified to be "more restrictive"
(in the case of "GMT" it is in fact *less* restrictive, which is
inconsistent with the claim of being "more restrictive").  It also fails
to provide a roadmap to full conformance with the Internet Message Format,
which we are agreed is desirable.  There is also the issue of field and
field component naming conflicts with 2822.  And any remaining differences
are going to have to be dealt with by gateways, so we ought to take time
to carefully review the implications and relevant USEPRO text regarding
gateways before finalizing USEFOR.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ECfHl5061859; Sun, 14 Aug 2005 05:41:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ECfHbL061857; Sun, 14 Aug 2005 05:41: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 j7ECfFJG061842 for <[e-mail]>; Sun, 14 Aug 2005 05:41: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 B19D5299C1; Sun, 14 Aug 2005 08:41: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 j7ECfAiD028526(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, 14 Aug 2005 08:41:10 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7ECf7Pu028511(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, 14 Aug 2005 08:41:09 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Sun, 14 Aug 2005 08:40:56 -0400
User-Agent: KMail/1.8.2
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 Fri August 12 2005 07:28, Harald Tveit Alvestrand wrote:

> My current suggestion for SYNTAX (that is, what goes into USEFOR)
> 
> - Specify "identities" as domain-names

OK.

> or barewords,

We then need to specify a mechanism that guarantees the necessary
uniqueness of those "barewords" required by the use of the Path field for
preventing retransmissions without precluding propagation.  Or limit
"identities" to domain names, which provide the necessary uniqueness.

> period  
> 
> - Specify that "diagnostics" are PERMITTED in the path, and that this 
> standard does not restrict the format of diagnostics very much (in fact, 
> permit all of [A-Za-z0-9.:], and then shut up)

We then need to specify clearly how diagnostics are distinguished from
"identities" (and keywords, unless keywords are eliminated).  One
possible mechanism would be to put diagnostics in RFC 2822 comments,
in which case they are clearly separated into human-readable but
semantically invisible content, and there is no need for keywords.
 
> - Permit : in "diagnostics", not in "identities", and add some appropriate 
> note with warnings on what will happen to DEAD:BEEF:CAFE

Depends on how syntactic separation of diagnostics vs. "identities" is
handled.  If diagnostics are comments, it doesn't matter what (as long as
it is valid 2822 ccontent) appears there.

> Signing out for the weekend,

What, no "posters for the week" statistics? :-,



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E2FdXG075191; Sat, 13 Aug 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 j7E2FdCX075190; Sat, 13 Aug 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 j7E2FcKN075175 for <[e-mail]>; Sat, 13 Aug 2005 19:15:39 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-163.midband.mdip.bt.net ([81.144.75.163]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42fea949.a9da.4 for [e-mail]; Sun, 14 Aug 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 j7E2CEC08916 for [e-mail]; Sun, 14 Aug 2005 03:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22293
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Next steps - please concentrate on USEFOR again
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Sat, 13 Aug 2005 22:15:50 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]> Harald Tveit Alvestrand <[e-mail]> writes:

>Given that our first task is to finish USEFOR, I'll ask people to hold off 
>discussion on USEPRO issues until we've finished this round of USEFOR 
>updates.

Well there are some issues where both the USEPRO and USEFOR aspects need
to be considered together (the syntax and construction of the Path are a
case in point).

As for USEFOR, I have a couple of issues:

1. Son-of-1036 said that article bodies SHOULD NOT be empty (it broke some
implementations).

All our earlier drafts re-iterated that provision.

For some reason, it never got into USEFOR (though not including it was
never discussed). Please can we decide now whether or not be want to
retain that restriction?

2. I propose that the individual terms [reading, posting, followup] agent
and [injecting, relaying, serving] agent be defined in and used only in
USEPRO. And that in USEFOR the terms "user agent" and "news-server" be
used for those two groups (I have not checked in detail, but I think there
would be no problem changing USEFOR in that way). All the remaining
definitions are already pretty much the same now in USEFOR and USEPRO, and
would therefore appear only in USEFOR.

This idea has been mentioned eariler, and a few people expressed support.
It would make my job in USEPRO somewhat simpler, on account of the way I
currently introuce those terma as part of an overview of the general
architecture.

Please can we have tickets for these?

-- 
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 j7E2FdZ9075183; Sat, 13 Aug 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 j7E2FdOM075182; Sat, 13 Aug 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 j7E2Fc9u075174 for <[e-mail]>; Sat, 13 Aug 2005 19:15:38 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-75-163.midband.mdip.bt.net ([81.144.75.163]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42fea949.a9da.3 for [e-mail]; Sun, 14 Aug 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 j7E2CDI08912 for [e-mail]; Sun, 14 Aug 2005 03:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22292
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1093 Email addresses - conclusion
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <BF9529995E07CE370AB932FE@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]>
Date: Sat, 13 Aug 2005 22:03:52 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]> "Forrest J. Cavalier III" <[e-mail]> writes:

>Charles Lindsey wrote:
>> In the meantime, I shall rewrite those USEPRO texts and we can debate them
>> as part of the Path debate (whose issue number escapes me just at the
>> moment). From what you have said, a NOTE pointing out that these path
>> identities are also used for sending email, with a pointer to USEAGE
>> and/or RFC 2142, would be in order.

>I object.

>Despite what RFC2142 tries to claim, putting an address in the
>path is not "advertising" that the machine exists for receiving
>complaints via email.

Nobody ever said it was. But if it is an FQDN (which we seem to agree is
the preferred form), then it is automatically a candidate for trying to
send email to (and, as you point out, RFC 2142 gows way beyind that, so it
can no longer be claimed that this is not a possible secondary use for the
Path entries).

Anyway, our Chair did say that a non-normative NOTE to this effect would
be in order, and therefore I propose to incorporate such a NOTE, for your
consideration.

-- 
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 j7CM2Urj076697; Fri, 12 Aug 2005 15:02:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CM2Ut3076696; Fri, 12 Aug 2005 15:02:30 -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 j7CM2Tmh076650 for <[e-mail]>; Fri, 12 Aug 2005 15:02:29 -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 j7CM25B0040246 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 12 Aug 2005 15:02:09 -0700 (PDT)
Date: Fri, 12 Aug 2005 15:02:20 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>  This document, and specifications that build upon it, specifies how
>  to handle conformant articles. Handling of non-conformant articles
>  is outside the scope of this specification;

s/;/./  Outside of scope is outside of scope.

>    agents may choose
>  to accept such articles, reject such articles or modify such articles.

"Agents", in the general sense, should NEVER be allowed to modify
non-conforming articles, unless there is a specific modification to
correct something specific and the correction is well defined. If a
relaying agent, e.g., gets a non-conforming article, the only correct
assumption a conforming agent can make is that the article was mangled in
transit and it MUST be dropped. It must assume that the agents next to it
are operating correctly and would not create non-conforming articles; thus
the only way it became non-conforming is through some error in transit.

Further, agents, in the general sense, MUST NOT accept non-conforming
articles, for precisely the same reason. All that is left is "reject".

>  Articles are conformant if they use 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.

How do article generate "productions" of syntax? Perhaps you mean "agents 
MUST NOT generate".

>  Articles must conform to both the ABNF specified in RFC 2822 and to the
>  ABNF specified here, as applicable.

"Both" and "as applicable" are contradictions. "Both" means both apply,
and there is no "if" or "as". 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CLT1wd064428; Fri, 12 Aug 2005 14:29:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CLT1J9064427; Fri, 12 Aug 2005 14:29:01 -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 j7CLT0Wp064413 for <[e-mail]>; Fri, 12 Aug 2005 14:29:00 -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 j7CLSutS005265; Fri, 12 Aug 2005 17:28:56 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7CLStMb005264; Fri, 12 Aug 2005 17:28:55 -0400 (EDT)
Date: Fri, 12 Aug 2005 17:28:55 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1053 Relationship to RFC 2822 - suggestion
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, 12 Aug 2005, Frank Ellermann wrote:
> >| or modify such articles.
> 
> ...but that's one of the things I'd not say in a standard, even
> if it's true.

Concur.  The standard should say nothing that might appear to endorse
modifying already-injected articles, except for the obvious requirement to
adjust Path and possibly Xref. 

                                                          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 j7CL5UBv057092; Fri, 12 Aug 2005 14:05:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CL5Ujs057091; Fri, 12 Aug 2005 14:05: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 j7CL5SB9057078 for <[e-mail]>; Fri, 12 Aug 2005 14:05:29 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E3gh0-00078l-50 for [e-mail]; Fri, 12 Aug 2005 23:03:54 +0200
Received: from c-180-160-149.hh.dial.de.ignite.net ([62.180.160.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 23:03:54 +0200
Received: from nobody by c-180-160-149.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 23:03:54 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1053 Relationship to RFC 2822 - suggestion
Date:  Fri, 12 Aug 2005 22:57:41 +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: c-180-160-149.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:

>| Handling of non-conformant articles is outside the scope of
>| this specification; agents may choose to accept such
>| articles, reject such articles

So far it's fine...

>| or modify such articles.

...but that's one of the things I'd not say in a standard, even
if it's true.  Let's say "may" ... "accept such articles", not
more.  Obviously there's an implicit "maybe not" (= reject),
don't talk about it, and there's also a very hidden implicit
"how they accept it is their business" (= modify), but don't
say it, it's out of scope.

> Does this make sense?

Yes, I like it better than the old terse text, but please don't
mention "modify", that's the private horror show of those who
try to pull this stunt (e.g. mail2news gateways, news servers
fixing the magic SP, 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 j7CKm3VD051113; Fri, 12 Aug 2005 13:48:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CKm3l8051112; Fri, 12 Aug 2005 13:48:03 -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 j7CKm1Vo051094 for <[e-mail]>; Fri, 12 Aug 2005 13:48:01 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E3gQN-0005GB-Sl for [e-mail]; Fri, 12 Aug 2005 22:46:43 +0200
Received: from c-180-160-149.hh.dial.de.ignite.net ([62.180.160.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 22:46:43 +0200
Received: from nobody by c-180-160-149.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 22:46:43 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 Path field delimiters and syntax - status
Date:  Fri, 12 Aug 2005 22:44:07 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
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-180-160-149.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:

> - Specify "identities" as domain-names or barewords, period

Maybe modulo "_" (underscore) for FQDNs, copying syntax as
found in RfC 3696 or elsewhere (something with LDH + dots).

Not essential, but this obscure underscore bothers me.  We
have more than enough strange ideas in USEFOR.  Adding our
own vision of "FQDN with underscore" should't be one of it.

> - Specify that "diagnostics" are PERMITTED in the path,
>   and that this standard does not restrict the format of
>   diagnostics very much (in fact, permit all of
>   [A-Za-z0-9.:], and then shut up)

2119 + PERMITTED ?  <g>

> Does this make sense?

Yes, s/PERMITTED/MAY/ or similar.  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 j7CHcpu1029943; Fri, 12 Aug 2005 10:38:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CHco5q029941; Fri, 12 Aug 2005 10:38: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 j7CHcnMJ029932 for <[e-mail]>; Fri, 12 Aug 2005 10:38:49 -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 j7CHcS3u031200 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 12 Aug 2005 10:38:28 -0700 (PDT)
Date: Fri, 12 Aug 2005 10:38:44 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: #1047 Path field delimiters and syntax - status
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>- Permit : in "diagnostics", not in "identities", and add some appropriate 
>note with warnings on what will happen to DEAD:BEEF:CAFE

>Does this make sense?

No. ':' is even less needed if the entry is only a "diagnostic", whatever
that is supposed to be. 

Proposal already on table to deal with IPv6 literals in path identities
and the use of colons. There is even less reason not to use it since you
want to limit their existance to "diagnostics".

And it matches the last text you produced for ABNF for path identities.

"We know this bad thing can happen if you do this. Instead of providing a
safe way to do it, we'll let you do the bad thing anyway." Good 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 j7CGR9mL024483; Fri, 12 Aug 2005 09:27:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CGR9DI024482; Fri, 12 Aug 2005 09:27:09 -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 j7CGR9ep024474 for <[e-mail]>; Fri, 12 Aug 2005 09:27: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 j7CGR6Bv002336 for <[e-mail]>; Fri, 12 Aug 2005 09:27:07 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id DF49FE7932; Fri, 12 Aug 2005 09:27:05 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1047 Path field delimiters and syntax - status
In-Reply-To: <[e-mail]> (Harald Tveit Alvestrand's message of "Fri, 12 Aug 2005 13:28:32 +0200")
Organization: The Eyrie
References: <[e-mail]>
Date: Fri, 12 Aug 2005 09:27:05 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> My current suggestion for SYNTAX (that is, what goes into USEFOR)

> - Specify "identities" as domain-names or barewords, period

> - Specify that "diagnostics" are PERMITTED in the path, and that this 
> standard does not restrict the format of diagnostics very much (in fact, 
> permit all of [A-Za-z0-9.:], and then shut up)

> - Permit : in "diagnostics", not in "identities", and add some appropriate 
> note with warnings on what will happen to DEAD:BEEF:CAFE

> Does this make sense?

Looks good to me.

-- 
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 j7CBSe7O098005; Fri, 12 Aug 2005 04:28:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CBSdJB098004; Fri, 12 Aug 2005 04:28: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 j7CBSd8E097996 for <[e-mail]>; Fri, 12 Aug 2005 04:28:39 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38D4E32009A for <[e-mail]>; Fri, 12 Aug 2005 13:28:33 +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 10753-05 for <[e-mail]>; Fri, 12 Aug 2005 13:28: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 62002320098 for <[e-mail]>; Fri, 12 Aug 2005 13:28:28 +0200 (CEST)
Date: Fri, 12 Aug 2005 13:28:32 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1047 Path field delimiters and syntax - 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: by 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>

At the moment, I have

- My suggestion to separate "diagnostic information" from "identities"; in 
the syntax, the result is that parsers need to expect both.

- A lot of debate on where and why IP addresses occur in the path, 
including some ideas from Charles about annotating the IP addresses with 
extra syntax that allows some more intelligent guessing on why they were 
added

My current suggestion for SYNTAX (that is, what goes into USEFOR)

- Specify "identities" as domain-names or barewords, period

- Specify that "diagnostics" are PERMITTED in the path, and that this 
standard does not restrict the format of diagnostics very much (in fact, 
permit all of [A-Za-z0-9.:], and then shut up)

- Permit : in "diagnostics", not in "identities", and add some appropriate 
note with warnings on what will happen to DEAD:BEEF:CAFE

Does this make sense?

Signing out for the weekend,

                       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 j7CBNJOd097011; Fri, 12 Aug 2005 04:23:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CBNJ1B097010; Fri, 12 Aug 2005 04:23:19 -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 j7CBNHYc097002 for <[e-mail]>; Fri, 12 Aug 2005 04:23:18 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B3F432009A for <[e-mail]>; Fri, 12 Aug 2005 13:23:11 +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 10753-03 for <[e-mail]>; Fri, 12 Aug 2005 13:23:07 +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 B3471320098 for <[e-mail]>; Fri, 12 Aug 2005 13:23:07 +0200 (CEST)
Date: Fri, 12 Aug 2005 13:23:12 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1053 Relationship to RFC 2822 - suggestion
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: by 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>

We've been around the bush of relationship to RFC 2822 a number of times.
This impacts #1052 (changes from RFC 2822), #1084 (Names for ABN 
forpductios redefining 2822 constructs).
Some clarification may be needed - I THINK we have a mostly-shared opinion, 
but we might benefit from being more explicit.

Current text from 2.1:

2.1  Base

   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.

Suggested, expanded text:

2.1  Base

   An article is said to be conformant to this specification if it
   conforms to the format specified in RFC 2822 section 3 and to the
   additional requirements of this specification.

   An article that uses the obsolete syntax specified in section 4 of
   [RFC2822], except for the two exceptions mentioned below, is NOT
   conformant to this specification.

   This document, and specifications that build upon it, specifies how
   to handle conformant articles. Handling of non-conformant articles
   is outside the scope of this specification; agents may choose
   to accept such articles, reject such articles or modify such articles.

   Agents conforming to this specification MUST generate only conformant
   articles.

   Articles are conformant if they use 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.

   Articles are conformant if they use the "GMT" timezone, as specified
   in section 3.1.2.

   The text below uses ABNF to specify restrictions on the syntax
   specified in [RFC2822]; this grammar is intended to be more restrictive
   than the RFC 2822 grammar.
   Articles must conform to both the ABNF specified in RFC 2822 and to the
   ABNF specified here, as applicable.


Does this make sense?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CA2cWq087307; Fri, 12 Aug 2005 03:02:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CA2bwN087306; Fri, 12 Aug 2005 03:02:37 -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 j7CA2ZwG087291 for <[e-mail]>; Fri, 12 Aug 2005 03:02:35 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 546BE32009A for <[e-mail]>; Fri, 12 Aug 2005 12:02:29 +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 08860-05 for <[e-mail]>; Fri, 12 Aug 2005 12:02:24 +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 6D248320099 for <[e-mail]>; Fri, 12 Aug 2005 12:02:23 +0200 (CEST)
Date: Fri, 12 Aug 2005 12:02:28 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Archives: Text version seems available and up-to-date
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: by 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>

For those of you who dislike the Web-based archives provided by IMC, a 
text-based version is now available.

See <ftp://ftp.ietf.org/ietf-mail-archive/usefor>

At last sighting, it appeared to be up-to-date.

                           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 j7C4omqD088800; Thu, 11 Aug 2005 21:50:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C4omNu088799; Thu, 11 Aug 2005 21:50:48 -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 j7C4okCu088793 for <[e-mail]>; Thu, 11 Aug 2005 21:50:46 -0700 (PDT) (envelope-from [e-mail])
Received: from root by ciao.gmane.org with local (Exim 4.43) id 1E3RUw-0004he-Sg for [e-mail]; Fri, 12 Aug 2005 06:50:26 +0200
Received: from c-180-160-191.hh.dial.de.ignite.net ([62.180.160.191]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 06:50:26 +0200
Received: from nobody by c-180-160-191.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 06:50:26 +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, 12 Aug 2005 06:27:14 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 39
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-191.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:

> Usenetters requested elimination of CFWS (but no other
> changes) to accommodate news software.  That change was made
> to the syntax (but no change to semantics of the RHS)
> accordingly.

Apparently they forgot the other issues, NO-WS-CTL and ">" and
some kind of "canonical" <msg-id>.  So now we fix that back to
VCHAR modulo some details as it always was, still is, and will
be for the foreseeable future (as far as NNTP is concerned).

> Given the fact that a domain name can be up to 255 octets,
> limiting a msg-id (domain name plus local-part plus '<', '@',
> and '>') simply isn't rational.

I could justify 322, and a limit is rational.  By some accident
we inherit 250.  It's ugly like hell, but replacing it by 322
if that breaks existing software everywhere makes no sense.

We discussed this already in the past years, so let's agree to
disagree about the ugly limit (of course we do agree that it's
ugly).

> Tilting at windmills didn't work well for Don Quixote.

Except from the stolen RfC 2822 names I'm happy with the fixed
syntax.  Syntactically Charles' and my version are identical -
we didn't talk for months about it without any results.

One minor difference, his version allows [] as RHS (an empty
domain-literal), my version wants non-empty domain-literals.

The real problem is of course that I in fact want <id-domain>,
where Charles allows random strings, a real domain-literal is
never empty.
                            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 j7C4fPUV088253; Thu, 11 Aug 2005 21:41:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C4fPpL088252; Thu, 11 Aug 2005 21:41: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 j7C4fNSq088243 for <[e-mail]>; Thu, 11 Aug 2005 21:41:24 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E3RL2-000441-Vj for [e-mail]; Fri, 12 Aug 2005 06:40:13 +0200
Received: from c-180-160-191.hh.dial.de.ignite.net ([62.180.160.191]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 06:40:12 +0200
Received: from nobody by c-180-160-191.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 06:40:12 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1003 Message-ID issues - status
Date:  Fri, 12 Aug 2005 06:36:55 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
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-191.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:

>> Therefore our "implementation details" should use different
>> names, because they really are different from 2822 details.
 
> If you want to change to an incompatible format, then use
> different field names to avoid confusion.

How about <id-local> and <id-domain> ?

>> Our semantics of the RHS is "domain", not "domain or
>> whatever".
 
> Same as RFC 2822. And 822. Also 733 and 724 if you accept
> pre-DNS "host" as analogous to domain.

Charles claims that <id-right> is "domain or whatever".  For
<id-domain> I'd hope that this is obviously wrong, dangerous,
harmful, etc.  Without tons of additional SHOULD and MUSTard.

                            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 j7C3vKHT084240; Thu, 11 Aug 2005 20:57:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C3vKqB084239; Thu, 11 Aug 2005 20:57: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 j7C3vJRU084232 for <[e-mail]>; Thu, 11 Aug 2005 20:57:19 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E3QeJ-00016i-Up for [e-mail]; Fri, 12 Aug 2005 05:56:03 +0200
Received: from c-180-160-191.hh.dial.de.ignite.net ([62.180.160.191]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 05:56:03 +0200
Received: from nobody by c-180-160-191.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 05:56:03 +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, 12 Aug 2005 05:54:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
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: c-180-160-191.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:

> Comments before I propose syntax?

Apparently not only I didn't comment Bruce's idea, nobody did,
or it was off list, or a case of bad timing beause we were
busy with tons of other details at this time (July 10 2004).

<http://article.gmane.org/gmane.ietf.usenet.format/27216>

What do you think of it ?  It avoids RfC 2231.  What are the
disadvantages ?
                           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 j7C3moQZ083671; Thu, 11 Aug 2005 20:48:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C3moxT083670; Thu, 11 Aug 2005 20:48:50 -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 j7C3mmgQ083663 for <[e-mail]>; Thu, 11 Aug 2005 20:48:49 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E3QWG-0000er-Cf for [e-mail]; Fri, 12 Aug 2005 05:47:44 +0200
Received: from c-180-160-191.hh.dial.de.ignite.net ([62.180.160.191]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 05:47:44 +0200
Received: from nobody by c-180-160-191.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 12 Aug 2005 05:47:44 +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, 12 Aug 2005 05:45:36 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 65
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-191.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 probably forgot it.  Search the archives for
> Message-ID: <[e-mail]>
> IIRC, you're the "examples-are-better-than-syntax" guy :-).

Omigod, July 10 2004.  Unfortunately still the old list, so
it's not easy to check what else happened at this time.

July 1, Russ tells me that 2231 exists, strange, I thought
that it was you.  Maybe 2231 made me so angry that I plonked
somebody (whatever that means with my "mozilla 3").  Lots of
articles about back-references, complaints-to, cmsg <sigh />
oops, yes, here it is, July 3 and 4:

<http://mid.gmane.org/[e-mail]>
<http://mid.gmane.org/[e-mail]>

Scanning until July 19, no, I really missed or ignored your
proposal.  We discussed URL folding and 2017 at this time.

Harald just closed the Injection-Date ticket, so maybe this
is no good time to reintroduce the <date-time> part of your
idea.  Otherwise it's very much like "Received", apparently 
you want to use some of the same <item-name>.

It doesn't use 2231 <parameter>, it uses 2822 <name-val-list>
with <item-name> and <item-value>.  Fine, so why don't we do
it this way ?

> Special offer; three for the price of one!

Compared with 2231 even #1 is better.

> I'd still do Complaints-To as a bracketed URI list.  Same
> general form as List-Post; plenty of reusable code for that.

Okay, I like your #1..#3 idea, and maybe it's then better to
go back to a separate Complaints-To.

~~~  
>> Yes. = and ? are no specials, but if there's a blank =>
>> quoted.
 
> Remember that RFC 2045 that I suggested rereading?  Look up
> "tspecial".

Sure, I know it.
SPECIALS : " ( ) , .   : ; <   >   @ [ \ ]
TSPECIALS: " ( ) ,   / : ; < = > ? @ [ \ ]

We discussed solutions without <parameter> like <name-val-list>
or a similar construct in the Received-SPF header field IIRC.

So 2045 rules about <parameter> don't enter the picture.  If we
want <quoted-string> all of <qtext> is okay, incl. "=" and "?".

Your idea is much better than my idea, let's forget the latter.

In essence what you propose is to replace all 'name = "value"'
by 'name value'.  CFWS separated words.  So far that's KISS and
better than 2231, where are the problems ?

                            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 j7BHNRxd094158; Thu, 11 Aug 2005 10:23:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BHNRBR094157; Thu, 11 Aug 2005 10:23:27 -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 j7BHNRoh094138 for <[e-mail]>; Thu, 11 Aug 2005 10:23:27 -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 j7BHN6tW010928 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 11 Aug 2005 10:23:06 -0700 (PDT)
Date: Thu, 11 Aug 2005 10:23:21 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Angels, pins, 2142 and 2119
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>- RFC 2142 is, largely, a failed standard. Most sites do not claim 
>conformance to it now, most sites won't claim conformance to it in the 
>future.

It is, however, the existing standard in the area. If it is ignored, then
there is zero reason to believe that our rewrite into USEFOR output will 
be any less ignored. Smoke, mirrors, and changing reality, eh? Who's 
trying to do that now?

>- RFC 2119 is a guideline, and was written in English, not mathematical 
>language.

It is a guideline the we explicitely claim to be following. Guideline or
rock-hard standard irrelevant, when we say we use the terms the same way
and then routinely ignore it, we are lying.

>Please choose a more constructive style of debate in the future; battering 
>each other with "the only possible way to read this paragraph is FOO, 
>therefore you can/cannot recommend BAR" is Just Not Helpful.

Please provide a reference for the quote. Or anything close to it.

>Anyway, most of the real arguments in that thread are now completely moot, 
>given that the group has consensus to not mandate anything about email 
>addresses in the USEPRO document.

Sigh. I guess red really is blue. 

>The USEPRO document will not say MUST or SHOULD about any of the addresses 
>"abuse@identity", "usefor@identity" or "news@identity".

So we get to go through the whole thing again when USAGE is brought up.
Fine. Maybe the consensus will change betwixt now and thence.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7BBuxcV028160; Thu, 11 Aug 2005 04:56:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BBuxoL028159; Thu, 11 Aug 2005 04:56:59 -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 j7BBuwep028144 for <[e-mail]>; Thu, 11 Aug 2005 04:56:58 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F411E3200EA for <[e-mail]>; Thu, 11 Aug 2005 13:56: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 03125-08 for <[e-mail]>; Thu, 11 Aug 2005 13:56: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 24A753200E8 for <[e-mail]>; Thu, 11 Aug 2005 13:56:49 +0200 (CEST)
Date: Thu, 11 Aug 2005 13:56:53 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Re: #1048 Injection-date
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: by 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 don't see any strong push to change injection-date into a component of 
injection-info. So I'm closing this ticket with "no change required".

For USEFOR, it's late...

                    Harald

--On fredag, juli 22, 2005 22:57:47 +0200 Frank Ellermann 
<[e-mail]> wrote:

>
> 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 j7BBYfIo020504; Thu, 11 Aug 2005 04:34:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BBYfRH020503; Thu, 11 Aug 2005 04:34:41 -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 j7BBYdtt020489 for <[e-mail]>; Thu, 11 Aug 2005 04:34:40 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A39923200E4; Thu, 11 Aug 2005 13:34:34 +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 02609-09; Thu, 11 Aug 2005 13:34:31 +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 284853200B2; Thu, 11 Aug 2005 13:34:30 +0200 (CEST)
Date: Thu, 11 Aug 2005 13:34:34 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1028 orig-date (was: 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: by 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>

Seems like a good idea, and uncontroversial.
I've changed status to "text accepted".

--On onsdag, juli 20, 2005 08:19:34 +0200 Frank Ellermann 
<[e-mail]> wrote:

>
> 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 j7BBWK2s019704; Thu, 11 Aug 2005 04:32:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BBWKtE019703; Thu, 11 Aug 2005 04:32:20 -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 j7BBWJg9019692 for <[e-mail]>; Thu, 11 Aug 2005 04:32:19 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C9F43200E4; Thu, 11 Aug 2005 13:32: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 02759-04; Thu, 11 Aug 2005 13:32:09 +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 519993200B2; Thu, 11 Aug 2005 13:32:07 +0200 (CEST)
Date: Thu, 11 Aug 2005 13:32:11 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: Russ Allbery <[e-mail]>, [e-mail]
Subject: Re: #1021 Newsgroups header ABNF: Status
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: by 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'm changing the status of this ticket to "text accepted".

                   Harald

--On torsdag, juli 21, 2005 12:00:12 -0700 Russ Allbery <[e-mail]> 
wrote:

>
> 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 j7BBPp4e017439; Thu, 11 Aug 2005 04:25:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BBPpGv017438; Thu, 11 Aug 2005 04:25:51 -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 j7BBPoUV017427 for <[e-mail]>; Thu, 11 Aug 2005 04:25:51 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7AD0B3200E4 for <[e-mail]>; Thu, 11 Aug 2005 13:25:45 +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 02759-01 for <[e-mail]>; Thu, 11 Aug 2005 13:25:40 +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 57DB63200B2 for <[e-mail]>; Thu, 11 Aug 2005 13:25:40 +0200 (CEST)
Date: Thu, 11 Aug 2005 13:25:42 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1093 Email addresses - Consensus
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: by 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 WG chair, I declare consensus.

The USEPRO document will not say MUST or SHOULD about any of the addresses 
"abuse@identity", "usefor@identity" or "news@identity".

                           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 j7BAs1qw005910; Thu, 11 Aug 2005 03:54:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BAs1Vl005909; Thu, 11 Aug 2005 03:54: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 j7BAs1UH005897 for <[e-mail]>; Thu, 11 Aug 2005 03:54:01 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA66F3200E4 for <[e-mail]>; Thu, 11 Aug 2005 12:53:55 +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 01538-06 for <[e-mail]>; Thu, 11 Aug 2005 12:53:52 +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 B3D663200D4 for <[e-mail]>; Thu, 11 Aug 2005 12:53:52 +0200 (CEST)
Date: Thu, 11 Aug 2005 12:53:56 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Angels, pins, 2142 and 2119
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: by 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 have reviewed the thread entitled "New USEPRO path-identity text (Hello, 
Chair?)".

In my opinion, most of the arguments presented in the thread bear about as 
much resembleance to useful input on this group's output as a discussion on 
the number of angels that can dance on the head of a pin.

Remember:

- RFC 2142 is, largely, a failed standard. Most sites do not claim 
conformance to it now, most sites won't claim conformance to it in the 
future.

- RFC 2119 is a guideline, and was written in English, not mathematical 
language. And not very precise English at that. Trying to do word-by-word 
exegesis on the text is not just unprofitable, it's downright silly. We 
need to take a pragmatic approach to usage of the "keywords", and use them 
in ways that will be useful as a guidance to implementors.

- Protocol standards specify requirements for implementations. The way an 
implementation complies is not "are all possible configurations 
standards-compliant?", it is "can the system be configured to be 
standards-compliant?".
Most systems behave in non-compliant ways part of the time, and protocol 
standards have no business trying to require that they don't. That's one 
reason why Best Current Practices (the real ones) are distinct from 
protocol documents.

Please choose a more constructive style of debate in the future; battering 
each other with "the only possible way to read this paragraph is FOO, 
therefore you can/cannot recommend BAR" is Just Not Helpful.

Anyway, most of the real arguments in that thread are now completely moot, 
given that the group has consensus to not mandate anything about email 
addresses in the USEPRO document.


                              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 j7BAWsDr098264; Thu, 11 Aug 2005 03:32:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BAWsa3098263; Thu, 11 Aug 2005 03:32: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 j7BAWrct098250 for <[e-mail]>; Thu, 11 Aug 2005 03:32:54 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B7C83200E4 for <[e-mail]>; Thu, 11 Aug 2005 12:32: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 01171-10 for <[e-mail]>; Thu, 11 Aug 2005 12:32:45 +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 58FAD3200D0 for <[e-mail]>; Thu, 11 Aug 2005 12:32:45 +0200 (CEST)
Date: Thu, 11 Aug 2005 12:32:48 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: Next steps - please concentrate on USEFOR again
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: by 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>

Reviewing the discussion that has occured in July and August, two facts 
seem readily apparent:

- Most of the discussions reach no conclusion
- Most of the discussion is on USEPRO, not USEFOR

Given that our first task is to finish USEFOR, I'll ask people to hold off 
discussion on USEPRO issues until we've finished this round of USEFOR 
updates.

                        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 j7B09KsD087429; Wed, 10 Aug 2005 17:09:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B09KiF087428; Wed, 10 Aug 2005 17:09: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 j7B09J4a087415 for <[e-mail]>; Wed, 10 Aug 2005 17:09: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 j7B090FD011704 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 10 Aug 2005 17:09:00 -0700 (PDT)
Date: Wed, 10 Aug 2005 17:09:14 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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 Wed, 10 Aug 2005, Harald Tveit Alvestrand wrote:

> The poll-maker has said what the intent was - to cover USEPRO only.

The poll-maker did not say this until after the poll was over.  Voting
requires a clear statement on what is being voted on, BEFORE the votes are
cast. "You voted for BLUE but I meant to say RED, so I'll count your vote
as a vote for RED" is not acceptable. This vote was not specific to 
USEPRO. To say now that it was is Redding the Blue.

The poll-maker has already claimed that this poll result covers USEFOR.  
("As WG chair, I conclude that it's possible that the working group can
come to consensus on excluding these requirements from the USEFOR standard
document." "If Frank, Charles and Richard can live with a group consensus
that the USEFOR document is to go forward without any requirement to
support these email addresses, I can declare this issue closed - and
possibly reopen the issue when it's time to update USEAGE.") I'll remind
the chair that USAGE is just as much a USEFOR document as is USEPRO.

We've already covered the concept of a consensus that changes depending on 
the intended reader. What is appropriate to require from an admin in the 
document where we tell him what is required is just as appropriate for the 
document where we tell everyone else what to expect from the admin. 

> Nobody has indicated that they wish to change their opinion based on this 
> clarifiation.

You really expect someone to say "oh, well, now that I know this covers
just USEPRO (or was it USEFOR?) I'll say that there should be a mandate in
USEPRO..."? That's ridiculous. I suspect that those who said "no
requirement" actually meant it, and they probably didn't mean "no
requirement today, but require it next month." I certainly didn't mean 
that.
 
> NOW SHUT UP.

Thanks for your kind words and careful consideration. And your careful use
of a language you admit is not your main one. You do not accept this kind
of language from other participants, but the Chair is free to amend the 
rules. Has this one been amended permanently?

It's either a consensus or it is not. The issue is either closed or it is
not. If you are not going to treat it as a consensus, then do not waste
our time with a poll about it. Certainly do not waste our time telling us 
that you didn't write what you intended but you'll interpret things as if 
you had anyway.

I swear, you've got as close to a unanimous consensus about an issue as 
I've ever seen this group come to over anything that has been debated, and
you're ready to throw it away because the questions didn't say what you 
wanted them to. You've even got ME clearly compromising over something I 
think ought to be a mandate, but even with this miracle it's not good 
enough. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ALiSUN075582; Wed, 10 Aug 2005 14:44:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ALiSln075581; Wed, 10 Aug 2005 14:44:28 -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 j7ALiRFa075572 for <[e-mail]>; Wed, 10 Aug 2005 14:44:28 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 561A13200D0; Wed, 10 Aug 2005 23:44:21 +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 09081-02; Wed, 10 Aug 2005 23:44:18 +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 73B433200E4; Wed, 10 Aug 2005 23:44:17 +0200 (CEST)
Date: Wed, 10 Aug 2005 23:44:21 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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: by 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>

John,

The poll-maker has said what the intent was - to cover USEPRO only.
Nobody has indicated that they wish to change their opinion based on this 
clarifiation.

NOW SHUT UP.

--On onsdag, august 10, 2005 10:59:54 -0700 John Stanley <[e-mail]> 
wrote:

>
>
> "Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:
>
>> I can live with it if the understanding is that the topic can be covered
>> in USEAGE.
>
> Of course you can "live with it" if you get another chance to hold the
> same argument all over again after a clear consensus contrary to your
> position.
>
> Nothing in the poll limited itself to USEPRO. That's how I voted on it;
> I assume that that is how everyone else voted on it, too, since any
> specificity would certainly warrant at least a mention.
>
> This is ridiculous. Either we think there is "no requirement" or we don't.
> A consensus that changes from day to day simply isn't a consensus.
>
>






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AI6G6N057375; Wed, 10 Aug 2005 11:06:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AI6GJq057374; Wed, 10 Aug 2005 11:06:16 -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 j7AI6Ee0057357 for <[e-mail]>; Wed, 10 Aug 2005 11:06:15 -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 j7AI5stW026313 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 10 Aug 2005 11:05:54 -0700 (PDT)
Date: Wed, 10 Aug 2005 11:06:09 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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>:

>Read carefully what Charles said:  the suggested note would indicate that
>the path identities *are* used for sending mail -- which is true -- not
>that they necessarily *should* be. 

And in which section of which document do you expect we will document the
fact that some people print out USENET messages and use them to line their 
birdcages? If we document all uses of USENET, we must document that one, 
too.

By pointing out that they ARE used that way, with no condemnation from us 
for that use, we've put the implicit stamp of approval on that use.

"Forrest J. Cavalier III" <forrest@xxxxxxxxxxxxxxx>:

>If USEFOR gets a note to that effect, I am not sure what was
>the point of the poll.

The poll apparently has no point, since we'll be debating this same issue
all over again when it comes time to deal with USAGE. Even after the Chair 
has almost semi-determined that there is a consensus on the 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 j7AI1gZA056831; Wed, 10 Aug 2005 11:01:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AI1gJC056830; Wed, 10 Aug 2005 11:01:42 -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 j7AI1fSh056822 for <[e-mail]>; Wed, 10 Aug 2005 11:01:41 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-186-168-pppoe.dsl.hrbg.epix.net [216.37.186.168]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j7AI1egt013138 for <[e-mail]>; Wed, 10 Aug 2005 14:01:40 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 Aug 2005 14:01:40 -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: #1093 Email addresses - conclusion
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>

Henry Spencer wrote:

> 
> Read carefully what Charles said:  the suggested note would indicate that
> the path identities *are* used for sending mail -- which is true -- not
> that they necessarily *should* be. 

Somone using documented headers for wrong purposes makes no obligation
to place text in any document.

There is no end to telling implementors about stupid user behavior.

What's next?  Do we tell admins that placing a path-identity will result
in DNS lookups and "curious" NNTP CONNECT requests by people looking for
open servers?

That may be worthwhile to point out, but not in USEFOR or USEPRO, not even in a
NOTE pointing them to USEAGE.

Otherwise we end up with dozens or hundreds of NOTES pointing out that
they should read 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 j7AI053B056654; Wed, 10 Aug 2005 11:00:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AI05l0056653; Wed, 10 Aug 2005 11:00:05 -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 j7AI04LP056636 for <[e-mail]>; Wed, 10 Aug 2005 11:00:04 -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 j7AHxfFD088028 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 10 Aug 2005 10:59:45 -0700 (PDT)
Date: Wed, 10 Aug 2005 10:59:54 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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 can live with it if the understanding is that the topic can be covered
>in USEAGE. 

Of course you can "live with it" if you get another chance to hold the
same argument all over again after a clear consensus contrary to your
position.

Nothing in the poll limited itself to USEPRO. That's how I voted on it;
I assume that that is how everyone else voted on it, too, since any 
specificity would certainly warrant at least a mention. 

This is ridiculous. Either we think there is "no requirement" or we don't.
A consensus that changes from day to day simply isn't a consensus.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AH674H051836; Wed, 10 Aug 2005 10:06:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AH67HA051833; Wed, 10 Aug 2005 10:06:07 -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 j7AH65nZ051805 for <[e-mail]>; Wed, 10 Aug 2005 10:06:06 -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 j7AH62tS001132; Wed, 10 Aug 2005 13:06:02 -0400 (EDT)
Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j7AH62NA001131; Wed, 10 Aug 2005 13:06:02 -0400 (EDT)
Date: Wed, 10 Aug 2005 13:06:02 -0400 (EDT)
From: Henry Spencer <[e-mail]>
To: Usefor Mailing List <[e-mail]>
Subject: Re: #1093 Email addresses - conclusion
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, 10 Aug 2005, Forrest J. Cavalier III wrote:
> > ...From what you have said, a NOTE pointing out that these path
> > identities are also used for sending email, with a pointer to USEAGE
> > and/or RFC 2142, would be in order.
> 
> ...Despite what RFC2142 tries to claim, putting an address in the
> path is not "advertising" that the machine exists for receiving
> complaints via email.

Read carefully what Charles said:  the suggested note would indicate that
the path identities *are* used for sending mail -- which is true -- not
that they necessarily *should* be. 

                                                          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 j7AGuJ0x051142; Wed, 10 Aug 2005 09:56:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AGuJkD051141; Wed, 10 Aug 2005 09:56:19 -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 j7AGuIL9051134 for <[e-mail]>; Wed, 10 Aug 2005 09:56:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-186-168-pppoe.dsl.hrbg.epix.net [216.37.186.168]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j7AGuBgt023212 for <[e-mail]>; Wed, 10 Aug 2005 12:56:17 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 10 Aug 2005 12:56: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: #1093 Email addresses - conclusion
References: <BF9529995E07CE370AB932FE@B50854F0A9192E8EC6CDA126> <[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:
> In the meantime, I shall rewrite those USEPRO texts and we can debate them
> as part of the Path debate (whose issue number escapes me just at the
> moment). From what you have said, a NOTE pointing out that these path
> identities are also used for sending email, with a pointer to USEAGE
> and/or RFC 2142, would be in order.

I object.

Despite what RFC2142 tries to claim, putting an address in the
path is not "advertising" that the machine exists for receiving
complaints via email.

If USEFOR gets a note to that effect, I am not sure what was
the point of the poll.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AGFbNJ048074; Wed, 10 Aug 2005 09:15:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AGFbiF048073; Wed, 10 Aug 2005 09: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 j7AGFZjI048049 for <[e-mail]>; Wed, 10 Aug 2005 09:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-76-237.midband.mdip.bt.net ([81.144.76.237]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42fa2827.10539.26 for [e-mail]; Wed, 10 Aug 2005 17:15:35 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7AGCFP27439 for [e-mail]; Wed, 10 Aug 2005 17:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22260
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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 10 Aug 2005 15:39:01 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]> "Forrest J. Cavalier III" <[e-mail]> writes:

>You are saying that RFC2119 sentence

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

>actually means

>     For example, they must not be used to try to
>     limit implementors to one particular method
>     where the method is not required for interoperability.

>That makes the RFC2119 sentence meaningless, so that interpretation
>of RFC2119 is wrong.

I do not see how that sentence is "meaningless". It is indeed a reasonable
interpretation of the sentence actually written (and the sentence was only
an "example" anyway).

>I think WG participants mis-interpreting RFC2119 is a matter for
>the Chair.  Either RFC2119 means what you say, or I am correct.
>It can't be both.

RFC 2119 is so badly written that it might even be both :-( .

-- 
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 j7AGFaTX048062; Wed, 10 Aug 2005 09:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AGFaRN048060; Wed, 10 Aug 2005 09: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 j7AGFZrj048048 for <[e-mail]>; Wed, 10 Aug 2005 09:15:35 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-76-237.midband.mdip.bt.net ([81.144.76.237]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42fa2826.10539.25 for [e-mail]; Wed, 10 Aug 2005 17:15:34 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7AGCEW27429 for [e-mail]; Wed, 10 Aug 2005 17:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22258
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1093 Email addresses - conclusion
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <BF9529995E07CE370AB932FE@B50854F0A9192E8EC6CDA126>
Date: Wed, 10 Aug 2005 15:26:19 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 <BF9529995E07CE370AB932FE@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>As WG chair, I conclude that it's possible that the working group can come 
>to consensus on excluding these requirements from the USEFOR standard 
>document. (I don't see any strong arguments against putting in a NOTE 
>saying that these practices exist, however - that's not normative).

>If Frank, Charles and Richard can live with a group consensus that the 
>USEFOR document is to go forward without any requirement to support these 
>email addresses, I can declare this issue closed - and possibly reopen the 
>issue when it's time to update USEAGE.

I can live with it if the understanding is that the topic can be covered
in USEAGE. I shall write some USEAGE text (but not this week).

In the meantime, I shall rewrite those USEPRO texts and we can debate them
as part of the Path debate (whose issue number escapes me just at the
moment). From what you have said, a NOTE pointing out that these path
identities are also used for sending email, with a pointer to USEAGE
and/or RFC 2142, would be in order.

-- 
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 j7AGFaWD048063; Wed, 10 Aug 2005 09:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AGFaxA048061; Wed, 10 Aug 2005 09: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 j7AGFZHd048047 for <[e-mail]>; Wed, 10 Aug 2005 09:15:35 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-76-237.midband.mdip.bt.net ([81.144.76.237]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42fa2825.10539.24 for [e-mail]; Wed, 10 Aug 2005 17:15:33 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j7AGCFf27435 for [e-mail]; Wed, 10 Aug 2005 17:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22259
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Shame vs Engineering, also NEW conformance criteria
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <uevYB0Kr$[e-mail]>
Date: Wed, 10 Aug 2005 15:34:35 GMT
Lines: 21
Sender: [e-mail]
Precedence: 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 <uevYB0Kr$[e-mail]> Richard Clayton <[e-mail]> writes:

>... this area isn't broken and works passably well IME. Why aren't we
>leaving well alone, documenting what is done and not bothering to
>transcribe other RFCs?

But "passably well" is hardly an ideal state of affairs. However, some
advice in USEAGE on the way that both users and implementors should handle
these matters (based around the algorithm that we discussed) would
probably suffice to keep things running smoothly.

-- 
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 j7ADBrWt014811; Wed, 10 Aug 2005 06:11:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ADBqrh014810; Wed, 10 Aug 2005 06:11:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ADBpH6014791 for <[e-mail]>; Wed, 10 Aug 2005 06:11:51 -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-36.mail.demon.net with esmtp (Exim 4.42) id 1E2qN4-0007FT-K2 for [e-mail]; Wed, 10 Aug 2005 13:11:50 +0000
Message-ID: <[e-mail]>
Date: Wed, 10 Aug 2005 14:10:24 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: #1093 Email addresses - conclusion
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <3f2$+rS$77v5lOKLWue+dOzI9c>
Sender: [e-mail]
Precedence: 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]>,
Harald Tveit Alvestrand <[e-mail]> writes

>>> If Frank, Charles and Richard can live with a group consensus that the
>>> USEFOR document is to go forward without any requirement to support
>>> these  email addresses, I can declare this issue closed
>>
>> And why do these three specific people get to veto a group consensus?
>
>They don't. But if they state that they cannot live with this consensus, 
>and intend to appeal the issue on some basis, it's better to have this in 
>the open.

I have no problem with having no compulsion ... my main concern in
suggesting an alternative way of expressing the requirements was to move
away from telling news server operators what to do -- and describe
instead the operation of the protocol elements so they could choose an
appropriate set of features to achieve what they needed

If we move from that to a position where they don't have to do anything,
then, since nothing is currently broken with no rules, it will not of
itself make anything worse

>>> - and possibly reopen the issue when it's time to update USEAGE.

There I would hope we could base the recommendations upon having an
explicit "Injection-Info:" header field, so that it became entirely
clear how to contact the entity who had control over future postings; by
far the most common "abuse" issue

- -- 
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/AwUBQvn8wJoAxkTY1oPiEQIMUwCg0auVSkptR1kbiKB5naeHOMni2F8AoKMM
S6VNzgK+o1evQCa8rRXMYaei
=oIx5
-----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 j7A6DDuZ057203; Tue, 9 Aug 2005 23:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A6DDem057202; Tue, 9 Aug 2005 23:13:13 -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 j7A6DCCJ057183 for <[e-mail]>; Tue, 9 Aug 2005 23:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A2483200A0 for <[e-mail]>; Wed, 10 Aug 2005 08:13:07 +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 20923-02 for <[e-mail]>; Wed, 10 Aug 2005 08:13:04 +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 5CD8232009C for <[e-mail]>; Wed, 10 Aug 2005 08:13:04 +0200 (CEST)
Date: Wed, 10 Aug 2005 08:13:07 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: English (Re: #1093 Email addresses: Poll results, sort of final)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <F4EF9C6F7616DE12FA5F39C5@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: by 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, august 09, 2005 22:55:28 -0400 Bruce Lilly <[e-mail]> 
wrote:

>> and one person would prefer no
>> mandate, but could live with a SHOULD mandate.
>
> There's no such thing as "a SHOULD mandate"; "SHOULD" is a recommendation
> (indeed it explicitly carries the same meaning as RECOMMENDED).  The BCP
> 14 mandates (as in mandatory, are REQUIRED, MUST, SHALL, MUST NOT, and
> SHALL NOT).

Bruce (and John):

For your info - RFC 2119 refers to MUST, SHOLD and MAY as "requirement 
levels".

The "american heritage dictionary of the English language" defines 
"mandate" (definition one) as "an authoritative command or instruction". 
SHOULD is an authoritative instruction too, but a more complex one.

I could have used a word that you would not have found fault with. I 
didn't. I'm unlikely to use "mandate" again in this context.

Neither of your chairs is a native English speaker. Live with 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 j7A3YqP2017432; Tue, 9 Aug 2005 20:34:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A3Yq3N017431; Tue, 9 Aug 2005 20:34:52 -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 j7A3Yq5C017425 for <[e-mail]>; Tue, 9 Aug 2005 20:34:52 -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 j7A3YpQM018410 for <[e-mail]>; Tue, 9 Aug 2005 20:34:51 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 205C8E792D; Tue,  9 Aug 2005 20:34:51 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
In-Reply-To: <[e-mail]> (Frank Ellermann's message of "Wed, 10 Aug 2005 05:16:13 +0200")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 09 Aug 2005 20:34:51 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:
 
>> If someone wants to arrange a peering relationship via the
>> telephone, I think that's their business.

> Sure.  And if they offer no working address to report problems
> the next entity in the path will be hold responsible.  At that
> point I'd also consider to publish whatever-it-is in a relevant
> group.  But first I'd try to settle it by mail.  Bye, Frank

I think what you're saying above is supporting my point that being able to
reach any individual transit news administrator via e-mail isn't really
required.

-- 
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 j7A3K08a015701; Tue, 9 Aug 2005 20:20:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A3K0Sr015700; Tue, 9 Aug 2005 20:20:00 -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 j7A3Jwxj015683 for <[e-mail]>; Tue, 9 Aug 2005 20:19:58 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2h74-0005b2-8O for [e-mail]; Wed, 10 Aug 2005 05:18:42 +0200
Received: from 212.82.251.166 ([212.82.251.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 10 Aug 2005 05:18:42 +0200
Received: from nobody by 212.82.251.166 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 10 Aug 2005 05:18:42 +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:  Wed, 10 Aug 2005 05:16:13 +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]> <[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.166
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:
 
> Frank Ellermann <[e-mail]> writes:

[oops, I really posted it, for some time I thought that I've
 confused Re:Mail and Re:News again, unusual delay on my side]

> The way that problems are quite frequently reported and fixed
> is that they're mentioned in a public forum and one of the
> peers of the site having problems uses their knowledge of
> contacts at the offending site to track down a solution.

If there is a forum for such problems.  E.g. when clara.net
didn't get nanas for obscure reasons I asked in a local group
what's going on, and some time later it was fixed.

If there's a problem with hamburg.* bothering clara.net admins
with it would be less promising, I'd need some old paths from
more than one server, and then I'd try to guess where the real
problem might be, and contact the corresponding admin.

Generally I stay away from problems where I'd be forced to
interpret paths correctly.  But if it's about rogue cancels or
other cases of net abuse it might interest me.  Posting in say
de.admin.net-abuse.news is not the same as a mail to usenet@,
the former is often more or less qualified public whining.
 
> If someone wants to arrange a peering relationship via the
> telephone, I think that's their business.

Sure.  And if they offer no working address to report problems
the next entity in the path will be hold responsible.  At that
point I'd also consider to publish whatever-it-is in a relevant
group.  But first I'd try to settle it by 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 j7A2teBD011713; Tue, 9 Aug 2005 19:55:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A2teAB011712; Tue, 9 Aug 2005 19:55:40 -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 j7A2tdZK011706 for <[e-mail]>; Tue, 9 Aug 2005 19:55:39 -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 62C32299F4; Tue,  9 Aug 2005 22:55:38 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7A2tY9S019990(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, 9 Aug 2005 22:55:35 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7A2tXgI019989(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, 9 Aug 2005 22:55:33 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1093 Email addresses: Poll results, sort of final
Date: Tue, 9 Aug 2005 22:55:28 -0400
User-Agent: KMail/1.8.2
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <F4EF9C6F7616DE12FA5F39C5@B50854F0A9192E8EC6CDA126>
In-Reply-To: <F4EF9C6F7616DE12FA5F39C5@B50854F0A9192E8EC6CDA126>
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 August 9 2005 09:26, Harald Tveit Alvestrand wrote:

>   1A) All identities that look like domain-names MUST support
[...]
>   1C) Some identities MUST support
>       ("at least one of the <path-identity>s inserted by
>       themselves" is one example of "some")
> 	Charles Lindsey (preferred)
[...]

> Conclusion: 2 people support some form of mandate in USEPRO.

I see only one (unless you're counting some of the "None of the above"
respondents).

> 6 people support not making any mandate in USEPRO (one of which has said 
> that he thinks it's a good idea for USEAGE),

I see 7 in the "no requirement" category alone; surely that means "not making
any mandate".

> and one person would prefer no  
> mandate, but could live with a SHOULD mandate.

There's no such thing as "a SHOULD mandate"; "SHOULD" is a recommendation
(indeed it explicitly carries the same meaning as RECOMMENDED).  The BCP 14
mandates (as in mandatory, are REQUIRED, MUST, SHALL, MUST NOT, and SHALL
NOT).

>   2A) All identities MUST support abuse@identity
> 	Charles Lindsey (one alternative of 2)
[...]
>   2D) Top level domain corresponding to identity MUST support
> 	Frank Ellermann (wants 2)
[...]
> Counting as above, 3 people support some form of mandate.

I see only 2, both of whom also want no mandate.

> 6 people do not support any form of mandate.

I count 7. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A1mpg5005872; Tue, 9 Aug 2005 18:48:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A1mpb7005871; Tue, 9 Aug 2005 18:48:51 -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 j7A1mnh8005863 for <[e-mail]>; Tue, 9 Aug 2005 18:48:50 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2fhj-000667-74 for [e-mail]; Wed, 10 Aug 2005 03:48:27 +0200
Received: from 212.82.251.166 ([212.82.251.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 10 Aug 2005 03:48:27 +0200
Received: from nobody by 212.82.251.166 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 10 Aug 2005 03:48:27 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1093 Email addresses - conclusion
Date:  Wed, 10 Aug 2005 03:44:44 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 13
Message-ID:  <[e-mail]>
References:  <BF9529995E07CE370AB932FE@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: 212.82.251.166
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 don't see any strong arguments against putting in a NOTE
> saying that these practices exist, however - that's not
> normative

I'd like that, the note offers a place for "[RfC2142]" as an
informative reference.  No 2119 keywords.

> Seems reasonable?

Yes, BTW, this issue was about USEPRO, not 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 j79NSg6a093089; Tue, 9 Aug 2005 16:28:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79NSg4T093088; Tue, 9 Aug 2005 16:28:42 -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 j79NSfjA093080 for <[e-mail]>; Tue, 9 Aug 2005 16:28:41 -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 j79NSItW052340 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 9 Aug 2005 16:28:19 -0700 (PDT)
Date: Tue, 9 Aug 2005 16:28:34 -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>

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>>I see both of those as nonsense addresses.

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

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

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

>c'est la vie

Lah Veee.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79MvA05091051; Tue, 9 Aug 2005 15:57:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79MvAP0091050; Tue, 9 Aug 2005 15:57:10 -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 j79MvAFs091043 for <[e-mail]>; Tue, 9 Aug 2005 15:57:10 -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 j79Mv9O9016038 for <[e-mail]>; Tue, 9 Aug 2005 15:57:09 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id EBC82E792D; Tue,  9 Aug 2005 15:57:08 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
In-Reply-To: <[e-mail]> (Frank Ellermann's message of "Tue, 09 Aug 2005 22:08:47 +0200")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 09 Aug 2005 15:57:08 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> UseNetizens incl. admins are not required to have Web
> access.  Therefore it follows that all participants must
> have a working e-mail address - and of course that's an
> interoperability issue, it's the way how problems are
> reported and hopefully fixed.

I don't understand why this follows.

The way that problems are quite frequently reported and fixed is that
they're mentioned in a public forum and one of the peers of the site
having problems uses their knowledge of contacts at the offending site to
track down a solution.

I don't believe I have ever reported or fixed a Usenet problem by
prepending news@, usenet@, or abuse@ to a Path entry and mailing that
address.

> Ordinary users might get away with TLD .invalid in some
> cases, but admins and moderators must offer a working
> e-mail address, otherwise they have no business on this
> planet, let alone in Usenet.

If someone wants to arrange a peering relationship via the telephone, I
think that's their business.

-- 
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 j79KqAU6080802; Tue, 9 Aug 2005 13:52:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79KqA3i080801; Tue, 9 Aug 2005 13:52:10 -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 j79Kq992080793 for <[e-mail]>; Tue, 9 Aug 2005 13:52:09 -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 j79KpjtW096333 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 9 Aug 2005 13:51:45 -0700 (PDT)
Date: Tue, 9 Aug 2005 13:52:01 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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, 9 Aug 2005, Harald Tveit Alvestrand wrote:

> They don't. But if they state that they cannot live with this consensus, 
> and intend to appeal the issue on some basis, it's better to have this in 
> the open.

If you cannot close the issue unless they agree, that's a veto. You said 
that you can close it unless they don't agree, implying you cannot close
it unless they do. If you can close it either way, say so and do so.

> You may be the only person who saw it as not specific to USEPRO.

I read the poll several times, looking for any magic limitations on what 
our consensus was to be applied to. The word USEFOR or USEPRO appeared 
exactly 0 times each. 

Your question was concerning a general policy of what we should require
as a working group in our products. If USAGE is one of those, then I
consider that the question has been asked for USAGE, too.

> So the target audiences may be different.

So, our policy regarding what is justifiable and proper to require from
news admins differs depending on who is reading a document? If an admin 
reads it we think one thing, and if a Joe User reads it we think another?
I don't think so. We've come to a rather clear consensus that "no 
requirement" is our group opinion, for all three addresses. We can't 
logically or honestly write one document assuming there is no requirement
and then put a requirement in the accompanying document. 

> I used "mandate" as a shorthand for "MUST or SHOULD", and counted 1B, 1C 
> and 1D as "some mandate". I did not count Richard Clayton among the 2.

"SHOULD" is not a mandate. 

It is now understandable why our USEPRO editor has not been forced to
respect RFC2119 by the Chair, because our Chair does not respect RFC2119 
himself.

> Either you did not read "mandate" to include "SHOULD", or you did not 
> regard some of the people listed above as people.

I do not regard a recommendation, no matter how "strong" it may be, as a
mandate. If you consider it an option to not consider some of the people
listed as people, feel free, but please refrain from projecting your
condition on me.

> Or there is some other 
> explanation for you counting only 2 people here.

That would be an understanding of what RFC2119 says about "SHOULD", and 
the fact that only two people actually voted for a 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 j79Kfbhs079924; Tue, 9 Aug 2005 13:41:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79Kfb7l079923; Tue, 9 Aug 2005 13:41:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79KfaEM079917 for <[e-mail]>; Tue, 9 Aug 2005 13:41:36 -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-35.mail.demon.net with esmtp (Exim 4.42) id 1E2aq7-00099X-Hd for [e-mail]; Tue, 09 Aug 2005 20:36:47 +0000
Message-ID: <gnLLP5A5SR+CFAk$@highwayman.com>
Date: Tue, 9 Aug 2005 21:40:25 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: Shame vs Engineering
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <0Ny$+jC477vg9OKLnte+dC7ZKr>
Sender: [e-mail]
Precedence: 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]>, John
Stanley <[e-mail]> writes

>Richard Clayton <richard@xxxxxxxxxxxxxx>:
>
>>you ought to consider reading the original emails (hence I've cc'd this
>>to you as well)   Harald wrote  <abuse@xxxxx>  which is a nonsense
>>address (unlike <abuse@xxxxx> which is not)
>
>I see both of those as nonsense addresses.

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

c'est la vie

- -- 
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/AwUBQvkUuZoAxkTY1oPiEQK3ZQCfZsDGKn70H8UK/YQQN0i7+iNhXyEAn2e6
J64Eo/OwveaUb7m4yaq4Ft2P
=ARUi
-----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 j79KYHD8079352; Tue, 9 Aug 2005 13:34:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79KYHdM079351; Tue, 9 Aug 2005 13:34: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 j79KYGad079341 for <[e-mail]>; Tue, 9 Aug 2005 13:34:16 -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 j79KXwFD058462 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 9 Aug 2005 13:33:58 -0700 (PDT)
Date: Tue, 9 Aug 2005 13:34:11 -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>

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>you ought to consider reading the original emails (hence I've cc'd this
>to you as well)   Harald wrote  <abuse@xxxxx>  which is a nonsense
>address (unlike <abuse@xxxxx> which is not)

I see both of those as nonsense addresses. 

>you may also have missed my earlier example of <m@im>

No, I saw your earlier example of m@im. I guess I'm not the only one who
doesn't consider that a valid FQDN. In fact, I seem to recall that UNIX,
at the very least, will always treat that as an UNqualified hostname,
and try to fully qualify it prior to use. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79KO7Uo078456; Tue, 9 Aug 2005 13:24:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79KO7SS078455; Tue, 9 Aug 2005 13:24: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 j79KO5r3078446 for <[e-mail]>; Tue, 9 Aug 2005 13:24:06 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2acM-0002iX-W0 for [e-mail]; Tue, 09 Aug 2005 22:22:35 +0200
Received: from c-134-88-96.hh.dial.de.ignite.net ([62.134.88.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 09 Aug 2005 22:22:34 +0200
Received: from nobody by c-134-88-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 09 Aug 2005 22:22:34 +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:  Tue, 09 Aug 2005 22:08:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 25
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: c-134-88-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>

Forrest J. Cavalier III wrote:

> Chair?

Somewhere in Paul's slides that's called "go to daddy
syndrome" (or similar).  Please don't do this.  Whatever
Alexey or Harald think about 2119, it has the same value
as Bruce's or Charles' interpretation.

Unless they declare "rough consensus" about a particular
USEFOR question of course.  But finding the one and only
way to read 2119 is not - USEFOR is not creating 2119bis.

UseNetizens incl. admins are not required to have Web
access.  Therefore it follows that all participants must
have a working e-mail address - and of course that's an
interoperability issue, it's the way how problems are
reported and hopefully fixed.

Ordinary users might get away with TLD .invalid in some
cases, but admins and moderators must offer a working
e-mail address, otherwise they have no business on this
planet, let alone in Usenet.
                               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 j79KJKB1078228; Tue, 9 Aug 2005 13:19:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79KJK3I078226; Tue, 9 Aug 2005 13:19:20 -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 j79KJJ0Y078212 for <[e-mail]>; Tue, 9 Aug 2005 13:19:19 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 010E23200D4; Tue,  9 Aug 2005 22:19:15 +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 32515-04; Tue,  9 Aug 2005 22:19:11 +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 60A743200D0; Tue,  9 Aug 2005 22:19:11 +0200 (CEST)
Date: Tue, 09 Aug 2005 22:19:14 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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: by 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, august 09, 2005 12:05:49 -0700 John Stanley 
<[e-mail]> wrote:

>
>
> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> If Frank, Charles and Richard can live with a group consensus that the
>> USEFOR document is to go forward without any requirement to support
>> these  email addresses, I can declare this issue closed
>
> And why do these three specific people get to veto a group consensus?

They don't. But if they state that they cannot live with this consensus, 
and intend to appeal the issue on some basis, it's better to have this in 
the open.

>> - and possibly reopen the issue when it's time to update USEAGE.
>
> Your poll was neither USEFOR nor USEPRO specific, and thus it applies to
> USEAGE as well. If the group consensus today is "no requirement", then
> it is ridiculous to come back in a month and debate the whole issue again.

You may be the only person who saw it as not specific to USEPRO.
The ticket as sent to the mailing list mentioned USEPRO specifically, and 
if it was possible to read the poll as applying more widely than the 
ticket, that is my drafting error.

The difference between USEPRO and USEAGE is that (presumably) anyone who 
wants to build interoperable NetNews implementations should follow USEPRO, 
while only those wishing to follow "best practices" (which are not required 
for basic interoperability, but makes life easier for Internet users) would 
follow USEAGE.
So the target audiences may be different.

>> Seems reasonable?
>
> Closing it, yes. Giving three people veto power, no. Reopening it in a
> few  weeks, no.
>
> Regarding your counts:
>
>> Conclusion: 2 people support some form of mandate in USEPRO.
>
> Under question one, I see just one person voting for a mandate, and that
> same person also voted for a non-mandate. Where did you get 2?

  1B) All identities that look like domain-names SHOULD support
	Frank Ellermann
  1C) Some identities MUST support
      ("at least one of the <path-identity>s inserted by
      themselves" is one example of "some")
	Charles Lindsey (preferred)
  1D) Some identities SHOULD support
	Richard Clayton (second)
	Charles Lindsey (second)

I used "mandate" as a shorthand for "MUST or SHOULD", and counted 1B, 1C 
and 1D as "some mandate". I did not count Richard Clayton among the 2.

>> Counting as above, 3 people support some form of mandate.
>
> I count two, and both of those, again, also voted for a non-mandate.

  2A) All identities MUST support abuse@identity
	Charles Lindsey (one alternative of 2)
  2B) All identities SHOULD support
	Richard Clayton (preferred)
	Frank Ellermann (wants 2)
	Charles Lindsey (one alternative of 2)
  2D) Top level domain corresponding to identity MUST support
	Frank Ellermann (wants 2)
  2E) Top level domain corresponding to identity SHOULD support
	Richard Clayton (could live with)

> Is this some kind of "new math" that I was lucky enough to have missed
> out  on?

Either you did not read "mandate" to include "SHOULD", or you did not 
regard some of the people listed above as people. Or there is some other 
explanation for you counting only 2 people here.

                    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 j79JrsKg076557; Tue, 9 Aug 2005 12:53:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79Jrssh076556; Tue, 9 Aug 2005 12:53: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 j79Jrqm7076548 for <[e-mail]>; Tue, 9 Aug 2005 12:53:53 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E2a99-0007ez-A5 for [e-mail]; Tue, 09 Aug 2005 21:52:23 +0200
Received: from c-134-88-96.hh.dial.de.ignite.net ([62.134.88.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 09 Aug 2005 21:52:23 +0200
Received: from nobody by c-134-88-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 09 Aug 2005 21:52:23 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Shame vs Engineering, also NEW conformance criteria
Date:  Tue, 09 Aug 2005 21:46:37 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 41
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <uevYB0Kr$[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-88-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>

Richard Clayton wrote:

> this is rapidly going entirely off-topic

As indicated by the Subject, but it's actually funny.

> I am assured that  <m@im> (that's the 'Isle of Man'
> in the Irish Sea) is a working email address

It fails with the "at least one dot" rule in RfC 2821,
2821bis will try to fix this.  At the moment it's an
SMTP syntax error, "working" or not.

> I don't believe that this was an intentional change
> from earlier....

John confirmed that the "one dot" rule was intended.
Catch host names assuming some kind of default domain.

The 2821bis syntax will allow a trailing dot for this
case and FQDN = TLD.

> the last thing we need is a rule that says you can
> use UUCP name unless it matches a country code...

<g>  Indeed.  As far as I'm concerned we could "upgrade"
this stuff to state-of-the-art 1994 and s-o-1036, pseudo-
domain UUCP or die, "demon", die.  Dito one or more "wolf",
"cafe", "dead", "beef", and similar stoneage monsters.

We're declaring 100% of all user agents as "obsolete" -
assuming that not one UA gets 2231 right - so why are we
so shy with this "traditional name" crap ?

Let's say "MUST FQDN" and be done with it.  Those who
don't use a FQDN are non-conforming, ready.  And maybe
allow UUCP as pseudo-domain.  I promise I'll scream if
somebody mentions BITNET.  This is the 3rd millennium.

                  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 j79J5tOQ072552; Tue, 9 Aug 2005 12:05:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79J5tRI072551; Tue, 9 Aug 2005 12:05: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 j79J5sPc072538 for <[e-mail]>; Tue, 9 Aug 2005 12:05:54 -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 j79J5ZFD028546 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 9 Aug 2005 12:05:35 -0700 (PDT)
Date: Tue, 9 Aug 2005 12:05:49 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses - conclusion
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>If Frank, Charles and Richard can live with a group consensus that the 
>USEFOR document is to go forward without any requirement to support these 
>email addresses, I can declare this issue closed

And why do these three specific people get to veto a group consensus?

>- and possibly reopen the issue when it's time to update USEAGE.

Your poll was neither USEFOR nor USEPRO specific, and thus it applies to 
USEAGE as well. If the group consensus today is "no requirement", then
it is ridiculous to come back in a month and debate the whole issue again.

>Seems reasonable?

Closing it, yes. Giving three people veto power, no. Reopening it in a few 
weeks, no.

Regarding your counts:

>Conclusion: 2 people support some form of mandate in USEPRO.

Under question one, I see just one person voting for a mandate, and that
same person also voted for a non-mandate. Where did you get 2? 

>Counting as above, 3 people support some form of mandate.

I count two, and both of those, again, also voted for a non-mandate.

Is this some kind of "new math" that I was lucky enough to have missed out 
on?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79ItH6U071663; Tue, 9 Aug 2005 11:55:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79ItHZb071662; Tue, 9 Aug 2005 11:55: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 j79ItGsT071643 for <[e-mail]>; Tue, 9 Aug 2005 11:55:16 -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 j79IsvFD024773 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 9 Aug 2005 11:54:57 -0700 (PDT)
Date: Tue, 9 Aug 2005 11:55:11 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Shame vs Engineering, also NEW conformance criteria
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.032 () HOT_NASTY
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>:

>So in the case I gave (wapping.cs.man.ac.uk), that would result in sending
>your complaint to:

>   To: abuse@xxxxxxxxxxxx,abuse@xxxxxxxxx,abuse@xxxxx

I see you are incapable of following a simple algorithm for creating
email addresses.

Even though I cannot determine what the 'xxxxxx' stand for in each case,
it is trivial to determine that correct use of the algorithm would result
in four abuse@ addresses, not three.

>That is the machine-gun approach (you can be pretty sure that at least one
>will hit the target).

So what if it is the machine-gun approach? You get to the "top level 
domain", don't you? You don't need a mandate in USEFOR to get there, do 
you? Problem solved. Most people would be happy with a solution. I sense 
that you are not.

>Indeed, cs.man.ac.uk will reach the proper place.

Good. Was that one of the addresses in your list? If so, problem solved.
Be happy. If it wasn't, then you didn't understand the algorithm and ought
not be commenting on it.

>man.ac.uk will in fact reach someone with no responsibility for the server
>is question,

Really? That's funny. Since cs is delegated namespace, it would seem that 
man.ac.uk still has a vested interest in the operations of the cs 
department systems. That's how it works here where I work. In fact, the 
next level up from my systems is very strict, and the next level up from 
him is even louder and more obnoxious about solving problems.

>And the man at ac.uk
>would be mightily pissed off if everybody followed your algorithm and he
>found himself being copied on every complaint ever made about any student
>in the UK.

Sucks to be him. But if 'man' decides to abdicate its responsibility, then
it's up to 'ac' to cut the ties.

>And your algorithm still does not implement what RFC 2142 calls for, which
>is the "top level domain".

You've just demonstrated a complete lack of understanding of RFC2142 and
what my algorithm does. My algorithm does not "implement" anything from
RFC2142, and it was never intended to "implement" anything from RFC2142.
It is up to the domain owner to "implement" the abuse reporting address
for the top level domain, not my algorithm. All it does is guarantee that
you get your email to the top level domain abuse reporting address, and it
does that.

>Which of those is the top-level domain and why,

If you use my algorithm, you don't need to know. One of them is guaranteed 
to be correct.

>when you are supposed to be sending to the TLD only,

Where did you get the impression that an abuse report must be sent to only
the top level domain abuse reporting address? Where in RFC2142 is the USER
restricted from sending an abuse report any damn place he wants to? Do you 
have any clue what RFC2142 says?

> are you sending to three addresses?

Four. 

wapping.cs.man.ac.uk, cs.man.ac.uk, man.ac.uk, ac.uk.

But you'd have to have actually read and understood the algorithm to know
the right result.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79InAa3071224; Tue, 9 Aug 2005 11:49:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79InAex071223; Tue, 9 Aug 2005 11:49:10 -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 j79In93K071217 for <[e-mail]>; Tue, 9 Aug 2005 11:49:09 -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 1E2Z9w-0008im-Ar; Tue, 09 Aug 2005 18:49:08 +0000
Message-ID: <[e-mail]>
Date: Tue, 9 Aug 2005 19:47:35 +0100
To: [e-mail]
Cc: John Stanley <[e-mail]>
From: Richard Clayton <[e-mail]>
Subject: Re: Shame vs Engineering
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <Pu1$+vcD77fJiMKLZWf+du0HJ4>
Sender: [e-mail]
Precedence: 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]>, John
Stanley <[e-mail]> writes
>
>
>Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:
>
>>it generates a lot of junk mail to abuse@xxxxx, but I suppose you've 
>>already understood and accepted that....
>
>Step 3, if the address contains just one dot, send the mail.

you ought to consider reading the original emails (hence I've cc'd this
to you as well)   Harald wrote  <[e-mail]>  which is a nonsense
address (unlike <[e-mail]> which is not)

> No,
>abuse@xxxxx isn't a possible destination based on that algorithm. And
>since you start with an FQDN, you will always start with at least one dot.

you may also have missed my earlier example of <m@im>

- -- 
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/AwUBQvj6R5oAxkTY1oPiEQKB4ACfZqcsM5mYrqpzTS571hu6JIvcsucAn1ve
tesWiLCrb6HVeWsl1+pcKnEO
=PUTN
-----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 j79IcvQk070198; Tue, 9 Aug 2005 11:38:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79IcvpA070197; Tue, 9 Aug 2005 11:38:57 -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 j79IcuwV070186 for <[e-mail]>; Tue, 9 Aug 2005 11:38:56 -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 j79IcbFD018267 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 9 Aug 2005 11:38:37 -0700 (PDT)
Date: Tue, 9 Aug 2005 11:38:51 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses: Poll results, so far
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>:

>No, 1B and 1D and NOT "what RFC2142 says", neither is 2B

Please read RFC2142 before you try telling us what it says, Charles.

Specifically for abuse@, 2B says:

 2B) All identities SHOULD support

RFC2142 says:

   Note, however, that it is valid and encouraged
   to support mailbox names for sub-domains, as appropriate.

Close enough. Much closer than your "MUST" for the FQDN.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79IY3Hg069774; Tue, 9 Aug 2005 11:34:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79IY3oY069773; Tue, 9 Aug 2005 11:34:03 -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 j79IY2Z2069765 for <[e-mail]>; Tue, 9 Aug 2005 11:34:02 -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 j79IXbFD016182 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 9 Aug 2005 11:33:42 -0700 (PDT)
Date: Tue, 9 Aug 2005 11:33:50 -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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>it generates a lot of junk mail to abuse@xxxxx, but I suppose you've 
>already understood and accepted that....

Step 3, if the address contains just one dot, send the mail. No,
abuse@xxxxx isn't a possible destination based on that algorithm. And
since you start with an FQDN, you will always start with at least one dot.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79EOrh6047174; Tue, 9 Aug 2005 07:24:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79EOrww047172; Tue, 9 Aug 2005 07:24:53 -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 j79EOqpv047155 for <[e-mail]>; Tue, 9 Aug 2005 07:24:53 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF2B63200F0 for <[e-mail]>; Tue,  9 Aug 2005 16:24: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 24372-02 for <[e-mail]>; Tue,  9 Aug 2005 16:24:43 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FA2C3200D0 for <[e-mail]>; Tue,  9 Aug 2005 16:24:43 +0200 (CEST)
Date: Tue, 09 Aug 2005 15:37:00 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1093 Email addresses - conclusion
Message-ID: <BF9529995E07CE370AB932FE@B50854F0A9192E8EC6CDA126>
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: by 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>

Drawing a conclusion from the poll results:

A number of people have argued strongly about the issue.
The main arugments made seem to be on the lines of (paraphrase):

- RFC 2142 already says much of the same thing, so we don't need to say 
anything
- RFC 2142 is a failed standard, so we need to say it
- Our requirements are different from RFC 2142, so we need to say what our 
requirements are
- Abuse addresses aren't needed for interoperability, so shouldn't be in 
the protocol specification
- People need to see the requirement in the specification to know about 
appropriate behaviour
- People will do what they will do, so putting "nice to have" requirements 
into the standard is "false advertising"

I believe that everyone has heard these arguments. It seems unlikely that 
many of the participants will change their minds.

As WG chair, I conclude that it's possible that the working group can come 
to consensus on excluding these requirements from the USEFOR standard 
document. (I don't see any strong arguments against putting in a NOTE 
saying that these practices exist, however - that's not normative).

If Frank, Charles and Richard can live with a group consensus that the 
USEFOR document is to go forward without any requirement to support these 
email addresses, I can declare this issue closed - and possibly reopen the 
issue when it's time to update USEAGE.

Seems reasonable?

                        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 j79EOrsq047175; Tue, 9 Aug 2005 07:24:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79EOraD047173; Tue, 9 Aug 2005 07:24:53 -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 j79EOp9W047149 for <[e-mail]>; Tue, 9 Aug 2005 07:24:52 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0D893200ED for <[e-mail]>; Tue,  9 Aug 2005 16:24:47 +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 24377-01 for <[e-mail]>; Tue,  9 Aug 2005 16:24:41 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 605043200D4 for <[e-mail]>; Tue,  9 Aug 2005 16:24:40 +0200 (CEST)
Date: Tue, 09 Aug 2005 15:26:20 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1093 Email addresses: Poll results, sort of final
Message-ID: <F4EF9C6F7616DE12FA5F39C5@B50854F0A9192E8EC6CDA126>
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: by 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 think enough time has passed....

1) news@ and usenet@ for all path-identities in the Path: or
  Injection-info: headers
  Alternatives, plese pick one:

  1A) All identities that look like domain-names MUST support
  1B) All identities that look like domain-names SHOULD support
	Frank Ellermann
  1C) Some identities MUST support
      ("at least one of the <path-identity>s inserted by
      themselves" is one example of "some")
	Charles Lindsey (preferred)
  1D) Some identities SHOULD support
	Richard Clayton (second)
	Charles Lindsey (second)
  1E) No requirement
	Richard Clayton (preferred)
	Russ Allbery
	Bruce Lilly
	Forrest J. Cavalier (wants 2)
	Ralph Babel
	Dan Schlitt
	Eivind Tagseth
  1F) None of the above
	Forrest J. Cavalier (wants 2)
	John Stanley

Conclusion: 2 people support some form of mandate in USEPRO.
6 people support not making any mandate in USEPRO (one of which has said 
that he thinks it's a good idea for USEAGE), and one person would prefer no 
mandate, but could live with a SHOULD mandate.

2) abuse@ for injecting agents as identified in Path:, for the
   case where Injection-info doesn't contain "mail-complaints-to"
   Alternatives, please pick one:

  2A) All identities MUST support abuse@identity
	Charles Lindsey (one alternative of 2)
  2B) All identities SHOULD support
	Richard Clayton (preferred)
	Frank Ellermann (wants 2)
	Charles Lindsey (one alternative of 2)
  2C) No requirement
	Russ Allbery
	Bruce Lilly
	Forrest J. Cavalier (wants 2)
	Ralph Babel
	Dan Schlitt
	Eivind Takseth
  2D) Top level domain corresponding to identity MUST support
	Frank Ellermann (wants 2)
  2E) Top level domain corresponding to identity SHOULD support
	Richard Clayton (could live with)
  2F) None of the above
	Forrest J. Cavalier (wants 2)
	John Stanley

Counting as above, 3 people support some form of mandate.
6 people do not support any form of 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 j79DW1Ka031121; Tue, 9 Aug 2005 06:32:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79DW1U0031120; Tue, 9 Aug 2005 06:32:01 -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 j79DVxDm031103 for <[e-mail]>; Tue, 9 Aug 2005 06:32:00 -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 1E2UCx-00093x-BN for [e-mail]; Tue, 09 Aug 2005 13:31:57 +0000
Message-ID: <uevYB0Kr$[e-mail]>
Date: Tue, 9 Aug 2005 14:30:19 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: Shame vs Engineering, also NEW conformance criteria
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <rQ$$+X3n77$$INKLyyR+d+OsCs>
Sender: [e-mail]
Precedence: 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

>And your algorithm still does not implement what RFC 2142 calls for, which
>is the "top level domain". Which of those is the top-level domain and why,
>when you are supposed to be sending to the TLD only, are you sending to
>three addresses?

this is rapidly going entirely off-topic, especially since the chair may
decide the consensus is to drop all this stuff...

however I am assured that  <m@im> (that's the 'Isle of Man' in the Irish
Sea) is a working email address, and that a number of other TLDs have MX
records, and working addresses to go with them !

that said, I can imagine a lot of software would not accept it (either
through the application of heuristics or the ABNF syntax in RFC2821
which apparently requires two components -- though I don't believe that
this was an intentional change from earlier....)

it should be noted, I suppose, that parsing  ...!demon!... will yield an
unsendable-to  abuse@demon  (though your system may apply some
heuristics and turn that into [e-mail] (if you live
inside example.com)) ...  but the last thing we need is a rule that says
you can use UUCP name unless it matches a country code...

... this area isn't broken and works passably well IME. Why aren't we
leaving well alone, documenting what is done and not bothering to
transcribe other RFCs?

- -- 
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/AwUBQviv65oAxkTY1oPiEQJDgACg3VBiA0/Ppa3BLmLJHa7NcAbZr2QAn0Ec
p9M+H9qdecbYcK/AT0gHZbLM
=rJLR
-----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 j79CiUjT012400; Tue, 9 Aug 2005 05:44:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79CiUUn012399; Tue, 9 Aug 2005 05:44:30 -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 j79CiTIR012388 for <[e-mail]>; Tue, 9 Aug 2005 05:44:30 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-212-178-pppoe.dsl.hrbg.epix.net [216.37.212.178]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j79CiLgt009033 for <[e-mail]>; Tue, 9 Aug 2005 08:44:26 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 09 Aug 2005 08:44:26 -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 (Hello, Chair?)
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.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:

> I see no conflict whatsoever. Implementors can provide lots of email
> addresses and web forms as well for all I care. So saying that they
> MUST/SHOULD/whatever include one particular address is not "imposing a
> particular method".

You are saying that RFC2119 sentence

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

actually means

     For example, they must not be used to try to
     limit implementors to one particular method
     where the method is not required for interoperability.

That makes the RFC2119 sentence meaningless, so that interpretation
of RFC2119 is wrong.

I think WG participants mis-interpreting RFC2119 is a matter for
the Chair.  Either RFC2119 means what you say, or I am correct.
It can't be both.

Chair?




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79BEGeo080198; Tue, 9 Aug 2005 04:14:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79BEGQC080197; Tue, 9 Aug 2005 04: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 j79BEFfE080179 for <[e-mail]>; Tue, 9 Aug 2005 04:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-14.midband.mdip.bt.net ([81.144.70.14]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f89006.14cba.de for [e-mail]; Tue,  9 Aug 2005 12:14:14 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j79BCCA08413 for [e-mail]; Tue, 9 Aug 2005 12:12:12 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22234
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]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 9 Aug 2005 10:35:18 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]> "Forrest J. Cavalier III" <[e-mail]> writes:


>RFC2119:

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

>You said
>     All it has ever said is that administrators MUST provide that
>     address, so that everybody has at least one known way to contact them.

>...which is in plain conflict with the RFC2119 statement.

I see no conflict whatsoever. Implementors can provide lots of email
addresses and web forms as well for all I care. So saying that they
MUST/SHOULD/whatever include one particular address is not "imposing a
particular method".

>How do you maintain they are not in conflict?

>Is it because you mis-read that RFC2119 statement as a requirement to
>disallow implementors imposing a particular method (of complaints) on
>everybody?  (E.g. by saying "We only take web-form complaints, and
>don't run SMTP here.")

There are too many negations in your sentence for me to be able to
decipher any meaning in it.

But I see that RFC 2821 uses "MUST" in connection with the "postmaster@"
address. That certainly rules out "We only take web-form complaints", but
it does not outlaw web-form complaints as an additional mode of contact,
so it has not "imposed" any particular method. Moreover, there is no
interoperability issue attached to the provision of "postmaster@", though
there is certainly a potential for harm if it is absent.

So if you are claiming that the things I have suggested writing in our
draft are contrary to RFC 2119, then please exaplain how those words in
RFC 2821 are not contrary to RFC 2119.

-- 
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 j79BEFss080188; Tue, 9 Aug 2005 04:14:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79BEFLL080187; Tue, 9 Aug 2005 04:14:15 -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 j79BEENH080165 for <[e-mail]>; Tue, 9 Aug 2005 04:14:14 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-14.midband.mdip.bt.net ([81.144.70.14]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f89005.14cba.dd for [e-mail]; Tue,  9 Aug 2005 12:14:13 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j79BCEk08427 for [e-mail]; Tue, 9 Aug 2005 12:12:14 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22236
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Shame vs Engineering, also NEW conformance criteria
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 9 Aug 2005 10:55:40 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]> John Stanley <[e-mail]> writes:

>Since "top level domain" is so hard to grasp, here's a simple algorithm 
>you can use: 

>	1. A = FQDN of the host you want to complain about
>	2. Append "abuse@A" to the To: line of your mail agent
>	3. If A contains just one dot, send the mail, exit.
>	4. Remove from A the leftmost dotted component. E.g.
>	   a.news.example.com would become news.example.com.
>	5. Append a comma to the To: line of your mail agent.
>	6. Goto step 2.

So in the case I gave (wapping.cs.man.ac.uk), that would result in sending
your complaint to:

   To: [e-mail],[e-mail],[e-mail]

That is the machine-gun approach (you can be pretty sure that at least one
will hit the target). Indeed, cs.man.ac.uk will reach the proper place.
man.ac.uk will in fact reach someone with no responsibility for the server
is question, but who might prod the person who was. And the man at ac.uk
would be mightily pissed off if everybody followed your algorithm and he
found himself being copied on every complaint ever made about any student
in the UK.

And your algorithm still does not implement what RFC 2142 calls for, which
is the "top level domain". Which of those is the top-level domain and why,
when you are supposed to be sending to the TLD only, are you sending to
three addresses?

-- 
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 j79BEEGl080175; Tue, 9 Aug 2005 04:14:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79BEEVp080174; Tue, 9 Aug 2005 04:14:14 -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 j79BEDWk080160 for <[e-mail]>; Tue, 9 Aug 2005 04:14:13 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-14.midband.mdip.bt.net ([81.144.70.14]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f89004.14cba.dc for [e-mail]; Tue,  9 Aug 2005 12:14:12 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j79BCDY08423 for [e-mail]; Tue, 9 Aug 2005 12:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22235
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1093 Email addresses: Poll results, so far
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 9 Aug 2005 10:42:54 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]> John Stanley <[e-mail]> writes:

>Looking at 1 in terms of RFC2142, then, we see that 1B, 1D, and 1E are all
>"what RFC2142 says",..........

No, 1B and 1D and NOT "what RFC2142 says", neither is 2B

-- 
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 j79A3qAL055049; Tue, 9 Aug 2005 03:03:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79A3qbn055047; Tue, 9 Aug 2005 03:03: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 j79A3n76055018 for <[e-mail]>; Tue, 9 Aug 2005 03:03:50 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE9F23200D1; Tue,  9 Aug 2005 12:03:45 +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 18252-05; Tue,  9 Aug 2005 12:03: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 B87AA3200D0; Tue,  9 Aug 2005 12:03:42 +0200 (CEST)
Date: Tue, 09 Aug 2005 12:03:43 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: Re: Shame vs Engineering, also NEW conformance criteria
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: by 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 mandag, august 08, 2005 11:19:25 -0700 John Stanley <[e-mail]> 
wrote:

> Since "top level domain" is so hard to grasp, here's a simple algorithm
> you can use:
>
> 	1. A = FQDN of the host you want to complain about
> 	2. Append "abuse@A" to the To: line of your mail agent
> 	3. If A contains just one dot, send the mail, exit.
> 	4. Remove from A the leftmost dotted component. E.g.
> 	   a.news.example.com would become news.example.com.
> 	5. Append a comma to the To: line of your mail agent.
> 	6. Goto step 2.
>
> I assume, of course, you are able to understand that "abuse@A" means
> to replace "A" with the contents of the variable A. And I also assume
> that you understand the difference between an example ("E.g.") and
> "In other words" ("I.e."), so you know that this algorithm isn't limited
> to addresses in the example.com domain.
>
> Now, explain why this algorithm is not sufficient to find the already
> mandatory abuse reporting address for any FQDN.

it generates a lot of junk mail to [e-mail], but I suppose you've 
already understood and accepted 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 j799xkSY053178; Tue, 9 Aug 2005 02:59:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j799xka6053177; Tue, 9 Aug 2005 02:59: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 j799xjEV053163 for <[e-mail]>; Tue, 9 Aug 2005 02:59:45 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC6153200D1; Tue,  9 Aug 2005 11:59: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 18226-03; Tue,  9 Aug 2005 11:59: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 5AEEF3200D0; Tue,  9 Aug 2005 11:59:36 +0200 (CEST)
Date: Tue, 09 Aug 2005 11:59:39 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: John Stanley <[e-mail]>, [e-mail]
Subject: RE: #1093 Email addresses: Poll results, so far
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: by 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 mandag, august 08, 2005 12:03:19 -0700 John Stanley <[e-mail]> 
wrote:

> I'm assuming, of course, that when you write "no requirement" you actually
> mean "we don't say anything", not that we say "there is no requirement
> ...". If we don't say anything, then we are saying implicitely that
> RFC2142 is still valid. (Not that we could actually invalidate it.)

Yes, I meant "no requirement in the USEFOR 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 j78J3UaN085153; Mon, 8 Aug 2005 12:03:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78J3UYO085152; Mon, 8 Aug 2005 12:03:30 -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 j78J3Tga085132 for <[e-mail]>; Mon, 8 Aug 2005 12:03:29 -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 j78J36FD081286 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 8 Aug 2005 12:03:10 -0700 (PDT)
Date: Mon, 8 Aug 2005 12:03:19 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: RE: #1093 Email addresses: Poll results, so far
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>So far, I'd have to call this "no consensus", 

Far from it. I'd say it's rather clear.

I'm assuming, of course, that when you write "no requirement" you actually
mean "we don't say anything", not that we say "there is no requirement 
...". If we don't say anything, then we are saying implicitely that 
RFC2142 is still valid. (Not that we could actually invalidate it.)

Looking at 1 in terms of RFC2142, then, we see that 1B, 1D, and 1E are all
"what RFC2142 says", and 1A and 1C are "not what RFC2142 says". That 
division results in an 8 to 1 result (counting twice the same voters you 
let vote twice) for "what RFC2142 says". And the one vote "not RFC2142" 
also voted for an option that is RFC2142. Sounds like its almost 
unanimous.

I don't speak for Forrest, but my 1F vote can live with that result.

Doing the same for 2 gives 2B, 2C, and 2D as "what RFC2142 says" and 2A 
and 2E as "not RFC2142." Grouped that way results in 8 to 2 for "what 
RFC2142 says." Again, I counted twice the same people you allowed to vote 
twice. Both of the two who voted "not RFC2142" also voted for an option 
that IS RFC2142, so it appears that "RFC2142" is acceptable to them. 

If you examine the text of my vote for item 2, you'll notice that it says,
essentially, "what RFC2142 says", and was cast as 2F instead of 2C only 
because of the abiguity in the meaning of "no requirement". So, that makes 
it 9 to 2, with the 2 being explicit in saying they can accept the 
opposite result. 

That's NOT a consensus for "what RFC2142 says", in BOTH cases?

So, the only thing left to debate is whether we just say nothing at all or 
try to rewrite RFC2142 into our draft. Since RFC2142 already says it, and 
there appears to be a groundswell of support for updating RFC2142 just 
within this group, we ought to say nothing. If we write it in, and then 
2142 is updated to say something different, who follows which?

As for the idea of slipping some new mandates into USAGE, I don't see 
where this poll was USEFOR or USEPRO specific, so a consensus here is a 
consensus 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 j78ISoQ5081146; Mon, 8 Aug 2005 11:28:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78ISoPi081145; Mon, 8 Aug 2005 11:28:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from soy.epix.net (soy.epix.net [199.224.64.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78ISnfM081138 for <[e-mail]>; Mon, 8 Aug 2005 11:28:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-228-137-pppoe.dsl.hrbg.epix.net [216.37.228.137]) by soy.epix.net (8.12.10/2004120601/PL) with ESMTP id j78ISegE001830 for <[e-mail]>; Mon, 8 Aug 2005 14:28:48 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 14:28: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: New USEPRO path-identity text (Hello, Chair?)
References: <[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
Sender: [e-mail]
Precedence: 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 <[e-mail]> "Forrest J. Cavalier III" <[e-mail]> writes:
> 
> 
>>>Hold on! Nobody has said you MUST send your complaint (whatever) by email
>>>to that specified address. All it has ever said is that administrators
>>>MUST provide that address, so that everybody has at least one known way to
>>>contact them.
> 
> 
>>Are you seriously making this argument?  Do you really understand RFC2119
>>"implementors" to include "everybody"?
> 
> 
> Eh? I understand "everybody" to include "implementors", and I expect
> "everybody" to be able to find whatever usenet/news/abuse addresses we
> finally agree to mention.
> 


RFC2119:

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

You said
     All it has ever said is that administrators MUST provide that
     address, so that everybody has at least one known way to contact them.

...which is in plain conflict with the RFC2119 statement.

How do you maintain they are not in conflict?

Is it because you mis-read that RFC2119 statement as a requirement to
disallow implementors imposing a particular method (of complaints) on
everybody?  (E.g. by saying "We only take web-form complaints, and
don't run SMTP here.")



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78IJZOr079968; Mon, 8 Aug 2005 11:19:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78IJZmD079967; Mon, 8 Aug 2005 11:19:35 -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 j78IJYLv079944 for <[e-mail]>; Mon, 8 Aug 2005 11:19:34 -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 j78IJBtW015953 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 8 Aug 2005 11:19:11 -0700 (PDT)
Date: Mon, 8 Aug 2005 11:19:25 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Shame vs Engineering, also NEW conformance criteria
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>

I:

>considered a part of the private nets) like 10.*, 192.168.*, etc. He's 
>just refused to refer to the addresses as "routable".

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

> Not at all. I had something in about routing tables at one stage,

"Routing tables" is not the same concept as "routable" and "non-routable."

10.* and 192.168.* are non-routable because they are defined that way,
because they are assigned as "open addresses" that anyone can use. That 
does NOT mean that they will not appear in someone's routing table, simply 
because a large organization that is using the 10.* netblock may very well
have routers within their network that will certainly contain 10.* 
addresses in the routing tables. 

But 10.* addresses are not supposed to be routed outside the organization 
that is using them, which is why they are called non-routable. When they 
hit the "wide open Internet", they aren't supposed to be routed.

The opposition to the phrase "routing tables" was specific to that concept
and not to "routable" in general. Don't pretend you did say "routable"
just because you used the phrase "routing tables".

>While I was about it, I changed "working email address" to "deliverable
>email address". If you think that too is broken, then you must also agree
>that RFC 2142 is broken (which it is, but not for that reason).

Charles, I will not jump through your hoop nor agree with you on things 
that I do not agree. Please stop putting words in my mouth.

You cannot logically say anything more than "syntactically correct" and 
have an adequate reflection of reality. There are too many sites that 
filter using RBL et. al. to ever pretend that any email address you 
mandate is going to be deliverable, and adding in the automated abuse 
responders that deliver the email to nothing more than the bit bucket 
after saying "Thanks for the gumball, Popeye" makes it even sillier to 
pretend. 

And weren't you the fellow who so sweetly referred to my proposed
expansion of the definition of followup as "smoke and mirrors" and "trying
to change reality"? And now you pretend you can order sites to do things
they already refuse to do based on existing standards? What, one rule is
ignored so you think everyone will jump up and obey the new one just
because Charles said so?

>If, as you are so keen to point out, RFC 2142 is to be regarded as a
>standard, and if it states that certain addresses derived from the Path
?"must" be deliverable, then it would seem that RFC 2142 has redefined the
>meaning of the Path header.

We are not the RFC2142 working group, it is not our task to rewrite 
RFC2142. Just as RFC2142 may have overstepped its limits by trying to add 
a purpose to the path header, we would overstep our limits by redefining
an address defined in RFC2142.

>My view, however, is that RFC 2142 is such a shambles ...

Yes, we know. You don't know what a top level domain is. You want us to 
rewrite RFC2142 under the guise of a news standard to help all those poor 
ignorant people who cannot figure out how to complain about something.

If you want a new RFC2142 I suggest you join the RFC2142 working group, or 
get it created so you can work your magic in the correct place. This is 
USEFOR. We deal with news.

>that we would be
>better deciding for ourselves exactly what we want regarding those
>various addresses,

When what you want is a direct contradiction to an existing standard, no.

>Eh? I understand "everybody" to include "implementors", and I expect
>"everybody" to be able to find whatever usenet/news/abuse addresses we
>finally agree to mention.

And I expect "everybody" to be able to find whatever addresses RFC2142
specifies, because it really isn't that hard and even in the remote chance
there is a failure, there is no harm to the news system.

Since "top level domain" is so hard to grasp, here's a simple algorithm 
you can use: 

	1. A = FQDN of the host you want to complain about
	2. Append "abuse@A" to the To: line of your mail agent
	3. If A contains just one dot, send the mail, exit.
	4. Remove from A the leftmost dotted component. E.g.
	   a.news.example.com would become news.example.com.
	5. Append a comma to the To: line of your mail agent.
	6. Goto step 2.

I assume, of course, you are able to understand that "abuse@A" means
to replace "A" with the contents of the variable A. And I also assume
that you understand the difference between an example ("E.g.") and
"In other words" ("I.e."), so you know that this algorithm isn't limited 
to addresses in the example.com domain.

Now, explain why this algorithm is not sufficient to find the already 
mandatory abuse reporting address for any FQDN.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78Gp5Fk072523; Mon, 8 Aug 2005 09:51:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Gp5bE072522; Mon, 8 Aug 2005 09:51:05 -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 j78Gp4n3072509 for <[e-mail]>; Mon, 8 Aug 2005 09:51:04 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-76.midband.mdip.bt.net ([81.144.72.76]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f78d76.4494.7c for [e-mail]; Mon,  8 Aug 2005 17:51:02 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j78GmaK27315; Mon, 8 Aug 2005 17:48:36 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22228
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Shame vs Engineering
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 8 Aug 2005 14:01:00 GMT
Lines: 69
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]> "Forrest J. Cavalier III" <[e-mail]> writes:

>To get an example I went to news.software.nntp and THE VERY FIRST ARTICLE
>I CHOSE had this:

>cox.net!news-xfer.cox.net!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!news.glorb.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail

>1. cox.net is not a FQDN.  Is there a good reason to prohibit this entry?

Yes it is. It even has an MX record. If I saw that Path and wanted to
communicate with the admin of that server, I would try "[e-mail]"
rather than "[e-mail]".


>2. nntp.frontiernet.net
>    No DNS entries.

There is an MX record for frontiernet.net. And a name server at
auth01.roc.ny.frontiernet.net. But nothing else. Not impressive. 

>3. postnews.google.com
>    No DNS entries.

Well, did you expect any? :-)

>This article had a Complaints-To, and an X-Complaints-To header fields.

>How many people would have difficulty finding contact information
>for any of those path entries?  Compare that to the hassle of cox.net
>telling all its up and downstream peers all of its routing server
>names, or google.com maintaining DNS records for all of the internal
>machines behind its firewall.

Presumably the reason cox.net put that shortened version in the Path was to
save it the trouble of informing its peers each time it brought a new
server on stream. That is the sort of thing we need to explicitly allow
next time we update the text telling how to construct Paths.

>Since NEWS is not USENET, does anyone see a problem with someone
>running a private server on 192.168.x.x (or other globally non-unique
>IP addresses), and sticking those IP addresses in the path?  If articles
>with those paths leak out to Usenet, what do I care if they don't
>propagate?

A cooperating subnet can always agree to break the rules. But if it is
possible for a news transmission path to enter some intranet with a
firewall and leave the same intranet at another point to progagate onwards
through Usenet, then the admins had better be careful what
<path-inentity>s they insert as it passes through their internal machines.

>I agree with John that we don't need explanatory notes about
>adminstrators bearing consequences for violating a MUST.  There
>is no end to obvious things we can emphasize using extra NOTEs.

Sure. All I want is to point out the slight theoretical risk of using
names not in the DNS. I am open to suggestions how to express this. But,
so long as Bruce is protesting that we have not closed that miniscule
loophole, then I think we need to say _something_.

-- 
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 j78Gp42U072510; Mon, 8 Aug 2005 09:51:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Gp4bB072507; Mon, 8 Aug 2005 09:51: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 j78Gp2Xa072490 for <[e-mail]>; Mon, 8 Aug 2005 09:51:03 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-76.midband.mdip.bt.net ([81.144.72.76]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f78d76.4494.7b for [e-mail]; Mon,  8 Aug 2005 17:51:02 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j78GmP427309; Mon, 8 Aug 2005 17:48:25 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22227
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Shame vs Engineering, also NEW conformance criteria
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 8 Aug 2005 13:25:12 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]> John Stanley <[e-mail]> writes:

>See above. 10.x.x.x is not a routable IP address and does not fall into 
>the category of valid as we have attempted to define it. While Charles 
>still has something about "public", he's already made it clear that his 
>intent was to exclude the private netblocks (and multicast, if that isn't 
>considered a part of the private nets) like 10.*, 192.168.*, etc. He's 
>just refused to refer to the addresses as "routable".

Not at all. I had something in about routing tables at one stage, and I
was told (Bruce, I think) that would not do, and was told to go look at
RFC 1918. So I did that and came up with "public".

My text now says:

   2.   An encoding of the public [RFC 1918], permanently routable IP
        address - <IPv4address> or <IPv6address> [RFC 3986] - of that
        news-server. ........

Somebody will tell me that is redundant next :-( .

While I was about it, I changed "working email address" to "deliverable
email address". If you think that too is broken, then you must also agree
that RFC 2142 is broken (which it is, but not for that reason).

-- 
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 j78Gp3lv072499; Mon, 8 Aug 2005 09:51:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Gp3BQ072498; Mon, 8 Aug 2005 09:51:03 -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 j78Gp10c072471 for <[e-mail]>; Mon, 8 Aug 2005 09:51:02 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-76.midband.mdip.bt.net ([81.144.72.76]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f78d75.4494.7a for [e-mail]; Mon,  8 Aug 2005 17:51:01 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j78GmDf27305; Mon, 8 Aug 2005 17:48:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22230
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: Mon, 8 Aug 2005 14:12:02 GMT
Lines: 33
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>:

>>And RFC 2142, when it says "if an NNTP server's host name is
>>DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its
>>"Path:" headewrs, then email must be deliverable to both <USENET@xxxxxxx>
>>and <USENET@xxxxxxxxxxxxxxxxxxx>..." is telling another lie :-) . 

>RFC2142 does not define the function of the path header, we do. And prior 
>to us, RFC1036 did. And RFC1036 does not say that the path header is a 
>list of contact addresses for server admins. It says that the path header 
>records the sites through which an article has passed.

If, as you are so keen to point out, RFC 2142 is to be regarded as a
standard, and if it states that certain addresses derived from the Path
"must" be deliverable, then it would seem that RFC 2142 has redefined the
meaning of the Path header.

My view, however, is that RFC 2142 is such a shambles that we would be
better deciding for ourselves exactly what we want regarding those
various addresses, and write that into our own standard accordingly.

-- 
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 j78Gp2kA072486; Mon, 8 Aug 2005 09:51:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Gp25W072484; Mon, 8 Aug 2005 09:51:02 -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 j78Gp0KT072467 for <[e-mail]>; Mon, 8 Aug 2005 09:51:01 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-76.midband.mdip.bt.net ([81.144.72.76]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f78d73.4494.78 for [e-mail]; Mon,  8 Aug 2005 17:50:59 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j78GlO027291; Mon, 8 Aug 2005 17:47:24 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22226
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1093 Email addresses: Poll results, so far
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 8 Aug 2005 13:14:47 GMT
Lines: 20
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]> Harald Tveit Alvestrand <[e-mail]> writes:

>So far, I'd have to call this "no consensus", with the most numerous 
>grouping arguing that we should not put in any requirement (for various 
>reasons). I was surprised to see that requiring news@ and usenet@ addresses 
>apparently has less support than requiring abuse@ addresses.

It is also noteworthy that some of the 1E/2C voters have indicated that
moving the whole issue to USEAGE would be a possible way forward.

-- 
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 j78Gp2cZ072485; Mon, 8 Aug 2005 09:51:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78Gp2Ug072483; Mon, 8 Aug 2005 09:51:02 -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 j78Gp1tg072469 for <[e-mail]>; Mon, 8 Aug 2005 09:51:01 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-72-76.midband.mdip.bt.net ([81.144.72.76]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f78d74.4494.79 for [e-mail]; Mon,  8 Aug 2005 17:51:00 +0100 (envelope-sender <[e-mail]>)
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j78Gm2b27301; Mon, 8 Aug 2005 17:48:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22229
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]> <[e-mail]>
Date: Mon, 8 Aug 2005 14:05:11 GMT
Lines: 24
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]> "Forrest J. Cavalier III" <[e-mail]> writes:

>> Hold on! Nobody has said you MUST send your complaint (whatever) by email
>> to that specified address. All it has ever said is that administrators
>> MUST provide that address, so that everybody has at least one known way to
>> contact them.

>Are you seriously making this argument?  Do you really understand RFC2119
>"implementors" to include "everybody"?

Eh? I understand "everybody" to include "implementors", and I expect
"everybody" to be able to find whatever usenet/news/abuse addresses we
finally agree to mention.

-- 
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 j76Jigsu044652; Sat, 6 Aug 2005 12:44:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j76JigC5044651; Sat, 6 Aug 2005 12:44:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kosat.consultit.no (kosat.consultit.no [80.203.206.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j76JifVb044636 for <[e-mail]>; Sat, 6 Aug 2005 12:44:42 -0700 (PDT) (envelope-from [e-mail])
Received: from tagseth-trd.consultit.no (182.80-202-209.nextgentel.com [80.202.209.182]) by kosat.consultit.no (Postfix) with SMTP id B111C8329 for <[e-mail]>; Sat,  6 Aug 2005 21:47:54 +0200 (CEST)
Received: by tagseth-trd.consultit.no (sSMTP sendmail emulation); Sat,  6 Aug 2005 21:37:17 +0200
Date: Sat, 6 Aug 2005 21:37:17 +0200
From: Eivind Tagseth <[e-mail]>
To: [e-mail]
Subject: Re: #1093 Email addresses: Poll
Message-ID: <[e-mail]>
Mail-Followup-To: Eivind Tagseth <[e-mail]>, [e-mail]
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
User-Agent: Mutt/1.5.8i
Sender: [e-mail]
Precedence: 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]> [2005-08-03 15:05:15 +0200]:

>  1E) No requirement

>  2C) No requirement



Eivind



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j76JPVgJ043580; Sat, 6 Aug 2005 12:25:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j76JPVHN043579; Sat, 6 Aug 2005 12:25:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from TheWorld.com (pcls3.std.com [192.74.137.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j76JPUTM043572 for <[e-mail]>; Sat, 6 Aug 2005 12:25:30 -0700 (PDT) (envelope-from [e-mail])
Received: from shell.TheWorld.com ([e-mail] [192.74.137.71]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id j76JK0vc022923; Sat, 6 Aug 2005 15:20:04 -0400
Received: from localhost (schlitt@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id PAA2350660; Sat, 6 Aug 2005 15:06:13 -0400 (EDT)
X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs
Date: Sat, 6 Aug 2005 15:06:12 -0400
From: Dan Schlitt <[e-mail]>
X-X-Sender: [e-mail]
To: Harald Tveit Alvestrand <[e-mail]>
cc: [e-mail]
Subject: Re: #1093 Email addresses: Poll
In-Reply-To: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
Message-ID: <[e-mail]>
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.86rc1/1004/Sat Aug  6 07:47:25 2005 on pcls3.std.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: 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, 3 Aug 2005, Harald Tveit Alvestrand wrote:

>
> I think the issue can be broken down into two different pieces:
>
> 1) news@ and usenet@ for all path-identities in the Path: or
>   Injection-info: headers
>   Alternatives, plese pick one:
>
>   1A) All identities that look like domain-names MUST support
>   1B) All identities that look like domain-names SHOULD support
>   1C) Some identities MUST support
>       ("at least one of the <path-identity>s inserted by
>       themselves" is one example of "some")
>   1D) Some identities SHOULD support
>   1E) No requirement
>   1F) None of the above

When I was managing a news server it would have been convenient to have
the generic e-mail addresses instead of having to keep track of who the
person was who managed news at the various sites that I exchanged news
with. But deducing e-mail addresses from the Path: seems to me to be
pretty unreliable. So I think that this is a topic that is more
appropriate for a best practices document. I guess that puts me in the
1E camp.

 >
> 2) abuse@ for injecting agents as identified in Path:, for the
>    case where Injection-info doesn't contain "mail-complaints-to"
>    Alternatives, please pick one:
>
>   2A) All identities MUST support abuse@identity
>   2B) All identities SHOULD support
>   2C) No requirement
>   2D) Top level domain corresponding to identity MUST support
>   2E) Top level domain corresponding to identity SHOULD support
>   2F) None of the above
>
> I read Charles' currently proposed text as 1D & 2B.

Promoting the availability of the abuse@ e-mail address may be a good
thing for the Internet community, but it is not something that should be
in a standards document for news. It might be appropriate in a news best
practices document. The discussion there should include examples of news
specific situations where it is useful. 2C

/dan



> Please send a message to the list saying which alternatives you support;
> once we know if there is a consensus in the working group on one pair of
> alternatives, we can go to wordsmithing.
>
>                      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 j76GQBVE031431; Sat, 6 Aug 2005 09:26:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j76GQBtY031430; Sat, 6 Aug 2005 09:26: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 j76GQAhX031424 for <[e-mail]>; Sat, 6 Aug 2005 09:26:10 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 354F83200A5 for <[e-mail]>; Sat,  6 Aug 2005 18:26:08 +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 21854-01 for <[e-mail]>; Sat,  6 Aug 2005 18:26:05 +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 E2A6D3200A0 for <[e-mail]>; Sat,  6 Aug 2005 18:26:03 +0200 (CEST)
Date: Sat, 06 Aug 2005 18:26:05 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1093 Email addresses: Poll results, so far
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: by 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>

1) news@ and usenet@ for all path-identities in the Path: or
  Injection-info: headers
  Alternatives, plese pick one:

  1A) All identities that look like domain-names MUST support
  1B) All identities that look like domain-names SHOULD support
	Frank Ellermann
  1C) Some identities MUST support
      ("at least one of the <path-identity>s inserted by
      themselves" is one example of "some")
	Charles Lindsey (preferred)
  1D) Some identities SHOULD support
	Richard Clayton (second)
	Charles Lindsey (second)
  1E) No requirement
	Richard Clayton (preferred)
	Russ Allbery
	Bruce Lilly
	Forrest J. Cavalier (wants 2)
	Ralph Babel
  1F) None of the above
	Forrest J. Cavalier (wants 2)
	John Stanley

2) abuse@ for injecting agents as identified in Path:, for the
   case where Injection-info doesn't contain "mail-complaints-to"
   Alternatives, please pick one:

  2A) All identities MUST support abuse@identity
	Charles Lindsey (one alternative of 2)
  2B) All identities SHOULD support
	Richard Clayton (preferred)
	Frank Ellermann (wants 2)
	Charles Lindsey (one alternative of 2)
  2C) No requirement
	Russ Allbery
	Bruce Lilly
	Forrest J. Cavalier (wants 2)
	Ralph Babel
  2D) Top level domain corresponding to identity MUST support
	Frank Ellermann (wants 2)
  2E) Top level domain corresponding to identity SHOULD support
	Richard Clayton (could live with)
  2F) None of the above
	Forrest J. Cavalier (wants 2)
	John Stanley

So far, I'd have to call this "no consensus", with the most numerous 
grouping arguing that we should not put in any requirement (for various 
reasons). I was surprised to see that requiring news@ and usenet@ addresses 
apparently has less support than requiring abuse@ addresses.

I'll give it a few more days before drawing conclusions.

                      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 j75K3Xkc069907 for <[e-mail]>; Fri, 5 Aug 2005 13:03:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75K3Xpc069906 for ietf-usefor-skb; Fri, 5 Aug 2005 13:03:33 -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 j75K3WUv069883 for <[e-mail]>; Fri, 5 Aug 2005 13:03:32 -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 j75K3AFD057010 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 5 Aug 2005 13:03:14 -0700 (PDT)
Date: Fri, 5 Aug 2005 13:03:22 -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>

Bruce Lilly <blilly@xxxxxxxxx>:

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

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

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

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

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

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

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

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

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

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

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

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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75Jjtg0068457 for <[e-mail]>; Fri, 5 Aug 2005 12:45:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75JjtNG068456 for ietf-usefor-skb; Fri, 5 Aug 2005 12:45:55 -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 j75Jjscq068447 for <[e-mail]>; Fri, 5 Aug 2005 12:45:54 -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 j75JjXtW007978 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 5 Aug 2005 12:45:34 -0700 (PDT)
Date: Fri, 5 Aug 2005 12:45:48 -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>:

>Such an administrator has not actually violated any MUST AFAICS. He has
>merely exercised bad judgement.

Then we have implicitely told him he can do what he did, and thus his only 
bad judgement was in listening to us. Don't threaten implementors and 
admins who listen to us with having to bear the consequences.

>It has been patiently explained to you many times and by many people that
>"SHOULD" does not equate to "optional".

Where did you see me use the word "equate"? I don't see it anywhere; are 
you putting words in my mouth again? 

"SHOULD" is not mandatory. The opposite of mandatory is optional. It is 
RECOMMENDED that you do something, but you don't have to. It is your 
option. Please find a dictionary and look up the words you don't 
understand.

>And RFC 2142, when it says "if an NNTP server's host name is
>DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its
>"Path:" headewrs, then email must be deliverable to both <USENET@xxxxxxx>
>and <USENET@xxxxxxxxxxxxxxxxxxx>..." is telling another lie :-) . 

RFC2142 does not define the function of the path header, we do. And prior 
to us, RFC1036 did. And RFC1036 does not say that the path header is a 
list of contact addresses for server admins. It says that the path header 
records the sites through which an article has passed.

>If the designated server for the abuse@ address uses that RBL blacklist,
>then indeed the administrator has not fulfilled his responsibilities under
>whatever MUST/SHOULD/... we write into our draft.

1. Knowing that it is an existing practice and documenting it otherwise is 
simply silly. We know that RBL lists are used; thus we ought to know that 
abuse@ addresses that are the sent email from sites on the RBL are likely 
not to work. Saying that someone MUST have a "working" abuse@ address is 
pretty meaningless, since we know that it can be considered to be 
"working" and still generate bounces.

2. No, if we say SHOULD, then an admin who uses RBL blocking on his abuse@ 
address certainly HAS fullfilled his responsibilities, because SHOULD is 
only a recommendation, and RFC2119 clearly says that he can do other than 
what we recommend.

>[The latest stupidity that has arisen is those abuse@ addresses whose
>virus filters reject emails sent to them containing copies of
>virus-containing emails that have emananated from those ISPs.]

I'm sorry, did I wind up in the wrong working group? I thought this was 
USEFOR, and that we dealt with NEWS and not email. When did it become our 
responsibility to discuss admins who bounce virus-containing emails?

><foo@xxxxxxxxxxx> is syntactically correct, 

No. No dot in domain name. Oh, yeah, the helpful archive again.

> but it is not a "working" email address.

Dunno. Can't tell what you wrote. Maybe it is, maybe it isn't. Doesn't 
matter. The best we can specify is that the address MUST be syntactically 
correct. We cannot mandate that it must "work" (for whatever definition of 
"work" you want to come up with) because we know ahead of time that there 
will be many places where it will not, and because it is OUTSIDE THE SCOPE 
OF OUR GROUP to redefine RFC2142.

>I note that RFC 2142 (as quoted above) uses "deliverable".
>Would that be better than "working" or "valid"?

Since we know that "deliverable" is just as unlikely as "working" or
"valid", no. You asked me what the correct term ought to be, I told you.
Syntactically correct.







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75GXG3v044085 for <[e-mail]>; Fri, 5 Aug 2005 09:33:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75GXGrn044084 for ietf-usefor-skb; Fri, 5 Aug 2005 09:33: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 j75GXFbE044078 for <[e-mail]>; Fri, 5 Aug 2005 09:33: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 0FEB029956; Fri,  5 Aug 2005 12:33: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 j75GXC7d017694(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, 5 Aug 2005 12:33:13 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j75GXCGb017693(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, 5 Aug 2005 12:33:12 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: Shame vs Engineering
Date: Fri, 5 Aug 2005 12:33:08 -0400
User-Agent: KMail/1.8.2
Cc: "Forrest J. Cavalier III" <[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 August 5 2005 10:25, Forrest J. Cavalier III wrote:
> 
> Bruce Lilly wrote:
>  > In practice, IP addresses are used in Path so
> > rarely, and FQDNs are so readily available, that it's really not worth
> > spending a lot of time worrying about this; the semantics and protocol
> > impose a uniqueness requirement. 
> 
> There is a difference between a unique path entry, an unique FQDN,
> and a unique FQDN that is in the DNS tables (which is what is required
> when abuse@ is a MUST.)

For the moment, I'm not concerned about the abuse@ stuff; there is a poll
in progress and I have separately responded to that.  I am concerned about
the use of the Path field for limiting retransmissions, the corresponding
uniqueness requirement and the document text related to that.

> To get an example I went to news.software.nntp and THE VERY FIRST ARTICLE
> I CHOSE had this:
> 
> cox.net!news-xfer.cox.net!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!news.glorb.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail

No IP addresses, no unqualified (UUCP or otherwise) names.

> 1. cox.net is not a FQDN.

Depends on your definition of "FQDN":

# nslookup -sil -type=any cox.net
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
cox.net nameserver = ns.west.cox.net.
cox.net nameserver = ns.cox.net.
cox.net nameserver = ns.east.cox.net.
cox.net mail exchanger = 100 mx.east.cox.net.
cox.net mail exchanger = 100 mx.west.cox.net.
Name:   cox.net
Address: 68.1.17.9

Authoritative answers can be found from:
cox.net nameserver = ns.east.cox.net.
cox.net nameserver = ns.west.cox.net.
cox.net nameserver = ns.cox.net.
ns.cox.net      internet address = 68.1.16.100
ns.east.cox.net internet address = 68.12.19.237
ns.west.cox.net internet address = 68.111.106.76
mx.east.cox.net internet address = 68.1.17.3
mx.west.cox.net internet address = 68.6.19.3


It looks like a FQDN (a name with the right-most label (net) being a
registered top-level domain name), and DNS reports several corresponding
records (I'll leave authoritative checks to anybody who cares), including
an A record.

Exactly what sort of definition of "FQDN" do you have in mind that would
exclude "cox.net"?

> 2. nntp.frontiernet.net
>     No DNS entries.

Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
nntp.frontiernet.net
        origin = auth01.roc.ny.frontiernet.net
        mail addr = hostmaster.frontiernet.net
        serial = 163
        refresh = 10800
        retry = 3600
        expire = 604800
        minimum = 900
nntp.frontiernet.net    nameserver = auth02.roc.ny.frontiernet.net.
nntp.frontiernet.net    nameserver = auth01.roc.ny.frontiernet.net.

Authoritative answers can be found from:
nntp.frontiernet.net    nameserver = auth02.roc.ny.frontiernet.net.
nntp.frontiernet.net    nameserver = auth01.roc.ny.frontiernet.net.

> 3. postnews.google.com
>     No DNS entries.

True, but it's still a FQDN, and there is a "google.com" responsible for
names under that hierarchy (with DNS records including SOA).
 
> 4. z14g2000cwz.googlegroups.com
>     No DNS entries

Same situation as above.
 
> This article had a Complaints-To, and an X-Complaints-To header fields.

Not useful at the moment (no defined syntax).
 
> How many people would have difficulty finding contact information
> for any of those path entries?

Don't care.  That's not the purpose of Path.

> Compare that to the hassle of cox.net 
> telling all its up and downstream peers all of its routing server
> names, or google.com maintaining DNS records for all of the internal
> machines behind its firewall.

Unnecessary.
 
> Since NEWS is not USENET, does anyone see a problem with someone
> running a private server on 192.168.x.x (or other globally non-unique
> IP addresses), and sticking those IP addresses in the path?  If articles
> with those paths leak out to Usenet, what do I care if they don't
> propagate?

That's not the issue.
 
> If we provide a clear explanation of how retransmissions are limited,
> do we have to explain to implementors that they will have trouble
> with propagation when they use a DYNAMIC IP address and stick that
> in the Path?  It's a silly example anyway, because in the scenarios
> some people have concocted to make their point, there is no way
> for peers to connect and send news to such a machine.

You seem to be confusing connection to a host with content in a Path
field.  One does not directly affect the other (e.g. one can connect
to the site which entered a private-use IP address using a different
name).

There are actually two criteria:
1. names MUST be globally unique (to prevent failure of transport due
   to name clashes)
2. names must (logically) be known to a site's immediate neighbors as
   that is where the checks for names to limit retransmissions take
   place

We do need to specify the first, as is it a global requirement associated
with the Path field semantics and the field's use in protocols.  We
shouldn't have to state the second as such provided that the description
of the semantics of the field are made sufficiently clear -- it should be
obvious.  I believe that the first paragraph of USEFOR section 3.1.6 is
currently sufficiently clear on that point.  If you feel that further
clarification is necessary, feel free to propose a change.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75Eb6Cx033108 for <[e-mail]>; Fri, 5 Aug 2005 07:37:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75Eb6MP033107 for ietf-usefor-skb; Fri, 5 Aug 2005 07:37:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from soy.epix.net (soy.epix.net [199.224.64.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75Eb31R033095 for <[e-mail]>; Fri, 5 Aug 2005 07:37:06 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-199-224-97-80-pppoe.dsl.hrbg.epix.net [199.224.97.80]) by soy.epix.net (8.12.10/2004120601/PL) with ESMTP id j75Eb2gE000943 for <[e-mail]>; Fri, 5 Aug 2005 10:37:03 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 05 Aug 2005 10:37: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: New USEPRO path-identity text (Hello, Chair?)
References: <[e-mail]> <[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:

> In <[e-mail]> John Stanley <[e-mail]> writes:
> 
> 
>>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:
> 
> 
>>>       NOTE: A news-server administrator who chooses a name which turns
>>>       out not to be unique will have to bear the consequences.
> 
> 
>>A news server administrator who chooses to do anything against a MUST 
>>will have to bear the consequences. Just how many patently obvious things 
>>do you think we need to put in a standard? Why aren't we threatening them 
>>every time we use MUST? 
> 
> 
> Such an administrator has not actually violated any MUST AFAICS. He has
> merely exercised bad judgement.
> 
> 
> 
>>>However, I don't think it is wise to describe a "SHOULD" feature as
>>>"optional". 
> 
> 
>>You don't have to. RFC2119 already does that.
> 
> 
> It has been patiently explained to you many times and by many people that
> "SHOULD" does not equate to "optional".

It has been patiently and impatiently explained to you that RFC2119
makes it clear that if you only need a valid reason to disregard a SHOULD.

Standards are all about defining consequences, not creating some
petty heirarchy of who is more compliant and shaming implementors.  No
one who is an editor should need RFC2119 terms explained, or why
"optional" is different than "OPTIONAL."

John is precise enough to write "must" and "optional" when he
means "must" and "optional" and not "MUST" and "OPTIONAL."  You are
an editor, so you MUST follow the convention that John uses.

I asked before, and the Chair ruled.  Can the Chair please use private
email to force Charles to use RFC2119 terms properly?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75EPYpq031169 for <[e-mail]>; Fri, 5 Aug 2005 07:25:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75EPYUg031168 for ietf-usefor-skb; Fri, 5 Aug 2005 07:25:34 -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 j75EPYW4031157 for <[e-mail]>; Fri, 5 Aug 2005 07:25:34 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-199-224-97-80-pppoe.dsl.hrbg.epix.net [199.224.97.80]) by lentil.epix.net (8.12.10/2004120601/PL) with ESMTP id j75EPQBI012655 for <[e-mail]>; Fri, 5 Aug 2005 10:25:30 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 05 Aug 2005 10:25:27 -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: Shame vs Engineering
References: <[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>

Bruce Lilly wrote:
 > In practice, IP addresses are used in Path so
> rarely, and FQDNs are so readily available, that it's really not worth
> spending a lot of time worrying about this; the semantics and protocol
> impose a uniqueness requirement. 

There is a difference between a unique path entry, an unique FQDN,
and a unique FQDN that is in the DNS tables (which is what is required
when abuse@ is a MUST.)

Maybe there are a lot of people here that don't actually look at
path headers enough to know what is in them now, working perfectly well,
but would become non-compliant with text proposed.

To get an example I went to news.software.nntp and THE VERY FIRST ARTICLE
I CHOSE had this:

cox.net!news-xfer.cox.net!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!news.glorb.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail

1. cox.net is not a FQDN.  Is there a good reason to prohibit this entry?

    There certainly is a good, practical, maybe even necessary, reason to allow
    it when you have a multiple machines doing routing (and all the big providers
    certainly do.)

2. nntp.frontiernet.net
    No DNS entries.

3. postnews.google.com
    No DNS entries.

4. z14g2000cwz.googlegroups.com
    No DNS entries

This article had a Complaints-To, and an X-Complaints-To header fields.

How many people would have difficulty finding contact information
for any of those path entries?  Compare that to the hassle of cox.net
telling all its up and downstream peers all of its routing server
names, or google.com maintaining DNS records for all of the internal
machines behind its firewall.

Since NEWS is not USENET, does anyone see a problem with someone
running a private server on 192.168.x.x (or other globally non-unique
IP addresses), and sticking those IP addresses in the path?  If articles
with those paths leak out to Usenet, what do I care if they don't
propagate?

I agree with John that we don't need explanatory notes about
adminstrators bearing consequences for violating a MUST.  There
is no end to obvious things we can emphasize using extra NOTEs.

If we provide a clear explanation of how retransmissions are limited,
do we have to explain to implementors that they will have trouble
with propagation when they use a DYNAMIC IP address and stick that
in the Path?  It's a silly example anyway, because in the scenarios
some people have concocted to make their point, there is no way
for peers to connect and send news to such a machine.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75DveJh019635 for <[e-mail]>; Fri, 5 Aug 2005 06:57:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75DveMQ019634 for ietf-usefor-skb; Fri, 5 Aug 2005 06:57:40 -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 j75DvdCe019619 for <[e-mail]>; Fri, 5 Aug 2005 06:57:40 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-76-39.midband.mdip.bt.net ([81.144.76.39]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f35305.e6a.7d for [e-mail]; Fri,  5 Aug 2005 12:52:37 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j75BCFb15722 for [e-mail]; Fri, 5 Aug 2005 12:12:15 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22207
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: Fri, 5 Aug 2005 10:15:22 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]> John Stanley <[e-mail]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>        NOTE: A news-server administrator who chooses a name which turns
>>        out not to be unique will have to bear the consequences.

>A news server administrator who chooses to do anything against a MUST 
>will have to bear the consequences. Just how many patently obvious things 
>do you think we need to put in a standard? Why aren't we threatening them 
>every time we use MUST? 

Such an administrator has not actually violated any MUST AFAICS. He has
merely exercised bad judgement.


>>However, I don't think it is wise to describe a "SHOULD" feature as
>>"optional". 

>You don't have to. RFC2119 already does that.

It has been patiently explained to you many times and by many people that
"SHOULD" does not equate to "optional".

>>>Is it the function of Path to "enable administrators to be contacted", or 
>>>is it to simply record the path the article has taken? 

>>Both.

>Then, of course, the "not-for-mail" that is commonly appended is, what, a
>lie? Then, of course, RFC1036, when it says "The "Path" line is not used
>for replies, and should not be taken as a mailing address" is what,
>telling another lie? And the RFC1036 definition of Path that says "This
>line shows the path the message took to reach the current system" and 
>nothing at all about it being intended as a contact address is what, yet 
>another lie?

And RFC 2142, when it says "if an NNTP server's host name is
DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its
"Path:" headewrs, then email must be deliverable to both <[e-mail]>
and <[e-mail]>..." is telling another lie :-) .


>>The minimum we can expect is that is does not bounce (i.e. if you give it
>>as RCPT TO: to the proper server, then it will not be (permanently)
>>blocked).

>Unfortunately, as soon as RBL adds the sending site to it's blacklist, any 
>mail server that uses RBL will block it. Unless you want to demand that 
>RBL not be allowed for any mail server that handles USENET-related email, 
>you can't say much more than "correct syntax", and that's useless.

If the designated server for the abuse@ address uses that RBL blacklist,
then indeed the administrator has not fulfilled his responsibilities under
whatever MUST/SHOULD/... we write into our draft.

[The latest stupidity that has arisen is those abuse@ addresses whose
virus filters reject emails sent to them containing copies of
virus-containing emails that have emananated from those ISPs.]

>>If you can suggest any other phrase in place of "working" that conveys
>>that sense, without going into long descriptions of SMTP protocol details,
>>then please do so.

>"Syntactically correct". 

<[e-mail]> is syntactically correct, but it is not a "working"
email address. I note that RFC 2142 (as quoted above) uses "deliverable".
Would that be better than "working" or "valid"?

-- 
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 j75Bmchi071737 for <[e-mail]>; Fri, 5 Aug 2005 04:48:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75BmcRO071719 for ietf-usefor-skb; Fri, 5 Aug 2005 04:48:38 -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 j75Bmbs0071659 for <[e-mail]>; Fri, 5 Aug 2005 04:48:37 -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 836AB2996A for <[e-mail]>; Fri,  5 Aug 2005 07:48:34 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j75Bm3Qk012360(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, 5 Aug 2005 07:48:15 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j75Bm2x0012359(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, 5 Aug 2005 07:48:02 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: Shame vs Engineering
Date: Fri, 5 Aug 2005 07:47:59 -0400
User-Agent: KMail/1.8.2
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 August 4 2005 19:50, John Stanley wrote:
> 
> Bruce Lilly <blilly@xxxxxxxxx>:
> 
> >And "limit retransmissions" is mentioned in BCP 14 as a harm mitigation
> >item suitable for imperative keywords such as MUST.
> 
> Yes, yes, that's very nice. But if we have four options available, then 
> all four have to meet that criterion or they should not be available, no?

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

> >There is also something called DHCP, so while e.g. 216.49.158.220 is fully
> >routable, it may be assigned to one host at one time and to a very
> >different host a moment later (the Path field has no timestamp),
> 
> If a news server admin has his servers assigned addresses by DHCP and 
> doesn't make sure the same address is assigned each time, he deserves to 
> lose articles/see dups. It's just silly to do that.

He may have no choice; IP addresses are assigned by a service provider.
Use of an IP address, in order to meet the uniqueness requirement, would
have to be predicated on the address being not only globally routable,
but also statically assigned.  That's something that the site administrator
might be able to determine, but cannot in general be determined by some
other party, which makes use of IP addresses for diagnostics of limited
use, at least as a path entry (if we were to provide for comments, that
would be another matter).  In practice, IP addresses are used in Path so
rarely, and FQDNs are so readily available, that it's really not worth
spending a lot of time worrying about this; the semantics and protocol
impose a uniqueness requirement.  Uniqueness is guaranteed by a FQDN, but
not by an IP address (in general) or an unregistered, unregisterable UUCP
name, or by some random string.  Let's specify that (to meet the uniqueness
requirement) the Path entries (other than the tail-entry) MUST be FQDNs
and move on.

> Notice that the only mandate refers to injection agents, so apparently it 
> is ok by us for an admin of a transport or serving agent to use DHCP to 
> configure his IP address and use that in the Path. If that's true, why not
> for injection, too?

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

> >That's orders of magnitude difference, where
> >an IP address can easily be reassigned before an article finishes 
> >propagating.
> 
> If an admin runs his servers that way, who are we to tell him no?

We are the protocol specifiers, and the requirement exists due to the
field semantics and the use in transport protocols. 

> After 
> all, the Path entry is NOT a contact address, so the Path entry for an 
> injecting agent is really no different than one for a transport or serving
> agent.

Agreed. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7506Ze0091086 for <[e-mail]>; Thu, 4 Aug 2005 17:06:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7506ZD2091085 for ietf-usefor-skb; Thu, 4 Aug 2005 17:06:35 -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 j7506YHd091067 for <[e-mail]>; Thu, 4 Aug 2005 17:06:34 -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 j7506HFD025597 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 4 Aug 2005 17:06:17 -0700 (PDT)
Date: Thu, 4 Aug 2005 17:06:29 -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>:

>        NOTE: A news-server administrator who chooses a name which turns
>        out not to be unique will have to bear the consequences.

A news server administrator who chooses to do anything against a MUST 
will have to bear the consequences. Just how many patently obvious things 
do you think we need to put in a standard? Why aren't we threatening them 
every time we use MUST? 

Admins who ignore MUSTS are outside the scope of our document. Telling 
them they have to "bear the consequences" is patently silly.

>I find that rather bizarre. What harm arises, or what security hole is
>opened, if the Xref header uses a different identity? 

A fascinating argument. What harm arises if the injecting agent does not 
have an abuse@ address for the FQDN it uses as a path-identity?

>I now have:

>   There are various circumstances when news-server administrators may
>   need to be contacted. To facilitate this, the following email
>   addresses are provided:

Unless you personally are willing to provide those addresses, don't tell 
people that they "are provided". 

>However, I don't think it is wise to describe a "SHOULD" feature as
>"optional". 

You don't have to. RFC2119 already does that.

>>Is it the function of Path to "enable administrators to be contacted", or 
>>is it to simply record the path the article has taken? 

>Both.

Then, of course, the "not-for-mail" that is commonly appended is, what, a
lie? Then, of course, RFC1036, when it says "The "Path" line is not used
for replies, and should not be taken as a mailing address" is what,
telling another lie? And the RFC1036 definition of Path that says "This
line shows the path the message took to reach the current system" and 
nothing at all about it being intended as a contact address is what, yet 
another lie?

>Harald's syntax is not yet definitive. And it did include colons within
><IPv6address>s, so you still need to eschew "dead" and "beef".

As I recall, no, colons were NOT allowed in a path-identity. So no, we do 
not need to "eschew" 'dead' and 'beef'. 

>The minimum we can expect is that is does not bounce (i.e. if you give it
>as RCPT TO: to the proper server, then it will not be (permanently)
>blocked).

Unfortunately, as soon as RBL adds the sending site to it's blacklist, any 
mail server that uses RBL will block it. Unless you want to demand that 
RBL not be allowed for any mail server that handles USENET-related email, 
you can't say much more than "correct syntax", and that's useless.

>If you can suggest any other phrase in place of "working" that conveys
>that sense, without going into long descriptions of SMTP protocol details,
>then please do so.

"Syntactically correct". 

  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74NoXTj089314 for <[e-mail]>; Thu, 4 Aug 2005 16:50:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74NoXhL089313 for ietf-usefor-skb; Thu, 4 Aug 2005 16:50:33 -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 j74NoWUZ089306 for <[e-mail]>; Thu, 4 Aug 2005 16:50:32 -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 j74NoEFD020047 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 4 Aug 2005 16:50:14 -0700 (PDT)
Date: Thu, 4 Aug 2005 16:50:26 -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>

Bruce Lilly <blilly@xxxxxxxxx>:

>And "limit retransmissions" is mentioned in BCP 14 as a harm mitigation
>item suitable for imperative keywords such as MUST.

Yes, yes, that's very nice. But if we have four options available, then 
all four have to meet that criterion or they should not be available, no?

>There is also something called DHCP, so while e.g. 216.49.158.220 is fully
>routable, it may be assigned to one host at one time and to a very
>different host a moment later (the Path field has no timestamp),

If a news server admin has his servers assigned addresses by DHCP and 
doesn't make sure the same address is assigned each time, he deserves to 
lose articles/see dups. It's just silly to do that.

Notice that the only mandate refers to injection agents, so apparently it 
is ok by us for an admin of a transport or serving agent to use DHCP to 
configure his IP address and use that in the Path. If that's true, why not
for injection, too?

>Once upon a time, there was a registry for UUCP names, and a UUCP Mapping
>Project associated with it.

I know that, too. And there were UUCP names that were never mapped because
either the admin never sent in the data or the map coordinator for that 
area just ignored it.

>> See above. 10.x.x.x is not a routable IP address and does not fall into 
>> the category of valid as we have attempted to define it.

>Note DHCP. 

DHCP and 10.x.x.x are two different concepts. If someone configures his 
DHCP to lease out 10.x.x.x addresses, then they are not valid under item 2 
and thus outside the scope of this discussion.

>That's orders of magnitude difference, where
>an IP address can easily be reassigned before an article finishes 
>propagating.

If an admin runs his servers that way, who are we to tell him no?

On the other hand, if we tell transport and serving agent admins they CAN 
run them that way, who are we to tell injecting agent admins not to? After 
all, the Path entry is NOT a contact address, so the Path entry for an 
injecting agent is really no different than one for a transport or serving
agent.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74NOlbI087493 for <[e-mail]>; Thu, 4 Aug 2005 16:24:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74NOlMN087492 for ietf-usefor-skb; Thu, 4 Aug 2005 16:24: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 j74NOjwD087486 for <[e-mail]>; Thu, 4 Aug 2005 16:24:46 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6C8D3200B3; Fri,  5 Aug 2005 01:24: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 03460-09; Fri,  5 Aug 2005 01:24:40 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE5DB3200B5; Fri,  5 Aug 2005 01:24:39 +0200 (CEST)
Date: Fri, 05 Aug 2005 01:23:05 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: "Ralph Babel, singing - so be afraid" <[e-mail]>, [e-mail]
Subject: Re: #1093 Email addresses: Poll
Message-ID: <69E94D6D3D73605C152D6E84@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <[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: by 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>

Nice to hear a new voice!

--On 4. august 2005 21:03 +0200 "Ralph Babel, singing - so be afraid" 
<[e-mail]> wrote:

>
>> 1E) No requirement
>> 2C) No requirement
>
> BTW: Did I miss a "ReCharter or conclude" poll in "Apr 05"?
>
> Oh, I see: "April 2105". ("... If Usenet is still alive ...")

we're behind on our milestones.....this one, too...





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74LEONd077416 for <[e-mail]>; Thu, 4 Aug 2005 14:14:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74LEO5q077415 for ietf-usefor-skb; Thu, 4 Aug 2005 14:14:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from soy.epix.net (soy.epix.net [199.224.64.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74LENBr077409 for <[e-mail]>; Thu, 4 Aug 2005 14:14:23 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-186-67-pppoe.dsl.hrbg.epix.net [216.37.186.67]) by soy.epix.net (8.12.10/2004120601/PL) with ESMTP id j74LECgE006234 for <[e-mail]>; Thu, 4 Aug 2005 17:14:22 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 04 Aug 2005 17:14:12 -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
CC: [e-mail]
Subject: Re: New USEPRO path-identity text (Hello, Chair?)
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
Sender: [e-mail]
Precedence: 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 <[e-mail]> Bruce Lilly <[e-mail]> writes:
> 
> 
>>On Fri July 29 2005 17:03, Frank Ellermann wrote:
> 
> 
>>>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).
> 
> 
>>Inconsistent.  "mail (or phone)" means that "MUST about news@ / usenet@"
>>is "used to try to impose a particular method on implementors where the
>>method is not required for interoperability".  Phone use does not
>>require an email address.
> 
> 
> Hold on! Nobody has said you MUST send your complaint (whatever) by email
> to that specified address. All it has ever said is that administrators
> MUST provide that address, so that everybody has at least one known way to
> contact them.

Are you seriously making this argument?  Do you really understand RFC2119
"implementors" to include "everybody"?






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74JuxGX070864 for <[e-mail]>; Thu, 4 Aug 2005 12:56:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74JuxBe070863 for ietf-usefor-skb; Thu, 4 Aug 2005 12:56:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Juwdg070848 for <[e-mail]>; Thu, 4 Aug 2005 12:56:58 -0700 (PDT) (envelope-from [e-mail])
Received: from dialup032.mcc.ac.uk ([130.88.69.32]) by curlew.cs.man.ac.uk with esmtp (Exim 4.51 (FreeBSD)) id 1E0lpo-000PGR-Fr for [e-mail]; Thu, 04 Aug 2005 20:56:58 +0100
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j74JsJR06799; Thu, 4 Aug 2005 20:54:19 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22201
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]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Thu, 4 Aug 2005 12:22:58 GMT
Lines: 223
MIME-Version: 1.0
X-UoM: Scanned by the University Mail System. See http://www.mcc.ac.uk/cos/email/scanning for details.
Sender: [e-mail]
Precedence: 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

>>   In order to record the passage of articles through the network, and
>>   to enable their administrators to be contacted, news-servers need to
>>   identify themselves by means of a <path-identity> (F-3.1.6), which
>>   can appear in 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).

>This still mixes two very different things and it would be better to
>separate them far more clearly:

>Make this intro just say:

>    In order to record the passage of articles through the network,
>    news-servers need to identify themselves by means of a <path-
>    identity> (F-3.1.6), which appears in the Path header field.

Since this is an introduction to what <path-identity>s are provided for,
it would be odd not to mention all of their uses. The question of whether
you use the same one in all headers could be indeed be addressed later on,
so I now have:

   In order to record the passage of articles through the network, and
   to facilitate contact with their administrators, news-servers need to
   identify themselves by means of a <path-identity> (F-3.1.6), which
   can appear in 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).
[Maybe that last sentence moves elsewhere.]

Note the word "facilitate", which hopefully addresses some of your
concerns lower down.

>>   3. 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 server in
>>      question is not connected to the Internet), or unless it is of
>>      longstanding usage and cessation would be unduly disruptive[1], or
>>      unless one of the earlier options is provided as well.

>... and then there's still this vague threat which does not assist
>anyone and encouragement for multiple entries (which I accept that some
>systems do, but I don't see why it should be made to sound normal, it
>just ought not to be forbidden):

Yes, that is overly verbose and I knew it would need further discussion,
but I am being pulled in different directions by different people.

In particular, Bruce is upset that we provide no machanism to guarantee
the uniquness of these names (despite the fact that no mechanism is
possible, and the system is currently working fine without such a
mechanism). He demands that we admit to a "known technical omission".

Essentially, you ask me to omit the whole sentence about administrators'
responsibility and inappropriate choice. But that was there to draw
attention to the risk (as near as I wanted to get to "known technical
omission", though I doubt Bruce would accept it as such). I still think
that we need to point out this risk, and would welcome suggested wordings.
In the meantime, I have replaced it with a NOTE:

        NOTE: A news-server administrator who chooses a name which turns
        out not to be unique will have to bear the consequences.


>THEN you should discuss the Xref header field along these lines (I've
>recently been reading the Diablo source and it is clear from comments
>there (and the effort they go to) that there are some news reading
>programs that barf when the path identity in the Xref fails to match up
>properly with the Path (and with the name of the server).

I find that rather bizarre. What harm arises, or what security hole is
opened, if the Xref header uses a different identity? Russ has already
said, in these threads, that it does not matter. And why should Diablo
(which is a server, not a reader AIUI) care about the incoming Xref, which
it is supposed to be discarding anyway? And why are reading agents even
looking at the Path?

>    The Xref header field is used to keep used to keep track of the
>    <article-locator>s of crossposted articles so that reading agents
>    serviced by a particular serving agent can mark such articles as
>    read.

The place to say that is USEFOR, where it is in fact already said.

>    When articles are being passed to a reading agent the <server-
>    name> in this header field SHOULD match the left-most <path-
>    identity> in the Path header field.

And the place to say that would be in "Duties of a Serving Agent", though
I would want to hear a lot more support before saying so.


>>   There are two circumstances when news-server administrators may need
>>   to be contacted by email:

>    There are circumstances when news-server administrators may need to
>    be contacted. The optional Injection-Info header field MAY be used
>    to provide specific contact information. If it is present then the
>    <path-identity> within it SHOULD match the <path-identity> added to
>    the Path header field.

I now have:

   There are various circumstances when news-server administrators may
   need to be contacted. To facilitate this, the following email
   addresses are provided:

However, I don't think it is wise to describe a "SHOULD" feature as
"optional". Yes, this may be a better place to say that the Injection-Info
identity address SHOULD match the Path one, but let us see what comes out
of the Xref business before changing it.

>    The following algorithm SHOULD yield a valid contact address.

That depends on whether the "abuse" and "news/usenset" are both going to
be "SHOULD". I wrote separate "SHOULD"s for the two cases so that we could
adjust them independently (Harald's poll will decide that). If they
finally turn out to be the same, then the wording can be simplified.

>>   1. (injecting agents only)
>>      For sending complaints concerning the behavior of the poster of an
>>      article, the correct address is

>recast more vaguely (and avoiding the "correct" word) as:

The first part of the sentence was copied verbatim from USEFOR. We need to
be consistent, so I don't want to change that unless USEFOR changes (and
the word "complaint" is firmly built into the name of the <parameter>
concerned). But I accept your

>  ........, the address to be used is:


>>      o "abuse@" followed by the <path-identity> in that Injection-Info
>>        field; or, in the absence of any Injection-Info field, the
>>        <path-identity> inserted by that agent in the Path header field
>>        (which, for an injecting agent, should be the one followed by
>>        the keyword "POSTED"). Evidently, that <path-identity> needs to
>>        be an FQDN for this to work.

>this one is not, needs to say "email", so rewrite as

>  o an email address constructed as "abuse@" followed by the <path-
>    identity> in the Injection-Info field; or, in the absence of any
>    Injection-Info header field, the <path-identity> inserted by that
>    agent in the Path header field (which, for an injecting agent, is
>    the first one, reading from the left, to be followed by the keyword
>    "POSTED").

I now have "an address consisting of ...". Likewise in the "all agents"
text further down. But it is already clear from the revised context that
is it email addresses that are meant.

And one cannot rely on the presence of "POSTED" since it is a new feature
of our standard (hence my parenthetic "which ... should be..."). Yes, if
there are two "POSTED"s it needs to be the leftmost, but that is rare and
I did not want to complicate what was only a parenthetic remark.

>>[Notes]
>>
>>   [1]  Now that we are agreed to allow a single server to insert
>>        several <path-identity>s to identify itself, do we really still
>>        need to mention that "unduly disruprive business"? Richard?

>yes, just because !demon! also adds another entity does not mean that
>other long-standing users of UUCP names do the same

But they probably SHOULD. And if we say they SHOULD, then there would be
no need for that longish "disruptive" sentence.

>a) in the real world you don't need MX records to send email

I don't think I implied anywhere that you did.

>b) I don't see how anyone could have anything sensible to report about
>anything other than the left-most machine to appear in the path

If one observes, from study of of many Paths, that some relaying site is
consistently munging articles, or duplicating them, or otherwise
interfering with propagation, then one would indeed need to contact them.

>c) we don't insist, it's a SHOULD, which means that adults can decide
>that there are overriding reasons for failing to provide the email
>addresses.

I agree. But its a "MUST" (or "must") for all cases in RFC 2142, which is
why I want to weaken it.

>Personally, I'd still rather drop the whole of #2 in the algorithm (ie
>ANY mention of news@ or usenet@ and leave RFC2142 to sink or swim by
>itself without ANY comment here.  viz: we just write the text about how
>to use Injection-Info information to build an abuse@ address and leave
>it at that. Anyone with a problem with their peer is going to use the
>sysadmin address established when the peering arrangement was set up;
>and problems with machines further away are either non-urgent (low
>volume) or it's hardly rocket-science to work out who to contact

For sure, people will know who their peers are. The news/usenet addresses
are provided for non-peers. If RFC 2142 had been written in an
intelligible manner, it would have been fine. But it is too strong in some
places and too vague in others. "news/usenet" are comparable to "postmaster"
in email, and RFC 2821 saw fit to define it afresh (even as a MUST) rather
than rely on 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 j74JuvJc070846 for <[e-mail]>; Thu, 4 Aug 2005 12:56:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74JuvKK070845 for ietf-usefor-skb; Thu, 4 Aug 2005 12:56:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74JuuEK070832 for <[e-mail]>; Thu, 4 Aug 2005 12:56:57 -0700 (PDT) (envelope-from [e-mail])
Received: from dialup032.mcc.ac.uk ([130.88.69.32]) by curlew.cs.man.ac.uk with esmtp (Exim 4.51 (FreeBSD)) id 1E0lpn-000PGR-Mu for [e-mail]; Thu, 04 Aug 2005 20:56:56 +0100
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j74Js4s06794; Thu, 4 Aug 2005 20:54:04 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22202
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, 4 Aug 2005 13:09:57 GMT
Lines: 60
MIME-Version: 1.0
X-UoM: Scanned by the University Mail System. See http://www.mcc.ac.uk/cos/email/scanning for details.
Sender: [e-mail]
Precedence: 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>:


>Is it the function of Path to "enable administrators to be contacted", or 
>is it to simply record the path the article has taken? 

Both. And any other diagnostic uses people can find for it.

>>   <Path-identity>s can take the following forms (in decreasing order of
>>   suitability):

>Either suitable is or is not. Your preference is not a measure of 
>suitability. Do you really mean "preference"?

OK. I've put "preference".

>>   3. Some other (arbitrary) name believed to be unique and registered
>>      at least with all other news-servers sending articles directly to

>Hyphen-ated news-servers why-is?

That is the technical term as I have defined it in USEPRO. It could easily
be changed throughout if needs be.


>>        NOTE: The syntax permits the colon character (which, prior to
>>        this standard, was a <path-delimiter>) within any <path-
> 
>The last text I saw Harald produce for this did NOT allow colons.

Harald's syntax is not yet definitive. And it did include colons within
<IPv6address>s, so you still need to eschew "dead" and "beef".


>Define "working email address". Is it the same as "mailable"? Given that
>"working" says nothing about "delivered to a human who actually reads it",
>or being able to pass through MAPS or ORBS or RBL or whatever the filter
>of the day is, about the best I can see us being able to specify is that
>the address is syntactically correct.

The minimum we can expect is that is does not bounce (i.e. if you give it
as RCPT TO: to the proper server, then it will not be (permanently)
blocked).

If you can suggest any other phrase in place of "working" that conveys
that sense, without going into long descriptions of SMTP protocol details,
then please do so.

-- 
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 j74JuuoX070836 for <[e-mail]>; Thu, 4 Aug 2005 12:56:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74JuuBW070835 for ietf-usefor-skb; Thu, 4 Aug 2005 12:56:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Juuie070813 for <[e-mail]>; Thu, 4 Aug 2005 12:56:56 -0700 (PDT) (envelope-from [e-mail])
Received: from dialup032.mcc.ac.uk ([130.88.69.32]) by curlew.cs.man.ac.uk with esmtp (Exim 4.51 (FreeBSD)) id 1E0lpn-000PGR-10 for [e-mail]; Thu, 04 Aug 2005 20:56:55 +0100
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j74Jreq06788; Thu, 4 Aug 2005 20:53:40 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22205
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Shame vs Engineering, also NEW conformance criteria
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Thu, 4 Aug 2005 13:29:08 GMT
Lines: 40
MIME-Version: 1.0
X-UoM: Scanned by the University Mail System. See http://www.mcc.ac.uk/cos/email/scanning for details.
Sender: [e-mail]
Precedence: 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 Sat July 30 2005 00:03, John Stanley wrote:

>> 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 Path field is used to limit retransmissions (see BCP 14) to sites
>through which an article has passed.  That requires uniqueness in site
>name.  an FQDN guarantees uniqueness.  An IP address literal does not;
>10.11.12.13 corresponds to different hosts at different parts of the
>network, as do 192.168.0.1, 169.254.0.1, 172.16.1.1, and 127.0.0.1.  A
>UUCP name lacks any sort of guarantee of uniqueness and there is
>currently no mechanism for uniqueness.  It is known that there have been
>duplicate uses of UUCP names.

Please stop shooting at your own strawmen. Nobody has ever suggested that
IP addresses such as 192.168.0.1 and 127.0.0.1 should be permitted. It
would be required that the IP address be that of the host concerned, and
that it be one that would reach that host from the public internet.

The wording that currently expresses that intent is:

   2.   An encoding of the public [RFC 1918] IP address - <IPv4address>
        or <IPv6address> [RFC 3986] - of that news-server. ...

If that is not clear enough, then please suggest improvements.

-- 
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 j74JuuxR070822 for <[e-mail]>; Thu, 4 Aug 2005 12:56:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74JuuUF070819 for ietf-usefor-skb; Thu, 4 Aug 2005 12:56:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74JutgD070800 for <[e-mail]>; Thu, 4 Aug 2005 12:56:55 -0700 (PDT) (envelope-from [e-mail])
Received: from dialup032.mcc.ac.uk ([130.88.69.32]) by curlew.cs.man.ac.uk with esmtp (Exim 4.51 (FreeBSD)) id 1E0lpl-000PGR-Td for [e-mail]; Thu, 04 Aug 2005 20:56:54 +0100
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j74JqPl06769; Thu, 4 Aug 2005 20:52:25 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22203
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]>
Date: Thu, 4 Aug 2005 13:14:07 GMT
Lines: 32
MIME-Version: 1.0
X-UoM: Scanned by the University Mail System. See http://www.mcc.ac.uk/cos/email/scanning for details.
Sender: [e-mail]
Precedence: 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 29 2005 17:03, Frank Ellermann wrote:

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

>Inconsistent.  "mail (or phone)" means that "MUST about news@ / usenet@"
>is "used to try to impose a particular method on implementors where the
>method is not required for interoperability".  Phone use does not
>require an email address.

Hold on! Nobody has said you MUST send your complaint (whatever) by email
to that specified address. All it has ever said is that administrators
MUST provide that address, so that everybody has at least one known way to
contact them.

And that "MUST" was "SHOULD" when last seen, and will finally be whatever
comes out of Harald's poll.

-- 
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 j74Juu57070823 for <[e-mail]>; Thu, 4 Aug 2005 12:56:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Juutg070820 for ietf-usefor-skb; Thu, 4 Aug 2005 12:56:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74JutpT070802 for <[e-mail]>; Thu, 4 Aug 2005 12:56:55 -0700 (PDT) (envelope-from [e-mail])
Received: from dialup032.mcc.ac.uk ([130.88.69.32]) by curlew.cs.man.ac.uk with esmtp (Exim 4.51 (FreeBSD)) id 1E0lpm-000PGR-G4 for [e-mail]; Thu, 04 Aug 2005 20:56:54 +0100
Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j74JrD806780; Thu, 4 Aug 2005 20:53:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22204
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1093 Email addresses: Poll
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
Date: Thu, 4 Aug 2005 13:21:32 GMT
Lines: 43
MIME-Version: 1.0
X-UoM: Scanned by the University Mail System. See http://www.mcc.ac.uk/cos/email/scanning for details.
Sender: [e-mail]
Precedence: 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 <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>1) news@ and usenet@ for all path-identities in the Path: or
>  Injection-info: headers

>  1A) All identities that look like domain-names MUST support
>  1B) All identities that look like domain-names SHOULD support
>  1C) Some identities MUST support
>      ("at least one of the <path-identity>s inserted by
>      themselves" is one example of "some")
>  1D) Some identities SHOULD support
>  1E) No requirement
>  1F) None of the above

I prefer 1C, or maybe 1D.

>2) abuse@ for injecting agents as identified in Path:, for the
>   case where Injection-info doesn't contain "mail-complaints-to"

>  2A) All identities MUST support abuse@identity
>  2B) All identities SHOULD support
>  2C) No requirement
>  2D) Top level domain corresponding to identity MUST support
>  2E) Top level domain corresponding to identity SHOULD support
>  2F) None of the above

I prefer 2A or 2B.
2D and 2E are meaningless unless TLD is rigorously defined.

For comparison, note that RFC 2142 (interpreting "must" as "MUST") requires
1A and 2D (in fact more than 1A). I doubt that is going to represent
anything like our consensus view.

-- 
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 j74JkwRt069700 for <[e-mail]>; Thu, 4 Aug 2005 12:46:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Jkw4t069699 for ietf-usefor-skb; Thu, 4 Aug 2005 12:46:58 -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 j74JkvqC069660 for <[e-mail]>; Thu, 4 Aug 2005 12:46: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 72918299F6 for <[e-mail]>; Thu,  4 Aug 2005 15:46: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 j74JktjF003356(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, 4 Aug 2005 15:46:55 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j74Jks3V003355(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, 4 Aug 2005 15:46:55 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: Shame vs Engineering
Date: Thu, 4 Aug 2005 15:46:50 -0400
User-Agent: KMail/1.8.2
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 August 4 2005 12:48, John Stanley wrote:
> 
> Bruce Lilly <blilly@xxxxxxxxx>:
> 
> >The Path field is used to limit retransmissions (see BCP 14) to sites
> >through which an article has passed.  That requires uniqueness in site
> >name. 
> 
> Yes, that's right.

And "limit retransmissions" is mentioned in BCP 14 as a harm mitigation
item suitable for imperative keywords such as MUST.
 
> > an FQDN guarantees uniqueness.
> 
> That's not the only way. That's only one of the four options we have 
> provided.
> 
> >An IP address literal does not;
> >10.11.12.13 corresponds to different hosts at different parts of the
> >network,
> 
> Ummm, so that's why I said "a valid IP literal", which according to item 2
> (I think it is) is NOT a non-routable address such as any of the examples
> you gave. They aren't valid according to our draft; please don't throw
> them up as examples to disprove something I said regarding a valid IP
> literal.

There is also something called DHCP, so while e.g. 216.49.158.220 is fully
routable, it may be assigned to one host at one time and to a very different
host a moment later (the Path field has no timestamp), so there is still no
guarantee of uniqueness.  I'm also concerned about the (lack of) stability
of IPv4 address blocks (RFC 3330 has made some recent changes) and it is
probably too early to gauge IPv6 reserved block stability.

> >A UUCP name lacks any sort of guarantee of uniqueness 
> 
> And yet, the system functioned for many years using them. Go figure. 

Once upon a time, there was a registry for UUCP names, and a UUCP Mapping
Project associated with it.  One goal of that project was to provide
unique names among *registered* UUCP sites; it failed to do so, and the
project is gone.  So while it may have sort-of "functioned" for some time,
there is no longer a registry to provide the necessary uniqueness trait.

[...]
> See above. 10.x.x.x is not a routable IP address and does not fall into 
> the category of valid as we have attempted to define it.

Note DHCP.  An IP address can be reassigned in time periods of minutes, hours,
or (unusually) days.  Domain names are typically assigned to a registrant for
increments measured in years.  That's orders of magnitude difference, where
an IP address can easily be reassigned before an article finishes propagating.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74J4IeK066189 for <[e-mail]>; Thu, 4 Aug 2005 12:04:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74J4IJf066188 for ietf-usefor-skb; Thu, 4 Aug 2005 12:04:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from madcow.cryp.to (madcow.cryp.to [193.123.234.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74J4GY0066173 for <[e-mail]>; Thu, 4 Aug 2005 12:04:17 -0700 (PDT) (envelope-from [e-mail])
Received: from nemesis.pfm-mainz.de (localhost [127.0.0.1]) by madcow.cryp.to with ESMTP id j74J4Cp4003959 for <[e-mail]>; Thu, 4 Aug 2005 21:04:13 +0200
Date: Thu, 4 Aug 2005 21:03:35 +0200
Message-Id: <[e-mail]>
In-Reply-To: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
From: [e-mail] (Ralph Babel, singing - so be afraid)
To: [e-mail]
Subject: Re: #1093 Email addresses: Poll
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

> 1E) No requirement
> 2C) No requirement

BTW: Did I miss a "ReCharter or conclude" poll in "Apr 05"?

Oh, I see: "April 2105". ("... If Usenet is still alive ...")



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74GtdxU056624 for <[e-mail]>; Thu, 4 Aug 2005 09:55:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Gtdx0056623 for ietf-usefor-skb; Thu, 4 Aug 2005 09:55: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 j74Gtc6H056612 for <[e-mail]>; Thu, 4 Aug 2005 09:55:38 -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 j74GtItW056670 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 4 Aug 2005 09:55:18 -0700 (PDT)
Date: Thu, 4 Aug 2005 09:55:33 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: #1093 Email addresses: Poll
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>Another interpretation of the email discussion is that we have one vocal 
>proponent of one viewpoint, one vocal opponent with a clear alternative, 
>and a number of viewpoints that are not strictly aligned with either of 
>the two others,

All of the ones I've seen have been pretty clear: MUST is not justified.
It would be a stretch of the imagination to not see that as aligning with
"MUST is not justified".

> it's impossible to count those).

People who don't care enough to express an opinion are now supposed to 
decide what we do? Wow. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74GmcuQ056145 for <[e-mail]>; Thu, 4 Aug 2005 09:48:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74GmccO056144 for ietf-usefor-skb; Thu, 4 Aug 2005 09:48:38 -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 j74GmbpF056136 for <[e-mail]>; Thu, 4 Aug 2005 09:48:37 -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 j74GmJFD095728 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 4 Aug 2005 09:48:19 -0700 (PDT)
Date: Thu, 4 Aug 2005 09:48:31 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: Re: Shame vs Engineering, also NEW conformance criteria
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>:

>The Path field is used to limit retransmissions (see BCP 14) to sites
>through which an article has passed.  That requires uniqueness in site
>name. 

Yes, that's right.

> an FQDN guarantees uniqueness.

That's not the only way. That's only one of the four options we have 
provided.

>An IP address literal does not;
>10.11.12.13 corresponds to different hosts at different parts of the
>network,

Ummm, so that's why I said "a valid IP literal", which according to item 2
(I think it is) is NOT a non-routable address such as any of the examples
you gave. They aren't valid according to our draft; please don't throw
them up as examples to disprove something I said regarding a valid IP
literal.

>A UUCP name lacks any sort of guarantee of uniqueness 

And yet, the system functioned for many years using them. Go figure. 

If the option isn't valid to start with, then remove it from the list as 
invalid. If it's on the list as one of the ways of identifying a site, 
then it's valid according to us and I see no reason why some are "MUST" 
and others are not.

>Contact for abuse reporting is a WIBNI (Wouldn't It Be Nice If...), not
>a protocol requirement.  But it's not the purpose of the Path field.

According to Charles's latest text, it is. 

>See above.  Foo.example.com may mean different things in the long term;
>10.11.12.13 can mean different things at the same time.

See above. 10.x.x.x is not a routable IP address and does not fall into 
the category of valid as we have attempted to define it. While Charles 
still has something about "public", he's already made it clear that his 
intent was to exclude the private netblocks (and multicast, if that isn't 
considered a part of the private nets) like 10.*, 192.168.*, etc. He's 
just refused to refer to the addresses as "routable".








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74DD0DV017715 for <[e-mail]>; Thu, 4 Aug 2005 06:13:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74DD0ns017714 for ietf-usefor-skb; Thu, 4 Aug 2005 06:13: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 j74DCwd8017697 for <[e-mail]>; Thu, 4 Aug 2005 06:12:59 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F25473200B5; Thu,  4 Aug 2005 15:12: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 23247-03; Thu,  4 Aug 2005 15:12:54 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FAAB3200B3; Thu,  4 Aug 2005 15:12:54 +0200 (CEST)
Date: Thu, 04 Aug 2005 15:06:11 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: "Forrest J. Cavalier III" <[e-mail]>, [e-mail]
Subject: Re: #1093 Email addresses: Poll
Message-ID: <058854C928E9C2C1C854A548@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126> <[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: by 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 4. august 2005 08:26 -0400 "Forrest J. Cavalier III" 
<[e-mail]> wrote:

>
> Ah, a return to Usefor WG polls that allows voting contrary to reality
> and reason.
>
> This doesn't need a poll.  The consensus is already clear from discussion,
> with a cluster of well-reasoned opinions in the "ANTI" group, and one
> opinion, not supported by reason, far away from that.

If that is true, interpreting the polll result should be easy.

Another interpretation of the email discussion is that we have one vocal 
proponent of one viewpoint, one vocal opponent with a clear alternative, 
and a number of viewpoints that are not strictly aligned with either of the 
two others, and a number of silent onlookers (or possibly a number of 
people who have already given up hope for consensus and stopped reading; 
it's impossible to count those).

Thanks for responding to the poll.

               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 j74CQvwI099075 for <[e-mail]>; Thu, 4 Aug 2005 05:26:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74CQvG2099074 for ietf-usefor-skb; Thu, 4 Aug 2005 05:26: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 j74CQu1x099057 for <[e-mail]>; Thu, 4 Aug 2005 05:26:56 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.2.11] (hrbg-216-37-186-67-pppoe.dsl.hrbg.epix.net [216.37.186.67]) by pine.epix.net (8.12.10/2004120601/PL) with ESMTP id j74CQkgt000870 for <[e-mail]>; Thu, 4 Aug 2005 08:26:55 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 04 Aug 2005 08:26:47 -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: #1093 Email addresses: Poll
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
In-Reply-To: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
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>

Ah, a return to Usefor WG polls that allows voting contrary to reality
and reason.

This doesn't need a poll.  The consensus is already clear from discussion,
with a cluster of well-reasoned opinions in the "ANTI" group, and one
opinion, not supported by reason, far away from that.

The path header field has a specific purpose for article propagation, not
indicating who accepts complaints and how.  There is no way to put in all
the diagnostic information included RFC2822 "Received" fields, and if we
tried the result will be about as unreliable, and as confusing and
unhelpful when Joe User only knows how to complain by emailing path
identities.

When you eliminate all the unjustified, contrary to RFC2119, and redundant
(as in "this feature is already supported by Complaints-To, or injection info"
or is properly described by other IETF documents") you are left with only
two choices, which are close enough to being the same choice that you don't
need a poll.

 > 1) news@ and usenet@ for all path-identities in the Path: or
 >   Injection-info: headers
 >   Alternatives, plese pick one:
    1E) No requirement
    1F) None of the above


> 
> 2) abuse@ for injecting agents as identified in Path:, for the
>    case where Injection-info doesn't contain "mail-complaints-to"
>    Alternatives, please pick one:
    2C) No requirement
    2F) None of the 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 j741CNaQ004230 for <[e-mail]>; Wed, 3 Aug 2005 18:12:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j741CNSm004229 for ietf-usefor-skb; Wed, 3 Aug 2005 18:12:23 -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 j741CMI9004221 for <[e-mail]>; Wed, 3 Aug 2005 18:12:22 -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 8815729B2C; Wed,  3 Aug 2005 21: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 j741CGlE016726(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, 3 Aug 2005 21:12:18 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j741CF9u016725(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, 3 Aug 2005 21:12:16 -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, 3 Aug 2005 21:12:12 -0400
User-Agent: KMail/1.8.2
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 02:47, Frank Ellermann wrote:

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

Message identifiers and the fields using them -- Message-ID, References,
In-Reply-To -- started with RFC 724.  The fields and the identifiers
they use were adopted by RFC 850.

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

If you want to change to an incompatible format, then use different
field names to avoid confusion. 

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

Same as RFC 2822. And 822. Also 733 and 724 if you accept pre-DNS "host"
as analogous to domain.
 
> 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).

The "tag" proposal was so uninteresting it wasn't worth commenting on.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j740qI90002763 for <[e-mail]>; Wed, 3 Aug 2005 17:52:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j740qInt002762 for ietf-usefor-skb; Wed, 3 Aug 2005 17:52:18 -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 j740qHwS002745 for <[e-mail]>; Wed, 3 Aug 2005 17:52: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 C915F29A61 for <[e-mail]>; Wed,  3 Aug 2005 20:52:16 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j740qFAB016617(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, 3 Aug 2005 20:52:16 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j740qFk8016616(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, 3 Aug 2005 20:52:15 -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, 3 Aug 2005 20:52:11 -0400
User-Agent: KMail/1.8.2
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 29 2005 10:23, Charles Lindsey wrote:

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

That is a false assertions, as can plainly be seen from the mailing list
archives.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j740n7bJ002521 for <[e-mail]>; Wed, 3 Aug 2005 17:49:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j740n7Lc002520 for ietf-usefor-skb; Wed, 3 Aug 2005 17:49:07 -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 j740n62b002514 for <[e-mail]>; Wed, 3 Aug 2005 17:49:06 -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 CBFEB299E9; Wed,  3 Aug 2005 20:49: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 j740n3JB016595(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, 3 Aug 2005 20:49:05 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j740n2HC016594(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, 3 Aug 2005 20:49:02 -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
Date: Wed, 3 Aug 2005 20:48:57 -0400
User-Agent: KMail/1.8.2
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 29 2005 12:54, Frank Ellermann wrote:
> 
> 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 ?

Usenetters requested elimination of CFWS (but no other changes) to
accommodate news software.  That change was made to the syntax (but
no change to semantics of the RHS) accordingly.

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

Given the fact that a domain name can be up to 255 octets, limiting
a msg-id (domain name plus local-part plus '<', '@', and '>') simply
isn't rational.

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

Tilting at windmills didn't work well for Don Quixote.  Good luck.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j740WsVk001574 for <[e-mail]>; Wed, 3 Aug 2005 17:32:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j740Ws9g001573 for ietf-usefor-skb; Wed, 3 Aug 2005 17:32:54 -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 j740WrmV001565 for <[e-mail]>; Wed, 3 Aug 2005 17:32: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 ns5.townisp.com (Postfix) with ESMTP id E48DB29A52; Wed,  3 Aug 2005 20:32:52 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j740Wl36016494(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, 3 Aug 2005 20:32:51 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j740Wk3n016493(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, 3 Aug 2005 20:32:47 -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, 3 Aug 2005 20:32:41 -0400
User-Agent: KMail/1.8.2
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 Fri July 29 2005 14:40, Frank Ellermann wrote:
> 
> 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 ?

You probably forgot it.  Search the archives for
Message-ID: <[e-mail]>
IIRC, you're the "examples-are-better-than-syntax" guy :-).

Special offer; three for the price of one!

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

I'd still do Complaints-To as a bracketed URI list.  Same general
form as List-Post; plenty of reusable code for that.
 
---------
> > 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.

RFC 2017 is hardly "new".
  
> > 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.

See comp.mail.mime for an example of an ISP that likes to re-wrap
(at coincidentally ~ 255) during transport.
  
----------
> >> 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.

Remember that RFC 2045 that I suggested rereading?  Look up
"tspecial".

> > and encoded-words aren't allowed in quotes-strings.
> 
> No, = and ? are allowed in quoted-strings, in any combination.

Yes, but then there's no encoded-word.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7400j1N098884 for <[e-mail]>; Wed, 3 Aug 2005 17:00:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7400jG3098883 for ietf-usefor-skb; Wed, 3 Aug 2005 17:00:45 -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 j7400ios098877 for <[e-mail]>; Wed, 3 Aug 2005 17:00: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 ns3.townisp.com (Postfix) with ESMTP id 925DD29A12; Wed,  3 Aug 2005 20:00:43 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j7400gxa016349(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, 3 Aug 2005 20:00:42 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j7400ffF016348(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, 3 Aug 2005 20:00:42 -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, 3 Aug 2005 20:00:37 -0400
User-Agent: KMail/1.8.2
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 Fri July 29 2005 17:03, Frank Ellermann wrote:

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

Inconsistent.  "mail (or phone)" means that "MUST about news@ / usenet@"
is "used to try to impose a particular method on implementors where the
method is not required for interoperability".  Phone use does not
require an email address.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73NZUSM097389 for <[e-mail]>; Wed, 3 Aug 2005 16:35:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73NZU7J097388 for ietf-usefor-skb; Wed, 3 Aug 2005 16:35:30 -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 j73NZTeK097381 for <[e-mail]>; Wed, 3 Aug 2005 16:35: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 ns5.townisp.com (Postfix) with ESMTP id ECD7829A57; Wed,  3 Aug 2005 19:35:28 -0400 (EDT)
Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j73NZQQg016201(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, 3 Aug 2005 19:35:27 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j73NZPKX016200(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, 3 Aug 2005 19:35:25 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: #1093 Email addresses: Poll
Date: Wed, 3 Aug 2005 19:35:21 -0400
User-Agent: KMail/1.8.2
Cc: Harald Tveit Alvestrand <[e-mail]>
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
In-Reply-To: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
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 August 3 2005 09:05, Harald Tveit Alvestrand wrote:

In all cases (neither issue is syntax/semantics or news protocol, and
BCP 14 imperatives in an Informative document are dubious).

>   1E) No requirement

>   2C) No requirement

> Please send a message to the list saying which alternatives you support; 

I could support a recommendation-level statement in USEAGE, but that
shouldn't even be on the radar screen at this point (4 months beyond
"recharter or conclude" with neither of the standards track documents
that we're supposed to produce anywhere near capable of passing muster).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73NP0HT096509 for <[e-mail]>; Wed, 3 Aug 2005 16:25:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73NP0QE096508 for ietf-usefor-skb; Wed, 3 Aug 2005 16:25: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 j73NOxl6096502 for <[e-mail]>; Wed, 3 Aug 2005 16:24: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 352B8299F5 for <[e-mail]>; Wed,  3 Aug 2005 19:24: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 j73NOvXK016096(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, 3 Aug 2005 19:24:57 -0400
Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j73NOujr016095(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, 3 Aug 2005 19:24:56 -0400
From: Bruce Lilly <[e-mail]>
Reply-To: [e-mail]
Organization: Bruce Lilly
To: [e-mail]
Subject: Re: Shame vs Engineering, also NEW conformance criteria
Date: Wed, 3 Aug 2005 19:24:52 -0400
User-Agent: KMail/1.8.2
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 Sat July 30 2005 00:03, John Stanley wrote:

> 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 Path field is used to limit retransmissions (see BCP 14) to sites
through which an article has passed.  That requires uniqueness in site
name.  an FQDN guarantees uniqueness.  An IP address literal does not;
10.11.12.13 corresponds to different hosts at different parts of the
network, as do 192.168.0.1, 169.254.0.1, 172.16.1.1, and 127.0.0.1.  A
UUCP name lacks any sort of guarantee of uniqueness and there is
currently no mechanism for uniqueness.  It is known that there have been
duplicate uses of UUCP names.

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

Contact for abuse reporting is a WIBNI (Wouldn't It Be Nice If...), not
a protocol requirement.  But it's not the purpose of the Path field.

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

See above.  Foo.example.com may mean different things in the long term;
10.11.12.13 can mean different things at the same time.

On a somewhat related note (one of our co-chairs will be familiar with
this issue), we are supposed to be generating Standards Track RFCs for
1) syntax & semantics and 2) protocol issues.  In order for a Standards
Track specification to advance to the next level (Draft Standard), it
will be necessary to prepare documentation for two independent fully
conforming implementations (BCP 9).  That will be facilitated if our
Standards Track documents have sections summarizing conformance
criteria.  Obviously, any BCP 14 imperative keywords (as these are
supposed to be limited to issues of interoperability and harm
mitigation) would be candidates for inclusion in such a summary.  I
suggest producing conformance criteria summary sections in the usefor
and usepro drafts, the first pass of which could be a list of existing
use of BCP 14 imperative keywords.   That would consolidate in one place
all use of such keywords, which we can then review for appropriateness
per the BCP 14 rules for use of such imperatives as well as review
with respect to the ability to objectively evaluate implementations
for conformance.  A summary of conformance criteria would also be a
convenience for implementers, for obvious reasons.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73LFVsP086317 for <[e-mail]>; Wed, 3 Aug 2005 14:15:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73LFVNO086316 for ietf-usefor-skb; Wed, 3 Aug 2005 14:15: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 j73LFSBJ086308 for <[e-mail]>; Wed, 3 Aug 2005 14:15:29 -0700 (PDT) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E0QYJ-00059D-36 for [e-mail]; Wed, 03 Aug 2005 23:13:27 +0200
Received: from c-180-160-40.hh.dial.de.ignite.net ([62.180.160.40]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 03 Aug 2005 23:13:27 +0200
Received: from nobody by c-180-160-40.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 03 Aug 2005 23:13:27 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1093 Email addresses: Poll
Date:  Wed, 03 Aug 2005 23:06:04 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Message-ID:  <[e-mail]>
References:  <5CDF309B260515727F61EBA3@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: c-180-160-40.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:

> 1B) All identities that look like domain-names SHOULD support

That apparently reflects 2142 best.  Could be in a "note" with
a reference to 2142 mentioning these traditional addresses, no
2119 keyword required from my POV.  No requirement (1E), but
still mention it with a 2142 reference.

> 2B) All identities SHOULD support

That's in the spirit of 2142...

> 2D) Top level domain corresponding to identity MUST support

...dito.  IMHO we don't need 2D. it's clear.  2B is also clear,
it's just what 2142 says.  Maybe something like "SHOULD offer
mail-complaints-to, and else it's supposed to follow RfC 2142
about abuse@ addresses" could do it.

Let's not mention the "top level domain" issue.  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 j73HpSp2069670 for <[e-mail]>; Wed, 3 Aug 2005 10:51:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73HpSi3069669 for ietf-usefor-skb; Wed, 3 Aug 2005 10:51:28 -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 j73HpRQ0069652 for <[e-mail]>; Wed, 3 Aug 2005 10:51:27 -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 j73Hp9FD034851 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 3 Aug 2005 10:51:09 -0700 (PDT)
Date: Wed, 3 Aug 2005 10:51:21 -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>:

>   In order to record the passage of articles through the network, and
>   to enable their administrators to be contacted, news-servers need to
>   identify themselves by means of a <path-identity> (F-3.1.6), which
>   can appear in Path, Injection-Info and Xref header fields.

Is it the function of Path to "enable administrators to be contacted", or 
is it to simply record the path the article has taken? 

>   <Path-identity>s can take the following forms (in decreasing order of
>   suitability):

Either suitable is or is not. Your preference is not a measure of 
suitability. Do you really mean "preference"?

>   3. Some other (arbitrary) name believed to be unique and registered
>      at least with all other news-servers sending articles directly to

Hyphen-ated news-servers why-is?

>      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

Here's that threat again. Tell the admin how to do it right and stop 
threatening him with unspecified "consequences" for listening to us.

>        NOTE: The syntax permits the colon character (which, prior to
>        this standard, was a <path-delimiter>) within any <path-
 
The last text I saw Harald produce for this did NOT allow colons.

>   There are two circumstances when news-server administrators may need
>   to be contacted by email:

Irrelevant for a specification of a protocol. People are free to imagine 
any number of reasons they want for contacting a news server admin. That 
excuse makes the entire section it heads specious.

>      For sending complaints concerning the behavior of the poster of an
>      article, the correct address is

Outside the scope of a protocol definition, and already covered by 
existing standards. Why do we* continue to demand that we redefine 
existing standards that are outside our scope?

* by "we", of course, I mean "Charles acting on our behalf".

>   2. (all agents)
>      For reporting technical problems concerning the operation of a
>      news-server, the correct address is either "news@" or "usenet@"
 
So if I see a problem with a server I know is run by Russ, I cannot 
contact him directly, I have to send it through news@somewhere? I really 
want to do "the correct thing", so please enlighten me why it isn't to 
contact him directly?

>        NOTE: The mechanisms set out above are broadly compatible with
>        the provisions of [RFC 2142].

Right. Whatever. 

>      Injecting agent administrators SHOULD[2,3] ensure that a working
>      email address is obtained by this process.

Define "working email address". Is it the same as "mailable"? Given that
"working" says nothing about "delivered to a human who actually reads it",
or being able to pass through MAPS or ORBS or RBL or whatever the filter
of the day is, about the best I can see us being able to specify is that
the address is syntactically correct. We can't specify much stronger than
that, since anything stronger will simply be ignored by anyone who
implements spam filters for role accounts. And who doesn't, these days?

>   [3]  Do we want to relax the need for an abuse address at small
>        private servers, or even at all servers not offering a public
>        service?

We have no authority to relax the need for an abuse address "at small
private servers", since every "small private server" that has a FQDN will
also have a top level domain to go with it, and RFC2142 already covers the
requirements for top level domain abuse addresses. Please STOP pretending
that if we don't mandate it that we are releasing anyone from already
existing mandates in other standards.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73HVFMq068131 for <[e-mail]>; Wed, 3 Aug 2005 10:31:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73HVFLD068130 for ietf-usefor-skb; Wed, 3 Aug 2005 10:31:15 -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 j73HVFx3068120 for <[e-mail]>; Wed, 3 Aug 2005 10:31:15 -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 j73HUuFD021972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 3 Aug 2005 10:30:57 -0700 (PDT)
Date: Wed, 3 Aug 2005 10:31:09 -0700 (PDT)
From: John Stanley <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: #1093 Email addresses: Poll
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>

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>1) news@ and usenet@ for all path-identities in the Path: or
> Injection-info: headers
> Alternatives, plese pick one:

> 1A) All identities that look like domain-names MUST support

And just how do we define what "looks like" a domain name? And why should 
WE be defining what "looks like" a domain name, when our task is USENET?

 1F) None of the above

I guess I have to go with that, since none of the options is correct. 
We can justify a MUST for one (or both, by stretching history) for every 
site, but "looks like a domain name" is silly. 

>2) abuse@ for injecting agents as identified in Path:, for the
>  case where Injection-info doesn't contain "mail-complaints-to"
>  Alternatives, please pick one:

> 2A) All identities MUST support abuse@identity

Expressly contradicted by existing standard.

> 2C) No requirement

Since existing standards already put some requirement on this, how can we 
come along and say "no requirement"? 

> 2D) Top level domain corresponding to identity MUST support

There is already a standard that says this. Why should we repeat it?

 2F) None of the above

I guess I'll have to go with this one, again, since none of the options 
are correct. The correct option is:

 2G: We say nothing because it has already been covered in other standards
     which have responsibility for this area.

>I read Charles' currently proposed text as 1D & 2B.

When Charles says "MUST", it does not match 2B (SHOULD), it matches 2A. 
And I just reread your question to make sure, and yes, you clearly specify 
the case "Injection info does't contain", which is most definitely when 
Charles's MUST kicks in.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73HIdhn066704 for <[e-mail]>; Wed, 3 Aug 2005 10:18:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73HIdv6066703 for ietf-usefor-skb; Wed, 3 Aug 2005 10:18:39 -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 j73HIdtK066694 for <[e-mail]>; Wed, 3 Aug 2005 10:18:39 -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 j73HIaxH005311 for <[e-mail]>; Wed, 3 Aug 2005 10:18:37 -0700
Received: by windlord.stanford.edu (Postfix, from userid 1000) id BB49DE79D7; Wed,  3 Aug 2005 10:18:36 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1093 Email addresses: Poll
In-Reply-To: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126> (Harald Tveit Alvestrand's message of "Wed, 03 Aug 2005 15:05:15 +0200")
Organization: The Eyrie
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
Date: Wed, 03 Aug 2005 10:18:36 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (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:

> I think the issue can be broken down into two different pieces:

> 1) news@ and usenet@ for all path-identities in the Path: or
>  Injection-info: headers
>  Alternatives, plese pick one:

>  1A) All identities that look like domain-names MUST support
>  1B) All identities that look like domain-names SHOULD support
>  1C) Some identities MUST support
>      ("at least one of the <path-identity>s inserted by
>      themselves" is one example of "some")
>  1D) Some identities SHOULD support
>  1E) No requirement
>  1F) None of the above

1E.  People aren't going to support it anyway, and I don't see any reason
to raise hopes in the standard.

> 2) abuse@ for injecting agents as identified in Path:, for the
>   case where Injection-info doesn't contain "mail-complaints-to"
>   Alternatives, please pick one:

>  2A) All identities MUST support abuse@identity
>  2B) All identities SHOULD support
>  2C) No requirement
>  2D) Top level domain corresponding to identity MUST support
>  2E) Top level domain corresponding to identity SHOULD support
>  2F) None of the above

2C.  abuse@ is none of our business.

-- 
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 j73E0R8G048519 for <[e-mail]>; Wed, 3 Aug 2005 07:00:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73E0R8O048518 for ietf-usefor-skb; Wed, 3 Aug 2005 07:00:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73E0QCj048506 for <[e-mail]>; Wed, 3 Aug 2005 07:00:26 -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-36.mail.demon.net with esmtp (Exim 4.42) id 1E0JnE-000FdQ-LY for [e-mail]; Wed, 03 Aug 2005 14:00:25 +0000
Message-ID: <[e-mail]>
Date: Wed, 3 Aug 2005 14:58:55 +0100
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: #1093 Email addresses: Poll
References: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
In-Reply-To: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <j87$+nlv77$aoPKLg6d+de++fY>
Sender: [e-mail]
Precedence: 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 <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <[e-mail]> writes

>I think the issue can be broken down into two different pieces:
>
>1) news@ and usenet@ for all path-identities in the Path: or
> Injection-info: headers
> Alternatives, plese pick one:
>
> 1A) All identities that look like domain-names MUST support
> 1B) All identities that look like domain-names SHOULD support
> 1C) Some identities MUST support
>     ("at least one of the <path-identity>s inserted by
>     themselves" is one example of "some")
> 1D) Some identities SHOULD support
> 1E) No requirement
> 1F) None of the above

1E  but if this is too extreme, then 1D

>2) abuse@ for injecting agents as identified in Path:, for the
>  case where Injection-info doesn't contain "mail-complaints-to"
>  Alternatives, please pick one:
>
> 2A) All identities MUST support abuse@identity
> 2B) All identities SHOULD support
> 2C) No requirement
> 2D) Top level domain corresponding to identity MUST support
> 2E) Top level domain corresponding to identity SHOULD support
> 2F) None of the above

2B (noting that this is the injecting agent ONLY), but could live with
2E (but I really don't see why people who want that can't add an
Injection-Info and avoid their perceived problems)

- -- 
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/AwUBQvDNn5oAxkTY1oPiEQJSrwCgj0GsNjI0RulpTAVSrERCnJyOb7oAoOSG
7IGoLwBCjMegdOJ/RiLj7xXQ
=17Ko
-----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 j73DMNuh033504 for <[e-mail]>; Wed, 3 Aug 2005 06:22:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73DMNa2033503 for ietf-usefor-skb; Wed, 3 Aug 2005 06:22:23 -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 j73DMMfj033492 for <[e-mail]>; Wed, 3 Aug 2005 06:22:23 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED4EA3200B5 for <[e-mail]>; Wed,  3 Aug 2005 15:22:22 +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 14391-08 for <[e-mail]>; Wed,  3 Aug 2005 15:22:14 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FE003200B8 for <[e-mail]>; Wed,  3 Aug 2005 15:22:14 +0200 (CEST)
Date: Wed, 03 Aug 2005 15:08:16 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1093 USEPRO 2.3: Supported email addresses
Message-ID: <FB62355B08824C2A45246E4D@B50854F0A9192E8EC6CDA126>
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: by 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 have created ticket #1093 to track this issue.
I'll send out one of my (in)famous polls in the next message.

Subject: USEPRO 2.3: Supported email addresses

Charles proposed the following new text:

There are two circumstances when news-server administrators may need
to be contacted by email:

1. (injecting agents only)
For sending complaints concerning the behavior of the poster of an
article, the correct address is
o If there is an Injection-Info header field with a "mail-
complaints-to" <parameter>, then the address in that
<parameter>; otherwise
o "abuse@" followed by the <path-identity> in that Injection-Info
field; or, in the absence of any Injection-Info field, the
<path-identity> inserted by that agent in the Path header field
(which, for an injecting agent, should be the one followed by
the keyword "POSTED"). Evidently, that <path-identity> needs to
be an FQDN for this to work.
Injecting agent administrators SHOULD[2,3] ensure that a working
email address is obtained by this process.

2. (all agents)
For reporting technical problems concerning the operation of a
news-server, the correct address is either "news@" or "usenet@"
followed by a <path-identity> obtained from an Injection-Info or
Path header field as above. Administrators SHOULD[4] ensure that
a working email address is obtained from at least one of the<path-
identity>s inserted by themselves[5].

NOTE: The mechanisms set out above are broadly compatible with
the provisions of [RFC 2142].

It is not clear to this chair that there is consensus on this 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 j73DLTwx033187 for <[e-mail]>; Wed, 3 Aug 2005 06:21:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73DLTYU033186 for ietf-usefor-skb; Wed, 3 Aug 2005 06:21:29 -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 j73DLSVu033175 for <[e-mail]>; Wed, 3 Aug 2005 06:21:29 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8821D3200B8 for <[e-mail]>; Wed,  3 Aug 2005 15:21: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 14391-06 for <[e-mail]>; Wed,  3 Aug 2005 15:21:25 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B67A43200B5 for <[e-mail]>; Wed,  3 Aug 2005 15:21:21 +0200 (CEST)
Date: Wed, 03 Aug 2005 15:05:15 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1093 Email addresses: Poll
Message-ID: <5CDF309B260515727F61EBA3@B50854F0A9192E8EC6CDA126>
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: by 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 think the issue can be broken down into two different pieces:

1) news@ and usenet@ for all path-identities in the Path: or
  Injection-info: headers
  Alternatives, plese pick one:

  1A) All identities that look like domain-names MUST support
  1B) All identities that look like domain-names SHOULD support
  1C) Some identities MUST support
      ("at least one of the <path-identity>s inserted by
      themselves" is one example of "some")
  1D) Some identities SHOULD support
  1E) No requirement
  1F) None of the above

2) abuse@ for injecting agents as identified in Path:, for the
   case where Injection-info doesn't contain "mail-complaints-to"
   Alternatives, please pick one:

  2A) All identities MUST support abuse@identity
  2B) All identities SHOULD support
  2C) No requirement
  2D) Top level domain corresponding to identity MUST support
  2E) Top level domain corresponding to identity SHOULD support
  2F) None of the above

I read Charles' currently proposed text as 1D & 2B.
Please send a message to the list saying which alternatives you support; 
once we know if there is a consensus in the working group on one pair of 
alternatives, we can go to wordsmithing.

                     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 j73CiB80018917 for <[e-mail]>; Wed, 3 Aug 2005 05:44:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73CiB70018916 for ietf-usefor-skb; Wed, 3 Aug 2005 05:44:11 -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 j73Ci9R6018900 for <[e-mail]>; Wed, 3 Aug 2005 05:44:10 -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 1E0IbQ-0007JO-0x for [e-mail]; Wed, 03 Aug 2005 12:44:09 +0000
Message-ID: <[e-mail]>
Date: Wed, 3 Aug 2005 13:42:48 +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]> <[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 <3L0$+7Sb77vtnOKLfua+dOjBxY>
Sender: [e-mail]
Precedence: 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

>2.3.  Identification of news-servers
>
>[new version]
>
>   In order to record the passage of articles through the network, and
>   to enable their administrators to be contacted, news-servers need to
>   identify themselves by means of a <path-identity> (F-3.1.6), which
>   can appear in 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).

This still mixes two very different things and it would be better to
separate them far more clearly:

Make this intro just say:

    In order to record the passage of articles through the network,
    news-servers need to identify themselves by means of a <path-
    identity> (F-3.1.6), which appears in the Path header field.

and then the next bit is OK, by me....

>   <Path-identity>s can take the following forms (in decreasing order of
>   suitability):
>
>   1. A fully qualified domain name (FQDN) associated with an "A" or
>      "AAAA" record identifying that news-server, or with an "MX" record
>      through which its administrators can be contacted; alternatively
>      an equivalent "CNAME".
>
>   2. An encoding of the public [RFC 1918] IP address - <IPv4address> or
>      <IPv6address> [RFC 3986] - of that news-server. This option SHOULD
>      NOT be used if an FQDN for that server is available (however, such
>      IP addresses are perfectly suitable for purely diagnostic
>      identities [reference needed to later section]).

... up to here, and then....

>   3. 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 server in
>      question is not connected to the Internet), or unless it is of
>      longstanding usage and cessation would be unduly disruptive[1], or
>      unless one of the earlier options is provided as well.

... and then there's still this vague threat which does not assist
anyone and encouragement for multiple entries (which I accept that some
systems do, but I don't see why it should be made to sound normal, it
just ought not to be forbidden):

so rewrite 3 as:

    Some other name believed to be unique and registered at least with
    all other news-servers sending articles directly to the given one.
    This option SHOULD NOT be used unless the earlier options are
    unavailable (e.g. because the server 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
>        therefore be unwise to choose, as such a name, anything composed
>        solely from four (or less) hexadecimal digits.

THEN you should discuss the Xref header field along these lines (I've
recently been reading the Diablo source and it is clear from comments
there (and the effort they go to) that there are some news reading
programs that barf when the path identity in the Xref fails to match up
properly with the Path (and with the name of the server).

    The Xref header field is used to keep used to keep track of the
    <article-locator>s of crossposted articles so that reading agents
    serviced by a particular serving agent can mark such articles as
    read. When articles are being passed to a reading agent the <server-
    name> in this header field SHOULD match the left-most <path-
    identity> in the Path header field.

THEN you can move on to the stuff about contacting people. Since it
doesn't seem to harm the text much to put off saying email until it is
unavoidable I have done that in my suggested text. If there is any
consensus for other means of contact then it will make it easier to edit

>   There are two circumstances when news-server administrators may need
>   to be contacted by email:

    There are circumstances when news-server administrators may need to
    be contacted. The optional Injection-Info header field MAY be used
    to provide specific contact information. If it is present then the
    <path-identity> within it SHOULD match the <path-identity> added to
    the Path header field.

    The following algorithm SHOULD yield a valid contact address.

>   1. (injecting agents only)
>      For sending complaints concerning the behavior of the poster of an
>      article, the correct address is

recast more vaguely (and avoiding the "correct" word) as:

  1. (injecting agents only)
    For messages relating to the posting of a particular article, the
    address to be used is:

>      o If there is an Injection-Info header field with a "mail-
>        complaints-to" <parameter>, then the address in that
>        <parameter>; otherwise

this small para OK by me

>      o "abuse@" followed by the <path-identity> in that Injection-Info
>        field; or, in the absence of any Injection-Info field, the
>        <path-identity> inserted by that agent in the Path header field
>        (which, for an injecting agent, should be the one followed by
>        the keyword "POSTED"). Evidently, that <path-identity> needs to
>        be an FQDN for this to work.

this one is not, needs to say "email", so rewrite as

  o an email address constructed as "abuse@" followed by the <path-
    identity> in the Injection-Info field; or, in the absence of any
    Injection-Info header field, the <path-identity> inserted by that
    agent in the Path header field (which, for an injecting agent, is
    the first one, reading from the left, to be followed by the keyword
    "POSTED").

>   2. (all agents)
>      For reporting technical problems concerning the operation of a
>      news-server, the correct address is either "news@" or "usenet@"
>      followed by a <path-identity> obtained from an Injection-Info or
>      Path header field as above.  Administrators SHOULD[4] ensure that
>      a working email address is obtained from at least one of the<path-
>      identity>s inserted by themselves[5].

rewrite [see below for more about this paragraph] as

  2. (all agents)
    For reporting technical problems concerning the operation of a news-
    server, the address to be used is an email address constructed as
    either "news@" or "usenet@" followed by a <path-identity> obtained
    from an Injection-Info or Path header field as above.  

>        NOTE: The mechanisms set out above are broadly compatible with
>        the provisions of [RFC 2142].
>[Notes]
>
>   [1]  Now that we are agreed to allow a single server to insert
>        several <path-identity>s to identify itself, do we really still
>        need to mention that "unduly disruprive business"? Richard?

yes, just because !demon! also adds another entity does not mean that
other long-standing users of UUCP names do the same

>   [2]  That used to be "MUST", but recently expressed opinions appear
>        to favour "SHOULD".
>
>   [3]  Do we want to relax the need for an abuse address at small
>        private servers, or even at all servers not offering a public
>        service?
>
>   [4}  That used to be "ideally should" (which is weaker that RFC 2142
>        - which was "must"). Do we want it as strong as "SHOULD"?
>        Obviously, it will not work if all you have is a UUCP-style
>        name.
>
>   [5]  If the server inserts several identities (e.g. a chain of hosts
>        in its farm) it would suffice for one working MX record
>        (hopefully an obvious one) to be in the list. Or do we really
>        want to insist that it creates an MX record to match every
>        individual host?

a) in the real world you don't need MX records to send email

b) I don't see how anyone could have anything sensible to report about
anything other than the left-most machine to appear in the path

c) we don't insist, it's a SHOULD, which means that adults can decide
that there are overriding reasons for failing to provide the email
addresses.

Personally, I'd still rather drop the whole of #2 in the algorithm (ie
ANY mention of news@ or usenet@ and leave RFC2142 to sink or swim by
itself without ANY comment here.  viz: we just write the text about how
to use Injection-Info information to build an abuse@ address and leave
it at that. Anyone with a problem with their peer is going to use the
sysadmin address established when the peering arrangement was set up;
and problems with machines further away are either non-urgent (low
volume) or it's hardly rocket-science to work out who to contact

>   [6]  That still leaves open the precise syntax of <path-identity> and
>        the like, and whether we are going to have words like ".SEEN" to
>        indicate diagnostice ones.  However, that issue should be
>        discussed under ticket #1047.

Summary: (to assist the chair if no-one else)

Charles has taken on board the notion of saying how to use Injection-
Info and then leaving it to the admins to build it to be useable (rather
than having a lot of didactic stuff about how to build it). This elides
a number of contentious words -- albeit not yet all of them. I like this
approach and endorse it. My, necessarily, detailed suggestions above
address what still concerns me.

There's a further issue, that RFC2142 documents a scheme for using news@
and usenet@ that is of limited practical use in a world where almost
everyone operates behind an abuse@ address. Some complication in this
document is avoided by failing to say anything about this (it either
works or doesn't work today, and what we say will not change that or
make anything more obvious). Avoiding any mention here has the benefit
that any future revision to 2142 in this area can be done orthogonally
to this document

- -- 
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/AwUBQvC7yJoAxkTY1oPiEQIw4ACfdVk3XKhFpMDXb7111xNa97/+ftQAnAmh
EUbmJ9pFvA1NuJkDJZ/0uN4t
=oU6z
-----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 j73BDVLm086007 for <[e-mail]>; Wed, 3 Aug 2005 04:13:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73BDVOs086006 for ietf-usefor-skb; Wed, 3 Aug 2005 04:13:31 -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 j73BDSlB085981 for <[e-mail]>; Wed, 3 Aug 2005 04:13:30 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-70-252.midband.mdip.bt.net ([81.144.70.252]) by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42f0a6d5.167d7.b9 for [e-mail]; Wed,  3 Aug 2005 12:13:25 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j73BCPv11736 for [e-mail]; Wed, 3 Aug 2005 12:12:25 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22185
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]> <[e-mail]> <[e-mail]>
Date: Wed, 3 Aug 2005 10:43:55 GMT
Lines: 134
Sender: [e-mail]
Precedence: 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:

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

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

Though I am not sure I really want MUST for that case.

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

OK, I think I have now heard enough to propose new text. But note that
there are still some questions at the end which need to be decided.

2.3.  Identification of news-servers

[new version]

   In order to record the passage of articles through the network, and
   to enable their administrators to be contacted, news-servers need to
   identify themselves by means of a <path-identity> (F-3.1.6), which
   can appear in 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).

   <Path-identity>s can take the following forms (in decreasing order of
   suitability):

   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record identifying that news-server, or with an "MX" record
      through which its administrators can be contacted; alternatively
      an equivalent "CNAME".

   2. An encoding of the public [RFC 1918] IP address - <IPv4address> or
      <IPv6address> [RFC 3986] - of that news-server. This option SHOULD
      NOT be used if an FQDN for that server is available (however, such
      IP addresses are perfectly suitable for purely diagnostic
      identities [reference needed to later section]).

   3. 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 server in
      question is not connected to the Internet), or unless it is of
      longstanding usage and cessation would be unduly disruptive[1], or
      unless one of the earlier options is provided as well.

        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
        therefore be unwise to choose, as such a name, anything composed
        solely from four (or less) hexadecimal digits.

   There are two circumstances when news-server administrators may need
   to be contacted by email:

   1. (injecting agents only)
      For sending complaints concerning the behavior of the poster of an
      article, the correct address is
      o If there is an Injection-Info header field with a "mail-
        complaints-to" <parameter>, then the address in that
        <parameter>; otherwise
      o "abuse@" followed by the <path-identity> in that Injection-Info
        field; or, in the absence of any Injection-Info field, the
        <path-identity> inserted by that agent in the Path header field
        (which, for an injecting agent, should be the one followed by
        the keyword "POSTED"). Evidently, that <path-identity> needs to
        be an FQDN for this to work.
      Injecting agent administrators SHOULD[2,3] ensure that a working
      email address is obtained by this process.

   2. (all agents)
      For reporting technical problems concerning the operation of a
      news-server, the correct address is either "news@" or "usenet@"
      followed by a <path-identity> obtained from an Injection-Info or
      Path header field as above.  Administrators SHOULD[4] ensure that
      a working email address is obtained from at least one of the<path-
      identity>s inserted by themselves[5].

        NOTE: The mechanisms set out above are broadly compatible with
        the provisions of [RFC 2142].
[Notes]

   [1]  Now that we are agreed to allow a single server to insert
        several <path-identity>s to identify itself, do we really still
        need to mention that "unduly disruprive business"? Richard?

   [2]  That used to be "MUST", but recently expressed opinions appear
        to favour "SHOULD".

   [3]  Do we want to relax the need for an abuse address at small
        private servers, or even at all servers not offering a public
        service?

   [4}  That used to be "ideally should" (which is weaker that RFC 2142
        - which was "must"). Do we want it as strong as "SHOULD"?
        Obviously, it will not work if all you have is a UUCP-style
        name.

   [5]  If the server inserts several identities (e.g. a chain of hosts
        in its farm) it would suffice for one working MX record
        (hopefully an obvious one) to be in the list. Or do we really
        want to insist that it creates an MX record to match every
        individual host?

   [6]  That still leaves open the precise syntax of <path-identity> and
        the like, and whether we are going to have words like ".SEEN" to
        indicate diagnostice ones.  However, that issue should be
        discussed under ticket #1047.


-- 
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 j71GG5kF061415 for <[e-mail]>; Mon, 1 Aug 2005 09:16:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71GG5uE061414 for ietf-usefor-skb; Mon, 1 Aug 2005 09:16:05 -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 j71GG4uX061407 for <[e-mail]>; Mon, 1 Aug 2005 09:16:05 -0700 (PDT) (envelope-from [e-mail])
Received: from host81-144-73-148.midband.mdip.bt.net ([81.144.73.148]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.190) id 42ee4ac1.493f.bb for [e-mail]; Mon,  1 Aug 2005 17:16:01 +0100 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j71GCDs15088 for [e-mail]; Mon, 1 Aug 2005 17:12:13 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:22183
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]> <[e-mail]> <[e-mail]>
Date: Mon, 1 Aug 2005 13:37:28 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]> Frank Ellermann <[e-mail]> writes:

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

Ah! I see the problem. We have:

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

and the ":" used as a separator can also appear in an IPv6address.

It is not actually ambiguous, but it is not tidy. We need a separator that
cannot occur in either a dot.atom (well, dot.atom.text maybe) or in an IP
address. That gives us:

    ( ) < > [ ] ; @ \ ,

none of which is really suitable. So maybe square brackets as you
suggested:

    posting-host = example.com
    posting-host = example.com[123.123.123.123]
    posting-host = example.com[beef:beef:beef:beef:....]
    posting-host = 123.123.123.123
    posting-host = [123.123.123.123]

probably make the [...] optional if there it no dot-atom[.text].

Or else we leave it (not-quite) ambiguous as it is.

Comments before I propose syntax?

-- 
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 j71G5qst060411 for <[e-mail]>; Mon, 1 Aug 2005 09:05:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71G5q9e060410 for ietf-usefor-skb; Mon, 1 Aug 2005 09:05: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 j71G5pmj060404 for <[e-mail]>; Mon, 1 Aug 2005 09:05:52 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 233393201A7 for <[e-mail]>; Mon,  1 Aug 2005 18:05: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 22627-01 for <[e-mail]>; Mon,  1 Aug 2005 18:05:45 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 217293201A9 for <[e-mail]>; Mon,  1 Aug 2005 18:05:45 +0200 (CEST)
Date: Mon, 01 Aug 2005 17:48:42 +0200
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: I'm back.... sorry about the absence
Message-ID: <2F7910EF340D59ECFFC79622@B50854F0A9192E8EC6CDA126>
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: by 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 was on another holiday trip last week, and returned home to find that my 
email server's OS disk had decided to call it a day.

Decent email service was only restored today (Monday) - and now I'm at the 
IETF meeting, which, despite my low level of formal responsibility, has the 
capacity for generating plenty of interrupts on my time.

I'll try to catch up and give reasonably coherent comments later - Alexey 
and I are meeting (physically) here in Paris on Wednesday.

                  Harald