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

[Mark Nottingham <[e-mail]>]

Hi Ben,

> On 23 Jan 2020, at 2:14 pm, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 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"?

Not really. 

For example - my application might require implementations to support http schemes, but shouldn't say "never use the foo scheme."


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

Ack. Will take another look.


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

The RFC Production Centre is well-acquainted with my penchant for "scare quotes", and will "deal" with me (and them) later.

Thanks,


--
Mark Nottingham   https://www.mnot.net/