|Wachob, Gabe||Feb 9, 2005 10:29 am|
|Drummond Reed||Feb 9, 2005 5:46 pm|
|Dave McAlpin||Feb 10, 2005 9:59 am|
|Peter C Davis||Feb 10, 2005 10:17 am|
|Dave McAlpin||Feb 10, 2005 10:29 am|
|Peter C Davis||Feb 10, 2005 10:32 am|
|Dave McAlpin||Feb 10, 2005 10:47 am|
|Lindelsee, Mike||Feb 10, 2005 3:10 pm|
|Drummond Reed||Feb 10, 2005 5:08 pm|
|Subject:||RE: [xri-editors] Important new XRID issue|
|From:||Drummond Reed (drum...@cordance.net)|
|Date:||Feb 10, 2005 5:08:13 pm|
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.
-----Original Message----- From: Lindelsee, Mike [mailto:mlin...@visa.com] Sent: Thursday, February 10, 2005 3:10 PM To: xri-...@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?
-----Original Message----- From: Dave McAlpin [mailto:Dave...@epok.net] Sent: Thursday, February 10, 2005 10:47 AM To: Peter C Davis Cc: xri-...@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.
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.