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

[Bruce Lilly <blilly@xxxxxxxxx>]

On Wed June 29 2005 08:33, Harald Tveit Alvestrand wrote:
>   A path-identity identifies an agent. For the news system to work
>   properly, the path-identity must be globally unique.

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

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

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

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

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

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

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

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

> 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).
-------------------------------------
> Message-ID: <DBD861979EC6EF845F72B90A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> In-Reply-To: <42C2A7B7.3993@xxxxxxxxxxxxxxxxx>
> References:  <B1567455A8003F858BE0F033@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>  <42C2A7B7.3993@xxxxxxxxxxxxxxxxx>
[...]
> --On onsdag, juni 29, 2005 15:52:55 +0200 Frank Ellermann 
> <nobody@xxxxxxxxxxxxxxxxx> wrote:
[...]
> > Doesn't change the dead:beef:cafe:: problems, [ and ] are also
> > punctuation in 1036.
> 
> 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.

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  
> discussion has shown that [] doesn't make the problem worse, so I see 
> little argument for not using them if we use them elsewhere.

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