On 5/28/19 5:35 AM, 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
>
> Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
> ---
> doc/Makefile.am | 2 +-
> doc/uri.md | 183 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 184 insertions(+), 1 deletion(-)
>
> +## NBD URI export name
> +
> +The path part of the URI except for the leading `/` character MAY be
> +passed to the server as the export name.
> +
> +For example:
> +
> + NBD URI Export name
> + ----------------------------------------------------
> + nbd://example.com/disk disk
> + nbd+unix:///disk disk
Should this use:
nbd+unix:///disk?socket=/foo disk
to comply with the other statements that the socket query should be
present for nbd+unix://, and to give an example of how the query is not
part of the export name?
> +## NBD URI socket parameter
> +
> +If the scheme name indicates a Unix domain socket then the query
> +parameters MUST include a `socket` key, referring to the Unix domain
> +socket which on Unix-like systems is usually a special file on the
> +local disk.
> +
> +On platforms which support Unix domain sockets in the abstract
> +namespace, and if the client supports this, the `socket` parameter MAY
> +begin with an ASCII NUL character. When the URI is properly encoded
> +it will look like this:
> +
> + nbd+unix:///?socket=%00/abstract
> +
...
> +
> +## Clients which do not support TLS
> +
> +Wherever this document refers to encryption, authentication and TLS,
> +clients which do not support TLS SHOULD give an error when
> +encountering an NBD URI that requires TLS (such as one with a scheme
> +name `nbds`).
> \ No newline at end of file
You'll want to fix that :)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature