Re: iSCSI: All text keys MUST be supported?

["Matt Wakeley" <matt_wakeley@agilent.com>]

julian_satran@il.ibm.com wrote:
> 
> 1.2.4 reads now:
> 
> 1.1.1     Text Mode Negotiation
> 
>    During login and thereafter some session or connection parameters are
>    negotiated through an exchange of textual information.
> 
>    In "list" negotiation, the offering party sends a list of values for a
>    key in its order of preference.
> 
>    The responding party answers with the first value from the list it
>    supports and is allowed to use for the specific initiator.
> 
>    The value "none" MUST always be used to indicate a missing function.
>    However, none is a valid selection only if it is explicitly offered and
>    MAY be selected by omission (i.e., <key>=none MAY be omitted).

Why MAY "<key>=none" be selected by omission?  This is just another one of
those "options" that we all hate.  If it's none, explicitely say so.

You also need to remove the "none MUST always be used to indicate a missing
function" because the following paragraph allows the use of "reject" or
"NotUnderstood" to indicate a missing function.

These two paragraphs need cleaning up.

> 
>    If a target is not supporting, or not allowed to use with a specific
>    initiator, any of the offered options, it may use the value "reject".
>    The values "none" and "reject" are reserved and must be used only as
>    described here.  Any key not understood is answered with
>    "NotUnderstood".
> 
>    The general format of text negotiation is:
> 
>       Offer-> <key>=<value1>,<value2>,...,<valuen>
>       Answer-> <key>=<valuex>|reject|NotUnderstood
> 
>    In "numerical" negotiations, the offering and responding party state a
>    numerical value. The result of the negotiation is key dependent;
>    frequently the lower or the higher of the two values is used.
> 
>    Although the initiator is the requesting party and controls the
>    request-response initiation and termination the target can offer
>    key=value pairs of its own as part of a sequence and not only in
>    response to an identical key=value pair offered by the initiator.
> 
>    And 2.8.3 reads:
> 
> 1.1.1     Text
> 
>    The initiator sends the target a set of key=value or key=list pairs
>    encoded in UTF-8 Unicode. The key and value are separated by a '='
>    (0x3D) delimiter. Many key=value pairs can be included in the Text block
>    by separating them with null (0x00) delimiters.  A list is a set of
>    values separated by comma (0x2C). Large binary items can be encoded
>    using their hexadecimal representation (e.g., 8190 is 0x1FFE) or decimal
>    representation. The maximum length of an individual value (not its
>    string representation) is 255 bytes.
> 
>    The data length of a text command or response SHOULD be less than 4096
>    bytes.  Key names MUST NOT exceed 64 bytes. Key values MUST NOT exceed
>    255 characters.

data length should be less than PDUlength.

-Matt