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

Re: Should the HTTP protocol become "inapropriate"

From: Paul Prescod <prescod@gmail.com>
Date: Sun, 27 Jul 2008 02:07:19 -0700
Message-Id: <B56CE099-425A-4BE0-89B0-1C9EC0E9041A@gmail.com>
To: Tim Berners-Lee <timbl@w3.org>
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>

IMHO, This response does not address the situation where a small  
minority requires an alternate resolution protocol. "don't create a  
new Christian denomination: just change the Catholic church from the  
inside."

Works well sometimes...

To continue the analogy: perhaps the church benefits from the  
innovations produced by the seemingly heretical sects.

And: is the current dogmatism a counter revolution triggered by regret  
over the mess created the last time there was a schism? ("web services")

Is it the position of Tim, Mark and David Orchard that it would be  
wrong? Dangerous? to define a mechanism for embedding hints for  
alternate resolution protocols inside of HTTP URIs?

My opinion is that it is the logical result of the observation that  
HTTP URIs (backed by HTTP proxies) are better than other URIs on the  
web in almost every circumstance.

For example, I could imagine a world in which Jabber URIs were HTTP  
URIs and when I clicked them on my iPhone, something useful would  
happen, just as something useful should happen when I click a  
namespace URI or RDF property URI.

Instead of xmpp://paul@prescod.net it could be:

http://prescod.net/xmpp://Paul@prescod.net

Or the last bit could be inferred from context to avoid repeating the  
context.

iChat might parse this string, notice that it is an embedded xmpp URI  
and treat it as it would xmpp://

Safari on my iPhone would falback to HTTP get behaviour which might  
result in anything from a "sorry; you need a chat program" message to  
a full HTML/HTTP -> xmpp proxy.

Wouldn't a world of more reliably "clickable", discoverable,self- 
describable URIs be preferable?

New URI schemes and protocols continue to be invented as is right and  
proper. Shouldn't they be encouraged to describe themselves through  
web technologies as new XML vocabularies are? Isn't HTTP a good choice  
for the universal fallback protocol?

###This message was lovingly handcrafted on a phone-like device###


On 27-Jul-08, at 12:59 AM, Tim Berners-Lee <timbl@w3.org> 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 14:03:45 UTC

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