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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: Moving forward after comment period


XRI TC members and observers-
    Our public comment period has closed and we received a small handful of comments [1] and discovered some minor bugs and issues as a result of early implementations. In addition, we were faced with the fact that the draft "Introduction to XRI" document was leading some, especially those in the W3C TAG, to draw conclusions or impressions that we didn't feel were justified by the specifications themselves.
 
PROPOSED PLAN
 
    To address these issues, we (TC Chairs and editors) are proposing the following plan moving forward:
  1. A focused effort by a number of the editors (myself and Mike Lindelsee especially) to revise and extend the introduction document.
  2. Several important, though relatively minor, changes in the XRI document (noted below)
  3. A delay in the vote to ensure that the intro document and the changes are fully in place and agreed to. We don't yet have a firm idea of when the vote would happen, though it will definitely not be before July.
    Questions or issues with this plan should be voiced now.
 
 
PROPOSED CHANGES TO SPECIFICATIONS
  1. Change the proxied resolution specification to include the following:

    * Make proxy resolution do full authority and X2R local access as a default. This means that the full XRI (including the path part) may be added to the proxy base URI, and that the proxy will do, by default, X2R resolution if the content-type of the request is not provided. 

    * This will let you put an XRI (with the full proxy base URI prepended) in a web page (or any other context that uses HTTP URIs) and the XRI becomes resolvable (with some limitations on how you interact with that XRI, obviously). 

    * In order to continue to use XRIs as identifiers when they are published in the "proxy" form described above, we need to have a way for the XRI values to be extracted from the various HTTP proxy URIs containing the XRI values. For example, we could say that HTTP proxy base URIs MUST end with "%DE%AD%BE%EF" and everything after that could be expected to be the XRI value - so you could crawl the web for HTTP URLs with "%DE%AD%BE%EF" in them and everything after that string is an XRI value. Useful for publishing XRIs in the HTTP-only WWW. We believe this should satisfy the W3C TAG's commentary.
  2. Non-normative example of negotiation for an XRID in X2R local access. That is, while its currently possible, we do not explicitly say that X2R local access can result in an XRID. It may be worthwhile showing how this resolution could happen with the media type for XRIDs (application/xrid+xml).
  3. Get rid of trust attribute – use TrustMechanism child element of Authority instead. Instead of merely saying that an authority is trusted via a yes/no attribute, it may make more sense to simply include a TrustMechanism element as a child of the Authority element and indicate *which* trust mechanism(s) the authority has. The absence of a TrustMechanism element would be equivalent of saying the authority doesn't do trusted resolution.
  4. Priority element/attribute for synonyms, service, and authority elements. Instead of relying on document order for certain elements, have an explicit "priority" child element or attribute so that the intended order of application of these elements (where multiple copies of these elements exist) can be explicitly communicated. We'll need some more specific input from the folks who have run across this requirement in their implementation.
These changes will be tracked in a revisions tracking document that will be put together by Drummond.
 
    -Gabe
 
[1] http://lists.oasis-open.org/archives/xri-comment/

__________________________________________________
gwachob@visa.com

Chief Systems Architect
Technology Strategies and Standards
Visa International
Phone: +1.650.432.3696   Fax: +1.650.554.6817
 
 


__________________________________________________
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International
Phone: +1.650.432.3696   Fax: +1.650.554.6817

 


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