URI Design and Ownership

Note: This ballot was opened for revision 04 and is now closed.

(Spencer Dawkins) Yes

Comment (2014-05-14 for -04)
No email
send info
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.

Barry Leiba Yes

(Ted Lemon) Yes

Comment (2014-05-13 for -04)
No email
send info
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!

(Pete Resnick) Yes

Comment (2014-05-13 for -04)
No email
send info
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".

(Jari Arkko) No Objection

(Benoît Claise) No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2014-05-21)
No email
send info
Thanks for addressing my DISCUSS and COMMENTs.

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-05-15 for -04)
No email
send info
-- 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

- 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.

- 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

- 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

- 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?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-05-14 for -04)
No email
send info
I support Stephen & Alissa's discusses and will watch for the outcome.  Thanks

(Martin Stiemerling) No Objection

(Richard Barnes) (was Discuss) Abstain

Comment (2014-06-03)
No email
send info
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.