URI Design and Ownership
draft-nottingham-rfc7320bis-03
Yes
(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Barry Leiba)
No Objection
Roman Danyliw
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 03 and is now closed.
Roman Danyliw
No Objection
Warren Kumari
No Objection
Comment
(2020-01-21)
Not sent
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)
Sent for earlier
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 IESG member
Yes
Yes
()
Unknown
Alexey Melnikov Former IESG member
Yes
Yes
()
Not sent
Alissa Cooper Former IESG member
Yes
Yes
()
Not sent
Barry Leiba Former IESG member
Yes
Yes
()
Not sent
Benjamin Kaduk Former IESG member
Yes
Yes
(2020-01-22)
Sent
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 Former IESG member
No Objection
No Objection
()
Not sent
Deborah Brungard Former IESG member
No Objection
No Objection
()
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
()
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2020-01-20)
Sent
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 IESG member
No Objection
No Objection
()
Not sent