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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

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


Subject: FW: Working on our XRI resolution section


Shame on me for keeping this offlist!

	-Gabe




Peter-
	I've been thinking more about this and I wanted to talk about a couple of local access protocol options. 

	I've been thinking a lot about the lightweight end of things, specifically about a local access protocol that was HTTP based, looking (or being) something like RFC 2169 (the trivial HTTP-based protocol for URN resolution). We'd like to be able to resolve an XRI into something like a WS-Addressing EndpointReference (http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-addressing.asp ) .. That is, at the end of the local access protocol, I'd like to have a particular type of XML document. This document could plug into RFC 2169 as a the output of a I2C conversion. The thing is, I think every application may want a different type of data as a result of a resolution. Some may just want mappings to other URIs (I2I), some may want "data" (I2C), etc. Also, I think language is something that may need to be specified (don't know). So, an HTTP based protocol could specify using HTTP language and HTTP "content-type" headers in the request (of the local access protocol) to specify exactly what is wanted by the resolver. (this is akin to a DNS resolver specifying an A-record query vs. a MX-record query vs. an ANY query). 

	I mentioned WS-Addressing EndpointReferences as potential resolution outputs, but WSDL, WSIL, RDDL, or even something custom might be appropriate, at least for documents which "describe" an XRI. Again, though, whatever comes out of resolution is something I want to be something we don't hardcode, but rather something we specify a way for the client and server of the local access protocol to specify between themselves. 

	The outcome of all this is that we could specify RCFC 2169 as a local access protocol, and further specify using the HTTP headers I mentioned above to allow more refined querying. I'd like to hear what you think about that (I have some reservations, but it feels sorta right). 

	Another local access protocl that we've talked about inside Visa is LDAP. Seems natural, widely deployed, etc. I'd be curious to hear others you might think about.

	Now, as to your specific thoughts:

* addressing/trust/authoritative servers - maybe this is part of the "local access protocol"? maybe the way you query the assertions associated with a naming authority is to use some special relative XRI (ie if the naming authority is xri://a.b.c, then you get the assertions associated with the naming authority by performing the local access protocol at xri://a.b.c/(+assertions) or something like that). The other option is to require that the local access protocol provide a protocol-specific means of querying assertions about authenticity, etc. 

* As for "several" (>2) local access protocols - if you can think of pre-existing "access" specs (loosely defined) that would fit in here, great. I think we at least have to define the functionality a local access protocol *has* to provide (limited read), and what it *can* provide (ie write, access-controlled read/write, etc). Even plain ole HTTP is a local access protocol (even outside RFC 2169) if we define "local access protocol" in one way. 

- My assumption is that the modal use of the local access protocol is to interact with representations (ie attributes) of a "resource". So when I connect to a LDAP system during the local access protocol, I'm assuming I have not identified the LDAP system, but rather something described in the LDAP system. Thus, "non-network" resources are explicitly (and specifically) designed for. I think the ability to address networked resources (ie servers, network components) can also be done with this "two-phase" resolution process - the second phase (the "local access" part) may simply be a traditional network protocol (eg SNMP)? Don't quite know. 

- As for language (of the querier), I think this becomes part of the "information set" of every query. That is, for the underlying protocols (e.g. HTTP local access), there should be a way of specifying these things (e.g. HTTP language headers). I'm not sure how this would work with NAPTR-style DNS queries.. 

- As for "version" negotiations - version of what? version of the resource? is this something we have to bake into resolution? Are we talking about discovery or just the ability to say something like "give me version x or newer"? 

Lots of good stuff! I'm hoping we can leverage a lot of current work out there and not have to invent new protocols... 

	-Gabe

> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Tuesday, May 27, 2003 9:17 AM
> To: Wachob, Gabe
> Subject: Re: Working on our XRI resolution section
> 
> 
> Pretty close, i think, to a working model.  a couple of thoughts:
> 
> - addressing trust and authoratative status of a resolution node, is 
> itself, a metadata query on the xri identifying the authority node
> - we should consider profiling several "local protocols" (eg: 
> more than 2)
> - consider cases where the xri may not resolve, or the identitifer is 
> not something one can interact with over a network (eg: 
> abstract xri's 
> such as "cars", or "SUV"s)
> - consideration for version and language negotions within 
> resolution itself.
> 
> I'm sure there are more... but this is a good start.
> 
> --- peterd
> 
> 
> Wachob, Gabe wrote:
> 
> > Peter-   
> >     What is your feeling about using the "resolution architecture" 
> > proposal text I emailed to the list as a starter for the 
> resolution spec?
> >  
> >     For your convenience:
> > http://lists.oasis-open.org/archives/xri/200305/msg00019.html
> >  
> >     -Gabe
> 
> 




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