RE: [xri] Re: Collaboration vs Capitulation

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

Robin, thanks for the input. The W3C TAG dialog has indeed been very
productive. We're about to take another step forward in the dialog - that's
what most of this thread has been about.

TC members, please do remove Robin from the cc list (he's a subscriber to
the regular list so he'll receive a copy anyway).

=Drummond 

> -----Original Message-----
> From: Robin Cover [mailto:robin@oasis-open.org]
> Sent: Wednesday, October 15, 2008 12:46 PM
> To: Barnhill, William [USA]
> Cc: John Bradley; Nika Jones; OASIS XRI TC
> Subject: [xri] Re: Collaboration vs Capitulation
> 
> Bill (and anyone else),
> 
> Will you kindly remove my name from the 'cc' recipient list
> on any subsequent postings for this thread?
> 
> My contribution was simply to answer the Bill's question about the
> abbreviation 'AWWW':
> 
>   > For the lurkers amongst us, AWWW = what again?
> 
> The direction being taken here now (bringing up the name
> 'TimB', with phrases like "listening to the TAG",
> "what comes out of the TAG is not gospel") appears to me
> counterproductive to healthy collaboration.  I don't
> want my name associated with any such conversation.
> 
> Bill, I have also (along with you) not been party to
> the joint concalls between XRI-TC and W3C, but from
> a great distance (lightly monitoring the summaries
> from Drummond Reed and others), it appears that the
> collaboration has been helpful, producing positive results.
> I'm very pleased to see this kind of fruitful interaction.
> 
> Thanks.
> 
> - Robin
> 
> Robin Cover
> OASIS, Director of Information Services
> Editor, Cover Pages and XML Daily Newslink
> http://xml.coverpages.org/
> http://xml.coverpages.org/newsletterArchive.html
> +1 972-296-1783
> 
> 
> On Wed, 15 Oct 2008, Barnhill, William [USA] wrote:
> 
> > Separate message, because a different topic.
> >
> > As for precluding the Accept: header, if a protocol uses HTTP then it
> uses
> > HTTP (and thereby the std HTTP headers). To say we can only use a sub-
> set of
> > HTTP..what standard is this sub-set, HTTP-lite? I am all for listening
> to the
> > TAG, and I have always had a lot of respect for TimBL, but what comes
> out of
> > the TAG is not gospel. It's stuff from pioneers and experts in the
> field, no
> > less, and no more.IMHO we should consider their input very carefully
> (see the
> > abstract resolution proposal in earlier msg for my take on addressing
> this
> > input) and decide ourselves whether their input makes sense given our
> use
> > cases and requirements.  If the compromise and collaboration between the
> TAG
> > and the XRI TC is going to be the XRI TC doing everything the TAG tells
> us to
> > do because that's what the TAG tells us to do then that's not
> collaboration
> > it's capitulation.
> > Frankly, from everything I've read I've heard and read about TimBL I'd
> hope
> > he'd be the first for open, reasoned, and non-vitriolic collaboration,
> so I'd
> > think the W3C would be for that as well. Not saying they aren't btw, as
> they
> > have sat down at the table with the TC via the joint telecons. I have
> not
> > been in those calls however so I do not have a good enough handle on the
> > collaboration that's taking place to comment.
> >
> > -Bill Barnhill
> >
> >
> >
> > From: John Bradley
> > Sent: Wed 10/15/2008 2:52 PM
> > To: Barnhill, William [USA]
> > Cc: Robin Cover; Nika Jones; OASIS XRI TC
> > Subject: Re: [xri] Versioning ... was: Re: [xri] PLEASE REVIEW: Draft of
> > XRI-As-Relative-URI page
> >
> >
> > We use the media type in the accept header for service selection in the
> > current spec.  The media type application/xrds+xml is passed in the
> query
> > string.
> >
> > We are precluded from using the accept header as long as we are claiming
> that
> > the XRI itself is abstract.
> > The W3C has raised this as one of the issues they are concerned with
> several
> > times.
> >
> > We are not currently breaking there rule.  We should avoid going there.
> >
> > =jbradley
> >
> >
> > On 15-Oct-08, at 11:03 AM, Barnhill, William [USA] wrote:
> >
> >>
> >> Ah, thanks. But..how does that say we can't do this. Assuming we get a
> mime
> >> media type registered for XRI, or have a proposed one of
> >> application/xrds+xml then as I see it we have two options open to us
> beside
> >> encoding this within the URI: content negotiation using the accept
> header
> >> or content-features header
> >> (http://tools.ietf.org/html/draft-ietf-conneg-content-features-02). I
> am
> >> not suggesting we rev the media type for each version. Instead I am
> >> suggestion we use a 'v' parameter like so
> >>
> >> Accept: application/xrds+xml;v=2.0, application/xrds+xml;v=3.0,
> >> application/xdi+xml
> >>
> >> -Bill Barnhill
> >>
> >>
> >> From: Robin Cover
> >> Sent: Wed 10/15/2008 1:24 PM
> >> To: Barnhill, William [USA]
> >> Cc: John Bradley; Nika Jones; OASIS XRI TC
> >> Subject: RE: [xri] Versioning ... was: Re: [xri] PLEASE REVIEW: Draft
> of
> >> XRI-As-Relative-URI page
> >>
> >> AWWW = Architecture of the World Wide Web
> >>
> >> http://www.w3.org/TR/webarch/
> >>
> >> -- rcc
> >>
> >> Robin Cover
> >> OASIS, Director of Information Services
> >> Editor, Cover Pages and XML Daily Newslink
> >> http://xml.coverpages.org/
> >> http://xml.coverpages.org/newsletterArchive.html
> >> +1 972-296-1783
> >>
> >>
> >> On Wed, 15 Oct 2008, Barnhill, William [USA] wrote:
> >>
> >>> For the lurkers amongst us, AWWW = what again?
> >>>
> >>>
> >>> From: John Bradley
> >>> Sent: Wed 10/15/2008 12:47 PM
> >>> To: Nika Jones
> >>> Cc: OASIS XRI TC
> >>> Subject: Re: [xri] Versioning ... was: Re: [xri] PLEASE REVIEW: Draft
> of
> >>> XRI-As-Relative-URI page
> >>>
> >>>
> >>> Using the accept header is something that we cant do because of AWWW.
> We
> >>> don't currently use the accept header for the proxy for anything other
> >>> than
> >>> service selection.
> >>>
> >>> I am not opposed to having the proxy support multiple syntaxes for
> >>> entering a
> >>> XRI.
> >>>
> >>>
> >>> =jbradley
> >>>
> >>> On 15-Oct-08, at 9:42 AM, Nika Jones wrote:
> >>>
> >>>
> >>> Both ideas make sense (headers/parameters) ... the only thing would be
> for
> >>> people handwriting the HXRI (and would that acronym need to change for
> >>> other
> >>> schemes?) Most of the time I can see a client taking a native XRI and
> >>> resolving it through the proxy (so the XRI to HXRI would be
> automated)...
> >>> however there may be time when a person needs to write the HXRI by
> hand...
> >>>
> >>> like OpenID... if I find that a client doesn't support native XRI
> (tisk,
> >>> tisk
> >>> *smile*) then I can type in the HXRI so that it conforms to the
> "http://*";
> >>> that the OpenID client seems to be looking for, and that usually
> works. So
> >>> for hand writing the XRI to an HXRI it seems easier to remember (
> >>> *.{TLD}/xri{version}:{XRI} )
> >>>
> >>>
> >>> example.net/xri2:=example or example.net/xri3:@example
> >>>
> >>>
> >>> than
> >>>
> >>>
> >>> example.net/=example?v=2
> >>>
> >>>
> >>> which is like ( *.{TLD}/{xri}{version-parameter} ) ... we'd also have
> very
> >>> little HTTP Headers control when hand writing HXRIs. I don't want to
> dwell
> >>> on
> >>> it, but I just wanted to give some background as to where I was coming
> >>> from.
> >>>
> >>>
> >>> Nika
> >>>
> >>>
> >>>
> >>>
> >>> On Oct 15, 2008, at 7:11 AM, John Bradley wrote:
> >>>
> >>>
> >>> For the http: proxy binding the XRI version should probably be in the
> >>> query
> >>> parameters.  That is where we specify returning XRD or XRDS etc.
> >>>
> >>> Putting it in the base URI is going to cause problems.
> >>>
> >>>
> >>> =jbradley
> >>>
> >>> On 15-Oct-08, at 6:32 AM, Barnhill, William [USA] wrote:
> >>>
> >>>
> >>>
> >>>
> >>> Just a couple of quick thoughts:
> >>> .. XRI resolution should be adaptable to non-http. I realize that's
> not
> >>> currently supported, but should be IMHO. Please be careful that the
> >>> changes
> >>> you are making based on W3C feedback do not lock it totally to HTTP.
> >>> .. That said, if for the majority using HTTP you don't just have the
> URL
> >>> to
> >>> play with. The accepts header seems a good use for the version (the
> client
> >>> specifies the versions it understands, the proxy returns the highest
> >>> version
> >>> the client understands). This also means URL links people have
> coded/made
> >>> will not break when you version ('Cool URLs' and all that).
> >>> Thanks,
> >>> Bill
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> From: Nika Jones
> >>> Sent: Tue 10/14/2008 11:54 PM
> >>> To: OASIS XRI TC
> >>> Subject: Re: [xri] PLEASE REVIEW: Draft of XRI-As-Relative-URI page
> >>>
> >>>
> >>> With XRI 3.0 around the corner, would it be prudent to add a version
> to
> >>> the
> >>> sub-scheme?
> >>>
> >>>
> >>> http://proxy.example.com/v2/=example
> >>>
> >>>
> >>> or
> >>>
> >>> http://proxy.example.com/xri:v2:@example*mint
> >>>
> >>>
> >>> Nika
> >>>
> >>>
> >>>
> >>>
> >>> On Oct 14, 2008, at 6:09 PM, John Bradley wrote:
> >>>
> >>>
> >>> I think the idea is to move away from beginning the domain name with
> xri
> >>> and
> >>> move to making the significant part the tld.
> >>>
> >>> For sftp we ned to sort out what the encoding rules are for the
> binding.
> >>> Normally you would be adding query parameters to the URI as well so
> >>> encoding
> >>> for ftp may be a challenge.
> >>>
> >>>
> >>> =jbradley
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 14-Oct-08, at 6:00 PM, njones@ouno.com wrote:
> >>>
> >>>
> >>> All:
> >>>
> >>> Does the XRI need to also be the first path... It's written as, "first
> >>> character of the path," so is it the first character of the first
> path?
> >>>
> >>> would it be more appropriate to write it
> >>>
> >>> *.{TLD}/{XRI}
> >>>
> >>> where {TLD} is any Top Level Domain (.net, .com, .org, etc.) and the
> >>> {XRI}is any valid XRI?
> >>>
> >>> Also for FTP (and FTPS and SFTP I presume) how does the resolution
> happen?
> >>> Would you need a special server listening to port 21 or 990? Or am I
> >>> getting confused as to where the FTP is placed. Is the following
> valid:
> >>> ftp://xri.net/@example*run
> >>>
> >>> Nika
> >>>
> >>>
> >>> On Tue, 14 Oct 2008 00:05:31 -0700, "Drummond Reed"
> >>> <drummond.reed@cordance.net> wrote:
> >>>
> >>> XRI TC Members and Observers:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Per my action item from the last telecon, I have posted a first draft
> >>>
> >>> wiki
> >>>
> >>> page describing the XRI-As-Relative-URI proposal to:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>         http://wiki.oasis-open.org/xri/XriAsRelativeUri
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> The next step is for TC members to review and comment on this page. As
> >>>
> >>> always, being a wiki, feel free to just go in and edit the page. Or,
> if
> >>>
> >>> you
> >>>
> >>> prefer, send feedback or question to the list.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> The goal is to incorporate any feedback by Wednesday so we can begin
> >>>
> >>> sending
> >>>
> >>> messages to the W3C TAG public mailing list to solicit feedback there
> >>>
> >>> before
> >>>
> >>> our next telecon this coming Thursday.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> =Drummond
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe from this mail list, you must leave the OASIS TC that
> >>> generates this mail.  Follow this link to all your TCs in OASIS at:
> >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php