RE: [xri] Minutes: 11/4 XRI TC Telecon

["Drummond Reed" <drummond.reed@cordance.net>]

Nick,

Thanks for this very cogent analysis about the "xri." syntax for HXRIs. Note
that this syntax that has now been incorporated into Working Draft 09
(http://www.oasis-open.org/apps/org/workgroup/xri/download.php/15310/xri-res
olution-V2.0-wd-09.pdf).

Let me share a few additional perspectives/requirements that went into this
choice.

First, HXRI syntax is intended to be a intermediate measure to assist user
agents (like browsers) that do not natively understand XRIs. As you say,
HXRIs and HTTP proxy resolvers are really a way to "tunnel" XRIs through
HTTP URIs. So we don't feel the need to strongly encourage the deployment of
lots and lots of HTTP proxy resolvers, which is why fairly restrictive
domain name-based syntax seems an acceptable choice.

Second, the "xri." syntax (plus the lack of escaping, below) fulfills the
requirement we have for HXRIs to be easy for ordinary users to type. 

Third, by restricting the prefix semantics to the domain name, we can
specify that the entire local part is the QXRI (query XRI), and avoid any
special escaping at all. In other words, any HTTP proxy resolver at an
"xri." domain name is dedicated to XRI processing.

Fourth, as you point out, as unnecessary as it is, "www." has become a
widely understood convention, with real behavior attached in many client
applications (including the editor I'm using to write this email.) So the
"xri." syntax simply takes advantage of that same pattern.

I hope this helps. I encourage you to take a look at the HXRI syntax and
proxy resolution functionality in the context of Working Draft 09 and share
your further thoughts.

Best,

=Drummond 

-----Original Message-----
From: Nick Ragouzis [mailto:nickr@enosis.com] 
Sent: Sunday, November 06, 2005 9:12 AM
To: 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] Minutes: 11/4 XRI TC Telecon

For me:

> a) SOAP-style vs. URI-style XRIDs
+1 URI, with suitable mechanics for service/@auth ../@version ../@priority;
plus extension points.

> c) HXRI format
I just can't shake the feeling that the proposed approach is, 

* on one hand, retrograde: here we've been teaching folks that the "www."
isn't necessary ... and for good reason (but I'll agree
that many service providers have begun putting their own LOCAL service
semantics in the host (as one user option) which is reason
enough to not touch that), and 

* is promoting to operational something that's been merely notational
(appearance in dns of "mail.", "mobile.", ... styles), 

* and on the other hand is shifting or moving a service/semantic component
into a locator component, loosely, if you'll allow me.
The lending to an http uri the semantics of an xri seems to me closer to the
case of managing a new service type ... which
traditionally (once :port was let go) has been accommodated 'early' in the
path. Further, proxy semantics transcend this
distinction, so don't require the shift into the locator component.  

So, at the http level I'm thinking we're looking not for a "routing" or
"resolution" affordance, but a "convention" for a service:
e.g. http://any.fqdn/xri%3a%5c%5c... which any service can respond to as in
xri, or blithely ignore (just as would certainly happen,
I'm guessing, at the outset). And, anyway, it would leave operators to
decide on their own to create xri.any.dom hosts that
interpret "normal" http paths as locators that translate into XRIs (rather
than what the current proposal would do, which is limit
that to just the to-be-decided specific form of the path).

Which points out sth else about faults ... in terms of errors, to an
HTTP-bound service representation, 404 makes much more sense to
me. As a proxy affordance, HXRI is a 'mapping' service, not a host, not the
xri resolution svc; and at least
http://any.fqdn/xri%3a%5c%5c... would reach the targeted domain (and appear
in those logs, putting the service operator on notice of
the fault) whereas the proposal fails with NSN at the dns.

So this gets to the question of the permissible form of the absolute xri in
the path. Since we have to be somewhat restrictive with
this form, restricting it to incl the (escaped) xri:// seems in scope for
consideration ... plus I'm think the HXRI form will be a
bit more the concern of humans that we've accounted. Especially during the
adoption period, when users often have to interpret this
stuff (email line breaks in new ways, reading it off to someone else,
transferring it by hand from one platform to another ... let
alone the bizcard model from the rqmnts). 

If we aren't very restrictive we'll end up with another whole species headed
for tinyurl. Which, when I think about it, with HXRI
requirements we are, more, asking for a 'tunneling' through HTTP to an XRI
service, with a token would be 'natural' for *common*
HTTP use (not common for XRI use). Something like:
  allowed: http://fq.dn/xri(~~|%3a%5c%5c)/[esc-subdelims|unreserved]
  should: http://fq.dn/xri~~/[unreserved]

Keeping with unreserved chars means at least email clients that already
don't properly handle URIs won't break/halt at that point
before the complete "xri_prefix" ("xri~~") or even better for the full
recommended limited form.

You'll note a different preference indicated above, to not standardize on a
query form as part of satisfying proxy resolution. The
query possibility should be left open to apps to use whatever &xri=anyform&
they want ... and any query spec here for proxy would
(I'm guessing) be generalized to any use of xris in queries (which if XRITC
were interested, could be a different part of the
reqmnts). 

HTH,
--Nick

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Saturday, November 05, 2005 10:00 PM
> To: 'Drummond Reed'; xri@lists.oasis-open.org
> Subject: [xri] Minutes: 11/4 XRI TC Telecon
> 
> 
> Following are the minutes of the unofficial XRI TC telecon held from
> 8:30-10:00AM Pacific on Friday, Nov. 4, 2005.
> 
> Present:
> 
> Gabe
> Mike
> Peter
> Les
> Victor
> Dave
> Drummond
> Steve
> Bill
> Marty
> Owen
> 
> 1) REVISIT OF YESTERDAY'S AGENDA ITEMS TO DETERMINE/CONFIRM CONSENSUS
> 
> a) SOAP-style vs. URI-style XRIDS
> 
> First we checked consensus on whether everyone agrees either 
> style will
> work. There was consensus on this.
> 
> We then checked for preferences.
> 
> SOAP-style preference:
> Bill Barnhill
> Mike
> Gabe (mild)
> 
> 
> URI-style preference:
> Victor
> Steve
> Drummond
> Peter
> Les
> Dave
> Owen
> 
> We therefore will prepare the next Working Draft using the 
> URI-style format.
> 
> b) Spec refactor discussion
> 
> Because much of the work has already been done to prepare a 
> refactored spec
> that uses mostly the URI-style format, we will incorporate 
> that refactoring
> into the Working Draft.
> 
> c) HXRI format
> 
> Gabe made the point that HXRIs would need to use the path 
> rather than the
> query style to be compatible with "microformat" initiatives 
> such as the
> rel-tag syntax (http://microformats.org/wiki/Main_Page). 
> 
> Mike felt that the query format was preferable, and Dave also 
> prefers it
> because it may require less escaping. However upon further 
> discussion the
> collective wisdom of the group was that it would be best to 
> define only one
> HXRI format, and the path format meets a broader set of requirements. 
> 
> Drummond suggested that he and Dave discuss it and come back 
> with a specific
> recommendation about the escaping rules.
> 
> 2) CONTINUE DISCUSSION OF PROXY RESOLUTION RULES AND PATTERN MATCHING
> 
> Dave again explained his suggestion about adding a <Pattern> element
> specifying its use in selecting a service element. Currently 
> there only way
> to choose a Service element which is by type and priority. 
> Dave's suggestion
> would add an optional element that contains a regular 
> expression. If the XRI
> has a path component, upon completing authority resolution 
> the client would
> selects the appropriate service by seeing if the XRI path 
> matches the regex
> in the Pattern element, if any.
> 
> No consensus was reached. Drummond suggested that he work with Dave to
> prepare a specific proposal as part of the Working Draft.
> 
> 3) EDITORS AND WORKING DRAFT SCHEDULE
> 
> Drummond has already volunteered to help Gabe edit the next 
> Working Draft
> (and since Gabe's time is limited, he'd like the help). 
> 
> Dave and Les also volunteered to help as editors.
> 
> Since considerable work has already been started, the goal is 
> to produce the
> next draft in time for TC members to review it prior to the 
> next call (next
> Friday).
> 
> 4) ADVANCEMENT OF XRI SYNTAX 2.0 COMMITTEE DRAFT 02
> 
> The public review period for XRI Syntax 2.0 Committee Draft 
> 02 has closed.
> One public comment was received from Norm Walsh at Sun. He 
> referenced the
> W3C TAG feedback and said that he didn't feel the TAG's concerns were
> addressed.
> 
> There was consensus that, while the TAG comments resulting a 
> huge amount of
> work being done to XRI resolution to make it fully backwards 
> compatible with
> HTTP URIs (which will be apparent shortly in the new Working 
> Draft of XRI
> Resolution), it had no effect on XRI Syntax.
> 
> Therefore there was consensus to immediately begin the ballot 
> to advance XRI
> Syntax 2.0 Committee Draft 02 to a Committee Specification 
> and submit it by
> November 15 for vote as an OASIS Standard. 
> 
> Drummond will contact XRI TC Administrator Mary McRae and ask 
> her to open an
> online ballot today so it can close by Friday, November 11. 
> Everyone is
> asked to vote as soon as possible after this ballot opens.
> 
> We will also need to begin preparing the TC member attestations of
> implementation and interoperability. Drummond will send email 
> to the list
> about this.
> 
> 5) NEXT MEETING
> 
> We will continue to hold meetings at 8:30am Pacific Fridays 
> until we finish
> the XRI 2.0 suite. The exception will be Friday November 25 due to the
> Thanksgiving holiday in the U.S.
> 
> =Drummond 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>