Re: Allowing IP addresses as path-identiites

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <431EE800.5000007@xxxxxxxxxxxxxxx> "Forrest J. Cavalier III" <forrest@xxxxxxxxxxxxxxx> 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: chl@xxxxxxxxxxxxxxxx      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