W3C home > Mailing lists > Public > www-tag@w3.org > February 2014

Re: WEIRDS and use of fixed URIs

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Tue, 25 Feb 2014 19:00:17 +0900
Message-ID: <530C69B1.7020107@it.aoyama.ac.jp>
To: Mark Nottingham <mnot@mnot.net>
CC: Yves Lafon <ylafon@w3.org>, TAG List <www-tag@w3.org>, Tim Bray <tbray@textuality.com>
On 2014/02/21 15:28, Mark Nottingham wrote:
> Just a little more context here -- WEIRDS is trying to define a standard interface for accessing WHOIS data over HTTP using http(s):// URIs). It's doing so by saying that, given a URI prefix that's obtained out-of-band, you then can assume that resources with that base URI are laid out in a certain pattern.
>
> Depending on how that discussion goes, we may be forced to modify uri-get-off-my-lawn to allow what WEIRDS is doing, thereby setting precedent for other standards to constrain URIs for their applications.
>
> Tim Bray and I have been advocating against this practice strongly, and I expect the discussion to come to a head at the upcoming London IETF meeting. A statement (formal or not) from the TAG and/or TimBL would IMHO help preserve URI owners' control over their name space.

I have tried to come to Mark's and Tim's help in this discussion, 
because I think the general issue is very important. If there were no 
indirection at all, then that would be extremely bad.

However, given Mark's description above, I don't think what they are 
doing is actually too bad.

Let me give a (probably not even half-way appropriate, but anyway) 
example from the real world: Assume you buy a refrigerator. You can put 
that anywhere in your home (or outside if the garden is yours, too, or 
in somebody else's home if you get their permission). But there's very 
little if anything that you can configure inside the refrigerator. So 
nobody will put a refrigerator on your lawn if you don't want.

In that sense, it seems to be a reasonable compromise. You can put the 
WEIRDS interface on a server of your choice, at a path of your choice. 
But you can't tweak the structure below that path.

This may not be the ideal solution, but the ideal solution might include 
that the server owner can put the various resources involved at 
arbitrary, independent locations, increasing the bootstrap overhead.

As far as I understand, there's nothing in WebArch or anywhere else 
relevant that would forbid to put related resources at related 
locations. Indeed, putting related resources at related locations is a 
very widely used practice.

Also, there's nothing forbidding to put related resources in the same 
relative locations on different servers. In fact, one reason for the 
creation of relative URI references is exactly that whole URI 
(sub)hierarchies can be moved around or served from different locations 
at the same time.

So in conclusion, WEIRDS will get off your lawn (and be happy with using 
whatever space in whatever location you tell it to use), but as 
currently specified, it won't let you tweak internal details in the 
space it is assigned to. Actually, in some very general sense, WEIRDS 
could claim that others should get off its turf once it gets a little 
corner assigned to it.

Regards,   Martin.

> Cheers (and not wearing any hats),
>
>
>
> On 20 Feb 2014, at 12:14 am, Yves Lafon<ylafon@w3.org>  wrote:
>
>> Hi,
>> There is a discussion going on in apps-discuss [1] aboud weirds-bootstrap [2]
>> using a fixed URI path to address parts of their protocol.
>> This seems to go against the spirit of AWWW on URI opacity [3] and mnot's "URI Design and Ownership" draft.
>> Do the TAG want to be part of that discussion?
>> Cheers,
>>
>> [1] https://www.ietf.org/mail-archive/web/apps-discuss/current/msg11386.html
>> [2] https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/
>> [3] http://www.w3.org/TR/webarch/#uri-opacity
>> [4] https://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-01
>>
>> --
>> Baroula que barouleras, au tiéu toujou t'entourneras.
>>
>>         ~~Yves
>>
>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>
Received on Tuesday, 25 February 2014 10:01:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:01 UTC