URI Design and Ownership
draft-ietf-appsawg-uri-get-off-my-lawn-05

[Ballot comment]
As the document is currently written, I cannot support it.  The restrictions it imposes are pretty onerous, and the rationales for the most part very vague.  I suspect that I actually agree with a large part of the content, but as written, especially with so little rationale, I'm concerned that it's over-broad, and will be used to block protocols that are actually innocuous.  If the document said, "If you're tempted to do X; you SHOULD NOT because Y; you SHOULD really do Z", I would probably be a YES.  But instead it reads mostly as "You MUST NOT do X" -- little explanation Y, little help Z.

All that said, though, I've gotten feedback from a few members of the community, and it appears that they understand the document differently than I do, and they're OK with it.  So I have cleared my DISCUSS.

I hope there is some follow-up, though, to beef up the rationales in this document, make the proscriptions more precise, and provide better guidance for developers.

[Ballot comment]
As the document is currently written, I cannot support it.  The restrictions it imposes are pretty onerous, and the rationales for the most part very vague.  I suspect that I actually agree with a large part of the content, but as written, especially with so little rationale, I'm concerned that it's over-broad, and will be used to block protocols that are actually innocuous.  If the document said, "If you're tempted to do X; you SHOULD NOT because Y; you SHOULD really do Z", I would probably be a YES.  But instead it reads mostly as "You MUST NOT do X" -- little explanation Y, little help Z.

All that said, though, I've gotten feedback from a few members of the community, and it appears that they understand the document differently than I do, and they're OK with it.  So I have cleared my DISCUSS.

[Ballot comment]

-- These were my discuss points. I still need to update
them based on the discussion (and will hopefully before
the end of the telechat;-) but wanted to clear before
the start of the call.

1) Section 2 uses terms from 1.1 to distinguish various
things, but 1.1 is very vague in defining the set of
specifications to which this BCP is meant to apply. Why
won't this cause loads of argument later about
so-and-so I-D that e.g. defines {whatever}/myapp being
covered by this or not? Seems to me it will. I'll clear
on this once you've responded, since we already have
those arguments so we're no worse off in that respect
with this, but I'd like to at least ask if you can
better define the target specifications to which you
want this BCP to apply.

2) 2.2: what about the port number in authority,
doesn't that need a mention?

3) 2.3 says {whatever}/myapp is bad, and depends on the
intro for why ("operational difficulty") but that part
of the intro only IMO shows that collisions are bad,
(see my comment below) which does not seem to justify
the conclusion that this (fairly common) practice is
really bad since {whatever} can be chosen to make
collision probability as small as you like. I don't get
the justification for this to be honest.

4) 2.4, 3rd para: is this outlawing the practice of
defining how to handle your message as an HTTP form?
E.g. as an alternative to a POST body. Is that a good
plan? And why "SHOULD NOT" - when is it ok to do this?

5) section 3: I wondered which of these techniques is
in wide-spread use? If none, then how is this credibly
a BCP? Is it not the case that the techniques that are
outlawed here are is more common use than those that
are recommended? (To clear this bit for me, a simple
statement of the reality would be sufficient, though
another LC might be warranted then perhaps.)

--- These are my (old) comments

- general: BCP UPDATES STD. My head spins, but I don't
complain:-) I hope a) nobody does complain, and b)
nobody tries to explain to me why that's ok, or not
ok:-)

- general: I wondered if the authors or appsawg have
really checked if this all makes sense for all existing
URI schemes. Isn't having done that part of the work
here? (I'm not trying to trap you with an undisclosed
counter-example for when you say you have btw:-)

- general: I was surprised you don't list some of the
existing counter-examples (e.g. robots.txt)

- intro, "Dilution" - Are missing a bit of the
argument?  Is the "missing" bit is that structured data
from non-owner specifications is quite likely to
contain ephemeral data as values, e.g.
"recordNo=3893243" 

- intro, "Operational difficulty" - this overlaps with
"Collisions" - couldn't you craft an example that
doesn't? If not, is this really a separate point to
make here?

- intro, "Client assumptions" - the example only leads
to undesirable behaviour if someone deploys with
"mySig" and not "sig", so I'm not sure this is relevant
here as either a) the specification said you could use
another name in which case that's a dumb spec, or b)
the server isn't implementing the spec. Neither seems
really due to representing the structured data in the
URI.

- intro, 2nd last para: what is an "independent
standard"?  I think saying "IETF specification" would
be better. (And nittily: s/usurp it./usurp that./)

- intro, last para: s/explains/explains some/ or are
you claiming there are no others or that any others
discovered or invented ought also update this proposed
BCP?

- 1.1 - the section title lead me to believe that types
of person and not types of specification would be
identified, which isn't what's in the body of the
section.  Maybe s/specification/specification writer/
generally in the body or change the title?

- 2.1 - does "SHOULD NOT preclude" mean that you SHOULD
define which URI schemes work with your protocol and
which do not?  I think this'd be better stated as a
positive really, for clarity.

- 2.3, s/cannot/ought not/ or use a 2119 term. People
clearly can, and have written specs with "/myapp"
hardcoded therein.

- 2.4, 2nd para: I don't get why this is true.

- 2.4, 3rd para: What does "MUST NOT specify" mean
really?  Its a pretty odd phrase.

- 2.4, last para: not a great example since a signature
can be verified or not by its value.

- 2.5: I don't get why only media types are allowed to
specify fragment syntaxes. I mean why does that make
sense? If its for purely historic reasons, maybe say
that. (And why can't I dress any old crap up as a
media-format and get around this BCP that way?)

- section 3: I don't myself buy that collision
improbability isn't a good enough solution, but that's
just my opinion (hence not a discuss), but shouldn't
you say why? E.g. why is a prefix of "myapp_rand()_"
not good enough?

[Ballot discuss]
As Alissa points out, I suspect that a lot of the considerations here are specific to HTTP.

I'm concerned that this document reflects a few assumptions about URIs that look really odd when you compare them to what we normally assume about protocol fields.

In general, this document seems to reverse an important implication.  The following are not equivalent:
  protocol => format
  format => protocol
The former is usually true; the latter usually false.  Protocols define formats all the time -- that's 80% of what a protocol is.  This document seems to assume, however, that just because one protocol uses a given format, then anything that uses that format belongs to that protocol. 

This seems like an assumption that we don't really make anywhere else.  If an HTTP-based protocol were to require request bodies to have a particular content type, for example, it would be entirely non-controversial.  We would not assume that all requests with that content type belonged to that protocol.  Why are URIs privileged?

In other words, this document says that it's OK for protocols to extract information from a URI, but they have to take what they get -- they can't require that the URIs have any particular format.  This seems dramatically different from how other protocol fields are handled.  Usually applications are free to examine received protocol elements however they like, and say "No, that's not OK" if they don't like the contents.  Why are URIs privileged?

Now, I don't entirely disagree with the risks called out in the document.  There is a risk of confusion if you specify components in a URI, and there is a risk of rigidity if URIs are constrained in bad ways.  My problem with this document is more with regard to how it approaches these risks.  Rather than calling out these risks and advising protocol designers on how to avoid them -- while still allowing URIs to be structured by protocols, making informed trade-offs -- the document forces a risk judgement on all future protocols.

[Ballot comment]
My Yes is anticipating a resolution to discussions with Alissa and with Stephen (and anyone else who's balloting after me), but this seems exactly the kind of BCP we should be producing, and I for one have no concerns with updating a standards-track specification with a BCP that's clear that it's doing the update.

[Ballot comment]
I am disappointed by the lack of examples of operational difficulties in the last paragraph of 2.3 and the second paragraph of 2.4. I also don't understand the SHOULD NOT (instead of the MUST NOT) in 2.4.

In 2.4, please strike "is not conforming; doing so".

In 2.5, please strike "is not conforming, and".

[Ballot comment]
In section 1.1:
  o  Protocol Extensions ("extensions") - specifications that offer new
      capabilities to potentially any identifier, or a large subset;
      e.g., a new signature mechanism for 'http' URIs, or metadata for
      any URI.

"potentially any" is a really awkward construction which I first read as a typo, and which potentially could confuse non-native speakers.  The RFC editor will probably notice this as well, but I would suggest phrasing it thusly:

  o  Protocol Extensions ("extensions") - specifications that offer new
      capabilities that could apply to any identifier, or to a large subset of
      possible identifiers; e.g., a new signature mechanism for 'http'
      URIs, or metadata for any URI.

Aside from this nit, this is a really good document and I'm happy to see it moving forward!

[Ballot discuss]
(1) I had the same thought when reading this as Stephen commented about in reference to whether all of this guidance makes sense for all URI schemes, or whether it is actually motivated by activity going on in relation to http: and https: and not other schemes. In general the guidance seems widely applicable but I'm a little uncomfortable assuming that there aren't any situations where sip: or tel: URIs might be used differently enough that deviating from what this document says has in the past or will in the future seem like the right thing to do. So it would be helpful to hear about why the guidance in this document makes sense for all URIs.

(2) Section 2.1:
"A specification that defines substructure within a URI scheme MUST do
    so in the defining document for that URI scheme, or by modifying
    [RFC4395]."

I don't understand the bit about modifying RFC 4395. First of all, RFC 4395
is quite general, so it seems odd that a single prospective scheme specifier
would go modify that document just to be able to define a substructure
within a URI scheme. Furthermore, I'm wondering if the real point here is to
say that once scheme substructures are initially defined, they cannot be
modified in the future. I don't really read that anywhere in RFC 4395, but
if that is the implication here, why not just make that statement another
recommendation of this BCP, and skip the bit about modifying RFC 4395?

[Ballot comment]
Section 2.1:
"However, applications
  SHOULD NOT preclude the use of other URI schemes in the future,
  unless they are clearly specific to the nominated schemes."

"Clearly specific to the nominated schemes" is a vague enough standard that I wonder whether this is really worth saying at all. That is, isn't this what specifications generally already do anyway? What is driving spec authors to overly constrain future URI scheme use other than the "specificity" of the application in question?

[Ballot discuss]

1) Section 2 uses terms from 1.1 to distinguish various
things, but 1.1 is very vague in defining the set of
specifications to which this BCP is meant to apply. Why
won't this cause loads of argument later about
so-and-so I-D that e.g. defines {whatever}/myapp being
covered by this or not? Seems to me it will. I'll clear
on this once you've responded, since we already have
those arguments so we're no worse off in that respect
with this, but I'd like to at least ask if you can
better define the target specifications to which you
want this BCP to apply.

2) 2.2: what about the port number in authority,
doesn't that need a mention?

3) 2.3 says {whatever}/myapp is bad, and depends on the
intro for why ("operational difficulty") but that part
of the intro only IMO shows that collisions are bad,
(see my comment below) which does not seem to justify
the conclusion that this (fairly common) practice is
really bad since {whatever} can be chosen to make
collision probability as small as you like. I don't get
the justification for this to be honest.

4) 2.4, 3rd para: is this outlawing the practice of
defining how to handle your message as an HTTP form?
E.g. as an alternative to a POST body. Is that a good
plan? And why "SHOULD NOT" - when is it ok to do this?

5) section 3: I wondered which of these techniques is
in wide-spread use? If none, then how is this credibly
a BCP? Is it not the case that the techniques that are
outlawed here are is more common use than those that
are recommended? (To clear this bit for me, a simple
statement of the reality would be sufficient, though
another LC might be warranted then perhaps.)

[Ballot comment]

- general: BCP UPDATES STD. My head spins, but I don't
complain:-) I hope a) nobody does complain, and b)
nobody tries to explain to me why that's ok, or not
ok:-)

- general: I wondered if the authors or appsawg have
really checked if this all makes sense for all existing
URI schemes. Isn't having done that part of the work
here? (I'm not trying to trap you with an undisclosed
counter-example for when you say you have btw:-)

- general: I was surprised you don't list some of the
existing counter-examples (e.g. robots.txt)

- intro, "Dilution" - Are missing a bit of the
argument?  Is the "missing" bit is that structured data
from non-owner specifications is quite likely to
contain ephemeral data as values, e.g.
"recordNo=3893243" 

- intro, "Operational difficulty" - this overlaps with
"Collisions" - couldn't you craft an example that
doesn't? If not, is this really a separate point to
make here?

- intro, "Client assumptions" - the example only leads
to undesirable behaviour if someone deploys with
"mySig" and not "sig", so I'm not sure this is relevant
here as either a) the specification said you could use
another name in which case that's a dumb spec, or b)
the server isn't implementing the spec. Neither seems
really due to representing the structured data in the
URI.

- intro, 2nd last para: what is an "independent
standard"?  I think saying "IETF specification" would
be better. (And nittily: s/usurp it./usurp that./)

- intro, last para: s/explains/explains some/ or are
you claiming there are no others or that any others
discovered or invented ought also update this proposed
BCP?

- 1.1 - the section title lead me to believe that types
of person and not types of specification would be
identified, which isn't what's in the body of the
section.  Maybe s/specification/specification writer/
generally in the body or change the title?

- 2.1 - does "SHOULD NOT preclude" mean that you SHOULD
define which URI schemes work with your protocol and
which do not?  I think this'd be better stated as a
positive really, for clarity.

- 2.3, s/cannot/ought not/ or use a 2119 term. People
clearly can, and have written specs with "/myapp"
hardcoded therein.

- 2.4, 2nd para: I don't get why this is true.

- 2.4, 3rd para: What does "MUST NOT specify" mean
really?  Its a pretty odd phrase.

- 2.4, last para: not a great example since a signature
can be verified or not by its value.

- 2.5: I don't get why only media types are allowed to
specify fragment syntaxes. I mean why does that make
sense? If its for purely historic reasons, maybe say
that. (And why can't I dress any old crap up as a
media-format and get around this BCP that way?)

- section 3: I don't myself buy that collision
improbability isn't a good enough solution, but that's
just my opinion (hence not a discuss), but shouldn't
you say why? E.g. why is a prefix of "myapp_rand()_"
not good enough?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-uri-get-off-my-lawn-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (URI Design and Ownership) to Best Current Practice


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'URI Design and Ownership'
  as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-05-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  RFC3986 Section 1.1.1 defines URI syntax as "a federated and
  extensible naming system wherein each scheme's specification may
  further restrict the syntax and semantics of identifiers using that
  scheme."  In other words, the structure of a URI is defined by its
  scheme.  While it is common for schemes to further delegate their
  substructure to the URI's owner, publishing independent standards
  that mandate particular forms of URI substructure is inappropriate,
  because that essentially usurps ownership.  This document further
  describes this problematic practice and provides some acceptable
  alternatives for use in standards.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Who is the document shepherd? Martin Thomson
Who is the responsible Area Director? Barry Leiba

The draft describes how URI structure is specified; specifically,
that standards SHOULD NOT specify structure in URIs (and why).

The intended status is BCP.  This document codifies what is best
practice, in part to help prevent (or aid in preventing) bad practices
that continue to emerge in this area.

2. Review and Consensus

This document has had positive feedback and strong support from the
working group.  A number of reviews from people in the web community
resulted in only minor additions.

3. Intellectual Property

No IPR disclosures or concerns.

4. Other Points

The current version claims to update RFC 3986, but doesn't provide any
hint as to why.