W3C home > Mailing lists > Public > www-tag@w3.org > July 2008

Re: Should the HTTP protocol become "inapropriate"

From: John Bradley <john.bradley@wingaa.com>
Date: Sun, 27 Jul 2008 12:09:13 -0700
Cc: "Paul Prescod" <paul@prescod.net>, "Mark Baker" <distobj@acm.org>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "David Orchard" <orchard@pacificspirit.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, "www-tag@w3.org" <www-tag@w3.org>
Message-Id: <51E834D9-9F5A-43CC-8BC2-AF936C70C9E9@wingaa.com>
To: Tim Berners-Lee <timbl@w3.org>
Tim,

I thank you for contributing to the discussion.

There is a saying 实事求是 (seek truth from facts).

So please consider the facts as I and perhaps others see them.

XRI provides two things:
1.  A URN like syntax that is useful for describing and addressing  
data in XDI-RDF.
2.  A resolution service that is XML based (XRDS) and extensible far  
beyond what DNS or IDN is designed to provide.

We see XDI-RDF and SPARQL as complimentary and hopefully interoperable  
technologies,  much like we have with http: and xri:.

XRI  exists and is deployed as an OASIS committee standard.    XDI  
exists and is in testing (though the standard is still in committee  
draft)

XRIs need to be identifiable by a client application without querying  
meta data, PROPFIND or some other interaction.

XRI needs a way to define additional normalization rules beyond what  
are defined for http: in IRI.

I have referred to this as a sub-scheme for http:

If a standard sub-scheme can be developed, then XRI and others will  
have no need to register new URI schemes.

I believe that issue-50 was created to address this.

The XRI-TC believes however that issue-50 URNsAndRegistries-50 is not  
complete or sufficient for resolution and syntax.

You state below "Of course, XRI people can become HTTP people"

You are correct, if the issues are addressed.

If the issues are not,  I humbly submit that there is a risk of HTTP  
people becoming XRI people.

That is not our goal or intention.

We are working with great diligence towards an understanding that  
avoids the latter outcome.

If our help with issue-50 is desired we will give it willingly.

Thank you for considering my interpretation of the facts.
I hope that it may lead us to some truth that can accommodate us both.

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中

On 27-Jul-08, at 12:59 AM, Tim Berners-Lee wrote:

>
>
> On 2008-07 -26, at 06:35, Paul Prescod wrote:
>
>>
>> On Fri, Jul 25, 2008 at 11:24 AM, Mark Baker <distobj@acm.org> wrote:
>>>
>>>
>>> A hypermedia approach would have explicitly declared the "?" URI in
>>> the former representation with some link metadata called
>>> "metadata-record" or some such, e.g. <a rel="metadata" href="?" />
>>
>> think the thing being neglected in this discussion is that the reason
>> for the naming convention is that HTTP based resolution may not be
>> always appropriate for these identifiers.
>
> I suspect that is because you regard the HTTP resolution mechanism  
> as fixed.
> That is relative, though.
>
> The XRI people feel capable of changing, if necessary, of changing  
> the XRI resolution mechanism.
> That is because the XRI people are the design authority.
> They feel less confident that they can change (extend, morph, adapt,  
> etc) the HTTP resolution protocol.
>
> The HTTP people feel capable of changing, if necessary, of changing  
> the HTTP resolution mechanism.
> That is because HTTP people are the design authority for HTTP.
> They feel less confident that they can change (extend, morph, adapt,  
> etc) the XRI resolution protocol.
>
> Of course, XRI people can become HTTP people.
>
> There are very many people using HTTP URIs.
> When there is a problem, that there needs to be different  
> functionality, then there will be a large call for a change.  XRI  
> folks can certainly add to others' their criteria and join the  
> conversation about how the system may need to be changes and  
> supported in the future.
>
> Tim
>
>> [...]
>


Received on Sunday, 27 July 2008 19:09:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:23 UTC