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

Thanks for addressing my DISCUSS and COMMENTs.

I support Stephen & Alissa's discusses and will watch for the outcome.  Thanks

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