OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Thoughts on IP addresses for identifier authorities


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]