RE: [xri-editors] Important new XRID issue

["Drummond Reed" <drummond.reed@cordance.net>]

Gabe,

My bad. What I meant was that we wanted two different types of XRI
*authorities* (I keep saying "resolver" when I mean "authority"): one that
answers i-number resolution requests and one that answers i-name resolution
requests. But right now an XRID only provides a "XRIAuthority/URI" element.
An XRI authority could provide two URIs, one intended for i-number
resolution and one for i-name resolution, but how is the resolver code
supposed to know which one to use for what?

Is that clearer? If not, call me and let's discuss via voice. It's a pretty
simple requirement but neither Peter or I saw a way to support it w/o adding
just a tiny bit of semantics to the XRID.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Wednesday, February 09, 2005 9:27 AM
To: Drummond Reed; xri-editors@lists.oasis-open.org
Cc: Victor Grey; Fen Labalme
Subject: RE: [xri-editors] Important new XRID issue

Drummond-
	I don't understand why you need a special feature. Why don't you
just have one resolver that does i-numbers and one doing i-names and the
result of subsegment resolution for a top-level i-number subsegment
points to a resolver that is tuned for i-number resolution and the
result of subsegment resolution for a top-level subsegment points to a
resolver that is tuned for i-name resolution.

	Why do you need two different resolvers based on the "next
subsegment"? This seems to totally break the architecture that we've
been talking about since XRI 1.0... 

	-Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Tuesday, February 08, 2005 11:10 PM
> To: xri-editors@lists.oasis-open.org
> Cc: 'Victor Grey'; 'Fen Labalme'
> Subject: [xri-editors] Important new XRID issue
> 
> Gabe & gang:
> 
> Peter and I just realized that in working on the XDI.ORG 
> Global Services
> Specifications (GSS) at http://gss.xdi.org, we had included a 
> use case that
> is not directly supported by the current Resolution working draft.
> 
> It's very simple: as an XRI authority, the XDI.ORG Global 
> Registry Service
> (GRS) has always planned to offer separate XRI Authority URIs 
> for resolving
> global i-names vs. global i-numbers. Peter and I discussed 
> this several
> times in the past and it always made sense to separate them 
> because the
> traffic patterns, load balancing, and caching characteristics 
> of global
> i-names vs. global i-numbers may vary so much.
> 
> But in writing up the GSS I-Name/I-Number Tech FAQ that I've 
> been working on
> (http://gss.xdi.org/moin.cgi/InameInumberTechFaq), I realized 
> that XRIDs as
> currently composed in the 2.0 working draft don't have the semantics
> necessary for resolvers to understand unambiguously that an 
> XRI authority
> provides different XRIAuthority/URI values for resolving i-names vs.
> i-numbers. The authority could, of course, reflect the 
> semantics in the URI
> itself, as Peter did when he proposed the XRI Authority 
> values currently
> listed in the draft GSS specs at
> http://gss.xdi.org/moin.cgi/GssOpSpecs#head-a3f239efc0620f106c
> 85b5352a14bc5a
> 87573b06. 
> 
> However establishing a convention of putting "i-name." or 
> "i-number." in the
> DNS name or in the local part of the URI is obviously not a 
> good solution.
> 
> A much better fix would be to add an attribute to the XRIAuthority/URI
> element such as "ResolveType". It's value could be enumerated 
> as simply "*"
> or "!". And the processing rule would be simply:
> 
> "If "Type" is present, a resolver MUST (or SHOULD?) only send XRI
> subsegments that begin with the character specified in the 
> "ResolveType"
> attribute."
> 
> Or does someone else see a more elegant way to deal with this use case
> (which is a very important one for global XRI registry 
> services, and may be
> important to many high-volume XRI authorities.)
> 
> =Drummond 
> 
> 
> 
> 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-editors/membe
> rs/leave_workgroup.php.
> 
> 

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-editors/members/leave_workg
roup.php.