RE: [xri-editors] Important new XRID issue

["Dave McAlpin" <Dave.McAlpin@epok.net>]

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