Re: [PATCH v2] doc: Define a standard URI syntax for NBD URIs.

[Wouter Verhelst <w@uter.be>]

On Wed, Jun 05, 2019 at 01:27:48PM -0500, Eric Blake wrote:
> We could, of course, teach qemu to support whatever this spec ends up
> with in addition to everything else; but there's also the point that the
> qemu code uses a consistent model for TLS across multiple entities (not
> just NBD, but also Spice, chardevs, ...), and then there's the question
> of whether a compatibility hack should be global to all of them or just
> to the NBD code.

I'm starting to think more and more that TLS certificate things should
not be part of the URL. If you think about it, all URLs are portable;
that is, you can take a URL from one host to the next, and it will just
work, and you don't need to change it. If you point to files on the
local file system from the URL, then that doesn't work anymore, which I
think breaks the paradigm of the URL. Of course with the obvious
exception of the file:// URL, which is supposed to point to a local
file...

Yes, in TLS you sometimes need to pass authentication tokens, but *how*
you do that is an implementation detail of the software you're using,
and I think standardizing that is a bad idea. After all, browsers also
don't standardize how you specify a client certificate to authenticate
with, and I think neither should we. I think it feels like a mistake to
do so.

(yes, I know I made the initial suggestion, but still)

[...]
> > There ought to be a way to specify the TLS priority string to control
> > what valid cipher settings are.

I think that too is not something that needs to be done as part of the
URL. After all, if you want to set a TLS priority string on one
connection, you probably want to set it on *all* connections, so it's
not something specific to a particular connection, which it would be for
options you specify in a URL.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard