Re: iSCSI: All text keys MUST be supported?

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

Eddy Quicksall wrote:
> 
> 1. When I read "MAY be selected by omission", I read that if one omits
> <key>=none, then it means the same thing as <key>=none. And that the other
> guy MUST adhere to that rule.
> 
> What is your interpretation of the current text?

That's the problem - it can be interpreted many different ways.
Just delete the "MAY be selected by omission".  Make everything explicitely
selected.

Ok, so I should have said "less than or equal to PDUlength".
My point is, that if PDUlength is less than 4096, the message length must not
be larger than PDUlength.

-Matt

> 
> 2. Why should we limit the length to 4095 bytes when 4096 is not a strange
> number? Especially when we have to round things to 4 byte multiples anyway
> (which means 4095+one wasted byte becomes 4096). It seems we just cheated
> ourselves out of 1 byte.
> 
> Eddy
> 
> ----- Original Message -----
> From: "Matt Wakeley" <matt_wakeley@agilent.com>
> To: <ips@ece.cmu.edu>
> Sent: Monday, June 25, 2001 6:00 PM
> Subject: Re: iSCSI: All text keys MUST be supported?
> 
> > 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
> >
> >
> >