xri message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Moving forward after comment period
- From: "Wachob, Gabe" <gwachob@visa.com>
- To: <xri@lists.oasis-open.org>
- Date: Tue, 3 May 2005 15:35:45 -0700
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
__________________________________________________
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]