URI Design and Ownership
RFC 8820

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

Benjamin Kaduk Yes

Comment (2020-01-22)
Thanks for the well-written document!  A few minor comments:

Section 2.1

   Applications and Extensions can require use of specific URI
   scheme(s); for example, it is perfectly acceptable to require that an
   Application support 'http' and 'https' URIs.  However, Applications
   ought not preclude the use of other URI schemes in the future, unless
   they are clearly only usable with the nominated schemes.

I'm having a little trouble squaring "can require specific schemes" with
"ought not preclude the use of other schemes".  How accurate would it be
to try to summarize this guidance as "specify what properties you need
the scheme to have, not the scheme itself"?

Section 2.4

side note: the discussion we give here about the flaws in assumptions
about query parameters named "sig" is more complete than the earlier
such discussion in Section 1; the earlier treatment is slightly
confusing without the additional context present here.  It's not really
clear that a forward reference would be appropriate, though, hence this
is just a side note.

Section 3

   Specifying more elaborate structures in an attempt to avoid
   collisions is not an acceptable solution, and does not address the
   issues in Section 1.  For example, prefixing query parameters with
   "myapp_" does not help, because the prefix itself is subject to the
   risk of collision (since it is not "reserved").

nit: I'm not sure what purpose the scare-quotes on "reserved" serve.
nit^2: the previous paragraph uses single-quotes around 'reserved'.

Alvaro Retana No Objection

Martin Vigoureux No Objection

Roman Danyliw No Objection

Warren Kumari No Objection

Comment (2020-01-21)
No email
send info
As asked by Eric, and the OpsDir review (Qin Wu - "I am curious why this bis document is not published through WG process but through individual stream process. If this document is published through individual steam process with AD sponsored, should this document be classified as informational? Where was this document initially discussed to build IETF consensus?") I'm also wondering why this wasn't a WG document -- anyway, I'm assuming the AD has a good reason, so, LGTM :-)

Éric Vyncke No Objection

Comment (2020-01-21)
No email
send info
Thank you for the work put into this document.  I have really appreciated the justifications and explanations. Just wondering why it is not a WG document.

-éric

(Adam Roach; former steering group member) Yes

Yes ()
No email
send info

(Alexey Melnikov; former steering group member) Yes

Yes ()
No email
send info

(Alissa Cooper; former steering group member) Yes

Yes ()
No email
send info

(Barry Leiba; former steering group member) Yes

Yes ()
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ()
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ()
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2020-01-20)
Please note the TSV-ART review (Thanks Joe!) and the issue raised regarding an outstaying errata on RFC7320 that may impact the change in this doc.

(Suresh Krishnan; former steering group member) No Objection

No Objection ()
No email
send info