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: 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-a3f239efc0620f106c85b5352a14bc5a
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 




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