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.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.
That is almost identical to what I had in mind. To be honest I cannot think of anything for which this might be needed (apart from tls-verify-peer which would have security implications). But one never knows and I very well know the feeling of "well, if we added _this_ harmless thing back in the day, we wouldn't need to deal with all _that_". And it's a basically a type of thing that needs to be added right from the start, otherwise it doesn't make sense. On the other hand this is just a URI and there are already some clients that accept some variations of it, so it might be too late anyway. Anyway, thanks for elaborating on the topic.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: PGP signature