Control: cancel ABNF bug

[Frank Ellermann <[e-mail]>]

Hi, there's apparently a subtle bug in the -06 ABNF.
We want (USEPRO 6.3):

      control-command     =/ Cancel-command
      Cancel-command      = "cancel" Cancel-arguments
      Cancel-arguments    = FWS msg-id [FWS]

That's your  msg-id = "<" id-left "@" id-right ">"
(same as my  msg-id = "<" id-unique "@" id-domain ">" ).

But USEFOR and 2045 (with Ned's pending erratum) say:

      control-command =  verb *( [FWS] argument )
      verb            =  token
      argument        =  value

      value := token / quoted-string
      token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                  or tspecials>
      tspecials :=  "(" / ")" / "<" / ">" / "@" /
                    "," / ";" / ":" / "\" / <"> /
                    "/" / "[" / "]" / "?" / "="
                    ; Must be in quoted-string,
                    ; to use within parameter values

In other words Control: cancel <whatever@example> is not
allowed, and we certainly don't want to quote a <msg-id>:

               Control: cancel "<whatever@example>"

Substituting <word> for <value> has the same problem.
1*utext also can't solve it, we don't want NO-WS-CTL.
Taking 1*VCHAR should do the trick, for section 1.4:

      VCHAR           =  <see RFC 4234 appendix B.1>

For section 3.2.5 (changing only its <argument>):

      control-command =  verb *( [FWS] argument )
      verb            =  token
      argument        =  1*VCHAR

Or directly  argument = 1*(%x21-7E)  without the VCHAR.

                        Bye, Frank

P.S.:  why on earth do they need more than 10 months to
publish an erratum submitted by one of the 2045 authors ?






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k010pb54070394; Sat, 31 Dec 2005 16:51:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k010pbS0070393; Sat, 31 Dec 2005 16:51:37 -0800 (PST)
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 k010pZ25070382 for <[e-mail]>; Sat, 31 Dec 2005 16:51:36 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EsrRc-0002Fl-Vb for [e-mail]; Sun, 01 Jan 2006 01:51:32 +0100
Received: from 1cust5.tnt7.hbg2.deu.da.uu.net ([149.225.100.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 01 Jan 2006 01:51:32 +0100
Received: from nobody by 1cust5.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 01 Jan 2006 01:51:32 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Control: cancel ABNF bug
Date:  Sun, 01 Jan 2006 01:44:59 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 49
Message-ID:  <[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: 1cust5.tnt7.hbg2.deu.da.uu.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>

Hi, there's apparently a subtle bug in the -06 ABNF.
We want (USEPRO 6.3):

      control-command     =/ Cancel-command
      Cancel-command      = "cancel" Cancel-arguments
      Cancel-arguments    = FWS msg-id [FWS]

That's your  msg-id = "<" id-left "@" id-right ">"
(same as my  msg-id = "<" id-unique "@" id-domain ">" ).

But USEFOR and 2045 (with Ned's pending erratum) say:

      control-command =  verb *( [FWS] argument )
      verb            =  token
      argument        =  value

      value := token / quoted-string
      token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                  or tspecials>
      tspecials :=  "(" / ")" / "<" / ">" / "@" /
                    "," / ";" / ":" / "\" / <"> /
                    "/" / "[" / "]" / "?" / "="
                    ; Must be in quoted-string,
                    ; to use within parameter values

In other words Control: cancel <whatever@example> is not
allowed, and we certainly don't want to quote a <msg-id>:

               Control: cancel "<whatever@example>"

Substituting <word> for <value> has the same problem.
1*utext also can't solve it, we don't want NO-WS-CTL.
Taking 1*VCHAR should do the trick, for section 1.4:

      VCHAR           =  <see RFC 4234 appendix B.1>

For section 3.2.5 (changing only its <argument>):

      control-command =  verb *( [FWS] argument )
      verb            =  token
      argument        =  1*VCHAR

Or directly  argument = 1*(%x21-7E)  without the VCHAR.

                        Bye, Frank

P.S.:  why on earth do they need more than 10 months to
publish an erratum submitted by one of the 2045 authors ?




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBVNMol7063606; Sat, 31 Dec 2005 15:22:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBVNMoZH063605; Sat, 31 Dec 2005 15:22:50 -0800 (PST)
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 jBVNMmsk063598 for <[e-mail]>; Sat, 31 Dec 2005 15:22:49 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Esq3g-0005se-IF for [e-mail]; Sun, 01 Jan 2006 00:22:44 +0100
Received: from 1cust5.tnt7.hbg2.deu.da.uu.net ([149.225.100.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 01 Jan 2006 00:22:44 +0100
Received: from nobody by 1cust5.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sun, 01 Jan 2006 00:22:44 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  artwork
Date:  Sun, 01 Jan 2006 00:21:17 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 96
Message-ID:  <[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: 1cust5.tnt7.hbg2.deu.da.uu.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>

Hi, nobody said that a collection of ABNF-prose is a bad idea.

So I guess that we want this for the point "Collected ABNF?"
in the remaining five "Issues to be Addressed" as stated on
http://tools.ietf.org/html/draft-ietf-usefor-usefor-06#page-5

This replaces the 2nd and 3rd of three paragraphs in section 1.4
after adding 2231 and 3986 references to the first paragraph:

=  Header fields defined in this specification use the Augmented Backus-
=  Naur Form (ABNF) notation (including the Core Rules) specified in
-  [RFC2234] and many constructs defined in [RFC2822] and [RFC2045].
+  [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as
+  amended by [RFC2231], and [RFC3986].
=  Section 3.1.3 updates the [RFC2822] definition of <msg-id>.

The new second and last paragraph in section 1.4 will be the ABNF,
using the same xml2rfc "artwork" style as for all later ABNF lines:

~~~ cut ~~~
token           =  <see RFC 2045 section 5.1>
value           =  <see RFC 2045 section 5.1>
parameter       =  <see RFC 2231 section 7>
attribute       =  <see RFC 2231 section 7>

FWS             =  <see RFC 2822 section 3.2.3>
CFWS            =  <see RFC 2822 section 3.2.3>
atext           =  <see RFC 2822 section 3.2.4>
dot-atom-text   =  <see RFC 2822 section 3.2.4>
phrase          =  <see RFC 2822 section 3.2.6>
utext           =  <see RFC 2822 section 3.2.6>
date-time       =  <see RFC 2822 section 3.3>
mailbox         =  <see RFC 2822 section 3.4>
mailbox-list    =  <see RFC 2822 section 3.4>
address-list    =  <see RFC 2822 section 3.4>
fields          =  <see RFC 2822 section 3.6>

IPv6address     =  <see RFC 3986 section 3.2.2>
IPv4address     =  <see RFC 3986 section 3.2.2>

ALPHA           =  <see RFC 4234 appendix B.1>
CRLF            =  <see RFC 4234 appendix B.1>
DIGIT           =  <see RFC 4234 appendix B.1>
DQUOTE          =  <see RFC 4234 appendix B.1>
SP              =  <see RFC 4234 appendix B.1>
~~~ end ~~~

That's all, I checked it in conjuction with our -06 ABNF using
Bill's ABNF parser.  We don't have any <attribute> in the ABNF,
but use <attribute> in the prose, therefore I've added it here.

                    A happy 2006 to USEFOR...










































...or rather a happy year 8 "ab USEFOR condita" ;-)




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBU4Z3Ca050468; Thu, 29 Dec 2005 20:35:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBU4Z35N050467; Thu, 29 Dec 2005 20:35:03 -0800 (PST)
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 jBU4Z1P6050448 for <[e-mail]>; Thu, 29 Dec 2005 20:35:02 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EsByl-0003bc-J1 for [e-mail]; Fri, 30 Dec 2005 05:34:59 +0100
Received: from 1cust31.tnt2.hbg2.deu.da.uu.net ([149.225.12.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 30 Dec 2005 05:34:59 +0100
Received: from nobody by 1cust31.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 30 Dec 2005 05:34:59 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: ABNF
Date:  Fri, 30 Dec 2005 05:33:35 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 40
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: 1cust31.tnt2.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> if you look at draft-ietf-usefor-article-13, you will see
> that is exactly what was done (non-normatively, of course),

Yes, I liked that, but a later consensus (?) was to drop it.

> At the other extreme, a simple list of the rules 'borrowed'
> from other documents. And there are many possible stages in
> between.

Let's pick the ABNF-prose imports, otherwise Bill would need
hours to check our ABNF.

 <host-value> 
> The syntax using the ":" was taken from the presently used
> NNTP-Posting-Host header, which <host-value> is intended to
> replace.

Okay.  But note that colon is a 2045 <tspecial>, so there will
a major difference for "FQDN or IPv4 only" vs. "FQDN:IPv4", in
the latter case the <host-value> MUST be in a <quoted-string>.

With square brackets for all IP literals (as in 2821) or at the
very minimum for IPv6 and beyond (as in STD 66) we could avoid
all potential IPv6 trouble:

| IP-literal  = "[" ( IPv4address / IPv6address ) "]"
|
| host-value  = dot-atom-text / IP-literal /
|               ( dot-atom-text IP-literal )

If you (collective you) don't like this we should at least use
grouping notation as recommended in 4234 3.5:

| host-value = dot-atom-text / IPv4address / IPv6address /
|              ( dot-atom-text ":" ( IPv4address / IPv6address ))

The latter is equivalent with <host-value> in draft -06.  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 jBU43IMl045603; Thu, 29 Dec 2005 20:03:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBU43IWS045602; Thu, 29 Dec 2005 20:03:18 -0800 (PST)
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 jBU43H4b045595 for <[e-mail]>; Thu, 29 Dec 2005 20:03:17 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EsBTw-0003xY-CO for [e-mail]; Fri, 30 Dec 2005 05:03:08 +0100
Received: from 1cust31.tnt2.hbg2.deu.da.uu.net ([149.225.12.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 30 Dec 2005 05:03:08 +0100
Received: from nobody by 1cust31.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 30 Dec 2005 05:03:08 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: IANA considerations
Date:  Fri, 30 Dec 2005 05:02:07 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 42
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 1cust31.tnt2.hbg2.deu.da.uu.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:

> You are mixing a whole bunch of separate issues there.

Indeed.  I prefer to have a limited list of attack vectors in
the "IETF last call", in essence Message-ID and our "magic SP".

> If a header is widely used across several protocols, then it
> is sensible to define it in one place (unless some
> controversy arises), and the IANA registry then mentions that
> one place for both protocols. So the machinery is there -
> the question is whether to use it.

If the 2822 folks wish to adopt our User-Agent as is, even with
our weird "magic SP", they can do it.  In theory you could also
register it directly for mail (without 2822bis), just post the
registration form on the msghdr list, wait two weeks, and then
IANA is obliged to add it to the registry (AFAIK - only Martin
tested it for a provisional Archived-At registration).

> he still intends to publish S-o-1036 as an infomational/
> whatever RFC, so on the strength of that, I think we can now
> remove the historic appendices from both USEFOR and USEPRO,
> and possibly simplify the section that declares some things
> 'obsolete'.

Good news.  Let Henry finish off these three pre-1036 header
fields in his "IANA considerations".  We can then focus on our
header fields (incl. two NNTP-* replaced by two Injection-*):

>>Maybe "obsoleted" is the correct value for NNTP-Posting-* (?)
 
> Could be. Or we are allowed to invent new words if really
> necessary.

Apparently we are, but for NNTP-* "obsoleted" is fine, and for
the four s-o-1036 header fields "historic" is okay.  For Lines:
"standard" or "deprecated" or "obsolescent" will do, and that's
then at least consistent with our own usage of "obsoleted" and
"historic" for different purposes.
                                  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 jBU3XaUU040983; Thu, 29 Dec 2005 19:33:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBU3Xaoq040982; Thu, 29 Dec 2005 19:33:36 -0800 (PST)
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 jBU3XYkV040975 for <[e-mail]>; Thu, 29 Dec 2005 19:33:35 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EsB1F-0004u7-05 for [e-mail]; Fri, 30 Dec 2005 04:33:29 +0100
Received: from 1cust31.tnt2.hbg2.deu.da.uu.net ([149.225.12.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 30 Dec 2005 04:33:28 +0100
Received: from nobody by 1cust31.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 30 Dec 2005 04:33:28 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: IANA considerations
Date:  Fri, 30 Dec 2005 04:27:40 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <CA4640EE41B1F3E153B07D27@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: 1cust31.tnt2.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> We are really up against the problem that the IETF machinery
> does not seem to cope well with the case where a Standard
> has been superseded by a Proposed Standard (and everybody
> agrees that the old one is to be considered dead), but nobody
> has gotten around to moving the new standard along the track.

For 2821, a PS broken by design (= essentially a DDoS machine),
the fatal design flaw was already a part of STD 3 (1123).  And
"everybody agrees with 1123 5.3.6a" would be utter dubious, but
I digress.

I don't see anything of this issue here, the status of 1036 is
"unknown", not "standard".  S-o-1036 would be "historic", and
draft-ietf-usefor-usefor will be the only game in town (as PS)
for the NetNews article format.

The new header field registry offers "standard" for anything on
standards track (and even for wannabe-standards published by
other SDOs like ISO, W3C, Unicode, ECMA, etc., roll-your-own).

Apparently it also allows "obsolescent" or "deprecated" for
our case "Lines:".  IMO good enough, the draft uses precisely
these adjectives in 3.3.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 jBT3EtaN084929; Wed, 28 Dec 2005 19:14:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBT3EtFR084928; Wed, 28 Dec 2005 19:14:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBT3EsMk084914 for <[e-mail]>; Wed, 28 Dec 2005 19:14:54 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-65-43.midband.mdip.bt.net ([81.144.65.43]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43b354ad.50ba.10 for [e-mail]; Thu, 29 Dec 2005 03:14:53 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBT3CAh17464 for [e-mail]; Thu, 29 Dec 2005 03:12:10 GMT
To: [e-mail]
Xref: clerew local.usefor:22805
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: IANA considerations
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <4E1927EA4BCAE0EFDB80BE29@B50854F0A9192E8EC6CDA126>
Date: Wed, 28 Dec 2005 19:41:11 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 <4E1927EA4BCAE0EFDB80BE29@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>Grumble. The HTTP and Mail documents both give full templates per header,=20
>and as you say, this makes for a very long document (easy to produce, just=20
>tedious). I like the idea of not making -usefor depend on this.

Well looking at the registries IANA have actually constructed
(http://www.iana.org/assignments/message-headers/perm-headers.html and
http://www.iana.org/assignments/message-headers/prov-headers.html), they
have only taken the bare bones of those documents - essentially what Ken's
table proposed), so I think that is all we are obliged to provide. In
fact, they haven't even included the 'Status' and 'Author/Change
controller' fields at all, which I find odd. And for sure, if we want any
"related information" to be attached to some header, we will need to say
so explicitly in out IANA Considerations.

>The issue of documenting obsoleted headers is problematic. We can (in=20
>theory) argue that the sentences referring to them as "obsoleted" in=20
>usefor-usefor is enough definition for an obsoleted header. It would be=20
>more proper to have son-of-1036 as the reference - but that introduces a=20
>dependency, which is bad.

I would say that if we declare the Foo-Bar header to be "obsolete", then
the document which delcares it obsolete is the primary reference that is
needed. A secondary reference to any document that might have defined it
previously would be a sensible addition, if such exists, but I would
suppose that would be of the nature of an "informative" reference, and as
such need not create a dpendency. In any case, I presume we are going to
have an informative reference to S-o-1036 in lieu of those Historical
Appendices,

-- 
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 jBT3Esk2084921; Wed, 28 Dec 2005 19:14:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBT3EsiF084920; Wed, 28 Dec 2005 19:14:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBT3Eruw084911 for <[e-mail]>; Wed, 28 Dec 2005 19:14:54 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-65-43.midband.mdip.bt.net ([81.144.65.43]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43b354ac.50ba.f for [e-mail]; Thu, 29 Dec 2005 03:14:52 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBT3CB017472 for [e-mail]; Thu, 29 Dec 2005 03:12:11 GMT
To: [e-mail]
Xref: clerew local.usefor:22806
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: IANA considerations
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <CA4640EE41B1F3E153B07D27@B50854F0A9192E8EC6CDA126>
Date: Wed, 28 Dec 2005 19:45:38 GMT
Lines: 23
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <CA4640EE41B1F3E153B07D27@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>Seems to be a field where syntax checking is not going to be terribly=20
>strict.... if a field was defined in 822 and deprecated in 2822, I suppose=20
>the correct status would be "standard-but-obsoleted"......

For which you could use the word "obsolescent". However, that might
require some explanation. We are really up against the problem that the
IETF machinery does not seem to cope well with the case where a Standard
has been superseded by a Proposed Standard (and everybody agrees that the
old one is to be considered dead), but nobody has gotten around to moving the
new standard along the track.

-- 
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 jBSJDe7t033080; Wed, 28 Dec 2005 11:13:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBSJDeqx033078; Wed, 28 Dec 2005 11:13:40 -0800 (PST)
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 jBSJDcZ6033065 for <[e-mail]>; Wed, 28 Dec 2005 11:13:39 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-112.midband.mdip.bt.net ([81.144.66.112]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43b2e3e1.ba4c.b9 for [e-mail]; Wed, 28 Dec 2005 19:13:37 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBSJCHM14409 for [e-mail]; Wed, 28 Dec 2005 19:12:17 GMT
To: [e-mail]
Xref: clerew local.usefor:22803
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 - Path header (was toplabel...)
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]>  <[e-mail]>  <[e-mail]> <7684C8CF917DC078E129BA27@B50854F0A9192E8EC6CDA126>
Date: Wed, 28 Dec 2005 18:14:14 GMT
Lines: 71
Sender: [e-mail]
Precedence: 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 <7684C8CF917DC078E129BA27@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[e-mail]> writes:

>--On 21. desember 2005 16:55 +0000 Charles Lindsey <[e-mail]>=20
>wrote:

>> Then you need to say "It usually takes the form of a fully qualified
>> domain name ...", and/or make some mention of barewords.

>Did you miss my point?

>"The form of a domain name having one or more components" subsumes the form =

>of a domain name having one component - "foobar" is just as much in "the=20
>form of a domain name" as "clerew.man.ac.uk" is - it is just not a FULLY=20
>QUALIFIED domain name, in the way the term is usually used.

>Putting in "usually" would mean that you couldn't tell for sure whether=20
>non-domain-name constructs like "1...." or "really....silly" were allowed=20
>as "path-identity". (The grammar does not disallow them.)

>That said, there may be good reason for mentioning the case of "bareword" - =

>it's an important case for being consistent with existing practice.
>If so, propose text.

Well it all depends on how much you want to say here, and how much in
USEPRO. And also on precisely what you want to disallow/discourage.

So I would start from

   A <path-identity> is a name identifying a site.  It usually takes the
   form of a fully qualified domain name or a "bareword".

That is brief, but requires some definition of "bareword". If it is
understood (whether by writing ABNF or otherwise) that it has no "."s in
it, then it is clear that funnies like "really....silly" would be at best
'unusual' (even if syntactically permitted) and you could leave it to
USEPRO to draw the rules tighter (with MUST/SHOULD/MAY/whatever as we may
decide). Alternatively, you could wrap up the whole thing in ABNF (which,
at one extreme, would lead to a syntax such as I have proposed).

However, I would suggest that there are two more pressing things to decide
first:

1. The remarks in the present draft regarding the "dead:beef" matter are
just wrong. I think we are agreed that we don't want to see ':'s anywhere
except in IPv6addresses, and then only in diagnostics/whatever. But do we
want to make that prohibition clear here in USEFOR (which would certainly
need some ABNF), or do we want to do it as part of some "rule tightening"
in USEPRO?

2. How many and which keywords do we want to introduce here? Which is
related to the question of whether we want some way to distinguish
diagnostics from sites (for which a keyword such as "SEEN" would apprear
to be needed). So either we need to define the keywords here in USEFOR, or
else we regard them as "funny kinds of barwords" and give
instructions/conventions for inserting them in USEPRO. To my mind, it
would be much better to try and decide which instructions/conventions we
are aiming towards now, rather than fix the format of USEFOR before we are
quite sure where we are aiming.

-- 
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 jBSJDeOK033079; Wed, 28 Dec 2005 11:13:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBSJDevI033077; Wed, 28 Dec 2005 11:13:40 -0800 (PST)
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 jBSJDcL1033063 for <[e-mail]>; Wed, 28 Dec 2005 11:13:39 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-112.midband.mdip.bt.net ([81.144.66.112]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43b2e3e0.ba4c.b8 for [e-mail]; Wed, 28 Dec 2005 19:13:36 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBSJCJK14417 for [e-mail]; Wed, 28 Dec 2005 19:12:19 GMT
To: [e-mail]
Xref: clerew local.usefor:22804
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ABNF
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 28 Dec 2005 19:10:24 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]> Frank Ellermann <[e-mail]> writes:

>Ken Murchison wrote:
> 
>> Both issues fixed.

>Thanks.  I think we should add an "import interface" for all 21
>terms defined elsewhere.  We use five sources 2045, 2231, 2822,
>3986, and 4234, and the 2231 terms are redefinitions of 2045.

I am all for giving the hard-pressed reader as much help as possible.
There are many ways one might do this. At one extreme, one could include
all the cited rules from all the documents referred to as part of the
"collected syntax" appendix. Indeed, if you look at
draft-ietf-usefor-article-13, you will see that is exactly what was done
(non-normatively, of course), complete with a notation to show which RFC
each rule had been taken from, and whether it had been changed/adapted
from its original. At the other extreme, a simple list of the rules
'borrowed' from other documents. And there are many possible stages in
between.


>| host-value  =  dot-atom-text 
>|                [ ":" ( IPv4address / IPv6address ) ]

>We discussed to replace ":" by a "better" separator, but I
>forgot the details.  Could we use "[" ( IPv4 / IPv6 ) "]" ?

The syntax using the ":" was taken from the presently used
NNTP-Posting-Host header, which <host-value> is intended to replace.

-- 
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 jBSDC4sq091990; Wed, 28 Dec 2005 05:12:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBSDC4MM091989; Wed, 28 Dec 2005 05:12:04 -0800 (PST)
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 jBSDC2f7091982 for <[e-mail]>; Wed, 28 Dec 2005 05:12:03 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-67-244.midband.mdip.bt.net ([81.144.67.244]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43b28f20.7d8b.1a for [e-mail]; Wed, 28 Dec 2005 13:12:00 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBO3CBm22303 for [e-mail]; Sat, 24 Dec 2005 03:12:11 GMT
To: [e-mail]
Xref: clerew local.usefor:22795
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: IANA considerations
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 23 Dec 2005 13:03:17 GMT
Lines: 83
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

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

>Charles Lindsey wrote:

>> We also need to consider whether User-Agent should also apply
>> to the protocol "email". It was designed with that intent
>> and our draft says so

>Easy for 2822bis to adopt this if they like it...

>> Probably we should check with IESG whether they would be
>> willing for us to do this, since it would stretch our charter
>> somewhat.

>...that's a good reason to stay away from it.  They could be
>tempted to ask us why it took us six years to figure out the
>Message-ID, and why we want to screw up mail before the Path-
>syntax is 100% clear.

Eh? You are mixing a whole bunch of separate issues there. If a header is
widely used across several protocols, then it is sensible to define it in
one place (unless some controversy arises), and the IANA registry then
mentions that one place for both protocols. So the machinery is there -
the question is whether to use it. Anyway, I think we need to hear Harald
on this one.

>>    NNTP-Posting-Host netnews deprecated IETF
>>    NNTP-Posting-Date netnews deprecated IETF
>>    Also-Control netnews obsoleted IETF
>>    See-Also netnews obsoleted IETF
>>    Article-Names netnews obsoleted IETF
>>    Article-Updates netnews obsoleted IETF

>What about Relay-Version / Posted-Version / Date-Received ?
>Apparently they are only mentioned (already as obsolete) in
>appendix A.3 of s-o-1036, but not in 1036.

Yes, they could usefully be mentioned. The only difference is that the
first four were actually proposed for current use in S-o-1036, whereas the
last three were already dead and buried by then (so perhaps 'Historic' is
the word to use). But S-o-1036 is still a good reference for what they
used to be like.

BTW, I have now heard back from Henry Spencer. Seems he lost his email
connection through a massive cockup by his ISP. Yes, he still intends to
publish S-o-1036 as an infomational/whatever RFC, so on the strength of
that, I think we can now remove the historic appendices from both USEFOR
and USEPRO, and possibly simplify the section that declares some things
'obsolete'. We should then refer to S-o-1036 in a suitable place.

As for the two NNTP-POSTING-* ones, I see benefit in mentioning them, and
the lack of formal definition need be no bar. "Long established custom"
should be good enough if you don't want to mention the source code of INN.

There are also some other headers with "Long standing custom" usage (such
as Mail-Copies-To) but their future is still in the balance (we did not
include them, but we did not bar them from future work).


> [NNTP-Posting-*]
>> I think it would still be proper to describe IETF as the
>> "Change Controller" (but not as Author, obviously).

>We grabbed them and deprecate them in a not-yet IETF PS, so
>that's "Change Controller: IETF" as per the 3864 rules...

Indeed,


>Maybe "obsoleted" is the correct value for NNTP-Posting-* (?)

Could be. Or we are allowed to invent new words if really necessary.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBQ3ULGn001254; Sun, 25 Dec 2005 19:30:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBQ3ULaU001253; Sun, 25 Dec 2005 19:30:21 -0800 (PST)
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 jBQ3UKhV001245 for <[e-mail]>; Sun, 25 Dec 2005 19:30:20 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 388D32596BA; Mon, 26 Dec 2005 04:29:28 +0100 (CET)
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 30802-08; Mon, 26 Dec 2005 04:29:23 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5B3F2580D1; Mon, 26 Dec 2005 04:29:22 +0100 (CET)
Date: Mon, 26 Dec 2005 04:26:37 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1047 - Path header (was toplabel...)
Message-ID: <7684C8CF917DC078E129BA27@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[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]>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1F503801E372CB1D9EA3=========="
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>

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



--On 21. desember 2005 16:55 +0000 Charles Lindsey <[e-mail]>=20
wrote:

>>>>   A <path-identity> is a name identifying a site.  It takes the form =
of
>>>>   a domain name having one or more components separated by dots.
>>>
>>> That makes no allowance for barewords (whether we formally define that
>>> term or not). "It _usually_ takes the form of a domain name ..." would
>>> be OK, because any gory details could then be left to USEPRO.
>
>> Try telling the difference between a domain name having one component
>> and a  bareword.
>
> Then you need to say "It usually takes the form of a fully qualified
> domain name ...", and/or make some mention of barewords.

Did you miss my point?

"The form of a domain name having one or more components" subsumes the form =

of a domain name having one component - "foobar" is just as much in "the=20
form of a domain name" as "clerew.man.ac.uk" is - it is just not a FULLY=20
QUALIFIED domain name, in the way the term is usually used.

Putting in "usually" would mean that you couldn't tell for sure whether=20
non-domain-name constructs like "1...." or "really....silly" were allowed=20
as "path-identity". (The grammar does not disallow them.)

That said, there may be good reason for mentioning the case of "bareword" - =

it's an important case for being consistent with existing practice.
If so, propose text.

                         Harald




--==========1F503801E372CB1D9EA3==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iD8DBQFDr2LtOMj+2+WY0F4RAkkBAJ0a9BzIi2XAudC9tFovRDioNGtD0QCggmfD
Gw6zGdpyLU0WOG/nhoiIDjc=
=zWQd
-----END PGP SIGNATURE-----

--==========1F503801E372CB1D9EA3==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBQ2n1ti096385; Sun, 25 Dec 2005 18:49:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBQ2n1QN096384; Sun, 25 Dec 2005 18:49:01 -0800 (PST)
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 jBQ2mv9j096363 for <[e-mail]>; Sun, 25 Dec 2005 18:48:57 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 768D02596FB; Mon, 26 Dec 2005 03:48:05 +0100 (CET)
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 25730-05; Mon, 26 Dec 2005 03:47:59 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF5CB2596FE; Mon, 26 Dec 2005 03:47:54 +0100 (CET)
Date: Mon, 26 Dec 2005 03:24:12 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: IANA considerations
Message-ID: <05B075A37FAF445BE051DD77@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========7858000A4ABFDCF93D07=========="
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>

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



--On 22. desember 2005 12:12 +0000 Charles Lindsey <[e-mail]>=20
wrote:

>> 6.  IANA Considerations
>
>
>>       NOTE: For each of the registered header fields, the Applicable
>>       protocol is "netnews" and the Author/Change controller is "IETF".
>
> We also need to consider whether User-Agent should also apply to the
> protocol "email". It was designed with that intent, and our draft says so
> (indeed, it would also have been identical to the HTTP protocol version,
> but for some differences in the lexical conventions of HTTP). It is used
> as much in email as in Netnews (though syntax varies somewhat on both,
> because it has not been written down before, except in the HTTP
> standards).
>
> Probably we should check with IESG whether they would be willing for us =
to
> do this, since it would stretch our charter somewhat. OTOH, I doubt =
anyone
> is going to bother to do an ID for the same header in email jusr =
repeating
> our syntax.
>
> The same thing might apply to the Organization header, which is widely
> used in email.

After the snafu over the Newsgroups: headers.... No, we won't do that.



--==========7858000A4ABFDCF93D07==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iD8DBQFDr1RMOMj+2+WY0F4RAjRxAJ4oLxnQnOEUXazlM9Ku/JaKy/NI7gCfTxGY
SDSkkVXLfMOJY+7We4xfv2k=
=wkGy
-----END PGP SIGNATURE-----

--==========7858000A4ABFDCF93D07==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBQ2n0gs096378; Sun, 25 Dec 2005 18:49:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBQ2n0lr096377; Sun, 25 Dec 2005 18:49:00 -0800 (PST)
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 jBQ2mxa8096369 for <[e-mail]>; Sun, 25 Dec 2005 18:48:59 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 347AE2596FB; Mon, 26 Dec 2005 03:48:07 +0100 (CET)
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 26079-01; Mon, 26 Dec 2005 03:47:59 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FFC72596FD; Mon, 26 Dec 2005 03:47:54 +0100 (CET)
Date: Mon, 26 Dec 2005 03:22:19 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: IANA considerations
Message-ID: <CA4640EE41B1F3E153B07D27@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========13D3F8B4B37C3B4D46EA=========="
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>

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



--On 22. desember 2005 06:08 +0100 Frank Ellermann=20
<[e-mail]> wrote:

>
> Ken Murchison wrote:
>
>> | Lines          | obsoleted | This document (Section 3.3.1)        |
>
> AFAIK there's no status "obsoleted" in 3864.  You could only
> mention this in the comment of a complete registration form.

3864 section 4.2.1:

   Status:
      Specify "standard", "experimental", "informational", "historic",
      "obsoleted", or some other appropriate value according to the type
      and status of the primary document in which it is defined.  For
      non-IETF specifications, those formally approved by other
      standards bodies should be labelled as "standard"; others may be
      "informational" or "deprecated" depending on the reason for
      registration.

Seems to be a field where syntax checking is not going to be terribly=20
strict.... if a field was defined in 822 and deprecated in 2822, I suppose=20
the correct status would be "standard-but-obsoleted"......





--==========13D3F8B4B37C3B4D46EA==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iD8DBQFDr1PcOMj+2+WY0F4RAjTaAKDW35itBO+Y9tWJXsww04Q2GPlolgCgvKGD
TrUWfZbqtgcuUO+9o66T744=
=Jsv5
-----END PGP SIGNATURE-----

--==========13D3F8B4B37C3B4D46EA==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBQ2mrDg096357; Sun, 25 Dec 2005 18:48:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBQ2mr64096356; Sun, 25 Dec 2005 18:48:53 -0800 (PST)
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 jBQ2mprL096348 for <[e-mail]>; Sun, 25 Dec 2005 18:48:52 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 410F1259704; Mon, 26 Dec 2005 03:47:59 +0100 (CET)
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 25538-10; Mon, 26 Dec 2005 03:47:54 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 782412596FC; Mon, 26 Dec 2005 03:47:53 +0100 (CET)
Date: Mon, 26 Dec 2005 03:14:47 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Ken Murchison <[e-mail]>, [e-mail]
Subject: Re: IANA considerations
Message-ID: <4E1927EA4BCAE0EFDB80BE29@B50854F0A9192E8EC6CDA126>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========02BE2954ACB18CDA98B0=========="
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>

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



--On 22. desember 2005 08:17 -0500 Ken Murchison <[e-mail]>=20
wrote:

>>    NNTP-Posting-Date netnews deprecated IETF
>>    Also-Control netnews obsoleted IETF
>>    See-Also netnews obsoleted IETF
>>    Article-Names netnews obsoleted IETF
>>    Article-Updates netnews obsoleted IETF
>>
>> A proper reference for the last 4 would be Son-of-1036, which we propose
>> to refer to in any case. The 1st two have no published definition that I
>> know of apart from the source code of INN. However, they are both much
>> used, and we have explicitly deprecated their continued use in USEFOR. I
>> think it would still be proper to describe IETF as the "Change
>> Controller" (but not as Author, obviously).
>
> If s-o-1036 actually defines a header, then I think we can probably
> register it.  If there is no definition anywhere that we can reference,
> then how can we register it?  I certainly don't want to add ABNF to our
> doc for headers that are dead.
>
> Harald, any thoughts?

Grumble. The HTTP and Mail documents both give full templates per header,=20
and as you say, this makes for a very long document (easy to produce, just=20
tedious). I like the idea of not making -usefor depend on this.

The issue of documenting obsoleted headers is problematic. We can (in=20
theory) argue that the sentences referring to them as "obsoleted" in=20
usefor-usefor is enough definition for an obsoleted header. It would be=20
more proper to have son-of-1036 as the reference - but that introduces a=20
dependency, which is bad.

More opinions?


--==========02BE2954ACB18CDA98B0==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iD8DBQFDr1IYOMj+2+WY0F4RAv5lAJ0VMSHHzdsS0v6dQ3NSJ5wHV4jlsgCeN3zb
wQtk5c/SsLndcp2FESGNzDg=
=7fHY
-----END PGP SIGNATURE-----

--==========02BE2954ACB18CDA98B0==========--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBNAnuHJ046944; Fri, 23 Dec 2005 02:49:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBNAnulf046943; Fri, 23 Dec 2005 02:49:56 -0800 (PST)
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 jBNAntKD046936 for <[e-mail]>; Fri, 23 Dec 2005 02:49:56 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EpkUb-0004Rn-5H for [e-mail]; Fri, 23 Dec 2005 11:49:45 +0100
Received: from pd9fba8d5.dip0.t-ipconnect.de ([217.251.168.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 23 Dec 2005 11:49:45 +0100
Received: from nobody by pd9fba8d5.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 23 Dec 2005 11:49:45 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  host-value (was: ABNF)
Date:  Fri, 23 Dec 2005 11:46:58 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
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: pd9fba8d5.dip0.t-ipconnect.de
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>

> | host-value  =  dot-atom-text
> |                [ ":" ( IPv4address / IPv6address ) ]

No, that's not the same before, sorry.  Next attempt:

| host-value  =  dot-atom-text
|             / ( [ dot-atom-tet ":" ]
|                 ( IPv4address / IPv6address ))

Won't win us a price for beautiful ABNF.  Third atempt:

| host-value  = dot-atom-text / IPv4address / IPv6address /
|               ( dot-atom-text ":" ( IPv4address / IPv6address ))

That's somewhat clearer.  If the ":" is a problem we could
try something completely different:

| IP-literal  = "[" ( IPv4address / IPv6address ) "]"
|
| host-value  = dot-atom-text / IP-literal /
|               ( dot-atom-text IP-literal )

That's not bad, or is it ?  Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBNAPTod044337; Fri, 23 Dec 2005 02:25:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBNAPTov044336; Fri, 23 Dec 2005 02:25:29 -0800 (PST)
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 jBNAPRrV044328 for <[e-mail]>; Fri, 23 Dec 2005 02:25:28 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Epk74-0005gw-Av for [e-mail]; Fri, 23 Dec 2005 11:25:26 +0100
Received: from pd9fba8d5.dip0.t-ipconnect.de ([217.251.168.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 23 Dec 2005 11:25:26 +0100
Received: from nobody by pd9fba8d5.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 23 Dec 2005 11:25:26 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: ABNF
Date:  Fri, 23 Dec 2005 11:23:42 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 43
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: pd9fba8d5.dip0.t-ipconnect.de
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>

Ken Murchison wrote:
 
> Both issues fixed.

Thanks.  I think we should add an "import interface" for all 21
terms defined elsewhere.  We use five sources 2045, 2231, 2822,
3986, and 4234, and the 2231 terms are redefinitions of 2045.

Readers would be hard pressed to merge these sources with our
ABNF to get something that's valid.  We could offer the source
(plus section) by 21 ABNF lines like (unverified examples):

               CRLF     = <see RFC 4234 section 2  > 
               token    = <see RFC 2231 section 2  >
               fields   = <see RFC 2822 section 3.6>

Grouped by RFC number this should help, not only for Bill's
validator.

--- host-value ---

I've seen another minor problem in the ABNF (in addition to
<article-locator> )

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

Alternatives without grouping are discouraged in 4234.  To fix
that you could say:

| host-value  =  dot-atom-text 
|                [ ":" ( IPv4address / IPv6address ) ]

We discussed to replace ":" by a "better" separator, but I
forgot the details.  Could we use "[" ( IPv4 / IPv6 ) "]" ?

--- Lines ---

Bill's validator proposes "Lines:" instead of "Lines" ":", and
that's also the style already used for all other header fields.

                              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 jBNACWpG043218; Fri, 23 Dec 2005 02:12:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBNACWYE043217; Fri, 23 Dec 2005 02:12:32 -0800 (PST)
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 jBNACU6E043203 for <[e-mail]>; Fri, 23 Dec 2005 02:12:31 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6657E259720; Fri, 23 Dec 2005 11:11:39 +0100 (CET)
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 10891-08; Fri, 23 Dec 2005 11:11:36 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1401259719; Fri, 23 Dec 2005 11:11:35 +0100 (CET)
Date: Fri, 23 Dec 2005 11:15:14 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: ABNF
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 torsdag, desember 22, 2005 16:35:34 +0100 Frank Ellermann 
<[e-mail]> wrote:

>
> Hi, I tried to validate the ABNF:
>
>| injection-info  =  "Injection-Info:" SP [CFWS] path-identity
>|                    [CFWS] *(';' parameter) CRLF
>
> s/';'/";"/
>
> Bill's parser accepts fields =/ etc.  I just added anything
> from 2822 we need not redefined by us on top of the collected
> USEFOR ABNF.
>
> I got a "lines defined but not used" warning, please add this
> to fields =/


Thanks Frank!
That's one of the steps that the WG chair is supposed to make sure has been 
done before submission - very good to have it done!

               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 jBN2bsuK092175; Thu, 22 Dec 2005 18:37:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBN2bs3p092174; Thu, 22 Dec 2005 18:37:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBN2brVC092168 for <[e-mail]>; Thu, 22 Dec 2005 18:37:53 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBN2bqSM001512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 22 Dec 2005 21:37:53 -0500
Message-ID: <[e-mail]>
Date: Thu, 22 Dec 2005 21:38:01 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Supersedes and Expire header fields
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
> 
> So I think all that might be needed is a NOTE:
> 
>    NOTE: The Expires header field is also sometimes used in Email with a
>    similar meaning [RFC 2156].

Done.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMHEoj4027141; Thu, 22 Dec 2005 09:14:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMHEoR6027140; Thu, 22 Dec 2005 09:14:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMHEmCE027133 for <[e-mail]>; Thu, 22 Dec 2005 09:14:49 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-67-121.midband.mdip.bt.net ([81.144.67.121]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43aadf07.bc90.25f for [e-mail]; Thu, 22 Dec 2005 17:14:47 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBMHCCi12995 for [e-mail]; Thu, 22 Dec 2005 17:12:12 GMT
To: [e-mail]
Xref: clerew local.usefor:22785
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Supersedes and Expire header fields
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Thu, 22 Dec 2005 12:18:03 GMT
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Ken Murchison <[e-mail]> writes:

>Out current text has the following note regarding Supersedes:

>    NOTE: The Supersedes header field defined here has no connection with
>    the Supersedes header field that sometimes appears in Email messages
>    converted from X.400 according to [RFC2156]; in particular, the
>    syntax here permits only one <msg-id> in contrast to the multiple
>    <msg-id>s in that Email version.


>RFC 2156 also defines an Expires header field, which looks like its 
>compatible with Netnews, provided the mandatory SP follows ':'.  Do we 
>want to have some kind of note similar to what we have above for 
>Expires, or should we refer to RFC 2156 when discussing it?

At least their Expires is defined with the same syntax and essentially the
same semantics, so the potential for harm/confusion is less. Moreover, it
is generally acepted that headers defined for email and used in Netnews,
or vice versa are OK if their meaning carries over in a sensible manner.

So I think all that might be needed is a NOTE:

   NOTE: The Expires header field is also sometimes used in Email with a
   similar meaning [RFC 2156].

-- 
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 jBMG3j41020295; Thu, 22 Dec 2005 08:03:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMG3j8r020274; Thu, 22 Dec 2005 08:03:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMG3eEh020190 for <[e-mail]>; Thu, 22 Dec 2005 08:03:40 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBMG3exi009132 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Thu, 22 Dec 2005 11:03:40 -0500
Message-ID: <[e-mail]>
Date: Thu, 22 Dec 2005 11:03:48 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: ABNF
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann wrote:
> Hi, I tried to validate the ABNF:
> 
> | injection-info  =  "Injection-Info:" SP [CFWS] path-identity
> |                    [CFWS] *(';' parameter) CRLF
> 
> s/';'/";"/
> 
> Bill's parser accepts fields =/ etc.  I just added anything
> from 2822 we need not redefined by us on top of the collected
> USEFOR ABNF.  
> 
> I got a "lines defined but not used" warning, please add this
> to fields =/

Both issues fixed.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMFb0Tx017398; Thu, 22 Dec 2005 07:37:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMFb01B017397; Thu, 22 Dec 2005 07:37:00 -0800 (PST)
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 jBMFawgR017391 for <[e-mail]>; Thu, 22 Dec 2005 07:36:58 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EpSUl-0003do-Fn for [e-mail]; Thu, 22 Dec 2005 16:36:43 +0100
Received: from pd9fba8af.dip0.t-ipconnect.de ([217.251.168.175]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 16:36:43 +0100
Received: from nobody by pd9fba8af.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 16:36:43 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  ABNF
Date:  Thu, 22 Dec 2005 16:35:34 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 339
Message-ID:  <[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: pd9fba8af.dip0.t-ipconnect.de
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>

Hi, I tried to validate the ABNF:

| injection-info  =  "Injection-Info:" SP [CFWS] path-identity
|                    [CFWS] *(';' parameter) CRLF

s/';'/";"/

Bill's parser accepts fields =/ etc.  I just added anything
from 2822 we need not redefined by us on top of the collected
USEFOR ABNF.  

I got a "lines defined but not used" warning, please add this
to fields =/
                           Bye, Frank

;;;;;;;;;;;;;;;;; -2822- ;;;;;;;;;;;;;;;;;;;;;;;;

NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
                        %d11 /          ;  that do not include the
                        %d12 /          ;  carriage return, line feed,
                        %d14-31 /       ;  and white space characters
                        %d127

text            =       %d1-9 /         ; Characters excluding CR and LF
                        %d11 /
                        %d12 /
                        %d14-127 /
                        obs-text

quoted-pair     =       ("\" text) / obs-qp

FWS             =       ([*WSP CRLF] 1*WSP) /   ; Folding white space
                        obs-FWS

ctext           =       NO-WS-CTL /     ; Non white space controls
                        %d33-39 /       ; The rest of the US-ASCII
                        %d42-91 /       ;  characters not including "(",
                        %d93-126        ;  ")", or "\"

ccontent        =       ctext / quoted-pair / comment

comment         =       "(" *([FWS] ccontent) [FWS] ")"

CFWS            =       *([FWS] comment) (([FWS] comment) / FWS)

atext           =       ALPHA / DIGIT / ; Any character except controls,
                        "!" / "#" /     ;  SP, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

atom            =       [CFWS] 1*atext [CFWS]

dot-atom        =       [CFWS] dot-atom-text [CFWS]

dot-atom-text   =       1*atext *("." 1*atext)

qtext           =       NO-WS-CTL /     ; Non white space controls
                        %d33 /          ; The rest of the US-ASCII
                        %d35-91 /       ;  characters not including "\"
                        %d93-126        ;  or the quote character

qcontent        =       qtext / quoted-pair

quoted-string   =       [CFWS]
                        DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                        [CFWS]

word            =       atom / quoted-string

phrase          =       1*word / obs-phrase

utext           =       NO-WS-CTL /     ; Non white space controls
                        %d33-126 /      ; The rest of US-ASCII
                        obs-utext

date-time       =       [ day-of-week "," ] date FWS time [CFWS]

day-of-week     =       ([FWS] day-name) / obs-day-of-week

day-name        =       "Mon" / "Tue" / "Wed" / "Thu" /
                        "Fri" / "Sat" / "Sun"

date            =       day month year

year            =       4*DIGIT / obs-year

month           =       (FWS month-name FWS) / obs-month

month-name      =       "Jan" / "Feb" / "Mar" / "Apr" /
                        "May" / "Jun" / "Jul" / "Aug" /
                        "Sep" / "Oct" / "Nov" / "Dec"

day             =       ([FWS] 1*2DIGIT) / obs-day

time            =       time-of-day FWS zone

time-of-day     =       hour ":" minute [ ":" second ]

hour            =       2DIGIT / obs-hour

minute          =       2DIGIT / obs-minute

second          =       2DIGIT / obs-second

zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone

address         =       mailbox / group

mailbox         =       name-addr / addr-spec

name-addr       =       [display-name] angle-addr

angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr

group           =       display-name ":" [mailbox-list / CFWS] ";"
                        [CFWS]

display-name    =       phrase

mailbox-list    =       (mailbox *("," mailbox)) / obs-mbox-list

address-list    =       (address *("," address)) / obs-addr-list

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

domain-literal  =       [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent        =       dtext / quoted-pair

dtext           =       NO-WS-CTL /     ; Non white space controls
                        %d33-90 /       ; The rest of the US-ASCII
                        %d94-126        ;  characters not including "[",
                                        ;  "]", or "\"

message         =       (fields / obs-fields)
                        [CRLF body]

body            =       *(*998text CRLF) *998text

;;;;;;;;;;;;;;;;; fields ;;;;;;;;;;;;;;;;;;;;;;;;

fields          =       *(trace
                          *(resent-date /
                           resent-from /
                           resent-sender /
                           resent-to /
                           resent-cc /
                           resent-bcc /
                           resent-msg-id))
                        *(orig-date /
                        from /
                        sender /
                        reply-to /
                        to /
                        cc /
                        bcc /
                        message-id /
                        in-reply-to /
                        references /
                        subject /
                        comments /
                        keywords /
                        optional-field)

fields          =/ *( newsgroups /
                      path /
                      injection-date /
                      followup-to /
                      expires /
                      control /
                      supersedes /
                      distribution /
                      summary /
                      approved /
                      organization /
                      xref /
                      archive /
                      user-agent /
                      injection-info )

;;;;;;;;;;;;;;;;; USEFOR ;;;;;;;;;;;;;;;;;;;;;;;;

unstructured    =  1*( [FWS] utext ) [FWS]

from            =  "From:" SP mailbox-list CRLF

orig-date       =  "Date:" SP date-time CRLF

message-id      =  "Message-ID:" SP [FWS] msg-id [FWS] CRLF

msg-id          =  "<" id-left "@" id-right ">"
                   ; maximum length is 250 octets

id-left         =  dot-atom-text / no-fold-quote

id-right        =  dot-atom-text / no-fold-literal

no-fold-quote   =  DQUOTE
                      ( "." *mqtext /
                        *mqtext "." /
                        *mqtext mqspecial *mqtext )
                      DQUOTE

mqtext          =  atext / "." / mqspecial

mqspecial       =  "(" / ")" /      ; same as specials except
                   "<" /            ; "\" and DQUOTE quoted
                   "[" / "]" /      ; "." doubled and ">" omitted
                   ":" / ";" /
                   "@" / "," /
                   ".." / "\\" / "\" DQUOTE

no-fold-literal =  "[" *( mdtext / "\[" / "\]" / "\\" ) "]"

mdtext          =  %d33-61 /        ; The rest of the US-ASCII
                   %d63-90 /        ; characters not including
                   %d94-126         ; ">", "[", "]", or "\"

subject         =  "Subject:" SP unstructured CRLF

newsgroups      =  "Newsgroups:" SP newsgroup-list CRLF

newsgroup-list  =  [FWS] newsgroup-name
                   *( [FWS] "," [FWS] newsgroup-name ) [FWS]

newsgroup-name  =  component *( "." component )

component       =  1*component-char

component-char  =  ALPHA / DIGIT / "+" / "-" / "_"

path            =  "Path:" SP path-list CRLF

path-list       =  [FWS]
                   *( ( path-identity / path-keyword /
                        path-diagnostic ) [FWS]
                      path-delimiter [FWS] )
                   tail-entry [FWS]


path-identity   =  ( ALPHA / DIGIT )
                   *( ALPHA / DIGIT / "-" / "." / "_" )

path-keyword    =  "POSTED" / "MISMATCH"

path-diagnostic =  1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

tail-entry      =  path-identity

path-delimiter  =  "!" / "!!"

sender          =  "Sender:" SP mailbox CRLF

reply-to        =  "Reply-To:" SP address-list CRLF

comments        =  "Comments:" SP unstructured CRLF

keywords        =  "Keywords:" SP phrase *("," phrase) CRLF

injection-date  =  "Injection-Date:" SP date-time CRLF

references      =  "References:" SP [CFWS] msg-id *(CFWS msg-id)
                   [CFWS] CRLF

followup-to     =  "Followup-To:" SP ( newsgroup-list / poster-text )
                   CRLF

poster-text     =  [FWS] %d112.111.115.116.101.114 [FWS]
                   ; "poster" in lower-case

expires         =  "Expires:" SP date-time CRLF

control         =  "Control:" SP [FWS] control-command [FWS] CRLF

control-command =  verb *( [FWS] argument )

verb            =  token

argument        =  value

supersedes      =  "Supersedes:" SP [FWS] msg-id [FWS] CRLF

distribution    =  "Distribution:" SP dist-list CRLF

dist-list       =  [FWS] dist-name
                   *( [FWS] "," [FWS] dist-name ) [FWS]

dist-name       =  ALPHA / DIGIT
                   *( ALPHA / DIGIT / "+" / "-" / "_" )

summary         =  "Summary:" SP unstructured CRLF

approved        =  "Approved:" SP mailbox-list CRLF

organization    =  "Organization:" SP unstructured CRLF

xref            =  "Xref:" SP [FWS] server-name
                   1*( FWS location ) [FWS] CRLF

server-name     =  path-identity

location        =  newsgroup-name ":" article-locator

article-locator =  1*( %x21-27 / %x29-3A / %x3C-7E )
                   ; US-ASCII printable characters
                   ; except '(' and ';'

archive         =  "Archive:" SP [CFWS] ("no" / "yes")
                   *( [CFWS] ";" archive-param ) CRLF

archive-param   =  parameter

user-agent      =  "User-Agent:" SP 1*product [CFWS] CRLF

product         =  [CFWS] token [ [CFWS] "/" product-version ]

product-version =  [CFWS] token

injection-info  =  "Injection-Info:" SP [CFWS] path-identity
                   [CFWS] *(";" parameter) CRLF

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

sender-value    =  mailbox / "verified"

lines           =  "Lines" ":" SP [FWS] 1*DIGIT [FWS] CRLF




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMDp6U6007018; Thu, 22 Dec 2005 05:51:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMDp6n3007017; Thu, 22 Dec 2005 05:51:06 -0800 (PST)
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 jBMDp5Gw007010 for <[e-mail]>; Thu, 22 Dec 2005 05:51:06 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EpQqR-000659-DC for [e-mail]; Thu, 22 Dec 2005 14:50:59 +0100
Received: from pd9fba8af.dip0.t-ipconnect.de ([217.251.168.175]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 14:50:59 +0100
Received: from nobody by pd9fba8af.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 14:50:59 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: IANA considerations
Date:  Thu, 22 Dec 2005 14:49:06 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: pd9fba8af.dip0.t-ipconnect.de
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>

Ken Murchison wrote:

> See my response to Charles' message.

Yes, our articles crossed at some point behind my monitor. ;-)

Let's take "historic" for the four s-o-1036 header fields,
because the plan for s-o-1036 was publication as "historic".

For NNTP-Posting-* "obsoleted" is fine, we replace them by
our Injection-*, and they are not yet "historic", they are
even not specified in any RFC (AFAIK).

For "Lines" you could say "obsolescent" or "deprecated" if
you don't like "standard", that's what the draft does, and
3864 allows any "appropriate value".

For the three s-o-1036 appendix A.3 header fields last seen
1983 (before RFC 1036) let's delete the intro of chapter 3.3
in -06, and start directly after "In addition...":

| This standard obsoletes four header fields defined in
| [Son-of-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 jBMDP7qw004709; Thu, 22 Dec 2005 05:25:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMDP74B004708; Thu, 22 Dec 2005 05:25:07 -0800 (PST)
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 jBMDP5BQ004701 for <[e-mail]>; Thu, 22 Dec 2005 05:25:06 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EpQRL-0005Qv-Px for [e-mail]; Thu, 22 Dec 2005 14:25:03 +0100
Received: from pd9fba8af.dip0.t-ipconnect.de ([217.251.168.175]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 14:25:03 +0100
Received: from nobody by pd9fba8af.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 14:25:03 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: IANA considerations
Date:  Thu, 22 Dec 2005 14:22:07 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 55
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: pd9fba8af.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> We also need to consider whether User-Agent should also apply
> to the protocol "email". It was designed with that intent
> and our draft says so

Easy for 2822bis to adopt this if they like it...

> Probably we should check with IESG whether they would be
> willing for us to do this, since it would stretch our charter
> somewhat.

...that's a good reason to stay away from it.  They could be
tempted to ask us why it took us six years to figure out the
Message-ID, and why we want to screw up mail before the Path-
syntax is 100% clear.

>    NNTP-Posting-Host netnews deprecated IETF
>    NNTP-Posting-Date netnews deprecated IETF
>    Also-Control netnews obsoleted IETF
>    See-Also netnews obsoleted IETF
>    Article-Names netnews obsoleted IETF
>    Article-Updates netnews obsoleted IETF

What about Relay-Version / Posted-Version / Date-Received ?
Apparently they are only mentioned (already as obsolete) in
appendix A.3 of s-o-1036, but not in 1036.

Why do we have them at all, what was Henry talking about when
he wrote "early versions of the news software" ?  His examples
are 1983, RfC 1036 was published 1987.  Should we just remove
this from our draft, because it's ancient pre-1036 history ?

 [NNTP-Posting-*]
> I think it would still be proper to describe IETF as the
> "Change Controller" (but not as Author, obviously).

We grabbed them and deprecate them in a not-yet IETF PS, so
that's "Change Controller: IETF" as per the 3864 rules...

...oops, I just see that "obsoleted" for "Lines" is allowed:

| Status:
|  Specify "standard", "experimental", "informational",
|  "historic", "obsoleted", or some other appropriate value

Maybe "obsoleted" is the correct value for NNTP-Posting-* (?)

My first guess would be "historic" => old and not more needed,
"obsoleted" => old and replaced by something better.  If that
makes sense NNTP-Posting-* are "obsoleted", the othere are all
"historic", but the 'obsolescent' Lines is still "standard".

                     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 jBMDHgvb003770; Thu, 22 Dec 2005 05:17:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMDHgZP003769; Thu, 22 Dec 2005 05:17:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMDHfO2003762 for <[e-mail]>; Thu, 22 Dec 2005 05:17:41 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBMDHfGk021833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Dec 2005 08:17:42 -0500
Message-ID: <[e-mail]>
Date: Thu, 22 Dec 2005 08:17:49 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Frank Ellermann <[e-mail]>
CC: [e-mail]
Subject: Re: IANA considerations
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann wrote:
> Ken Murchison wrote:
> 
> 
>>| Lines          | obsoleted | This document (Section 3.3.1)        |
> 
> 
> AFAIK there's no status "obsoleted" in 3864.  You could only
> mention this in the comment of a complete registration form.

 From RFC 3864:

    "Status:
       Specify "standard", "experimental", "informational", "historic",
       "obsoleted", or some other appropriate value according to the type
       and status of the primary document in which it is defined."


> 
> Say "standard", it's only a registry, details are irrelevant
> if the source has it right.
> 
> You forgot the registrations for all header fields declared
> to be "historic" by draft-ietf-usefor-usefor-06:

See my response to Charles' message.


-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMDH6kB003719; Thu, 22 Dec 2005 05:17:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMDH6DM003718; Thu, 22 Dec 2005 05:17:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMDH4QA003711 for <[e-mail]>; Thu, 22 Dec 2005 05:17:05 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBMDH3Ru021749 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Dec 2005 08:17:04 -0500
Message-ID: <[e-mail]>
Date: Thu, 22 Dec 2005 08:17:11 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Harald Tveit Alvestrand <[e-mail]>
Subject: Re: IANA considerations
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
> In <[e-mail]> Ken Murchison <[e-mail]> writes:
> 
> 
>>6.  IANA Considerations
> 
> 
> 
>>      NOTE: For each of the registered header fields, the Applicable
>>      protocol is "netnews" and the Author/Change controller is "IETF".
> 
> 
> We also need to consider whether User-Agent should also apply to the
> protocol "email". It was designed with that intent, and our draft says so
> (indeed, it would also have been identical to the HTTP protocol version,
> but for some differences in the lexical conventions of HTTP). It is used
> as much in email as in Netnews (though syntax varies somewhat on both,
> because it has not been written down before, except in the HTTP
> standards).
> 
> Probably we should check with IESG whether they would be willing for us to
> do this, since it would stretch our charter somewhat. OTOH, I doubt anyone
> is going to bother to do an ID for the same header in email jusr repeating
> our syntax.
> 
> The same thing might apply to the Organization header, which is widely
> used in email.

I have no problem adding this (if I can get xml2rfc to behave well with 
another column in the table), if somebody wants to do the legwork with 
IETF/IESG to determine if we can/should add this to our doc.


> I think we also need to mention various other headers now deprecated or
> obsoleted.
> 
>    NNTP-Posting-Host netnews deprecated IETF
                                ^^^^^^^^^^

RFC 3864 doesn't list "deprecated", just "standard", "experimental", 
"informational", "historic", "obsoleted".  I supposed we *could* use 
"deprecated", but perhaps we could get by with "historic".


>    NNTP-Posting-Date netnews deprecated IETF
>    Also-Control netnews obsoleted IETF
>    See-Also netnews obsoleted IETF
>    Article-Names netnews obsoleted IETF
>    Article-Updates netnews obsoleted IETF
> 
> A proper reference for the last 4 would be Son-of-1036, which we propose
> to refer to in any case. The 1st two have no published definition that I
> know of apart from the source code of INN. However, they are both much
> used, and we have explicitly deprecated their continued use in USEFOR. I
> think it would still be proper to describe IETF as the "Change Controller"
> (but not as Author, obviously).

If s-o-1036 actually defines a header, then I think we can probably 
register it.  If there is no definition anywhere that we can reference, 
then how can we register it?  I certainly don't want to add ABNF to our 
doc for headers that are dead.

Harald, any thoughts?


> I think it important that one should be able to look up any header one may
> have encountered in some article in the IANA registry in order to see what
> its official status, if any, might be (surely that is the whole point of
> the registry).

I agree in theory.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMCF4sj097568; Thu, 22 Dec 2005 04:15:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBMCF40f097567; Thu, 22 Dec 2005 04:15:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBMCF1oq097559 for <[e-mail]>; Thu, 22 Dec 2005 04:15:02 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-65-249.midband.mdip.bt.net ([81.144.65.249]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43aa98c0.7e17.1a for [e-mail]; Thu, 22 Dec 2005 12:14:56 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBMCCb011368 for [e-mail]; Thu, 22 Dec 2005 12:12:38 GMT
To: [e-mail]
Xref: clerew local.usefor:22784
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: IANA considerations
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 22 Dec 2005 12:12:16 GMT
Lines: 62
Sender: [e-mail]
Precedence: 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]> Ken Murchison <[e-mail]> writes:

>6.  IANA Considerations


>       NOTE: For each of the registered header fields, the Applicable
>       protocol is "netnews" and the Author/Change controller is "IETF".

We also need to consider whether User-Agent should also apply to the
protocol "email". It was designed with that intent, and our draft says so
(indeed, it would also have been identical to the HTTP protocol version,
but for some differences in the lexical conventions of HTTP). It is used
as much in email as in Netnews (though syntax varies somewhat on both,
because it has not been written down before, except in the HTTP
standards).

Probably we should check with IESG whether they would be willing for us to
do this, since it would stretch our charter somewhat. OTOH, I doubt anyone
is going to bother to do an ID for the same header in email jusr repeating
our syntax.

The same thing might apply to the Organization header, which is widely
used in email.

>    +----------------+-----------+--------------------------------------+
>    | Header field   | Status    | Specification document(s)            |
>    | name           |           |                                      |
>    +----------------+-----------+--------------------------------------+
>    +----------------+-----------+--------------------------------------+

I think we also need to mention various other headers now deprecated or
obsoleted.

   NNTP-Posting-Host netnews deprecated IETF
   NNTP-Posting-Date netnews deprecated IETF
   Also-Control netnews obsoleted IETF
   See-Also netnews obsoleted IETF
   Article-Names netnews obsoleted IETF
   Article-Updates netnews obsoleted IETF

A proper reference for the last 4 would be Son-of-1036, which we propose
to refer to in any case. The 1st two have no published definition that I
know of apart from the source code of INN. However, they are both much
used, and we have explicitly deprecated their continued use in USEFOR. I
think it would still be proper to describe IETF as the "Change Controller"
(but not as Author, obviously).

I think it important that one should be able to look up any header one may
have encountered in some article in the IANA registry in order to see what
its official status, if any, might be (surely that is the whole point of
the registry).

-- 
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 jBM59tgV054507; Wed, 21 Dec 2005 21:09:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBM59tB4054506; Wed, 21 Dec 2005 21:09:55 -0800 (PST)
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 jBM59s0q054500 for <[e-mail]>; Wed, 21 Dec 2005 21:09:55 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EpIi3-0003JG-2O for [e-mail]; Thu, 22 Dec 2005 06:09:47 +0100
Received: from pd9fba924.dip0.t-ipconnect.de ([217.251.169.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 06:09:47 +0100
Received: from nobody by pd9fba924.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 06:09:47 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: IANA considerations
Date:  Thu, 22 Dec 2005 06:08:40 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 33
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: pd9fba924.dip0.t-ipconnect.de
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>

Ken Murchison wrote:

> | Lines          | obsoleted | This document (Section 3.3.1)        |

AFAIK there's no status "obsoleted" in 3864.  You could only
mention this in the comment of a complete registration form.

Say "standard", it's only a registry, details are irrelevant
if the source has it right.

You forgot the registrations for all header fields declared
to be "historic" by draft-ietf-usefor-usefor-06:

       NNTP-Posting-Date       (no spec., dummy source Usefor)
       NNTP-Posting-Host       (no spec., dummy source Usefor)
       Relay-Version           (no spec.  => Usefor or 1036 ?)
       Posted-Version          (no spec.  => Usefor or 1036 ?)
       Date-Received           (no spec.  => Usefor or 1036 ?)
       Also-Control            (Usefor or s-o-1036 ?)
       See-Also                (Usefor or s-o-1036 ?)
       Article-Names           (Usefor or s-o-1036 ?)
       Article-Updates         (Usefor or s-o-1036 ?)

IMHO the IANA registry needs the last known status "historic",
and the source for this last known status, and that's always
draft-ietf-usefor-usefor-06. 

In theory s-o-1036 is the first source for the deprecation of
Relay-Version / Posted-Version / Date-Received, but it's no
RFC at the moment, let's just register the complete "historic"
zoo and be done with it.
                         Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBM4rAhJ052647; Wed, 21 Dec 2005 20:53:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBM4rAdI052646; Wed, 21 Dec 2005 20:53:10 -0800 (PST)
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 jBM4r8Ir052636 for <[e-mail]>; Wed, 21 Dec 2005 20:53:09 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EpIRo-0006ds-DP for [e-mail]; Thu, 22 Dec 2005 05:53:00 +0100
Received: from pd9fba924.dip0.t-ipconnect.de ([217.251.169.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 05:53:00 +0100
Received: from nobody by pd9fba924.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 22 Dec 2005 05:53:00 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Supersedes and Expire header fields
Date:  Thu, 22 Dec 2005 05:52:04 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
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: pd9fba924.dip0.t-ipconnect.de
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>

Ken Murchison wrote:

> Do we want to have some kind of note similar to what we have
> above for Expires

I take it that you mean Supersedes here.  

| / "Expires" ":" date-time
[...]

The MIXER <date-time> is apparently 822, and the proposed 2822
wishes to update 822.  We already discuss this in the draft.

IMHO no second note about MIXER needed:  mail2news operators
would know what to do if a MIXER <date-time> incompatible with
USEFOR hits them.  And they also know "magic SP everywhere".

                       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 jBLJGUs9095088; Wed, 21 Dec 2005 11:16:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLJGU99095087; Wed, 21 Dec 2005 11:16:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLJGTcc095080 for <[e-mail]>; Wed, 21 Dec 2005 11:16:30 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBLJGUMc030617 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 21 Dec 2005 14:16:31 -0500
Message-ID: <[e-mail]>
Date: Wed, 21 Dec 2005 14:16:38 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-ietf-usefor-usefor-06
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
> 
> 
>>+   This also applies to the following header field defined in [RFC2822]:
>>+
>>+   Message-ID
>>+
>>+   Several of these headers are mainly of interest to servers, and
>>+   servers often need to process these fields very rapidly.
> 
> 
> s/to servers/to news servers/ (since that is now the terminology we use)

Applied.


>>3.2.14.  Injection-Info
>>
>>
>>-   The "sender" parameter identifies the mailbox of the verified sender
>>-   of the article (alternatively, it uses the token "verified" to
>>+   The "sender" <parameter> identifies the mailbox of the verified
>>+   sender of the article (alternatively, it uses the token "verified" to
>>   indicate that at least any addr-spec in the Sender header field of
> 
>                                 ^^^^^^^^^
>                                <addr-spec>

Fixed.


>>Appendix C.  Differences from RFC 2822
>>
>>+
>>+      The length of a msg-id MUST NOT exceed 250 octets.
> 
>                         ^^^^^^
>                        <msg-id>

Fixed.


> 
>>+      It is legal for a parser to not accept obsolete syntax, except
>>+      that:
> 
> 
> Split infinitives can lead to long religious wars :-( . It is usually
> safer not to include them.

/not accept/reject/


I'll leave the rest of your comments to Harald, since most, if not all, 
of the text added/replaced in -06 was taken verbatim from the tickets.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLJAKQS094429; Wed, 21 Dec 2005 11:10:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLJAKOM094428; Wed, 21 Dec 2005 11:10:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLJAJof094421 for <[e-mail]>; Wed, 21 Dec 2005 11:10:20 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBLJAJSP029516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 21 Dec 2005 14:10:20 -0500
Message-ID: <[e-mail]>
Date: Wed, 21 Dec 2005 14:10:27 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: #1047 - Path header (was toplabel...)
References: <[e-mail]> <[e-mail]> <[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=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>

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In message <[e-mail]>, Charles Lindsey
> <[e-mail]> writes
> 
> 
>>>  The Path header field indicates the route taken by an article since
>>>  its injection into the Netnews system.  Each agent that processes an
>>>  article is required to prepend one (or more) identities to this
>>>  header field body.  This is primarily to enable news servers to avoid
>>>  sending articles to sites already known to have them, in particular
>>>  the site they came from, and additionally to permit tracing the route
>>>  articles take in moving over the network, and for gathering Usenet
>>>  statistics.
> 
> 
> /Usenet //
> 
> 
>>>  Each <path-identity> in the <path-list> (excluding the one in the
>>>  <tail-entry>) indicates, from right to left, the successive agents
>>>  through which the article has passed.  The <path-keyword> "POSTED"
>>>  indicates that the agent to its left injected the article.  The use
>>>  of the <path-delimiter> "!!" indicates that the agent to its left
>>>  claims that the agent to its right was the verified source of the
>>>  article (whereas the <path-delimiter> "!" implies no such claim).
>>>  The <path-keyword> "MISMATCH" indicates that the agent to its right
>>>  failed to be so verified.
> 
> 
> this sounds as if !! can only appear early on :(  for the third sentence
> try:
> 
>     The use of the <path-delimiter> "!!" indicates that the agent to its
>     left verified the identity of the agent to its right before
>     accepting the article (whereas the <path-delimiter> "!" implies no
>     such claim.


Both changes applied.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLHDPYf081643; Wed, 21 Dec 2005 09:13:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLHDPhE081642; Wed, 21 Dec 2005 09:13:25 -0800 (PST)
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 jBLHDOYL081627 for <[e-mail]>; Wed, 21 Dec 2005 09:13:25 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-5.midband.mdip.bt.net ([81.144.66.5]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43a98d33.16586.1f4 for [e-mail]; Wed, 21 Dec 2005 17:13:23 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBLHCRS04356 for [e-mail]; Wed, 21 Dec 2005 17:12:27 GMT
To: [e-mail]
Xref: clerew local.usefor:22779
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 - Path header (was toplabel...)
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]> <[e-mail]>
Date: Wed, 21 Dec 2005 17:00:04 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 <[e-mail]> Richard Clayton <[e-mail]> writes:


>>>   Each <path-identity> in the <path-list> (excluding the one in the
>>>   <tail-entry>) indicates, from right to left, the successive agents
>>>   through which the article has passed.  The <path-keyword> "POSTED"
>>>   indicates that the agent to its left injected the article.  The use
>>>   of the <path-delimiter> "!!" indicates that the agent to its left
>>>   claims that the agent to its right was the verified source of the
>>>   article (whereas the <path-delimiter> "!" implies no such claim).
>>>   The <path-keyword> "MISMATCH" indicates that the agent to its right
>>>   failed to be so verified.

>this sounds as if !! can only appear early on :(  for the third sentence
>try:

>    The use of the <path-delimiter> "!!" indicates that the agent to its
>    left verified the identity of the agent to its right before
>    accepting the article (whereas the <path-delimiter> "!" implies no
>    such claim.

Yes, that sounds better.

But we still need to reach some conclusion on what to say about
<path-keyword>s, and decide whether to tighten things up sufficiently that
we can truly say that <path-identity>s consisting only of <=4 Hex Digits
are the only ones that need be warned against.

-- 
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 jBLHDPgI081634; Wed, 21 Dec 2005 09:13:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLHDPaH081633; Wed, 21 Dec 2005 09:13:25 -0800 (PST)
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 jBLHDNu2081623 for <[e-mail]>; Wed, 21 Dec 2005 09:13:24 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-5.midband.mdip.bt.net ([81.144.66.5]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.207) id 43a98d32.16586.1f3 for [e-mail]; Wed, 21 Dec 2005 17:13:22 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBLHCQj04351 for [e-mail]; Wed, 21 Dec 2005 17:12:26 GMT
To: [e-mail]
Xref: clerew local.usefor:22778
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 - Path header (was toplabel...)
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]> <[e-mail]>
Date: Wed, 21 Dec 2005 16:55:38 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]> Harald Tveit Alvestrand <[e-mail]> writes:

>--On mandag, desember 19, 2005 17:20:29 +0000 Charles Lindsey 
><[e-mail]> wrote:

>>>   A <path-identity> is a name identifying a site.  It takes the form of
>>>   a domain name having one or more components separated by dots.
>>
>> That makes no allowance for barewords (whether we formally define that
>> term or not). "It _usually_ takes the form of a domain name ..." would be
>> OK, because any gory details could then be left to USEPRO.

>Try telling the difference between a domain name having one component and a 
>bareword.

Then you need to say "It usually takes the form of a fully qualified
domain name ...", and/or make some mention of 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 jBLEaZwb062208; Wed, 21 Dec 2005 06:36:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLEaZKs062207; Wed, 21 Dec 2005 06:36:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLEaYEh062198 for <[e-mail]>; Wed, 21 Dec 2005 06:36:35 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBLEaYwk007396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 21 Dec 2005 09:36:35 -0500
Message-ID: <[e-mail]>
Date: Wed, 21 Dec 2005 09:36:43 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Supersedes and Expire header fields
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>

Out current text has the following note regarding Supersedes:

    NOTE: The Supersedes header field defined here has no connection with
    the Supersedes header field that sometimes appears in Email messages
    converted from X.400 according to [RFC2156]; in particular, the
    syntax here permits only one <msg-id> in contrast to the multiple
    <msg-id>s in that Email version.


RFC 2156 also defines an Expires header field, which looks like its 
compatible with Netnews, provided the mandatory SP follows ':'.  Do we 
want to have some kind of note similar to what we have above for 
Expires, or should we refer to RFC 2156 when discussing it?

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLEIZb3060266; Wed, 21 Dec 2005 06:18:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBLEIZD2060265; Wed, 21 Dec 2005 06:18:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBLEIYcH060252 for <[e-mail]>; Wed, 21 Dec 2005 06:18:35 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBLEIXg0004198 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Wed, 21 Dec 2005 09:18:33 -0500
Message-ID: <[e-mail]>
Date: Wed, 21 Dec 2005 09:18:42 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: IANA considerations
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> If you want a text to insert into USEFOR, then you will find all you want
> in the IANA Considerations section (10.2) of draft-ietf-usefor-article-13.
> It is a bit out of date, because we have changed some headers, but it is
> in exactly the format that RFC 3864 asks for.

OK, here's what I have in my current copy.  Note that I had to pull the 
protocol and change controller out of the <texttable>, since its is the 
only way that xml2rfc would render the text version without mangling it.



6.  IANA Considerations

    IANA is requested to register the following header fields in the
    Permanent Message Header Field Repository, in accordance with the
    procedures set out in [RFC3864].

       NOTE: For each of the registered header fields, the Applicable
       protocol is "netnews" and the Author/Change controller is "IETF".

    +----------------+-----------+--------------------------------------+
    | Header field   | Status    | Specification document(s)            |
    | name           |           |                                      |
    +----------------+-----------+--------------------------------------+
    | Approved       | standard  | This document (Section 3.2.9)        |
    |                |           |                                      |
    | Archive        | standard  | This document (Section 3.2.12)       |
    |                |           |                                      |
    | Comments       | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.5)            |
    |                |           |                                      |
    | Control        | standard  | This document (Section 3.2.5)        |
    |                |           |                                      |
    | Date           | standard  | This document (Section 3.1.2),       |
    |                |           | [RFC2822] (Section 3.6.1)            |
    |                |           |                                      |
    | Distribution   | standard  | This document (Section 3.2.7)        |
    |                |           |                                      |
    | Expires        | standard  | This document (Section 3.2.4)        |
    |                |           |                                      |
    | Followup-To    | standard  | This document (Section 3.2.3)        |
    |                |           |                                      |
    | From           | standard  | This document (Section 3.1.1),       |
    |                |           | [RFC2822] (Section 3.6.2)            |
    |                |           |                                      |
    | Injection-Date | standard  | This document (Section 3.2.1)        |
    |                |           |                                      |
    | Injection-Info | standard  | This document (Section 3.2.14)       |
    |                |           |                                      |
    | Keywords       | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.5)            |
    |                |           |                                      |
    | Lines          | obsoleted | This document (Section 3.3.1)        |
    |                |           |                                      |
    | Message-ID     | standard  | This document (Section 3.1.3),       |
    |                |           | [RFC2822] (Section 3.6.4)            |
    |                |           |                                      |
    | Newsgroups     | standard  | This document (Section 3.1.5)        |
    |                |           |                                      |
    | Organization   | standard  | This document (Section 3.2.10)       |
    |                |           |                                      |
    | Path           | standard  | This document (Section 3.1.6)        |
    |                |           |                                      |
    | References     | standard  | This document (Section 3.2.2),       |
    |                |           | [RFC2822] (Section 3.6.4)            |
    |                |           |                                      |
    | Reply-To       | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.2)            |
    |                |           |                                      |
    | Sender         | standard  | This document (Section 3.2),         |
    |                |           | [RFC2822] (Section 3.6.2)            |
    |                |           |                                      |
    | Subject        | standard  | This document (Section 3.1.4),       |
    |                |           | [RFC2822] (Section 3.6.5)            |
    |                |           |                                      |
    | Summary        | standard  | This document (Section 3.2.8)        |
    |                |           |                                      |
    | Supersedes     | standard  | This document (Section 3.2.6)        |
    |                |           |                                      |
    | User-Agent     | standard  | This document (Section 3.2.13)       |
    |                |           |                                      |
    | Xref           | standard  | This document (Section 3.2.11)       |
    +----------------+-----------+--------------------------------------+




-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKKo2Vf049245; Tue, 20 Dec 2005 12:50:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBKKo2aY049243; Tue, 20 Dec 2005 12:50:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKKo1fG049229 for <[e-mail]>; Tue, 20 Dec 2005 12:50:01 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQr-0008QJ-7Q; Tue, 20 Dec 2005 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-usefor-usefor-06.txt 
Message-Id: <[e-mail]>
Date: Tue, 20 Dec 2005 15:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: Netnews Article Format
	Author(s)	: C. Lindsey, et al.
	Filename	: draft-ietf-usefor-usefor-06.txt
	Pages		: 37
	Date		: 2005-12-19
	
This document specifies the syntax of network news (Netnews) articles
   in the context of the "Internet Message Format" (RFC 2822) and
   "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045).  This
   document supersedes RFC 1036, updating it to reflect current practice
   and incorporating incremental changes specified in other documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-usefor-usefor-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usefor-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usefor-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usefor-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKA1q2P072990; Tue, 20 Dec 2005 02:01:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBKA1qRL072989; Tue, 20 Dec 2005 02:01:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBKA1pgA072979 for <[e-mail]>; Tue, 20 Dec 2005 02:01:51 -0800 (PST) (envelope-from [e-mail])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1EoeC9-00012V-5a for [e-mail]; Tue, 20 Dec 2005 09:54:09 +0000
Message-ID: <[e-mail]>
Date: Tue, 20 Dec 2005 10:00:11 +0000
To: [e-mail]
From: Richard Clayton <[e-mail]>
Subject: Re: #1047 - Path header (was toplabel...)
References: <[e-mail]> <[e-mail]> <[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 <zZz$+zH$77$8tPKLm6a+dercx2>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

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

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

>>   The Path header field indicates the route taken by an article since
>>   its injection into the Netnews system.  Each agent that processes an
>>   article is required to prepend one (or more) identities to this
>>   header field body.  This is primarily to enable news servers to avoid
>>   sending articles to sites already known to have them, in particular
>>   the site they came from, and additionally to permit tracing the route
>>   articles take in moving over the network, and for gathering Usenet
>>   statistics.

/Usenet //

>>   Each <path-identity> in the <path-list> (excluding the one in the
>>   <tail-entry>) indicates, from right to left, the successive agents
>>   through which the article has passed.  The <path-keyword> "POSTED"
>>   indicates that the agent to its left injected the article.  The use
>>   of the <path-delimiter> "!!" indicates that the agent to its left
>>   claims that the agent to its right was the verified source of the
>>   article (whereas the <path-delimiter> "!" implies no such claim).
>>   The <path-keyword> "MISMATCH" indicates that the agent to its right
>>   failed to be so verified.

this sounds as if !! can only appear early on :(  for the third sentence
try:

    The use of the <path-delimiter> "!!" indicates that the agent to its
    left verified the identity of the agent to its right before
    accepting the article (whereas the <path-delimiter> "!" implies no
    such claim.

- -- 
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/AwUBQ6fWK5oAxkTY1oPiEQIyxwCgnfw8Zf+J1nEjeUo3/22O0iLmeSYAnRC6
7PaWaYogGRprOEg4EYPVpTjo
=HOBD
-----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 jBK8ONoK063309; Tue, 20 Dec 2005 00:24:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBK8ON3O063308; Tue, 20 Dec 2005 00:24:23 -0800 (PST)
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 jBK8OM6x063301 for <[e-mail]>; Tue, 20 Dec 2005 00:24:23 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17D1325970F; Tue, 20 Dec 2005 09:23:34 +0100 (CET)
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 13005-02; Tue, 20 Dec 2005 09:23:30 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id A04F725970B; Tue, 20 Dec 2005 09:23:30 +0100 (CET)
Date: Tue, 20 Dec 2005 09:27:02 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1047 - Path header (was toplabel...)
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]>	 <[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>

--On tirsdag, desember 20, 2005 07:50:42 +0100 Frank Ellermann 
<[e-mail]> wrote:

>
> Harald Tveit Alvestrand wrote:
>
>> Try telling the difference between a domain
>> name having one component and a bareword.
>
>               %x5F   SCNR
>

Underscore. Sigh. yes.
Note that those are legal in domain names, but illegal in host names; third 
religious war to the right for details...







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBK6rhPU054491; Mon, 19 Dec 2005 22:53:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBK6rhR0054490; Mon, 19 Dec 2005 22:53:43 -0800 (PST)
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 jBK6rfeu054471 for <[e-mail]>; Mon, 19 Dec 2005 22:53:42 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EobM5-00066F-Ju for [e-mail]; Tue, 20 Dec 2005 07:52:13 +0100
Received: from pd9fba922.dip0.t-ipconnect.de ([217.251.169.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 20 Dec 2005 07:52:13 +0100
Received: from nobody by pd9fba922.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 20 Dec 2005 07:52:13 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1047 - Path header (was toplabel...)
Date:  Tue, 20 Dec 2005 07:50:42 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 7
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]>
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: pd9fba922.dip0.t-ipconnect.de
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:
 
> Try telling the difference between a domain
> name having one component and a bareword.

              %x5F   SCNR




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBK6hifH052498; Mon, 19 Dec 2005 22:43:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBK6hieg052497; Mon, 19 Dec 2005 22:43:44 -0800 (PST)
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 jBK6hhsF052485 for <[e-mail]>; Mon, 19 Dec 2005 22:43:43 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C2792596E9; Tue, 20 Dec 2005 07:42:54 +0100 (CET)
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 10464-03; Tue, 20 Dec 2005 07:42:51 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 425B92596E7; Tue, 20 Dec 2005 07:42:51 +0100 (CET)
Date: Tue, 20 Dec 2005 07:46:22 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1047 - Path header (was toplabel...)
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]> <[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 mandag, desember 19, 2005 17:20:29 +0000 Charles Lindsey 
<[e-mail]> wrote:

>>   A <path-identity> is a name identifying a site.  It takes the form of
>>   a domain name having one or more components separated by dots.
>
> That makes no allowance for barewords (whether we formally define that
> term or not). "It _usually_ takes the form of a domain name ..." would be
> OK, because any gory details could then be left to USEPRO.

Try telling the difference between a domain name having one component and a 
bareword.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBK3GCa5031961; Mon, 19 Dec 2005 19:16:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBK3GCn1031960; Mon, 19 Dec 2005 19:16:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-6.gradwell.net (lon-mail-6.gradwell.net [193.111.201.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBK3GBP1031947 for <[e-mail]>; Mon, 19 Dec 2005 19:16:11 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-120.midband.mdip.bt.net ([81.144.66.120]) by lon-mail-6.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a77779.136f0.96 for [e-mail]; Tue, 20 Dec 2005 03:16:09 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBK3C9F21227 for [e-mail]; Tue, 20 Dec 2005 03:12:09 GMT
To: [e-mail]
Xref: clerew local.usefor:22767
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1047 - Path header (was toplabel...)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>   <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Mon, 19 Dec 2005 17:20:29 GMT
Lines: 140
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>--On torsdag, desember 15, 2005 16:59:12 +0000 Charles Lindsey 
><[e-mail]> wrote:

>> However, the main question that still needs answering (as Harald has
>> agreed) is whether we want to arrange the syntax so that one can
>> immediately tell whether a given entry is a path-entry or a
>> souce[diagnostic]-entry.
>>
>> I have said that is a desireable feature, but nobody else has answered
>> yet.

>And I have said that I do not judge it possible to design and get consensus 
>for such a mechanism without delaying USEFOR considerably, given the 
>current lack of energy in the group.

>I think it's better at this time to allow stuff in USEFOR (which will also 
>allow existing usage, which is varied, and not mechanically 
>distinguishable) and make rules for "one way to do it" in USEPRO.

No, I don't think that is workable without syntactic changes in USEFOR.

Anyway, we now have a new draft-06 which addresses some of these issues,
so let us start from that. I have assembled the full text as it now stands
following Ken's diffs.

>3.1.6  Path
>
>   The Path header field indicates the route taken by an article since
>   its injection into the Netnews system.  Each agent that processes an
>   article is required to prepend one (or more) identities to this
>   header field body.  This is primarily to enable news servers to avoid
>   sending articles to sites already known to have them, in particular
>   the site they came from, and additionally to permit tracing the route
>   articles take in moving over the network, and for gathering Usenet
>   statistics.
>
>   path            =  "Path:" SP path-list CRLF
>
>   path-list       =  [FWS]
>                      *( ( path-identity / path-keyword /
>                           path-diagnostic ) [FWS]
>                         path-delimiter [FWS] )
>                      tail-entry [FWS]
>
>
>   path-identity   =  ( ALPHA / DIGIT )
>                      *( ALPHA / DIGIT / "-" / "." / "_" )
>
>   path-keyword    =  "POSTED" / "MISMATCH"

Leaving that in the syntax will prevent subsequent introduction of new
keywords (e.g. SEEN) or making the list of keywords extensible, as you
have suggested. Moreover, it would preclude changing to the alternative
"news.example..MISMATCH" notation.

>   path-diagnostic =  1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

That allows ":" in _any_ diagnostic, not just in IpV6addresses.

>
>   tail-entry      =  path-identity
>
>   path-delimiter  =  "!" / "!!"
>
>   A <path-identity> is a name identifying a site.  It takes the form of
>   a domain name having one or more components separated by dots.

That makes no allowance for barewords (whether we formally define that
term or not). "It _usually_ takes the form of a domain name ..." would be
OK, because any gory details could then be left to USEPRO.

>
>   Each <path-identity> in the <path-list> (excluding the one in the
>   <tail-entry>) indicates, from right to left, the successive agents
>   through which the article has passed.  The <path-keyword> "POSTED"
>   indicates that the agent to its left injected the article.  The use
>   of the <path-delimiter> "!!" indicates that the agent to its left
>   claims that the agent to its right was the verified source of the
>   article (whereas the <path-delimiter> "!" implies no such claim).
>   The <path-keyword> "MISMATCH" indicates that the agent to its right
>   failed to be so verified.

Which actually extends what was said before because it allows the agent to
is left to shout "MISMATCH" without actually prefacing it with a
diagnostic saying what it actually saw. I think "MISMATCH" (or "SEEN" if
we have it) needs to be anchored to the agent to its left, just as with
"!!".

>
>      NOTE: Although case-insensitive, it is intended that the <path-
>      keyword>s "POSTED" and "MISMATCH" should be in upper case, to
>      distinguish them from the <path-identity>s which are traditionally
>      in lower case.
>
>   A <path-diagnostic> is an item inserted into the Path header for
>   purposes other than to indicate the name of a site.  One commonly
>   observed usage is to insert an IP address.

At least you need to say that such an IP address indicates the site which
whatever agent put it there claims to have received the article from.
However, what we do not (and cannot) know is how often sites insert a
domain-name with that same diagnostic intent, although we do know that many
sites DO insert such a domain name in the form
"true.source.example.MISMATCH".

>  ... The colon (":") is
>   permitted in order to allow IPv6 addresses to be inserted; note that
>   this will cause interoperability problems at older sites that regard
>   ":" as a <path-delimiter> and have neighbors whose names have 4 or
>   fewer characters, and where all the characters are valid HEX digits.

No, that bit about HEX digits is no longer true if you allow ":" in _any_
<path-diagnostic> (such as a "bare-diagnostic" IYSWIM). If you want to
make it cleat that ":" is not allowed except in an IPv6address, then you
either have to write in a big "MUST NOT", or else you have to write some
ABNF (which I think would be better).

But sooner or later we have to make up our minds what we are going to
allow here, so we might as well do it sooner. Certainly, if we want to

1. make it so that diagnostics are recognisable as such (whether by keyword
or otherwise), and

2. keep open the possibility of the alternative keyword notation,

then it has to go into USEFOR. I grant you that the rest of the details
could then be dealt with in USEPRO.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBK3GBjx031949; Mon, 19 Dec 2005 19:16:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBK3GBon031942; Mon, 19 Dec 2005 19:16:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-6.gradwell.net (lon-mail-6.gradwell.net [193.111.201.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBK3G9bM031933 for <[e-mail]>; Mon, 19 Dec 2005 19:16:10 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-120.midband.mdip.bt.net ([81.144.66.120]) by lon-mail-6.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a77774.136f0.94 for [e-mail]; Tue, 20 Dec 2005 03:16:04 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBK3CBp21239 for [e-mail]; Tue, 20 Dec 2005 03:12:11 GMT
To: [e-mail]
Xref: clerew local.usefor:22769
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: IANA considerations
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 19 Dec 2005 17:55:42 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]> Frank Ellermann <[e-mail]> writes:

>Hi, here's my proposal for the missing IANA considerations:

>1 - we create a simple draft-ietf-usefor-hdrreg-00.txt, that
>    would be a WG -00, so we need Alexey's or Harald's OK

No, there is no need to do that. RFC 3864 requires us to include the
proper IANA registrations within USEFOR itself.

>2 - we add an informative reference to that I-D in the future
>    "WG last call xmas edition" (draft-ietf-usefor-usefor-07),
>    with IANA considerations as a pointer to the hddrreg-draft

>3 - in essence that news header registry draft would be like...

>http://www.ninebynine.org/IETF/Messaging/HdrRegistry/draft-lindsey-hdrreg-netnews-01.xml

That document dealt with provisional registrations for the headers as they
stand in RFC 1036, etc. And yes, I really ought to submit it as an
informational RFC.

But the format of that document is far more complex that RFC 3864 requires
(it was copied from the style of Graham Klyne's over-verbose mail
document).

If you want a text to insert into USEFOR, then you will find all you want
in the IANA Considerations section (10.2) of draft-ietf-usefor-article-13.
It is a bit out of date, because we have changed some headers, but it is
in exactly the format that RFC 3864 asks for.

-- 
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 jBK3GBjm031950; Mon, 19 Dec 2005 19:16:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBK3GB5J031948; Mon, 19 Dec 2005 19:16:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-6.gradwell.net (lon-mail-6.gradwell.net [193.111.201.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBK3G9gX031934 for <[e-mail]>; Mon, 19 Dec 2005 19:16:10 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-120.midband.mdip.bt.net ([81.144.66.120]) by lon-mail-6.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a77778.136f0.95 for [e-mail]; Tue, 20 Dec 2005 03:16:08 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBK3CAn21235 for [e-mail]; Tue, 20 Dec 2005 03:12:10 GMT
To: [e-mail]
Xref: clerew local.usefor:22768
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: draft-ietf-usefor-usefor-06
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Mon, 19 Dec 2005 17:45:12 GMT
Lines: 90
Sender: [e-mail]
Precedence: 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]> Ken Murchison <[e-mail]> writes:

>I just submitted the -06 draft to the I-D editor.  Attached are the 
>diffs between -05 and -06 for those that are interested.

OK, that has tidied up a lot of the issues that we had agreed, leaving
just #1047 as the main outstanding matter.

So all I have at this moment is some nits (Frank also had some, which I
will not repeat here).

I should now be in a position to produce a new USEPRO draft, consistent
with this latest USEFOR, as a basis for our future work.

>+   This also applies to the following header field defined in [RFC2822]:
>+
>+   Message-ID
>+
>+   Several of these headers are mainly of interest to servers, and
>+   servers often need to process these fields very rapidly.

s/to servers/to news servers/ (since that is now the terminology we use)


>    Folding the Newsgroups header field over several lines has been shown
>    to harm propagation significantly......

Actually, it is worse than that. Even WSP will break existing usage, and
it is more than "significantly". I think you have to make it clear that
this is a newly introduced feature, hence "MUST accept" but "MUST NOT
generate" (yet, for some value of "yet" :-) ).


> 3.2.14.  Injection-Info
> 
> 
>-   The "sender" parameter identifies the mailbox of the verified sender
>-   of the article (alternatively, it uses the token "verified" to
>+   The "sender" <parameter> identifies the mailbox of the verified
>+   sender of the article (alternatively, it uses the token "verified" to
>    indicate that at least any addr-spec in the Sender header field of
                                ^^^^^^^^^
                               <addr-spec>
>    the article, or in the From header field if the Sender header field
>-   is absent, is correct).  If an injecting agent can verify sender of
>-   an article, it SHOULD use this parameter in favour of the "posting-
>-   account" parameter.
>+   is absent, is correct).  If a news server can verify the sender of an
>+   article, it SHOULD use this <parameter> in favor of the "posting-
>+   account" <parameter>.


>-Appendix B.  Differences from RFC 1036
>+Appendix B.  Differences from RFC 1036 and its derivatives
> 
>+
>+      Whitespace is permitted in Newsgroups header fields.

        Whitespace (with the possiility of folding) is permitted in
        Newsgroups header fields (but is not to be generated)

[or similar wording, perhaps even mentioning "MUST NOT.]

It should also be noted that further Differences from 1036 are listed in
USEPRO (notably for the syntax of control messages, which are in USEPRO).


> Appendix C.  Differences from RFC 2822
> 
>+
>+      The length of a msg-id MUST NOT exceed 250 octets.
                        ^^^^^^
                       <msg-id>

>+      It is legal for a parser to not accept obsolete syntax, except
>+      that:

Split infinitives can lead to long religious wars :-( . It is usually
safer not to include 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 jBK0lnuf017736; Mon, 19 Dec 2005 16:47:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBK0lnOR017734; Mon, 19 Dec 2005 16:47:49 -0800 (PST)
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 jBK0ll8F017726 for <[e-mail]>; Mon, 19 Dec 2005 16:47:47 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EoVdq-0006eq-8z for [e-mail]; Tue, 20 Dec 2005 01:46:10 +0100
Received: from 1cust159.tnt2.hbg2.deu.da.uu.net ([149.225.12.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 20 Dec 2005 01:46:10 +0100
Received: from nobody by 1cust159.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 20 Dec 2005 01:46:10 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: draft-ietf-usefor-usefor-06
Date:  Tue, 20 Dec 2005 01:40:59 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 124
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: 1cust159.tnt2.hbg2.deu.da.uu.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:

> So I shall email him now to see where he is at.

Thanks, I hope he's well.  Of course we can reference s-o-1036
without historic RFC, but I'd prefer the original (2002?) plan.

---
>> Actually it's s/Older Netnews/Other/ (JFTR, no issue)
> Indeed, because the new [NNTP] also does it.

Not only [NNTP], I saw "headers" in another RFC, completely
unrelated to NetNews.  If necessary I can dig for it.

---
> I think we have to accept that the Message-ID header comes
> from RFC 2822, although we have given it a good mauling.

Well, I don't accept this, because the 2822 Message-ID doesn't
reflect common practice.  We explain all details in chapter
3.1.3.  The introduction of chapter 3 just enumerates the set
of header fields not allowing [CFWS], and Message-ID belongs
to this set.

That this is different from 2822 is beside the point in this
enumeration, it's explained in 3.1.3 and again in appendix C.

Telling the same story three tiimes doesn't help.  We should
get rid of these three lines:

+
+   This also applies to the following header field defined in [RFC2822]:
+

Curious readers will see this, it's obvious with Message-ID as
last (or first) header field in the "no-CFWS" enumeration.

In hardcore nitpicking mode I'd prefer three lines with three
header fields per line - instead of nine lines, or even twelve
lines with this uncalled for "Message-ID is 2822" subsection.

---
> BTW, the new [NNTP] is only waiting for the new SASL
> standard, so that the RFC-Editor doesn't have any dangling
> References. Is Alexey listening?

They're almost ready as far as I can judge it as lurker.  Sam
refuses to sponsor CRAM-MD5 as DS, but that doesn't affect the
core spec.  OT:  I have a working CRAM-MD5 implementation, can
I just submit an "implementation and interoperability report" ?

---
>> Somehow we managed to mention "cmsg" nowhere - it should at
>> least show up in appendix B (differences from 1036).

> No, because is is not a matter of syntax. The whole ctl/cmsg
> mess is thoroughly covered in USEPRO, with strong
> discouragement for its continued use.

It is a syntax issue, we removed the concept of a "structured"
Subject header field.  After discussing "Re: the note between
Do and Mi" for *_years_* in *_thousands_* of articles.  We did
not discuss this because it was funny, it's a major difference
from 1036.  The least we can do is to mention it in appendix B.

---
>> Oops, why on earth do we exclude "(" from article-locator ?
>> That's probably an obsolete CFWS oddity, proposed new ABNF:

> Yes, it was for comments.

Then let's get rid of it.  I'm perverse, I try to "see" the
raw "idea" or "concept" behind any ABNF oddity, from <toplabel>
over <id-domain> - some say <id-right> because their concept is
in fact slightly different - down to ")" in <article-locator>.

---
> We never went as far as setting up an IANA Registry for the
> <parameter>s in this new header. If you want it done
> (technically, there is no reason why not) they please propose
> it.

No, I want that those who invent new Injection-Info parameters
go to that trouble, "we" (TINW) don't need this at the moment.

---
>>> +   that news server received the article.  For security reasons, it
>>>     SHOULD be in a cryptic notation understandable only by the
>> [...]
>>> +   administrator of the news server.

>> How about s/For security reaons, it/It/ ?  It could be also
>> for privacy reasons, and in Germany it could be for legal
>> reasons.

> Or you could say "For security and other reasons,". I have no
> problem either way.

Same here.

---
>>> +   is absent, is correct).  If a news server can verify the sender of an
>>> +   article, it SHOULD use this <parameter> in favor of the "posting-
>>> +   account" <parameter>.

>> After talking with his legal department.  In other words,
>> this can't be a SHOULD, pleae delete this statement.

s/pleae/please/

> No, the WG fought long and hard between those who wanted all
> relevant tracing information exposed, so that malefactors
> could be caught, and those who wanted to protect the privacy
> of posters. The upshot was an agreed paragraph setting out
> the pros and cons, which eventually got moved to USEAGE. That
> is the proper place to discuss this.

The SHOULD makes no technical sense, and it might be illegal in
my country without the prior and explicit consent of the sender.

See also BCP 14 at <http://tools.ietf.org/html/2119#section-6>

                           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 jBJNEAPj008599; Mon, 19 Dec 2005 15:14:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJNEAMc008598; Mon, 19 Dec 2005 15:14:10 -0800 (PST)
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 jBJNE8ns008589 for <[e-mail]>; Mon, 19 Dec 2005 15:14:09 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EoUBF-0007yT-Op for [e-mail]; Tue, 20 Dec 2005 00:12:33 +0100
Received: from 1cust159.tnt2.hbg2.deu.da.uu.net ([149.225.12.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 20 Dec 2005 00:12:33 +0100
Received: from nobody by 1cust159.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 20 Dec 2005 00:12:33 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: IANA considerations
Date:  Tue, 20 Dec 2005 00:05:15 +0100
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: 1cust159.tnt2.hbg2.deu.da.uu.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>

Ken Murchison wrote:

> What is the reasoning behind creating a separate I-D?

The IANA header registry stuff is kind of boring.  I like it
very much, but my tastes are a bit extraordinary.  Adding the
about 22 KB (plus more fields minus boilerplate) in a revised

<http://tools.ietf.org/html/draft-lindsey-hdrreg-netnews>

to the about 64 KB in draft-ietd-usefor-usefor would result
in about one quarter "IANA header registration considerations".

Therefore I think it's better to split this...

> why not include the header registry in our document?

...but I don't insist on it.  It's only a matter of taste:

As it is draft-ietf-usefor-usefor is short and sweet with no
nonsense.  14 pages of header registrations would inflate it.

                       Bye, Frank




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJI1NCo062487; Mon, 19 Dec 2005 10:01:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJI1Nsg062486; Mon, 19 Dec 2005 10:01:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJI1Mc6062480 for <[e-mail]>; Mon, 19 Dec 2005 10:01:23 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBJI1LRx011375 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Mon, 19 Dec 2005 13:01:22 -0500
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 13:01:30 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-ietf-usefor-usefor-06
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann wrote:
> Ken Murchison wrote:
> 
> 
>>diffs between -05 and -06 for those that are interested.
> 
> 
> Thanks, let's see how far we get using this as input:
> 
> 
>>+   The normative reference to RFC 2234 and the informative reference to
>>+   RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and
> 
> 
> No issue, but 4234 is published: s/2234/4234/g

Fixed.

>>+   o  Removed RFC 0821 as a normative reference.
> 
> 
> JFTR: 2821.

Fixed.

>>       NOTE: Older Netnews specifications used the term "header" as a
>>       synonym for what [RFC2822] calls "header field". 
> 
> 
> Actually it's s/Older Netnews/Other/ (JFTR, no issue)

Fixed.



> 
>>+   and standards [RFC0977] might have trouble with the full range of 
> 
> 
> BTW, often you say [NNTP], here you have [RFC0977], how about
> [NNTP] everywhere ?  That would also eliminate the instructions
> for the RFC editor (together with s/2234/4234/ - see above).

Fixed.


> 
>>+   The following <newsgroup-name&gts have been used for specific
> 
> 
> Missing semicolon in the source....^^^

Fixed.



> 
>>-      NOTE: Historically, the <tail-entry> indicated the name of the
>>-      sender.  If not used for this purpose, the string "not-for-mail"
>>-      is often used instead (since at one time the whole path could be
>>-      used as a mail address for the sender).
> 
> 
> What's wrong with that note ?

Editorial mistake.  Its been returned to the document.



> With old xml2rfc versions a <vspace /> could enforce a line
> break before <date-time>.  Now &lt;date-&wj;time&gt; might do
> it, or better use &lt;date&nbhy;time&gt; (non-breaking-hyphen).
> 
> 
>>+   See the remarks under Section 3.1.2 regarding the syntax of <date-
>>+   time> and the requirements and recommendations to which it is
> 
> 
> Dito, replace it globally.

Fixed.



>>+      <parameter> may provide additional information about true origin
>>+      of the article.
> 
> 
> Missing article or DEnglish on my side.

Fixed.


> 
> 
>>+   that news server received the article.  For security reasons, it
>>    SHOULD be in a cryptic notation understandable only by the
> 
> [...]
> 
>>+   administrator of the news server.
> 
> 
> How about s/For security reaons, it/It/ ?  It could be also for
> privacy reasons, and in Germany it could be for legal reasons.

Using Charles' suggested text.



>>+   the generation of internationalized <newsgroup name>s for use in
> 
> 
> Missing "-" (or rather &nbhy; ;-)

Fixed.


> 
> 
>>+   Content-Type: multipart/mixed
>>+   (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
> 
> 
>>+   Content-Type: multipart/digest;
>>+   boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
> 
> 
> You need a leading space in the second line for the folding.
> If it's too long replace xyzzy by something that's shorter.

Fixed.


> 
> 
>>    [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
>>               Specifications: ABNF", RFC 2234, November 1997.
> 
> 
> 4234
> 
> 
>>+   [RFC0977]  Kantor, B. and P. Lapsley, "Network News Transfer
>>+              Protocol", RFC 977, February 1986.
> 
> 


Fixed.



-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJHDLxp058159; Mon, 19 Dec 2005 09:13:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJHDLtv058158; Mon, 19 Dec 2005 09:13:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJHDKfc058151 for <[e-mail]>; Mon, 19 Dec 2005 09:13:20 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-67-144.midband.mdip.bt.net ([81.144.67.144]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a6ea2e.7cc7.1b2 for [e-mail]; Mon, 19 Dec 2005 17:13:18 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBJHCNs17161 for [e-mail]; Mon, 19 Dec 2005 17:12:23 GMT
To: [e-mail]
Xref: clerew local.usefor:22766
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: draft-ietf-usefor-usefor-06
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Mon, 19 Dec 2005 16:29:35 GMT
Lines: 196
Sender: [e-mail]
Precedence: 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:

>Ken Murchison wrote:


>Apparently Henry dropped his plan to publish s-o-1036 as
>"historic", that's sad.

He suddenly vanished from this list (and all his other usual haunts) and
his personal domain (spsystems.net) went dead.

I just Googled for him, and it seems that he posted nothing to Usenet
between July 27th and October 11th, at which point his signature started
to contain

spsystems.net is temporarily off the air; | Henry Spencer 
mail to henry at zoo.utoronto.ca instead.  | [e-mail]

So I shall email him now to see where he is at. I would certainly like to
be able to get rid of those two historical appendices, which are simply
verbatim copies from s-o-1036.


>>        NOTE: Older Netnews specifications used the term "header" as a
>>        synonym for what [RFC2822] calls "header field". 

>Actually it's s/Older Netnews/Other/ (JFTR, no issue)

Indeed, because the new [NNTP] also does it.


>Add Message-ID to the "defined in this document" set, and get
>rid of the 2822-set:  Our Message-ID is still different from
>(2)822, and it's defined here.  You have the full discloure
>later in 3.1.3:

I think we have to accept that the Message-ID header comes from RFC 2822,
although we have given it a good mauling.

>> +   and standards [RFC0977] might have trouble with the full range of

I dislike that convention of writing [RFC0977] rather than [RFC977]. Yes,
I know why it is done (getting the References sorted sensibly - but I
would rather fix that by hand by negotiation with the RFC-Editor after
last call).

>BTW, often you say [NNTP], here you have [RFC0977], how about
>[NNTP] everywhere ?  That would also eliminate the instructions
>for the RFC editor (together with s/2234/4234/ - see above).

Yup. BTW, the new [NNTP] is only waiting for the new SASL standard, so
that the RFC-Editor doesn't have any dangling References. Is Alexey
listening?

>> +   The following <newsgroup-name&gts have been used for specific

>Missing semicolon in the source....^^^

Yup.

>> +      and "ctl" was formerly used to indicate a <control-command> within
>> +      the Subject header field.

>Somehow we managed to mention "cmsg" nowhere - it should at
>least show up in appendix B (differences from 1036).

No, because is is not a matter of syntax. The whole ctl/cmsg mess is
thoroughly covered in USEPRO, with strong discouragement for its continued
use.


>> -      NOTE: Historically, the <tail-entry> indicated the name of the
>> -      sender.  If not used for this purpose, the string "not-for-mail"
>> -      is often used instead (since at one time the whole path could be
>> -      used as a mail address for the sender).

>What's wrong with that note ?

I agree. Please can we have it back?



>>                       ; except '(' and ';'

>Oops, why on earth do we exclude "(" from article-locator ?
>That's probably an obsolete CFWS oddity, proposed new ABNF: 

Yes, it was for comments.

OTOH, there may be agents out there that strip comments from all
unstructured headers without looking first to see that they are doing, so
it would probably be safer to leave the restriction in place.


>> +   other unlisted <parameter>s SHOULD NOT be used unless defined in
>> +   extensions to this standard.

>Could be also a MUST NOT as far as I'm concerned, if they want
>new tricks let them create a IANA registry for their funny
>inventions.

There would be no interoperability, so I don't think we can justify
"MUST". We never went as far as setting up an IANA Registry for the
<parameter>s in this new header. If you want it done (technically, there is
no reason why not) they please propose it.

>> it is RECOMMENDED that folding is
>[...]
>> +   not used within any <parameter> (but only before or after the ";"
>> +   separating those <parameter>s), and that comments are only used
>> +   following the last <parameter>.

>The former is also a general rule, should we add a pointer to
>2822 2.2.3 ?  It's a 2822-SHOULD, not some red-is-green excuse.

Actually, it goes further than that rule in RFC 2822, but I have no problem
with adding a pointer.

>> +      <parameter> may provide additional information about true origin
>> +      of the article.

>Missing article or DEnglish on my side.

Yup.

>> +   that news server received the article.  For security reasons, it
>>     SHOULD be in a cryptic notation understandable only by the
>[...]
>> +   administrator of the news server.

>How about s/For security reaons, it/It/ ?  It could be also for
>privacy reasons, and in Germany it could be for legal reasons.

Or you could say "For security and other reasons,". I have no problem
either way.

>> +   is absent, is correct).  If a news server can verify the sender of an
>> +   article, it SHOULD use this <parameter> in favor of the "posting-
>> +   account" <parameter>.

>After talking with his legal department.  In other words, this
>can't be a SHOULD, pleae delete this statement.

No, the WG fought long and hard between those who wanted all relevant
tracing information exposed, so that malefactors could be caught, and
those who wanted to protect the privacy of posters. The upshot was an
agreed paragraph setting out the pros and cons, which eventually got moved
to USEAGE. That is the proper place to discuss this.

>> +   The "mail-complaints-to" <parameter> specifies mailbox(es) for
>> +   sending complaints concerning the behavior of the poster of the
>> +   article.

>Obvious, doesn't need an explanation.

It is usualy to describe (however briefly) the meaning of all features
introduced by the syntax.

>> +   the generation of internationalized <newsgroup name>s for use in

>Missing "-" (or rather &nbhy; ;-)

Yup.

>> +   Content-Type: multipart/mixed
>> +   (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")

>> +   Content-Type: multipart/digest;
>> +   boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy

>You need a leading space in the second line for the folding.
>If it's too long replace xyzzy by something that's shorter.

Yup.


>> +      There are numerous other small changes, clarifications and
>> +      enhancements.

>The removal of Subject: cmsg is not a small change, it's among
>the few things why we bother to create this future "1036ter".

Ken's 1036-changes text is largely taken from USEPRO. But there are a few
items that will still remain in USEPRO because they relate to the
protocol, or to the syntax of control messages. This is one of them.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJGP9CP054142; Mon, 19 Dec 2005 08:25:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBJGP98u054140; Mon, 19 Dec 2005 08:25:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBJGP82p054133 for <[e-mail]>; Mon, 19 Dec 2005 08:25:09 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.18] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBJGP88P023946 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Mon, 19 Dec 2005 11:25:08 -0500
Message-ID: <[e-mail]>
Date: Mon, 19 Dec 2005 11:25:15 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: IANA considerations
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann wrote:
> Hi, here's my proposal for the missing IANA considerations:
> 
> 1 - we create a simple draft-ietf-usefor-hdrreg-00.txt, that
>     would be a WG -00, so we need Alexey's or Harald's OK
> 
> 2 - we add an informative reference to that I-D in the future
>     "WG last call xmas edition" (draft-ietf-usefor-usefor-07),
>     with IANA considerations as a pointer to the hddrreg-draft

What is the reasoning behind creating a separate I-D?  Since we're 
(re)defining Usenet in USEFOR, why not include the header registry in 
our document?  Email and HTTP have separate documents because the 
protocol documents predated RFC 3864.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBHJdwCp005077; Sat, 17 Dec 2005 11:39:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBHJdwwE005076; Sat, 17 Dec 2005 11:39:58 -0800 (PST)
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 jBHJduV1005070 for <[e-mail]>; Sat, 17 Dec 2005 11:39:56 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Enhsb-0007rG-6c for [e-mail]; Sat, 17 Dec 2005 20:38:05 +0100
Received: from c-134-89-138.hh.dial.de.ignite.net ([62.134.89.138]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 17 Dec 2005 20:38:05 +0100
Received: from nobody by c-134-89-138.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 17 Dec 2005 20:38:05 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  IANA considerations
Date:  Sat, 17 Dec 2005 20:34:35 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 76
Message-ID:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-134-89-138.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>

Hi, here's my proposal for the missing IANA considerations:

1 - we create a simple draft-ietf-usefor-hdrreg-00.txt, that
    would be a WG -00, so we need Alexey's or Harald's OK

2 - we add an informative reference to that I-D in the future
    "WG last call xmas edition" (draft-ietf-usefor-usefor-07),
    with IANA considerations as a pointer to the hddrreg-draft

3 - in essence that news header registry draft would be like...

http://www.ninebynine.org/IETF/Messaging/HdrRegistry/draft-lindsey-hdrreg-netnews-01.xml

...with minor editorial changes for all details:

Update boilerplate s/full3667/full3978/ , docName, WG, date,
and normative reference to 3864.  Remove the 2119 keywords.

Add informative reference to 4021, add normative reference to
draft-ietf-usefor-usefor.  Remove references to 1036 and 2119.

s/1036/draft-ietf-usefor-usefor/g
s/informational/standard/g

Split the registered header fields into two (or maybe three)
categories (old chapter 2 => new chapters 2, 3, and maybe 4).

One chapter for the deprecated / historic news header fields,
status "historic":  

       NNTP-Posting-Date       (no spec., dummy source Usefor)
       NNTP-Posting-Host       (no spec., dummy source Usefor)
       Relay-Version           (no spec.  => Usefor or 1036 ?)
       Posted-Version          (no spec.  => Usefor or 1036 ?)
       Date-Received           (no spec.  => Usefor or 1036 ?)
       Also-Control            (Usefor or s-o-1036 ?)
       See-Also                (Usefor or s-o-1036 ?)
       Article-Names           (Usefor or s-o-1036 ?)
       Article-Updates         (Usefor or s-o-1036 ?)

One chapter for the hardcore Netnews header fields, as in the
old 2004 draft, status "standard":

       Message-ID
       References
       Newsgroups
       Path
       Control
       Supersedes
       Followup-To
       Expires
       Distribution
       Supersedes
       Approved
       Xref
       Organization
       Summary
       Lines                 (comment: obsolescent)
       Archive               (comment: new)
       User-Agent            (comment: new)
       Injection-Info        (comment: new)
       Injection-Date        (comment: new)
         
Maybe a chapter for the most important mail header fields also
_required_ (= mandatory) in NetNews, with essentially the same
syntax and semantics as in mail / 2822, status "standard":

       Date
       From
       Subject

Or add this to the "main" chapter (?)  Dummy IANA and security
considerations as is, no I18N considerations, ready.

                         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 jBH2O5BU015420; Fri, 16 Dec 2005 18:24:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBH2O524015419; Fri, 16 Dec 2005 18:24:05 -0800 (PST)
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 jBH2O2fJ015412 for <[e-mail]>; Fri, 16 Dec 2005 18:24:03 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EnRii-0007yk-Qd for [e-mail]; Sat, 17 Dec 2005 03:22:48 +0100
Received: from 1cust213.tnt3.hbg2.deu.da.uu.net ([149.225.14.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 17 Dec 2005 03:22:48 +0100
Received: from nobody by 1cust213.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 17 Dec 2005 03:22:48 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: draft-ietf-usefor-usefor-06
Date:  Sat, 17 Dec 2005 03:17:24 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 192
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: 1cust213.tnt3.hbg2.deu.da.uu.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>

Ken Murchison wrote:

> diffs between -05 and -06 for those that are interested.

Thanks, let's see how far we get using this as input:

> +   The normative reference to RFC 2234 and the informative reference to
> +   RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and

No issue, but 4234 is published: s/2234/4234/g

> +   o  Removed RFC 0821 as a normative reference.

JFTR: 2821.

>     o  IANA considerations (the Klyne message header registry is now
>        official as RFC 3864)?.

Oops, -05 had no IANA considerations at all, that's wrong.

> -   Appendix B.  Differences from RFC 1036
> +   Appendix B.  Differences from RFC 1036 and its derivatives

Apparently Henry dropped his plan to publish s-o-1036 as
"historic", that's sad.

> +   A best common practice document, [USEAGE], describes

Maybe s/, [USEAGE], describes/ will describe/ - I won't bet
that it will be finished, let alone soon or as a BCP, and an
approved USEFOR / USEPRO pair blocked in the RFC editor queue
isn't what "we" (TINW) want.

>        NOTE: Older Netnews specifications used the term "header" as a
>        synonym for what [RFC2822] calls "header field". 

Actually it's s/Older Netnews/Other/ (JFTR, no issue)

> +   The following header fields defined in this document do not allow
> +   comments (CFWS):
[...]
> +   This also applies to the following header field defined in [RFC2822]:
> +
> +   Message-ID

Add Message-ID to the "defined in this document" set, and get
rid of the 2822-set:  Our Message-ID is still different from
(2)822, and it's defined here.  You have the full discloure
later in 3.1.3:

> +   and standards [RFC0977] might have trouble with the full range of 

BTW, often you say [NNTP], here you have [RFC0977], how about
[NNTP] everywhere ?  That would also eliminate the instructions
for the RFC editor (together with s/2234/4234/ - see above).

> +   The following <newsgroup-name&gts have been used for specific

Missing semicolon in the source....^^^

> +      and "ctl" was formerly used to indicate a <control-command> within
> +      the Subject header field.

Somehow we managed to mention "cmsg" nowhere - it should at
least show up in appendix B (differences from 1036).

> +                      *( ( path-identity / path-keyword /
[...]

I'll look at the <path-list> etc. ABNF in the complete draft.

> -      NOTE: Historically, the <tail-entry> indicated the name of the
> -      sender.  If not used for this purpose, the string "not-for-mail"
> -      is often used instead (since at one time the whole path could be
> -      used as a mail address for the sender).

What's wrong with that note ?

> +   A <path-diagnostic> is an item inserted into the Path header for
> +   purposes other than to indicate the name of a site.  One commonly
> +   observed usage is to insert an IP address.  The colon (":") is
> +   permitted in order to allow IPv6 addresses to be inserted; note that
> +   this will cause interoperability problems at older sites that regard
> +   ":" as a <path-delimiter> and have neighbors whose names have 4 or
> +   fewer characters, and where all the characters are valid HEX digits.

Seconded, no amount of MUSTard and weird colon encoding schemes
could obfuscate the fact that this is just ugly whatever we do.

> +   See the remarks under Section 3.1.2 regarding the syntax of <date-
> +   time> and the requirements and recommendations to which it is

With old xml2rfc versions a <vspace /> could enforce a line
break before <date-time>.  Now &lt;date-&wj;time&gt; might do
it, or better use &lt;date&nbhy;time&gt; (non-breaking-hyphen).

> +   See the remarks under Section 3.1.2 regarding the syntax of <date-
> +   time> and the requirements and recommendations to which it is

Dito, replace it globally.

>                       ; except '(' and ';'

Oops, why on earth do we exclude "(" from article-locator ?
That's probably an obsolete CFWS oddity, proposed new ABNF: 

-  article-locator =  1*( %x21-27 / %x29-3A / %x3C-7E )
-                     ; US-ASCII printable characters
-                     ; except '(' and ';'
+  article-locator =  1*( %x21-3A / %x3C-7E )
+                     ; VCHAR excl. colon ":"

>     sender-value    =  mailbox / "verified"

One of the hidden mines, let's see what happens, it deserves a
[Discuss].

> +   other unlisted <parameter>s SHOULD NOT be used unless defined in
> +   extensions to this standard.

Could be also a MUST NOT as far as I'm concerned, if they want
new tricks let them create a IANA registry for their funny
inventions.

> it is RECOMMENDED that folding is
[...]
> +   not used within any <parameter> (but only before or after the ";"
> +   separating those <parameter>s), and that comments are only used
> +   following the last <parameter>.

The former is also a general rule, should we add a pointer to
2822 2.2.3 ?  It's a 2822-SHOULD, not some red-is-green excuse.

> +      <parameter> may provide additional information about true origin
> +      of the article.

Missing article or DEnglish on my side.

> +   that news server received the article.  For security reasons, it
>     SHOULD be in a cryptic notation understandable only by the
[...]
> +   administrator of the news server.

How about s/For security reaons, it/It/ ?  It could be also for
privacy reasons, and in Germany it could be for legal reasons.

> +   is absent, is correct).  If a news server can verify the sender of an
> +   article, it SHOULD use this <parameter> in favor of the "posting-
> +   account" <parameter>.

After talking with his legal department.  In other words, this
can't be a SHOULD, pleae delete this statement.

> +   The "mail-complaints-to" <parameter> specifies mailbox(es) for
> +   sending complaints concerning the behavior of the poster of the
> +   article.

Obvious, doesn't need an explanation.

> +   the generation of internationalized <newsgroup name>s for use in

Missing "-" (or rather &nbhy; ;-)

> +   Content-Type: multipart/mixed
> +   (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")

> +   Content-Type: multipart/digest;
> +   boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy

You need a leading space in the second line for the folding.
If it's too long replace xyzzy by something that's shorter.

>     [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
>                Specifications: ABNF", RFC 2234, November 1997.

4234

> +   [RFC0977]  Kantor, B. and P. Lapsley, "Network News Transfer
> +              Protocol", RFC 977, February 1986.

See above.

> +      There are numerous other small changes, clarifications and
> +      enhancements.

The removal of Subject: cmsg is not a small change, it's among
the few things why we bother to create this future "1036ter".

Otherwise it's ready, isn't it ?  I haven't checked the ABNF
for the path.
                      Tnx & 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 jBGMxJVt094765; Fri, 16 Dec 2005 14:59:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBGMxJ3n094764; Fri, 16 Dec 2005 14:59:19 -0800 (PST)
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 jBGMxH6v094758 for <[e-mail]>; Fri, 16 Dec 2005 14:59:18 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11DF325971F; Fri, 16 Dec 2005 23:58:31 +0100 (CET)
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 20733-02; Fri, 16 Dec 2005 23:58:27 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id C2F4925970E; Fri, 16 Dec 2005 23:58:27 +0100 (CET)
Date: Sat, 17 Dec 2005 00:02:07 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Ken Murchison <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-usefor-usefor-06
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>

Thank you, Ken!


--On fredag, desember 16, 2005 15:07:55 -0500 Ken Murchison 
<[e-mail]> wrote:

> I just submitted the -06 draft to the I-D editor.  Attached are the diffs
> between -05 and -06 for those that are interested.
>
> --
> Kenneth Murchison
> Systems Programmer
> Carnegie Mellon University






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGK9rJN076905; Fri, 16 Dec 2005 12:09:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBGK9rJR076904; Fri, 16 Dec 2005 12:09:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP1-ETH1.andrew.cmu.edu [128.2.10.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGK9pg1076895 for <[e-mail]>; Fri, 16 Dec 2005 12:09:52 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.17] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id jBGK7n6M022936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Fri, 16 Dec 2005 15:09:23 -0500
Message-ID: <[e-mail]>
Date: Fri, 16 Dec 2005 15:07:55 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: draft-ietf-usefor-usefor-06
Content-Type: multipart/mixed; boundary="------------070504090607030209040906"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

This is a multi-part message in MIME format.
--------------070504090607030209040906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I just submitted the -06 draft to the I-D editor.  Attached are the 
diffs between -05 and -06 for those that are interested.

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

--------------070504090607030209040906
Content-Type: text/x-patch;
 name="draft-ietf-usefor-usefor-05-06.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-ietf-usefor-usefor-05-06.diff"

--- /home/ken/Desktop/draft-ietf-usefor-usefor-05.unpg	2005-12-15 14:59:16.000000000 -0500
+++ /home/ken/Desktop/draft-ietf-usefor-usefor-06.unpg	2005-12-16 14:44:25.000000000 -0500
@@ -3,16 +3,16 @@
 
 
 Usenet Format Working Group                            K. Murchison, Ed.
-Internet-Draft                                        Oceana Matrix Ltd.
+Internet-Draft                                Carnegie Mellon University
 Obsoletes: 1036 (if approved)                                 C. Lindsey
-Expires: January 2, 2006                        University of Manchester
+Expires: June 19, 2006                          University of Manchester
                                                                  D. Kohn
                                                         Skymoon Ventures
-                                                               July 2005
+                                                       December 16, 2005
 
 
                          Netnews Article Format
-                      draft-ietf-usefor-usefor-05
+                      draft-ietf-usefor-usefor-06
 
 Status of this Memo
 
@@ -37,7 +37,7 @@
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on January 2, 2006.
+   This Internet-Draft will expire on June 19, 2006.
 
 Copyright Notice
 
@@ -53,9 +53,44 @@
 
 Note to the RFC Editor
 
-   The normative reference to RFC 2234 may be replaced by
-   draft-crocker-abnf-rfc2234bis should it reach RFC status before this
-   one.
+   The normative reference to RFC 2234 and the informative reference to
+   RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and
+   draft-ietf-nntpext-base respectively should one or both of those of
+   those documents reach RFC status before this one.
+
+Changes since draft-ietf-usefor-usefor-05
+
+   o  Resolved ticket #1003 (msg-id).
+
+   o  Resolved ticket #1021 (Newsgroups description and exceptions).
+
+   o  Resolved ticket #1028 (fixed ABNF for orig-date).
+
+   o  Began adding text for ticket #1032 (diff from RFC 1036).
+
+   o  Resolved ticket #1046 (MIME boundary security considerations).
+
+   o  Addressed ticket #1047 (Path header field delimiters and
+      components) using Harald's suggested text -- Still an open issue.
+
+   o  Resolved ticket #1052 (diffs from RFC 2822).
+
+   o  Resolved ticket #1053 (relationship to RFC 2822).
+
+   o  Resolved ticket #1079 (header fields which don't permit CFWS).
+
+   o  Applied text from ticket #1080 (Injection-Info MIME params).
+
+   o  Resolved ticket #1082 (Approved header field semantics).
+
+   o  Resolved ticket #1088 (Injection-Date mandatory/optional).
+
+   o  Resolved ticket #1102 (Definition of "agents", etc).
+
+   o  Removed RFC 0821 as a normative reference.
+
+   o  Miscellaneous editorial changes.
+
 
 Changes since draft-ietf-usefor-usefor-04
 
@@ -173,12 +208,7 @@
 
 Issues to be addressed
 
-   o  MIME boundary security considerations.
-
-   o  Path header field delimiters and components.
-
-   o  Complete appendixes for changes from RFC 1036 and differences from
-      RFC 2822.
+   o  Ticket #1047: Path header field delimiters and components.
 
    o  IANA considerations (the Klyne message header registry is now
       official as RFC 3864)?.
@@ -234,7 +264,7 @@
      6.1.  Normative References
      6.2.  Informative References
    Appendix A.  Acknowledgements
-   Appendix B.  Differences from RFC 1036
+   Appendix B.  Differences from RFC 1036 and its derivatives
    Appendix C.  Differences from RFC 2822
    Authors' Addresses
    Intellectual Property and Copyright Statements
@@ -268,9 +298,9 @@
    This document focuses on the syntax and semantics of Netnews
    articles.  [USEPRO] is also a standards-track document, and describes
    the protocol issues of Netnews articles, independent of transport
-   protocols such as [NNTP].  An best common practice document,
-   [USEAGE], describes implementation recommendations to improve
-   interoperability and usability.
+   protocols such as [NNTP].  A best common practice document, [USEAGE],
+   describes implementation recommendations to improve interoperability
+   and usability.
 
    This specification is intended as a definition of what article
    content format is to be passed between systems.  Though some news
@@ -309,11 +339,11 @@
    article" may lack some mandatory header fields.
 
    A "message identifier" (Section 3.1.3) is a unique identifier for an
-   article, usually supplied by the "posting agent" which posted it or,
-   failing that, by the "injecting agent".  It distinguishes the article
+   article, usually supplied by the "user agent" which posted it or,
+   failing that, by the "news server".  It distinguishes the article
    from every other article ever posted anywhere.  Articles with the
    same message identifier are treated as if they are the same article
-   regardless of any differences in the body or header.
+   regardless of any differences in the body or header fields.
 
    A "newsgroup" is a single news forum, a logical bulletin board,
    having a name and nominally intended for articles on a specific
@@ -328,40 +358,32 @@
    implemented partially or entirely in software.
 
    A "poster" is the person or software that composes and submits a
-   possibly compliant article to a "posting agent".  The poster is
+   possibly compliant article to a "user agent".  The poster is
    analogous to [RFC2822]'s author.
 
-   A "posting agent" is the software that assists posters to prepare
-   proto-articles, in compliance with this standard.  The proto-article
-   is then passed on to an "injecting agent" for final checking and
-   injection into the news stream.  If the article is not compliant, or
-   is rejected by the injecting agent, then the posting agent informs
-   the poster with an explanation of the error.
-
    A "reader" is the person or software reading news articles.
 
-   A "reading agent" is software which presents articles to a reader.
-
    A "followup" is an article containing a response to the contents of
    an earlier article, its "precursor".  Every followup includes a
    "References" header field identifying that precursor (but note that
    non-followup articles may also use a References header field).
 
-   A "followup agent" is a combination of reading agent and posting
-   agent that aids in the preparation and posting of a followup.
-
-   Posting, reading and followup agents (which are usually just
-   different services provided by the same piece of software) are known
-   collectively as "user agents".
-
-   An "injecting agent" takes the finished article from the posting
-   agent (often via the [NNTP] "post" command) performs some final
-   checks and passes it on to a relaying agent for general distribution.
-
    A "control message" is an article which is marked as containing
-   control information; a relaying or serving agent receiving such an
-   article may (subject to the policies observed at that site) take
-   actions beyond just filing and passing on the article.
+   control information; a news server receiving such an article may
+   (subject to the policies observed at that site) take actions beyond
+   just filing and passing on the article.
+
+   A "news server" is software that may accept articles from a "user
+   agent", and/or make articles available to user agents, and/or
+   exchange articles with other news servers.
+
+   A "user agent" is software that may help posters submit proto-
+   articles to a news server, and/or fetch articles from a news server
+   and present them to a reader, and/or assist the reader in creating
+   articles and followups.
+
+   The generic term "agent" is used when describing requirements that
+   apply to both user agents and news servers.
 
 1.6.  Structure of This Document
 
@@ -381,14 +403,37 @@
 
 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.
+   An article is said to be conformant to this specification if it
+   conforms to the format specified in [RFC2822] 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.
+
+   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 agents MUST NOT generate productions of
+   such syntax.
+
+   Articles are conformant if they use the "GMT" <zone>, as specified in
+   Section 3.1.2.
+
+   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 conforming to this specification MUST generate only conformant
+   articles.
+
+   The text below uses ABNF to specify restrictions on the syntax
+   specified in [RFC2822]; this grammar is intended to be more
+   restrictive than the [RFC2822] grammar.  Articles must conform to the
+   ABNF specified in [RFC2822].
+
+   Articles must also conform to the restrictions specified here, both
+   those that are expressed as text and those that are expressed as
+   ABNF.
 
       NOTE: Older Netnews specifications used the term "header" as a
       synonym for what [RFC2822] calls "header field".  This document
@@ -415,9 +460,9 @@
 
    o  All agents MUST generate header fields so that at least one space
       immediately follows the ':' separating the header field name and
-      the header field body (for compatibility with deployed software).
-      News agents MAY accept header fields which do not contain the
-      required space.
+      the header field body (for compatibility with deployed software,
+      including [NNTP] servers).  News agents MAY accept header fields
+      which do not contain the required space.
 
    o  Every line of a header field body (including the first and any
       that are subsequently folded) MUST contain at least one non-
@@ -459,7 +504,7 @@
 
    For the purposes of Section 5 of [RFC2047], all header fields defined
    in Section 3 of this standard are to be considered as "extension
-   message header fields" (insofar as they are not already considered
+   message header fields" (insofar as they are not already so considered
    under the existing Email standards), permitting the use of [RFC2047]
    encodings within any <unstructured> header field, or within any
    <comment> or <phrase> permittted within any structured header field.
@@ -492,6 +537,25 @@
 
    Each of these header fields may occur at most once in a news article.
 
+   The following header fields defined in this document do not allow
+   comments (CFWS):
+
+   Newsgroups
+   Path
+   Followup-to
+   Control
+   Supersedes
+   Distribution
+   Xref
+   Lines
+
+   This also applies to the following header field defined in [RFC2822]:
+
+   Message-ID
+
+   Several of these headers are mainly of interest to servers, and
+   servers often need to process these fields very rapidly.
+
 3.1.  Mandatory Header Fields
 
    Each news article conformant with this specification MUST have
@@ -514,11 +578,11 @@
    Therefore, agents MUST accept <date-time> constructs which use the
    "GMT" zone.
 
-   from            =  "Date:" SP date-time CRLF
+   orig-date       =  "Date:" SP date-time CRLF
 
-   NOTE: This specification does not change [RFC2822], which says that
-   agents MUST NOT generate <date-time> constructs which include any
-   zone names defined by <obs-zone>.
+      NOTE: This specification does not change [RFC2822], which says
+      that agents MUST NOT generate <date-time> constructs which include
+      any zone names defined by <obs-zone>.
 
    Software that accepts dates with unknown timezones SHOULD treat such
    timezones as equivalent to "-0000" when comparing dates, as specified
@@ -533,12 +597,13 @@
    The Message-ID header field contains a single unique message
    identifier.  Netnews is more dependent on message identifier
    uniqueness and fast comparison than Email is, and some news software
-   might have trouble with the full range of possible <msg-id>s
-   permitted by [RFC2822]; this section therefore restricts the syntax
-   of <msg-id> as compared to Section 3.6.4 of [RFC2822].  The global
-   uniqueness requirement for <msg-id> in [RFC2822] is to be understood
-   as applying across all protocols using such message identifiers, and
-   across both Email and Netnews in particular.
+   and standards [RFC0977] might have trouble with the full range of
+   possible <msg-id>s permitted by [RFC2822]; this section therefore
+   restricts the syntax of <msg-id> as compared to Section 3.6.4 of
+   [RFC2822].  The global uniqueness requirement for <msg-id> in
+   [RFC2822] is to be understood as applying across all protocols using
+   such message identifiers, and across both Email and Netnews in
+   particular.
 
    message-id      =  "Message-ID:" SP [FWS] msg-id [FWS] CRLF
 
@@ -600,14 +665,14 @@
       case-sensitive (and thus, once created, are not to be altered
       during subsequent transmission or copying)
 
-   This is to simplify processing by relaying and serving agents and to
-   ensure interoperability with existing implementations and compliance
-   with [NNTP].  Thus, whereas under [RFC2822] the following <msg-id>s
-   would be considered semantically equivalent,
-
-   <[e-mail]>
-   <"abcd"@example.com>
-   <"ab\cd"@example.com>
+   This is to simplify processing by news servers and to ensure
+   interoperability with existing implementations and compliance with
+   [NNTP].  Thus, whereas under [RFC2822] the following <msg-id>s would
+   be considered semantically equivalent,
+
+   <[e-mail]>
+   <"ab.cd"@example.com>
+   <"ab.\cd"@example.com>
 
    only the first of them is syntactically permitted by this standard,
    and hence a simple comparison of octets will always suffice to
@@ -622,8 +687,8 @@
    fashion.  Implementations MUST NOT generate two Message-IDs where the
    only difference is the case of characters in the <id-right> part.
 
-   If domain literals are used, the syntax found in Section 4.1.3 of
-   [RFC2821] is RECOMMENDED.
+   When generationg a <msg-id>, implementations SHOULD use a domain name
+   as the <id-right>.
 
       NOTE: Section 3.6.4 of [RFC2822] recommends that the <id-right>
       should be a domain name or a domain literal.  Domain literals are
@@ -655,11 +720,6 @@
 
    component-char  =  ALPHA / DIGIT / "+" / "-" / "_"
 
-      NOTE: Observe that the syntax does not allow comments within the
-      Newsgroups header field; this is to simplify processing by
-      relaying and serving agents which have a requirement to process
-      this header field extremely rapidly.
-
    Folding the Newsgroups header field over several lines has been shown
    to harm propagation significantly.  Folded Newsgroups header fields
    SHOULD NOT be generated, but MUST be accepted.
@@ -671,95 +731,108 @@
       NOTE: All-digit components conflict with one widely used storage
       scheme for articles.  Mixed case groups cause confusion between
       systems with case sensitive matching and systems with case
-      insensitive matching of newsgroup names.
+      insensitive matching of <newsgroup-name>s.
 
-   Components beginning with underline ("_") are reserved for use by
-   future versions of this standard and MUST NOT be generated by posting
+   <component>s 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 relaying
-   and serving agents.
+   messages [USEPRO]).  However, such names MUST be accepted by news
+   servers.
 
-   Components beginning with "+" and "-" are reserved for private use
-   and MUST NOT be generated by posting agents (whether in Newsgroups
+   <component>s beginning with "+" and "-" are reserved for private use
+   and MUST NOT be generated by user agents (whether in Newsgroups
    header fields or in newgroup control messages [USEPRO]) without a
    private prior agreement to do so.  However, such names MUST be
-   accepted by relaying and serving agents.
+   accepted by news servers.
 
-   The following newsgroup names are reserved, and MUST NOT be used as
+   The following <newsgroup-name>s are reserved, and MUST NOT be used as
    the name of a newsgroup:
 
-   o  Groups starting with the component "example"
+   o  Groups whose first (or only) component is "example"
 
    o  The group "poster"
 
-   The following newsgroup names have been used for specific purposes in
-   various implementations and protocols, and MUST therefore not be used
-   for the names of normal newsgroups.  They MAY be used for their
-   specific purpose, or by local agreement.
+   The following <newsgroup-name&gts have been used for specific
+   purposes in various implementations and protocols, and therefore MUST
+   NOT be used for the names of normal newsgroups.  They MAY be used for
+   their specific purpose, or by local agreement.
 
-      Groups starting with the component "to"
+      Groups whose first (or only) component is "to"
 
-      Groups starting with the component "control"
+      Groups whose first (or only) component is "control"
 
-      Groups containing the component "all"
+      Groups which contain (or consist only of) the component "all"
 
-      Groups containing the component "ctl"
+      Groups which contain (or consist only of) the component "ctl"
 
       The group "junk"
 
-      NOTE: The list above includes the groups "to", "control", "all",
-      and "ctl".
+      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.
 
 3.1.6.  Path
 
    The Path header field indicates the route taken by an article since
    its injection into the Netnews system.  Each agent that processes an
    article is required to prepend one (or more) identities to this
-   header field body.  This is primarily to enable relaying agents to
-   avoid sending articles to sites already known to have them, in
-   particular the site they came from, and additionally to permit
-   tracing the route articles take in moving over the network, and for
-   gathering Usenet statistics.
+   header field body.  This is primarily to enable news servers to avoid
+   sending articles to sites already known to have them, in particular
+   the site they came from, and additionally to permit tracing the route
+   articles take in moving over the network, and for gathering Usenet
+   statistics.
 
    path            =  "Path:" SP path-list CRLF
 
    path-list       =  [FWS]
-                      *( ( path-identity / path-keyword ) [FWS]
-                      path-delimiter [FWS] )
+                      *( ( path-identity / path-keyword /
+                           path-diagnostic ) [FWS]
+                         path-delimiter [FWS] )
                       tail-entry [FWS]
 
 
    path-identity   =  ( ALPHA / DIGIT )
-                      *( ALPHA / DIGIT / "-" / "." / ":" / "_" )
+                      *( ALPHA / DIGIT / "-" / "." / "_" )
+
+   path-keyword    =  "POSTED" / "MISMATCH"
 
-   path-keyword    = "POSTED" / "MISMATCH"
+   path-diagnostic =  1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
 
    tail-entry      =  path-identity
 
    path-delimiter  =  "!" / "!!"
 
+   A <path-identity> is a name identifying a site.  It takes the form of
+   a domain name having one or more components separated by dots.
+
    Each <path-identity> in the <path-list> (excluding the one in the
    <tail-entry>) indicates, from right to left, the successive agents
-   through which the article has passed.  The <keyword> "POSTED"
+   through which the article has passed.  The <path-keyword> "POSTED"
    indicates that the agent to its left injected the article.  The use
    of the <path-delimiter> "!!" indicates that the agent to its left
    claims that the agent to its right was the verified source of the
    article (whereas the <path-delimiter> "!" implies no such claim).
-   The <keyword> "MISMATCH" indicates that the agent to its right failed
-   to be so verified.  The full procedure for constructing a Path header
-   field as well as the specific format and use of <path-identity> and
-   <tail-entry> are discussed in [USEPRO].
-
-      NOTE: Historically, the <tail-entry> indicated the name of the
-      sender.  If not used for this purpose, the string "not-for-mail"
-      is often used instead (since at one time the whole path could be
-      used as a mail address for the sender).
+   The <path-keyword> "MISMATCH" indicates that the agent to its right
+   failed to be so verified.
 
       NOTE: Although case-insensitive, it is intended that the <path-
       keyword>s "POSTED" and "MISMATCH" should be in upper case, to
       distinguish them from the <path-identity>s which are traditionally
       in lower case.
 
+   A <path-diagnostic> is an item inserted into the Path header for
+   purposes other than to indicate the name of a site.  One commonly
+   observed usage is to insert an IP address.  The colon (":") is
+   permitted in order to allow IPv6 addresses to be inserted; note that
+   this will cause interoperability problems at older sites that regard
+   ":" as a <path-delimiter> and have neighbors whose names have 4 or
+   fewer characters, and where all the characters are valid HEX digits.
+
 3.2.  Optional Header Fields
 
    None of the header fields appearing in this section is required to
@@ -794,21 +867,26 @@
    The Injection-Date header field contains the date and time that the
    article was injected into the network.  Its purpose is to prevent the
    reinjection into the news stream of "stale" articles which have
-   already expired by the time they arrive at some relaying or serving
-   agent.
+   already expired by the time they arrive at some news server.
 
-   injection-date  =  "Injection-Date:" SP date-time CRLF
+   This header field MUST be inserted whenever an article is injected.
+   However, software that predates this standard does not use this
+   header, and therefore agents MUST accept articles without the
+   Injection-Date header field.
 
+   injection-date  =  "Injection-Date:" SP date-time CRLF
 
-   See the remarks under Section 3.1.2 regarding the syntax of date-time
-   and the requirements and recommendations to which it is subject.
 
-      NOTE: The date-time in this header field would normally be
-      expected to be later than the date-time in the Date header field,
-      but differences between the clocks on the various agents and other
-      special circumstances might vitiate that; no provision is made for
-      any such discrepancy to be corrected - better that the injecting
-      agent should just insert the correct time as it sees it.
+   See the remarks under Section 3.1.2 regarding the syntax of <date-
+   time> and the requirements and recommendations to which it is
+   subject.
+
+      NOTE: The <date-time> in this header field would normally be
+      expected to be later than the <date-time> in the Date header
+      field, but differences between the clocks on the various agents
+      and other special circumstances might vitiate that; no provision
+      is made for any such discrepancy to be corrected - better that the
+      news server should just insert the correct time as it sees it.
 
    This header field is intended to replace the currently-used but
    undocumented "NNTP-Posting-Date" header field, whose use is now
@@ -850,8 +928,8 @@
    (Section 3.1.5, with the exception that the keyword "poster" (which
    is always lowercase) requests that followups should be mailed to the
    article's reply address rather than posted.  Although the keyword
-   "poster" is case-sensitive, followup agents MAY choose to recognize
-   case-insensitive forms such as "Poster".
+   "poster" is case-sensitive, user agents MAY choose to recognize case-
+   insensitive forms such as "Poster".
 
 3.2.4.  Expires
 
@@ -861,8 +939,9 @@
 
    expires         =  "Expires:" SP date-time CRLF
 
-   See the remarks under Section 3.1.2 regarding the syntax of date-time
-   and the requirements and recommendations to which it is subject.
+   See the remarks under Section 3.1.2 regarding the syntax of <date-
+   time> and the requirements and recommendations to which it is
+   subject.
 
 3.2.5.  Control
 
@@ -937,7 +1016,8 @@
 
    The Approved header field indicates the mailing addresses (and
    possibly the full names) of the persons or entities approving the
-   article for posting.
+   article for posting.  Its principal uses are in moderated articles
+   and in group control messages [USEPRO].
 
    approved        =  "Approved:" SP mailbox-list CRLF
 
@@ -960,9 +1040,9 @@
 3.2.11.  Xref
 
    The Xref header field indicates where an article was filed by the
-   last serving agent to process it.  The article locations are used to
-   keep track of crossposted articles so that reading agents serviced by
-   a particular serving agent can mark such articles as read.
+   last news server to process it.  The article locations are used to
+   keep track of crossposted articles so that user agents serviced by a
+   particular news server can mark such articles as read.
 
    xref            =  "Xref:" SP [FWS] server-name
                       1*( FWS location ) [FWS] CRLF
@@ -976,12 +1056,12 @@
                       ; except '(' and ';'
 
    The <server-name> is included so that software can determine which
-   serving agent generated the header field.  The locations specify what
+   news server generated the header field.  The locations specify what
    newsgroups the article was filed under (which may differ from those
    in the Newsgroups header field) and where it was filed under them.
-   The exact form of an article-locator is implementation-specific.
+   The exact form of an <article-locator> is implementation-specific.
 
-      NOTE: The traditional form of an article-locator (as required by
+      NOTE: The traditional form of an <article-locator> (as required by
       [NNTP]) is a decimal number, with articles in each newsgroup
       numbered consecutively starting from 1.
 
@@ -1020,13 +1100,13 @@
    product-version =  [CFWS] token
 
    This header field MAY contain multiple product-tokens identifying the
-   agent and any subproducts which form a significant part of the
-   posting agent, listed in order of their significance for identifying
-   the application.
+   user agent and any subproducts which form a significant part of it,
+   listed in order of their significance for identifying the
+   application.
 
       NOTE: Some of this information has previously been sent in non-
       standardized header fields such as X-Newsreader, X-Mailer,
-      X-Posting-Agent, X-Http-User-Agent, and others.  Once an agent
+      X-Posting-Agent, X-Http-User-Agent, and others.  Once a user agent
       uses User-Agent, it should have no need to send these non-standard
       header fields.
 
@@ -1037,87 +1117,94 @@
 
 3.2.14.  Injection-Info
 
-   The Injection-Info header field provides information as to how an
-   article entered the Netnews system and to assist in tracing its true
-   origin.  It can also specify one or more addresses where complaints
-   concerning the poster of the article may be sent.
+   The Injection-Info header field contains information provided by the
+   injecting news server as to how an article entered the Netnews system
+   and to assist in tracing its true origin.  It can also specify one or
+   more addresses where complaints concerning the poster of the article
+   may be sent.
 
    injection-info  =  "Injection-Info:" SP [CFWS] path-identity
-                      *( [CFWS] ";" [CFWS] inj-info-param )
-                      [CFWS] CRLF
-
-   inj-info-param  =  post-host-param /
-                      post-acct-param /
-                      sender-param /
-                      logging-param /
-                      complainto-param /
-                      ext-param
-                      ;; At most one of "post-host-param",
-                      ;; "post-acct-param", "sender-param",
-                      ;; "logging-param" or "complainto-param"
-                      ;; is allowed.
+                      [CFWS] *(';' parameter) CRLF
 
-   ext-param       = parameter
-   [[Should also allow for x-attributes?]]
+      NOTE: The syntax of <parameter> ([RFC2045] as amended by
+      [RFC2231]), taken in conjunction with the folding rules of
+      [RFC0822], effectively allows [CFWS] to occur both before and
+      after the <parameter>, and also on either side of its "=".
+
+   The following table gives the <attribute> and the format of the
+   <value> for each <parameter> defined for use with this header field.
+   At most one occurrence of each such <parameter> is allowed.
+
+   <attribute>              format of <value>
+   --------------------     -----------------
+   "posting-host"           a <host-value>
+   "posting-account"        any <value>
+   "sender"                 a <sender-value>
+   "logging-data"           any <value>
+   "mail-complaints-to"     an <address-list>
 
-   post-host-param =  "posting-host" "=" host-value
+   where
 
-   host-value      =  dot-atom / [ dot-atom ":" ]
+   host-value      =  dot-atom-text / [ dot-atom-text ":" ]
                       ( IPv4address / IPv6address ) ;  see [RFC 3986]
 
-   post-acct-param =  "posting-account" "=" value
-
-   sender-param    =  "sender" "=" sender-value
-
    sender-value    =  mailbox / "verified"
 
-   logging-param   =  "logging-data" "=" value
-
-   complainto-param=  "mail-complaints-to" "=" address-list
-
+      NOTE: Since any such <host-value>>, <sender-value> or <address-
+      list> has also to be a syntactically correct <value>, it will
+      usually be necessary to encapsulate is as a <quoted-string>, for
+      example:
+
+   sender = "\"Joe Q. Public\" <[e-mail]>"
+
+   Additionally, any other <parameter> whose <attribute> starts with
+   "x-" MAY be used where the defined ones appear to be unsuitable, but
+   other unlisted <parameter>s SHOULD NOT be used unless defined in
+   extensions to this standard.
 
    Although comments and folding of white space are permitted throughout
    the Injection-Info header field, it is RECOMMENDED that folding is
-   not used within any parameter (but only before or after the ";"
-   separating those parameters), and that comments are only used
-   following the last parameter.
+   not used within any <parameter> (but only before or after the ";"
+   separating those <parameter>s), and that comments are only used
+   following the last <parameter>.
 
       NOTE: Some of this information has previously been sent in non-
       standardized header fields such as NNTP-Posting-Host, X-trace,
-      X-Complaints-To, and others.  Once an injecting agent uses
-      Injection-Info, it should have no need to send these non-standard
-      header fields.
-
-   The "posting-host" parameter specifies the FQDN and/or IP address
-   (IPv4address or IPv6address) of the host from which the injecting
-   agent received the article.
-
-      NOTE: If the "posting-host" parameter identifies a dial-up point-
-      of-presence, the "posting-account" or the "logging-data" parameter
-      may provide additional information about true origin of the
-      article.
+      X-Complaints-To, and others.  Once a news server uses Injection-
+      Info, it should have no need to send these non-standard header
+      fields.
+
+   The "posting-host" <parameter> specifies the FQDN and/or IP address
+   (IPv4address or IPv6address) of the host from which the news server
+   received the article.
+
+      NOTE: If the "posting-host" <parameter> identifies a dial-up
+      point-of-presence, the "posting-account" or the "logging-data"
+      <parameter> may provide additional information about true origin
+      of the article.
 
-   The "posting-account" parameter identifies the source from which the
-   injecting agent received the article.  For security reasons, it
+   The "posting-account" <parameter> identifies the source from which
+   that news server received the article.  For security reasons, it
    SHOULD be in a cryptic notation understandable only by the
-   administrator of the injecting agent.
+   administrator of the news server.
 
-   The "sender" parameter identifies the mailbox of the verified sender
-   of the article (alternatively, it uses the token "verified" to
+   The "sender" <parameter> identifies the mailbox of the verified
+   sender of the article (alternatively, it uses the token "verified" to
    indicate that at least any addr-spec in the Sender header field of
    the article, or in the From header field if the Sender header field
-   is absent, is correct).  If an injecting agent can verify sender of
-   an article, it SHOULD use this parameter in favour of the "posting-
-   account" parameter.
+   is absent, is correct).  If a news server can verify the sender of an
+   article, it SHOULD use this <parameter> in favor of the "posting-
+   account" <parameter>.
 
-   The "logging-data" parameter contains information (typically a
+   The "logging-data" <parameter> contains information (typically a
    session number or other non-persistent means of identifying a posting
    account) which will enable the true origin of the article to be
-   determined by reference to logging information kept by the injecting
-   agent.
+   determined by reference to logging information kept by the news
+   server.
 
-   The "mail-complaints-to" parameter specifies mailbox(es) for sending
-   complaints concerning the behavior of the poster of the article.
+   The "mail-complaints-to" <parameter> specifies mailbox(es) for
+   sending complaints concerning the behavior of the poster of the
+   article.
 
 3.3.  Obsolete Header Fields
 
@@ -1128,11 +1215,11 @@
    Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
    Date-Received: Friday, 19-Nov-82 16:59:30 EST
 
-   Relay-Version contained version information about the relaying agent
+   Relay-Version contained version information about the news server
    that last processed the article.  Posting-Version contained version
-   information about the posting agent that posted the article.  Date-
-   Received contained the date when the last relaying agent to process
-   the article first saw it (in a slightly nonstandard format).
+   information about the user agent that posted the article.  Date-
+   Received contained the date when the last news server to process the
+   article first saw it (in a slightly nonstandard format).
 
    In addition, this present standard obsoletes certain header fields
    defined in [Son-of-1036]:
@@ -1167,8 +1254,8 @@
    body, and including the whole of all MIME message and multipart parts
    contained in the body (the single empty separator line between the
    header fields and the body is not part of the body).  The "body" here
-   is the body as found in the posted article as transmitted by the
-   posting agent.
+   is the body as found in the posted article as transmitted by the user
+   agent.
 
    Historically, this header field was used by the [NNTP] overview
    extension, but its use for this purpose is now deprecated.  As a
@@ -1181,8 +1268,8 @@
 
    Internationalization of news article header fields and bodies is
    provided using MIME mechanisms discussed in Section 2.3.  Note that
-   the generation of internationalized newsgroup names for use in header
-   fields is not addressed in this document.
+   the generation of internationalized <newsgroup name>s for use in
+   header fields is not addressed in this document.
 
 
 5.  Security Considerations
@@ -1205,6 +1292,19 @@
    that generate message identifiers for news articles SHOULD ensure
    that they are unpredictable.
 
+   MIME security considerations are discussed in [RFC2046].  Note that
+   the full range of encodings allowed for parameters in [RFC2046] and
+   [RFC2231] permits constructs that simple parsers may fail to parse
+   correctly; examples of hard-to-parse constructs are:
+
+   Content-Type: multipart/mixed
+   (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
+
+   Content-Type: multipart/digest;
+   boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
+
+   Such differences in parsing may be used as part of an attack.
+
 
 6.  References
 
@@ -1242,9 +1342,6 @@
    [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.
 
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
    [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
               April 2001.
 
@@ -1264,6 +1361,12 @@
    [PGPVERIFY]
               Lawrence, D., "PGPverify", June 1999.
 
+   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
+              text messages", STD 11, RFC 822, August 1982.
+
+   [RFC0977]  Kantor, B. and P. Lapsley, "Network News Transfer
+              Protocol", RFC 977, February 1986.
+
    [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
               USENET messages", RFC 1036, December 1987.
 
@@ -1305,54 +1408,90 @@
    Melnikov.
 
 
-Appendix B.  Differences from RFC 1036
+Appendix B.  Differences from RFC 1036 and its derivatives
 
    This appendix contains a list of changes that have been made in the
    Netnews Article Format from earlier standards, specifically
    [RFC1036].
 
+      The [RFC2822] conventions for parenthesis-enclosed <comment>s in
+      header fields are supported in all newly defined header fields and
+      in header fields inherited from [RFC2822].  They are, however,
+      still disallowed for performance and/or compatibility reasons in
+      the Message-ID, Newsgroups, Path, Followup-To, Control,
+      Supersedes, Distribution, Xref and Lines header fields.
+
+      Whitespace is permitted in Newsgroups header fields.
+
+      An enhanced syntax for the Path header field enables the injection
+      point of, and the route taken by an article to be determined with
+      more precision.
+
+      MIME is recognized as an integral part of Netnews.
+
+      There is a new Injection-Date header to make the rejection of
+      stale articles more precise and to minimize spurious rejections.
 
+      There are several new optional header fields defined, notably
+      Archive, Injection-Info and User-Agent, leading to increased
+      functionality.
+
+      Certain header fields, notably Lines, have been made obsolete
+      (Section 3.3).
+
+      There are numerous other small changes, clarifications and
+      enhancements.
 
 
 Appendix C.  Differences from RFC 2822
 
    This appendix lists the differences between the syntax allowed by the
    Netnews Article Format (this document) as compared to the Internet
-   Message Format, specifically [RFC2822].
+   Message Format, as specified in [RFC2822].
+
+   The Netnews article format is a strict subset of the Internet Message
+   Format; all Netnews articles conform to the syntax of [RFC2822].
+
+   The following restrictions are important:
 
       A SP (space) is REQUIRED after the colon (':') following header
       field name.
 
-      A more restricted syntax of msg-id (to be used by the Message-ID,
-      References, and Supersedes header fields).
+      A more restricted syntax of <msg-id> (to be used by the
+      Message-ID, References, and Supersedes header fields) is defined.
+
+      The length of a msg-id MUST NOT exceed 250 octets.
 
       Comments are not allowed in the Message-ID header field.
 
-      The CFWS between msg-ids in the References header field is not
+      The CFWS between <msg-id>s in the References header field is not
       optional.
 
-      An <unstructured> header field body MUST contain at least one non-
-      whitespace character (header fields such as Subject can not be
-      empty).
+      It is legal for a parser to not accept obsolete syntax, except
+      that:
 
-      The <obs-phrase> construct MUST be accepted.
+         The <obs-phrase> construct MUST be accepted.
 
-      The obsolete timezone "GMT" MUST be accepted in the Date header
-      field.
+         The obsolete <zone> "GMT" MUST be accepted within a <date-
+         time>.
 
-      The length of a msg-id MUST NOT exceed 250 octets.
+      Every line of a header field body (including the first and any
+      that are subsequently folded) MUST contain at least one non-
+      whitespace character.  This means that an empty header field body
+      is illegal.
 
 
 Authors' Addresses
 
    Kenneth Murchison (editor)
-   Oceana Matrix Ltd.
-   21 Princeton Place
-   Orchard Park, NY  14127
+   Carnegie Mellon University
+   5000 Forbes Avenue
+   Cyert Hall 285
+   Pittsburgh, PA  15213
    US
 
-   Phone: [phone]
-   Email: [e-mail]
+   Phone: [phone]
+   Email: [e-mail]
 
 
    Charles H. Lindsey

--------------070504090607030209040906--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGIG6bH066050; Fri, 16 Dec 2005 10:16:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBGIG6O3066049; Fri, 16 Dec 2005 10:16:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGIG5r5066040 for <[e-mail]>; Fri, 16 Dec 2005 10:16:05 -0800 (PST) (envelope-from [e-mail])
Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1EnK7c-0006Rv-E0; Fri, 16 Dec 2005 19:16:00 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.54) id 1EnK7Z-00033X-Jg; Fri, 16 Dec 2005 19:15:57 +0100
From: Florian Weimer <[e-mail]>
To: "Charles Lindsey" <[e-mail]>
Cc: [e-mail]
Subject: Re: Slightly OT - Stupid Spammers
References: <[e-mail]>
Date: Fri, 16 Dec 2005 19:15:57 +0100
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Wed, 14 Dec 2005 13:03:26 GMT")
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:

> Now this list is not archived at Google, AFAICT, so the spammer must have
> been trawling in gmane.

Are you sure?  I would expect that given the size of the list, a few
subscribers use compromised Windows machines, and the spam bots got
the addresses from there.

The solution is simple: use a separate domain for message IDs.
(Rejecting in the MTA does not really help if there are too many
message IDs floating around.)  Obviously, it only works in a setting
where you have some control over the clients.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGEDufH032206; Fri, 16 Dec 2005 06:13:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBGEDueC032205; Fri, 16 Dec 2005 06:13:56 -0800 (PST)
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 jBGEDs4A032198 for <[e-mail]>; Fri, 16 Dec 2005 06:13:55 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48EDC25971C; Fri, 16 Dec 2005 15:13:08 +0100 (CET)
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 06971-09; Fri, 16 Dec 2005 15:13:03 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32089259715; Fri, 16 Dec 2005 15:13:03 +0100 (CET)
Date: Fri, 16 Dec 2005 15:16:41 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: toplabel (was: I'm back (finally))
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>

--On torsdag, desember 15, 2005 16:59:12 +0000 Charles Lindsey 
<[e-mail]> wrote:

> However, the main question that still needs answering (as Harald has
> agreed) is whether we want to arrange the syntax so that one can
> immediately tell whether a given entry is a path-entry or a
> souce[diagnostic]-entry.
>
> I have said that is a desireable feature, but nobody else has answered
> yet.

And I have said that I do not judge it possible to design and get consensus 
for such a mechanism without delaying USEFOR considerably, given the 
current lack of energy in the group.

I think it's better at this time to allow stuff in USEFOR (which will also 
allow existing usage, which is varied, and not mechanically 
distinguishable) and make rules for "one way to do it" in USEPRO.

If we can get that far.

                  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 jBFHLtlU090196; Thu, 15 Dec 2005 09:21:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBFHLtGE090195; Thu, 15 Dec 2005 09:21:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBFHLrQS090189 for <[e-mail]>; Thu, 15 Dec 2005 09:21:54 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-4.midband.mdip.bt.net ([81.144.66.4]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a1a62e.13edb.5d for [e-mail]; Thu, 15 Dec 2005 17:21:50 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBFHCDN15166 for [e-mail]; Thu, 15 Dec 2005 17:12:13 GMT
To: [e-mail]
Xref: clerew local.usefor:22758
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: toplabel (was: I'm back (finally))
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 15 Dec 2005 16:59:12 GMT
Lines: 35
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

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

>Charles Lindsey wrote:

>> The syntax I have proposed currently includes:
>>    toplabel = [ label *( "-" ) ] ALPHA [ label *( "-" ) ]
>>                ; at least one ALPHA


>We'd need "at least one non-DIGIT" for what Harald found out,
>and as stated in RFC 3696, "allowing" toblabels like 1-2-3.


>   toplabel = ( [ label *( "-" ) ] ALPHA [ *( "-" ) label ] )
>            / ( label 1*( "-" ) label )

OK, I've put that in my syntax now.

However, the main question that still needs answering (as Harald has agreed) is
whether we want to arrange the syntax so that one can immediately tell
whether a given entry is a path-entry or a souce[diagnostic]-entry.

I have said that is a desireable feature, but nobody else has answered
yet.

-- 
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 jBFHLr1K090186; Thu, 15 Dec 2005 09:21:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBFHLrXZ090185; Thu, 15 Dec 2005 09:21:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBFHLp4o090171 for <[e-mail]>; Thu, 15 Dec 2005 09:21:52 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-4.midband.mdip.bt.net ([81.144.66.4]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a1a62d.13edb.5c for [e-mail]; Thu, 15 Dec 2005 17:21:49 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBFHCEW15174 for [e-mail]; Thu, 15 Dec 2005 17:12:14 GMT
To: [e-mail]
Xref: clerew local.usefor:22759
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Slightly OT - Stupid Spammers
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Thu, 15 Dec 2005 17:02:21 GMT
Lines: 23
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

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

>I've gotten so much spam to message IDs for so many years that I wrote
>special rules into my mail server to handle it something like five years
>ago, so I don't even notice new instances any more.

Yes, I am about to arrange a filter upstream of myself (since I obviously
know the format of my locally generated message-ids), so that I don't
see them.

It just struck me that spammers could find more fertile places to scrape
than this list :-).

-- 
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 jBENJZEt036252; Wed, 14 Dec 2005 15:19:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBENJZOQ036251; Wed, 14 Dec 2005 15:19:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBENJY3i036230 for <[e-mail]>; Wed, 14 Dec 2005 15:19:35 -0800 (PST) (envelope-from [e-mail])
Received: from isop10 (velvet.isolution.nl [194.109.164.102]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBENJPGe071876 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 15 Dec 2005 00:19:33 +0100 (CET) (envelope-from [e-mail])
Message-ID: <05d901c60104$d7572f70$[e-mail]>
From: "Ruud H.G. van Tol" <[e-mail]>
To: <[e-mail]>
References:  <[e-mail]> <040101c600d7$dbf1e6b0$[e-mail]>  <[e-mail]>
Subject: Re: Slightly OT - Stupid Spammers
Date: Thu, 15 Dec 2005 00:18:17 +0100
Organization: Chaos rules.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Virus-Scanned: by XS4ALL Virus Scanner
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Frank Ellermann:
> Ruud H.G. van Tol:

>> all you can do is silently discard them.
>
> After reporting them to SpamCop, that's what I do...

Mail that is not properly addressed, doesn't get past SMTP here. But I
have spamtraps too, and my addresses are quite old and known, so I get a
lot of spam, and occasionally infected messages that weren't detected by
a the self-updating virus scanners yet.

I only report spam that is not already known by (a private selection of)
the big blacklists, which limits it for me to about 30 per day.
The infected messages (that carry complete zips or Windows-executables)
I send to a McAfee submit address following the procedure on
http://vil.nai.com/vil/submit-sample.asp


>> Catch-all is evil.
>
> ...the vanity host @xyzzy is the only way to create
> correct Message-IDs with my UA, and it comes with a
> catch-all, TINSTAAFL.

Would it work if you could put subhosts like "host01.xyzzy.claranet.de"
in DNS as localhost addresses like 127.6.66.01?


> Adding SPF FAIL it's still possible to use catch-all.
> Without SPF I'd given up on SMTP and/or Message-IDs.

I have never really looked into SPF.


>> [receiving messages that were not properly addressed]
>> compare the Envelope-To: with the embedded To:
>
> Won't fly for BCC.

If you have the complete Envelope-To, or at least the selection that
holds all te addresses that are yours, then you can check the
differences, and find the BCC ones. My main provider (xs4all.nl) adds an
Envelope-To header field to the messages with such a selection.


> But "reject as much as you can" is certainly the way to go.

For most people it should be.

I have seen spammers switching IP-nrs quite frequently lately, using an
IP-nr for only one or two days, or even just a few hours, every few
weeks, to let them flow out of black lists again. Some spammers have
been doing that for years already, but it seems to be getting more
popular.

-- 
Grtz, Ruud



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBEL8knC094852; Wed, 14 Dec 2005 13:08:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEL8kkG094851; Wed, 14 Dec 2005 13:08:46 -0800 (PST)
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 jBEL8jLG094844 for <[e-mail]>; Wed, 14 Dec 2005 13:08:45 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Emdoa-0003Cn-RR for [e-mail]; Wed, 14 Dec 2005 22:05:33 +0100
Received: from 1cust183.tnt3.hbg2.deu.da.uu.net ([149.225.14.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 14 Dec 2005 22:05:32 +0100
Received: from nobody by 1cust183.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 14 Dec 2005 22:05:32 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Slightly OT - Stupid Spammers
Date:  Wed, 14 Dec 2005 22:01:26 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Message-ID:  <[e-mail]>
References:  <[e-mail]> <040101c600d7$dbf1e6b0$[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: 1cust183.tnt3.hbg2.deu.da.uu.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>

Ruud H.G. van Tol wrote:

> all you can do is silently discard them.

After reporting them to SpamCop, that's what I do...
 
> Catch-all is evil.

...the vanity host @xyzzy is the only way to create
correct Message-IDs with my UA, and it comes with a
catch-all, TINSTAAFL.

Adding SPF FAIL it's still possible to use catch-all.
Without SPF I'd given up on SMTP and/or Message-IDs.

> compare the Envelope-To: with the embedded To:

Won't fly for BCC.  But "reject as much as you can"
is certainly the way to go.
                           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 jBEKrgJm091625; Wed, 14 Dec 2005 12:53:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEKrgYE091624; Wed, 14 Dec 2005 12:53:42 -0800 (PST)
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 jBEKrfwQ091617 for <[e-mail]>; Wed, 14 Dec 2005 12:53:41 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Emdag-00056U-Qd for [e-mail]; Wed, 14 Dec 2005 21:51:10 +0100
Received: from 1cust183.tnt3.hbg2.deu.da.uu.net ([149.225.14.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 14 Dec 2005 21:51:10 +0100
Received: from nobody by 1cust183.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 14 Dec 2005 21:51:10 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: Slightly OT - Stupid Spammers
Date:  Wed, 14 Dec 2005 21:47:10 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
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: 1cust183.tnt3.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> the spammer must have been trawling in gmane.

With its Web / RSS interfaces that would require some special
knowledge about the "raw" article view, no rocket science but
still a special procedure.  I'd guess it's plain old NNTP.

> has anyone else been getting spams derived from their
> message-ids used on this list?

I get spam to my Message-IDs all the time, even before I used
GMaNe.  Rarely I get spam to an address that I used precisely
once in de.admin.net-abuse.mail several years ago.  <shrug />

                           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 jBEKdost089373; Wed, 14 Dec 2005 12:39:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEKdoFJ089372; Wed, 14 Dec 2005 12:39:50 -0800 (PST)
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 jBEKdmMY089362 for <[e-mail]>; Wed, 14 Dec 2005 12:39:49 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EmdNP-0000Ia-Db for [e-mail]; Wed, 14 Dec 2005 21:37:27 +0100
Received: from 1cust183.tnt3.hbg2.deu.da.uu.net ([149.225.14.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 14 Dec 2005 21:37:27 +0100
Received: from nobody by 1cust183.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 14 Dec 2005 21:37:27 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  toplabel (was: I'm back (finally))
Date:  Wed, 14 Dec 2005 21:21:28 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 39
Message-ID:  <[e-mail]>
References:  <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 1cust183.tnt3.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:

> The syntax I have proposed currently includes:
>    toplabel = [ label *( "-" ) ] ALPHA [ label *( "-" ) ]
>                ; at least one ALPHA

Yes, that's the "at least one ALPHA" syntax.  But I got this
wrong, it isn't the same as "not only digits" as in RFC 3696.

We'd need "at least one non-DIGIT" for what Harald found out,
and as stated in RFC 3696, "allowing" toblabels like 1-2-3.

Based on what we discussed in...
http://article.gmane.org/gmane.ietf.usenet.format/30109
...that could result in:

   toplabel = ( [ label *( "-" ) ] ALPHA [ *( "-" ) label ] )
            / ( label 1*( "-" ) label )

Is this the most simple form to say "not all-numeric" plus
"hyphen only inside" ?  We could also add "minimal length 2":

   toplabel = ( [ label *( "-" ) ] ALPHA   *( "-" ) label   )
            / (   label *( "-" )   ALPHA [ *( "-" ) label ] )
            / (   label          1*( "-" )          label   )

> less restrictive than what you have found in RFC 1123.  We
> could follow either, but I don't think Film at 11 would be
> needed either way :-)

It's interesting not only here, it could also affect 2821bis
(= to avoid useless root server queries for erroneous IPv4
constructs without square brackets) and RfCs using the simple
2396 approach "must start with ALPHA".

And SPF could reach AUTH48 as soon as 2476bis got its number.

                           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 jBEJi55K081159; Wed, 14 Dec 2005 11:44:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEJi5cb081158; Wed, 14 Dec 2005 11:44:05 -0800 (PST)
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 jBEJi4lN081152 for <[e-mail]>; Wed, 14 Dec 2005 11:44:04 -0800 (PST) (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 jBEJi3bj016386 for <[e-mail]>; Wed, 14 Dec 2005 11:44:04 -0800
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 89C3AE79ED; Wed, 14 Dec 2005 11:44:03 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: Slightly OT - Stupid Spammers
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Wed, 14 Dec 2005 13:03:26 GMT")
Organization: The Eyrie
References: <[e-mail]>
Date: Wed, 14 Dec 2005 11:44:03 -0800
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:

> Anyway, has anyone else been getting spams derived from their
> message-ids used on this list?

I've gotten so much spam to message IDs for so many years that I wrote
special rules into my mail server to handle it something like five years
ago, so I don't even notice new instances any more.

-- 
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 jBEHvduT067843; Wed, 14 Dec 2005 09:57:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEHvdaC067842; Wed, 14 Dec 2005 09:57:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBEHvcE1067828 for <[e-mail]>; Wed, 14 Dec 2005 09:57:38 -0800 (PST) (envelope-from [e-mail])
Received: from isop10 (velvet.isolution.nl [194.109.164.102]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBEHvTIW028137 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 14 Dec 2005 18:57:34 +0100 (CET) (envelope-from [e-mail])
Message-ID: <040101c600d7$dbf1e6b0$[e-mail]>
From: "Ruud H.G. van Tol" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Slightly OT - Stupid Spammers
Date: Wed, 14 Dec 2005 18:57:24 +0100
Organization: Chaos rules.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Virus-Scanned: by XS4ALL Virus Scanner
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey schreef:

> Anyway, has anyone else been getting spams derived from their
> message-ids used on this list?

I get from this that you have a catch-all setup.

If you choose to have messages accepted for non-deliverable addresses,
then all you can do is silently discard them.

Catch-all is evil. Non-existent hostnames and usernames should be
rejected at the very start of the SMTP-conversation (maybe after a
minute of silence).

Something similar happens when such a message is addressed to multiple
recipients from which a few exist, so compare the Envelope-To: with the
embedded To:.

The Message-IDs can have been scraped from the web, simply triggerd by
the '@' inside them. There will be other places than gmane that archive
this list.

-- 
Grtz, Ruud



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBEHMWWE062463; Wed, 14 Dec 2005 09:22:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEHMW1g062462; Wed, 14 Dec 2005 09:22:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBEHMVHi062448 for <[e-mail]>; Wed, 14 Dec 2005 09:22:31 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-65-18.midband.mdip.bt.net ([81.144.65.18]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a054d6.5348.1bc for [e-mail]; Wed, 14 Dec 2005 17:22:30 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBEHCSH06832 for [e-mail]; Wed, 14 Dec 2005 17:12:28 GMT
To: [e-mail]
Xref: clerew local.usefor:22749
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: I'm back (finally)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 14 Dec 2005 12:50:05 GMT
Lines: 48
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

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

>Charles Lindsey wrote:

>>> at the time Jon Postel was IANA, he said quite clearly that
>>> "there will never be a numeric TLD". But I've not managed to
>>> find a policy document that says so.

>> I think all we can do is to proceed on the assumption that
>> John Postel was correct.


>We don't need ABNF for that, or do we ?  Apparently 1123 2.1
>(a part of STD 3) says toplabel = 1*ALPHA

Well we have decided that a path-identity should be an <fqdn> or a
<bareword>, but not an <IP-address> (those are only for
source-identities/diagnostics). So if we want to give a clear syntax for
what is allowed, some ABNF for <fqdn> seems in order.

The syntax I have proposed currently includes:

   toplabel = [ label *( "-" ) ] ALPHA [ label *( "-" ) ]
               ; at least one ALPHA

which gives the required safety and agrees with Jon Postel, but is less
restrictive than what you have found in RFC 1123. We could follow either,
but I don't think Film at 11 would be needed either way :-) .

>| However, a valid host name can never have the dotted-decimal
>| form #.#.#.#, since at least the highest-level component
>| label will be alphabetic.

Yes, that seems clear enough. (It is also the place where it says that if
a domain name is acceptable in some context, then an IP address SHOULD be
acceptable also - which we have decided not to follow in Paths :-( .)


-- 
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 jBEHMVm5062455; Wed, 14 Dec 2005 09:22:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBEHMVL3062454; Wed, 14 Dec 2005 09:22:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBEHMUBd062447 for <[e-mail]>; Wed, 14 Dec 2005 09:22:31 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-65-18.midband.mdip.bt.net ([81.144.65.18]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43a054d5.5348.1bb for [e-mail]; Wed, 14 Dec 2005 17:22:29 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jBEHCSv06836 for [e-mail]; Wed, 14 Dec 2005 17:12:28 GMT
To: [e-mail]
Xref: clerew local.usefor:22750
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Slightly OT - Stupid Spammers
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
Date: Wed, 14 Dec 2005 13:03:26 GMT
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Well we all know that spammers trawl newsgroups looking for valid email
addresses. But the more stupid ones also pick up message-ids and try to
email spam to them. I have been getting around 50 spams a night addressed
to non-existent users on my machine, which turn out to be message-ids that
I have used. They all come via zombied machines, but the spammer appears
to be feeding the zombies in real time, because the times of posting of a
batch are all close together, even though they come from different
zombies. The contents cover all the spam topics that seem to be
fashionable at the moment.

Anyway, I thought I would try to discover exactly which groups the spammer
had been trawling, but Google only had a few of those message-ids (from
some widely separated copies of a FAQ I post).

But then, to my surprise, I found 5 of them were the message-ids of
messages I had posted to this list (I only looked at those 5, so there
were probably a lot more - they were from the days when the list was
hosted at Landfield, because looking for message-ids on the present
archive is _really_ hard work).

Now this list is not archived at Google, AFAICT, so the spammer must have
been trawling in gmane.

Anyway, has anyone else been getting spams derived from their message-ids
used on this list?

-- 
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 jBDFECiQ059396; Tue, 13 Dec 2005 07:14:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jBDFECLi059395; Tue, 13 Dec 2005 07:14:12 -0800 (PST)
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 jBDFEAOe059380 for <[e-mail]>; Tue, 13 Dec 2005 07:14:11 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EmBp2-000329-M0 for [e-mail]; Tue, 13 Dec 2005 16:12:09 +0100
Received: from c-180-161-151.hh.dial.de.ignite.net ([62.180.161.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 13 Dec 2005 16:12:08 +0100
Received: from nobody by c-180-161-151.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 13 Dec 2005 16:12:08 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: I'm back (finally)
Date:  Tue, 13 Dec 2005 16:08:01 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
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-151.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:

>> at the time Jon Postel was IANA, he said quite clearly that
>> "there will never be a numeric TLD". But I've not managed to
>> find a policy document that says so.

> I think all we can do is to proceed on the assumption that
> John Postel was correct.

That would be "not only digits".  No idea how I managed to
hallucinate "at least one alpha" into RFC 3696, it clearly
says "not all-numeric":

| There is an additional rule that essentially requires that
| top-level domain names not be all-numeric.

We don't need ABNF for that, or do we ?  Apparently 1123 2.1
(a part of STD 3) says toplabel = 1*ALPHA

| However, a valid host name can never have the dotted-decimal
| form #.#.#.#, since at least the highest-level component
| label will be alphabetic.
                             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 jB9GWX68047951; Fri, 9 Dec 2005 08:32:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB9GWXr6047950; Fri, 9 Dec 2005 08:32:33 -0800 (PST)
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 jB9GWW9n047943 for <[e-mail]>; Fri, 9 Dec 2005 08:32:32 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C61F4259745; Fri,  9 Dec 2005 17:31:50 +0100 (CET)
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 22797-10; Fri,  9 Dec 2005 17:31:43 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F98F259742; Fri,  9 Dec 2005 17:31:43 +0100 (CET)
Date: Fri, 09 Dec 2005 17:34:57 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1102: Proposed resolution
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]> <[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, desember 09, 2005 12:15:00 +0000 Charles Lindsey 
<[e-mail]> wrote:

>
> In <[e-mail]> Harald Tveit
> Alvestrand <[e-mail]> writes:
>
>> An "user agent" is software that helps posters submit proto-articles to
>> a  news server, fetches articles from a news server and presents them to
>> a  reader, and assists the reader in creating articles and followups.
>
>> A "news server" is software which accepts articles from an user agent,
>> makes articles available to user agents, and exchanges articles with
>> other  news servers.
>
> That wording might imply that each user/serving agent is obliged to offer
> all the services described, whereas there exist specialized agents (esp.
> serving ones) which do only part of the job.
>
> I suggest s/and/or/ in a couple of places. Otherwise, it seems fine.

That's reasonable. I'll leave the editor to do 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 jB9FJYXb038558; Fri, 9 Dec 2005 07:19:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB9FJYS7038557; Fri, 9 Dec 2005 07:19:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-6.gradwell.net (lon-mail-6.gradwell.net [193.111.201.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB9FJXCA038534 for <[e-mail]>; Fri, 9 Dec 2005 07:19:34 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-67-86.midband.mdip.bt.net ([81.144.67.86]) by lon-mail-6.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 439998e9.8952.16a for [e-mail]; Fri,  9 Dec 2005 14:47:05 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jB9Eedj26757 for [e-mail]; Fri, 9 Dec 2005 14:40:39 GMT
To: [e-mail]
Xref: clerew local.usefor:22746
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1102: Proposed resolution
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Fri, 9 Dec 2005 12:15:00 GMT
Lines: 34
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>An "user agent" is software that helps posters submit proto-articles to a 
>news server, fetches articles from a news server and presents them to a 
>reader, and assists the reader in creating articles and followups.

>A "news server" is software which accepts articles from an user agent, 
>makes articles available to user agents, and exchanges articles with other 
>news servers.

That wording might imply that each user/serving agent is obliged to offer
all the services described, whereas there exist specialized agents (esp.
serving ones) which do only part of the job.

I suggest s/and/or/ in a couple of places. Otherwise, it seems fine.


>CHANGE all occurences of the above + "serving agent", "netnews agents", 
>"news agents" into one of the three terms described above.

There will be a few places where the wording will need a bit more than
that, e.g. "... a news server, when injecting articles, MUST/SHOULD
[do whatever]...."

-- 
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 jB8HTckP016056; Thu, 8 Dec 2005 09:29:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB8HTbNh016055; Thu, 8 Dec 2005 09:29:38 -0800 (PST)
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 jB8HTbVN016048 for <[e-mail]>; Thu, 8 Dec 2005 09:29:37 -0800 (PST) (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 jB8HTa8M003632 for <[e-mail]>; Thu, 8 Dec 2005 09:29:36 -0800
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 0BB11E78D9; Thu,  8 Dec 2005 09:29:36 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1088 Injection-date (Re: Ticket status, November 28, 2005)
In-Reply-To: <[e-mail]> (Harald Tveit Alvestrand's message of "Thu, 08 Dec 2005 15:37:48 +0100")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 08 Dec 2005 09:29:36 -0800
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:

>>> 2 for Russ', 1 for Charles' - other opinions?

>> The proper action, if you don't like my suggested NOTE, is "No change".

> I do not agree. There has been enough debate about this single field that 
> it's a Good Thing to be explicit. In my opinion.

Yup.  Not that this changes the numbers any, but I haven't changed my mind
on this.

-- 
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 jB8HT71p015945; Thu, 8 Dec 2005 09:29:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB8HT7Yl015944; Thu, 8 Dec 2005 09:29:07 -0800 (PST)
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 jB8HT6fF015938 for <[e-mail]>; Thu, 8 Dec 2005 09:29:07 -0800 (PST) (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 jB8HT4pB030900 for <[e-mail]>; Thu, 8 Dec 2005 09:29:05 -0800
Received: by windlord.stanford.edu (Postfix, from userid 1000) id A21E2E78D8; Thu,  8 Dec 2005 09:29:04 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1102: Proposed resolution
In-Reply-To: <[e-mail]> (Harald Tveit Alvestrand's message of "Thu, 08 Dec 2005 15:29:59 +0100")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 08 Dec 2005 09:29:04 -0800
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 propose the following resolution for #1102:

[...]

I wholeheartedly agree with this proposal.

-- 
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 jB8HSors015927; Thu, 8 Dec 2005 09:28:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB8HSop7015926; Thu, 8 Dec 2005 09:28:50 -0800 (PST)
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 jB8HSnFu015919 for <[e-mail]>; Thu, 8 Dec 2005 09:28:49 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-65-124.midband.mdip.bt.net ([81.144.65.124]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 43986ae4.6102.2a3 for [e-mail]; Thu,  8 Dec 2005 17:18:28 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jB8HCQX16094 for [e-mail]; Thu, 8 Dec 2005 17:12:26 GMT
To: [e-mail]
Xref: clerew local.usefor:22741
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1102
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Thu, 8 Dec 2005 16:55:59 GMT
Lines: 33
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>I had an offline exchange with the editor, and he seems to think that it's 
>not unreasonable to make the change.

>I'll propose text for a definitions paragraph, and he will use editorial 
>license to make the changes in the body of the document.

Fair enough! My offer to produce a first cut of the needed changes still
stands if Ken wants to take it up.

I am assuming that the two terms to be defined willl be "User Agent" and
"Serving Agent", and that my suggestion to s/serving agent/storage agent/
plus s/news-server/serving agent/ throughout USEPRO is OK.

The other main consequential change in USEPRO will be that section 2.1
(definitions) will be replaced by a statement that the definitions from
USEFOR are adopted (these definitions are now pretty well identical in the
2 documents) and section 2.2 (Defining the Architecture) will remain
largely as it is (intrpducing the overall architecture by defining the
more specific *-agent terms, which are then used throughout the remainder
of USEPRO).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB8EZQ2b083928; Thu, 8 Dec 2005 06:35:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB8EZQVY083927; Thu, 8 Dec 2005 06:35:26 -0800 (PST)
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 jB8EZPg1083919 for <[e-mail]>; Thu, 8 Dec 2005 06:35:26 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2218025972E; Thu,  8 Dec 2005 15:34:45 +0100 (CET)
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 09208-02; Thu,  8 Dec 2005 15:34:41 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73156259732; Thu,  8 Dec 2005 15:34:41 +0100 (CET)
Date: Thu, 08 Dec 2005 15:37:48 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Charles Lindsey <[e-mail]>, [e-mail]
Subject: Re: #1088 Injection-date (Re: Ticket status, November 28, 2005)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: 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 torsdag, desember 01, 2005 11:40:45 +0000 Charles Lindsey 
<[e-mail]> wrote:
>
>> 2 for Russ', 1 for Charles' - other opinions?


> The proper action, if you don't like my suggested NOTE, is "No change".

I do not agree. There has been enough debate about this single field that 
it's a Good Thing to be explicit. In my opinion.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB8ERdjE082499; Thu, 8 Dec 2005 06:27:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB8ERdni082498; Thu, 8 Dec 2005 06:27:39 -0800 (PST)
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 jB8ERc8K082481 for <[e-mail]>; Thu, 8 Dec 2005 06:27:38 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 61C81259732 for <[e-mail]>; Thu,  8 Dec 2005 15:26:56 +0100 (CET)
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 09013-06 for <[e-mail]>; Thu,  8 Dec 2005 15:26:53 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id EAB5325972E for <[e-mail]>; Thu,  8 Dec 2005 15:26:52 +0100 (CET)
Date: Thu, 08 Dec 2005 15:29:59 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: [e-mail]
Subject: #1102: Proposed resolution
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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 propose the following resolution for #1102:

ADD to the definitions in 1.5:

An "user agent" is software that helps posters submit proto-articles to a 
news server, fetches articles from a news server and presents them to a 
reader, and assists the reader in creating articles and followups.

A "news server" is software which accepts articles from an user agent, 
makes articles available to user agents, and exchanges articles with other 
news servers.

The word "agent" is used when describing requirements that apply to both 
user agents and news servers.

REMOVE from the definitions in 1.5:

"posting agent" ( -> user agent)
"reading agent" ( -> user agent)
"followup agent" ( -> user agent)
"injecting agent" ( -> news server)

CHANGE all occurences of the above + "serving agent", "netnews agents", 
"news agents" into one of the three terms described above.

Makes 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 jB68geZd088735; Tue, 6 Dec 2005 00:42:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB68geje088734; Tue, 6 Dec 2005 00:42:40 -0800 (PST)
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 jB68gdaY088727 for <[e-mail]>; Tue, 6 Dec 2005 00:42:39 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6DA7259722; Tue,  6 Dec 2005 09:41:59 +0100 (CET)
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 11949-10; Tue,  6 Dec 2005 09:41:56 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A27C25971D; Tue,  6 Dec 2005 09:41:56 +0100 (CET)
Date: Tue, 06 Dec 2005 09:44:49 +0100
From: Harald Tveit Alvestrand <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: #1102
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[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 had an offline exchange with the editor, and he seems to think that it's 
not unreasonable to make the change.

I'll propose text for a definitions paragraph, and he will use editorial 
license to make the changes in the body of the document.

--On torsdag, desember 01, 2005 14:47:02 +0100 Frank Ellermann 
<[e-mail]> wrote:

>
> Charles Lindsey wrote:
>
>> I need to know how the terminology is going to be defined in
>> order to make progress on USEPRO.
>
> Sure, but USEPRO is something for 2006, while USEFOR-06 is for
> this year.  I'd prefer to see or create a short text diff. -05
> vs. -06 without the bulk #1102 updates.  The latter is only a
> case of editorial "lillygilding" (Randy's term for some late
> LTRU issues), no chance to get something seriously wrong.
>
> For the other remaining tickets (excl. #1102) it's likely that
> we find some issues in -06, and a short text diff. should help.
>
>                             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 jB5CK3ua026042; Mon, 5 Dec 2005 04:20:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB5CK3RM026041; Mon, 5 Dec 2005 04:20:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-6.gradwell.net (lon-mail-6.gradwell.net [193.111.201.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5CK2A8026032 for <[e-mail]>; Mon, 5 Dec 2005 04:20:03 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-52.midband.mdip.bt.net ([81.144.66.52]) by lon-mail-6.gradwell.net with esmtp (Gradwell gwh-smtpd 1.206) id 4394306e.138f9.46 for [e-mail]; Mon,  5 Dec 2005 12:19:58 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jB5CCE204458 for [e-mail]; Mon, 5 Dec 2005 12:12:14 GMT
To: [e-mail]
Xref: clerew local.usefor:22739
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1102
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, 5 Dec 2005 11:01:41 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]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:
> 
>> I need to know how the terminology is going to be defined in
>> order to make progress on USEPRO.

>Sure, but USEPRO is something for 2006, while USEFOR-06 is for
>this year.  I'd prefer to see or create a short text diff. -05
>vs. -06 without the bulk #1102 updates.  The latter is only a
>case of editorial "lillygilding" (Randy's term for some late
>LTRU issues), no chance to get something seriously wrong.

There is already more that has changed since -05 (as documented in
Harald's proposed/accepted texts) than will fit in a short text diff. ISTM
that you are not opposed to making the #1102 change, in which case I might
as well get on and document what I propose. In that case, I would be able
to produce a revised USEPRO as soon as the next USEFOR appears that would
at least be consistent and remove all the duplications that currently
exist. Then we could start discussing USEPRO in detail.

-- 
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 jB1DsY45060410; Thu, 1 Dec 2005 05:54:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB1DsYXS060407; Thu, 1 Dec 2005 05:54:34 -0800 (PST)
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 jB1DsVUV060379 for <[e-mail]>; Thu, 1 Dec 2005 05:54:32 -0800 (PST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EhopR-0002HR-NG for [e-mail]; Thu, 01 Dec 2005 14:50:29 +0100
Received: from c-134-88-129.hh.dial.de.ignite.net ([62.134.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 01 Dec 2005 14:50:29 +0100
Received: from nobody by c-134-88-129.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 01 Dec 2005 14:50:29 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Frank Ellermann <[e-mail]>
Subject:  Re: #1102
Date:  Thu, 01 Dec 2005 14:47:02 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c-134-88-129.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 need to know how the terminology is going to be defined in
> order to make progress on USEPRO.

Sure, but USEPRO is something for 2006, while USEFOR-06 is for
this year.  I'd prefer to see or create a short text diff. -05
vs. -06 without the bulk #1102 updates.  The latter is only a
case of editorial "lillygilding" (Randy's term for some late
LTRU issues), no chance to get something seriously wrong.

For the other remaining tickets (excl. #1102) it's likely that
we find some issues in -06, and a short text diff. should help.

                            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 jB1CDpD5050800; Thu, 1 Dec 2005 04:13:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB1CDpj2050799; Thu, 1 Dec 2005 04:13:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1CDopK050753 for <[e-mail]>; Thu, 1 Dec 2005 04:13:51 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-173.midband.mdip.bt.net ([81.144.66.173]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.205) id 438ee8fd.135a8.8 for [e-mail]; Thu,  1 Dec 2005 12:13:49 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jB1CCRX18892 for [e-mail]; Thu, 1 Dec 2005 12:12:27 GMT
To: [e-mail]
Xref: clerew local.usefor:22737
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1088 Injection-date (Re: Ticket status, November 28, 2005)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Thu, 1 Dec 2005 11:40:45 GMT
Lines: 44
Sender: [e-mail]
Precedence: 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:

>The text that I inserted into the ticket system is (in case people have 
>forgotten):

> This header field MUST be inserted whenever an article is
> injected.
> However, software that predates this standard does not use this
> header, and therefore agents MUST accept articles without the
> Injection-Date header field.

>I think this text is better than what Charles is proposing.
>I don't see anything that is more bizarre than the other uses of MUST in 
>the document.

But I never claimed that those "MUST"s were "bizarre". I said they were
redundant.

There are currently 14 optional header fields defined in USEFOR. If we are
to say "agents MUST accept articles without the XXXX header field" in this
case, why are we not saying the same thing for all the other 13?

And as for Russ's first MUST, USEPRO currently specifies about a dozen
steps that have to be gone through in order to inject an article correctly
(with assorted MUST/SHOULD/MAY wording as appropriate). One of them is
"MUST insert Injection-Date" (with an exception for some rare special
cases where it is already present) and it clearly belongs as one of those
steps. So why repeat it in USEFOR (and what is proposed is technically
incorrect, because of that rare special case)?

The proper action, if you don't like my suggested NOTE, is "No change".

>2 for Russ', 1 for Charles' - other opinions?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1CDoS3050783; Thu, 1 Dec 2005 04:13:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB1CDo7S050782; Thu, 1 Dec 2005 04:13:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1CDn4A050750 for <[e-mail]>; Thu, 1 Dec 2005 04:13:49 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-173.midband.mdip.bt.net ([81.144.66.173]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.205) id 438ee8f9.135a8.7 for [e-mail]; Thu,  1 Dec 2005 12:13:45 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jB1CCQP18887 for [e-mail]; Thu, 1 Dec 2005 12:12:26 GMT
To: [e-mail]
Xref: clerew local.usefor:22736
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: I'm back (finally)
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Date: Thu, 1 Dec 2005 11:24:11 GMT
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Harald Tveit Alvestrand <[e-mail]> writes:

>The feedback I got (not official) was that the 1123 oblique reference was 
>the closest we have come to an official statement; I got one comment saying 
>that at the time Jon Postel was IANA, he said quite clearly that "there 
>will never be a numeric TLD". But I've not managed to find a policy 
>document that says so.

I think all we can do is to proceed on the assumption that John Postel was
correct.

>I've pushed on the dnsext list for the prohibition to be added to 
>draft-eastlake-2606bis, but that hasn't happened so far... meeting some 
>resistance, mostly of the "not the IETF's business" type.

I would have thought it was very much the IETF's business if every IP
address in the traditional form ("123.456.123.456") could also be
potentially a domain-name. I am sure there are lots of existing things
that would break if that were ever to be allowed.

There is currently a guidance statement from ICANN, that I unearthed in
the IANA website, that says ".example" and the like should not be TLDs. I
suppose persuading ICANN to include a remark about numeric TLDs would
resolve the issue (I gather it is already too late to prevent numeric
components at lower levels).

-- 
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 jB1CDmH6050742; Thu, 1 Dec 2005 04:13:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB1CDmge050740; Thu, 1 Dec 2005 04:13:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB1CDkoh050680 for <[e-mail]>; Thu, 1 Dec 2005 04:13:47 -0800 (PST) (envelope-from [e-mail])
Received: from host81-144-66-173.midband.mdip.bt.net ([81.144.66.173]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.205) id 438ee8f5.135a8.6 for [e-mail]; Thu,  1 Dec 2005 12:13:41 +0000 (envelope-sender <[e-mail]>)
Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id jB1CCPu18883 for [e-mail]; Thu, 1 Dec 2005 12:12:25 GMT
To: [e-mail]
Xref: clerew local.usefor:22735
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1102
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 1 Dec 2005 11:12:08 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]> Frank Ellermann <[e-mail]> writes:

>Charles Lindsey wrote:

>> I have already offered to write the detailed changes that
>> would be needed.  Looks Like I should go ahead and do that
>> anyway, so that people can see exactly what the consequences
>> would be.

>I'd guess that this will be a rather boring hour with an editor
>resulting in a better readable version of the text (plus a few
>corresponding changes in USEPRO).

>How about waiting for -06, worst case there are still some
>issues fixed in -07, and then offer a -08 for #1102 and WGLC ?

No, because I need to know how the terminology is going to be defined in
order to make progress on USEPRO.

Hopefully, all technical issues will be resolved in time for -06, and -07
will just be a cleanup. So we should be able to start serious progress on
USEPRO once -06 is done.

So I still think I need to embark on the "boring hour with an editor" now,
assuming there is still some possibility the WG might then agree to adopt
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