Ballot for draft-nottingham-rfc7320bis
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
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 :-)
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
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'.
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.