[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Res decision #3: HXRI strawman
Bill, You're absolutely right about HTTPS. I
simply forgot to include that (it was close to =Drummond From: Barnhill William
[mailto:barnhill_william@bah.com] +1, qualified as below for encoding, and
regardless of decision on https proxies. I'm assuming the absolute xri appended
onto the HXRI base (http://xri.foo.com[/?])
is encoded to allow parsing, as for example I thought XRIs MAY have fragment
identifiers, and a fragment start # is not a legit query character. Also I'd suggest alowing for https
proxies as well, perhaps with a mandate of using TLS if using a https
proxy. Halfway between trusted resolution and http proxies, but I can see
it being used. From: 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: 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. 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]