RE: [xri] Thoughts on IP addresses for identifier authorities

["Drummond Reed" <drummond.reed@onename.com>]

Gabe,

Thanks for putting this question to rest - I wasn't sure how the
simplified resolution protocol changed the question.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Monday, September 15, 2003 8:50 AM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Thoughts on IP addresses for identifier authorities

Drummond-
        Your response is now out of date ;-)

        The current proposal is to simply convert an XRI using a DNS or
IP address as the authority into a HTTP URI and perform a (GET?) on that
URL using the "local" part of the XRI as the "relative" part of the HTTP
URI (after having been escaped).

        So its very much simpler, at the expense of complete
flexibility.

        -Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@onename.com]
> Sent: Sunday, September 14, 2003 11:50 AM
> To: Wachob, Gabe; xri@lists.oasis-open.org
> Subject: RE: [xri] Thoughts on IP addresses for identifier authorities
>
>
> Gabe, I missed this message when I was gone on vacation this
> summer but
> reread it this weekend and think it is an important point to
> clarify in
> the text of the spec itself.
> 
> Here's what I think you are asking: "In the case of the URI authority
> section of an XRI being an IP address, and thus their being
> no inherent
> resolution or local access protocol (such as DNS or HTTP) for the
> authority, what should the XRI specification say the default
> resolution
> or local access protocol is?"
> 
> And what I think you are proposing is, "THTTP, as defined in the XRI
> resolution spec."
> 
> 1) Am I correct?
> 2) Does this change based on your new simplified resolution protocol?
> 
> =Drummond
> 
> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Monday, July 21, 2003 4:22 PM
> To: 'xri@lists.oasis-open.org'
> Subject: [xri] 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
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/xri/members/leave
> _workgroup.php.
>