Subject: #1047 Path-identity: A proposal (perhaps)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 29 Jun 2005 14:33:30 +0200

At the moment, it seems that we're at an impasse partially caused by our 
documents' failure to explain what a "path-identity" is. I don't know if I 
understand it either....

At the moment, the specific format and use of path-identity is punted to 
USEPRO, where it seems to be still undefined.

If we explained it, would this be a reasonable text to insert in 3.1.6?
(I've modified the BNF too. Only modified stuff included here)
--------------------------------------------------------------------
  A path-identity identifies an agent. For the news system to work
  properly, the path-identity must be globally unique.
  Traditional usage has had two means of generating unique identifiers:
  DNS names and asserted identities. The first gets its uniqueness from
  the DNS; the second gets its uniqueness from tradition. New servers
  should use DNS names.

  In some cases, one wishes to embed something into a path-entity that
  is not a name. One common thing to embed is an IP address, serving
  as an identity when the name of the agent is not known.

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

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

   path-keyword    = "POSTED" / "MISMATCH"

   path-address    =  IPv4address / no-fold-literal ; see [RFC2373]

  NOTE: The path-address contains characters that some systems consider
     path-delimiters. This can cause problems; path-address should
     therefore only be used when absolutely necessary.
     See [USEPRO] for details on when to use them.
--------------------------------------------------------------------

Note that in recycling no-fold-literal, I've added [] around addresses... 
and that a naked IPv4 address is allowed separately, because people have 
said this is already present (too much for us to remove).

Does this make sense?

                      Harald

---

From: Richard Clayton <[email-masked]>
Date: Wed, 29 Jun 2005 14:00:26 +0100

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

> the DNS; the second gets its uniqueness from tradition. New servers

Not terribly important, but since the majority of the traditional names
that occur in the "middle" of paths derive from UUCP (the ones at the
ends are more of a mixture, but still mainly UUCP) could we change the
second sentence to finish...

...  "gets its uniqueness from tradition, mainly from when articles were
carried over UUCP."

which at least gives a clue (something to Google on) as why the
tradition arose and why it is no longer sustainable.

- -- 
richard                                              Richard Clayton

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

---

From: Henry Spencer <[email-masked]>
Date: Wed, 29 Jun 2005 09:26:08 -0400 (EDT)

> If we explained it, would this be a reasonable text to insert in 3.1.6?

Looks reasonable to me...

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 29 Jun 2005 15:52:55 +0200

> path-address = IPv4address / no-fold-literal ; see [RFC2373]

s/2373/3986/

> recycling no-fold-literal, I've added [] around addresses...

Doesn't change the dead:beef:cafe:: problems, [ and ] are also
punctuation in 1036.
                        Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Wed, 29 Jun 2005 10:41:06 -0700

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

> documents' failure to explain what a "path-identity" is. I don't know if
> I understand it either....

> (I've modified the BNF too. Only modified stuff included here)

This looks okay to me.

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 30 Jun 2005 09:21:43 +0200

> Doesn't change the dead:beef:cafe:: problems, [ and ] are also

no, the only improvement from my proposed text with dead:beef:cafe is that 
we isolate new-weird-characters like [:] to "diagnostic stuff" - we don't 
write anything that lets sites name themselves dead:beef. And I think 
discussion has shown that [] doesn't make the problem worse, so I see 
little argument for not using them if we use them elsewhere.

There are only 3 ways I see to get rid of the : character:

- Stop putting domain-literals in Path: at all (seems unacceptable)
- Encode IPv6 addresses differently (seems unacceptable)
- Treat IPv6 and IPv4 differently (seems unacceptable)

If you've eliminated the impossible, what you're left with.....

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 10:58:12 -0400

>   properly, the path-identity must be globally unique.

If we mean "public name" we should probably say so: s/identifies/is a
public name identifying/

Global uniqueness is an interoperability requirement ("to work properly");
s/must/MUST/ would make that clear.

>   the DNS; the second gets its uniqueness from tradition. New servers

Because of the global uniqueness requirement, s/should/MUST/.  Add
something to address Frank's concern about unauthorized use.

>    path-keyword    = "POSTED" / "MISMATCH"

The ABNF implies that
  Path: MISMATCH!tail-entry
and
  Path: MISMATCH!MISMATCH!tail-entry
are legal, which I believe is not the intended use of the keywords. I
believe that the intent would be conveyed by changing the naked
"path-keyword" in the path-list rule by
  (path-keyword [FWS] path-delimiter [FWS] (path-identity/path-address))
If I understand the "some cases" argument correctly, the only place an
IP address literal should appear would be after a MISMATCH keyword and
delimiter.  If so, the ABNF could be further revised (simplified) to
so indicate.  There are other issues; the ABNF indicates that
  Path: POSTED!tail-entry
and
  Path: POSTED!!tail-entry
and
  Path: POSTED!!MISMATCH!tail-entry
are legal, and that also conflicts with the text.  I believe that the
ABNF can be fixed (and I'm willing to try), but first we need to reach
some consensus on where an IP address literal is and is not permitted.
Likewise for "POSTED" and "MISMATCH" (USEFOR currently defers to USEPRO,
which mentions neither).

>    path-address    =  IPv4address / no-fold-literal ; see [RFC2373]

RFC 2373 has been obsoleted by RFC 3513.  Obviously ("sometimes...")
RFC 3513 would be a *normative* reference.  However...

Neither RFC 2373 nor 3513 defines or uses "no-fold-literal".

While RFC 2373 had ABNF for "IPv4address" in an Appendix, RFC 3513
defines it nowhere and contains no ABNF.

RFC 2821 has ABNF for "IPv4-address-literal" and "IPv6-addr", which
might be useful.  If I understand yesterday's discussion correctly,
there will already be a normative (obviously) reference to RFC 2821.
Neither production permits CFWS.  I suggest using the aforementioned
2821 ABNF productions:
  path-address = IPv4-address-literal / ( "[" IPv6-addr "]" ) ; [RFC2821]
(but see below regarding brackets).

>      See [USEPRO] for details on when to use them.

s/some systems/systems conforming to the previous specification/
(modulo bracket issues, which go away if the brackets go away; see below)
s/contains/may contain colon and bracket/
("may" because an IPv4address certainly contains no characters which
are interpreted as delimiters; the remainder to clarify the issue -- but
again, see below regarding brackets)

Because of the backward compatibility/interoperability problem
s/should/MUST/.

> said this is already present (too much for us to remove).
-------------------------------------
> Message-ID: <[email-masked]>
> In-Reply-To: <[email-masked]>
> References:  <[email-masked]>
>  <[email-masked]>
[...]
> <[email-masked]> wrote:
[...]
> write anything that lets sites name themselves dead:beef.

I think such naming is a red herring.  Good riddance to the possibility,
but it's not the major concern (it's covered by "use DNS names" in any
event).  The issue of interpretation of IPv6 address literal
colon-separated components as path identities remains an
interoperability problem.  We can defer detailed discussion to USEPRO,
but let's be clear that it is an interoperability problem which can
cause articles to fail to propagate properly and use BCP 14 imperatives
accordingly.

> And I think  

I've seen no discussion of brackets on list in response to the proposed
change, other than Frank's comments...

Brackets are not explicitly named in RFC 1036 and are not in the set of
"punctuation" characters used by the RFC 1036 authors in B news 2.11.
Obviously, B news does not treat brackets as delimiters.  C news does.
INN does, according to Russ' 1999-06-19 message.

Bracket characters bracketing an IPv6-addr don't appreciably change
the situation one way or the other; eliminating the brackets or changing
"[" to "@!:^%" wouldn't affect C news or INN.  The characters add to
the length, that's about it.  The only thing I can see in favor of
retaining them it that they would prevent any B news implementations
or others using B news compatible code from misinterpreting the IPv4 part
of a hybrid literal (because B news doesn't treat brackets as delimiters
and "123.45.67.89" differs from "123.45.67.89]"), but then depending
on the (possibly compressed) hex part of the hybrid, treating the IPv4
part as different might be the wrong thing to do.  I'd prefer to lose
the brackets, since they're an unnecessary difference between treatment
of IPv4 and IPv6, seem to simply add length, and are not strictly part
of the RFC 1036 specification (which would complicate wording regarding
the backward compatibility issue).

2005-06-30:3

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Jun 2005 19:47:58 GMT

>  as an identity when the name of the agent is not known.

Hmmm! That looks more of a USEPRO matter. Indeed there is that and much
more in USEPRO, and I wanted it put in USEFOR, but Alexey told me it did
not belong there. So please can we be as brief as possioble in USEFOR, and
point to USEPRO for the gory details (see below)

>   path-address    =  IPv4address / no-fold-literal ; see [RFC2373]

A good idea, but the term <path-identity> needs to include everything that
may occur in the list, except the two keywords, because it is used with
that meaning in many places. So it would be better as:

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

   path-identity   =  ( ALPHA / DIGIT )
                         *( ALPHA / DIGIT / "-" / "." / "_" ) /
                      IPv4address / IPv6address ; see [RFC 3986]

>  NOTE: The path-address contains characters that some systems consider
                                                       ^
                                                    legacy
>     See [USEPRO] for details on when to use them.

However, that is better said in USEPRO. Moreover, it is only the ":" in an
<IPv6address> that is problematical, so that is the only case to mention
explicitly.

>said this is already present (too much for us to remove).

Yes, but you have also brought in a whole lot of other things, including a
further bunch of former <path-delimiter>s (even "!").

Moreover, current practice has been not to include [...] around IP
addresses when used in <path-identity>s, and "[" and "]" were also
<path-delimiter>s in the old days (though not so harmful in this
particular context). Hence I have reverted to <IPv6address> in my revised
syntax.

Here, now, is the text currently proposed for USEPRO. Maybe we should
review it now; there are several things that have come up in recent days
which maybe ought to go into it.

   News-servers need to identify themselves, by inserting their <path-
   identity>s (F-3.1.6), into Path, Injection-Info and Xref headers. An
   injecting agent MUST identify itself with the same <path-identity> in
   both Path and Injection-Info headers.  To ensure that a <path-
   identity> provides a unique identity for the news-server concerned,
   it SHOULD be one of:

   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record, which SHOULD identify the actual host inserting
      this <path-identity> and, ideally, should also be "mailable" (see
      below).

   2. A fully qualified domain name (FQDN) associated with an "MX"
      record, which MUST be "mailable".

   3. An arbitrary name believed to be unique and registered at least
      with all other news-servers receiving articles directly from the
      given one.

   4. An encoding of an IP address - <IPv4address> or <IPv6address> [RFC
      3986].

   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@<FQDN>" and
   "news@<FQDN>", in conformity with [RFC 2142].

   For an injecting agent prepending to a Path header (7.2.2), the
   <path-identity> MUST be option 1 or 2 and the FQDN MUST be mailable,
   and if the agent offers its services to the general public the form
   "abuse@<FQDN>" MUST also be available, unless a more specific
   complaints address has been provided in a <complainto-param> of an
   Injection-Info header (F-3.2.14).  For other agents, options 1
   through 3 are to be preferred.

>Does this make sense?

Not yet :-(

-- 
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: Frank Ellermann <[email-masked]>
Date: Thu, 30 Jun 2005 23:44:56 +0200

Charles Lindsey wrote:

> So please can we be as brief as possioble in USEFOR, and
> point to USEPRO for the gory details

Hear, hear!  SCNR

> the term <path-identity> needs to include everything that
> may occur in the list, except the two keywords

...or the <tail-entry>.

> So it would be better as:
[...]

ACK.

> Here, now, is the text currently proposed for USEPRO.
[...]

>| To ensure that a <path-identity> provides a unique identity
>| for the news-server concerned, it SHOULD be one of:

How about "it MUST be" ?  Or even simply "it is" ?!?
[...]

>| The FQDN of a news-server is "mailable" if its
>| administrators can be reached by email using both of the
>| forms "usenet@<FQDN>" and "news@<FQDN>", in conformity
>| with [RFC 2142].

Maybe say 'forms "usenet@" and "news@" at the FQDN represented
by the <path-identity>, in conformity with [RFC 2142].'  Issue:
I'm not sure about using <FQDN> if that's no term in the ABNF.

>| "abuse@<FQDN>" MUST also be available

Dito, '"abuse@" address MUST' etc., if your <FQDN> doesn't fly.

> Not yet :-(

Getting much better, limiting ":" to IPv6 is a step forward.

Some of Bruce's points are not yet covered, MISMATCH!MISMATCH
etc., maybe we have to declare these beasts as special cases
of a path-delimiter, brain-storming:

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

 path-delimiter = "!" / "!!" / "!MISMATCH!" / "!POSTED!"

No more path-keyword.  Does that solve Bruce's problem ?  Bye

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 19:14:35 -0400

> No more path-keyword.  Does that solve Bruce's problem ?  Bye

That still permits foo!!tail-entry, foo!MISMATCH!tail-entry, and
doesn't address (no pun intended) where IP address literals are or
are not allowed.

I made some quick notes this morning:
path-identity "!POSTED" needs to be a group
path-identity "!!" path-identity needs to be a group
"MISMATCH!" path-identity needs to be a group 
based on the text description following the ABNF in the usefor draft.
That text (and the draft ABNF) implies that
  Path: MISMATCH!example.net!tail-entry
is a valid complete field, which might not be what is intended; the
text doesn't say that there needs to be anything to the left of
MISMATCH.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Jul 2005 02:51:13 +0200

Bruce Lilly wrote:

> That still permits foo!!tail-entry, foo!MISMATCH!tail-entry

Yes, and I wasn't consequent with the [FWS], next attempt:

 path-list      = [FWS] path-identity [FWS]
                  *( path-delimiter [FWS] path-identity [FWS] )
                  ( "!" [ "POSTED!" ] ) [FWS] tail-entry [FWS]

 path-delimiter = "!" [[ "MISMATCH" / "POSTED" ] "!" ]

That's a bit convoluted, maybe a simple list of delimiters is
better, see above: 
                  ( "!" / "!POSTED!" ) [FWS] tail-entry [FWS]

> doesn't address (no pun intended) where IP address literals
> are or are not allowed.

It was based on Charles' revised syntax for a <path-identity>:

| path-identity = ( ALPHA / DIGIT )
|                 *( ALPHA / DIGIT / "-" / "." / "_" ) /
|                 IPv4address / IPv6address    ; see [RFC 3986]

> path-identity "!POSTED" needs to be a group

Okay, path-identity "!POSTED!" tail-entry catches the normal
case, path-identity "!POSTED!" path-list is for reinjection.

> path-identity "!!" path-identity needs to be a group

Also okay, I have path-identity "!!" path-list, and no way to
combine it with a tail-entry.

> "MISMATCH!" path-identity needs to be a group

Dito as path-identity "!MISMATCH!" path-list, not with a tail.

> is a valid complete field, which might not be what is
> intended; the text doesn't say that there needs to be
> anything to the left of MISMATCH.

Then it was wrong, "!MISMATCH!" is the same idea as "!!", only
for a mismatch.  In my hardcore nitpicking mode it should be:

path-identity "!" path-identity "!MISMATCH!" path-list

a!b!MISMATHCH!c!...!not-for-mail as in "I got this starting
with c!... but I think it should be b, anyway I am a, enjoy".

Or should this be a!!b!MISMATCH!c!...!not-for-mail (?)  Bye.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 30 Jun 2005 21:49:12 -0400

> |                 IPv4address / IPv6address    ; see [RFC 3986]

That's inconsistent with Harald's "diagnostic stuff".

> for a mismatch.  In my hardcore nitpicking mode it should be:

I guess it's up to somebody who cares for the newfangled "feature"
to open a ticket proposing a specific text change...
 
> Or should this be a!!b!MISMATCH!c!...!not-for-mail (?)  Bye.

Good question; sounds reasonable to me.  Anyway, I'm waiting  for
resolution of the issues before ABNF-wrangling.