[art] Benjamin Kaduk's Yes on draft-nottingham-rfc7320bis-03: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-nottingham-rfc7320bis-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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'.