[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] Important new XRID issue
I'm not positive I understand the issue, but it sounds like if you have xri://=foo and xri://=!123, you'd like two different endpoints for =, one to answer for *foo (and other reassignable subsegments) and one to answer for !123 (and other persistent subsegments). Is that right? If it is, it's just one of an infinite number of special cases. What if I want one authority for even numbers and one for odd numbers? Or one for reassignable subsegments that start with "a", one for "b" etc. The right approach, I think, is to have a single authority definition and just redirect on the server side to the appropriate network endpoint based on your particular rules. Dave -----Original Message----- From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Wednesday, February 09, 2005 5:47 PM To: 'Wachob, Gabe'; xri-editors@lists.oasis-open.org Cc: 'Victor Grey'; 'Fen Labalme' 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_w orkg roup.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_w orkgroup.php. -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.302 / Virus Database: 265.8.6 - Release Date: 2/7/2005
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]