On 14 Apr 2016, at 16:37, Eric Blake <eblake@...696...> wrote: >> >> >> And indeed a FORCETLS server can reply with NBD_REP_ERR_TLSREQD. >> > > Technically, a FORCETLS server MUST reply with NBD_REP_ERR_TLS_REQD, > without any intervening NBD_REP_INFO. Yes, indeed. > Only a SELECTIVETLS server MAY > send intervening NBD_REP_INFO before ultimately failing (as in, "I'm > willing to tell you details about the export, but I will conclude by > telling you that you must upgrade to TLS before relying on those details"). Or "I can tell you this much, but for more you will need to upgrade to TLS". If it wants! >>> 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. > > That argues that either we add a canonical field to NBD_INFO_NAME, or we > have two separate types: NBD_INFO_CANONICAL_NAME (at most once), and > NBD_INFO_ALTERNATE_NAME (as many as wanted). I don't have any strong > preferences about the need or desire to expose more than one name; > anyone else want to chime in on whether I'm over-engineering things for > current needs? TBH I don't know why it sends the name back in the first place. But for now I would suggest leaving it as sending back a single canonical name. We can add more bells and whistles later if need be. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail