[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] FW: Working on our XRI resolution section
Responses inline.
> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Wednesday, May 28, 2003 7:30 AM
> To: Wachob, Gabe
> Cc: 'xri-editors@lists.oasis-open.org'
> Subject: Re: [xri-editors] FW: Working on our XRI resolution section
>
>
> >
> >
> >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=/libr
> ary/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.
HTTP provides the accept: header for just this purpose.
> 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.
Thats good too - the only problem I see is that we are limited to a small set of strings (ones that are defined to go after the +) - we can't just use URIs or MIME types to specify the exact content we want back.
>
> > 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".
Right. And I was hoping that the resolving process would end up with something which is of a type that is specified by the resolving client - the extent to which this is extensible is something we have to decide.
>
> > 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.
But I don't think its that simple. We can't simply say "use 2169" because 2169 (and 2438) state basically that they are "frameworks" (in fact, 2169 is for resolving URNs, not URIs).
And for LDAP, how do you map an XRI to an LDAP query?
I think that for any local access protocol, there is *some* effort we have to go through to make it useable in an interoperable way. Nothing heavyweight.
Are the 32 characters of the rs field enough for describing all the local access protocols and all the "types" of data we want at the end of the resolution process?
>
> >
> > 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)
Well, this seems to underspecify how one would use LDAP. I think its pretty important that we demonstrate (specify) in enough detail to be interoperable and unambiguous at least 2 local access protocols. Beyond that, sure, we can be open and see what develops.
>
> > 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.
Great. We've talked about using a different character for "specification-defined reserved words" (rather than +), but otherwise, sounds like a good plan to me.
>
> >* 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".
I think in practice, we'll have to do more with local access protocols than simply state that they can be used as local access protocols. Comments above. (Maybe I'm wrong - but I think its worthwhile going through the excercise).
>
> >- 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.
OK, we'll get to this issue in the process of resolution specification.
>
> >- 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... :-(
Yeah, thats why most people avoid versioning. We've said at least that we are going to punt on versinoing of naming authorities. We could just say that version negotiation is a local access issue for resources...
-Gabe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]