Subject: #1046 Security considerations for boundaries - text proposed

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 29 Sep 2005 16:45:35 +0200

A somewhat different rewrite from Frank's suggested text, to be appended to 
section 5:

 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 will 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.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 30 Sep 2005 13:29:14 GMT

> correctly; examples of hard-to-parse constructs are:

ITYM "that simple parsers might fail to parse correctly".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22656
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1052 Changes from RFC 2822
Date: Fri, 30 Sep 2005 13:58:18 GMT
Lines: 85
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>Updated text:

>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].
                  ^^^^^^^^^^^^^^
		  as specified in

That ensures that we do not actually take a position one way or the other
on the religious question of whether there is such a thing as "THE
Internet Message Format" (some read RFC 2822 as specifying there is;
others read it as applying only within the framework of "electronic
mail").

>   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
                                                               ^
                                                               a
>      field name.

>      A more restricted syntax of msg-id (to be used by the Message-ID,
                                   ^^^^^^
                                  <msg-id>
>      References, and Supersedes header fields) is defined.

>      The length of a msg-id MUST NOT exceed 250 octets.
                       ^^^^^^
                      <msg-id>

>      Comments are not allowed in the Message-ID header field.

>      The CFWS between msg-ids in the References header field is not
                        ^^^^^^^
                       <msg-ids>
>      optional.

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

>         The <obs-phrase> construct MUST be accepted.

>         The obsolete timezone "GMT" MUST be accepted in the Date header
                       ^^^^^^^^                        ^^^^^^^^^^^^^^^^^^
                        <zone>                       within a <date-time>
>         field.
          ^^^^^

[Because the same applies also to the Injection-Date and Expires header
fields.]

>      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 is illegal.

It might be helpful to add "(consequently, the syntax of <unstructured> is
changed)" [or "now requires at least one character" or somesuch].

The only item you have not included is something on the lines of:

       There is no RECOMMENDED limit of 78 characters in a header line.

[We decided this was a matter of best practice - hence there are advisory
limits in USEAGE].

It might also be useful to mention (but not as a restriction, of course)
that MIME is fully incorporated, at least to the extent given in RFC 2049.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22655
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1046 Security considerations for boundaries - text proposed
Date: Fri, 30 Sep 2005 13:29:14 GMT
Lines: 22
Sender: [email-masked]

> correctly; examples of hard-to-parse constructs are:

ITYM "that simple parsers might fail to parse correctly".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22654
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1053 2.1 Relationship to 2822 - revised text
Date: Fri, 30 Sep 2005 13:26:46 GMT
Lines: 28
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>2.1 Base

> 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" timezone, as specified
                                                ^^^^^^^^
                                                 <zone>
> in section 3.1.2.

If those two paragraphs starting "Articles are ..." were moved two
paragraphs higher, it would be clearer, and the wording could be
simplified slightly ("following" rather than "mentioned below").

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Thu, 29 Sep 2005 18:11:01 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1053 2.1 Relationship to 2822 - revised text
Sender: [email-masked]

2.1 Base

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

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

 This document, and specifications that build upon it, specifies how
 to handle conformant articles. Handling of non-conformant articles
 is outside the scope of this specification.

 Agents conforming to this specification MUST generate only conformant
 articles.

 Articles are conformant if they use the <obs-phrase> construct
 (use of a phrase like "John Q. Public" without the use of quotes,
 see [RFC2822] section 4.1) but agents MUST NOT generate productions
 of such syntax.

 Articles are conformant if they use the "GMT" timezone, as specified
 in section 3.1.2.

 The text below uses ABNF to specify restrictions on the syntax
 specified in [RFC2822]; this grammar is intended to be more restrictive
 than the RFC 2822 grammar.
 Articles must conform to the ABNF specified in RFC 2822.

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

Date: Thu, 29 Sep 2005 17:10:43 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1052 Changes from RFC 2822
Sender: [email-masked]

Updated text:

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].

   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) 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
      optional.

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

         The <obs-phrase> construct MUST be accepted.

         The obsolete timezone "GMT" MUST be accepted in the Date header
         field.

      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 is illegal.

Date: Thu, 29 Sep 2005 16:45:35 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1046 Security considerations for boundaries - text proposed
Sender: [email-masked]

Content-Type:

Date: Thu, 29 Sep 2005 16:25:19 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1029 References: No change needed
Sender: [email-masked]

It seems that the text in -05 is OK on this point (ABNF permits comments).

I've changed this to "no change needed".

Date: Thu, 29 Sep 2005 16:16:53 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1003 Message-ID: Resolution
Sender: [email-masked]

I make the following resolution of comments:

- Change the first paragraph

FROM:

   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

TO:

   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
   and standards [NNTP] have trouble with the full range of possible
   <msg-id>s

(remember to insert [NNTP] in references)

- Modify examples.

FROM:

   <[email-masked]>
   <"abcd"@example.com>
   <"ab\cd"@example.com>

TO:

   <[email-masked]>
   <"ab.cd"@example.com>
   <"ab.\cd"@example.com>

- Modify end of paragraph.

FROM:

   If domain literals are used, the syntax found in Section 4.1.3 of
   [RFC2821] is RECOMMENDED.

      NOTE: Section 3.6.4 of [RFC2822] recommends that the <id-right>
      should be a domain name or a domain literal.  Domain literals are
      troublesome since many IP addresses are not globally unique;
      domain names are more likely to generate unique Message-IDs.

TO:

   When generating a message-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
      troublesome since many IP addresses are not globally unique;
      domain names are more likely to generate unique Message-IDs.

To: [email-masked]
Xref: clerew local.usefor:22648
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 1078, 1088
Date: Tue, 27 Sep 2005 10:25:22 GMT
Lines: 48
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>I can see the justification for that, but that's not what that second MUST
>is.  That second MUST is a statement about the article format and about
>what parsers have to implement, not a provision that's just copied from
>another document.  I don't think it should be in a NOTE.

>>>    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.

>> No, the intent was to explain why it was not in the section for
>> "mandatory" headers, as might have been expected.

>> Here is another attempt:

>>       NOTE: [USEPRO] REQUIRES this header field to be inserted whenever an
>>       article in injected into the network. However, it has not formally
>>       been designated as "mandatory" since articles generated by earlier
>>       systems which do not include it still need to be accepted.

>I prefer my wording and do not support this proposal.  I don't think it's
>necessary to explicitly talk about the mandatory designation, and I do
>want to see that MUST in there to make it very explicit what the required
>behavior is.

If some particular header is defined in the syntax, and is declared to be
optional rather than mandatory, then it follows without further verbiage
that compliant agents MUST accept articles without it.

Therefore your proposed sentence (not in a NOTE) adds nothing.

However, a NOTE drawing attention to its slightly unusual status, and for
the removal of any possible doubt, is perfectly in order.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: 1078, 1088
Organization: The Eyrie
Date: Mon, 26 Sep 2005 10:17:01 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> Looking over the current ticket, I'm completely ambivalent, neither
>> supporting it nor not supporting it.  The gain in clarity competes with
>> the weird feeling about defining headers for e-mail in a news document.

> Newsgroups is "our" header, so we get to say what it means. Otherwise,
> some mail standard will rush in and say it wrong (look at 'Supersedes').
> Indeed, it was such a proposal by Jacob Palme (years ago) that caused it
> to appear in our drafts, and he declared himself satisfied by what we
> had written.

This argument doesn't convince me to be other than ambivalent.

>>> On Aug 26th I proposed:

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

>> RFC 2119 language doesn't belong in notes.  If it's part of the
>> protocol, it should be in the main body of the text.

> I think Harald agreed recently that RFC 2119 language in NOTEs was fine
> if it just quoted some other document, or drew attention to a
> consequence which could be deduced from such other documents.

I can see the justification for that, but that's not what that second MUST
is.  That second MUST is a statement about the article format and about
what parsers have to implement, not a provision that's just copied from
another document.  I don't think it should be in a NOTE.

>>    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.

> No, the intent was to explain why it was not in the section for
> "mandatory" headers, as might have been expected.

> Here is another attempt:

>       NOTE: [USEPRO] REQUIRES this header field to be inserted whenever an
>       article in injected into the network. However, it has not formally
>       been designated as "mandatory" since articles generated by earlier
>       systems which do not include it still need to be accepted.

I prefer my wording and do not support this proposal.  I don't think it's
necessary to explicitly talk about the mandatory designation, and I do
want to see that MUST in there to make it very explicit what the required
behavior is.

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

To: [email-masked]
Xref: clerew local.usefor:22644
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 1078, 1088 (was: Ticket status, USEFOR - Sept 21)
Date: Mon, 26 Sep 2005 11:26:52 GMT
Lines: 68
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:
>> Harald Tveit Alvestrand <[email-masked]> writes:

>>> 1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field
>>> in email

>Looking over the current ticket, I'm completely ambivalent, neither
>supporting it nor not supporting it.  The gain in clarity competes with
>the weird feeling about defining headers for e-mail in a news document.

Newsgroups is "our" header, so we get to say what it means. Otherwise,
some mail standard will rush in and say it wrong (look at 'Supersedes').
Indeed, it was such a proposal by Jacob Palme (years ago) that caused it
to appear in our drafts, and he declared himself satisfied by what we had
written.

>>> 1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
>>>   "Text needed" (I think consensus is "MUST generate, MUST NOT require")

>> On Aug 26th I proposed:

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

>RFC 2119 language doesn't belong in notes.  If it's part of the protocol,
>it should be in the main body of the text.

I think Harald agreed recently that RFC 2119 language in NOTEs was fine if
it just quoted some other document, or drew attention to a consequence
which could be deduced from such other documents.

>Other than that, I think this is too wordy.  Let's just say:

>    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.

No, the intent was to explain why it was not in the section for
"mandatory" headers, as might have been expected.

Here is another attempt:

      NOTE: [USEPRO] REQUIRES this header field to be inserted whenever an
      article in injected into the network. However, it has not formally
      been designated as "mandatory" since articles generated by earlier
      systems which do not include it still need to be accepted.

>I assume the fallback to Date is described elsewhere.

Yes.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22646
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1003 msg-id
Date: Mon, 26 Sep 2005 11:43:26 GMT
Lines: 26
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> s/and some news software might have trouble with the full
>> range of possible <msg-id>s permitted by [RFC2822];
>> /and news software complying with [NNTP] would have trouble
>> with the full range of possible <msg-id>s permitted by
>> [RFC2822];/

>How about "...software and [NNTP] have..." ?  There's trouble
>elsewhere with the 2822-concept, not limited to NNTP, and not
>only "might have".

Fine, so long as NNTP gets mentioned as a major reason.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22645
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: pseudo-TLDs
Date: Mon, 26 Sep 2005 11:41:22 GMT
Lines: 35
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Forrest J. Cavalier III wrote:

>> I think prefix dot is much better than underscore.

I agree with Forrest. At least to the extent that a dot is better. But
small inconspicuous characters at the start are liable to get lost, so I
have changed my proposed syntax to

   ...!site.example.com..MISMATCH!...

which was another of Forrest's suggestions. That way we are safe if ICANN
goes mad and envents a MISMATCH TLD.

And it will be immediately recognizable by anybody who is familiar with
the current Diablo usage.

>- Russ or Richard said that diag-keywords like SEEN
>  or MISMATCH are not really useful.

Richard I think. It was a comment by Russ that set me to propose SEEN
a few weeks back.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Mon, 26 Sep 2005 10:28:31 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Sent query: Restrictions on a DNS toplevel name? (fwd)
Sender: [email-masked]

Since I don't believe the USEFOR WG is the correct forum to make a decision 
on the "legal" TLD names, I decided to ask for an opinion....

---------- Forwarded Message ----------
Date: mandag, september 26, 2005 10:27:17 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc:
Subject: DNS question: Restrictions on a DNS toplevel name?

This is a request from the chair of USEFOR for a clarification.

The list has been discussing the properties that are guaranteed of a DNS
top-level name ("TLD name").

The current contenders for the throne are:

- MUST be alphabetic (only contain a-z)
- MUST begin with an alphabetic character (a-z)
- MUST contain at least one alphabetic character
- No guarantees

We think that under all circumstances, it is character set limited to
alphanumerics (a-z, 0-9) and the dash, and that the dash cannot appear as
the first or last character (by virtue of RFC 1123).

We would like to know:

- Which of the 4 theories above is currently believed to be true by the
IETF and by ICANN?
- Where can we find an authoritative statement supporting that theory, and
who is making that statement?

We have so far found RFC 1123 section 2.1 (standard) supporting the first
theory, RFC 3696 section 2 paragraph 8 (Informative) supporting the third,
and RFC 2181 section 11 seeming to support the fourth.

RFC 2860 section 4.3 seems to indicate that the authority is ICANN;
however, it would be strange if ICANN chose to disregard the IETF in this
matter.

Any clarification you can bring would be helpful.

                   Harald Alvestrand

---------- End Forwarded Message ----------

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: 1078, 1088 (was: Ticket status, USEFOR - Sept 21)
Organization: The Eyrie
Date: Fri, 23 Sep 2005 13:15:02 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Harald Tveit Alvestrand <[email-masked]> writes:

>> 1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field
>> in email
>>  "Text proposed" (by Charles)

> I think there was support from Russ, maybe others.

Looking over the current ticket, I'm completely ambivalent, neither
supporting it nor not supporting it.  The gain in clarity competes with
the weird feeling about defining headers for e-mail in a news document.

>> 1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
>>   "Text needed" (I think consensus is "MUST generate, MUST NOT require")

> On Aug 26th I proposed:

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

RFC 2119 language doesn't belong in notes.  If it's part of the protocol,
it should be in the main body of the text.

Other than that, I think this is too wordy.  Let's just say:

    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 assume the fallback to Date is described elsewhere.

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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1101 empty articles
Organization: The Eyrie
Date: Fri, 23 Sep 2005 13:06:55 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> Some servers (INN notably) reject articles with an empty body at the
>> moment, although I've been thinking about changing INN in that respect
>> as it's a pain for mail to news gatewaying.  If we allow them, we
>> probably need to warn somewhere (USEPRO, probably) that propagation may
>> not be great.

> Is that rejection when INN is injecting, or when it is relaying?

INN only cares when injecting.

> Are you aware of other software with this problem?

Not off-hand, but it wouldn't surprise me if it existed.

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

To: [email-masked]
Xref: clerew local.usefor:22635
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Ticket status, USEFOR - Sept 21
Date: Fri, 23 Sep 2005 16:12:55 GMT
Lines: 52
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>1047 USEFOR 3.1.6: Path field delimiters and components
> "Text proposed"

Discussion ongoing

>1052 USEFOR general: Document changes from RFC 2822
> "Text proposed" - appendix C of -05.

>1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field in 
>email
>  "Text proposed" (by Charles)

I think there was support from Russ, maybe others.

>1080 USEFOR 3.2.14: MIME parameters for Injection-Info and Archive
>  header field need more text/updated syntax
>   "No consensus"

Discussion ongoing

>1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
>   "Proposed No Change"

Agree

>1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
>   "Text needed" (I think consensus is "MUST generate, MUST NOT require")

On Aug 26th I proposed:

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

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 Path grammar proposals
Date:  Fri, 23 Sep 2005 19:53:19 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Charles Lindsey wrote:

> OTOH, Frank keeps leaning on me to shorten the list.

In fact I'd sign everything (without checking what it
is) if it's only supported by Russ + Richard + Forrest.

If they'd want ...!source.MATCH!source!... instead of
IIRC Henry's idea !!, fine.

For Harald's idea (an extensible list of keywords) I 
had horrible ideas like SPAM, XXX, EXPLICIT, or even
servers abusing it to insert their Ads into the Path:

...!site!this.path.presented.by.xyzzy.IGNORE!... ugh.

I've seen similar crap in mail header fields (incl.
timestamp lines).
                  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1003 msg-id
Date:  Fri, 23 Sep 2005 19:33:46 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 38
Sender: [email-masked]

Charles Lindsey wrote:

> s/and some news software might have trouble with the full
> range of possible <msg-id>s permitted by [RFC2822];
> /and news software complying with [NNTP] would have trouble
> with the full range of possible <msg-id>s permitted by
> [RFC2822];/

How about "...software and [NNTP] have..." ?  There's trouble
elsewhere with the 2822-concept, not limited to NNTP, and not
only "might have".

>    <[email-masked]>
>    <"ab.cd"@example.com>
>    <"ab.\cd"@example.com>
> (I think that small change has already been accepted)

No problem, that shows "one dot in the middle is no excuse
for using a quoted-string".

> If domain literals are used, they SHOULD take the form of an
> <IPv4address> or <IPv6address> [RFC 3986].

Yes, we'll probably use STD 66 also in other contexts.  For
2821bis I fear it can't simply forbid leading IPv4-zeros, and
so far John never commented my feeble attempts to get rid of
the strange IPv6-tag in 2821bis.  Or the ugly dcontent (with
NO-WS-CTL) for his hypothetical "General-Address-Literal".

> I am happy that the NOTE at the end of 3.1.3 says all that
> needs to be said.

That's where I think that <id-domain> won't need this NOTE,
and your (= you and Harald) discussion about some "artificial
subdomains" in another protocol (NAI) was also interesting
for this issue.
                       Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1046, #1079, #1082 (was: 9 of 17: #1028, #1029, #1046, #1052, #1079, #1082, #1084, #1101, #1102)
Date:  Fri, 23 Sep 2005 19:06:40 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 63
Sender: [email-masked]

Charles Lindsey wrote:

> My feeling is that security problems in 2045 should be fixed
> in 2045bis

Sure, in that case it would be 2046bis.  But as long as they
are not fixed, and we mandate to support MIME+ 2231+ (2)822
CFWS, we have to list this known problem.

Nobody's working on 2046bis at the moment, only MIME part 4
(2048bis) is ready.

> I do not quite follow what your two examples are intended to
> show.

Bruce's example shows that a MIME boundary can be very tricky
if you add 2822 CFWS, my example shows the same for 2231.

"Naive MIME implementations" (as Bruce put it) won't get this
"right", in fact we're not completely sure what "right" is in
the case of a boundary (2046 + 2231 suggest that at least some
syntax oddities shouldn't be used for a boundary).

With that insecure and unclear situation there are two choices:
Delete MIME in USEFOR falling back to a pre-s-o-1036 position
with a 2822 "out-of-scope" approach, or simply document this
"security consideration".

>> That's new for me or I missed it.  Anything relevant for
>> news servers (Xref, Message-ID, Distribution, Newsgroups,
>> Control, Supersedes, Expires, Date, Path, what else ?)

> Add Followup-To, Lines
> But remove Expires, Date (unchanged from 2822)

ACK, I also forgot Followup-To.  It's not "server territory",
but it will end up there (as Newsgroups), and it's the same
<newsgroup-list> without CFWS => Posting or followup agents
trying to add comments in Followup-To are doomed.

  [#1082]
>> The Approved header field indicates the mailing addresses
>> (and possibly the full names) of the persons or entities
>> approving the article for posting. Its principal uses are
>> in moderated articles and in group control messages
>> [USEPRO]

#1082 => ready.

> There should also be a sentence (maybe in a NOTE) such as the
> following

>    The presence of a this header implies a claim to have
>    authority to post the article, thus assisting other sites
>    to determine whether to accept or act upon it.

USEPRO or USEAGE details, that's IMHO irrelevant for USEFOR:

Of course it's a claim, and of course this header field has a
technical purpose (explained elsewhere).

                             Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:22629
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 9 of 17: #1028, #1029, #1046, #1052, #1079, #1082, #1084, #1101, #1102 (was: Ticket status, USEFOR - Sept 21)
Date: Fri, 23 Sep 2005 14:39:02 GMT
Lines: 87
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Harald Tveit Alvestrand wrote:

>> 1028 USEFOR 3.1.2 Date: What zones should be on the
>> MUST accept list?  "Text accepted"

Actually, it is further than that, since I think the accepted text is
already in USEFOR-05.

>That should be ready as soon as the syntax is fixed,
>IIRC s/from/orig-date/

Agreed.

>> 1029 USEFOR 3.2.2 References: Should comments be a
>> MUST NOT? "No consensus"

>The usefor-05 text (SHOULD NOT) is IMHO fine.

Me2

>> 1046 USEFOR 5. MIME boundary security considerations
>> "Text needed"

>Some text was proposed 13 weeks ago in:
><http://article.gmane.org/gmane.ietf.usenet.format/28928>

My feeling is that security problems in 2045 should be fixed in 2045bis,
and security problems in 2231 should be fixed in 2231bis.

In any case, I do not quite follow what your two examples are intended to
show.

>> 1079 USEFOR 2.1: List all header fields which don't allow
>> comments "No discussion"

>That's new for me or I missed it.  Anything relevant for
>news servers (Xref, Message-ID, Distribution, Newsgroups,
>Control, Supersedes, Expires, Date, Path, what else ?)

Add Followup-To, Lines
But remove Expires, Date (unchanged from 2822)

>> 1082 USEFOR 3.2.9: Need more text about Approved header
>> field semantics? "Text proposed"

>Where's that proposed text ?

> The Approved header field indicates the mailing addresses (and 
> possibly the full names) of the persons or entities approving the 
> article for posting. Its principal uses are in moderated articles and 
> in group control messages [USEPRO].

[The last sentence has been added]

There should also be a sentence (maybe in a NOTE) such as the following

   The presence of a this header implies a claim to have authority to post
   the article, thus assisting other sites to determine whether to accept
   or act upon it.

in order to explain the semantics of this header.

>> 1084 USEFOR 2.1, 3: Names for ABNF productions redefining
>> 822 constructs  "Proposed No Change"

>Yes, some kind of rough consensus IIRC.

Me2

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22630
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1101 empty articles
Date: Fri, 23 Sep 2005 14:48:23 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Richard Clayton <[email-masked]> writes:

>> ... so sometimes it's dumb and sometimes its very sensible. I don't see
>> that as a reason for forbidding them in the standard.

The only reason is a sentence in son-of-1036 to the effect that some
software reacts badly to bodyless articles.

Calling Henry! What software did you have in mind, and is that software
still in current use? If not, then we don't need the restriction.

>Some servers (INN notably) reject articles with an empty body at the
>moment, although I've been thinking about changing INN in that respect as
>it's a pain for mail to news gatewaying.  If we allow them, we probably
>need to warn somewhere (USEPRO, probably) that propagation may not be
>great.

Is that rejection when INN is injecting, or when it is relaying?

If the former, it is no problem (the article is returned to the poster and
he fixes it). And you remove the restriction in future releases.

But if it is the latter, then that is a serious problem given the
widespread use of INN, and we would need to say something somewhere.

Are you aware of other software with this problem?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22632
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1003 msg-id (was Ticket status, USEFOR - Sept 21)
Date: Fri, 23 Sep 2005 15:59:49 GMT
Lines: 51
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>It's been a long time since the last one.
>Here's the current list - 17 USEFOR tickets open.

>1003 USEFOR 3.1.3 - Cleanup ABNF for msg-id
> "Text proposed"

I have 3 issues:

1. 3.1.3 1st para:

s/and some news software might have trouble with the full range of
  possible <msg-id>s permitted by [RFC2822];
 /and news software complying with [NNTP] would have trouble with the full
  range of possible <msg-id>s permitted by [RFC2822];/

(where NNTP means the new standard currently with the RFC Editor).

2. <[email-masked]>
   <"ab.cd"@example.com>
   <"ab.\cd"@example.com>
(I think that small change has already been accepted)

3. If domain literals are used, the syntax found in Section 4.1.3 of
   [RFC2821] is RECOMMENDED.

The IPv6Address notation in RFC 2821 is unusual, and I hear might be
dropped in 2821bis. Better to say

or else omit it entirely.

   If domain literals are used, they SHOULD take the form of an
   <IPv4address> or <IPv6address> [RFC 3986].

> We still don't have a good resolution of Frank's "what is the right hand
> side of a message-ID supposed to be" issue.

I am happy that the NOTE at the end of 3.1.3 says all that needs to be
said.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22631
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path grammar proposals
Date: Fri, 23 Sep 2005 14:57:16 GMT
Lines: 36
Sender: [email-masked]

In <F24916A0FFFE2F28F2AD6618@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>--On 22. september 2005 13:35 +0000 Charles Lindsey <[email-masked]>=20
>wrote:

>> 2. Which diagnostics:
>>    POSTED MISMATCH SEEN MATCH have been suggested. Do we want them all, or
>>    fewer?

>A more fundamental question to address is probably whether the set of=20
>diagnostic keywords is cast in concrete by USEFOR or left open for future=20
>extension.

>If it's supposed to be extensible, the USEFOR grammar should say=20
>"diagnostics can exist", but not "these are all the diagnostics that can=20
>be".

That is a new suggestion which I had not considered. Yes, if the WG wants
it so it could be done (or maybe people will just do it anyway).

OTOH, Frank keeps leaning on me to shorten the list. Either way, I would
like to see some mechanism that prevented the present checks made by
relayers from being confused, even with current implementations (hence
some means - keywords/whatever - to distinguish genuine <path-identity>s
from anything else).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1102 agents & servers
Date:  Fri, 23 Sep 2005 17:16:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 9
Sender: [email-masked]

Charles Lindsey wrote:

> USEFOR would then "user agent" and "serving agent"
> (or sometimes just "agent").

I'm at a loss why "serving agent" should be better than
"news-server", but otherwise that could finish #1102
(for USEFOR-06) => editor's choice.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  usefor-06 and #1053 (was: Ticket status, USEFOR - Sept 21)
Date:  Fri, 23 Sep 2005 17:05:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 40
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> 1053 USEFOR 2.1 Relationship to RFC 2822
>  "Text Proposed" - my August 12 message.

news://news.gmane.org/[email-masked]
http://mid.gmane.org/[email-masked]

Some proposed to replace "; agents may choose to accept such
articles, reject such articles or modify such articles." by a
period, otherwise that's ready from my POV.

In my parallel universe the following tickets are "ready" and
only waiting for usefor-06:  #1028, #1029, #1046, #1052 (that
is appendix C), #1053, #1078 (I've not yet seen or missed the
proposed text), #1079, #1082 (I've not yet seen or missed the
proposed text), #1084, #1088 (MUST generate, MUST NOT require
as proposed by Harald), #1101, #1132 (added to #1047, no IPs
in path-identity).

That's 12 of 17, the five remaining issues are: #1003 (3:3:1
with a potential rough 6:1 consensus to derive from 2822 for
the <msg-id>), #1032 (text for appendix B needed), #1047 (the
Path), #1080 (Injection-Info, waiting for Bruce's and Charles'
final proposals), #1102 (use UA/server in USEFOR).

Maybe a good time for a usefor-06:  It confuses me when Charles
talks about new sections replacing non-existing old sections
like "2.10 (was 1.7)".

#1032 and #1102 are no showstoppers.  #1003 could be solved by
a poll during an "internal last call" for usefor-07 (?).

For #1080 we either pick one of two proposals, or there's only
one proposal.  Or we use 3.2.14 as is adding [CFWS] everywhere.

In other words, #1047 is the bottle-neck, but it's possible to
join the recent proposals.
                             Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:22624
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1102 agents & servers (was 9 of 17)
Date: Fri, 23 Sep 2005 14:15:08 GMT
Lines: 45
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Harald Tveit Alvestrand wrote:

>> 1102 USEFOR 1: Definition of "agents" or of "server/UA"?
>>    "No consensus" (although I'm not sure if many care)

However, we need to decide one way or another. Currently, most definitions
are duplicated in both USEFOR and USEPRO. That was not intended to be
permanent. My preference is to define the specialized ones in USEPRO,
where they are extensively used. My analysis has shown that USEFOR can
manage quite well on just two (user agent and news-server/whatever), and I
have offered to propose the detailed changes if the principle appears
acceptable.

>Some (excl. Russ) prefer to say "server/UA" in usefor-06.

Here is a suggestion for a slightly different terminology.

At present, "user agent" encompasses posting agent, followup agent and
reading agent. That seems fine.

We need a similar term to encompass injecting agent, relaying agent and
serving agent. So far, I have come up with news-server (with an awkward
hyphen in it).

My suggestion now is to s/serving agent/storage agent/ throughout USEPRO
(and anywhere else) and then to use "serving agent" to encompass the other
three. In some ways, "storage agent" is more descriptive of what they
actually do, and something involving "serving/server" is more in line with
what the world out there uses for the wider encompassing concept.

USEFOR would then "user agent" and "serving agent" (or sometimes just
"agent").

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: pseudo-TLDs
Date:  Fri, 23 Sep 2005 15:06:58 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 43
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> I think prefix dot is much better than underscore.

Underscore is a "traditional" way to do "funny" things
with DNS labels.  Or at least it pops up in discussions
I've seen again and again (MARID, DKIM, etc.)

For labels a dot would be the worst idea after 0xFF ;-)

Okay, here we're not really creating DNS labels, we
only try to avoid potential conflicts with FQDNs.

As far as host names are concerned undersore is good
enough - and for your dot idea there's also a (small)
chance to get it wrong if say host seen.site.example
exists with ...!.SEEN.site.example!... in the Path.

> Why use up that option and force future innovators
> into a corner for no good reason?

It's what everybody else does or proposes... <shrug />
Some problems with both "leading keyword" proposals:

- Russ or Richard said that diag-keywords like SEEN
  or MISMATCH are not really useful.

- So if we introduce it anyway let's at least stick
  to "common practice" for .MISMATCH (= pseudo-TLD)

- If we do this for .MISMATCH then using a different
  approach for "SEEN" would be odd (assuming that we
  introduce "SEEN" at all)

- Apparently it's *_not impossible_* to reserve such
  pseudo-TLDs, and I didn't know that RfC 2860 detail:
  <http://mid.gmane.org/[email-masked]>

- We're still free to do "the right thing" for POSTED,
  and introduce ...!.POSTED!... or ...!_POSTED!... (?)

                     Bye, Frank

Date: Fri, 23 Sep 2005 07:29:42 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: pseudo-TLDs
Sender: [email-masked]

Frank Ellermann wrote:

> Some folks want a TLD ".berlin", and from there to ".seen"
> (= de for ".seas") would be only a small step.  Forrest's
> ideas, keywords before diag and / or "impossible" keywords
> starting with a dot (or maybe underscore) could guarantee
> to avoid potential conflicts.

I think prefix dot is much better than underscore.  Many
internationalization overloads have been proposed using a prefix 
underscore in the past.

Why use up that option and force future innovators into a corner for 
no good reason?

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Add #1079 to #1052 ?  (was: #1052 Appendix C)
Date:  Fri, 23 Sep 2005 12:36:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

> + The following header fields mainly of interest for servers
> + allow no comments (CFWS):  Control, Distribution, Lines,
> + Message-ID, Newsgroups, Path, and Xref.

Sorry, I forgot Supersedes in this 1079-goes-1052-proposal:

+ The following header fields mainly of interest for servers
+ allow no comments (CFWS):  Control, Distribution, Lines,
+ Message-ID, Newsgroups, Path, Supersedes, and Xref.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1052 Appendix C 
Date:  Fri, 23 Sep 2005 12:05:18 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 114
Sender: [email-masked]

Charles Lindsey wrote:

 [Message-ID details irrelevant in appendix C] 
> No they are not.

>> - Comments are not allowed in the Message-ID header field.
 
> Comments are still allowed in References (at the moment),
> so it it not necessarily all the places msg-id is used. In
> any case, it is an important change from RFC 2822, worthy
> of separate mention.

Maybe we could join this issue with #1079, and just enumerate
all header fields without CFWS:

+ The following header fields mainly of interest for servers
+ allow no comments (CFWS):  Control, Distribution, Lines,
+ Message-ID, Newsgroups, Path, and Xref.

Neither Date nor Expires qualify for that list, it's the same
<date-time> as in 2822 (modulo "magic SP" and obs-* excl. GMT)

I want to kill simple open tickets, and that would be #1079.

>> - The length of a msg-id MUST NOT exceed 250 octets.
> Also worthy of separate mention.

Maybe, but then please near the main entry for Message-ID:

| A more restricted syntax of msg-id (to be used by the
| Message-ID, References, and Supersedes header fields).
+
+ The length of a msg-id MUST NOT exceed 250 octets.

>> + Most obsolete constructs in chapter 4 of [RfC 2822] are
>> + not necessarily accepted.  Two exceptions which still
>> + must be accepted are <obs-phrase> and timezone "GMT".

> Yes, that is better. but I would rather say:
 
>  - The obsolete syntax is in general not required to be
>    accepted, except for the following two cases:
>      1 ...
>      2 ...

Okay, or maybe mix it, "...not required to be accepted. Two
exceptions....".

###############################################################
> Other differences not yet mentioned in Appendix C:
 
> 2.2  The content of the first line of a header MUST NOT
>      consist of WSP only (though such SHOULD be accepted).
[...]

Yes, that belongs to the set "magic SP" + "unstructured not
only WSP":

| A SP (space) is REQUIRED after the colon (':') following
| header field name.

+ The first line of a header field MUST contain non-whitespace
+ characters of the header field body.  All header fields have
+ a non-whitespace header field body.  Header fields such as
+ the Subject cannot be empty or blank.

- An <unstructured> header field body MUST contain at least one
- non-whitespace character (header fields such as Subject can
- not be empty).

> 2.4  All agents MUST support header lines up to 998 octets,
>      but there is no RECOMENDED limit of 78 characters as in
>      RFC 2822.

First, I disagree, second, there is no section 2.4 in USEFOR.
Non-existing sections can't introduce differences from 2822.

> 2.6

There is no section 2.6 in USEFOR => no difference from 2822.
 
> 2.9 (was 1.6)

There is no section 2.9 in USEFOR.  1.6 does not talk about
header fields with the same name.  There's no problem with
one, two, three, or 1000 Archived-At or Keywords or what else.
This is no difference from 2822.

> 2.10 (was 1.7)

There is no section 2.9 in USEFOR-05.  There is also no 1.7.
Minimal MIME compatibility (2049) is implicitly addressed in
section 2.3.  This is no difference from 2822 (1.1 scope):

| There are several extensions published, such as the MIME
| document series [RFC2045, RFC2046, RFC2049], which describe
| mechanisms for the transmission of such data through
| electronic mail, either by extending the syntax provided
| here or by structuring such messages to conform to this
| syntax.  Those mechanisms are outside of the scope of this
| standard.

Appendix C cannot enumerate everything that's not in 2822, it
is about _differences_ : 2822-feature A corresponding to a
USEFOR-feature-A' where A is slightly _different_ from A'.

MIME Content-* header fields don't exist in 2822, like a Path
or Followup-To, so it's pointless to list this in appendix C.

Above all stick to usefor-05.  Talking about new non-existing
sections replacing old non-existing sections makes no sense :-(

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: pseudo-TLDs
Date:  Fri, 23 Sep 2005 10:49:47 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Charles Lindsey wrote:

>> e.g. <http://www.icann.org/tlds/tld-criteria-15aug00.htm>
 
> Right! I did not spot that one on my previous searches
> through IANA. I am much happier now.

Happier ?  You're not hoping that they'd add POSTED, SEEN,
and MISMATCH to their list only because one obscure USEFOR
RfC waiting in the queue for USEPRO and USEAGE says so, or
are you ?

Some folks want a TLD ".berlin", and from there to ".seen"
(= de for ".seas") would be only a small step.  Forrest's
ideas, keywords before diag and / or "impossible" keywords
starting with a dot (or maybe underscore) could guarantee
to avoid potential conflicts.
                              Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 Path grammar proposals
Date:  Fri, 23 Sep 2005 10:32:42 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

Charles Lindsey wrote:

> 2. Which diagnostics:
>    POSTED MISMATCH SEEN MATCH have been suggested.
>    Do we want them all, or fewer?

The server folks apparently say that it's all not very
useful, but at least it might cause no harm.  That's
not very encouraging, therefore I hope that we can get
rid of site!source?MATCH!source!... (for ? read . or !)
using the site!!source!... shorthand.  I hope I have
this concept in my version.

Mix this with your concept "at most one line per site",
i.e. multi-id plus optional diag plus at most one [FWS]
near the end, and it should be good enough.

Maybe add the 3696 <toplabel> concept, it's nowhere else
in syntax (all other RfCs use only "start with ALPHA").

                     Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:22621
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1052 Appendix C (was Re: 9 of 17)
Date: Thu, 22 Sep 2005 22:02:07 GMT
Lines: 87
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Harald Tveit Alvestrand wrote:

>> 1052 USEFOR general: Document changes from RFC 2822
>>  "Text proposed" - appendix C of -05.

>"MUST accept obs-phrase" and "MUST accept GMT" are no
>differences from 2822.  That appendix could be shorter:

>| A more restricted syntax of msg-id (to be used by the
>| Message-ID, References, and Supersedes header fields).

>That says it all, the following details are irrelevant
>for appendix C:

No they are not.

>- Comments are not allowed in the Message-ID header field.

Comments are still allowed in References (at the moment), so it it not
necessarily all the places msg-id is used. In any case, it is an important
change from RFC 2822, worthy of separate mention.

>- The length of a msg-id MUST NOT exceed 250 octets.

Also worthy of separate mention.

>- The <obs-phrase> construct MUST be accepted.

>- The obsolete timezone "GMT" MUST be accepted in the Date
>- header field.

>+ Most obsolete constructs in chapter 4 of [RfC 2822] are
>+ not necessarily accepted.  Two exceptions which still
>+ must be accepted are <obs-phrase> and timezone "GMT".

Yes, that is better. but I would rather say:

 - The obsolete syntax is in general not required to be accepted, except
for the following two cases:
     1 ...
     2 ...

Other differences not yet mentioned in Appendix C:

2.2  The content of the first line of a header MUST NOT consist of WSP
     only (though such SHOULD be accepted). Observe that continuation
     lines of headers also MUST NOT consist of WSP only, as in RFC 2822.

2.4  All agents MUST support header lines up to 998 octets, but there is
     no RECOMENDED limit of 78 characters as in RFC 2822. There is mention
     of a purely advisory limit of 79 (with a reference to USEAGE).

2.6  There must not be more than one header with a given header-name,
     except where explicitly sanctioned by the appropriate standard. In
     particular, there MUST NOT be more than one Keywords-header.

2.9 (was 1.6) RFC 2047 and RFC 2231 are fully integrated into the Netnews.

2.10 (was 1.7) All the Content-* MIME headers are considered to be
     incorporated into Netnews and MUST be accepted in articles at, least
     to the extent required by RFC 2049.

Note. Those wordings come from
http://www.imc.org/ietf-usefor/drafts/rfc2822-diffs.txt. I do not propose
thos particular words, but the points need to be covered. Ken?

Also, in http://www.imc.org/ietf-usefor/mail-archive/msg01901.html, i made
the following suggestion:

I have also suggested, to Ken, adding at the end of the new Appendix C:

   NOTE: The effect of all these differences still preserves the property
   that the articles that Usefor permits to be generated form a proper
   subset of the articles that are required to be acceptable to RFC 2822.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Thu, 22 Sep 2005 21:12:03 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1047 Path grammar proposals
Sender: [email-masked]

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

--On 22. september 2005 13:35 +0000 Charles Lindsey <[email-masked]>=20
wrote:

> 2. Which diagnostics:
>    POSTED MISMATCH SEEN MATCH have been suggested. Do we want them all, =
or
>    fewer?

A more fundamental question to address is probably whether the set of=20
diagnostic keywords is cast in concrete by USEFOR or left open for future=20
extension.

If it's supposed to be extensible, the USEFOR grammar should say=20
"diagnostics can exist", but not "these are all the diagnostics that can=20
be".

--==========0A243D5701D01DA028EB==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========0A243D5701D01DA028EB==========--

To: [email-masked]
Xref: clerew local.usefor:22619
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path grammar proposals
Date: Thu, 22 Sep 2005 13:35:19 GMT
Lines: 97
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>Currently I think that I have approximately 4 ABNF proposals for Path, with 
>many posted variants and fiddles. They are below.

>I think I see a consensus that we don't want to allow underscores in our 
>domain-based identifiers, while they should be allowed in barewords and 
>tail-entries; I don't see anything resembling a consensus on the exact 
>format of a diagnostic.

>If you prefer strongly that the USEFOR update should be based on one of the 
>four variants, please say so.

I prefer either one of mine, or Frank's. Within those, there are
essentially two orthogonal questions to ask:

1. The style of the diagnostics, either
   (a) ...!example.com!MISMATCH!... or
   (b) ...!example.com.MISMATCH!... (or similar)
with POSTED probably in style (a) regardless, for technical reasons.
Note that there is existing usage of style (b) (even for POSTED, in spite
of the technical problem).

2. Which diagnostics:
   POSTED MISMATCH SEEN MATCH have been suggested. Do we want them all, or
   fewer?

>------- Frank's of Sept 20:

> path          = "Path:" SP [FWS] path-list [FWS] CRLF
> path-list     = *( path-entry [FWS] "!" ) tail-entry
> path-entry    = path-identity [ path-diag ]

This is very similar to my 2nd proposal. The essential difference is that
my <path-entry> is several <path-identity>s followed by one optional
<diag/source-identity>, whereas Frank's has just a single <path-identity>
(in which case a site that wants to insert several <path-identity>s for
itself simply inserts several <path-entry>s). I am quite happy to adopt
Frank's structure in my next edition (with appropriate mention in USEPRO).

Any remaining differences are just different ways of writing the ABNF (my
latest ABNF, discussed but not yet published in full) is even closer to
Frank's. He also omits the MATCH keyword (#2 above).

>This has the interesting feature that it removes keywords, and changes the 
>!! delimiter from a "delimiter" to "the introduction to a path-diag".

It essentially does the keywords in style (b). The meaning of "!!" is
exactly the same as the present USEFOR (modulo possible bugs concerning
[FWS], which can be fixed).

>---- Charles' first proposal of Sept 15:

This essentially takes style (a) of #1, and the minimal set from #2.

There are some small changes arising from recent discussions which I have
not published as a full set yet. I also want to put the [FWS] before the
'!' rather than after (as Russ suggested). I will probably simplify the
<path-entry> to be more like Frank's (see above). There remains the issue
of [FWS].

>--- Charles' second proposal of Sept 15:

This essentially takes style (b) of #1, and the maximal set from #2 (and
these are my personal preferences). Other remarks as above,

>------ My proposal of September 13:

This takes style (a) of #1, and the minimal set from #2.

The main differences are that it does not relate the various objects to
FQDNs, IP-addresses and barewords, it allows that ':' in places other than
IPv6addresses (hence more scope for dead:beef problems), and it contains
more ambiguities. OTOH, it is a fair representation of what servers will
in practice recognize (as opposed to the others which show what should be
generated).

>This version needs an update to deal with the consensus to split barewords, 
>tail-entries and domain-based identities, as sketched above.

Which would actually bring it closer to the style of the others.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22618
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path components (was: ADMIN: Final warning to John Stanley)
Date: Thu, 22 Sep 2005 12:00:37 GMT
Lines: 40
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <[email-masked]>, Charles Lindsey
><[email-masked]> writes

>>If FRED identifies himself to good.guy.example (correctly) via SASL, but
>>shows himself as BILL in the <path-identity> he inserts (because he seeks
>>to hide the fact the article passed through him, or he wants to shift some
>>blame onto BILL), then the good,guy site should make the Path look like:
>>
>>    good.guy.example!FRED.MISMATCH!BILL!...
>>
>>and FRED's duplicity is exposed.

>and once again you have no hope of identifying FRED without looking at
>the system configuration (and probably also the system logs) at
>good.guy.example

Sure, but we don't expect to be able easily to identify sites that use
<bareword>s, which is why we encourage the use of domain-names wherever
possible.

So even if I cannot persuade good.guy.example to divulge the identity of
FRED, the fact that he appeared in the MISMATCH is quite useful, because
I can identify him in other Paths, find out who his peers are, see whether
he is regularly in the habit of impersonating BILL (or other people), and
if necessary I can choose to filter out articles with FRED in the Path
(which could be very useful if the malpractice that FRED is engaging in is
some form of hipcrime-like spew or other DOS attack).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22620
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: pseudo-TLDs
Date: Thu, 22 Sep 2005 13:53:58 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> Unfortunately, ICANN never signed up to RFC 2606

>I'd guess that there was an "IETF last call" for this BCP,

I don't think the IETF procedures were quite as rigorous in those days -
and a BCP is not in itself mandatory.

>But actually I think they have no problems with RfC 2606,
>IANA hosted the (dummy) <http://example.org> etc. pages
>for the three example SLDs defined in RfC 2606 chapter 3.

Yes, but they never hosted or reserved example (etc) as a TLD (which
technically could have been done in the same way as those three).

And all of invalid.[org,com,net] are already taken (and not by IANA).

>A Google search "2606 site:icann.org" resulted in 25 hits,
>some indicate that ICANN does know and support this BCP,
>e.g. <http://www.icann.org/tlds/tld-criteria-15aug00.htm>

Right! I did not spot that one on my previous searches through IANA. I am
much happier now.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22617
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Characters used in a tail-entry
Date: Thu, 22 Sep 2005 11:51:47 GMT
Lines: 33
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>these are the characters used in the tail-entry over roughly 100.000 of the 
>articles he had some data on.

>I think it safe to say that the characters in the string "not-for-mail" are 
>overrepresented! - but it seems that * is a more popular character than the 
>humble "q"...... and even the dread ":" makes a few appearances....

I think the main thing is to exclude any character which some server might
think was a delimiter (for then you could not be sure to detect the
boundaries of the <tail-entry>). Hence my suggestion for:

tail-entry = 1*( alphanum / "-" / "_" / "." )

which gives you the union of barewords, domains and IP addresses (except
for ':'). Whatever we put, somebody will try to use something outside of
it (maybe even in supposed barewords). I don't think we should particularly
care, and it is unlikely any actual harm would arise; but I would prefer
not to encourage some of the odder characters by actually including them
in the syntax. Obviously, the few Non-ASCII characters in your sample
ought not to be there.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Characters used in a tail-entry
Date:  Thu, 22 Sep 2005 17:19:30 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> it seems that * is a more popular character than the humble
> "q"...... and even the dread ":" makes a few appearances....

The 154 =B8 are also odd.
http://www.cs.tut.fi/~jkorpela/latin9.html says it's u+017E.

There's a bunch of other Latin-9 charaters occuring 77 times,
maybe it's always the same tail entry with two =B8 (154=2*77).

Your results indicate that allowing "." (dot) is a good move.
And "+" is apparently irrelevant (abusing 154 as the limit):

#   3		{   6		}   6
:   8		$  16		+  49
   50		V  61		|  66
@  67		%  79		q  94
J 109		* 114
                      Bye, Frank

Date: Wed, 21 Sep 2005 23:45:51 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Characters used in a tail-entry
Sender: [email-masked]

Just because Richard gave me access to his logfiles, I felt like I had to 
try...

these are the characters used in the tail-entry over roughly 100.000 of the 
articles he had some data on.

I think it safe to say that the characters in the string "not-for-mail" are 
overrepresented! - but it seems that * is a more popular character than the 
humble "q"...... and even the dread ":" makes a few appearances....

  50
# 3
$ 16
% 79
* 114
+ 49
- 1530391
. 310129
0 83675
1 89062
2 129645
3 39805
4 7962
5 14998
6 19651
7 1836
8 10336
9 11612
: 8
@ 67
A 28605
B 11613
C 7959
D 1780
E 3547
F 106046
G 101465
H 3814
I 6260
J 109
K 112732
L 552
M 106187
N 105156
O 1163
P 74809
Q 298
R 766
S 112420
T 214607
U 3595
V 61
W 1676
X 27671
Y 4697
Z 429
_ 3586
a 828374
b 158969
c 59143
d 18529
e 77279
f 796241
g 168753
h 143763
i 794495
j 1570
k 19999
l 932620
m 827806
n 858626
o 1578315
p 185160
q 94
r 812120
s 85812
t 843265
u 23566
v 4044
w 30353
x 153475
y 7880
z 2031
{ 6
| 66
} 6
¤ 77
¥ 77
¯ 77
° 77
³ 77
¸ 154
¼ 77
À 77
Æ 77
æ 77
ê 77

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1101 empty articles
Organization: The Eyrie
Date: Wed, 21 Sep 2005 11:18:43 -0700
Sender: [email-masked]

Richard Clayton <[email-masked]> writes:

> ... so sometimes it's dumb and sometimes its very sensible. I don't see
> that as a reason for forbidding them in the standard.

Some servers (INN notably) reject articles with an empty body at the
moment, although I've been thinking about changing INN in that respect as
it's a pain for mail to news gatewaying.  If we allow them, we probably
need to warn somewhere (USEPRO, probably) that propagation may not be
great.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1101 empty articles
Date:  Wed, 21 Sep 2005 19:11:55 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 9
Sender: [email-masked]

Richard Clayton wrote:

> sometimes it's dumb and sometimes its very sensible. I don't
> see that as a reason for forbidding them in the standard.

We could keep the s-o-1036 idea (roughly "UAs should warn")
in USEAGE later.
                           Bye, Frank

Date: Wed, 21 Sep 2005 17:51:07 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: #1101 empty articles
Sender: [email-masked]

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes

>> 1101 USEFOR 3: Empty article bodies - yes/no?
>>    "No discussion"
>
>Actually one proposal to reject it.

they turn up in some of the binary groups...

the Subject header field says "Please post X" and the body is empty

        this seems quite sensible

they also turn up from some mass posting programs with the Subject
saying "Here is X (0/17)" (and then you get 17 more articles with
UUENCODEd data, or whatever).  The intent of the author of the posting
tool was that "0/N" would contain a chatty bit of text, but this
particular poster could not be bothered to type anything in and so the
article is empty

        this seems dumb

they also turn up in text newsgroups, where people push the wrong
button, this is also dumb and unpopular....

... so sometimes it's dumb and sometimes its very sensible. I don't see
that as a reason for forbidding them in the standard.

- -- 
richard                                              Richard Clayton

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  9 of 17: #1028, #1029, #1046, #1052, #1079, #1082, #1084, #1101, #1102 (was: Ticket status, USEFOR - Sept 21)
Date:  Wed, 21 Sep 2005 18:14:16 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 97
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> It's been a long time since the last one.

Thanks, I've no clear idea why it doesn't work anymore:
Deleting the old certificate (+ browser restart + get
the new July 11 certificate) didn't help, and...

http://jce.iaik.tugraz.at/servlet/demo.sslserverinfo.SSLServerInfoServlet
http://jce.iaik.tugraz.at/servlet/demo.sslclientinfo.SSLClientInfoServlet

...claim that SSL_RSA_WITH_RC4_128_MD5 "should" work,
as it does with say ietf.org or amazon.  It's not the
known obvious problem with a bogus Netscape "security
library error" message.

If the IETF has yet no patent on "security by obscurity"
I volunteer to submit an I-D explaining the advantange of
TLS user ietf password ietf in relation to ROT-13.  </rant>

> 1028 USEFOR 3.1.2 Date: What zones should be on the
> MUST accept list?  "Text accepted"

That should be ready as soon as the syntax is fixed,
IIRC s/from/orig-date/

> 1029 USEFOR 3.2.2 References: Should comments be a
> MUST NOT? "No consensus"

The usefor-05 text (SHOULD NOT) is IMHO fine.

> 1046 USEFOR 5. MIME boundary security considerations
> "Text needed"

Some text was proposed 13 weeks ago in:
<http://article.gmane.org/gmane.ietf.usenet.format/28928>

Bruce had no problem with the two examples (one about
2822, another about 2231), and while he suggested that
implementors might be only too naive to get it right,
he didn't object that the 2046 authors probably didn't
want any syntactical nightmares for a MIME boundary.

> 1052 USEFOR general: Document changes from RFC 2822
>  "Text proposed" - appendix C of -05.

"MUST accept obs-phrase" and "MUST accept GMT" are no
differences from 2822.  That appendix could be shorter:

| A more restricted syntax of msg-id (to be used by the
| Message-ID, References, and Supersedes header fields).

That says it all, the following details are irrelevant
for appendix C:

- Comments are not allowed in the Message-ID header field.

- The length of a msg-id MUST NOT exceed 250 octets.

- The <obs-phrase> construct MUST be accepted.

- The obsolete timezone "GMT" MUST be accepted in the Date
- header field.

+ Most obsolete constructs in chapter 4 of [RfC 2822] are
+ not necessarily accepted.  Two exceptions which still
+ must be accepted are <obs-phrase> and timezone "GMT".

> 1079 USEFOR 2.1: List all header fields which don't allow
> comments "No discussion"

That's new for me or I missed it.  Anything relevant for
news servers (Xref, Message-ID, Distribution, Newsgroups,
Control, Supersedes, Expires, Date, Path, what else ?)

> 1082 USEFOR 3.2.9: Need more text about Approved header
> field semantics? "Text proposed"

Where's that proposed text ?

> 1084 USEFOR 2.1, 3: Names for ABNF productions redefining
> 822 constructs  "Proposed No Change"

Yes, some kind of rough consensus IIRC.

> 1101 USEFOR 3: Empty article bodies - yes/no?
>    "No discussion"

Actually one proposal to reject it.

> 1102 USEFOR 1: Definition of "agents" or of "server/UA"?
>    "No consensus" (although I'm not sure if many care)

Some (excl. Russ) prefer to say "server/UA" in usefor-06.

                            Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Yet another Path ABNF
Date:  Wed, 21 Sep 2005 16:08:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Charles Lindsey wrote:

> Eh? In all my proposed syntaxes, AFAIR, the "_" was only in
> the <bareword> within the <path-identity> (which it still
> is).

The first <bareword>-enabled versions used <dot-atom-text> -
at the moment I don't find the older underscore-discussions.

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: pseudo-TLDs
Date:  Wed, 21 Sep 2005 14:53:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Sender: [email-masked]

Charles Lindsey wrote:

> Unfortunately, ICANN never signed up to RFC 2606

How's "verisign up" supposed to work in the case of ICANN ?

I'd guess that there was an "IETF last call" for this BCP,
and if they didn't like it their objection didn't make it
into the final text or into a published appeal.

But actually I think they have no problems with RfC 2606,
IANA hosted the (dummy) <http://example.org> etc. pages
for the three example SLDs defined in RfC 2606 chapter 3.

A Google search "2606 site:icann.org" resulted in 25 hits,
some indicate that ICANN does know and support this BCP,
e.g. <http://www.icann.org/tlds/tld-criteria-15aug00.htm>

> the claim within the RFC that IANA had signed up to it
> appears not (or no longer) to be true if you search the
> IANA site.

For the reserved TLDs it's a semantical problem, they
don't "exist", they are forever reserved.  Probably the
Web master is no Escher-fan, otherwise (s)he could list
"TLD example" and the other three as "this is no TLD" ;-)

                      Bye, Frank

Date: Wed, 21 Sep 2005 13:58:14 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Ticket status, USEFOR - Sept 21
Sender: [email-masked]

It's been a long time since the last one.
Here's the current list - 17 USEFOR tickets open.

1003 USEFOR 3.1.3 - Cleanup ABNF for msg-id
 "Text proposed"
 We still don't have a good resolution of Frank's "what is the right hand
 side of a message-ID supposed to be" issue.

1028 USEFOR 3.1.2 Date: What zones should be on the MUST accept list?
 "Text accepted"

1029 USEFOR 3.2.2 References: Should comments be a MUST NOT?
 "No consensus"

1032 USEFOR general: Document changes from RFC 1036
 "Text needed" - waiting for Ken to propose text

1046 USEFOR 5. MIME boundary security considerations
 "Text needed"

1047 USEFOR 3.1.6: Path field delimiters and components
 "Text proposed"

1052 USEFOR general: Document changes from RFC 2822
 "Text proposed" - appendix C of -05.

1053 USEFOR 2.1 Relationship to RFC 2822
 "Text Proposed" - my August 12 message.

---- the tickets below this line are new since the previous summary ---

1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field in 
email
  "Text proposed" (by Charles)

1079 USEFOR 2.1: List all header fields which don't allow comments
  "No discussion"

1080 USEFOR 3.2.14: MIME parameters for Injection-Info and Archive
  header field need more text/updated syntax
   "No consensus"

1082 USEFOR 3.2.9: Need more text about Approved header field semantics?
   "Text proposed"

1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
   "Proposed No Change"

1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
   "Text needed" (I think consensus is "MUST generate, MUST NOT require")

1101 USEFOR 3: Empty article bodies - yes/no?
   "No discussion"

1102 USEFOR 1: Definition of "agents" or of "server/UA"?
   "No consensus" (although I'm not sure if many care)

1132 UEFOR 3.1.6: Outlaw IP address in path-identity?
   "Text accepted" (although the actual text is in #1047, and not finished)

When discussing the specific issues, please include the number in the 
subject header, and STAY ON TOPIC.

Thanks!

                        Harald

Date: Wed, 21 Sep 2005 12:39:04 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Path components (was: ADMIN: Final warning to John Stanley)
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>>>As to things other than IP-addresses preceding MISMATCH (in either of my
>>>syntax versions), I think you have to allow <bareword>s (for UUCP
>>>connections, and for where the "true-identity" which didn't MATCH was
>>>obtained from some SASL authentication rather than the IP of the incoming
>>>packets).  
>
>>that would be rare, but I accept it's possible... however, it seems odd
>>that such a connection would fail to match (SASL doesn't normal permit
>>the wrong person to connect)
>
>If FRED identifies himself to good.guy.example (correctly) via SASL, but
>shows himself as BILL in the <path-identity> he inserts (because he seeks
>to hide the fact the article passed through him, or he wants to shift some
>blame onto BILL), then the good,guy site should make the Path look like:
>
>    good.guy.example!FRED.MISMATCH!BILL!...
>
>and FRED's duplicity is exposed.

and once again you have no hope of identifying FRED without looking at
the system configuration (and probably also the system logs) at
good.guy.example

- -- 
richard                                              Richard Clayton

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

Date: Wed, 21 Sep 2005 12:36:06 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>
>In <[email-masked]> Richard Clayton <[email-masked]> 
>writes:
>
>>In message <[email-masked]>, Charles Lindsey
>><[email-masked]> writes
>
>>>The problem with receiving machine's syslogs is that those sites most
>>>prone to being involved with spams/scams are those most unlikely to be
>>>willing to divulge what is in their syslogs.
>
>>so quite what makes you assume that such wicked sites will bother to
>>record a "MISMATCH" ?
>
>It's not the wicked sites that insert MISMATCHes. They are inserted by the
>good sites downstream from the wicked sites so that their wickedness gets
>exposed:
>
>    good.site!wicked.site.MISMATCH!pretend-to-be-good.site!...

no, what is currently created is

        ...good.site!192.168.2.1.MISMATCH!other.site!...

where the situation is that "good.site" does not believe (for whatever
reason) that 192.168.2.1 is called "other.site"

they could of course discard the article (believing it to be forged) or
they could write the information into their syslog (my original point)

Harald's observation is pertinent, in that "good.site" may not wish to
check their syslogs just because some random netcop thinks that the
article looks dodgy. However, since the IP who owns "192.168.2.1" is
unlikely to tell you anything about its user without a court order I
don't see that this gets you any further.  Also, in practice, since an
IP address is often entirely useless without a timestamp you are going
to have to get "good.site" to look at their logs anyway.

If you really wanted traceability you'd put

        ...!192.168.2.1.04:17:23.GMT.MISMATCH!...

>The point I was trying to make was that wicked sites usually try to attach
>themselves to peers whose abuse-desks are known to be uncooperative to
>abuse investigators.

this is entirely soggy thinking. IMNSHO (I regularly advise a major ISP
on exotic abuse issues) no abuse desk on the planet is -- without the
active co-operation of "good.site" -- going to act on an IP address
(without a timestamp) that someone else placed into a Usenet article
Path: header field. There's just too many ways of forging that
information :(

so this is all wishful thinking ... and the preponderance of system
misconfigurations that Diablo has exposed doesn't really sway me from
that.  I note that Russ doesn't think it does any harm, and I suppose I
agree with that -- but please don't consider it does much good either

- -- 
richard                                              Richard Clayton

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

Date: Wed, 21 Sep 2005 13:34:20 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1047 Path grammar proposals
Sender: [email-masked]

Currently I think that I have approximately 4 ABNF proposals for Path, with 
many posted variants and fiddles. They are below.

I think I see a consensus that we don't want to allow underscores in our 
domain-based identifiers, while they should be allowed in barewords and 
tail-entries; I don't see anything resembling a consensus on the exact 
format of a diagnostic.

If you prefer strongly that the USEFOR update should be based on one of the 
four variants, please say so.

                      Harald

------- Frank's of Sept 20:

 path          = "Path:" SP [FWS] path-list [FWS] CRLF
 path-list     = *( path-entry [FWS] "!" ) tail-entry
 path-entry    = path-identity [ path-diag ]

 tail-entry    = 1*( alphanum / "-" / "_" / "." )

 path-identity = ( 1*( path-label "." ) path-label ) / bareword
 path-label    = alphanum [ *( alphanum / "-" ) alphanum ]
 bareword      = alphanum [ *( alphanum / "-" / "_" ) alphanum ]
 alphanum      = ALPHA / DIGIT

 path-diag     = [ [FWS] "!POSTED" ]
                 [ "!" /                 ; match => "!!"
                   ( [FWS] "!"
                     ( IPv4address       ; see [RFC 3986]
                     / IPv6address       ; see [RFC 3986]
                     / path-identity )
                     ( ".MISMATCH" / ".SEEN" ) ) ]

with a suggested "domain" definition (not referenced above):

   domain   = 1*( label "." ) toplabel     ; at least one dot
   label    = alphanum [ *( alphanum / "-" ) alphanum ]
   toplabel = [label *( "-" )] ALPHA [*( "-" ) label]

This has the interesting feature that it removes keywords, and changes the 
!! delimiter from a "delimiter" to "the introduction to a path-diag".

---- Charles' first proposal of Sept 15:

   path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF

   path-entry = path-identity *( "!" path-identity ) [ "!" "POSTED" ]
                  [ "!" [ source-identity [ "!" "MISMATCH" ] ] ]

   path-identity = fqdn / bareword

   fqdn = 1*( label "." ) toplabel

   label = alphanum / alphanum *( alphanum / "-" ) alphanum

   toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

   alphanum = ALPHA / DIGIT

   bareword = ALPHA / ALPHA *( alphanum / [ "-" / "_" ] ) alphanum )

   tail-entry = fqdn / bareword

   source-identity = fqdn / IP-address / bareword

   IP-address = IPv4address / IPv6address ;  see [RFC 3986]

--- Charles' second proposal of Sept 15:

   path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF

   path-entry = path-identity *( "!" path-identity )[ "!" "POSTED" ]
                   [ "!" [ path-source ] ]

   path-identity = fqdn / bareword

   fqdn = 1*( label "." ) toplabel

   label = alphanum / alphanum *( alphanum / "-" ) alphanum

   toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

   alphanum = ALPHA / DIGIT

   bareword = ALPHA / ALPHA *( alphanum / [ "-" / "_" ] ) alphanum )

   tail-entry = fqdn / bareword

   path-source = source-identity ( ".SEEN" / ".MATCH" / ".MISMATCH" )

   source-identity = fqdn / IP-address / bareword

   IP-address = IPv4address / IPv6address ;  see [RFC 3986]

------ My proposal of September 13:

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 = "!" / "!!"

This version needs an update to deal with the consensus to split barewords, 
tail-entries and domain-based identities, as sketched above.

To: [email-masked]
Xref: clerew local.usefor:22606
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Question: Folding and FWS in Path
Date: Wed, 21 Sep 2005 10:32:28 GMT
Lines: 58
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <[email-masked]>, Charles Lindsey
><[email-masked]> writes

>>The problem with receiving machine's syslogs is that those sites most
>>prone to being involved with spams/scams are those most unlikely to be
>>willing to divulge what is in their syslogs.

>so quite what makes you assume that such wicked sites will bother to
>record a "MISMATCH" ?

It's not the wicked sites that insert MISMATCHes. They are inserted by the
good sites downstream from the wicked sites so that their wickedness gets
exposed:

    good.site!wicked.site.MISMATCH!pretend-to-be-good.site!...

The point I was trying to make was that wicked sites usually try to attach
themselves to peers whose abuse-desks are known to be uncooperative to
abuse investigators.

>Looking at the Diablo release notes (since it is their invention) I find
>the following:

>        Added Path: name checking.  If the first element of the Path:
>        received by an article does not match any 'alias' statements
>        for the incoming connection, the IP address is prepended
>        to the path: with .MISMATCH appended.

Yes, that is more or less what we are trying to say.

>        >>> NOTE <<< you should grep through newly created spool
>        directories every so often looking for .MISMATCH in the spool
>        files to locate incoming feeds with improperly configured
>        'alias's (in dnewsfeeds).  When I turned this feature on,
>        I found that four of my 80+ feeds were misconfigured.

And that looks like excellent advice. I have made a note to consider
something like that at the relevant point in USEPRO.

>so in fact what it is actually attempting to record is sites who do not
>include themselves in the Path: header field, but what it will actually
>record is sites who peer with incorrectly configured servers :)

Plus the occasional genuinely wicked site; hence the reason to try to
minimize such false positives.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22605
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path components (was: ADMIN: Final warning to John Stanley)
Date: Wed, 21 Sep 2005 10:14:53 GMT
Lines: 63
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <[email-masked]>, Charles Lindsey
><[email-masked]> writes

>>The <tail-entry> is a historical oddity. 

>OK, I see that's unavoidable for reasons of interworking

>Why not insist that modern servers (who follow the new rules) just put
>!POSTED into the Path: header field and tell them that if they wish to
>record other information into the article for Traceability reasons to
>use the new header field provided specially for that purpose ?

Because there may be some useful information preloaded into the Path
before it reaches the injector (pseudo-identities such as 'cybercancel'
for example, or some record of paths traversed inside the posting site
before it reached the injector). There is also the rare case of a
reinjection, where there may already be several genuine <path-identity>s
followed by a POSTED (the reinjecting site is supposed to preserve these,
and add a further POSTED, so that everyone can see what has happened).

Also, the injecting site might choose to insert a <source-identity> after
the POSTED:
    injector.example!POSTED!123.123.123.123.SEEN!not-for-mail
(though a posting-host parameter in the Injection-Info would be a more
usual place to do that - but it does happen).

What you propose would in fact work (the 'POSTED' gets ignored just like
'not-for-mail') but it is confusing two concepts, so I would not want to
recommend it.

>>As to things other than IP-addresses preceding MISMATCH (in either of my
>>syntax versions), I think you have to allow <bareword>s (for UUCP
>>connections, and for where the "true-identity" which didn't MATCH was
>>obtained from some SASL authentication rather than the IP of the incoming
>>packets).  

>that would be rare, but I accept it's possible... however, it seems odd
>that such a connection would fail to match (SASL doesn't normal permit
>the wrong person to connect)

If FRED identifies himself to good.guy.example (correctly) via SASL, but
shows himself as BILL in the <path-identity> he inserts (because he seeks
to hide the fact the article passed through him, or he wants to shift some
blame onto BILL), then the good,guy site should make the Path look like:

    good.guy.example!FRED.MISMATCH!BILL!...

and FRED's duplicity is exposed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Question: Folding and FWS in Path
Organization: The Eyrie
Date: Tue, 20 Sep 2005 09:47:51 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> I bet that MISMATCHes will be extremely common.  They are often seen
>> already even though only one server adds them (and then in somewhat
>> limited situations, I believe).

> The few that I looked at in detail appeared not to be genuine MISMATCHes
> - most likely inadequate checking by the match detection software. The
> same sequence of Paths involving the same MISMATCH turned up again and
> again.

Right.  This will probably be common.

> If a newsadmin is regularly inserting a MISMATCH for some site, then he
> ought to be discussing with the peer in question what is going wrong, or
> else he should fix his software (or more likely his 'sys' file).

I think it's unlikely that anyone is going to do this on a regular basis.

> If there are too many such false positives, then the whole value of the
> MISMATCH notation (which is to catch bogously preloaded Paths) will be
> lost.

Yup, hence my skepticism, although I'm willing to support having the
feature in the standard given how many people have asked for it over the
years.

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

Date: Tue, 20 Sep 2005 16:20:32 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

--On mandag, september 19, 2005 17:00:30 +0000 Charles Lindsey 
<[email-masked]> wrote:

> The problem with receiving machine's syslogs is that those sites most
> prone to being involved with spams/scams are those most unlikely to be
> willing to divulge what is in their syslogs.

.... and those involved with spams/scams will be willing to put in 
MISMATCH....?

those who wish to lie will lie, no matter what the standard says.
If you presume a manager acting in good faith, the difference is in the 
amount of resources needed to get him to look at the logs.

Note: That MAY be a huge difference....

Date: Tue, 20 Sep 2005 14:57:57 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>In <[email-masked]> Richard Clayton <[email-masked]> 
>writes:

>> but if there's this huge encouragement
>>for adding diagnostics (which I suspect will be mainly ignored, the
>>place for a MISMATCH is in the receiving machine's syslog, not on the
>>propagated article) then the Path header lines are going to be rather
>>longer than at present...
>
>MISMATCHes will be relatively uncommon, with little effect on the length.
>
>The problem with receiving machine's syslogs is that those sites most
>prone to being involved with spams/scams are those most unlikely to be
>willing to divulge what is in their syslogs.

so quite what makes you assume that such wicked sites will bother to
record a "MISMATCH" ?

Looking at the Diablo release notes (since it is their invention) I find
the following:

        Added Path: name checking.  If the first element of the Path:
        received by an article does not match any 'alias' statements
        for the incoming connection, the IP address is prepended
        to the path: with .MISMATCH appended.

        >>> NOTE <<< you should grep through newly created spool
        directories every so often looking for .MISMATCH in the spool
        files to locate incoming feeds with improperly configured
        'alias's (in dnewsfeeds).  When I turned this feature on,
        I found that four of my 80+ feeds were misconfigured.

so in fact what it is actually attempting to record is sites who do not
include themselves in the Path: header field, but what it will actually
record is sites who peer with incorrectly configured servers :)

However, it is out there and although I note that Diablo now has a
"nomismatch" command to turn the feature off, it must be useful to
someone and so I suppose we have to allow it somehow.

- -- 
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"

Date: Tue, 20 Sep 2005 14:43:02 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Path components (was: ADMIN: Final warning to John Stanley)
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>>However, having thought about the issues a little more, my current
>>challenges are for someone to explain what purpose the <tail-entry>
>>serves in the revamped Path: header field, and secondly to explain a
>>scenario when a diagnostic such as MISMATCH could ever be attached to
>>anything other than an IP address.
>
>The <tail-entry> is a historical oddity. 

yes indeed, and serves no further useful purpose

>But it has to be there, because
>present practice (and USEPRO) is that it should be ignored by relaying
>agents when checking for peers in the path-list. 

OK, I see that's unavoidable for reasons of interworking

>(Or, if you like,
>everything after the last "!" is to be ignored).

Why not insist that modern servers (who follow the new rules) just put
!POSTED into the Path: header field and tell them that if they wish to
record other information into the article for Traceability reasons to
use the new header field provided specially for that purpose ?

>As to things other than IP-addresses preceding MISMATCH (in either of my
>syntax versions), I think you have to allow <bareword>s (for UUCP
>connections, and for where the "true-identity" which didn't MATCH was
>obtained from some SASL authentication rather than the IP of the incoming
>packets).  

that would be rare, but I accept it's possible... however, it seems odd
that such a connection would fail to match (SASL doesn't normal permit
the wrong person to connect)

>And if the site detecting the MISMATCH has been kind enough to
>reverse-lookup an incoming IP address and give you the result of that,
>then you (as a human peruser of the Path) should be grateful that it has
>saved you the trouble of doing it yourself. 

no, you should curse it for failing to understand a key principle of
making traceability robust :(   see the LINX BCP document of
Traceability (or my PhD thesis) for a longer explanation of why :(

>Since many sites currently
>seem to do just that, then we should allow the practice to continue.

I rather suspect, as I said before, that they may have subtly different
semantics in that they are recording who it was supposed to be, rather
than who it was :(

- -- 
richard                                              Richard Clayton

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

To: [email-masked]
Xref: clerew local.usefor:22599
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Yet another Path ABNF (was: #1132: Allowing IP addresses as path-identiites - Poll result)
Date: Tue, 20 Sep 2005 11:38:20 GMT
Lines: 36
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> OK, I've put that into my syntax proposal.

>Oops, careful, it was wrong, I forgot the critical hyphens for
>labels like 12-A--3.  A bit like <id-special> aka <mqspecial>:

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

OK, I now have that.

>> Eh? There is no proposal anywhere to allow "_" in FQDNs.

>Harald mumbled something in that direction, and you refused for
>months to kill the underscores in non-<bareword>s:

> <http://permalink.gmane.org/gmane.ietf.usenet.format/30046>
>|> Like Charles you also have an "_" in the <path-identity> for
>|> the non-<bareword> case.

Eh? In all my proposed syntaxes, AFAIR, the "_" was only in the <bareword>
within the <path-identity> (which it still is).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22600
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: pseudo-TLDs
Date: Tue, 20 Sep 2005 11:43:20 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>!example.com..POSTED!tail

>or the easier to parse....

>!.POSTED.example.com!tail

But neither of those will be recognised as "example.com" by a relayer
which is not supposed to send articles back to there (unless its 'sys'
file has been deliberately pre-loaded with "example.com..POSTED", etc).

That is why we invented the ...!example.com!POSTED!... notation (as in our
present draft), and which I still retain even in my 2nd alternative.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22598
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: pseudo-TLDs (was: #1132: Allowing IP addresses as path-identiites - Poll result)
Date: Tue, 20 Sep 2005 11:28:49 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> We are actually at the mercy of ICANN for several things,
>> including "example", "POSTED", "MISMATCH, etc.

>"example" etc. are in a BCP:  <http://purl.net/net/rfc/2606>

Unfortunately, ICANN never signed up to RFC 2606, and the claim within the
RFC that IANA had signed up to it appears not (or no longer) to be true if
you search the IANA site. "invalid" has the same problem.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22597
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Question: Folding and FWS in Path
Date: Tue, 20 Sep 2005 11:24:21 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> MISMATCHes will be relatively uncommon, with little effect on the
>> length.

>I bet that MISMATCHes will be extremely common.  They are often seen
>already even though only one server adds them (and then in somewhat
>limited situations, I believe).

The few that I looked at in detail appeared not to be genuine MISMATCHes -
most likely inadequate checking by the match detection software. The same
sequence of Paths involving the same MISMATCH turned up again and again.

If a newsadmin is regularly inserting a MISMATCH for some site, then he
ought to be discussing with the peer in question what is going wrong, or
else he should fix his software (or more likely his 'sys' file). If there
are too many such false positives, then the whole value of the MISMATCH
notation (which is to catch bogously preloaded Paths) will be lost.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Status
Date:  Tue, 20 Sep 2005 04:34:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 6
Sender: [email-masked]

Last public ticket status:  2005-07-19,  572 articles ago,
http://permalink.gmane.org/gmane.ietf.usenet.format/29539

Last visit by the editor:   2005-06-27,  963 articles ago,
http://permalink.gmane.org/gmane.ietf.usenet.format/29149

Date: Mon, 19 Sep 2005 22:10:31 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: pseudo-TLDs
Sender: [email-masked]

Frank Ellermann wrote:
> I'd prefer a clean solution, maybe 'all top labels starting
> with x- are invalid' resulting in "x-POSTED" etc.
> 
> OTOH there is already "invalid" for this purpose - whatever
> we do, we lose. same problem as with "local".

!example.com..POSTED!tail

or the easier to parse....

!.POSTED.example.com!tail

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Yet another Path ABNF (was: #1132: Allowing IP addresses as path-identiites - Poll result)
Date:  Tue, 20 Sep 2005 03:52:15 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 61
Sender: [email-masked]

Charles Lindsey wrote:

  [3696 rule for TLDs]
>> toplabel = [ label ] ALPHA [ label ]    ; at least one ALPHA

> OK, I've put that into my syntax proposal.

Oops, careful, it was wrong, I forgot the critical hyphens for
labels like 12-A--3.  A bit like <id-special> aka <mqspecial>:

   domain   = 1*( label "." ) toplabel     ; at least one dot
   label    = alphanum [ *( alphanum / "-" ) alphanum ]
   toplabel = [label *( "-" )] ALPHA [*( "-" ) label]

We don't need these <toplabel> details for something remotely
related to your pseudo-TLD .MISMATCH version (second version).

>> The (apparent) consensus here to allow "_" in addition to
>> "-" is already at odds with what "everybody" thinks to know.

> Eh? There is no proposal anywhere to allow "_" in FQDNs.

Harald mumbled something in that direction, and you refused for
months to kill the underscores in non-<bareword>s:

 <http://permalink.gmane.org/gmane.ietf.usenet.format/30046>
|> Like Charles you also have an "_" in the <path-identity> for
|> the non-<bareword> case.

| Yep. Allowing _ in hostnames seems to be an old tradition for
| USEFOR drafts, and I didn't change it for this.

If you now say that this was all wrong and underscores are of
course nonsense outside of <bareword> or <tail-entry> it will
again change the resulting syntax:

 path          = "Path:" SP [FWS] path-list [FWS] CRLF
 path-list     = *( path-entry [FWS] "!" ) tail-entry
 path-entry    = path-identity [ path-diag ]

 tail-entry    = 1*( alphanum / "-" / "_" / "." )

 path-identity = ( 1*( path-label "." ) path-label ) / bareword
 path-label    = alphanum [ *( alphanum / "-" ) alphanum ]
 bareword      = alphanum [ *( alphanum / "-" / "_" ) alphanum ]
 alphanum      = ALPHA / DIGIT

 path-diag     = [ [FWS] "!POSTED" ]
                 [ "!" /                 ; match => "!!"
                   ( [FWS] "!"
                     ( IPv4address       ; see [RFC 3986]
                     / IPv6address       ; see [RFC 3986]
                     / path-identity )
                     ( ".MISMATCH" / ".SEEN" ) ) ]

Bill's parser still says "no error".  I'd prefer to rename the
<bareword>, how about <obs-id> ?  It's an obs-cenity and broken
by design, the world map project died in the second millennium.

                         Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  pseudo-TLDs (was: #1132: Allowing IP addresses as path-identiites - Poll result)
Date:  Tue, 20 Sep 2005 02:58:52 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Charles Lindsey wrote:

> We are actually at the mercy of ICANN for several things,
> including "example", "POSTED", "MISMATCH, etc.

"example" etc. are in a BCP:  <http://purl.net/net/rfc/2606>

"POSTED" and "MISMATCH" are some madness found in the wild.

I'd prefer a clean solution, maybe 'all top labels starting
with x- are invalid' resulting in "x-POSTED" etc.

OTOH there is already "invalid" for this purpose - whatever
we do, we lose. same problem as with "local".

                             Bye, Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Question: Folding and FWS in Path
Organization: The Eyrie
Date: Mon, 19 Sep 2005 12:59:03 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Richard Clayton <[email-masked]> writes:

>> it isn't there at the moment...  but if there's this huge encouragement
>> for adding diagnostics (which I suspect will be mainly ignored, the
>> place for a MISMATCH is in the receiving machine's syslog, not on the
>> propagated article) then the Path header lines are going to be rather
>> longer than at present...

> MISMATCHes will be relatively uncommon, with little effect on the
> length.

I bet that MISMATCHes will be extremely common.  They are often seen
already even though only one server adds them (and then in somewhat
limited situations, I believe).

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

To: [email-masked]
Xref: clerew local.usefor:22591
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Question: Folding and FWS in Path
Date: Mon, 19 Sep 2005 17:00:30 GMT
Lines: 69
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <153526FD4DE53138862E87A0@B50854F0A9192E8EC6CDA126>, Harald
>Tveit Alvestrand <[email-masked]> writes
>>
>>1) Is there a group consensus to allow folding of Path?

I had understood that the last time we discussed this (not that long ago)
we agreed to leave it as it is.

>that said, all that goes wrong is that peers are offered extra articles
>which they then refuse based on the message-ID, so it's not the end of
>the world, just a small amount of extra traffic -- recall that paths
>across Usenet are often of very similar (very fast speed) so multiple
>peers often offer you the same article. Path: is there for a slower
>gentler Usenet where if you have an article, the chances are that none
>of your peers does, but if they do have it, then it's in a long queue
>heading your way and you'd do them a favour by not overloading them
>further by offering it to them

Exactly so. If a site really is receiving excessive traffic because some
peer is ignoring the Path after the first fold (N.B. peering sites, if
present, will tend to be near the start of the Path), then he simply has
to lean on the offending peer(s) to upgrade to this new-fangled standard
(and it won't be all that new-fangled by the time folded Paths are
appearing in significant quantity).

The effect is noway as harmful as would be the case of allowing folding in
the Newsgroups header before the bulk of servers had upgraded.

>>2) Is there a group consensus to allow whitespace in Path?

Whitespace was clearly allowed (as a delimiter) by RFC 1036; hence folding
was also implicitly allowed - the problem is that implementations largely
ignored this.

>it isn't there at the moment...  but if there's this huge encouragement
>for adding diagnostics (which I suspect will be mainly ignored, the
>place for a MISMATCH is in the receiving machine's syslog, not on the
>propagated article) then the Path header lines are going to be rather
>longer than at present...

MISMATCHes will be relatively uncommon, with little effect on the length.

The problem with receiving machine's syslogs is that those sites most
prone to being involved with spams/scams are those most unlikely to be
willing to divulge what is in their syslogs.

>>3) If yes: Are these features in status "use them now", or are they in 
>>status "MUST accept, SHOULD NOT generate"?

>If they must be there, then I think that would be best

That would be possible. But my preference would be for something like "MAY
generate, though it might result in a small increase of traffic to sites
whose peers are not yet upgraded to this standard".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22587
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Mon, 19 Sep 2005 13:18:49 GMT
Lines: 55
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>You've removed "path-keyword" - so what you're proposing is different from 
>what's specified in the current documents, not just a different syntax.

There are two issues here, and it is important to realise they are
orthogonal and can be decided separately.

1. Do the keywords take the form of (a) ...!KEYWORD!... or (b)
...!foo.example.KEYWORD!... .

2. What set of keywords (POSTED/SEEN/MATCH/MISMATCH/WHATEVER) do we
provide?

Ad #1, I opriginally proposed ...!KEYWORD!..., and it was accepted (hence
that is the current official WG position). The reason was that if you
allow

...!injector.example.com.POSTED!tail-entry

then a site that peers with injector.example.com will not know that it is
not supposed to relay the article back to injector.example.com. OTOH, it
does not matter with

...!news.example.com.MISMATCH!bogus.example.com!...

because you are not supposed to look at <diagnostic/source-identity>s when
deciding which peers to relay to. Note that there is some existing
practice with style (b) with both MISMATCH and POSTED.

Hence my proposed 2nd alternative used style (b) for MISMATCH et al, but
still used style <a) for POSTED.

Ad #2, POSTED is presumably non-controversial, as it MISMATCH. There seems
some merit in SEEN (so that all <diagnostic/source-identity>s are
immediately recognizable as such). MATCH is just for the sake of
completeness; it is redundant and would be discouraged in USEPRO; if the
WG wants to omit it, I have no problem.

>I'm hesitant to change what's in the documents, but I think there's still 
>no implementation of these features, and getting the keywords into the 
>diagnostics rather than treating them separately appeals to me.

Essentially, you are supporting style (b), but maybe not for POSTED.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22590
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Domain-shaped names not in the DNS (Re: #1047 and #1132 - USEPRO text for section 2.3)
Date: Mon, 19 Sep 2005 13:51:55 GMT
Lines: 59
Sender: [email-masked]

In <3681FAD199B3ABFFA052F08B@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>--On 15. september 2005 16:18 +0000 Charles Lindsey <[email-masked]>=20
>wrote:

>> You could, but there is still no sure way for a person reading the
>> not-DNS-hostname to discover who owns it.

>Why does he need to know?
>He knows who ADMINISTERS it, and if the administrator does not know who he=20
>allocated it to - that's bad for the administrator.
>So if he HAS to, he has an administrative chain to chase.

The reason people examine the Path closely and might wish to know the true
identity of particular sites is usually that they suspect some
malpractice/spam/scam/whatever.

Sadly, it is also the case that the higher you go in the levels of DNS
(which usually brings you to some large and bureaucratic organization such
as an ISP or other provider of connectivity services), the greater the
reluctance you find to provide information about individual sites (short
of a court order or other such blunt instrument) and the more likely you
are to find an abuse desk which simply presents a canned reply from a
rather limited repertoire (or worse, just acts like /dev/null).

Moreover, it is knwon that spammers/acammers/whoever tend to gravitate
towards large sites with poor records of fighting abuse.

Therefore, if a domain-name that actually resolves to something is
required, you have a much better chance to locate it. It it is an MX
record, you have someone to mail to. If it resolves to an IP-address, you
can find who owns that block, or you can use traceroute to get a fair idea
of its location.

I grant you that a <bareword> is not easily traceable, but at least you
can see it for what it is and adjust your strategy accordingly (e.g. by
examing lots of Paths to see who it peers with).

>I have heard multiple people pushing strongly against encouraging more use=20
>of <bareword>. Pointing out that you can get an unique name by leveraging=20
>administrative control of DNS domains would help lessen the need for=20
><bareword>.

No, what you have heard is lots of people saying that a <bareword> is
undesirable when a _useable_ domain-name is available. But not that a
<bareword> is any worse than a bogus domain-name. And it is agreed that
there are cases where a <bareword> is indeed a reasonable thing to use.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22584
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Mon, 19 Sep 2005 11:53:12 GMT
Lines: 59
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> Frank found a nice syntax for <hostname> in RFC 2396
>> its successor RFC 3986 has removed that, and refers you
>> instead to RFC 1034 plus RFC 1123.

>Maybe we need a 3696bis as a BCP, not only "informational".
>The relaxed 3696 idea without optional trailing dot is:

What we actually need is a 1034/1035bis :-( .

> toplabel = [ label ] ALPHA [ label ]    ; at least one ALPHA

OK, I've put that into my syntax proposal.

>The (apparent) consensus here to allow "_" in addition to
>"-" is already at odds with what "everybody" thinks to know.

Eh? There is no proposal anywhere to allow "_" in FQDNs. It is proposed to
allow it in <bareword>s, because it always has been so since out earliest
drafts, and there is apparently some usage (someone said so here recently
IIRC).

>> do we want to be able to distinguish <source-identity>s from
>> <path-identity>s by the presence of .SEEN/.MATCH/.MISMATCH,
>> or somesuch)?

>IMHO a <source> is only relevant for !source.MISMATCH! cases.

But there is existing practice to insert the source (usually as an
IP-address) by sites which apparently haven't checked whether it MATCHes
or not. Hence the proposal to introduce ".SEEN" (or "!SEEN!").

Whether you then introduce ".MATCH" (or "!MATCH!") is just a matter of
being consistent by offering the complete set. If it is allowed, USEPRO
will certainly discourage you from using it, in favour of "!!".

>Or even site!!path-id!claimed-id!... (is that really okay ?)

No, because that looks like the same site inserted both path-id and
claimed-id (just to cover all its options - like demon who might want both
"demon" and "news.demon.co.uk" to be present because some peers expected
one and some the other).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22583
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Mon, 19 Sep 2005 11:32:58 GMT
Lines: 38
Sender: [email-masked]

In <171EBBFFC2E070D0E8648F37@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>--On 15. september 2005 16:04 +0000 Charles Lindsey <[email-masked]>=20
>wrote:

>How about this?
>>
>>            If a dotted-decimal number can be entered without such
>>            identifying delimiters, then a full syntactic check must be
>>            made, because a segment of a host domain name is now allowed
>>            to begin with a digit and could legally be entirely numeric
>>            (see Section 6.1.2.4).  However, a valid host name can never
>>            have the dotted-decimal form #.#.#.#, since at least the
>>            highest-level component label will be alphabetic.
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

OK. Point noted (though "will be alphabetic" is not quite the same thing
as "MUST be alphabetic"). Anyway, all the syntaxes under discussion
incorporate it.

>Actually, we are somewhat at the mercy of ICANN here, but so far, I haven't
>seen even a single application for an all-numeric (or even seminumeric) =
>TLD.

We are actually at the mercy of ICANN for several things, including
"example", "POSTED", "MISMATCH, etc.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22586
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Mon, 19 Sep 2005 12:57:39 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Open questions:  what is allowed in a <tail-entry> ?

Given that it's intended to be ignored, it doesn't really matter provided
there is nothing that might ever be recognized as a delimiter inside it.
My present thought is just

tail-entry = 1*( alphanum / "-" / "_" / "." )

>Is Charles ready to drop the "multi-id per entry" idea in
>the syntax ?  If not adding it is simple:

I have no huge problem with that, provided it is made clear somewhere,
i.e. USEPRO, that a site can add several entries it it wishes (e.g.
...!demon!news.demon.co.uk!... so as to keep all its peers happy). The
only difference my syntax would make is that it would not allow a
<source-identity> in the middle of one site's bunch (it would be stupid to
do so, but no great harm would arise).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22588
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Mon, 19 Sep 2005 13:23:02 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Between the various alternativesly currently being discussed, I have no
>strong opinions.  I think they'd all likely work.  The only caveat is that
>I think it would be useful to allow, however tagged or indicated, a server
>to just always put diagnostic information into the Path for all peers
>rather than requiring that all servers using the new Path format do Path
>identity checking.

That checking is currently a MUST in USEPRO (to encourage sites to upgrade
ASAP). I think you are suggesting reducing it to SHOULD. That can easily
be done if the WG wishes, though I personally prefer MUST.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22589
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path components
Date: Mon, 19 Sep 2005 13:31:09 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Richard Clayton wrote:

> [tail-entry]
>> it is probably worth wondering if the <tail-entry> actually
>> serves a useful purpose of any kind ?

>> Why exactly are we keeping it ?

>Actually we're "introducing" it, it was optional in RfC 1036:

>| Normally, the rightmost name will be the name of the
>| originating system.  However, it is also permissible to
>| include an extra entry on the right, which is the name of the
>| sender.  This is for upward compatibility with older systems.

>If we require it (like s-o-1036) it's at least clear that the
>right-most entry (e.g. "not-for-mail") is _always_ irrelevant.

>> So is there another reason ?

>Guessing:  ordre, contreordre, desordre.  We can't forbid it.
>Making it optional (again, like 1036) is worse than required ?

Exactly so. Current practice is that it is always present, but is ignored
when deciding which peers to relay to (as in s-o-1036). That has been in
all our drafts (last discussed about 7 years ago), and is best left so.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22585
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Mon, 19 Sep 2005 12:50:14 GMT
Lines: 20
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>I'll make a brief plea to disallow [FWS] after "!" rather than before, if
>you're introducing folding, on the same grounds that most programming
>style guides recommend:

No problem with that. I have made a note to put it before in the next
version of my syntax (modulo whatever comes out of Harald's latest
initiative).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Question: Folding and FWS in Path
Organization: The Eyrie
Date: Fri, 16 Sep 2005 11:04:38 -0700
Sender: [email-masked]

Forrest J Cavalier <[email-masked]> writes:
> Richard Clayton wrote:

>> it looks very dangerous to me -- it will stop Path working at all for
>> any system that does not unfold before consulting it that said, all
>> that goes wrong is that peers are offered extra articles which they
>> then refuse based on the message-ID, so it's not the end of the world,
>> just a small amount of extra traffic

> Some (many?) peering servers keep only a limited message-ID cache,
> representing several hours of message IDs, not days.  Am I mistaken?

They certainly shouldn't!  There's absolutely no guarantee that one's
duplicates will follow a common path, and such a server would accept
duplicate articles in practice unless it also imposed tight restrictions
on Date.

(Unless perhaps you're talking only about the fast in-memory cache as
opposed to the full history file?)

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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Organization: The Eyrie
Date: Fri, 16 Sep 2005 11:02:20 -0700
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:
> Harald Tveit Alvestrand wrote:

>> You've removed "path-keyword" - so what you're proposing is
>> different from what's specified in the current documents,
>> not just a different syntax.

> Actually I'm lost what the server folks here (Richard, Russ,
> Forrest) really want.

Between the various alternativesly currently being discussed, I have no
strong opinions.  I think they'd all likely work.  The only caveat is that
I think it would be useful to allow, however tagged or indicated, a server
to just always put diagnostic information into the Path for all peers
rather than requiring that all servers using the new Path format do Path
identity checking.

> Richard said what he sees in practice is the diag.MISMATCH-style, that's
> Charles's second variant (with a similar diag.SEEN).

Right, Diablo does this now and Andrew submitted a patch to INN to do this
as well, a long time back, which I haven't applied because I was waiting
for the working group to converge on a recommendation for how this
information should be formally represented.

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

Date: Fri, 16 Sep 2005 12:24:32 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

> 1) Is there a group consensus to allow folding of Path?

I'm mildly opposed.

> 2) Is there a group consensus to allow whitespace in Path?

Likewise

> 3) If yes: Are these features in status "use them now", or are they in=20
> status "MUST accept, SHOULD NOT generate"?

The latter; I suspect there's too much existing software that will be
very unhappy with it (at least, won't check properly the whitespaced
entry, similar to what happened with Newsgroups).

Seth

To: [email-masked]
Xref: clerew local.usefor:22573
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path components (was: ADMIN: Final warning to John Stanley)
Date: Fri, 16 Sep 2005 11:32:37 GMT
Lines: 75
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <[email-masked]>, Charles Lindsey
><[email-masked]> writes
>>
>>In <[email-masked]> Richard Clayton <[email-masked]> 
>>writes:
>>
>>>and add to these the following path identities from machines (actually I
>>>think most of these will be usernames, which the POSTED requirement
>>>would hide away) which only passed articles _to_ the peering core (ie
>>>never receiving articles from the core and passing them on)
>>
>>If you are saying that many of these were <tail-entry>s, then they can do
>>no harm, because relayers are supposed to ignore the <tail-entry> (i.e.
>>you can happily use "dead" or "beef" as your <tail-entry>).
>>
>>Does your data enable you to distinguish and remove such <tail-entry>s
>>from your list? 

>I have the raw data still and could remove the last entry in the Path:
>but in the real world there tend to be several entries at the end of the
>path which serve a similar purpose (purporting to identify the poster)
>and there is no algorithmic method of distinguishing them

Sure, but if a site adds foo!bar!tail-entry to the Path before injecting,
then "foo" and "bar" are likely to be identities of hosts within the
poster's site, or deliberate attempts to keep the article from appearing
at some sites (the 'cybercancel' convention, for example), or similar. So
it may well be less likely for them to consist of four (or less) hex
digits.

>However, having thought about the issues a little more, my current
>challenges are for someone to explain what purpose the <tail-entry>
>serves in the revamped Path: header field, and secondly to explain a
>scenario when a diagnostic such as MISMATCH could ever be attached to
>anything other than an IP address.

The <tail-entry> is a historical oddity. But it has to be there, because
present practice (and USEPRO) is that it should be ignored by relaying
agents when checking for peers in the path-list. (Or, if you like,
everything after the last "!" is to be ignored).

I agree its form could be freer than my syntax makes it (so long as it
contains no "!"), but there might be problems in allowing it to be empty
(i.e. a path-list ending in "!") since I know of no surrent practice like
that.

How about:

   tail-entry = 1*( alphanum / "-" / "_" / "." )

i.e. pretty much anything that is clearly not a delimiter?

As to things other than IP-addresses preceding MISMATCH (in either of my
syntax versions), I think you have to allow <bareword>s (for UUCP
connections, and for where the "true-identity" which didn't MATCH was
obtained from some SASL authentication rather than the IP of the incoming
packets).  And if the site detecting the MISMATCH has been kind enough to
reverse-lookup an incoming IP address and give you the result of that,
then you (as a human peruser of the Path) should be grateful that it has
saved you the trouble of doing it yourself. Since many sites currently
seem to do just that, then we should allow the practice to continue.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Fri, 16 Sep 2005 16:05:06 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Forrest J. Cavalier III" <[email-masked]>, [email-masked]
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

--On fredag, september 16, 2005 08:26:12 -0400 "Forrest J. Cavalier III" 
<[email-masked]> wrote:

> Richard Clayton wrote:
>
>> it looks very dangerous to me -- it will stop Path working at all for
>> any system that does not unfold before consulting it
>>
>> that said, all that goes wrong is that peers are offered extra articles
>> which they then refuse based on the message-ID, so it's not the end of
>> the world, just a small amount of extra traffic
>
> Some (many?) peering servers keep only a limited message-ID cache,
> representing
> several hours of message IDs, not days.  Am I mistaken?
>

I think the last discussion of the message-id cache ("history file") gave a 
conclusion that "if you do less than a week, you're either an idiot or you 
have special circumstances and know exactly what you're doing"......

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date:  Fri, 16 Sep 2005 14:34:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> You've removed "path-keyword" - so what you're proposing is
> different from what's specified in the current documents,
> not just a different syntax.

Actually I'm lost what the server folks here (Richard, Russ,
Forrest) really want.  Richard said what he sees in practice 
is the diag.MISMATCH-style, that's Charles's second variant
(with a similar diag.SEEN).

OTOH he said that this has no effect, and a log file makes
more sense.  For a real effect it has to be source!MISMATCH
(or similar source!SEEN) with source = path-id instead of
diag = IP (or path-id).

That's quite different,  Supporting both concepts at the
same time is something I don't understand, but I hope that
somebody will explain where that's still better than say

         path = "Path:" SP *( VCHAR ) CRLF

                        Bye, Frank

Date: Fri, 16 Sep 2005 08:26:12 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

Richard Clayton wrote:

> it looks very dangerous to me -- it will stop Path working at all for
> any system that does not unfold before consulting it
> 
> that said, all that goes wrong is that peers are offered extra articles
> which they then refuse based on the message-ID, so it's not the end of
> the world, just a small amount of extra traffic

Some (many?) peering servers keep only a limited message-ID cache, representing
several hours of message IDs, not days.  Am I mistaken?

In this case, path is not some diagnostic nor advisory like 2822 "Received."
It is the only way that traffic is manageable.

Date: Fri, 16 Sep 2005 13:44:05 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Sender: [email-masked]

--On fredag, september 16, 2005 08:19:25 +0200 Frank Ellermann 
<[email-masked]> wrote:

>  path-diag     = [ [FWS] "!POSTED" ]
>                  [ "!" /                 ; match => "!!"
>                    ( [FWS] "!"
>                      ( IPv4address       ; see [RFC 3986]
>                      / IPv6address       ; see [RFC 3986]
>                      / path-identity ) ".MISMATCH" ) ]
>
> If you prefer your "lazy IP-diagnostics" = Charles' .SEEN
> please replace the ".MISMATCH" by ( ".SEEN" / ".MISMATCH" )
> in this proposal.

You've removed "path-keyword" - so what you're proposing is different from 
what's specified in the current documents, not just a different syntax.

I'm hesitant to change what's in the documents, but I think there's still 
no implementation of these features, and getting the keywords into the 
diagnostics rather than treating them separately appeals to me.

                   Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Question: Folding and FWS in Path
Date:  Fri, 16 Sep 2005 13:13:52 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 38
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> current syntax of PATH has FWS (folding white space)
> all over the place.

Charles' versions limits it to "end of path-entry"
(= one or more identities plus optional diagnostic)

You had it before or after all "!" or "!!"

My last proposal had it before all "!" or "!!"
(because Russ doesn't like "after")

We all have the alibi-pseudo-2882-[FWS] after the
"colon plus magic SP", and another before CRLF.
The prose forbids both, should be *WSP.  <shrug>

> 1) Is there a group consensus to allow folding of Path?

Dunno.

> 2) Is there a group consensus to allow whitespace in Path?

1036 had "blank" as separator, s-o-1036 announced
that the grandson will allow FWS.  If we'd _forbid_
WSP it has to be listed as "difference from 1036".

> 3) If yes: Are these features in status "use them now",
>    or are they in status "MUST accept, SHOULD NOT generate"?

Server territory, same idea as for Control / Message-ID /
Newsgroups / Xref / Expires / Distribution / Lines.

In other words, as long as the WG has conxistent concepts
I'm confident to find ABNF reflecting whatever that is.

                           Bye, Frank

Date: Fri, 16 Sep 2005 11:47:38 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Richard Clayton <[email-masked]>
Cc: [email-masked]
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

--On fredag, september 16, 2005 09:42:40 +0100 Richard Clayton 
<[email-masked]> wrote:

> why did they get added ?

I don't know .... they were in draft-ietf-usefor-article-00, in the 
"new-path" format ("old-path" syntax also permitted spaces, but only 
spaces).
(draft fetched from 
<http://bgp.potaroo.net/ietf/all-ids/draft-ietf-usefor-article-00.txt> - 
the draft was not dated, but had an expiry date of November 1998, so we can 
assume that it was from May 1998).

Son-of-1036 (1994) said:

     NOTE: This syntax has the disadvantage of contain-
     ing  no  white space, making it impossible to con-
     tinue a Path header across several lines.   Imple-
     mentors  of relayers and reading agents are warned
     that it is intended that  the  successor  to  this
     Draft will change the definition of path delimiter
     to:

          path-delimiter = "!" [ space ]

     and are urged to  fix  their  software  to  handle
     (i.e.,  ignore) white space following the exclama-
     tion points.  They are urged to hurry;  some  ill-
     behaved  systems  reportedly  already feel free to
     add such white space.

By February 2000 (article-03), this had settled down already to the present 
quite folding-permissive format:

5.6.1.  Format

      Path-content        = *( path-identity [FWS] delimiter [FWS] )
                     tail-entry *FWS
      path-identity       = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
      delimiter           = "/" / "?" / "%" / "," / "!"
      tail-entry          = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

This is from Forrest's very useful site:
<http://mibsoftware.com/userkt/usefor/s-o-1036/Path.htm>

Date: Fri, 16 Sep 2005 09:42:40 +0100
To: Harald Tveit Alvestrand <[email-masked]>
Cc: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Question: Folding and FWS in Path
Sender: [email-masked]

In message <153526FD4DE53138862E87A0@B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <[email-masked]> writes
>Question for the WG:
>
>current syntax of PATH has FWS (folding white space) all over the place.
>
>I recall discussion of other fields where folding was strongly discouraged 
>- Newsgroups: was the important one.
>
>1) Is there a group consensus to allow folding of Path?

it looks very dangerous to me -- it will stop Path working at all for
any system that does not unfold before consulting it

that said, all that goes wrong is that peers are offered extra articles
which they then refuse based on the message-ID, so it's not the end of
the world, just a small amount of extra traffic -- recall that paths
across Usenet are often of very similar (very fast speed) so multiple
peers often offer you the same article. Path: is there for a slower
gentler Usenet where if you have an article, the chances are that none
of your peers does, but if they do have it, then it's in a long queue
heading your way and you'd do them a favour by not overloading them
further by offering it to them

of course if systems have stupidly short history files then Path: helps
considerably!  I noted the recent discussion of a week or so, and recall
that a decade ago, UUNet used to run with 90 days plus...

>2) Is there a group consensus to allow whitespace in Path?

it isn't there at the moment...  but if there's this huge encouragement
for adding diagnostics (which I suspect will be mainly ignored, the
place for a MISMATCH is in the receiving machine's syslog, not on the
propagated article) then the Path header lines are going to be rather
longer than at present...

why did they get added ?

>3) If yes: Are these features in status "use them now", or are they in 
>status "MUST accept, SHOULD NOT generate"?

If they must be there, then I think that would be best

- -- 
richard                                              Richard Clayton

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

Date: Fri, 16 Sep 2005 08:08:29 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Domain-shaped names not in the DNS (Re: #1047 and #1132 - USEPRO text for section 2.3)
Sender: [email-masked]

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

--On 15. september 2005 16:18 +0000 Charles Lindsey <[email-masked]>=20
wrote:

>> You could send him a letter in the mail, or give him a phone call.....
>> what  I thought you originally meant by "not connected to the Internet"
>> was  "machine is not connected to the Internet at the time the name has
>> to be  decided upon", but you seem to use it as "administrator has never
>> been in  touch with anyone on the Internet".
>
> You could, but there is still no sure way for a person reading the
> not-DNS-hostname to discover who owns it.

Why does he need to know?
He knows who ADMINISTERS it, and if the administrator does not know who he=20
allocated it to - that's bad for the administrator.
So if he HAS to, he has an administrative chain to chase.

(btw, that's not uncommon in connected systems either. This machine=20
currently has a perfectly unique DNS name, halvestr-w2k02.emea.cisco.com,=20
but you don't stand a snowball's chance in hell of figuring out from the=20
DNS who owns it, apart from the obvious "it seems to belong to Cisco").

> So I am still against this idea,
> and I do not hear others pushing for it. If someone does not possess a
> clearly identifiable FQDN, then let him use a <bareword>. Then everybody
> knows it is no use chasing him through the DNS.

I have heard multiple people pushing strongly against encouraging more use=20
of <bareword>. Pointing out that you can get an unique name by leveraging=20
administrative control of DNS domains would help lessen the need for=20
<bareword>.

                       Harald

--==========9FC93B9C2377A111BD4F==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========9FC93B9C2377A111BD4F==========--

Date: Fri, 16 Sep 2005 08:24:45 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Question: Folding and FWS in Path
Sender: [email-masked]

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

Question for the WG:

current syntax of PATH has FWS (folding white space) all over the place.

I recall discussion of other fields where folding was strongly discouraged=20
- Newsgroups: was the important one.

1) Is there a group consensus to allow folding of Path?
2) Is there a group consensus to allow whitespace in Path?
3) If yes: Are these features in status "use them now", or are they in=20
status "MUST accept, SHOULD NOT generate"?

                  Harald

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

--==========E69E3D3B225D82201828==========--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date:  Fri, 16 Sep 2005 08:19:25 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 42
Sender: [email-masked]

Russ Allbery wrote:

> I'll make a brief plea to disallow [FWS] after "!" rather
> than before

For my wannabe-simplified path ABNF that would result in:

 path          = "Path:" SP [FWS] path-list [FWS] CRLF
 path-list     = *( path-entry [FWS] "!" ) tail-entry
 path-entry    = path-identity [ path-diag ]

 tail-entry    = 1*( alphanum / "-" / "_" / "." )    ; TBD ?!?

 path-identity = *( path-label "." ) path-label
 path-label    = alphanum [ *( alphanum / "-" / "_" ) alphanum ]
 alphanum      = ALPHA / DIGIT

 path-diag     = [ [FWS] "!POSTED" ]
                 [ "!" /                 ; match => "!!"
                   ( [FWS] "!"
                     ( IPv4address       ; see [RFC 3986]
                     / IPv6address       ; see [RFC 3986]
                     / path-identity ) ".MISMATCH" ) ]

If you prefer your "lazy IP-diagnostics" = Charles' .SEEN
please replace the ".MISMATCH" by ( ".SEEN" / ".MISMATCH" )
in this proposal.

Open questions:  what is allowed in a <tail-entry> ?

Is Charles ready to drop the "multi-id per entry" idea in
the syntax ?  If not adding it is simple:

--- see above ---
 path-entry    = path-identity [ path-diag ]
--- multi id. ---
 path-entry    = *( path-identity [FWS] "!" ) path-identity [ path-diag ]
--- --------- ---

So that's one proposal with two optional tweaks .SEEN and / or
"multi-id", and the <tail-entry> details TBD.  Bye, Frank

Date: Thu, 15 Sep 2005 22:49:40 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Sender: [email-masked]

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

--On 15. september 2005 16:04 +0000 Charles Lindsey <[email-masked]>=20
wrote:

>>> No, there is no need for that. Every <label> has to begin with ALPHA
>>> (and that was in RFC 1035), so if you see anything with just digits and
>>> "."s in it, it is either an <IPv4address> or it is a syntax error.
>
>> Actually RFC 1035 was superceded by RFC 1123 section 2.1 which states
>> that each label except the TLD may be all-numeric.
>
> Except that I see nothing in RFC 1123 that says the TLD is to be treated
> differently.

How about this?
>
>            If a dotted-decimal number can be entered without such
>            identifying delimiters, then a full syntactic check must be
>            made, because a segment of a host domain name is now allowed
>            to begin with a digit and could legally be entirely numeric
>            (see Section 6.1.2.4).  However, a valid host name can never
>            have the dotted-decimal form #.#.#.#, since at least the
>            highest-level component label will be alphabetic.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Actually, we are somewhat at the mercy of ICANN here, but so far, I haven't =

seen even a single application for an all-numeric (or even seminumeric) =
TLD.

> There is also the interesting question whether you are allowed two "-"s
> in succession. Apparently you are, so I have incorporated that (and
> allowed it in <bareword> too for good measure).

One word: IDN.
All IDN components (in ASCII form) are prefixed with xn--.

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

--==========DAA6B8743E8101EAD2AD==========--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Path components
Date:  Fri, 16 Sep 2005 07:48:15 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 40
Sender: [email-masked]

Richard Clayton wrote:

>> <bareword> required to start with ALPHA is okay when used
>> as <path-identity>.

> It won't break anything, and it would reflect current usage,
> but I don't think "3com" will be amused though

I've removed <bareword> from my last attempt - if we really
want to allow "underscore before a last dot", then it makes
no sense to introduce FQDN vs. bareword details in the ABNF:

<bareword> degenerates into "<path-identity> without dot".

If that's all nobody cares, because it's obvious.  Add note
"you better pick a FQDN <path-identity> with a dot", ready.

 [tail-entry]
> it is probably worth wondering if the <tail-entry> actually
> serves a useful purpose of any kind ?

> Why exactly are we keeping it ?

Actually we're "introducing" it, it was optional in RfC 1036:

| Normally, the rightmost name will be the name of the
| originating system.  However, it is also permissible to
| include an extra entry on the right, which is the name of the
| sender.  This is for upward compatibility with older systems.

If we require it (like s-o-1036) it's at least clear that the
right-most entry (e.g. "not-for-mail") is _always_ irrelevant.

> So is there another reason ?

Guessing:  ordre, contreordre, desordre.  We can't forbid it.
Making it optional (again, like 1036) is worse than required ?

                           Bye, Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Organization: The Eyrie
Date: Thu, 15 Sep 2005 22:15:14 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> I covered it in my version by disallowing [FWS] before a "!" (assuming
> it would be a good practice to always split lines in a comsistent and
> standard way). But if people want to permit [FWS] either before or after
> a "!", then I am sure that a grammar can still be written that will
> prevent FWS in the middle of a "!!". Opinions on whether we want to
> allow [FWS] on either side of a "!"?

I'll make a brief plea to disallow [FWS] after "!" rather than before, if
you're introducing folding, on the same grounds that most programming
style guides recommend:

    if (a
        && b)

rather than:

    if (a &&
        b)

This message should not be taken as support for the idea of folding the
Path header in general.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date:  Fri, 16 Sep 2005 07:00:45 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 69
Sender: [email-masked]

Charles Lindsey wrote:

> Frank found a nice syntax for <hostname> in RFC 2396

Credits to Wayne Schlitt... ;-)  The prose for the LDH-rule
is in John's 3696, and of course there's a subtlety, 3696
says "at least one ALPHA in a TLD", not "start with ALPHA".

> its successor RFC 3986 has removed that, and refers you
> instead to RFC 1034 plus RFC 1123.

Maybe we need a 3696bis as a BCP, not only "informational".
The relaxed 3696 idea without optional trailing dot is:

 domain   = 1*( label "." ) toplabel     ; at least one dot
 label    = alphanum [ *( alphanum / "-" ) alphanum ]
 toplabel = [ label ] ALPHA [ label ]    ; at least one ALPHA

The stricter and simpler SPF idea copied from 2396 etc. is:

 domain   = 1*( label "." ) toplabel     ; at least one dot
 label    = alphanum [ *( alphanum / "-" ) alphanum ]
 toplabel = ALPHA    [ *( alphanum / "-" ) alphanum ]

Really sad that this detail didn't hit any "IETF last call"
after 2396, at the moment we can only hope that ICANN won't
break both.

> So it would seem that there is nowhere any standard syntax
> for what a domain name looks like, although "everybody"
> (TINE) seems to know what it is.

The (apparent) consensus here to allow "_" in addition to
"-" is already at odds with what "everybody" thinks to know.

> There is also the interesting question whether you are
> allowed two "-"s in succession.

There might be some restrictions for 2ALPHA "--" at the begin
of a label not limited to "xn--".  But I'm too lazy to check
if that's policy or standard or whatever.

> do we want to be able to distinguish <source-identity>s from
> <path-identity>s by the presence of .SEEN/.MATCH/.MISMATCH,
> or somesuch)?

IMHO a <source> is only relevant for !source.MISMATCH! cases.

For !source.MATCH! we offer !! as shorthand, IMO good enough.

Russ' concept (your source.SEEN! would be new, so far I don't
see the point.  Let's say a site got the path claimed-id!...

If site isn't "lazy" the path (modulo POSTED) would be either
site!!claimed-id!...  or  site!source.MISMATCH!claimed-id!...

IIRC Russ said that the site is "lazy", but still wants to add
some diagnostics.  If that's a <path-identity> it could simply
say site!path-id!claimed-id!...

Or even site!!path-id!claimed-id!... (is that really okay ?)

We're only in trouble (syntactically) if a "lazy" site insists
on adding an IP:  site!ip-address!claimed-id!...  would be a
red duck styling itself as green grouse, only in that case a
site!ip-address.SEEN!claimed-id!...  is better (or necessary)

                     Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Simplified path ABNF / tail-entry trouble #1132 (was: #1132: Allowing IP addresses as path-identiites - Poll result)
Date:  Fri, 16 Sep 2005 05:44:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 47
Sender: [email-masked]

Charles Lindsey wrote:

> I covered it in my version by disallowing [FWS] before a "!"

Cute, it also simplifies my "either !! or diag!MISMATCH!" idea.

BTW, Richard reports that in reality "diag!MISMATCH!" uses the
format "diag.MISMATCH" (as in your second version).  Time for
a new attempt to put it all together.  Goals:

1 - either !! [FWS] or ! [FWS]
2 - allow "_" in labels or bareword
3 - pseudo-TLD MISMATCH allows to identify "diag.MISMATCH!"
4 - IPs only in <diag> => <toplabel> details irrelevant
5 - colon only for IPv6 in "<diag>.MISMATCH!", duck or grouse
6 - <tail-entry> may start with DIGIT, anything (?) goes that
    is NOT 1036-punctuation (incl. ":") or WSP or CTL

Talking about "anything goes" in <tail-entry>, what precisely
is this ?  What about "$", "+", "#", "%", "@" ?   Whatever we
say, this is a major difference from 1036, we have to mention
it in the "differences from 1036" appendix.

 path          = "Path:" SP [FWS] path-list [FWS] CRLF
 path-list     = *( path-entry "!" {FWS] ) tail-entry
 path-entry    = path-identity [ path-diag ]

 tail-entry    = 1*( aplphanum / "-" / "_" / "." )    ; TBD ?!?

 path-identity = *( path-label "." ) path-label
 path-label    = alphanum [ *( alphanum / "-" / "_" ) alphanum ]
 alphanum      = ALPHA / DIGIT 

 path-diag     = [ "!" [FWS] "POSTED" ]
                 [ "!" 
                   [ [FWS] ( IPv4address       ; see [RFC 3986]
                           / IPv6address       ; see [RFC 3986]
                           / path-identity ) ".MISMATCH" ] ]

If we prefer a variant with "!" [FWS] "MISMATCH" it's obvious
where to change this proposal.  

It does NOT support Russ' idea "add <diag> without checking,
and therefore also without a MISMATCH".

                           Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:22561
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Thu, 15 Sep 2005 16:13:28 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> my syntax severely limited where [FWS] was allowed
>> (essentially between things added by one site). If you
>> want to relax that, then I shall have to take care it
>> does not arise inside a "!!".

>I've no problem with "!" [FWS] "!" if that allows for a
>syntax where we get this concept:

No, I would not like that. These Path headers, as folded, are going to be
read by humans. If they see a single "!" at the end of a line, or at the
start of a following line, then they will be happy and think they
understand it (not noticing that a line ending with "!" was immediately
followed by another line beginning with "!"). If we are going to use the
"!!" notation, then it needs to stick out like a sore thumb, so that
everybody reading the header will easily spot it.

I covered it in my version by disallowing [FWS] before a "!" (assuming it
would be a good practice to always split lines in a comsistent and
standard way). But if people want to permit [FWS] either before or after a
"!", then I am sure that a grammar can still be written that will prevent
FWS in the middle of a "!!". Opinions on whether we want to allow [FWS] on
either side of a "!"?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22562
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 and #1132 - USEPRO text for section 2.3
Date: Thu, 15 Sep 2005 16:18:10 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>--On onsdag, september 14, 2005 14:16:36 +0000 Charles Lindsey 
><[email-masked]> wrote:

>> I don't see that. If you are totally separated from the internet, then
>> you are not in a position to negotiate with the administrator of
>> "example.org".

>You could send him a letter in the mail, or give him a phone call..... what 
>I thought you originally meant by "not connected to the Internet" was 
>"machine is not connected to the Internet at the time the name has to be 
>decided upon", but you seem to use it as "administrator has never been in 
>touch with anyone on the Internet".

You could, but there is still no sure way for a person reading the
not-DNS-hostname to discover who owns it. So I am still against this idea,
and I do not hear others pushing for it. If someone does not possess a
clearly identifiable FQDN, then let him use a <bareword>. Then everybody
knows it is no use chasing him through the DNS.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Thu, 15 Sep 2005 19:31:10 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Path components (was: ADMIN: Final warning to John Stanley)
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>
>In <[email-masked]> Richard Clayton <[email-masked]> 
>writes:
>
>>and add to these the following path identities from machines (actually I
>>think most of these will be usernames, which the POSTED requirement
>>would hide away) which only passed articles _to_ the peering core (ie
>>never receiving articles from the core and passing them on)
>
>If you are saying that many of these were <tail-entry>s, then they can do
>no harm, because relayers are supposed to ignore the <tail-entry> (i.e.
>you can happily use "dead" or "beef" as your <tail-entry>).
>
>Does your data enable you to distinguish and remove such <tail-entry>s
>from your list? 

I have the raw data still and could remove the last entry in the Path:
but in the real world there tend to be several entries at the end of the
path which serve a similar purpose (purporting to identify the poster)
and there is no algorithmic method of distinguishing them

ie: the results would not be much more illuminating

>If not, you have still shown that the problem is hardly
>significant.

the whole thrust of all of my data is that there is no problem. The
chair seems to be trying to move on re dead:beef & I'm backing that

However, having thought about the issues a little more, my current
challenges are for someone to explain what purpose the <tail-entry>
serves in the revamped Path: header field, and secondly to explain a
scenario when a diagnostic such as MISMATCH could ever be attached to
anything other than an IP address.

These seem to still be relevant open issues (but if the chair feels
otherwise I'll be quiet since it isn't going to break anything I care
about)

- -- 
richard                                              Richard Clayton

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

To: [email-masked]
Xref: clerew local.usefor:22558
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Thu, 15 Sep 2005 16:04:43 GMT
Lines: 97
Sender: [email-masked]

In <[email-masked]> Bill McQuillan <[email-masked]> writes:

>On Wed, 2005-09-14, Charles Lindsey wrote:

>> No, there is no need for that. Every <label> has to begin with ALPHA (and
>> that was in RFC 1035), so if you see anything with just digits and "."s
>> in it, it is either an <IPv4address> or it is a syntax error.

>Actually RFC 1035 was superceded by RFC 1123 section 2.1 which states that
>each label except the TLD may be all-numeric.

Except that I see nothing in RFC 1123 that says the TLD is to be treated
differently. Frank found a nice syntax for <hostname> in RFC 2396, but its
successor RFC 3986 has removed that, and refers you instead to RFC 1034
plus RFC 1123. So it would seem that there is nowhere any standard syntax
for what a domain name looks like, although "everybody" (TINE) seems to
know what it is.

There is also the interesting question whether you are allowed two "-"s
in succession. Apparently you are, so I have incorporated that (and
allowed it in <bareword> too for good measure).

So here now are the two versions of my syntax, incporporating various
changes from recent discussions. There are still possibilities to simplify
them in the direction of Frank's version, or even Harald's. However, life
would be simpler if we could have some views on which of my two
alternatives we want to use for further progress (i.e. do we want to be
able to distinguish <source-identity>s from <path-identity>s by the
presence of .SEEN/.MATCH/.MISMATCH, or somesuch)?

[1st version of syntax, following the usage of POSTED and
MISMATCH in the present USEFOR.]

   path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF

   path-entry = path-identity *( "!" path-identity ) [ "!" "POSTED" ]
                  [ "!" [ source-identity [ "!" "MISMATCH" ] ] ]

   path-identity = fqdn / bareword

   fqdn = 1*( label "." ) toplabel

   label = alphanum / alphanum *( alphanum / "-" ) alphanum

   toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

   alphanum = ALPHA / DIGIT

   bareword = ALPHA / ALPHA *( alphanum / [ "-" / "_" ] ) alphanum )

   tail-entry = fqdn / bareword

   source-identity = fqdn / IP-address / bareword

   IP-address = IPv4address / IPv6address ;  see [RFC 3986]

[2nd version of syntax, making <source-identity>s readily
distinguishable from <path-identity>s.]

   path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF

   path-entry = path-identity *( "!" path-identity )[ "!" "POSTED" ]
                   [ "!" [ path-source ] ]

   path-identity = fqdn / bareword

   fqdn = 1*( label "." ) toplabel

   label = alphanum / alphanum *( alphanum / "-" ) alphanum

   toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

   alphanum = ALPHA / DIGIT

   bareword = ALPHA / ALPHA *( alphanum / [ "-" / "_" ] ) alphanum )

   tail-entry = fqdn / bareword

   path-source = source-identity ( ".SEEN" / ".MATCH" / ".MISMATCH" )

   source-identity = fqdn / IP-address / bareword

   IP-address = IPv4address / IPv6address ;  see [RFC 3986]
 
-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22557
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Path components (was: ADMIN: Final warning to John Stanley)
Date: Thu, 15 Sep 2005 15:32:33 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>and add to these the following path identities from machines (actually I
>think most of these will be usernames, which the POSTED requirement
>would hide away) which only passed articles _to_ the peering core (ie
>never receiving articles from the core and passing them on)

If you are saying that many of these were <tail-entry>s, then they can do
no harm, because relayers are supposed to ignore the <tail-entry> (i.e.
you can happily use "dead" or "beef" as your <tail-entry>).

Does your data enable you to distinguish and remove such <tail-entry>s
from your list? If not, you have still shown that the problem is hardly
significant.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Thu, 15 Sep 2005 11:13:07 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: IPv6 in paths (was: ADMIN: Final warning to John Stanley)
Sender: [email-masked]

In message <[email-masked]>, Richard Clayton
<[email-masked]> writes
>
>In message <[email-masked]>, John
>Stanley <[email-masked]> writes
>
>>>Yes, but I believe that using a non-standard notation for IPv6 addresses
>>>is a worse evil than putting up with the minor inconvenience of the
>>>dead:beef problem (which is most unlikely to arise in practice, and is
>>>easily worked around by any sysadmin who gets caught by it).
>> 
>>It is not "evil" to use a simple notation. It thus is not a "worse evil".
>>It is something that admins won't notice in most cases, since they won't
>>be entering the information, it will be entered by the software
>>automatically, IF it even applies to their site. (The vast majority of
>>admins will never deal with it AT ALL.) And "easily worked around"  
>>requires renaming one's site, after noticing that there is a problem. A
>>problem which may have flooded your communications line already. 
>
>I don't follow that
>
>If your site is called "beef" and someone puts an IPv6 address into the
>Path header field with a :beef: component then until you notice, you
>will get less traffic rather than more (assuming all of your peers are
>treating ":" as a delimiter).  How does a flood occur ?

John replied to my question, but since we won't see that answer for two
weeks I shall paraphrase it here by replying to myself (sorry!).

His scenario was that a site had decided to use an IPv6 address as its
identity and was unlucky enough to be have components of that IP address
which were, for example, :dead:beef:

Now if that site's peers parse this as the two barewords "dead" and
"beef" then they won't realise that an article has already passed
through the site and so they will send it there again. John thinks that
this will "flood" the comms link.

However, I don't think that's quite true, since in practice (AIUI) the
site will be offered the article (IHAVE, CHECK etc) and will refuse it
based on the message-ID. So there will be extra traffic, but not all
that much (and given the wide range of similar speed paths through the
Internet it should be quite used to having multiple peers all offering
it the same article)

If the traffic _was_ a problem then the fix would be to not use the IPv6
address as an entity (we don't encourage that anyway) or to negotiate
with all its direct peers (the only people who matter for this second
scenario) to arrange that they don't treat ":" as a delimiter.

Going back to the first scenario (where peers don't hand over articles
that have passed through a site with an IPv6 :dead:beef: type of
identity) then the best fix (since presumably they have good reasons for
wishing to still be called "beef") is once again to negotiate with peers
to ask them to fix their view of delimiters. Note that in this case the
flood-fill nature of propagation means that _only_one_peer_ has to fix
their software.  

John pointed out (in the message we haven't seen on the list) that
detecting missing articles wasn't trivial -- and that, in my view, is a
valid point to make; newsadmins aren't going to spending their days
checking for completeness, a problem may go overlooked for months.

However, since at present no-one is called "beef" (or similar); since
flood-fill is a very robust distribution system; and since we indicate
that this is essentially a legacy form of recording identity, this is
all pretty moot.

Bottom line for me is that though this is a theoretical problem, it is
not now, or will ever be a practical one.

- -- 
richard                                              Richard Clayton

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

Date: Thu, 15 Sep 2005 10:33:40 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Path components
Sender: [email-masked]

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>
>Richard Clayton wrote:
>
>>         VISP, apex, esel, frgp, jpix,
>>         ktts, ornl, rice, spin, srcc,
>>         sws1, tino, torn
>[...]
>
>Thanks for info, it's always good to spice theoretical
>debates with a bit of reality.... :-)  Do you also have
>some statistics about "<bareword> starts with a DIGIT" ?

there are some domains starting with a digit, 4ax.com should be a clear
enough example of this to indicate the scale of that issue :)

as to bareword, there's 188 of these, ranging from "1", through "42" and
"666" to a whole lot which are clearly hex representations of IP
addresses, eg "40344AD0". In one case there is what may be a phone
number, "208-59-181-145". In all of these cases, the entity is outside
of the peering core, so I'd strongly suspect that these are all
identifications of posting agents and not of peering agents...

>Based on your four-letter-<bareword>s it's apparently no
>issue, <bareword> required to start with ALPHA is okay
>when used as <path-identity>.

It won't break anything, and it would reflect current usage, but I don't
think "3com" will be amused though

>But not for <tail-entry>.  All proposals to use exactly
>the same syntax in <tail-entry> did not pass this quick
>reality check.  "We" were stupid, of course <tail-entry>
>should be the same as <id-local> / <id-left> minus what
>RfC 1036 considered as "punctuation".

I think it is pretty clear that <tail-entry> is currently free-form.

This isn't surprising, it started as an email address, morphed into a
tracing mechanism and has long been superseded in both roles by other
header fields....

... SO.... if one is redesigning the Path: header field to contain all
of these "!!" and MISMATCH values then it is probably worth wondering if
the <tail-entry> actually serves a useful purpose of any kind ?

Why exactly are we keeping it ?

The answer might be to avoid discarding too much when an article is re-
injected by the clueless, but this is rare and quite frankly I suspect
that the article-ID is quite sufficient. So is there another reason ?

BTW: I note that almost every instance of MISMATCH in my dataset is
attached to an IPv4 address ("130.133.1.3.MISMATCH"), there are a
handful of exceptions ("newsfeed2.easynews.com.MISMATCH") almost all
involving major sites (ie that might most easily be persuaded to change
their behaviour) and one IPv6 ("2001:770:10:300::86e2:510d.MISMATCH").

If one considers how a mismatch is detected, and what can actually be
usefully recorded, I think one can see why an IP address is almost
inevitable (and I suspect that the ones involving names are using subtly
different semantics ("it was supposed to be news.example.com and it
wasn't" as opposed to "this is where is came from")

- -- 
richard                                              Richard Clayton

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date:  Thu, 15 Sep 2005 03:20:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 78
Sender: [email-masked]

Charles Lindsey wrote:

> Every <label> has to begin with ALPHA

That's unfortunately not more the case for the ldh-rule,
it's only the toplabel (compare RfC 2396 and others).

If you and Harald want to "allow" underscore you cannot
exclude "non-toplabel starting with DIGIT" at the same
time, that would be inconsistent.

>> say tail-entry = path-identity
> No

ACK, here I dropped the "starts with DIGIT" ball.

 [about no bareword> in <source-identity>]
> No, you still need <bareword> as a possibility for
> <source-identity>, because the article may have arrived
> by UUCP, or it may have arrived from an uninteresting IP
> address leased to a dialup, and what you want to quote
> is the "true source of the article" which you only knew
> because the sending site authenticted itself with SASL,
> using some <bareword> as its identity.

Sigh...  okay, IIRC Harald's proposal also covered that
idea, so "diag" or "source" can be an IP or just anything
also allowed as <path-identity>.

> I think we have to accept that this grammar is always going
> to be ambiguous (but mostly it doesn't matter). Harald's
> grammar is even more ambiguous.

Your second version (pseudo-TLD ".MISMATCH") had that clear.
It's possible to preserve this idea for "!MISMATCH" if we
restrict "diag" to "diag!MISMATCH".

Otherwise it's hard to see the point of "diag":  If nobody
but the site adding it knows what it is it's that red and
green sparkled duck feeding itself with dead:beef...

...at least we asked it to stay out of Injection-Info and
Xref, is that really all, syntactically ?

> my syntax severely limited where [FWS] was allowed
> (essentially between things added by one site). If you
> want to relax that, then I shall have to take care it
> does not arise inside a "!!".

I've no problem with "!" [FWS] "!" if that allows for a
syntax where we get this concept:

- either an (old) site doesn't care, then it shouldn't
  mess with "POSTED" / MISMATCH / "!!" / "diag" / "source"

- or it cares, then the two main cases (excl. POSTED) are
  "diag!MISMATCH!" or "!" (= match).

I consider the left of two adjacent "!" as shorthand for
"source!MATCH!" in a Path: site!source!MATCH!source!...

Not because I like potential cases of "!" FWS "!", but
as concept _IFF_ we want to restrict "diag" to "MISMATCH":

 path-diag = [ path-sep "POSTED" ]
             [ ( path-sep ( IP-address / path-identity )
                  path-sep "MISMATCH" ) / ( [FWS] "!" ) ]
                                          ^^^^^^^^^^^^^

The part ( [FWS] "!" ) is that match-shorthand.  For a
syntax with those read and green sparkled ducks it's of
course a bad idea to allow [FWS] "within" the "!!" case.

At least Harald's version allowed ...!!MISMATCH... or
...MISMATCH!!...  I hoped to remove this oddity somehow.

                    Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2822bis
Date:  Thu, 15 Sep 2005 02:24:46 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

Charles Lindsey wrote:
 
> What you actually meant was the mailing list
> "[email-masked]".

The truth is that I've not yet checked why on earth a
List-Id: <ietf-smtp.imc.org> is allowed, it appears to
be a stupid idea - OTOH we're about to specify similar
dubious constructs... ;-)
                              Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Path components
Date:  Thu, 15 Sep 2005 02:08:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Richard Clayton wrote:

>         VISP, apex, esel, frgp, jpix,
>         ktts, ornl, rice, spin, srcc,
>         sws1, tino, torn
[...]

Thanks for info, it's always good to spice theoretical
debates with a bit of reality.... :-)  Do you also have
some statistics about "<bareword> starts with a DIGIT" ?

Based on your four-letter-<bareword>s it's apparently no
issue, <bareword> required to start with ALPHA is okay
when used as <path-identity>.

But not for <tail-entry>.  All proposals to use exactly
the same syntax in <tail-entry> did not pass this quick
reality check.  "We" were stupid, of course <tail-entry>
should be the same as <id-local> / <id-left> minus what
RfC 1036 considered as "punctuation".

                        Bye, Frank

Date: Wed, 14 Sep 2005 16:45:15 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: ADMIN:
Sender: [email-masked]

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>If your site is called "beef" and someone puts an IPv6 address into the
>Path header field with a :beef: component then until you notice, you
>will get less traffic rather than more 

And if your site is named "ded:beef", then everything you pass on to your 
peer will be reflected back to you, because you are neither "ded" nor 
"beef", which are the two components your peer will be breaking your legal
path-identity into.

But yes, the more likely problem will be missing traffic. Missing traffic
is an even harder problem to detect than an overflow of traffic, so saying
the problem isn't bad because the admin will detect it and solve it is
naive, at best. And in this version of the problem, it isn't even the 
admin of the site that can fix it, his peers will have to.

It is just so much simpler to solve the problem ... oh, my, there we go
again. 

Date: Thu, 15 Sep 2005 01:20:25 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

--On onsdag, september 14, 2005 11:19:39 -0700 John Stanley 
<[email-masked]> wrote:

> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> NOTE: I don't have much hope of John's behaviour to change based on this
>> note.
>
> Of course not. My "behaviour" isn't out of the norm for this group. My
> behaviour doesn't seem out of line with your own.

I think the point I was trying to make has been amply demonstrated.

You will be welcome to post to the list again in two weeks, on September 29.

Until then, your posting rights have been removed.

                       Harald

Date: Wed, 14 Sep 2005 23:38:07 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Sender: [email-masked]

--On onsdag, september 14, 2005 12:00:53 +0000 Charles Lindsey 
<[email-masked]> wrote:

>> With that version of <label> there's still an unnecessary
>> ambiguity with <IPv4address>, it can be solved by <toplabel>:
>
> No, there is no need for that. Every <label> has to begin with ALPHA (and
> that was in RFC 1035), so if you see anything with just digits and "."s
> in it, it is either an <IPv4address> or it is a syntax error.

3com killed that piece of RFC 1035 many years ago.
These days, 121.net is a valid domain (belonging to a Hong Kong company).

Sorry, reality intruded.

Date: Wed, 14 Sep 2005 23:36:02 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1047 and #1132 - USEPRO text for section 2.3
Sender: [email-masked]

--On onsdag, september 14, 2005 14:16:36 +0000 Charles Lindsey 
<[email-masked]> wrote:

>> I also deleted the (not connected to the Internet) parenthesis in 3,
>> since  with the addition of option 2, that's not a valid excuse to not
>> have a  domain name.
>
> I don't see that. If you are totally separated from the internet, then
> you are not in a position to negotiate with the administrator of
> "example.org".

You could send him a letter in the mail, or give him a phone call..... what 
I thought you originally meant by "not connected to the Internet" was 
"machine is not connected to the Internet at the time the name has to be 
decided upon", but you seem to use it as "administrator has never been in 
touch with anyone on the Internet".

                  Harald

Date: Wed, 14 Sep 2005 14:36:05 -0700
From: Bill McQuillan <[email-masked]>
To: Usenet <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Sender: [email-masked]

On Wed, 2005-09-14, Charles Lindsey wrote:

>>With that version of <label> there's still an unnecessary
>>ambiguity with <IPv4address>, it can be solved by <toplabel>:

> No, there is no need for that. Every <label> has to begin with ALPHA (and
> that was in RFC 1035), so if you see anything with just digits and "."s
> in it, it is either an <IPv4address> or it is a syntax error.

Actually RFC 1035 was superceded by RFC 1123 section 2.1 which states that
each label except the TLD may be all-numeric.

-- 
Bill McQuillan <[email-masked]>

Date: Wed, 14 Sep 2005 22:31:12 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

In message <[email-masked]>, John
Stanley <[email-masked]> writes

>>Yes, but I believe that using a non-standard notation for IPv6 addresses
>>is a worse evil than putting up with the minor inconvenience of the
>>dead:beef problem (which is most unlikely to arise in practice, and is
>>easily worked around by any sysadmin who gets caught by it).
> 
>It is not "evil" to use a simple notation. It thus is not a "worse evil".
>It is something that admins won't notice in most cases, since they won't
>be entering the information, it will be entered by the software
>automatically, IF it even applies to their site. (The vast majority of
>admins will never deal with it AT ALL.) And "easily worked around"  
>requires renaming one's site, after noticing that there is a problem. A
>problem which may have flooded your communications line already. 

I don't follow that

If your site is called "beef" and someone puts an IPv6 address into the
Path header field with a :beef: component then until you notice, you
will get less traffic rather than more (assuming all of your peers are
treating ":" as a delimiter).  How does a flood occur ?

- -- 
richard                                              Richard Clayton

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

Date: Wed, 14 Sep 2005 16:46:19 -0400
From: Dan Schlitt <[email-masked]>
cc: [email-masked]
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

Over more years of observation of this working group than I care to
count I have come to a conclusion about a feature of it. Considering the
subject of the working group it probably could have been expected.

Some participants, past and present, treat the mailinglist as if it were
some usenet newsgroup. Discussions go on until those participating in
the discussion get tired and then they go on to some other topic, often
a recycled version of a previous endless discussion.

A working group mailing list is not a newsgroup. It has a task and the
intention to finish that task. Discussions need to lead to conclusions.
Perfection is not a goal; a working solution is the goal. Contributioins
to the mailinglist which do not move the group closer to the goal are
not all that helpful.

This working group has gone on far too long. It needs to conclude one
way or another. The chairs are trying hard to have a conclusion that
results in some RFCs. That is not the only conclusion to the working
group that is possible.

I would like to see the documents advance because a standard that
defines more or less current practice would be a "good thing." Not a
perfect standard but one that is "good enough."

/dan

-- 

Dan Schlitt
[email-masked]

Date: Wed, 14 Sep 2005 11:33:45 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>_You_ know that the proposed syntax is a nonsense, and _I_ know that the
>proposed syntax is a nonsense. But the WG has voted against us.

The only "vote" I know of regarding this was one that asked:

YES - IP addresses should be allowed as path-identity.
NO - IP addresses should not be allowed as path-identity.

I've seen no vote on the syntax you produced. Is the archive incomplete?
Did we actually vote to approve ambiguous syntax for poorly defined header 
contents? I mean, did we actually vote to approve THIS specific ...

>Yes, but I believe that using a non-standard notation for IPv6 addresses
>is a worse evil than putting up with the minor inconvenience of the
>dead:beef problem (which is most unlikely to arise in practice, and is
>easily worked around by any sysadmin who gets caught by it).
 
It is not "evil" to use a simple notation. It thus is not a "worse evil".
It is something that admins won't notice in most cases, since they won't
be entering the information, it will be entered by the software
automatically, IF it even applies to their site. (The vast majority of
admins will never deal with it AT ALL.) And "easily worked around"  
requires renaming one's site, after noticing that there is a problem. A
problem which may have flooded your communications line already. 

What is evil is to deliberately write a known interoperability issue into 
the standard when the solution is trivial. Our first goal used to be 
interoperability, and the first goal of Path used to be to prevent loops. 
This abandons both.

I'm sorry, but if I didn't respond to your objection again, the Chair 
would use it as an example of non-constructive "failure to respond".

Date: Wed, 14 Sep 2005 11:19:39 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>NOTE: I don't have much hope of John's behaviour to change based on this 
>note.

Of course not. My "behaviour" isn't out of the norm for this group. My 
behaviour doesn't seem out of line with your own.

>Unlike John, I will reply to the administrative portion, dealing with 
>behaviour, separately from the technical portion, dealing with the actual 
>proposal and objections to it.

I see no separate message dealing with the technical issues. Unlike the 
Chair, I will deal with the technical issues. And if you object to that 
phrasing, sir, then I'll point you to the previous paragraph containing 
similar language from your own keyboard.

>You have proposed this solution. I, and others, have observed that the 
>same debate on how to format an IPv6 address has been had in multiple 
>other fora, including in URIs, and the conclusion has always been to stick 
>with standard notation.

This is not "multiple other fora", this is USEFOR, and we have a known 
incompatibility issue with using colon-oriented notation for IPv6. You 
have admitted in your own words that there is an interoperability problem 
caused by this. I don't care what problems email or mime or html does NOT 
have with IPv6 encodings, I'm here to talk about USENET and the problems 
it has with this encoding. In this group.

I'm certain there have been long discussions about message ids in multiple 
other fora, as well. I do not see you chiding those here for not 
responding in other fora when we debated the specifics of news message id 
problems here. 

> You have not replied to this.

Of course I have not replied to debates in multiple other fora, since I do 
not participate in those fora nor am I particularly interested in those 
fora. I have no idea why you think I ought to have replied to debates in 
other fora or why it matters here. 

>The group has discussed the size of the problem (dead:beef:cafe) caused by 
>using standard IPv6 notation, and my reading of the consensus (without an 
>explicit poll for it) is that the group does not regard the problem as a 
>big enough problem to worry about.

You have called it an interoperability issue. That makes it a problem
worth worrying about. Since the solution is trivial, there is no reason
not to implement it. It is ridiculous to write a standard that says 
"here's how to do this and we know it causes interoperability issues, but 
we don't care enough to solve it, even though we could."

>You have not replied to this by anything I can see but "I disagree", and 
>formulations that I interpret as "it's obvious that I'm right".

You are wrong. I've dealt with the objections as they were raised, more 
than once. How you misinterpret things is your issue, not mine.

> Yes. And that choice is a given that we base the next steps on.

No, sir, choices are NOT givens. It is simply insulting to the 
participants of a discussion to come here and say that the result of the 
discussion is a given. "Givens" are the starting points for discussion; 
they are the things that are so obvious that they are assumed to be 
true or are so basic that you have to assume them to be true to 
begin. Allowing IP literals in a path-identity is neither. There are 
technical arguments for both sides.

You are telling the opponents that their opinion is so patently wrong that
it wasn't worth debating. The result is a "given". That's insulting, but I
don't expect you'll censure yourself for doing it.

>You've made proposals. You've had objections raised to them. You've not 
>responded, 

You are wrong. I've dealt with the objections as they were raised, and 
then again to summarize how they were dealt with.

> But your failure to respond to criticism, 

As the Chair of this group, I expect you to have read the discussions 
prior to making statements of this kind. I certainly expect you to read 
any message which you respond to. For example, from this very message:

>Yes, we CAN define how an IPv6 address is encoded into a Path header. It 
>is within our jurisdiction. No, this is NOT something that thousands of 
>admins around the planet will have to enter by hand every day, it's 
>entered automatically by software that can easily produce the required 
>output. When it appears as a diagnostic thingy, it will be SOFTWARE that 
>enters it there, not a human, and SOFTWARE can easily convert an IPv6 
>address into 32 hexadecimal characters. 

That is a DIRECT response to the objections that were raised. First 
that we have to do it the way some other RFC says, and second, that it 
would be a burden to make thousands of admins around the net type in 
unencoded IPv6 literals. This is not the first time I've said this.
In fact, the first two sentences are a pre-emptive response to your
"multiple other fora have decided..." objection. 

Do you have examples of other objections that were raised but not 
answered? If you are going to make the claim, and use it to justify a 
censure, you better have documentary proof. Well, sorry, I expect you to 
have proof, but this is USEFOR after all...

Since you ignored it the first time around, here are just some of the 
responses you claim do not exist:

On August 23:

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

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

Objection: we won't be 'thanked' for not using the 'standard'. Response:

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

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

On July 6:

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>I don't think the world out there is going to accept any encoding of IPv6
>addresses other than the one currently in widespread use (as defined in
>RFC 3986 as well as lots of other places).

Objection: "they won't accept". Response:

]Of course they will "accept it". Why wouldn't they? It's not like they 
]have to type the thing in every time they post an article.

Do we write standards hoping they will be accepted, or expecting them to 
be? What 'acceptance' does a news admin have to exhibit if it is his 
software that is doing something for him? And since "the world" isn't 
involved in this to start with, the objection is moot. Things I've said 
before.

On July 8:

Bruce Lilly <blilly@xxxxxxxxx>:

>That seems OK; I'm wary of "elide all colons" because dead::beef:cafe
>and dead:beef::cafe mean different things in IPv6-ese.

Objection: just eliding colons won't work. ("Just eliding colons" isn't 
the proposal.) Response:

]You cannot "elide all colons" until after you have undone the "double 
]colon abbreviation" step for IPv6, because, as you point out, the double 
]colons means something different than the single colon.

]And once you have elided them, there is no reason to put something else in 
]their place. Simply remove the colons. Problem solved. There are no 32 
]character UUCP names to conflict with.

And now, as for this being a problem not worth solving, I'll quote you,
on Jun 24.

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>I think my point was that given that the colons in IPv6 literals are known 
>to cause problems, and so far, no prohibition or warning is in the text, 
>the standards writers (that's us) haven't exhibited good judgment.....

Warning people that we have left them an interoperability issue they can 
be bitten by is failure to exhibit good judgement on our part.

To: [email-masked]
Xref: clerew local.usefor:22533
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: New reference for 3.1.3 (?)
Date: Wed, 14 Sep 2005 12:56:39 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Its "security considerations" suggest that some form
>of a "canonicalization" is fine - but our "pick what
>you like and then pray stick to it" is of course not
>what this text proposes.

Well the present USEFOR contains:

   o  even though commonly derived from <domain>s, <id-rights>s are
      case-sensitive (and thus, once created, are not to be altered
      during subsequent transmission or copying)

which makes our point pretty clear. The most one might add would be:

....from <domain>s (which are case-insensitive according to
[draft-ietf-dnsext-insensitive-06]), <id-rights>s are ...

But actually, <domain> is an RFC 2822 syntax rule, so it really derives
its case-insensitivity from there. I would be inclined to leave it be.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22534
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 and #1132 - ABNF for USEFOR 3.1.6
Date: Wed, 14 Sep 2005 13:46:06 GMT
Lines: 105
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles versions have it clear that there are one or more
>path-identities optionally followed by one "diagnostic"
>per site (= <path-entry> in his proposals).

The essential difference is that my grammar indicated what you should
generate (and gives a strong clue to what USEPRO will tell you when it
comes to creating a Path) and Harald's indicates more what should be
accepted. If we adopt the Harald style, then there will be somewhat more
to say in USEPRO.

However, I think Harald's present version is still too ambiguous. If we
are going to distinguish between <path-identity>s and <source-identity>s,
all built out of an assortment of barewords, FQDNs and IP-Addresses, then
the syntax should reflect this more. Hence I would support Frank's style
below if we are not going for my fuller version.

>Your version skips this detail, in theory it allows adjacent
><path-diagnostic>s or <path-keyword>s like...

>With that simplification here's another version, a wild
>mixture of your proposal and Charles' first version:

I have quoted this using Frank's correction in his second message.

> path          = "Path:" SP [FWS] path-list [FWS] CRLF
> path-list     = *( path-entry path-sep ) tail-entry
> path-entry    = path-identity [ path-diag ]

> tail-entry    = path-identity  ; typically "not-for-mail"

See my previous message for why that is wrong

> path-identity = ( 1*( label "." ) toplabel ) / bareword
> bareword      = ALPHA *( [ "-" / "_" ] alphanum )
> label         = alphanum [ *( alphanum / "-" ) alphanum ]
> toplabel      = ALPHA    [ *( alphanum / "-" ) alphanum ]
> alphanum      = ALPHA / DIGIT

And see my previous message for why that is wrong. Essentially,
"123.123.123.foo" is neither an FQDN nor an IP-Address, so no need to
allow it. I suggest:

   path-identity = fqdn / bareword
   fqdn = 1*( label "." ) label
   label = ALPHA *( [ "-" / "." ] (ALPHA / DIGIT) )

>   path-diag     = [ path-sep "POSTED" ]
>                   [ ( path-sep ( IP-address / path-identity )
>                       path-sep "MISMATCH" ) / ( [FWS] "!" ) ]

> IP-address    = IPv4address / IPv6address  ; see [RFC 3986]
> path-sep      = [FWS] "!" [FWS]

But now you have allowed "!FWS!" for "!!", and I don't think we want that.
I avoided that by only allowing [FWS] _after! a "!", not before it. But
other fixes are doubtless possible.

>Showing the <source-identity> in the case of a match strikes
>me as nonsense, and a !MISMATHCH! without <source-identity>
>is also dubious, here's a cleaner solution:

Unfortunately, showing the <source-identity> in the case of a match is a
widespread current practice. So I think we have to allow it (maybe with
keywords SEEN/MATCH). But I would be quite happy to explain, in USEPRO,
why it was a bad idea.

>P.S.:  <bareword> must start with ALPHA, is that as we want
>       it, or is <alphanum> good enough ?

I think both <bareword> and <Label> (hence <fqdn>s) need to start with an
ALPHA. That way, you can always distinguish what you have got, and the
only remaining ambiguity in the grammar is whether what you are looking at
is a <path-identity> or a <source-identity>.

>That's in the direction of Charles' first variant.  The
>concept of "one or more identity per site" in Charles'
>versions isn't critical:

Now my second variant seeks to make it syntactically clear whether you see
a <path-identity> or a <source-identity>. That is an orthogonal issue to
whether the syntax is written in Charles/Harald/Frank style, and we need
to discuss it on its merits.

It arose from a suggestion by Russ, which I worked up into a concrete
syntax (it was discussed some weeks back with some support) and it was
reinforced by a request from Forrest last week. Naturally, the precise
syntax, and whether you need all of "SEEN", "MATCH" and "MISMATCH" can be
discussed. But it would simplify the present discussions if we could
decide pretty soon whether we want to follow that route.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22531
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Wed, 14 Sep 2005 12:00:53 GMT
Lines: 103
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>>    path-identity = dot-atom-text / bareword

>Hi, you can't say <dot-atom-text> here, it contains some
>characters we don't like (delimiters for 1036 incl. "!"):

Yes, you are correct. I was following the over-liberal RFC 2822, rather
than the down-to-earth RFC 2821. And even RFC 2821 allows things that RFC
1035 doesn't, such as subdomains starting with a digit.														

>Let's stick to some kind of <ldh-string>.

>Yes.  For a "bare" version of <ldh-string> you'd get...

>     ldh-fqdn = ALPHA *( [ "-" / "." ] (ALPHA / DIGIT) )

OK, I have now s/dot-atom-text/fqdn/ everywhere, and I have

   fqdn = 1*( label "." ) label 
   label = ALPHA *( [ "-" / "." ] (ALPHA / DIGIT) ) 

>With that version of <label> there's still an unnecessary
>ambiguity with <IPv4address>, it can be solved by <toplabel>:

No, there is no need for that. Every <label> has to begin with ALPHA (and
that was in RFC 1035), so if you see anything with just digits and "."s
in it, it is either an <IPv4address> or it is a syntax error.

>>    tail-entry = dot-atom-text / bareword

>No <dot-atom-text>, just say tail-entry = path-identity

No, because I want to be able to say, in USEPRO, that if you see any
<path-identity> that is the name of one of your peers, then you don't
relay it to that peer. But that only works if there is no <path-identity>
inside a <tail-entry>.

>Dito, source-identity = path-identity / IP-address

>Actually I don't see the point of bareword here, is that for
>POSTED and MISMATCH in this variant ?  You could enumerate it:

No, you still need <bareword> as a possibility for <source-identity>,
because the article may have arrived by UUCP, or it may have arrived from
an uninteresting IP address leased to a dialup, and what you want to quote
is the "true source of the article" which you only knew because the
sending site authenticted itself with SASL, using some <bareword> as its
identity.

>>    IP-address = IPv4address / IPv6address ;  see [RFC 3986]

>Okay.  The latter has always a colon, so that's unambiguous

I think we have to accept that this grammar is always going to be
ambiguous (but mostly it doesn't matter). Harald's grammar is even more
ambiguous.

>> [2nd version of syntax, making <source-identity>s readily
>> distinguishable from <path-identity>s.]
>[...]

>The third case is wrong, you want an "!" at the end, always.
>The second case is also wrong, missing "!" before the source.

No, I want a "!" at the end never, except when I am trying to construct
the "!!" case. And it is actually wrong in both versions of my syntax. Try
this:

[1st version]
   path-entry = path-identity *( "!" path-identity ) [ "!" "POSTED" ]
                  [ "!" [ source-identity [ "!" "MISMATCH" ] ] ]
[2nd version]
   path-entry = path-identity *( "!" path-identity )[ "!" "POSTED" ]
                   [ "!" [ path-source ] ]

>>  Two "!"s in succession are equivelent to
>> "!site.example.MATCH!"

or a missing <path-source> (which gives rise to "!!") means it MATCHed.

Note also that my syntax severely limited where [FWS] was allowed
(essentially between things added by one site). If you want to relax that,
then I shall have to take care it does not arise inside a "!!".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22535
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 and #1132 - ABNF for USEFOR 3.1.6
Date: Wed, 14 Sep 2005 14:05:35 GMT
Lines: 67
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>I thought that making the grammar more complex, without anything resembling 
>a group consensus on what a diagnostic "should" look like, was not worth 
>the effort.

I think we need to make it clear what diagnostics are for. That's why I
called them "source-identities", and USEPRO will make it clear that they
can be prepended to indicate the observed identity of the sending site (as
opposed to the <path-identity> that the sending site claimed).

>> Your version skips this detail, in theory it allows adjacent
>> <path-diagnostic>s or <path-keyword>s like...
>>
>> ..!MISMATCH!MISMATCH!.. or ..!MISMATCH!abc::def!MISMATCH!.. or
>> ..!abc::def!abc::def!.. or ..!abc::def!MISMATCH!abc::def!..
>>
>> I'm not sure how bad that is.

>Yes, it does. And it has to - by design, Charles' text for MISMATCH:

>      If it does not match then it prepends instead two entries
>      to that content; firstly the true established <path-identity> of
>      the source followed by a '!', the <path-keyword> "MISMATCH" and a
>      further '!', and then, to the left of that, its own <path-
>      identity> followed by a '!!' <path-delimiter> as usual.

>Given that the "true established path-identity" is likely to be a 
>diagnostic (typically an IP address), not an identity, that will produce 
>something that parses as

>    <path-identity>!!<path-keyword>!!<path-diagnostic>

No, that does not seem right. What my text produces is

     <path-identity>!!<path-diagnostic>!<path-keyword>!

[Note that my text is telling you to "prepend" two things, so they land up
in the opposite order.]

>And given that Charles' examples showed no hard and fast rules for where 
>these diagnostics pop up in Path, I think it's a stretch to mandate 
>particular patterns of these beasts.

I hope I had made it clear that they land up _after_ whatever
<path-identity>s were placed there by the site creating the <path-entry>.

>I definitely tend to "less is more", yes - and not touching the previously 
>established consensus for reserving MISMATCH and POSTED, and adding the !!.
>I'd really like to get finished with this document.

I think we need to discuss and decide upon the alternative suggestion
(Russ, myself, Forrest) for putting some distinctive syntax in the
diagnostic/source-identities (precise syntactic details negotiable).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22536
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 and #1132 - USEPRO text for section 2.3
Date: Wed, 14 Sep 2005 14:16:36 GMT
Lines: 57
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>   <Path-identity>s can take the following forms (in decreasing order of
>   preference):

>   1. A fully qualified domain name (FQDN) that can be resolved to an
>      email server via an MX, A or AAAA record according to the procedures
>      of [RFC2821]; this guarantees that the name is unique, and makes it
>      easy to contact the administrators if needed.

>   2. A fully qualified domain name (FQDN) that is guaranteed to be
>      unique by the administrators of the domain; for instance, the
>      uniqueness of "server.example.org" could be guaranteed by the
>      administrator of "example.org" even if nothing is stored in the
>      DNS for that name.

No, I don't like that at all, and I hear no great clamour for it. (if that
goes, then #1 would go back to something like my present text).

>   3. Some other (arbitrary) name believed to be unique and registered
>      at least with all other news-servers sending articles directly to
>      the given one. This option SHOULD NOT be used unless the earlier
>      options are unavailable, or unless the name is of longstanding
>      usage and cessation would be unduly disruptive, or unless one
>      of the earlier options is provided as well

>   According to [RFC 2142], the forms "usenet@server" and "news@server"
>   are common addresses for a news server administrator.

I though you had ruled that these addresses (and abuse) were not to be
mentioned in USE[FOR,PRO], but only (possibly) is USEAGE.

>-------------------------------------------------------
>Note that I suggest deleting the NOTEs that Charles suggested; I don't 
>think they are needed.

You would still need the NOTE about the dead:beef problem, unless this is
covered in USEFOR (which it seems to be in both of our versions).

>I also deleted the (not connected to the Internet) parenthesis in 3, since 
>with the addition of option 2, that's not a valid excuse to not have a 
>domain name.

I don't see that. If you are totally separated from the internet, then
you are not in a position to negotiate with the administrator of
"example.org".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22532
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2822bis
Date: Wed, 14 Sep 2005 12:04:41 GMT
Lines: 28
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> It would help if you had said somewhere which was the
>> primary group to which your message had been posted.

>But my attribution line was also in some "X-Post style":

>| John C Klensin wrote in <ietf-smtp.imc.org>:

Ah! "ietf-smtp.imc.org" looks like a domain name. What you actually meant
was the mailing list "[email-masked]".

But that seems to me entirely the wrong list to be creating RFC2822bis,
though it would be fine for RFC2821bis.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22537
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ADMIN: Final warning to John Stanley
Date: Wed, 14 Sep 2005 14:22:54 GMT
Lines: 38
Sender: [email-masked]

In <[email-masked]> John Stanley <[email-masked]> writes:

>In fact, looking at your ABNF for this "path-diagnostic", I'll point out
>to you that, unless the diagnostic starts with one of the punctuation
>marks, or contains a colon, it is impossible to differentiate between a
>"path-diagnostic" and a "path-identity". "a.example.com" is completely
>ambiguous.

John

_You_ know that the proposed syntax is a nonsense, and _I_ know that the
proposed syntax is a nonsense. But the WG has voted against us.

I have to live with that. I suggest you do the same.

>>The colon (":") is permitted in order to allow IPv6 addresses to be 
>>inserted;

>IPv6 addresses can be inserted without colons; it is only one method of 
>encoding them that uses colons, and a different method has been proposed 
>to accomplish the same goal without the following admitted problem:

Yes, but I believe that using a non-standard notation for IPv6 addresses
is a worse evil than putting up with the minor inconvenience of the
dead:beef problem (which is most unlikely to arise in practice, and is
easily worked around by any sysadmin who gets caught by it).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Wed, 14 Sep 2005 12:09:37 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Path components (was: ADMIN: Final warning to John Stanley)
Sender: [email-masked]

In message <[email-masked]>, Richard Clayton
<[email-masked]> writes
>
>In message <E943132E910A141B32C6C6C0@B50854F0A9192E8EC6CDA126>, Harald
>Tveit Alvestrand <[email-masked]> writes
>
>>No example of an active site with a 4-letter hex-only name has been brought 
>>to the attention of the working group.
>
>I've checked my data from last year, I find that there were just four
>4-letter path entities in use at that time (I would not expect the
>number to increase, rather the opposite).
>
>They were
>
>        news, mail, iraf, qmul
>
>and the first two are clearly poor choices for a peering server

my humble apologies, I checked the wrong list :( I should also add from
"the peering core" of Usenet the following four letter words

        VISP, apex, esel, frgp, jpix,
        ktts, ornl, rice, spin, srcc,
        sws1, tino, torn

and add to these the following path identities from machines (actually I
think most of these will be usernames, which the POSTED requirement
would hide away) which only passed articles _to_ the peering core (ie
never receiving articles from the core and passing them on)

        -ro-, 1010, 3576, 4908, 5849, 6441, 6800, 7338, AAVN, acox, 
        act1, alan, alee, alex, alya, andy, anna, anon, anti, APSY, 
        asya, aton, ba52, bams, bbs3, bbty, bdl5, bill, BJPU, blah, 
        blbl, BORG, boyd, bram, brc4, bull, BUPT, cab4, carl, cbon, 
        CDPA, cet1, cew2, CGSH, chet, chib, Ckit, cold, cool, cpla, 
        Cran, crux, cung, cunt, d158, dade, dani, Dave, dave, DCMA, 
        dd21, deep, dell, denx, dgw2, dirk, dlit, DMCC, donn, doug, 
        dre1, drum, duck, dude, earl, ecik, efbe, elis, emyr, eric, 
        erud, evil, FISH, Fool, fort, free, frey, fttk, fuck, gck2, 
        gdfs, geb3, gene, ggrl, gjba, goon, gruu, gssm, gull, hace, 
        Hace, HCHS, hill, ihug, ikke, iraf, iret, iron, itcz, J0lt, 
        JAR1, jimd, jmac, jml4, john, jori, js54, jv11, jw35, jyri, 
        k235, K3UD, kami, ke10, KHHS, kibo, kiko, kirk, KMSH, kuff, 
        kulu, KYXK, laki, lala, ldjy, leif, liam, Life, Lion, LMM8, 
        loes, lota, luca, luna, lyle, lynn, macs, MANA, Mark, MAYA, 
        mbt2, MDJS, mevk, mgh3, mhg3, mike, miou, mivo, mjtg, mLog, 
        mlsh, Mr.X, mrr1, MSIA, MYTH, name, NCIT, NDHT, need, nemo, 
        neo1, ng56, nide, njtc, nmm1, NNRP, nono, nosp, NTUA, null, 
        OCSA, ORCH, oreo, otto, pane, pang, papa, parc, paul, PCCU, 
        pest, pete, PMSH, poka, pooh, prod, ps10, ptt2, QKMJ, rab4, 
        raff, rb28, rhps, rick, ronn, root, ross, rune, rz10, samc, 
        sara, sbor, SCAU, SCSC, shhh, shs7, SIEC, sino, sis4, Siyu, 
        SJTU, SLee, slim, SMTH, sole, spln, spok, spot, STAN, Star, 
        STAR, sven, Swan, swps, teej, thug, timl, tobi, tolo, tony, 
        towb, tr0x, trio, truc, TTSX, tusk, USTC, vans, vitt, WaBu, 
        wgrb, will, wing, wish, WOLF, woof, ws21, xman, XOOz, xp24, 
        yeah, YKVS, yt50, YTHT, zang, zbeg, zero, Zero, zygo, ZZXY

of this latter group, only these could be hex

        1010, 3576, 4908, 5849, 6441, 6800, 7338, ba52, cab4, d158,
        dade, dd21, efbe

where, one might flippantly ask, is the beef?

(betya all the people with naughty word filters won't see this message!)

- -- 
richard                                              Richard Clayton

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

Date: Wed, 14 Sep 2005 10:41:02 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

In message <E943132E910A141B32C6C6C0@B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <[email-masked]> writes

>No example of an active site with a 4-letter hex-only name has been brought 
>to the attention of the working group.

I've checked my data from last year, I find that there were just four
4-letter path entities in use at that time (I would not expect the
number to increase, rather the opposite).

They were

        news, mail, iraf, qmul

and the first two are clearly poor choices for a peering server

- -- 
richard                                              Richard Clayton

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

Date: Wed, 14 Sep 2005 11:14:59 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

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

NOTE: I don't have much hope of John's behaviour to change based on this=20
note. But it may be useful for other people to see it.

Unlike John, I will reply to the administrative portion, dealing with=20
behaviour, separately from the technical portion, dealing with the actual=20
proposal and objections to it. This is the administrative bit, and only=20
refers to the technical bit when required to illustrate the point.

--On 13. september 2005 10:01 -0700 John Stanley <[email-masked]> wrote:

>> I will suspend your posting rights to this list the next time you post
>> something that I find equally non-constructive.
>
> I find it non-constructive to pretend that text that cannot be entered
> as a path-identity is suddenly acceptable in the same context only
> because  we call it something else. What we call it is not the problem;
> the effect  it has on existing implementations is.
>
> I find it seriously non-constructive to ignore a simple solution to a
> problem that we keep debating and then writing into a standard
> explicitely. Your latest proposed text continues this non-constructive
> trend by admitting that existing software will break if a colon is used
> in  an IPv6 literal, completely ignoring a trivial solution to the
> problem.  Yes, we CAN define how an IPv6 address is encoded into a Path
> header. It  is within our jurisdiction. No, this is NOT something that
> thousands of  admins around the planet will have to enter by hand every
> day, it's  entered automatically by software that can easily produce the
> required  output. When it appears as a diagnostic thingy, it will be
> SOFTWARE that  enters it there, not a human, and SOFTWARE can easily
> convert an IPv6  address into 32 hexadecimal characters.

You have proposed this solution. I, and others, have observed that the same =

debate on how to format an IPv6 address has been had in multiple other=20
fora, including in URIs, and the conclusion has always been to stick with=20
standard notation.

You have not replied to this.

The group has discussed the size of the problem (dead:beef:cafe) caused by=20
using standard IPv6 notation, and my reading of the consensus (without an=20
explicit poll for it) is that the group does not regard the problem as a=20
big enough problem to worry about.
No example of an active site with a 4-letter hex-only name has been brought =

to the attention of the working group.

You have not replied to this by anything I can see but "I disagree", and=20
formulations that I interpret as "it's obvious that I'm right".

> I find it non-constructive to claim that something is a "given" when the
> truth is that it might be a consensus belief. "Given" means that =
something
> is an assumption from which discussion is started, not the (shaky) result
> of a long debate. Removal of Charles's item 2 is NOT a given, even if the
> Chair pretends it is. It is a CHOICE made after long debate.

Yes. And that choice is a given that we base the next steps on.
You may choose to think that the group's choice is wrong, but this does not =

give you the right to endlessly harp on the issue, and insist that your=20
disagreement be acknowledged somehow every time the issue is referred to.

> I've been constructive, I've provided the solution to a problem that you
> don't seem interested in doing anything about. I'm now simply reminding
> you that you've chosen to ignore the constructive comments, and that this
> entire discussion about what a "diagnostic" is and is not is a waste of
> time and effort.

You've made proposals. You've had objections raised to them. You've not=20
responded, but have insisted that you have presented "the solution".

I'm not saying none of your messages to the list are constructive. But your =

failure to respond to criticism, and the vituperative tone of your=20
messages, including the "green is red" non-sequitur you keep on inserting,=20
is simply not acceptable behaviour for a WG participant.

                   Harald

--==========3C7386BF9E781CB66B2A==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========3C7386BF9E781CB66B2A==========--

Date: Tue, 13 Sep 2005 10:01:12 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: ADMIN: Final warning to John Stanley
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>I do not find you amusing.

I was not attempting to be amusing. I was attempting to point out that
this "diagnostic-thingy" is the same sort of duck a path-identity is, no 
matter if we call it a goose or a gondola. If a colon in a path-identity 
is forbidden for cause, then the same cause exists to forbid it in a 
diagnostic, because a diagnostic will appear in exactly the same place.

In fact, looking at your ABNF for this "path-diagnostic", I'll point out
to you that, unless the diagnostic starts with one of the punctuation
marks, or contains a colon, it is impossible to differentiate between a
"path-diagnostic" and a "path-identity". "a.example.com" is completely
ambiguous.

I was going to respond separately to your proposed text, but in for a 
penny:

> 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.

Incorrect. A path-identity can also be a single word, as in a UUCP name.  
This is historical usage that nobody is seriously thinking will stop just
because we say it should. Your own ABNF does not mandate a dot. Even your
own proposed text for path-identity allows single word (i.e.  'dotless')
names. (Item 3) There is no "domain name" requirement.

>A path-diagnostic is an item inserted into the Path header for purposes 
>other than to indicate the name of a site.

You've defined what purpose a path-diagnostic is NOT for; what IS it for?
"Other than the name". Well, ok, it's not the name of a site. Except 
sometimes it will be; it can be the "real" name of the site a server gets
an article from if there is a mismatch. Not only is it then indicating the 
name of a site, it is indicating a name of a site the article passed 
through. And that's how we define path-identity. Green is red. Red is 
blue. Blue doesn't exist.

There is just not enough difference between the two to justify this 
artificial differentiation. The time you are using to debate this and try 
to come up with correct ABNF and new definitions is wasted. The existing 
path-identity is more than sufficient to do what needs to be done, and by 
simply prohibiting colons in IPv6 addresses we solve the dead:beef 
problem. And yet it is more constructive at this point in the game to 
spend more time debating new definitions that aren't really definitions at 
all.

>The colon (":") is permitted in order to allow IPv6 addresses to be 
>inserted;

IPv6 addresses can be inserted without colons; it is only one method of 
encoding them that uses colons, and a different method has been proposed 
to accomplish the same goal without the following admitted problem:

>note that this will cause interoperability problems at older sites that 
>regard ":" as a path-delimiter ...

Interoperability is a key goal, no? Ok, I guess not.

>I will suspend your posting rights to this list the next time you post 
>something that I find equally non-constructive.

I find it non-constructive to pretend that text that cannot be entered
as a path-identity is suddenly acceptable in the same context only because 
we call it something else. What we call it is not the problem; the effect 
it has on existing implementations is.

I find it seriously non-constructive to ignore a simple solution to a 
problem that we keep debating and then writing into a standard 
explicitely. Your latest proposed text continues this non-constructive 
trend by admitting that existing software will break if a colon is used in 
an IPv6 literal, completely ignoring a trivial solution to the problem. 
Yes, we CAN define how an IPv6 address is encoded into a Path header. It 
is within our jurisdiction. No, this is NOT something that thousands of 
admins around the planet will have to enter by hand every day, it's 
entered automatically by software that can easily produce the required 
output. When it appears as a diagnostic thingy, it will be SOFTWARE that 
enters it there, not a human, and SOFTWARE can easily convert an IPv6 
address into 32 hexadecimal characters. 

I find it non-constructive to claim that something is a "given" when the
truth is that it might be a consensus belief. "Given" means that something
is an assumption from which discussion is started, not the (shaky) result
of a long debate. Removal of Charles's item 2 is NOT a given, even if the 
Chair pretends it is. It is a CHOICE made after long debate.

I've been constructive, I've provided the solution to a problem that you
don't seem interested in doing anything about. I'm now simply reminding
you that you've chosen to ignore the constructive comments, and that this
entire discussion about what a "diagnostic" is and is not is a waste of
time and effort.

To: [email-masked]
Xref: clerew local.usefor:22525
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: NAI semantics (Re: #1047 Path field delimiters and syntax - status)
Date: Tue, 13 Sep 2005 11:23:16 GMT
Lines: 53
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>[Changing subject - far off thread]

>No, it explicitly does not.
>I did not quote all of RFC 2486, but the document makes it very clear that 
>there is NO requirement for *anything* to be at this point in the DNS.

>The requirement for using foo.bar.example.com as a NAI is that you have a 
>"right to use" the name foo.bar.example.com in the DNS.
>This can be an agreement with the bar.example.com administrator, or an 
>agreement with the example.com administrator (if bar isn't administered 
>separately) - there's no need for anything in the DNS.

The problem with that is that a "right" which is only established by some
verbal or written agreement with some administrator cannot be verified
externally.

The wording in RFC 2486 is far from clear.

  Those wishing to use an NAI realm name should first acquire the rights
  to use the corresponding FQDN.

It does not define "rights". If the nameserver for example.com does not
contain an NS or SOA record for bar.example.com, then the "right" to
foo.bar.example.com remains with example.com. OTOH, if such an NS or SOA
record does exist, then the "right" belongs to whoever owns the nameserver
contained therein, which would presumably be bar.example.com.

  Using an NAI realm without ownership of the corresponding FQDN creates
  the possibility of conflict and therefore is to be discouraged.

Again, what does "ownership" mean, and how does it relate to "rights"?

  Note that the use of an FQDN as the realm name does not imply use of the
  DNS for location of the authentication server or for authentication
  routing.

Which indicates that you don't have to use the DNS to locate the NAI host
(indeed, the DNS may not contain that nformation). But it seems that you
still need the DNS, or some part of it, in order to establish those
"rights" or "ownership".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Tue, 13 Sep 2005 13:22:05 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Cc: Scott Hollenbeck <[email-masked]>
Subject: ADMIN: Final warning to John Stanley
Sender: [email-masked]

John,

I do not find you amusing.
Or constructive.

I will suspend your posting rights to this list the next time you post 
something that I find equally non-constructive.

See RFC 3934 for the details.

--On mandag, september 12, 2005 10:51:31 -0700 John Stanley 
<[email-masked]> wrote:

>
>
> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> ... given that your previous case 2 should disappear,
>
> Given? The only given about case 2 is that it will continue to happen.
> When did it become a "given" that it should dissappear? The poll result
> was 4 to 2 (hardly earthshaking), and the 4 were actually voting that ip
> literals still be allowed to appear in the path header field but they
> just won't be called path-identities.
>
> It looks like a duck, it walks like a duck, it appears in the same place
> a  duck appears, but it ain't a duck because we think it is "given" that
> it ain't a duck. Green is red.
>
>
>
>
>

Date: Tue, 13 Sep 2005 13:18:00 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: #1047 and #1132 - ABNF for USEFOR 3.1.6
Sender: [email-masked]

--On tirsdag, september 13, 2005 12:24:53 +0200 Frank Ellermann 
<[email-masked]> wrote:

>
> Harald Tveit Alvestrand wrote:
>
>> path-identity   =  ( ALPHA / DIGIT )
>>                    *( ALPHA / DIGIT / "-" / "." / "_" )
>
>> path-diagnostic = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
>
> Here you hae one problem:  Each <path-identity> is also a
> <path-diagnostic>.  If the latter doesn't start with ALPHA or
> DIGIT (and/or if it contains a colon) it's clear what it is.

That's right.
Used as a parsing grammar and looking for names, that's not a problem - you 
may have a few more tokens to match against your neighbour list that were 
intended as diagnostics.

I thought that making the grammar more complex, without anything resembling 
a group consensus on what a diagnostic "should" look like, was not worth 
the effort.

> Like Charles you also have an "_" in the <path-identity> for
> the non-<bareword> case.

Yep. Allowing _ in hostnames seems to be an old tradition for USEFOR 
drafts, and I didn't change it for this.

> Charles versions have it clear that there are one or more
> path-identities optionally followed by one "diagnostic"
> per site (= <path-entry> in his proposals).
>
> Your version skips this detail, in theory it allows adjacent
> <path-diagnostic>s or <path-keyword>s like...
>
> ..!MISMATCH!MISMATCH!.. or ..!MISMATCH!abc::def!MISMATCH!.. or
> ..!abc::def!abc::def!.. or ..!abc::def!MISMATCH!abc::def!..
>
> I'm not sure how bad that is.

Yes, it does. And it has to - by design, Charles' text for MISMATCH:

      If it does not match then it prepends instead two entries
      to that content; firstly the true established <path-identity> of
      the source followed by a '!', the <path-keyword> "MISMATCH" and a
      further '!', and then, to the left of that, its own <path-
      identity> followed by a '!!' <path-delimiter> as usual.

Given that the "true established path-identity" is likely to be a 
diagnostic (typically an IP address), not an identity, that will produce 
something that parses as

    <path-identity>!!<path-keyword>!!<path-diagnostic>

And given that Charles' examples showed no hard and fast rules for where 
these diagnostics pop up in Path, I think it's a stretch to mandate 
particular patterns of these beasts.

> Apparently you prefer the "let's not invent new stuff
> in addition to '!!'" approach, taking "!MISMATCH!" and
> "!POSTED!" as given.

I definitely tend to "less is more", yes - and not touching the previously 
established consensus for reserving MISMATCH and POSTED, and adding the !!.
I'd really like to get finished with this document.

No comments on the details of the alternate grammar.... it's definitely 
more specific, but I wonder if being more specific is good here.

                        Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 and #1132 - ABNF for USEFOR 3.1.6
Date:  Tue, 13 Sep 2005 13:07:06 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

>  path-diag     = [ path-sep "POSTED" ]
>                  [ path-sep (( IP-address / path-identity )
>                                path-sep "MISMATCH"          ) ]

Ugh... too easy to get it wrong, the MISMATCH case must be
optional:

   path-diag     = [ path-sep "POSTED" ]
                   [ path-sep [( IP-address / path-identity )
                                 path-sep "MISMATCH"          ] ]

Hiding the "!!" as "!...!MISMATCH!" without the "...!MISMATCH"
is bad, actually that would be [FWS] "!" [FWS] [FWS] "!" [FWS]

One [FWS] too many for my tastes.

   path-diag     = [ path-sep "POSTED" ]
                   [ ( path-sep ( IP-address / path-identity )
                       path-sep "MISMATCH" ) / ( [FWS] "!" ) ]

Now the "!!" case is [FWS] "!" path-sep, and that's the same
as [FWS] "!" [FWS] "!" [FWS]
                               Sorry, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 and #1132 - ABNF for USEFOR 3.1.6
Date:  Tue, 13 Sep 2005 12:24:53 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 84
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

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

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

Here you hae one problem:  Each <path-identity> is also a
<path-diagnostic>.  If the latter doesn't start with ALPHA or
DIGIT (and/or if it contains a colon) it's clear what it is.

Like Charles you also have an "_" in the <path-identity> for
the non-<bareword> case.

Charles versions have it clear that there are one or more
path-identities optionally followed by one "diagnostic"
per site (= <path-entry> in his proposals).

Your version skips this detail, in theory it allows adjacent
<path-diagnostic>s or <path-keyword>s like...

..!MISMATCH!MISMATCH!.. or ..!MISMATCH!abc::def!MISMATCH!.. or
..!abc::def!abc::def!.. or ..!abc::def!MISMATCH!abc::def!..

I'm not sure how bad that is.

Apparently you prefer the "let's not invent new stuff
in addition to '!!'" approach, taking "!MISMATCH!" and
"!POSTED!" as given.

That's in the direction of Charles' first variant.  The
concept of "one or more identity per site" in Charles'
versions isn't critical:

If a site wants this, it can just do it, and if it adds
diagnostics for its own multiple identities it's stupid
but no real problem.

With that simplification here's another version, a wild
mixture of your proposal and Charles' first version:

 path          = "Path:" SP [FWS] path-list [FWS] CRLF
 path-list     = *( path-entry path-sep ) tail-entry
 path-entry    = path-identity [ path-diag ]

 tail-entry    = path-identity  ; typically "not-for-mail"

 path-identity = ( 1*( label "." ) toplabel ) / bareword
 bareword      = ALPHA *( [ "-" / "_" ] alphanum )
 label         = alphanum [ *( alphanum / "-" ) alphanum ]
 toplabel      = ALPHA    [ *( alphanum / "-" ) alphanum ]
 alphanum      = ALPHA / DIGIT

 path-diag     = [ path-sep "POSTED" ]
                 [ path-sep ( IP-address / path-identity ) ]
                 [ path-sep [ "MISMATCH" ]]

 IP-address    = IPv4address / IPv6address  ; see [RFC 3986]
 path-sep      = [FWS] "!" [FWS]

The lost "!!" is actually still there:  "!MISMATCH!" without
the "MISMATCH" is "!!".

Showing the <source-identity> in the case of a match strikes
me as nonsense, and a !MISMATHCH! without <source-identity>
is also dubious, here's a cleaner solution:

 path-diag     = [ path-sep "POSTED" ]
                 [ path-sep (( IP-address / path-identity )
                               path-sep "MISMATCH"          ) ]

With that trick IPs appear only to the left of a "!MISMATH!",
or in other words, anything to the left of "!MISMATCH!" is a
<source-identity> (in Charles' terminology).

Anything else is a <path-identity> or the <tail-entry> or the
keyword "POSTED".  Bill's parser says okay for both variants
of my <path-diag>, but it won't see if there are too many or
not enough "!" somewhere.
                          Bye, Frank

P.S.:  <bareword> must start with ALPHA, is that as we want
       it, or is <alphanum> good enough ?

Date: Tue, 13 Sep 2005 11:30:20 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1047 and #1132 - USEPRO text for section 2.3
Sender: [email-masked]

This is not a text that I'm asking the WG to resolve on now (since we're 
still trying to get USEFOR finished), but I want to have it recorded in the 
mailing list archives now, and resolve it when we get around to USEPRO.

Suggested text, replacing the text of USEPRO section 2.3 from the second
paragraph to the end:
-------------------------------------

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that can be resolved to an
      email server via an MX, A or AAAA record according to the procedures
      of [RFC2821]; this guarantees that the name is unique, and makes it
      easy to contact the administrators if needed.

   2. A fully qualified domain name (FQDN) that is guaranteed to be
      unique by the administrators of the domain; for instance, the
      uniqueness of "server.example.org" could be guaranteed by the
      administrator of "example.org" even if nothing is stored in the
      DNS for that name.

   3. Some other (arbitrary) name believed to be unique and registered
      at least with all other news-servers sending articles directly to
      the given one. This option SHOULD NOT be used unless the earlier
      options are unavailable, or unless the name is of longstanding
      usage and cessation would be unduly disruptive, or unless one
      of the earlier options is provided as well

   According to [RFC 2142], the forms "usenet@server" and "news@server"
   are common addresses for a news server administrator.

-------------------------------------------------------
Note that I suggest deleting the NOTEs that Charles suggested; I don't 
think they are needed.
I also deleted the (not connected to the Internet) parenthesis in 3, since 
with the addition of option 2, that's not a valid excuse to not have a 
domain name.

The last sentence is the remnants of the "email contact address 
requirement".

                           Harald

Date: Tue, 13 Sep 2005 10:10:15 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1047 and #1132 - ABNF for USEFOR 3.1.6
Sender: [email-masked]

Here's my current proposal, based on the discussion.

   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  =  "!" / "!!"

   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"
   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.

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 neighbours whose names have 4 or fewer characters, 
and where all the characters are valid HEX digits.

[USEPRO] gives details on how to choose a path-identity and how to 
construct the Path: header.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  New reference for 3.1.3 (?)
Date:  Tue, 13 Sep 2005 09:07:38 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 13
Sender: [email-masked]

Hi, the I-D explaining the issues of case-insensitive
DNS labels was just approved as PS:

http://ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-06

Should we add a reference to it in section 3.1.3 ?

Its "security considerations" suggest that some form
of a "canonicalization" is fine - but our "pick what
you like and then pray stick to it" is of course not
what this text proposes.
                        Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2822bis
Date:  Tue, 13 Sep 2005 05:57:54 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Charles Lindsey wrote:

> It would help if you had said somewhere which was the
> primary group to which your message had been posted.

Yes, somewhere like the header in a Cc: or To: or similar :-(

For unknown reasons my X-Post arrived only in one of the
two lists, and it wasn't the normal PEBKAC / typo problem.
Therefore I sent it again separately to USEFOR.

But my attribution line was also in some "X-Post style":

| John C Klensin wrote in <ietf-smtp.imc.org>:

Unfortunately the Web-side of GMaNe stopped to work 09-08,
you have to go to the original list archive at the moment:

<http://www.imc.org/ietf-smtp/mail-archive/maillist.html>
<http://www.imc.org/ietf-smtp/mail-archive/msg02527.html>

Mainly about "why should 2821bis wait for 2822bis ?".  Bye

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: NAI semantics
Date:  Tue, 13 Sep 2005 05:35:40 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Harald Tveit Alvestrand wrote:
 
> The requirement for using foo.bar.example.com as a NAI is
> that you have a "right to use" the name foo.bar.example.com
> in the DNS. This can be an agreement with the bar.example.com
> administrator
[.,.]
> there's no need for anything in the DNS.

Apparently the same idea as for <id-domain>, the wildcard for
xyzzy.claranet.de isn't a required part of the show (and with
some stupid spammers taking everything they see with an "@"
it's actually a PITA)
                     Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date:  Tue, 13 Sep 2005 05:18:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 101
Sender: [email-masked]

Charles Lindsey wrote:

>    path-identity = dot-atom-text / bareword

Hi, you can't say <dot-atom-text> here, it contains some
characters we don't like (delimiters for 1036 incl. "!"):

ATEXT: ALNUM ! # $ % & ' * + - / = ? ^ _ ` { | } ~
LDH  : ALNUM                           _

Let's stick to some kind of <ldh-string>.

>    bareword = ALPHA *( [ "-" / "_" ] (ALPHA / DIGIT) )

Yes.  For a "bare" version of <ldh-string> you'd get...

     ldh-fqdn = ALPHA *( [ "-" / "." ] (ALPHA / DIGIT) )

...or similar.  And for an unambiguous bareword without
underscore you'd need the "at least one dot" kludge, i.e.

 path-identity = ( 1*( label "." ) label ) / bareword
 label         = alphanum [ *( alphanum / "-" ) alphanum ]
 alphanum      = ALPHA / DIGIT

There are several cases of ALPHA / DIGIT in USEFOR, so the
additional <alphanum> is justified.

With that version of <label> there's still an unnecessary
ambiguity with <IPv4address>, it can be solved by <toplabel>:

 path-identity = ( 1*( label "." ) toplabel ) / bareword
 label         = alphanum [ *( alphanum / "-" ) alphanum ]
 toplabel      = ALPHA    [ *( alphanum / "-" ) alphanum ]
 alphanum      = ALPHA / DIGIT

IIRC we already had this part of the syntax before in the
discussions.

>    tail-entry = dot-atom-text / bareword

No <dot-atom-text>, just say tail-entry = path-identity

>    source-identity = dot-atom-text / IP-address / bareword

Dito, source-identity = path-identity / IP-address

Actually I don't see the point of bareword here, is that for
POSTED and MISMATCH in this variant ?  You could enumerate it:

     source-identity = ( 1*( label "." ) toplabel )
                     / "MISMATCH" / "POSTED" / IP-address

>    IP-address = IPv4address / IPv6address ;  see [RFC 3986]

Okay.  The latter has always a colon, so that's unambiguous
(add usual dead:beef rant here).  The former has always three
dots and digits, but never an ALPHA => no <toplabel>, no FQDN.

> [2nd version of syntax, making <source-identity>s readily
> distinguishable from <path-identity>s.]
[...]

>    path-identity = dot-atom-text / bareword

See above, better use <label> - in this variant an IPv4 is
always unambiguous, you don't need the <toplabel> detail.

>    tail-entry = dot-atom-text / bareword

See above, tail-entry = path-identity or, as you have it,
just the same syntax, but not the <dot-atom-text> version.

>    path-source = source-identity ( ".SEEN" / ".MATCH" /
>                                    ".MISMATCH" )

>    source-identity = dot-atom-text / IP-address / bareword

Something's wrong here, your syntax aparently allows...

     path-identity!path-identity!POSTED!path-source!
     path-identity!path-identity path-source!
     path-identity!path-identity

The third case is wrong, you want an "!" at the end, always.
The second case is also wrong, missing "!" before the source.

>  Two "!"s in succession are equivelent to
> "!site.example.MATCH!"

Okay, here's the fixed (?) version:

     path-entry = 1*( path-identity "!" )
                  [ "POSTED!" ] [[ path-source ] "!" ]

Skipping the prose, please could somebody else check this ?

                           Bye, Frank

Date: Mon, 12 Sep 2005 10:59:05 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>[2nd version of syntax, making <source-identity>s readily
>distinguishable from <path-identity>s.]

>   path-identity = dot-atom-text / bareword

>   source-identity = dot-atom-text / IP-address / bareword

How is one "dot-atom-text" readily distinguishable from any other?

>      NOTE: An <IPv6address> is the only place where a ":" can occur
>      within a <path-entry>. Since some current news-servers may treat
>      ":" as a delimiter (in addition to the customary "!"), it is
>      inadvisable for any <bareword> to be composed only from
>      hexadecimal digits.

Since we can solve this problem TRIVIALLY, why are we still pretending 
we cannot? Can someone please explain why we ought not use a simple 
solution and prevent this problem altogether?

>All the diagnostic <path-source>s are immediately distinguishable from the
><path-identity>s by the presence of a big uppercase keyword.
 
Allow me to point out again how ... silly ... this is, to pretend that we 
cannot have an IP literal as a path-identity, so we define a new kind of 
thing to allow IP literals to appear in exactly the same places we say 
they cannot appear when they are called path-identities.

Date: Mon, 12 Sep 2005 10:51:31 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: #1047 Path field delimiters and syntax - status
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

> ... given that your previous case 2 should disappear,

Given? The only given about case 2 is that it will continue to happen.
When did it become a "given" that it should dissappear? The poll result 
was 4 to 2 (hardly earthshaking), and the 4 were actually voting that ip 
literals still be allowed to appear in the path header field but they
just won't be called path-identities. 

It looks like a duck, it walks like a duck, it appears in the same place a 
duck appears, but it ain't a duck because we think it is "given" that it
ain't a duck. Green is red.

Date: Mon, 12 Sep 2005 16:34:34 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: NAI semantics (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

[Changing subject - far off thread]

--On mandag, september 12, 2005 12:28:54 +0000 Charles Lindsey 
<[email-masked]> wrote:

> Yes, but that does not go as far as Forrest was suggesting. RFC 2486 makes
> it clear that if you want to use foo.bar.example.com as an NAI realm, then
> it had better resolve to _something_ in the DNS (though maybe a mere TXT
> record would suffice).

No, it explicitly does not.
I did not quote all of RFC 2486, but the document makes it very clear that 
there is NO requirement for *anything* to be at this point in the DNS.

The requirement for using foo.bar.example.com as a NAI is that you have a 
"right to use" the name foo.bar.example.com in the DNS.
This can be an agreement with the bar.example.com administrator, or an 
agreement with the example.com administrator (if bar isn't administered 
separately) - there's no need for anything in the DNS.

To: [email-masked]
Xref: clerew local.usefor:22515
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1132: Allowing IP addresses as path-identiites - Poll result
Date: Mon, 12 Sep 2005 14:13:23 GMT
Lines: 192
Sender: [email-masked]

In <9F009A3C66B6C79AEB4756D7@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>I've taken out ticket #1132 to cover this specific issue, rather than the=20
>more generic #1047 ticket. They're linked in the tracker.

>Result:

>> YES - IP addresses should be allowed as path-identity.
>John Stanley
>Charles Lindsey

>> NO - IP addresses should not be allowed as path-identity.
>Richard Clayton
>Russ Allbery
>Frank Ellermann
>Dan Schlitt

I am disappointed at the way the decision went, but I have to live with it.

>I'll write up a suggested modification to section 3.2.1 based on this.

What is written has to be carefully tailored to what will be written in
USEFOR. Here is a suggested text (or rather two texts, with the second one
using SEEN/MATCH/MISMATCH to distingish diagnostics, which I propose to
call <source-identity>s, from <path-idenitiy>s.

I have followed Kai's suggestion for restricting the syntax of <bareword>.

Injection-Infor and Xref will simply use <path-identity> as redefined.

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 a <path-entry> to this header field
   body. .......

[1st version of syntax, following the usage of POSTED and
MISMATCH in the present USEFOR.]

   path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF

   path-entry = path-identity *( "!" path-identity ) [ "!" "POSTED" ]
                  [ [ source-identity [ "!" "MISMATCH" ] ] "!" ]

   path-identity = dot-atom-text / bareword

   bareword = ALPHA *( [ "-" / "_" ] (ALPHA / DIGIT) )

   tail-entry = dot-atom-text / bareword

   source-identity = dot-atom-text / IP-address / bareword

   IP-address = IPv4address / IPv6address ;  see [RFC 3986]

   Each <path-entry> (but not the <tail-entry>) indicates, from right to
   left, the successive sites through which the article has passed.  The
   keyword "POSTED" indicates that the agent to its left injected the
   article. A <source-identity>, if present, indicates the true source
   from which the agent to its left acquired the article (and any
   following "!MISMATCH" asserts that this differs from the
   <path-identity>(s) inserted by the preceding site, whereas two "!"s
   in succession indicate that the preceding <path-identity>(s) accords
   with that true source).

   The full procedure for constructing a <path-entry> as well as the
   preferred format to be used in a <path-identity> are discussed in
   [USEPRO].

      NOTE: An <IPv6address> is the only place where a ":" can occur
      within a <path-entry>. Since some current news-servers may treat
      ":" as a delimiter (in addition to the customary "!"), it is
      inadvisable for any <bareword> to be composed only from
      hexadecimal digits.

      NOTE: Historically, the <tail-entry> .........

      NOTE: Although case-insensitive, it is intended that the keywords
      "POSTED" and "MISMATCH" should be in upper case, to distinguish
      them from the <bareword>s which are traditionally in lower
      case.

[2nd version of syntax, making <source-identity>s readily
distinguishable from <path-identity>s.]

   path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF

   path-entry = path-identity *( "!" path-identity )[ "!" "POSTED" ]
                   [ [ path-source ] "!" ]

   path-identity = dot-atom-text / bareword

   bareword = ALPHA *( [ "-" / "_" ] (ALPHA / DIGIT) )

   tail-entry = dot-atom-text / bareword

   path-source = source-identity ( ".SEEN" / ".MATCH" / ".MISMATCH" )

   source-identity = dot-atom-text / IP-address / bareword

   IP-address = IPv4address / IPv6address ;  see [RFC 3986]
 
   Each <path-entry> (but not the <tail-entry>) indicates, from right to
   left, the successive sites through which the article has passed.  The
   keyword "POSTED" indicates that the agent to its left injected the
   article. A <path-source>, if present, indicates the true source from
   which the agent to its left acquired the article, and whether it
   accords with the <path-identity>(s) inserted by the preceding site.
   Two "!"s in succession are equivelent to "!site.example.MATCH!" where
   "site.example" agrees with that preceding <path-identity>(s).

   The full procedure ........

      NOTE: An <IPv6address> is the only place ...........

      NOTE: Historically, the <tail-entry> .........

      NOTE: Although case-insensitive, it is intended that the "SEEN",
      "POSTED" or "MISMATCH" in a <path-source> should be in upper case,
      to distinguish them from the <bareword>s which are traditionally
      in lower case.

In the following examples, "upstream.example.com" is a site which has
just sent an article (or so it is claimed) to "downstream.example.com".
"123.123.123.123" is the IP address from which downstream received it,
which may or may not be the IP address of upstream. The examples show the
full <path-entry> inserted by downstream, followed by (at least the start
of) the <path-entry> inserted by upstream.
 
1. downstream.example.com!123.123.123.123.SEEN!upstream.example.com...
2. downstream.example.com!123.123.123.123.MISMATCH!upstream.example.com...
3. downstream.example.com!123.123.123.123.MATCH!upstream.example.com...
4. downstream.example.com!!upstream.example.com...
5. downstream.example.com!upstream.example.com...
 
All the diagnostic <path-source>s are immediately distinguishable from the
<path-identity>s by the presence of a big uppercase keyword.
 
Even if you thought 123.123.123.123 was a site to which you were not
supposed to send articles, no current implementation would recognize it as
such in any of those examples.
 
Ex1. Downstream recorded that 123.123.123.123 was the source of the
article "just for the hell of it". It makes no claim to have verified that
it belonged to upstream.
 
Ex2. Downstream recorded that 123.123.123.123 was the source of the
article and asserted that it no way matched any known address associated
with upstream. Some current practice uses exactly that notation.

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

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

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

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

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

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

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22514
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Mon, 12 Sep 2005 12:49:42 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> [email-masked] (Kai Henningsen) writes:

>[email-masked] (Charles Lindsey)  wrote on 09.09.05 in <[email-masked]>:

>> In <[email-masked]> [email-masked] (Kai Henningsen)
>> writes:
>>
>> Maybe a <bareword> should be defined as needing to contain at least one
>> ALPHA.

>Hmm.

>I think the only place I've seen the term used before was in Perl, and so  
>to me it suggests the syntax of a language identifier - that is, a letter  
>followed by letters, digits, and underscores, and nothing else - and that  
>includes no dots.

The term was introduced by Harald ro describe all those <path-identity>s
that were neither domain names nor IP addresses.

And actually, I think restricting their syntax to what you describe might
actually make good sense. Does anyone know of existing practice contrary
to that?

>If that's not what we mean, I would very much prefer us using a different  
>name for it.

Sure.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22512
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2822bis (was: Virtual last call on "bounce")
Date: Mon, 12 Sep 2005 12:20:00 GMT
Lines: 41
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>John C Klensin wrote in <ietf-smtp.imc.org>:

>> I am somewhat disinclined to get 2821bis-02, or even
>> 2821bis-01, posted before 2822bis-00 appears, so people who
>> would like to see faster turnover on 2821bis drafts should
>> be pinging Pete.

>Starting 2822bis before the core USEFOR document is ready (or
>the USEFOR WG terminated) would be an _excessively_ bad idea.

Well I wouldn't mind them making a start on it, but it needs to be made
clear that compatibility with Netnews/NNTP practice is essential if they
expect to get it through the IESG.

>AFAIK Bruce intends to integrate 2047 (2231) encoded words into
>2822bis, even deciding if that's a good or bad idea could be a
>major effort.

But that strikes me as an excellent idea. Particularly if they can clean
up the RFC 2047 mess in the process (but they should only be considering
the small part of 2231 related to language coded in 2047).

>P.S.:  also posted to USEFOR for info

It would help if you had said somewhere which was the primary group to
which your message had been posted.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22513
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Mon, 12 Sep 2005 12:28:54 GMT
Lines: 45
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>--On fredag, september 09, 2005 13:45:05 +0000 Charles Lindsey 
><[email-masked]> wrote:

>>> I think you're missing here a FQDN not associated with any of these,
>>> possibly not even existing according to DNS, but within "your" sphere of
>>>  administration - that is, a FQDN which "you" could make exist or
>>> associate   with one of the above, but haven't.

>There's tradition for using DNS names like that - in another discussion, I 
>got the following piece quoted at me from RFC 2486, Section 6:

>   NAI realm names are required to be unique and the rights to use a
>   given NAI realm for roaming purposes are obtained coincident with
>   acquiring the rights to use a particular fully qualified domain name
>   (FQDN).  Those wishing to use an NAI realm name should first acquire
>   the rights to use the corresponding FQDN. Using an NAI realm without
>   ownership of the corresponding FQDN creates the possibility of
>   conflict and therefore is to be discouraged.

Yes, but that does not go as far as Forrest was suggesting. RFC 2486 makes
it clear that if you want to use foo.bar.example.com as an NAI realm, then
it had better resolve to _something_ in the DNS (though maybe a mere TXT
record would suffice).

What Forrest seems to be suggesting is that, if bar.example.com belongs to
you, and is recorded in the nameserver for example.com, then you should
automatically be allowed to use foo.bar.example.com as a <path-identity>
without having it recorded in the DNS, either by the nameserver at
example.com, or by whatever nameserver you establish for bar.example.com.

That is going too far for my taste (though it could certainlky be written
into USEPRO if that is what this WG really wants).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  2822bis (was: Virtual last call on "bounce")
Date:  Sun, 11 Sep 2005 11:30:40 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 35
Sender: [email-masked]

John C Klensin wrote in <ietf-smtp.imc.org>:

> I am somewhat disinclined to get 2821bis-02, or even
> 2821bis-01, posted before 2822bis-00 appears, so people who
> would like to see faster turnover on 2821bis drafts should
> be pinging Pete.

Starting 2822bis before the core USEFOR document is ready (or
the USEFOR WG terminated) would be an _excessively_ bad idea.

If the author feels otherwise he's invited to the Message-ID
threads in USEFOR, that would be literally hundreds of articles
from Bruce, Charles, me, and others.  NO-WS-CTL and some other
creatures.

AFAIK Bruce intends to integrate 2047 (2231) encoded words into
2822bis, even deciding if that's a good or bad idea could be a
major effort.

Last but not least there's this Resent-* problem that made it
into one of two senderid appeals some days ago.  2822bis is
hot stuff, and that really cries for a WG... in 2006, not now.

OTOH working on 2821bis is so far not very controversional, and
to my surprise even hardcore SPF and CSV friends have similar
visions not limited to HELO and EHLO.  I don't see why you
should wait for a 2822bis -00.  But there are serious reasons
why a 2822bis -00 should wait for usefor-06 (somewhere between
almost ready or finally give up).
                                  Bye, Frank

P.S.:  also posted to USEFOR for info

Date: 11 Sep 2005 10:51:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: #1047 Path field delimiters and syntax - status
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Charles Lindsey)  wrote on 09.09.05 in <[email-masked]>:

> In <[email-masked]> [email-masked] (Kai Henningsen)
> writes:
>
> >[email-masked] (Charles Lindsey)  wrote on 05.09.05 in
> ><[email-masked]>:

> >>    3. Some other (arbitrary) name believed to be unique and registered
> >>       at least with all other news-servers sending articles directly to
> >>       the given one. This option SHOULD NOT be used unless the earlier
> >>       options are unavailable (e.g. because the server in question is
> >>       not connected to the Internet), or unless it is of longstanding
> >>       usage and cessation would be unduly disruptive, or unless one
> >>       of the earlier options is provided as well.
>
> One of my worries is that <bareword>s (as we seem to be calling case 3)
> will also need a syntax. Clearly it will not allow a ':' (that is where
> this whole argument started), but would it allow a domain-name, or even an
> IPv4Address (which would defeat the object of the proposed restriction)?
>
> Maybe a <bareword> should be defined as needing to contain at least one
> ALPHA.

Hmm.

I think the only place I've seen the term used before was in Perl, and so  
to me it suggests the syntax of a language identifier - that is, a letter  
followed by letters, digits, and underscores, and nothing else - and that  
includes no dots.

If that's not what we mean, I would very much prefer us using a different  
name for it.

MfG Kai

Date: Sat, 10 Sep 2005 15:39:13 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1047 Path field delimiters and syntax - status
Sender: [email-masked]

--On fredag, september 09, 2005 13:45:05 +0000 Charles Lindsey 
<[email-masked]> wrote:

>> I think you're missing here a FQDN not associated with any of these,
>> possibly not even existing according to DNS, but within "your" sphere of
>>  administration - that is, a FQDN which "you" could make exist or
>> associate   with one of the above, but haven't.
>
> I don't think I would really like that usage, but it could be written into
> Case 1 if people want it so.

I think you can make that a Case 2; given that your previous case 2 should 
disappear, the number's free.

There's tradition for using DNS names like that - in another discussion, I 
got the following piece quoted at me from RFC 2486, Section 6:

   NAI realm names are required to be unique and the rights to use a
   given NAI realm for roaming purposes are obtained coincident with
   acquiring the rights to use a particular fully qualified domain name
   (FQDN).  Those wishing to use an NAI realm name should first acquire
   the rights to use the corresponding FQDN. Using an NAI realm without
   ownership of the corresponding FQDN creates the possibility of
   conflict and therefore is to be discouraged.

(NAIs are the things that look just like email addresses but aren't - they 
are used as principal identifiers in some VPN authentication schemes).

To: [email-masked]
Xref: clerew local.usefor:22507
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Allowing IP addresses as path-identiites
Date: Fri, 9 Sep 2005 13:53:45 GMT
Lines: 42
Sender: [email-masked]

In <[email-masked]> John Stanley <[email-masked]> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>No, the idea is that the syntax will be so written that IP addresses are
>>not allowed in <path-identity>s, but will be allowed in
>><diagnostic-identity>s (or whatever we choose to call them).

>Adding that syntax to that draft would be silly, since there is no real 
>difference between a "path-identity" and a "diagnostic-thingy".

The intention AIUI is to put this restriction, presumably as syntax, in
USEFOR. There may well be a syntactic difference between a "path-identity"
and a "diagnostic-thingy" (both Forrest and I have suggested that).

>If we cannot allow IPv6 address literals as path-identities because they
>would confuse existing software into thinking there were multiple
>non-unique path-identities (the "dead:beef" problem), then they cannot be
>allowed as "diagnostic-thingys" in the same header field for the very same
>reason.

Yes I agree with you entirely, for once, but we seem to be the only two
taking that position so far.

>If we solve the dead:beef problem (I mean, use the solution already 
>proposed),

The dead:beef problem has been much over-hyped; I don't think it is a show
stopper (though if you suddenly wanted to allow ':'s in <bareword>s it
might become one). So long as we can tell people to avoid <bareword>s
consisting of hexadecimal digits only, it need not be an issue.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22506
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Fri, 9 Sep 2005 13:45:05 GMT
Lines: 57
Sender: [email-masked]

In <[email-masked]> [email-masked] (Kai Henningsen) writes:

>[email-masked] (Charles Lindsey)  wrote on 05.09.05 in <[email-masked]>:

>>    <Path-identity>s can take the following forms (in decreasing order of
>>    preference):
>>
>>    1. A fully qualified domain name (FQDN) associated with an "A" or
>>       "AAAA" record identifying that news-server, or with an "MX" record
>>       through which its administrators can be contacted; alternatively
>>       an equivalent "CNAME".

>I think you're missing here a FQDN not associated with any of these,  
>possibly not even existing according to DNS, but within "your" sphere of  
>administration - that is, a FQDN which "you" could make exist or associate  
>with one of the above, but haven't.

I don't think I would really like that usage, but it could be written into
Case 1 if people want it so. We certainly need domain names that are not A
or AAAA records because some servers might not always be on line, and
might be using a leased IP. For example, my own server would use
clerew.man.ac.uk, which is an MX record (I have no fixed IP address). But
I would much prefer to stick with domain-names that resolve to at least
something in the DNS.

>Because I'd still see that preferrable to your case 2, and it's certainly  
>a case where whoever decides on the name has control over the uniqueness  
>of the name just as for 1.

>You currently subsume this under 3, where I don't think it belongs.

>>    3. Some other (arbitrary) name believed to be unique and registered
>>       at least with all other news-servers sending articles directly to
>>       the given one. This option SHOULD NOT be used unless the earlier
>>       options are unavailable (e.g. because the server in question is
>>       not connected to the Internet), or unless it is of longstanding
>>       usage and cessation would be unduly disruptive, or unless one
>>       of the earlier options is provided as well.

One of my worries is that <bareword>s (as we seem to be calling case 3)
will also need a syntax. Clearly it will not allow a ':' (that is where
this whole argument started), but would it allow a domain-name, or even an
IPv4Address (which would defeat the object of the proposed restriction)?

Maybe a <bareword> should be defined as needing to contain at least one
ALPHA.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Fri, 09 Sep 2005 13:42:35 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1132: Allowing IP addresses as path-identiites - Poll result
Sender: [email-masked]

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

Poll text:

> chair hat on:
>
> it's "me-too" time.
> If you have an opinion of whether or not we should allow IP addresses as
> path-identities, either YES or NO, please speak up.
>
> YES - IP addresses should be allowed as path-identity.
> NO - IP addresses should not be allowed as path-identity.
>
> NOTE: If we disallow IP addresses as path-identities, we will still allow
> them as "diagnostic data" - nobody's proposed that we should declare
> articles that have IP addresses in the path as non-conformant. However,
> if we disallow them, they WILL be disallowed in Injection-info and Xref,
> which are the two other places that use them.

I've taken out ticket #1132 to cover this specific issue, rather than the=20
more generic #1047 ticket. They're linked in the tracker.

Result:

> YES - IP addresses should be allowed as path-identity.
John Stanley
Charles Lindsey

> NO - IP addresses should not be allowed as path-identity.
Richard Clayton
Russ Allbery
Frank Ellermann
Dan Schlitt

> Other answers, like "you did not specify the question correctly"
Forrest J. Cavalier

I'll write up a suggested modification to section 3.2.1 based on this.

--==========23BD183AB56303D73ECC==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========23BD183AB56303D73ECC==========--

Date: 08 Sep 2005 22:18:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: #1047 Path field delimiters and syntax - status
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Charles Lindsey)  wrote on 05.09.05 in <[email-masked]>:

>    <Path-identity>s can take the following forms (in decreasing order of
>    preference):
>
>    1. A fully qualified domain name (FQDN) associated with an "A" or
>       "AAAA" record identifying that news-server, or with an "MX" record
>       through which its administrators can be contacted; alternatively
>       an equivalent "CNAME".

I think you're missing here a FQDN not associated with any of these,  
possibly not even existing according to DNS, but within "your" sphere of  
administration - that is, a FQDN which "you" could make exist or associate  
with one of the above, but haven't.

Because I'd still see that preferrable to your case 2, and it's certainly  
a case where whoever decides on the name has control over the uniqueness  
of the name just as for 1.

You currently subsume this under 3, where I don't think it belongs.

>    2. An encoding of the public [RFC 1918], permanently routable IP
>       address - <IPv4address> or <IPv6address> [RFC 3986] - of that
>       news-server. This option SHOULD NOT be used if an FQDN for that
>       server is available (however, such IP addresses are perfectly
>       suitable for purely diagnostic identities [reference needed to
>       later section]).
>
>    3. Some other (arbitrary) name believed to be unique and registered
>       at least with all other news-servers sending articles directly to
>       the given one. This option SHOULD NOT be used unless the earlier
>       options are unavailable (e.g. because the server in question is
>       not connected to the Internet), or unless it is of longstanding
>       usage and cessation would be unduly disruptive, or unless one
>       of the earlier options is provided as well.

MfG Kai

Date: Thu, 8 Sep 2005 11:01:20 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites
Sender: [email-masked]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>No, the idea is that the syntax will be so written that IP addresses are
>not allowed in <path-identity>s, but will be allowed in
><diagnostic-identity>s (or whatever we choose to call them).

Having just been told that I was being an obstructionist for not 
discussing the "one document" that we  are supposed to discuss when I 
responded to one of Charles's proposed texts for USAGE, I'll be happy to 
point out that USEPRO does not contain syntax for the path header. That's 
in USEFOR, and USEFOR contains no such "diagnostic-identity" definition. 

Adding that syntax to that draft would be silly, since there is no real 
difference between a "path-identity" and a "diagnostic-thingy".

If we cannot allow IPv6 address literals as path-identities because they
would confuse existing software into thinking there were multiple
non-unique path-identities (the "dead:beef" problem), then they cannot be
allowed as "diagnostic-thingys" in the same header field for the very same
reason.

If we solve the dead:beef problem (I mean, use the solution already 
proposed), then we might as well allow them as path-identities. And stop 
wasting the time debating what a "diagnotic thingy" is and how to 
differentiate it and what to do when someone violates the rules.

To: [email-masked]
Xref: clerew local.usefor:22501
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Date: Thu, 8 Sep 2005 14:11:12 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>Charles Lindsey wrote:
>> In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:
>> 
>> Yes, I made a proposal along those lines, except I put the keyword at the
>> end (because there is some existing practice for that). We can decide
>> after whether to follow that route (certainly the stuff in USEPRO covering
>> diagnostics needs a revision, and that might affect the precise syntax
>> too).

>Putting the keyword at the end makes it look like a TLD.  Starting with . makes
>it easy to determine it is not a bare FQDN.

If it were not for existing practice I would agree with you. But DNews (I
think, plus some others) regularly generates things like
...!news.example.com.MISMATCH!... in the Path, so I think it best to
formalize that usage rather then invent a different kind of wheel. I doubt
ICANN are on the verge of creating a "mismatch" TLD.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22502
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Allowing IP addresses as path-identiites
Date: Thu, 8 Sep 2005 14:35:48 GMT
Lines: 67
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>Does that mean that someone saying NO for path-identity is also
>saying that they reject uses of IP for diagnostics in path-list, since
>the grammar says a path-list contains path-identities, not server-names?

No, the idea is that the syntax will be so written that IP addresses are
not allowed in <path-identity>s, but will be allowed in
<diagnostic-identity>s (or whatever we choose to call them). If there is
some technical difficulty in writing that syntax, then it will be written
as a prohibition in the wording.

It will be my intention, as soon as this issue is decided, to propose a
syntax, probably in two versions, with the diagnostic stuff incorporating
some sort of keyword in one of them.

Injection-Info and Xref will use only <path-identity>. Even if we do allow
IP addresses in <path-identity> (which I still favour), I don't think they
would do any actual harm (e.g. parsing problems) in either of those
headers.

>If people think they want IP addresses for diagnostics, but not
>servers, it is another example of syntax that is easy to construct,
>but impossible to determine if something is a server identity or a diagnostic
>when parsing.  (I object to all syntax that is "write only", including
>a References: header field which cannot be used to determine followups.)

There I agree with you. This restriction, if we agree to it, will be
impossible to enforce. Relayers, when examing the Path, are never going to
do more that take whatever stuff is between the delimiters (however they
understand what a delimiter is) and check whether that stuff matches one
of their peers.

>If people don't want to allow IP addresses for path-identities, then
>they should poll on whether it is a MUST NOT, SHOULD NOT, MUST REJECT,
>MUST NOT RELAY.

I think the only viable options there are MUST NOT/SHOULD NOT generate,
which correspond pretty well to the NO and YES options in the poll.

>Charles was correct in pointing out that I should reconsider and
>indicate MUST ACCEPT, SHOULD NOT generate when used in path-list.  Or, if the
>path-list syntax is changed to distinguish diagnostics (such as a prefix
>keyword starting with ".") then MUST ACCEPT, MUST NOT generate, MAY use the keyword
>prefix + IP address.

That is pretty close to "YES".

>But MUST NOT for server-name, and SHOULD NOT when path-identity for
>Injection-info.

But I fail to see why you would want to make Xref different. Nobody really
cares about Xref, so long as the list of <location>s in it can be
extracted so as to prevent crossposts from showing up twice. The
<server-name> there is really only for humans to look at.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Thu, 08 Sep 2005 08:28:31 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Forrest J. Cavalier III" <[email-masked]>, [email-masked]
Subject: Re: Allowing IP addresses as path-identiites
Sender: [email-masked]

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

Forrest,

why do you bother responding to this thread when you can't be bothered to=20
read the message that started it?

--On 7. september 2005 09:15 -0400 "Forrest J. Cavalier III"=20
<[email-masked]> wrote:

> Does that mean that someone saying NO for path-identity is also
> saying that they reject uses of IP for diagnostics in path-list, since
> the grammar says a path-list contains path-identities, not server-names?

That message specifically said:

> NOTE: If we disallow IP addresses as path-identities, we will still allow
> them as "diagnostic data" - nobody's proposed that we should declare
> articles that have IP addresses in the path as non-conformant. However,
> if we disallow them, they WILL be disallowed in Injection-info and Xref,
> which are the two other places that use them.

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

--==========EAD2006FF148C2DF636D==========--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Allowing IP addresses as path-identiites
Date:  Wed, 07 Sep 2005 22:06:01 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> Does that mean that someone saying NO for path-identity is
> also saying that they reject uses of IP for diagnostics in
> path-list

No, that part would be still TBD, you added "keyword dot IP"
to the list, Charles proposed "IP dot keyword", and I vaguely
recall a dot-atom-text construct from Harald (but that didn't
work because it contained path delimiters).

> You may argue that an implementor knows whether they are
> inserting a server name or a diagnostic, and that there is
> no issue.  But the grammar only allows path-identity, folded
> white space, keywords, and delimiters.  (Well, it allows a
> tail entry which is a path-identity.)

We'd update the Path-ABNF allowing some kind of diagnostics
if the poll results in "no IPs as path-identity".  With this
idea all problems of IPs elsewhere (Xref or Injection-Info)
are eliminated or rather reduced to "diagnostics in the Path".

IMHO it's cleaner than Charles' approach (a SHOULD NOT for
IPs as path-identity).

> Harald can count that as a "YES", "NO", or a "NO RESPONSE"
> however he likes.

What you said sounds like NO for me, and what Charles said
like YES.
                          Bye, Frank

Date: Wed, 7 Sep 2005 09:42:45 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites
Sender: [email-masked]

"Forrest J. Cavalier III" <forrest@xxxxxxxxxxxxxxx>:

> So where do IP addresses for diagnostics fit in?

Not in the path header field, since that is composed of path-identities.
Either it is a path-identity, a path-delimiter, or a keyword.

>but impossible to determine if something is a server identity or a 
>diagnostic when parsing.

Since we have no definition of "diagnostic", yep, anything that appears in 
the path header that isn't a delimiter or keyword is a path-identity.

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>But you don't actually gain anything by forbidding them. The dead:beef
>problem still remains (because IP addresses are still allowed as
>diagnostics) and the syntax becomes a little more complicated.

1. the "dead:beef" problem is trivially solved and said solution has been 
on the table for probably more than a month now. The only reason I've seen 
to disallow IPv6 is that problem; it's been solved, so can we move on yet?

2. If you disallow IP addresses as path-identities, they are disallowed in
the Path header field, since IP addresses are not delimiters and are not
keywords. You cannot say "disallow as path-identity" and then claim they
are still allowed. That's a contradiction. Oh, of course, you could create
a "Diagnotic-Thing"  header field and put them there, but the question is
about path-identities, and those are what appears in path header fields.

Date: Wed, 07 Sep 2005 09:15:44 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites
Sender: [email-masked]

Frank Ellermann wrote:
> Forrest J. Cavalier III wrote:
> 
> 
>>When someone votes "NO - IP Addresses should not be allowed
>>as path-identity" are they voting that Relaying servers are
>>supposed to reject articles which have an IP in the Path:
>>header field?
> 
> 
> We're not "voting".  It's only a poll, you can start your own
> if you don't like Harald's.  When I posted "NO" what I meant
> was this:
> 
> NO - I don't want IPs as "path identity", neither in the Path:
> nor in Xref:, let alone nntp-URLs or Injection-Info.  It should
> be easy to use a proper FQDN as name for _servers_ - and where
> that's not the case we still offer the "traditional name" with
> the necessary caveat that this won't work for conflicts.

The poll wasn't for "server-name", it was for "path-identity."

Does that mean that someone saying NO for path-identity is also
saying that they reject uses of IP for diagnostics in path-list, since
the grammar says a path-list contains path-identities, not server-names?

You may argue that an implementor knows whether they are inserting
a server name or a diagnostic, and that there is no issue.  But the
grammar only allows path-identity, folded white space, keywords, and
delimiters.  (Well, it allows a tail entry which is a path-identity.)

So where do IP addresses for diagnostics fit in?

If people think they want IP addresses for diagnostics, but not
servers, it is another example of syntax that is easy to construct,
but impossible to determine if something is a server identity or a diagnostic
when parsing.  (I object to all syntax that is "write only", including
a References: header field which cannot be used to determine followups.)

If people don't want to allow IP addresses for path-identities, then
they should poll on whether it is a MUST NOT, SHOULD NOT, MUST REJECT,
MUST NOT RELAY.

Charles was correct in pointing out that I should reconsider and
indicate MUST ACCEPT, SHOULD NOT generate when used in path-list.  Or, if the
path-list syntax is changed to distinguish diagnostics (such as a prefix
keyword starting with ".") then MUST ACCEPT, MUST NOT generate, MAY use the keyword
prefix + IP address.

But MUST NOT for server-name, and SHOULD NOT when path-identity for Injection-info.

Harald can count that as a "YES", "NO", or a "NO RESPONSE" however he
likes.  He can interpret precise language into his imprecise choices.

Date: Wed, 07 Sep 2005 09:08:56 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:
> 
>>And if it matters here, I think all diagnostics should start
>>with ".keyword.", such as  "!.mismatch.10.0.0.1".
> 
> 
> Yes, I made a proposal along those lines, except I put the keyword at the
> end (because there is some existing practice for that). We can decide
> after whether to follow that route (certainly the stuff in USEPRO covering
> diagnostics needs a revision, and that might affect the precise syntax
> too).

Putting the keyword at the end makes it look like a TLD.  Starting with . makes
it easy to determine it is not a bare FQDN.

To: [email-masked]
Xref: clerew local.usefor:22492
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Date: Wed, 7 Sep 2005 10:36:50 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>YES - IP addresses should be allowed as path-identity.
>NO - IP addresses should not be allowed as path-identity.

>I think these poll choices are poorly specified.

>I say MUST ACCEPT, MUST NOT generate.  Is that YES or NO?

If you said MUST accept, SHOULD NOT generqte, then that would certainly be
"YES". I grant you it would need some pretty weird circumstance to justify
breaking that SHOULD NOT, but the Real World is a weird place :-).

>And if it matters here, I think all diagnostics should start
>with ".keyword.", such as  "!.mismatch.10.0.0.1".

Yes, I made a proposal along those lines, except I put the keyword at the
end (because there is some existing practice for that). We can decide
after whether to follow that route (certainly the stuff in USEPRO covering
diagnostics needs a revision, and that might affect the precise syntax
too).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22491
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Date: Wed, 7 Sep 2005 10:24:52 GMT
Lines: 30
Sender: [email-masked]

In <6C715BFE8359F291F057BD04@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>chair hat on:

>it's "me-too" time.
>If you have an opinion of whether or not we should allow IP addresses as=20
>path-identities, either YES or NO, please speak up.

>YES - IP addresses should be allowed as path-identity.
>NO - IP addresses should not be allowed as path-identity.

YES

I don't want to encourage them, and I don't expect them to appear often,
if at all, and I support SHOULD NOT use them without good cause.

But you don't actually gain anything by forbidding them. The dead:beef
problem still remains (because IP addresses are still allowed as
diagnostics) and the syntax becomes a little more complicated.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22493
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Date: Wed, 7 Sep 2005 10:40:18 GMT
Lines: 20
Sender: [email-masked]

In <4C8F9B0B48686F7B528A298D@[10.61.80.31]> Harald Tveit Alvestrand <[email-masked]> writes:

>Shucks, I forgot "none of the above" as a choice.....
>Are you talking about components of the path, or about identities that can=20
>appear in Xref: and Injection-info:?

I think we are talking about Path primarily, but it would be natural for
Injection-Info to follow what we decide. And Xref too for consistency,
though technically it hardly matters.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Wed, 07 Sep 2005 09:19:38 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Forrest J. Cavalier III" <[email-masked]>, [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

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

--On 7. september 2005 00:16 -0400 "Forrest J. Cavalier III"=20
<[email-masked]> wrote:

>> Shucks, I forgot "none of the above" as a choice.....
>> Are you talking about components of the path, or about identities that
>> can  appear in Xref: and Injection-info:?
>
> Since you replied by asking a question....does that mean you agree your
> poll choices are ambigous?

No. I think your question meant that you did not understand my poll=20
questions, which I think were completely obvioius given the complete=20
message and even the vaguest memory of the thread that led to me asking=20
this question.

My question was intended to get you to explain what you did not understand.

But since you seem more interested in nitpicking on the poll formulations=20
than in figuring out what the standard should say, I will note that you did =

not answer the question.

                      Harald

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

--==========A1CE52E5599DAC0F3E2D==========--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Allowing IP addresses as path-identiites
Date:  Wed, 07 Sep 2005 09:02:24 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

Forrest J. Cavalier III wrote:

> When someone votes "NO - IP Addresses should not be allowed
> as path-identity" are they voting that Relaying servers are
> supposed to reject articles which have an IP in the Path:
> header field?

We're not "voting".  It's only a poll, you can start your own
if you don't like Harald's.  When I posted "NO" what I meant
was this:

NO - I don't want IPs as "path identity", neither in the Path:
nor in Xref:, let alone nntp-URLs or Injection-Info.  It should
be easy to use a proper FQDN as name for _servers_ - and where
that's not the case we still offer the "traditional name" with
the necessary caveat that this won't work for conflicts.

> I hope people know what they are voting for.

s/voting//  Me too, if you think it's nonsense please tell me.
IMHO we've already discussed all pros and cons, it's possible
to get it right for IPs incl. IPv6, but it would be too messy.

> I don't.

Please post them if you have new arguments.  Just state what
you think - if it convinces Harald-with-hat-on he's free to
ignore all who posted "NO".  It's not really a "vote", it's
testing the water before declaring (rough) consensus.

                         Bye, Frank

Date: Wed, 07 Sep 2005 00:16:12 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

Harald Tveit Alvestrand wrote:
> 
> --On 6. september 2005 13:46 -0400 "Forrest J. Cavalier III" 
> <[email-masked]> wrote:
> 
> 
>>YES - IP addresses should be allowed as path-identity.
>>NO - IP addresses should not be allowed as path-identity.
>>
>>I think these poll choices are poorly specified.
>>
>>I say MUST ACCEPT, MUST NOT generate.  Is that YES or NO?
> 
> 
> Shucks, I forgot "none of the above" as a choice.....
> Are you talking about components of the path, or about identities that can 
> appear in Xref: and Injection-info:?

Since you replied by asking a question....does that mean you agree your poll
choices are ambigous?  This has nothing to do with understanding English.
I observe that your understanding and use of English is excellent, but what's
the reason to avoid RFC2119 terms?  If we can't even ask simple questions
precisely, then let's just give up on writing a useful document.

"not allowed" can mean MUST NOT generate, MUST NOT relay, MUST NOT
use to determine propagation.  Or does it mean that the USEFOR grammar ends up
having no way to specify IP addresses in path-identity (which means there
may not be any RFC2119 MUST terminology.)

"path-identity" is used in the grammar defining the syntax of three
different header fields. (-- A mistake if you ask me....Quick tell me
what will every clients do with an IPv6 address with colons in the
path-identity Xref header field?)

When someone votes "NO - IP Addresses should not be allowed as path-identity"
are they voting that Relaying servers are supposed to reject articles which
have an IP in the Path: header field?   Are they voting that servers are permitted
to reject articles which have an IP in the Path: header field?  Or that
the Injection-info-experiment-trying-to-be-a-standard-field cannot use an IP
address for the first terminal after the first CFWS.

I hope people know what they are voting for. I don't.

To: [email-masked]
Xref: clerew local.usefor:22483
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Polll results on injection-info, and some thought on progress
Date: Tue, 6 Sep 2005 16:57:54 GMT
Lines: 89
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:
>> Harald Tveit Alvestrand <[email-masked]> writes:

>> Well at least we have eliminated 3a, 3b and 3c. I.e. there is a problem
>> with the present description that needs to be fixed.

>> But I have not seen Russ's comment (was it posted here?). May we have some
>> explanation of what "fixing upstream" means?

>If we're going to use MIME, we should use MIME.  If the current MIME spec
>is broken, well, mail client authors are coping, and news client authors
>can cope too.  If it's really broken, it can get fixed in a revision of
>the MIME specification, which we'd then pick up automatically.

There is nothing particularly broken about current MIME. It is just a
little tricky to interface to it correctly. It has four properties that
are of relevance to the present problem.

1. The syntax of <parameter> and its components is written in RFC 822
style, so if you want to know whereabouts CFWS is allowed within it, you
need to understand the RFC 822 comment and folding rules. Since the rest
of our draft follows the RFC 2822 comment and folding style, there is need
for a NOTE (non-normative) to draw attention to this and to indicate
informally what the rule would look like in 2822 style.

2. MIME makes provision for the syntax of the relevant header fields to
include
	.... *( ";" parameter ) ....
with the understanding that any <parameter>s used therein should have been
defined by some standard or registered with IANA or whatever. There is
also a clear understanding that if any <parameter> not so
standardized/registered/whatever is seen, it is to be accepted and ignored
(thus if a future extension adds a new <parameter> to some header field,
then existing software is not broken - though it will not see the benefit
of the new feature). We want to retain that useful MIME feature.

3. There are rules for when the <value> on the RHS of a <parameter> MUST
take the form of a <quoted-string> rather than a <token>; however, if
you cannot (be bothered to) remember which characters are/aren't
<tspecial>s, then it never hurts to enclose them in "..." regardless. We
also want to retain that feature.

4. It is NOT customary to give an ABNF syntax for each particular
<parameter> you choose to define (look through RFC 2046 which defines lots
of <parameter>s for lots of media types without using any ABNF at all).
The benefit of that appreoach is that you are excused from worrying
about <quoted-string>s and CFWS and whatever else.

That is not to say that ABNF has no place in defining <parameter>s. For
example we could well say that one of the defined <parameter>s of the
Injection-Infor field is called "posting-host", and its <value> must
consist of some <dot-atom-text>, allowing you then to write

Injection-Info: news.stanford.edu; posting-host = zebra.standford.edu

or, alternatively,

Injection-Info: news.stanford.edu; posting-host = (this is a long
    folded comment) "zebra.standford.edu"

That is the approach I propose to take (see
http://www.imc.org/ietf-usefor/mail-archive/msg01964.html). Are you happy
with that approach, subject to tuning (there were a few suggestions in the
subsequent discussion that I need to incorporate)?

Here is how it tackles the issues raised above:

#1. Covered in a NOTE.
#2. Contains a syntax as indicated.
#3. Covered in a NOTE.
#4. I give a table of the <parameter>s we propose to define, showing what
you are allowed to put in each (with the aid of some ABNF as in my example
above, which was somewhat oversimplified).

There is also a further NOTE about the gibbousness of RFC 2231 which
can be retained, or omitted, or hacked about as people might like.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

Date: Tue, 6 Sep 2005 20:54:53 -0400
From: Dan Schlitt <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
cc: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

NO - IP addresses should not be allowed as path-identity.

/dan

-- 

Dan Schlitt
[email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Allowing IP addresses as path-identiites
Date:  Tue, 06 Sep 2005 23:55:26 +0200
Lines: 2
Sender: [email-masked]

NO - IP addresses should not be allowed as path-identity.

Date: Tue, 06 Sep 2005 21:31:35 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Forrest J. Cavalier III" <[email-masked]>, [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

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

--On 6. september 2005 13:46 -0400 "Forrest J. Cavalier III"=20
<[email-masked]> wrote:

>
> YES - IP addresses should be allowed as path-identity.
> NO - IP addresses should not be allowed as path-identity.
>
> I think these poll choices are poorly specified.
>
> I say MUST ACCEPT, MUST NOT generate.  Is that YES or NO?

Shucks, I forgot "none of the above" as a choice.....
Are you talking about components of the path, or about identities that can=20
appear in Xref: and Injection-info:?

I haven't yet seen anyone claim to have seen an IP address in Xref: in the=20
wild, and Injection-info: isn't implemented (AFAIK) by anyone yet, so I=20
don't see any reason to do a MUST ACCEPT.
But YMMV.

             Harald

>
> And if it matters here, I think all diagnostics should start
> with ".keyword.", such as  "!.mismatch.10.0.0.1".

--==========5638A6C77A1B9777410D==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========5638A6C77A1B9777410D==========--

Date: Tue, 06 Sep 2005 21:27:37 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Seth Breidbart <[email-masked]>, [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

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

--On 6. september 2005 14:40 -0400 Seth Breidbart <[email-masked]> wrote:

>
> If IP addresses aren't allowed in paths, how is a site to denote "I
> got this from someone claiming to be <domain> but the IP address
> doesn't match, it's actually <ip>"?

That's what I call "diagnostic data" - the site is not inserting its own=20
path-identity, so there's no reason to call it a path-identity.
See my proposal to a solution to #1047, dated June 29.

            Harald

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

--==========CE39FC5E1548F2B309A9==========--

Date: Tue, 6 Sep 2005 14:40:21 -0400 (EDT)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

If IP addresses aren't allowed in paths, how is a site to denote "I
got this from someone claiming to be <domain> but the IP address
doesn't match, it's actually <ip>"?

Seth

Date: Tue, 06 Sep 2005 13:46:10 -0400
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

YES - IP addresses should be allowed as path-identity.
NO - IP addresses should not be allowed as path-identity.

I think these poll choices are poorly specified.

I say MUST ACCEPT, MUST NOT generate.  Is that YES or NO?

And if it matters here, I think all diagnostics should start
with ".keyword.", such as  "!.mismatch.10.0.0.1".

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Organization: The Eyrie
Date: Tue, 06 Sep 2005 10:30:33 -0700
Sender: [email-masked]

Richard Clayton <[email-masked]> writes:
> Harald Tveit Alvestrand <[email-masked]> writes

>> If you have an opinion of whether or not we should allow IP addresses as 
>> path-identities, either YES or NO, please speak up.
>> 
>> YES - IP addresses should be allowed as path-identity.
>> NO - IP addresses should not be allowed as path-identity.

> I think they're unnecessary (and they're also currently uncommon). I
> would not like to see any encouragement for them, so "no"

I agree.

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

Date: Tue, 6 Sep 2005 08:18:52 -0700 (PDT)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Re: Allowing IP addresses as path-identiites 
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>YES - IP addresses should be allowed as path-identity.

Since you aren't going to stop it, it's better to figure out how to allow 
it and have it coexist peacefully.

>NOTE: If we disallow IP addresses as path-identities, we will still allow 
>them as "diagnostic data" -

I'm sorry, but I see no "diagnostic data" component in the definition of 
the path header. I see "path-identity", I see "path-keyword", and I see 
"path-delimiter." If we disallow IP addresses as path-identities, then 
they are disallowed altogether, since they fit neither the limited 
definition of path-keyword nor path-delimiter.

>I think we should delete option 2 in the list below.

There is no reason to, if you encode the IPv6 addresses as has been 
suggested several times. The only reason not to allow IPv6 is the 
dead:beef problem, which is trivially avoided. I know of no reason not to 
allow IPv4. It is, for routable addresses, as unique as the FQDN.

Date: Tue, 6 Sep 2005 12:31:57 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

In message <6C715BFE8359F291F057BD04@B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <[email-masked]> writes

>If you have an opinion of whether or not we should allow IP addresses as 
>path-identities, either YES or NO, please speak up.
>
>YES - IP addresses should be allowed as path-identity.
>NO - IP addresses should not be allowed as path-identity.

I think they're unnecessary (and they're also currently uncommon). I
would not like to see any encouragement for them, so "no"

- -- 
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"

Date: Tue, 06 Sep 2005 12:33:23 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Allowing IP addresses as path-identiites (Re: #1047 Path field delimiters and syntax - status)
Sender: [email-masked]

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

technical contributor hat on:

In case anyone is in any doubt whatsoever, I think we should delete option=20
2 in the list below. It adds zero value for the users of the standard, and=20
creates one more reason for identities to be unstable.

chair hat on:

it's "me-too" time.
If you have an opinion of whether or not we should allow IP addresses as=20
path-identities, either YES or NO, please speak up.

YES - IP addresses should be allowed as path-identity.
NO - IP addresses should not be allowed as path-identity.

NOTE: If we disallow IP addresses as path-identities, we will still allow=20
them as "diagnostic data" - nobody's proposed that we should declare=20
articles that have IP addresses in the path as non-conformant. However, if=20
we disallow them, they WILL be disallowed in Injection-info and Xref, which =

are the two other places that use them.

(I'm offline, so can't take out a ticket number on this specific subject.=20
Will do so when I get back online.)

               Harald

--On 5. september 2005 18:30 +0000 Charles Lindsey <[email-masked]>=20
wrote:

> My currently proposed USEPRO text is:
>
>    <Path-identity>s can take the following forms (in decreasing order of
>    preference):
>
>    1. A fully qualified domain name (FQDN) associated with an "A" or
>       "AAAA" record identifying that news-server, or with an "MX" record
>       through which its administrators can be contacted; alternatively
>       an equivalent "CNAME".
>
>    2. An encoding of the public [RFC 1918], permanently routable IP
>       address - <IPv4address> or <IPv6address> [RFC 3986] - of that
>       news-server. This option SHOULD NOT be used if an FQDN for that
>       server is available (however, such IP addresses are perfectly
>       suitable for purely diagnostic identities [reference needed to
>       later section]).
>
>    3. Some other (arbitrary) name believed to be unique and registered
>       at least with all other news-servers sending articles directly to
>       the given one. This option SHOULD NOT be used unless the earlier
>       options are unavailable (e.g. because the server in question is
>       not connected to the Internet), or unless it is of longstanding
>       usage and cessation would be unduly disruptive, or unless one
>       of the earlier options is provided as well.
>

--==========4646CAD4E51D83C262FC==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========4646CAD4E51D83C262FC==========--

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Polll results on injection-info, and some thought on progress
Organization: The Eyrie
Date: Mon, 05 Sep 2005 18:36:02 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Harald Tveit Alvestrand <[email-masked]> writes:

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

>>  No consensus.

> Well at least we have eliminated 3a, 3b and 3c. I.e. there is a problem
> with the present description that needs to be fixed.

> But I have not seen Russ's comment (was it posted here?). May we have some
> explanation of what "fixing upstream" means?

If we're going to use MIME, we should use MIME.  If the current MIME spec
is broken, well, mail client authors are coping, and news client authors
can cope too.  If it's really broken, it can get fixed in a revision of
the MIME specification, which we'd then pick up automatically.

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

To: [email-masked]
Xref: clerew local.usefor:22475
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Mon, 5 Sep 2005 18:30:16 GMT
Lines: 88
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

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

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

>RFC 1958 section 4.1:

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

But who said anything about "requiring addresses to be hard coded"?

Every internet protocol that I can think of (certainly email and URLs)
permits IP addresses in the syntax everywhere that domain-names are
allowed. It then goes on to tell you (with varying degrees of firmness)
that IP addresses SHOULD NOT be used without good cause (but the protocols
MUST still accept them and process them correctly). So indeed, there is no
place where they are REQUIRED to be used, but lots of places where they
MAY be used (subject to varying degrees of discouragement, as indicated).

That is all I am asking for in <path-identity>s. The syntax should
_permit_ them (as it will also for "diagnostic" use). But the semantics
(in USEPRO) will provide strong discouragement (as it will also do for
<bareword>s). My currently proposed USEPRO text is:

   <Path-identity>s can take the following forms (in decreasing order of
   preference):
 
   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record identifying that news-server, or with an "MX" record
      through which its administrators can be contacted; alternatively
      an equivalent "CNAME".

   2. An encoding of the public [RFC 1918], permanently routable IP
      address - <IPv4address> or <IPv6address> [RFC 3986] - of that
      news-server. This option SHOULD NOT be used if an FQDN for that
      server is available (however, such IP addresses are perfectly
      suitable for purely diagnostic identities [reference needed to
      later section]).

   3. Some other (arbitrary) name believed to be unique and registered
      at least with all other news-servers sending articles directly to
      the given one. This option SHOULD NOT be used unless the earlier
      options are unavailable (e.g. because the server in question is
      not connected to the Internet), or unless it is of longstanding
      usage and cessation would be unduly disruptive, or unless one
      of the earlier options is provided as well.

        NOTE: A news-server administrator who chooses a name which turns
        out not to be unique will have to bear the consequences.

        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within any <path-
        identity> which is in the form of an <IPv6address>.  It would
        therefore be unwise to choose, as such a name, anything composed
        solely from four (or less) hexadecimal digits.

[The precise text is up for discussion, of course, and I just noticed that
the mention of MX records may need to be toned down.]

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

Whay I am proposing seems exactly in conformance with that architectural
principle.

>I stand by "idiocy".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22474
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1101 empty body (was: Next steps - please concentrate on USEFOR again)
Date: Mon, 5 Sep 2005 17:25:18 GMT
Lines: 75
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Harald Tveit Alvestrand wrote:

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

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

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

>Add this also to appendix B, differences from 1036 ?

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

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

But no, s-o-1036 is much stronger than that. Here are the relevant bits of
4.3.1:

   The body of an article MAY be empty, although posting agents SHOULD
   consider this an error condition (meriting returning the article to the
   poster for revision). A posting agent which does not reject such an
   article SHOULD issue a warning to the poster and supply a non-empty
   body. ...

     NOTE: ... However, some existing news software is known to react
     badly to body-less articles, hence the request for posting agents to
     insert a body in such cases.

     NOTE: A possible posting-agent-supplied body text (already used by
     one widespread posting agent ) is "This article was probably
     generated by a buggy news reader". ...

The corresponding text in the last of our article-drafts (and indeed in
all of them since I don't know when) was:

   The body of an article SHOULD NOT be empty. A posting or injecting
   agent which does not reject such an article entirely SHOULD at least
   issue a warning message to the poster and supply a non-empty body.
   Note that the separator line MUST be present even if the body is
   empty.

        NOTE: Some existing news software is known to react badly to
        body-less articles, hence the request for posting and injecting
        agents to insert a body in such cases. The sentence "This
        article was probably generated by a buggy news reader" has
        traditionally been used in this situation.

>Reject #1101 ?  Bye, Frank

I think I would like to hear some comment from Henry on this one. It may
be that the "some existing news software" referred to can now be
considered so ancient that we can ignore it - or maybe it can't.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22478
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1093 Email addresses - conclusion
Date: Mon, 5 Sep 2005 19:15:20 GMT
Lines: 34
Sender: [email-masked]

In <[email-masked]> John Stanley <[email-masked]> writes:

>Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

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

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

Harald had said, when giving the results of the poll, than some mention in
USEAGE was not precluded. Acting on that, I therefore wrote some USEAGE
text, prefacing it with the following:

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

It is clearly defined as "tentative". You can disucss it now, if you like
(and as you seem to be doing), but for sure its major scrutiny will come
later. I only wrote it so that we would not lose sight of all the details
that have arisen in the recent discussions.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22476
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path field delimiters and syntax - status
Date: Mon, 5 Sep 2005 18:51:53 GMT
Lines: 42
Sender: [email-masked]

In <[email-masked]> [email-masked] (Kai Henningsen) writes:

>[email-masked] (Henry Spencer)  wrote on 24.08.05 in <[email-masked]>:

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

>But those "most basic sanity checks" are - from what you say - exactly the  
>same as NNTP does.

AIUI, most news servers (including INN and CNews) provide two interfaces:

'inews' - please inject this article (does some rather thorough format checks);
'rnews' - please relay this article (does the minimum amount of checks
          that it can get away with).

"minimum amount" probably includes the basic NNTP requirements
(essentially that the header fields can be separated out) and also enough
to disentangle the headers it needs to look at (which is most of the
mandatory ones).

OTOH, if the 'rnews' is also going to store the article locally (it is
then a serving agent as well as a relaying agent), then it probably needs
to do somewhat more (indeed USEPRO says it MUST).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22477
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Polll results on injection-info, and some thought on progress
Date: Mon, 5 Sep 2005 19:01:25 GMT
Lines: 59
Sender: [email-masked]

In <4908E0CCAE17394C8BEB2BF7@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>On this poll, the results are:

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

>  No consensus.

The usual practice in that case is that the status quo remains. I.e. we
retain what we currently have (modulo further tuning).

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

>  No consensus.

Well at least we have eliminated 3a, 3b and 3c. I.e. there is a problem
with the present description that needs to be fixed.

But I have not seen Russ's comment (was it posted here?). May we have some
explanation of what "fixing upstream" means?

>4) SHOULD THE FIELD ALLOW RFC 2231 CONSTRUCTS?
>  4a) Yes
>      Charles Lindsey, Russ Allbery
>  4b) No
>  4c) Something else
>      Frank Ellermann (langtags in encoded-words only)

>  A tendency towards "yes".

In which case we should be discussing whether we allow it, but make
discouraging noises (mainly about the multi-line stuff, and probably in a
NOTE).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
Xref: clerew local.usefor:22473
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Looping without injection-date? (Re: Meta-level thought: Expectations of interworking?)
Date: Mon, 5 Sep 2005 17:09:09 GMT
Lines: 32
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

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

>Yup.

OK, I have written the following paragraph into my current USEAGE text. I
will happily accept comments on it now, but otherwise it can be looked at
again when we get around to serious USEAGE discussion.

   For the purpose of preventing slowly propagating articles from being
   accepted a second time by agents from which they had already expired,
   [USEPRO] requires that a relaying agent reject as "stale" articles
   which predate "the earliest articles of which it normally keeps
   record". To this end, relaying agents SHOULD keep record of all
   articles received for at least 7 days.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Polll results on injection-info, and some thought on progress
Date:  Mon, 05 Sep 2005 07:53:11 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 46
Sender: [email-masked]

[...]
> Actually I started to miss your weekly "open ticket"
> summary, and considered to create / post a new version

It's apparently down again, only the http-intro works
from my POV <http://rt.psg.com> - not the https pages.

Ticket states as I remember them:

#1046 2822/2231 MIME security considerations was "text
needed" but could be "text proposed". 

????? date-ABNF:  typo in 3.1.2, s/from/orig-date/

????? Path:  Use Harald's idea "name required" to get
rid of IP problems (BTW, 2821bis proposes HELO FQDN,
plus SHOULD NOT <address-literal> crap only for EHLO)

????? Path:  Finish the "diagnostic" syntax, and for
perfectionists maybe split FQDN (dots, toplabel, no
underscore) from name (no dots, underscores are okay) 

????? Message-ID:  last state 3:3:1 for <id-right> vs.
<id-domain> vs. 2822-is-fine (= Bruce).  That's 6:1
if the production names are ignored.

????? Differences from 1036:  use texts as posted in
the corresponding thread.

#1101 empty body: no support, one proposal to reject

#1102 terminology: use UA vs. server in USEFOR (Russ
didn't like it, but it's a minor editorial point, no
showstopper)

----- (no ticket):  Ask Henry to publish s-o-1036 as
FYI (or directly as historic like 4156 and 4167 - the
latter strategy might need a "last call", unclear)

Anything else excl. the known Injection-Info issue ?

                        Bye, Frank

#1101: http://permalink.gmane.org/gmane.ietf.usenet.format/29979 
#1046: http://permalink.gmane.org/gmane.ietf.usenet.format/29552

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Polll results on injection-info, and some thought on progress
Date:  Mon, 05 Sep 2005 06:40:36 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 55
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> I can certainly believe tiredness.

Yes.  Actually I started to miss your weekly "open ticket"
summary, and considered to create / post a new version, but
Charles said he's away for some days, therefore I picked
something else on my "todo" list (2821bis ABNF).

> In terms of value for energy spent, closing the group may
> be a better alternative.

While that's an option I'd hate it if the Injection-Info
makes it as USEFOR-showstopper:

> 1a) No, we should keep approximately the current syntax
>     Charles Lindsey
> 1b) Yes, we should pick a substantially different solution
>     Frank Ellermann
[...]
>   No consensus.

That's a strange result, I wanted to support Bruce's idea.

Without the proponent (Bruce) that makes no sense.  Unlike
the Message-ID syntax I don't have any "different solution"
for Injection-Info (or rather my own proposal didn't work
as expected).

Bruce and Charles claim to have something that works.  If
Bruce isn't interested anymore to work out the details I'm
forced to withdraw my "1B".  What you then get is Charles
for "1A", whatever that is, at least it's not "no consensus".

> 2b) A single header field with a syntax different from
>     the "name=value" syntax
>     Frank Ellermann, Charles Lindsey, Russ Allbery

>   Perfect consensus.

If we'd follow Bruce's idea, we'll follow Bruce's idea ;-)
For a "perfect consensus" I miss at least Bruce here.

The weird Injection-Info shouldn't be the reason to close
the WG.  Compared with <id-domain> vs. <id-right> it's
not relevant enough, above all it's new, we could also
move it to a separate document (even "experimental").

That is an excessively cowardly idea, but if the WG fails
after what - six (?) - years that should be for a solid
reason like "2822 considered too broad for news by some
but not all", not "2231 considered too gibbous for news".

                        Bye, Frank

Date: Mon, 05 Sep 2005 02:54:49 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Polll results on injection-info, and some thought on progress
Sender: [email-masked]

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

OK, here's our result on injection-info.
A total of 3 people answered. Possible conclusions:

- The rest doesn't really care about this bit
- The group is tired and doesn't want to form more opinions

I can certainly believe tiredness. I did not make the timeline I suggested, =

and have severely underestimated the amount of time and energy it takes me=20
to get even proposed closure on issues.
In terms of value for energy spent, closing the group may be a better=20
alternative.

But I'll make one more round of trying to close things.

On this poll, the results are:

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

  No consensus.

2) IF SUBSTANTIAL CHANGES ARE MADE, WHAT FORM SHOULD IT BE?
  2a) Multiple header fields
  2b) A single header field with a syntax different from
      the "name=3Dvalue" syntax
      Frank Ellermann, Charles Lindsey, Russ Allbery

  Perfect consensus.

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

  No consensus.

4) SHOULD THE FIELD ALLOW RFC 2231 CONSTRUCTS?
  4a) Yes
      Charles Lindsey, Russ Allbery
  4b) No
  4c) Something else
      Frank Ellermann (langtags in encoded-words only)

  A tendency towards "yes".

--==========4D56A7C1E62D35512DD8==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========4D56A7C1E62D35512DD8==========--

Date: 03 Sep 2005 14:21:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: #1047 Path field delimiters and syntax - status
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Richard Clayton)  wrote on 02.09.05 in <[email-masked]>:

> In message <[email-masked]>, Kai Henningsen
> <[email-masked]> writes
> >
> >[email-masked] (Richard Clayton)  wrote on 21.08.05 in
> ><jr6LcRfMrKCDFARx @highwayman.com>:
> >
> >> The algorithm was to start from 'news.maxwell.syr.edu' and see if any
> >> article arrived that had been given any articles by this machine. If so
> >> then they were added to the core and a check made to see if there were
> >> now other machines to which articles had been given...  iterate.
> >
> >To get an impression of how fully you saw the periphery of the net, can
> >you tell me how many (or which) westfalen.de machines you found?
>
> core path identities (I've no idea what a "machine" is)
>
>         colo.khms.westfalen.de
>         silvana.westfalen.de
>         westfalen.de
>
> other path identities that sent messages to machines in the core
>
>         dl6dx.westfalen.de
>         ripley.westfalen.de
>         news.khms.westfalen.de
>
> recall that this was July->October 2004

Those are in fact all different machines :-) (khms.westfalen.de would be  
the same as news.khms.westfalen.de, but you don't list it.)

I wouldn't have expected to see any of those in "core" ... on the other  
hand, I'd have expected to see khms.westfalen.de in the lower group; I  
certainly posted quite some articles during that time!

MfG Kai

Date: Fri, 2 Sep 2005 17:34:44 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1047 Path field delimiters and syntax - status
Sender: [email-masked]

In message <[email-masked]>, Kai Henningsen
<[email-masked]> writes
>
>[email-masked] (Richard Clayton)  wrote on 21.08.05 in <jr6LcRfMrKCDFARx
>@highwayman.com>:
>
>> The algorithm was to start from 'news.maxwell.syr.edu' and see if any
>> article arrived that had been given any articles by this machine. If so
>> then they were added to the core and a check made to see if there were
>> now other machines to which articles had been given...  iterate.
>
>To get an impression of how fully you saw the periphery of the net, can  
>you tell me how many (or which) westfalen.de machines you found?

core path identities (I've no idea what a "machine" is)

        colo.khms.westfalen.de
        silvana.westfalen.de
        westfalen.de

other path identities that sent messages to machines in the core

        dl6dx.westfalen.de
        ripley.westfalen.de
        news.khms.westfalen.de

recall that this was July->October 2004

- -- 
richard                                              Richard Clayton

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

Date: 02 Sep 2005 12:22:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: #1047 Path field delimiters and syntax - status
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Richard Clayton)  wrote on 21.08.05 in <[email-masked]>:

> BTW: Usenet is not all that big -- I identified 2556 servers as being
> part of a "peering core" (from my vantage point). The other 8500
> machines were merely feeding into that core.
>
> The algorithm was to start from 'news.maxwell.syr.edu' and see if any
> article arrived that had been given any articles by this machine. If so
> then they were added to the core and a check made to see if there were
> now other machines to which articles had been given...  iterate.
>
> Looking now at those 2556 servers -- which are, at least from my vantage
> point, somewhat more important than the rest -- I find that 218 of them
> have chosen to use an identity that is a bare word, and I'd say that
> half of those look to be UUCP names.

To get an impression of how fully you saw the periphery of the net, can  
you tell me how many (or which) westfalen.de machines you found?

MfG Kai

Date: 02 Sep 2005 11:26:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: #1047 Path field delimiters and syntax - status
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Henry Spencer)  wrote on 24.08.05 in <[email-masked]>:

> On 24 Aug 2005, Kai Henningsen wrote:
> > But if you're doing news propagation and the intermediate site is supposed
> > to see the article, it goes through rnews - which, in the case of INN,
> > does NNTP, I believe, though not necessarily over IP, and thus certainly
> > checks. I expect C news did similar stuff.
>
> C News went the opposite route:  where all INN's incoming paths ultimately
> go via NNTP, all of C News's ultimately went via a disk spool area (very
> much in the style of UUCP).  The injection path did rigorous checking and
> fixups (e.g. adding Date) on user-posted articles before dropping them in
> the spool area.  The UUCP and NNTP incoming paths dropped data in the
> spool area without examining it.  The server/relayer code picked up from
> the spool area, and for speed, did only the most basic sanity checks --
> superficial parse of all the headers, check for presence of mandatory
> headers, detailed parse only for headers it actually cared about.

But those "most basic sanity checks" are - from what you say - exactly the  
same as NNTP does.

MfG Kai