Re: [xri-editors] FW: Working on our XRI resolution section

[Peter C Davis <peter.davis@neustar.biz>]

>
>
>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). 
>  
>
Typically, however, HTTP useragents do not request content-type, they 
are told what content-type to expect in the forthcomming response.  
DDDS, i think, provides better mechanics here (I2C+metadata, 
I2C+synonyms, I2I+wsdl, etc...).  This allows the resolver to select 
which class of resolution meets the applications needs, prior to 
dereferencing|resolving the returned [U|X]RI.

>	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. 
>  
>
Yes, the thing that is resolved should be out of scope for XRI 
resolution.  Simply the flexible framework for returning "whatever the 
publisher/authority of the XRI deems usefully given an XRI".

>	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). 
>
I'm thinking, with greater flexibility, simply specifying DDDS service 
field (ala rfc3404) as:

service_field = [ [protocol] *("+" rs)
protocol = ALPHA *31ALPHANUM
rs = ALPHA *31ALPHANUM

no need to go beyond that.  If we really need to contrain what protocols 
are valid, we can restrict it in the BNF of the NAPTR defs.

>
>	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.
>  
>
Again, an implimentation choice, IMHO.  given the xri:  
xri://.1.2.3/(+peterd) the naming authority .1.2.3 could publish a NAPTR 
such that the regx returned:

    !\+(\w+)!ldap://my.ldap.server/uid=\\1,dc=neustar,dc=us

can produce the ldap url ldap://my.ldap.server/uid=peterd,dc=neustar,dc=us

(forgive me, i need to revisit the LDAP URI syntax. the above is not 
completely accurat... but you get the picture)

>	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. 
>
Authoratativeness and trust are attributes (metadata) on the 
naming-authority part, at least in my mind.  Local-part must be within 
the domain of the naming authority...  So i think (+assertions) or 
(+metadata) is the proper approach here.

>* 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. 
>  
>
See my comments above, loose definitiions of the XRI NAPTR BNF may be 
sufficient to allow N protocols, wihtout our need to profile those we 
feel are "really usefull".

>- 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.. 
>  
>
I was thinking of the naming authority part, where LTR and RTL languages 
may impact the resolution process in the first step (finding a network 
endpoint to ask about the local-part.  The local-part MAY be 
implimnetation-specific, and perhaps even tightly bound to the protocol, 
such as HTTP language negotiation.

>- 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"? 
>  
>
versions are going to be interesting to say the least.  think of all the 
version-related resolution questions one may produce:

- give me version foo
- give me the most recent version
- give me a version between foo and bar (where bar may be the most recent)
- give me the resource offering from naming authority foo and a 
local-part version of bar

etc... :-(


---- peterd