RE: [xri-editors] Important new XRID issue

["Drummond Reed" <drummond.reed@cordance.net>]

Since I'd been offline at a meeting while this thread was going, I'm joining
late. To prevent email churn, I first called Gabe to discuss and then Dave
(at Gabe's recommendation) to get their perspectives.

A few notes/suggestions:

1) First, on clarifying the issue/requirement. In current XRID architecture,
same XRI Authority resolves requests for "*..." and "!..." at the same set
of URIs. The issue was that an XRI authority may desire to optimize
resolution to establish different sets of URIs for "*..." resolution vs.
"!..." resolution. XDI.ORG is an example of such an authority that was
planning to do just that and has specified that behavior in its draft Global
Services Specifications (http://gss.xdi.org/moin.cgi/GssOpSpecs).

2) I agree that this is primarily a scale issue. That's why those of us
involved with the XDI.ORG Global Services Specifications are bringing up the
issue. (I only wish we had caught it earlier.)

3) I strongly disagree with the argument that there are other XRI
characteristics that could equally qualify for such treatment. Only the *
segment vs. ! segment distinction is recognized in XRI syntax. My personal
opinion is that the different charteristics of persistent vs. reassignable
identifiers is a strong argument that an XRI authority should have the
option (but not the requirement) to declare different resolution URIs for *
vs. ! segments.

4) Yes, it could be handled by extensions, but I agree with Peter that with
this issue that's a poor substitute for handling it in the XRID where it
will lead to consistent behaviour and better performance for all concerned
(resolvers, developers, users, registries).

5) If we push this off to a future version of the Res spec, it raises a
different issue that we can't put off: giving the XRID a version identifier.
Dave and I talked about this and he is going to propose something based on
what SAML 2.0 did.

We agreed to try to close on this topic on the Editor's call tomorrow.

=Drummond 

-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Thursday, February 10, 2005 3:10 PM
To: xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] Important new XRID issue

I agree with Dave here.  It is awfully late in the process to be
bringing up changes that may be far-reaching. I also don't particularly
understand the actual requirement here.  It seems that a solution is
being proposed for an unspoken requirement.  

Since i-names and i-numbers already will resolve to different
authorities, I'm not seeing the problem you are trying to address.  Even
if I assume that we are talking about mixing resolutions of both
persistent and reassignable i-names, and that loads and traffic patterns
are different between the two kinds of resolutions -- one being high
volume and the other a lower volume, isn't the lower volume traffic just
swamped by (and easily absorbed in) the high volume traffic?

Mike 

>-----Original Message-----
>From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] 
>Sent: Thursday, February 10, 2005 10:47 AM
>To: Peter C Davis
>Cc: xri-editors@lists.oasis-open.org; Drummond Reed; Wachob, 
>Gabe; Victor Grey; Fen Labalme
>Subject: RE: [xri-editors] Important new XRID issue
>
>We can do this kind of enhancement forever. People will always be able
>to think of ways to specialize XRID elements in reasonable 
>ways, Service
>probably even more than Authority. And this _is_ a special case - we
>could just as easily say we wanted different authorities for ranges of
>persistent identifiers, or an authority that returns XDI style
>descriptors or whatever. At this point our priority should be releasing
>a spec, which means only fixing things that are clearly broken. I don't
>think this qualifies as broken.
>
>Dave
>

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.