Subject: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn

From: Tim Bray <[email-masked]>
Date: Thu, 5 Dec 2013 22:22:07 -0800

I think this should be published as a Best Common Practice soon as possible.

Minor issues:

* The title and introduction:

“Standardising Structure in URIs“ is unfortunate because the central
message is “Don’t try to standardize structure in URIs”. How about
“Preserving URI Space Design Freedom” or “URI Structure Design Considered
Harmful” or “URI Space Design Ownership” - I think that last one is a
serious suggestion.

: This document cautions against this practice in standards (sometimes
called "URI Squatting").

I’m not sure the “sometimes called” parenthetical really adds value, but if
preserved, it should be moved to immediately after “this practice”. Also,
the document doesn’t caution against it, it bristles with MUST NOTs.  How
about “This document is intended to prevent the use of this practice
(sometimes called "URI Squatting") in standards.”

* 1. Introduction

The bullet point beginning “Dilution” is grammatically strained.  The
“extra information” is the subject of both verbs, so turn it around to read
something like “Extra information, added to URIs to support
standardization, dilutes their usefulness as ..., and causes alternate
forms of the URI to exist.  And I’m not sure Dilution is the right label;
the key point is weakening the URI’s utility as an identifier. Having said
that I can’t think of a one-word alternative.

In that list of bullet points, you might also want to add that query
parameters are problematic for two more reasons: There’s not a good hook in
3986 to use to say what you’re talking about, and also you’re doing a
parameter-name land-grab, which means you now have another design problem,
you have to prefix or otherwise clutter your parameter names to in effect
create a namespace for them.  Or worse, don’t.

2nd-last para:  The phrase that begins “publishing standards that mandate
URI structure is inappropriate... ” is the central tl;dr of this whole
draft, very nicely crystallized. Could it be pulled out and featured in the
introduction or even abstract?

* 2.

“Different components of a URI have differing practices recommended.”
Passive voice, turn it around: “Best practices differ depending on the URI
component”, or some such.

* 3.

I think you could just subtract this whole section and not much would be
lost. I think you’re trying to hint at HATEOS without actually naming it.
 In particular, I find the second paragraph entirely baffling, and have no
idea what it’s trying to say.

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 6 Dec 2013 08:43:05 +0100

On 06.12.2013, at 07:22, Tim Bray <[email-masked]> wrote:

> 
> * 3.
> 
> I think you could just subtract this whole section and not much would be lost. I think you’re trying to hint at HATEOS without actually naming it.  In particular, I find the second paragraph entirely baffling, and have no idea what it’s trying to say.

I (think) Mark is referring to using something like JSON-Home[1] to have clients discover URIs at runtime.

Jan

[1] http://tools.ietf.org/html/draft-nottingham-json-home-03

> 
> 
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Erik Wilde <[email-masked]>
Date: Fri, 06 Dec 2013 09:40:55 -0800

hello all.

On 2013-12-05, 22:22 , Tim Bray wrote:
> “Preserving URI Space Design Freedom” or “URI Structure Design
> Considered Harmful” or “URI Space Design Ownership” - I think that last
> one is a serious suggestion.

reading this, there's another issue that i regularly run into in various 
designs, which might be useful to mention in the document: it's the 
question of whether a URI used in some representation is meant as an 
identifier only, or as a retrievable resource.

XML namespace URIs are a very popular example. and then there's the 
famous example of the HTML DTD URI which until this day generates 
substantial amounts of pretty useless traffic, because software accesses 
it instead of just using it as an identifier.

maybe it would be helpful to add a section saying that if a standard 
intends a URI to be an identifier only, it SHOULD clearly say so, and it 
SHOULD discourage clients from accessing it. clients SHOULD be 
encouraged to use comparison (as opposed to access) as the only 
meaningful operation for these kinds of URIs.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Dec 2013 10:54:03 -0800

On Dec 6, 2013, at 9:40 AM, Erik Wilde <[email-masked]> wrote:

> reading this, there's another issue that i regularly run into in various designs, which might be useful to mention in the document: it's the question of whether a URI used in some representation is meant as an identifier only, or as a retrievable resource.

<wishing there was a Like button on IETF mailing list so I could poke a million times>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Dec 2013 11:21:54 -0800

> <wishing there was a Like button on IETF mailing list so I could poke a million times>

I used to find this annoying, but I got over.  In the realm of
annoyances, this just doesn't rate that highly any more for me.

That said, it is definitely an issue.  My main concern is that I don't
see how this fits into the draft in question.  I'd in support of
publishing that one liner for sure, but think perhaps it's
inappropriate to throw more turnips on this particular donkey cart,
just because it's headed in the right direction.

---

From: Tim Bray <[email-masked]>
Date: Fri, 6 Dec 2013 11:31:32 -0800

We could have a lot of arguments about this, but I think it’s orthogonal to
the issue Mark is trying to address in an admirably tightly-focused way in
the draft.

On Fri, Dec 6, 2013 at 9:40 AM, Erik Wilde <[email-masked]> wrote:

> XML namespace URIs are a very popular example. and then there's the famous
> example of the HTML DTD URI which until this day generates substantial
> amounts of pretty useless traffic, because software accesses it instead of
> just using it as an identifier.
>
> SHOULD discourage clients from accessing it. clients SHOULD be encouraged
> to use comparison (as opposed to access) as the only meaningful operation
> for these kinds of URIs.
>
> cheers,
>
> dret.
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 7 Dec 2013 16:39:56 +1100

Thanks, Tim — all good feedback, will try to incorporate and come back if I have issues.

On 6 Dec 2013, at 5:22 pm, Tim Bray <[email-masked]> wrote:

> “Standardising Structure in URIs“ is unfortunate because the central message is “Don’t try to standardize structure in URIs”. How about “Preserving URI Space Design Freedom” or “URI Structure Design Considered Harmful” or “URI Space Design Ownership” - I think that last one is a serious suggestion.
> 
> : This document cautions against this practice in standards (sometimes called "URI Squatting").
> 
> I’m not sure the “sometimes called” parenthetical really adds value, but if preserved, it should be moved to immediately after “this practice”. Also, the document doesn’t caution against it, it bristles with MUST NOTs.  How about “This document is intended to prevent the use of this practice (sometimes called "URI Squatting") in standards.”
> 
> * 1. Introduction
> 
> The bullet point beginning “Dilution” is grammatically strained.  The “extra information” is the subject of both verbs, so turn it around to read something like “Extra information, added to URIs to support standardization, dilutes their usefulness as ..., and causes alternate forms of the URI to exist.  And I’m not sure Dilution is the right label; the key point is weakening the URI’s utility as an identifier. Having said that I can’t think of a one-word alternative.
> 
> In that list of bullet points, you might also want to add that query parameters are problematic for two more reasons: There’s not a good hook in 3986 to use to say what you’re talking about, and also you’re doing a parameter-name land-grab, which means you now have another design problem, you have to prefix or otherwise clutter your parameter names to in effect create a namespace for them.  Or worse, don’t.
> 
> 2nd-last para:  The phrase that begins “publishing standards that mandate URI structure is inappropriate... ” is the central tl;dr of this whole draft, very nicely crystallized. Could it be pulled out and featured in the introduction or even abstract?
> 
> * 2.
> 
> “Different components of a URI have differing practices recommended.” Passive voice, turn it around: “Best practices differ depending on the URI component”, or some such.
> 
> * 3.
> 

--
Mark Nottingham   http://www.mnot.net/