OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri-editors] Important new XRID issue


My preference is to handle this lower in the stack than the XRID. You're
also free to add an element in the Authority component that gives the
user more info about its intended usage, but you need to be prepared to
have the client ignore it. For instance, it's fine to have two Authority
elements, like

<Authority>
	...
	<URI>reassignable resolver</URI>
	<other:usage>*</other:usage>
</Authority>
<Authority>
	...
	<URI>persistent resolver</URI>
	<other:usage>!</other:usage>
</Authority>

but the client may ignore the other:usage piece so you need to have a
backup plan, like redirects or a load balancer or whatever.

Dave

-----Original Message-----
From: Peter C Davis [mailto:peter.davis@neustar.biz] 
Sent: Thursday, February 10, 2005 10:18 AM
To: xri-editors@lists.oasis-open.org
Cc: Dave McAlpin; Drummond Reed; Wachob, Gabe; Victor Grey; Fen Labalme
Subject: Re: [xri-editors] Important new XRID issue

On Thursday 10 February 2005 01:00 pm, Dave McAlpin wrote:
> 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? 

yes. this is correct.

> 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.

no, this is not a 'special case'.  this is suggestion for optimizations
of 
resolution.  in order to be usefull, resolution of XRI's must have
resolution 
performace characteristics on par with the DNS.  The primary issue here
is 
'special' in so much as the root of a namespace always has some
'special' 
considerations, driven by performace.  The GCS char's lack an internal 
delegation tool within the resolution spec.

there is implied delegation (i think) in =* vs =!, and we could use
that.  but 
an XRID does not allow that expression.

>
> 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.

HTTP redirect does not scale properly at a heavily utilized root, and 
introduces unnecessary additional overhead to the resolver.  perhaps,
through 
Layer5 load balancing (inspection of the request URI), can make the 
optimizations we need, but it seems to me better to consider this in the
spec 
at least (heck, there are a dozen ways to solve this... one of which is
to 
accommodate it in XRI2.0)

--- peterd

-- 
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]