[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] Important new XRID issue
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]