OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]