RE: [xri] Res decision #3: HXRI strawman

["Chasen, Les" <les.chasen@neustar.biz>]

I am all for making the format of an HXRI as simple as possible.  I think that that only helps make it easy for web site designers to use HXRI based links which just helps promote XRI use overall.  However, it feels like a mistake to me that clients, whether they are spiders, browsers, email clients or whatever, should decide that an http link is really a XRI.  It seems to me that that would be a rather fragile design that could get hacked.  I personally would not stress on coming up with a pattern that tries to allow this.

 

 

 

I-Name:  =les.chasen 

 

---

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thursday, November 03, 2005 1:02 AM
To: xri@lists.oasis-open.org
Subject: [xri] Res decision #3: HXRI strawman

 

Per our agenda below, this is a strawman proposal for decision #3 on the format of HXRIs (HTTP URIs) as required for fully specifying HTTP proxy resolution. This is Issue #13 on the Resolution change management page (http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionChanges). More background is available at:

 

http://wiki.oasis-open.org/xri/Xri2Cd02/SynTax/I3HxriQxri (note that this was originally a Syntax revision proposal)

            http://wiki.oasis-open.org/xri/NewResolutionRequirements (see the HXRI requirements section)

 

Based on discussions over the past few weeks, the following strawman tries to balance the requirements for simplicity and prevention of false positives.

 

The pseudo-ABNF for an HXRI would be:

 

            http://xri.[any.domain.name]/absolute-xri-here

            http://xri.[any.domain.name]?absolute-xri-here

 

The absolute XRI could, per our ABNF, include the "xri://" prefix or not.

 

The key to this proposal (vs. earlier proposals) is the use of "xri." as the prefix for the domain name. This solves two problems:

 

1) It makes it trivially easy for spiders to parse an HTTP URI to see if it qualifies as an HXRI.

2) It makes it extremely unlikely that existing HTTP URIs would produce false positives.

 

This format also fulfills the requirements of human friendliness, because it allows simple strings that can be typed directly into browsers to be recognized as HXRIs, e.g.:

 

            xri.example.com/=example

            xri.example.org/@example

 

=Drummond  

 

---

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, November 02, 2005 11:42 AM
To: xri@lists.oasis-open.org
Subject: [xri] XRI Res CD02 proposed decision tree

 

I've talked with Gabe and there is a clear sense at this point that we need to move from the high-level conceptual definition of XRI resolution down into the concrete decisions we need to make to arrive at XRI Resolution 2.0 Committee Draft 02. As best we can tell, these decisions fall into four buckets:

 

1) Refactoring the Res CD01 spec (for readability and to remove most of the non-normative material).

 

2) Structure of an XRID.

 

3) Structure of an HXRI (HTTP XRI – the form of an XRI that can be resolved using an HTTP proxy resolver).

 

4) Rules/requirements for proxy resolution.

 

We would like to suggest that:

 

a) This week's two calls (Thurs. 9AM PT and Fri 8:30AM PT) focus on these four topics, with the goal of driving to consensus on each of the four as quickly as possible so that the editors can proceed into drafting ASAP.

 

b) TC members who care about these topics submit and discuss strawman proposals on each of the four via email prior to the the calls so that we're not starting discussion from scratch.

 

No response = agreement on this process, so you feel we should use a different process, speak up. Otherwise we'll make this our call agenda for Thursday/Friday and invite submissions/discussions of strawmen beginning immediately.

 

=Drummond