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

[Eric Blake <eblake@...696...>]

The wording was a bit repetitive, but at the same time had a
flaw: it implied that INFO(name1) followed immediately by
GO(name2) would give the same transmission flags.  Make it
clear that the identical success response is only in the case
of the same parameters.

Meanwhile, swap paragraph ordering so that NBD_REP_SERVER
details aren't split by a side-note about NBD_REP_ERR_UNSUP.

Signed-off-by: Eric Blake <eblake@...696...>
---
 doc/proto.md | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

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`.
+
     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`.
+    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.

     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