On 04/11/2016 01:33 PM, Alex Bligh wrote: > These are changes which possibly have semantic effect > > * Clarify that SHOULD / MUST / MAY etc. when in capitals have an > RFC 2119 meaning using the wording within that RFC. > > * Fix some lowercase use of these words which actually were > meant to be uppercase. > > * Fix some lowercase 'should' which clearly meant 'MUST'; where > it's not obvious, I've made them 'SHOULD' or left them as is. > > * Fix wording on transmission flags to be clearer. > > Signed-off-by: Alex Bligh <[email protected]> > --- > doc/proto.md | 100 > +++++++++++++++++++++++++++++++++++------------------------ > 1 file changed, 59 insertions(+), 41 deletions(-) > > Changes since v5: > > * Rebased on top of "Improve documentation for TLS" > > * Eric's nit re NBD_OPT_INFO fixed in passing
> @@ -1031,20 +1049,19 @@ 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 > + 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 > + flags with `NBD_OPT_GO` as a previous `NBD_OPT_INFO` with the same > + parameters 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. This is what you were referring to above, although I still like my wording better (less repetitive). But I'm fine waiting for yours to land (it is a conflict magnet, and the sooner we get it in, the less we have to keep rebasing it) before reposting my wording improvements. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
