Re: [Nbd] [PATCHv3] docs/proto.md: Clarify SHOULD / MUST / MAY etc

[Wouter Verhelst <w@...112...>]

On Wed, Apr 06, 2016 at 11:06:15PM +0100, Alex Bligh wrote:
> 
> On 6 Apr 2016, at 22:54, Wouter Verhelst <w@...112...> wrote:
> 
> >> No I think clients should be required to be back compatible. There is
> >> nothing however preventing them terminating the connection.
> > 
> > That does not describe MUST, it describes SHOULD...
> 
> I'm saying the client MUST respect (and deal with) NBD_REP_UNSUP;
> if they don't there is no back compatibility.
> 
> The client is always able to disconnect at any time. For instance
> if the user presses ^C. We don't have to explicitly say that, or
> weaken the 'MUST' do we?

Abortive, unclean, disconnects are not part of any proper protocol
specification. They are an exceptional situation.

In my reading of RFC2119, a MUST requirement is something that a
properly written client must NEVER fail. If it doesn't implement a
feature mandated by a MUST, that is a protocol violation.

A SHOULD requirement, on the other hand, is something that's desirable
in almost all situations, but can in some cases be ignored. That feels
way more appropriate here. An implementation that does not satisfy a
SHOULD requirement is possibly problematic, but isn't blatantly
violating the protocol.

Back-compat features are reasonably important when the old feature is
first obsoleted; but as time goes on they lose their relevance. If we
spell that down as a MUST, we can never deprecate them without telling
people to blatantly violating the protocol. Of course we could always
update the spec, but why not do it properly in the first place?

I think back-compat features are SHOULD, not MUST.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12