On 14 Apr 2016, at 14:59, Eric Blake <eblake@...696...> wrote: > On 04/14/2016 04:29 AM, Alex Bligh wrote: >> Eric, >> >>> +Both options have identical formats for requests and replies. The only >>> +difference is that after a successful reply to `NBD_OPT_GO` (i.e. zero >>> +or more `NBD_REP_INFO` then an `NBD_REP_EXPORT`), transmission mode is >>> +entered immediately. Therefore these commands share common >>> +documentation. >> >> So just to check, for an *unsuccessful* option, can I send a sequence >> of NBD_REP_INFO followed by (e.g.) NBD_REP_ERR_TLSREQD? > > Seems like a reasonable request, although I hadn't thought of it. It > risks leaking information, but there's nothing wrong with a SELECTIVETLS > server that doesn't mind leaking information. And indeed a FORCETLS server can reply with NBD_REP_ERR_TLSREQD. >> If I'm right above 'the final `NBD_REP_EXPORT` or error'. > > In fact, with your approach coupled with Wouter's desire to end on > NBD_REP_ACK rather than NBD_REP_EXPORT, it becomes 'zero or more > NBD_REP_INFO followed by NBD_REP_ERR_*, or at least one NBD_REP_INFO > followed by NBD_REP_ACK' Yes. > Okay. And thinking about it more, a server may indeed want to advertise > all names by which an export is known, so NBD_INFO_NAME could even be > given more than once (but then the wording needs to no longer call out > that it is a 'canonical' name). Mmmm ... maybe. I'm not actually quite sure what the purpose of sending the canonical name is, but if there is a purpose may be we should set a 'canonical' flag on that one. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail