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:

  
A focused effort by a 
  number of the editors (myself and Mike Lindelsee especially) to revise and 
  extend the introduction document. 
  
Several important, though 
  relatively minor, changes in the XRI document (noted below) 
  
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

  
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.

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

  
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. 

  
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/

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

 

 

__________________________________________________ 
 

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