URI Design and Ownership
draft-ietf-appsawg-uri-get-off-my-lawn-05
Yes
(Barry Leiba)
No Objection
(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
Abstain
Note: This ballot was opened for revision 04 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -04)
Unknown
Pete Resnick Former IESG member
Yes
Yes
(2014-05-13 for -04)
Unknown
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".
Spencer Dawkins Former IESG member
Yes
Yes
(2014-05-14 for -04)
Unknown
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.
Ted Lemon Former IESG member
Yes
Yes
(2014-05-13 for -04)
Unknown
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!
Adrian Farrel Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2014-05-21)
Unknown
Thanks for addressing my DISCUSS and COMMENTs.
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-05-14 for -04)
Unknown
I support Stephen & Alissa's discusses and will watch for the outcome. Thanks
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-05-15 for -04)
Unknown
-- 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?
Richard Barnes Former IESG member
(was Discuss)
Abstain
Abstain
(2014-06-03)
Unknown
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.