Re: [Nbd] [PATCH v6 1/2] doc: Clean up wording about INFO then GO response

[Alex Bligh <alex@...872...>]

> 
> diff --git a/doc/proto.md b/doc/proto.md
> index f117394..a81b59c 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -743,6 +743,10 @@ Therefore these commands share common documentation.
>     to requests for exports that are unknown. This is so that clients
>     that have not negotiated TLS cannot enumerate exports.
> 
> +    For backwards compatibility, clients should be prepared to also
> +    handle `NBD_REP_ERR_UNSUP`. In this case, they should fall back to
> +    using `NBD_OPT_EXPORT_NAME`.

This back compatibility thing is the thing I thought should be a 'MUST'
but you and Wouter think (and I accepted) should be a 'SHOULD'. But
it should not be a 'should'. It's now - well it is
after MAY/SHOULD/MUST patch - a SHOULD elsewhere (search
for 'backwards'.

So s/should/SHOULD/ in both cases.

> +
>     In the case of `NBD_REP_SERVER`, the message's data takes on a different
>     interpretation than the default (so as to provide additional
>     binary information normally sent in reply to `NBD_OPT_EXPORT_NAME`,
> @@ -757,20 +761,13 @@ Therefore these commands share common documentation.
>     - 64 bits, size of the export in bytes (unsigned)
>     - 16 bits, transmission flags.
> 
> -    The server MUST NOT fail an NBD_OPT_GO sent with the same parameters
> -    as a previous NBD_OPT_INFO which returned successfully (i.e. with
> -    `NBD_REP_SERVER`) unless in the intervening time the client has
> -    negotiated other options. The server MUST return the same transmission
> -    flags with NBD_OPT_GO as a previous NBD_OPT_INFO unless in the
> -    intervening time the client has negotiated other options.
> -    The values of the transmission flags MAY differ from what was sent
> -    earlier in response to an earlier `NBD_OPT_INFO` (if any), and/or
> -    the server MAY fail the request, based on other options that were
> -    negotiated in the meantime.
> -
> -    For backwards compatibility, clients should be prepared to also
> -    handle `NBD_REP_ERR_UNSUP`. In this case, they should fall back to
> -    using `NBD_OPT_EXPORT_NAME`.

I'm a bit puzzled as to how that was a lowercase 'should' in the first
place. It's upper case after applying v5 of my SHOULD/MUST/MAY
patch. Just wondering in case there is anything else missed.

> +    If there are no intervening option requests between a successful
> +    `NBD_OPT_INFO` (that is, one that replied with `NBD_REP_SERVER`)
> +    and an `NBD_OPT_GO` with the same parameters, then the server MUST
> +    use an identical success response, including transmission flags.
> +    Otherwise, due to the intervening option requests or the use of
> +    different parameters, the server MAY send different transmission
> +    flags, and/or MAY fail the second request.

+1

>     The reply to an `NBD_OPT_GO` is identical to the reply to `NBD_OPT_INFO`
>     save that if the reply indicates success (i.e. is `NBD_REP_SERVER`),
> -- 
> 2.5.5
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Nbd-general mailing list
> Nbd-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
> 

-- 
Alex Bligh