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

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 May 2018 10:17:49 -0400

Quite often in a spec, I find myself writing something like this:

A Frame MAY be either buffered or unbuffered...

Frames are either buffered or unbuffered...

Which is correct? I am thinking the second because it is not actually
normative, it is by definition which is not the same thing.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 01 May 2018 07:56:00 -0700

> normative, it is by definition which is not the same thing.

The latter seems better to me for the exact reason you give.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 May 2018 11:00:09 -0400

The reason this became a concern was that I turned on a doohickey in my
document formatting tool which compiles tables of MUST/MAY/SHOULD for
conformance.

Minimizing the number of MAYs becomes a bigger concern when you see the
consequences.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 May 2018 17:04:51 +0200

> The latter seems better to me for the exact reason you give.

+1000

Best regards, Julian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 1 May 2018 09:34:58 -0700

On 5/1/18 8:00 AM, Phillip Hallam-Baker wrote:
> The reason this became a concern was that I turned on a doohickey in 
> my document formatting tool which compiles tables of MUST/MAY/SHOULD 
> for conformance.
>
> Minimizing the number of MAYs becomes a bigger concern when you see 
> the consequences.

Requirements language isn't all about MUST; the other words are equally 
important.

>
> On Tue, May 1, 2018 at 10:56 AM, Paul Hoffman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

Agreed.

-Heather

---

From: "John Levine" <[email-masked]>
Date: 1 May 2018 13:03:08 -0400

>normative, it is by definition which is not the same thing.

I agree.  It is a good idea to reread RFC 2119 every once in a while
to remember what the words mean.

MUST doesn't mean "do this or die", it means "do this if you want to
interoperate."  MAY means there are different ways to do something all
of which will interoperate.

I find relatively few uses for MAY, but one of them would be "letters
in domain names MAY be in uppper or lower case."

R's,
John

---

From: Dave Thaler <[email-masked]>
Date: Tue, 1 May 2018 17:22:38 +0000

John Levine writes:
> I find relatively few uses for MAY, but one of them would be "letters in domain names MAY be in uppper or lower case."

Agree with the former, and disagree with the latter.  Example of ok usage would be something like:
"letters in domain names SHOULD be in lower case, but MAY instead be in upper case".

MAY means it's optional and you can choose not to do it.  You can't choose not to have letters be in upper or lower case, you have to pick one of the two.  You might argue they "MUST be in upper or lower case", but that would be inappropriate in my view also since it's not possible to violate the MUST, and it's not possible to test it since there's no way to fail the MUST.

If there's two options, each of which is equally acceptable and neither is recommended, then a simple "can" would suffice instead of "MAY".

Dave

---

From: Scott Bradner <[email-masked]>
Date: Tue, 1 May 2018 13:31:03 -0400

just so

Scott

> On May 1, 2018, at 1:03 PM, John Levine <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 May 2018 20:35:46 +0200

> If there's two options, each of which is equally acceptable and neither is recommended, then a simple "can" would suffice instead of "MAY".

Actually, the meaning of MAY is very clear in RFC 2119.  Excerpt:

   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality.  In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

A MAY is a mandatory statement about interoperability like the other RFC 2119 keywords.  The optionality is not about you, it is about the other side: again, it means *you* MUST be prepared to interoperate with the other side independent of whether they do the option or whether they don’t.

If you are not making this particular statement (MUST interoperate with either kind of peer), don’t use MAY.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 May 2018 12:03:15 +1200

> The latter seems better to me for the exact reason you give.

The rule of thumb I use is that if s/may/might/ would not change
the intended meaning, then use 'might' and avoid Phill's dilemma.

Thus: A Frame might be either buffered or unbuffered (and the
protocol doesn't care).

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 May 2018 20:16:30 -0400

> in domain names MAY be in uppper or lower case."

​No. I thought that but actually it is wrong. You should have a MUST there.

Applications MUST accept letters in domain names in either ​upper or lower
case and treat these as equivalent.

This only occurred to me earlier today. A MAY for a generating party turns
into a MUST for the interpreter.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 May 2018 15:25:44 -0400

I think Phill has this exactly right.  I *really* hate "MAY" most of
the time; it's way overused, and overused confusingly.

Almost every time, when a spec says "MAY do x or y," it really means
"MUST choose between x and y, and do one of them."  But what it says,
according to the letter of 2119, is that it can do anything it likes,
and that x and y are what the spec suggests.

I'll really challenge people to show me a case where a spec needs to
use MAY -- really needs to use it, rather than just something like
this:

AS WRITTEN
   When <this happens> the server MAY close the client session."

BETTER
   When <this happens>, the server is likely to close the client
   session, and clients MUST be able to handle that situation.

(No one asked here, but I also mostly hate "SHOULD".  Mostly, not
entirely.  Most of the time, "when <this happens> the server SHOULD
<do that>" is useless -- perhaps one might say dangerous -- without an
explanation of when/why it might not do that.  And that's most often
better written as "the server MUST <do that> unless <explanation>."
IMO, we use too many unexplained SHOULDs, leaving implementors
uncertain.

But no one asked here.)

Barry

On Tue, May 1, 2018 at 8:16 PM, Phillip Hallam-Baker
<[email-masked]> wrote:
>> In article
>> <CAMm+LwgBFWW2GoemjDG3nVEO2=RLSH9XO3+uwRaQdi75oq=[email-masked]> you
>> write:
> No. I thought that but actually it is wrong. You should have a MUST there.
>
> Applications MUST accept letters in domain names in either upper or lower

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 May 2018 23:37:01 +0200

>   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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 May 2018 19:49:25 -0400

What value does the "MAY" give you there?  Why might I close the
session?  Why might I not?  How do I decide?  What, exactly, is it
that you, the spec writer, are telling me to *do* by using "MAY"
there?

Barry

-- 
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 3 May 2018 10:15:03 +0900

> that you, the spec writer, are telling me to *do* by using "MAY"

Please go back and read Dave Thaler's post again (which I think gives 
the best explanation). If you're implementing the client, then this MAY 
tells you that you MUST be able to handle the server closing the 
session. Such constellations are quite frequent in specs, and that's why 
having MAY as a short way of saying so is helpful.

As for the server, what the spec says is only that this way of handling 
things is an option. It doesn't tell the server implementer why it might 
close the session, or why not. It doesn't tell the server implementer 
how to decide.

The reason for this is that the spec writer, and the WG, understood that 
the server implementer would be in a much better position to decide what 
to do. A server implementer could close the connection because it's a 
very simple implementation, and closing the connection is the simplest 
thing to do. It could close the connection because it tried other things 
with this specific client, without satisfactory results. It could close 
the connection because it wants to test that the client can handle that. 
And so on. When writing specs, we are assuming that the implementers 
that read them have good reasons to choose one or more of the 
possibilities that the spec offers.

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 May 2018 03:16:21 +0200

> On May 3, 2018, at 01:49, Barry Leiba <[email-masked]> 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

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…)

			.oOo.

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