Re: [PATCH v3] doc: Define a standard URI syntax for NBD URIs.
On Tue, Jun 11, 2019 at 11:31:08AM -0500, Eric Blake wrote:
> On 6/11/19 9:22 AM, Martin Kletzander wrote:
> > On Tue, Jun 11, 2019 at 12:53:30PM +0100, Richard W.M. Jones wrote:
> >> For further information about discussion around this standard, see
> >> this thread on the mailing list:
> >> https://lists.debian.org/nbd/2019/05/msg00013.html
> >>
>
> >> +## Other NBD URI query parameters
> >> +
> >> +Clients SHOULD prefix experimental query parameters using `x-`. This
> >> +SHOULD NOT be used for query parameters which are expected to be
> >> +widely used.
> >> +
> >> +Any other query parameters which the client does not understand SHOULD
> >> +be ignored by the parser.
> >> +
> >
> > Everything seems good to me, I just have one "idea". I, however, am not
> > sure
> > whether it might be helpful or utterly stupid. But since I would never
> > forgive
> > myself not mentioning it, here goes:
> >
> > TL;DR: Is it worth to care about
> > versioning/some-kind-of-forward-compatibility?
>
> That may actually be a good idea.
I'm not sure it is, tbh.
> > If there is a new query parameter added later on, which would significantly
> > change the behaviour (or security), then a client might want to depend
> > on it not
> > being ignored by the parser (e.g. if just ignoring it would cause a
> > security
> > concern).
> >
> > What I thought of would be another parameter that would specify which other
> > parameters must be supported, so that the client quits if any of them is
> > unknown. On the other hand it should be perfectly fine to make sure new
> > enough
> > version of the client is used.
>
> So, you're asking for some way to know that ?foo=bar is supported by the
> client, by having a way to fail if the client doesn't know how to parse
> the foo query. What if we document mandatory support for a parameter
> '?features=comma,list,of,names', where a client MUST fail to parse the
> URI if it does not recognize one of the feature names from the list
> given to features? Then we can have:
>
> nbd://host/?foo=bar
> - okay to ignore query foo= as unknown
> nbd://host/?foo=bar&features=foo
> - client MUST fail to parse URI unless it also knows how to parse the
> foo query parameter
>
> The initial set of features mandated by the NBD URI spec is 'features'
> for self-description, as well as 'socket' for Unix but not necessarily
> TCP. Then the queries '?features=' and '?features=features' must both
> succeed, the query '?features=socket' depends on the scheme, and any
> other '?features=...' query becomes a feature probe.
I think you're overthinking it here. We could just say that a client
which does not recognize a parameter should just balk? After all, a URI
is something that in most cases would be passed on the command line, or
some such; the feedback to the user would be fairly quick. Additionally,
I can't think of any extra feature that we might want to add to the URL
but which might be optional...
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: