3.3Keywords

3.3.1expected: A keyword used to describe the behavior of the hardware or software in the design models

assumed by this standard. Other hardware and software design models may also be implemented.

3.3.2invalid: A keyword used to describe an illegal or unsupported bit, byte, word, field or code value. Receipt of an invalid bit, byte, word, field or code value shall be reported as error.

3.3.3ignored: A keyword used to describe a bit, byte, word, field or code value that shall not be examined by the receiving SCSI device. The bit, byte, word, field or code value has no meaning in the specified context.

3.3.4mandatory: A keyword indicating an item that is required to be implemented as defined in this standard.

3.3.5may: A keyword that indicates flexibility of choice with no implied preference (equivalent to “may or may

not”).

3.3.6may not: A keyword that indicates flexibility of choice with no implied preference (equivalent to “may or may not”).

3.3.7obsolete: A keyword indicating that an item was defined in a prior SCSI standard but has been removed from this standard.

3.3.8optional: A keyword that describes features that are not required to be implemented by this standard. However, if any optional feature defined by this standard is implemented, then it shall be implemented as defined in this standard.

3.3.9reserved: A keyword referring to bits, bytes, words, fields and code values that are set aside for future standardization. A reserved bit, byte, word or field shall be set to zero, or in accordance with a future extension to this standard. Recipients are not required to check reserved bits, bytes, words or fields for zero values. Receipt of reserved code values in defined fields shall be reported as an error.

3.3.10restricted: A keyword referring to bits, bytes, words, and fields that are set aside for use in other SCSI standards. A restricted bit, byte, word, or field shall be treated as a reserved bit, byte, word or field for the purposes of the requirements defined in this standard.

3.3.11shall: A keyword indicating a mandatory requirement. Designers are required to implement all such mandatory requirements to ensure interoperability with other products that conform to this standard. This standard prescribes no specific response by a component if it receives information that violates a mandatory behavior.

3.3.12should: A keyword indicating flexibility of choice with a strongly preferred alternative; equivalent to the phrase “it is strongly recommended”.

3.4Editorial conventions

Certain words and terms used in this standard have a specific meaning beyond the normal English meaning. These words and terms are defined either in 3.1 or in the body of the standard where they first appear. Names of commands, statuses, task management functions, task attributes, Information Units, sense keys, additional sense codes, and additional sense code qualifiers are in all uppercase (e.g., REQUEST SENSE). Lowercase is used for words having the normal English meaning.

The names of fields are in small uppercase (e.g., ALLOCATION LENGTH). When a field name is a concatenation of acronyms, uppercase letters may be used for readability (e.g., NORMACA). Normal case is used when the contents of a field are being discussed. Fields containing only one bit are usually referred to as the NAME bit instead of the NAME field. Where fields defined in another standard are referenced in this standard, the capitalization conventions of the originating standard are used.

Numbers that are not immediately followed by lower-case b or h are decimal values.

Numbers immediately followed by lower-case b (0101b) are binary values.

Numbers or upper case letters immediately followed by lower-case h (FA23h) are hexadecimal values.

In all of the figures, tables, and text of this standard, the most significant bit of a binary quantity is shown on the left side. Bit order and byte order are as specified in FC-FS-2.

The ISO convention of numbering is used (i.e., the thousands and higher multiples are separated by a space). A comma is used as the decimal point. A comparison of the American and ISO conventions is shown below:

Lists sequenced by letters (e.g., a-red, b-blue, c-green) show no ordering relationship between the listed items. Numbered lists (e.g., 1-red, 2-blue, 3-green) show an ordering relationship between the listed items.

If a conflict arises between text, tables, or figures, the order of precedence to resolve the conflicts is text, then tables, and finally figures. Exceptions to this convention are indicated in the appropriate subclauses. Not all tables or figures are fully described in the text. Tables show data format and values. Notes do not constitute any requirements for implementors.