Re: iSCSI: All text keys MUST be supported?

["Eddy Quicksall" <ESQuicksall@hotmail.com>]

Looks good, but what about 2.9.3? Should that have the following statement
removed? Because you could use that fact to just ignore the key if you don't
understand it. If the statement stands, one would have to wonder what the
original intent was.

    2.9.3 says:
       If the Text Response does not contain a key that
       was requested, the initiator must assume that the key was not
       understood by the target or that the answer is <key>=none.

Eddy

----- Original Message -----
From: <julian_satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Wednesday, June 13, 2001 1:32 PM
Subject: RE: iSCSI: All text keys MUST be supported?


>
>
> 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).
>
>    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.
>
>    Character strings are represented as plain text. Numeric and binary
>    values are represented using either decimal numbers or the hexadecimal
>    0x'ffff' notation. The result is adjusted to the specific key.
>
>    The target responds by sending its response back to the initiator. The
>    response text format is similar to the request text format.
>
>    Some basic key=value pairs are described in Appendix A and D. All of
>    these keys, except for the X- extension format, MUST be supported by
>    iSCSI initiators and targets.
>
>    Manufacturers may introduce new keys by prefixing them with X- followed
>    by their (reversed) domain name, for example the company owning the
>    domain acme.com can issue:
>
>       X-com.acme.bar.foo.do_something=0000000000000003
>
>    Any other key not understood by the target may be ignored by the target
>    without affecting basic function. However the Text Response for a key
>    that was not understood MUST be key=NotUnderstood.
>
>    Text operations are usually meant for parameter setting/negotiations
but
>    can be used also to perform some active operations.
>
>    It is recommended that Text operations that will take a long time
should
>    be placed in their own Text command.
>
>    A session may have only one outstanding text command at any given time.
>
>    Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com> on
> 13-06-2001 20:09:18
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> To:   "'Eddy Quicksall'" <EQuicksall@mediaone.net>, Julian
>       Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: All text keys MUST be supported?
>
>
>
>
> I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to
recognize
> and answer all text keys specified in the iSCSI protocol document.  Some
> features negotiated with these text commands are OPTIONAL to implement."
>
> Julian, is that your intention?  Would you make the wording more explicit?
>
> The further text is implicitly refering to 'proprietary' text keys a
vendor
> may dream up.
>
> Marj
>
> > -----Original Message-----
> > From: Eddy Quicksall [mailto:EQuicksall@mediaone.net]
> > Sent: Tuesday, June 12, 2001 10:20 AM
> > To: julian_satran@il.ibm.com; ips@ece.cmu.edu
> > Subject: iSCSI: All text keys MUST be supported?
> >
> >
> >
> > Section "2.8.3 Text" says:
> >
> >     All of these keys, except for the X- extension format,
> >     MUST be supported by iSCSI initiators and targets.
> >
> > But it further says:
> >
> >    Any other key not understood by the target may be ignored without
> >    affecting basic function. If the Text Response does not
> > contain a key
> >    that was requested, the initiator must assume that the key was not
> >    understood by the target or, whenever appropriate, that
> > the response
> >    was "none".
> >
> > These two statements seem contradictory (I don't think the
> > 2nd is talking
> > about only the X keys). I vote for removing the 1st paragraph above
> > and going with the 2nd. That way we would not have to insist
> > that every
> > key be supported ... the requester would just take the default if the
> > receiver did not support the key.
> >
> > Actually, section "2.9.3 Text Response Data"  says:
> >
> >    If the Text Response does not contain a key that
> >    was requested, the initiator must assume that the key was not
> >    understood by the target or that the answer is <key>=none.
> >
> > This seems to backup the 2nd paragraph above.
> >
> >
> >
> > Eddy@Quicksall.com
> >
>
>
>
>