[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]