[rfc-i] Drafting issue... use of MAY

Carsten Bormann cabo at tzi.org
Wed May 2 18:16:21 PDT 2018

> On May 3, 2018, at 01:49, Barry Leiba <barryleiba at computer.org> wrote:
> What value does the “MAY" give you there?  

It constrains the client, requiring it to be able to interoperate with a server that may or may not exhibit the described behavior (i.e., it also constrains the client not to rely on this behavior).

> Why might I close the
> session?  Why might I not?  How do I decide?  

This (the behavior of the side that MAY) is not constrained by the MAY.
MAY is constraining the other side.

> What, exactly, is it
> that you, the spec writer, are telling me to *do* by using "MAY"
> there?

See above.

This is all described nicely in the paragraph from RFC 2119 that I cited in a previous message in the thread.
(There is a reason we make RFC 2119 a normative reference…)


Now, the deviation from logic that needs to be rooted out happens when specs say:

The server MAY A or B.

According to logic and the definition in RFC 2119, this means: (A or B) is OPTIONAL, i.e. the server might A, B, or none of them; the client needs to prepare for handling all three cases.

But due to our usage of the English language, such a disjunction is often meant or read as: The server is constrained to either A or B, no other behavior is permitted of the server.
This reading is not supported by RFC 2119.
There would need to be a MUST NOT for the other behavior — note that RFC 2119 does not define “MAY NOT”!
This deviating reading does appear to be common (and questionable) usage.

Grüße, Carsten

> Barry
> On Wed, May 2, 2018 at 5:37 PM, Carsten Bormann <cabo at tzi.org> wrote:
>> On May 2, 2018, at 21:25, Barry Leiba <barryleiba at computer.org> wrote:
>>>  When <this happens> the server MAY close the client session."
>>>  When <this happens>, the server is likely to close the client
>>>  session, and clients MUST be able to handle that situation.
>> Not better.  Circumlocution does not help.  The MAY version here is exactly what you should write in this case.
>> (Of course, for more specific values of “handle that situation”, the MUST version may be appropriate.
>> But unsubstantiated judgement calls such as “is likely to” don’t belong into the spec.)
>> Grüße, Carsten
> -- 
> Barry
> --
> Barry Leiba  (barryleiba at computer.org)
> http://internetmessagingtechnology.org/

More information about the rfc-interest mailing list