xri message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Thoughts on IP addresses for identifier authorities
- From: "Wachob, Gabe" <gwachob@visa.com>
- To: "'xri@lists.oasis-open.org'" <xri@lists.oasis-open.org>
- Date: Mon, 21 Jul 2003 16:22:04 -0700
Hi all (esp.
editors)-
I
want to spell out what the meaning of an IP address is in the context of a
authority, because I'm not sure its entirely obvious to every one.
I
assume that the IP address specifies a local access endpoint. An IP address will
always constitute the entire authority identifier (ie you aren't going to add
more parts of the authority identifier after the IP address -- this would be
confusing and breaks the BNF). Thus, there's no reason not to interpret the IP
address as the endpoint for local access.
OK, so the question becomes then what sort of protocol to use with this
endpoint. Normally, one of the byproducts of resolution (even with DNS-specified
authorities) is not only the IP address (or URI) of a local access service, but
the protocol performed at that local access endpoint. With IP addresses (which I
see, frankly, as a degenerate case, btw), we don't have that extra
info.
My proposal is to simply say that if you use an IP address for an authority
(which means you are really not using any authority at all), you basically
require the user to do local access with the "default" local access protocol. I
suggest that default protocol be "thttp" (as defined in the spec), but I'm open
to other ideas. Even just saying "must use xri's thttp" isn't quite enough -
there's more to narrow down the absolute "default" local access protocol, but
thats not a major point.
Input welcome. I'd even consider a negotiation protocol. That is, a
resolver, given only an IP address, would negotiate with that IP address somehow
to discover whats available at that endpoint. Thats against the grain of
resolution which provides the type of protocol as part of resolution... The
model I've taken is that negotiation is relatively inefficient and we don't want
to assume that overhead all the time (and it could be a little complicated to
specify).
-Gabe
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]