[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri July 1 2005 15:50, Charles Lindsey wrote:
> 
> In <200506301058.13924.blilly@xxxxxxxxx> Bruce Lilly <blilly@xxxxxxxxx> writes:

> >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.
> 
> The procedures for constructing a Path entry are contained in my suggested
> USEPRO text posted here a week or so ago. It makes it clear exactly where
> and when those two keywords may appear, so it is hardly necessary to
> complicate the syntax with such matters (and there is no particular need
> for agents to take note of those keywords when parsing).

We *could* simply say
 path = "Path: " *text CRLF
but that would hardly provide clarity about what is in the field.  There
are two related issues:
1. the text appears to be wrong about the description, particularly w.r.t.
   MISMATCH
2. the ABNF should be consistent with the text, and should work with the
   text to provide a *clear* specification

> >>   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.
> 
> 
> >Because of the backward compatibility/interoperability problem
> >s/should/MUST/.
> 
> No, because there are plenty of hosts around that have IP addresses but no
> domain name. The text proposed for USEPRO makes it clear that IP addresses
> are the least desirable alternative.

That goes against Harald's "diagnostic stuff" suggestion.  A host with
an IP address but no domain name could, I suppose, concoct one in
in-addr.arpa.  The big problem is that many IP addresses are not unique,
and I suspect that the ones with unique ones have a domain name, especially
if they're running a news server, if for no other reason than to comply
with RFC 2142.  *If* they have no other choice, then that would meet the
"when absolutely necessary" condition, so there's no problem with MUST.