Prescriptive Language: You MAY skip this, but you probably SHOULD read it
Summary: As you read through the protocol documents, you'll notice that there are words in all caps, like MAY, SHOULD NOT, MUST, etc. This document gives a brief description of what these terms mean and why they are used.
Published: March 2012
The terms MAY, SHOULD, MUST, SHOULD NOT, and MUST NOT that appear in technical specifications in the Open Specifications program are referred to as prescriptive language. These terms have been adapted from an Internet standard ( [RFC2119]). Feel free to look at the standard for more details, but note that not all of the terms in RFC 2119 are used in the technical specifications.
Prescriptive language is used in order to be as clear as possible. Because the technical specifications sometimes describe different types of network behavior, it's important to distinguish between these behaviors. For example, sometimes the technical specifications describe general network protocol behavior and other times they specify Windows-specific activity. Prescriptive language helps make such distinctions clear by specifying exactly what each tem means in terms of your implementation.
The prescriptive terms used in Microsoft technical specifications are MUST, MAY, and SHOULD. Each term is described below.
This is used to define things that your implementation is required to do. For example, the following statement means that your client implementation cannot be allowed to perform more than 10 retry attempts per transaction:
The client MUST be limited to at most 10 retry attempts for every transaction.
MUST NOT specifies the opposite of MUST; that is, your implementation is required to not perform the specified action.
Contents of normative sections are assumed to be a MUST unless otherwise specified. (See "Normative Sections" below for more information.)
The Windows protocol specifications use the term MAY to specify optional behavior. This term implies that most Microsoft implementations do not exhibit this behavior. There are exceptions to this rule, and these exceptions are described (sometimes in great detail) in product behavior notes attached to the MAY. For example:
The client MAY <32> save the state of failed transactions.
<32> Section 188.8.131.52: Windows XP saves the state of failed transactions.
This example indicates that your implementation can save the state of failed transactions, but that this behavior isn't required. The behavior note indicated by <32> tells you how Windows handles this behavior. In this case, only Windows XP actually saves the state. Other versions of Windows do not. (The Product Behavior section near the end of each document will explicitly list each version of Windows or Windows products that uses the protocol described in the document.)
SHOULD is used as a synonym for "recommended". The use of SHOULD to specify optional behavior implies that at least some Microsoft implementations exhibit the optional behavior. There are exceptions to this rule, and these exceptions are described in product behavior notes attached to the SHOULD. The following statement recommends, but does not require, that your client implementation attempt to retry the transaction. Because there is no product behavior note, this statement also implies that every Microsoft implementation that includes this protocol will retry the transaction.
The client SHOULD retry the transaction.
SHOULD NOT specifies the opposite of SHOULD; that is, it is recommend that you build your implementation so that it does not perform the specified action. Unless there's a behavior note indicating otherwise, Windows follows the recommendation. This is a recommendation, not a mandate. You can expect that your implementation will still interoperate with Windows if you ignore it.