Re: iSCSI: All text keys MUST be supported?

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

1. Without something like "MAY be selected by omission", one would think it
can't be omitted. Can you think of alternate text?
2. When I was "complaining" about the "less than 4096" below, I was not
referring to what you said ... I was referring to what the spec says ("The
data length of a text command or response SHOULD be less than 4096 bytes.").
Does anyone know why we can't go to 4096 instead of 4095 as the spec
currently says.

Eddy

----- Original Message -----
From: "Matt Wakeley" <matt_wakeley@agilent.com>
To: <ips@ece.cmu.edu>
Sent: Wednesday, June 27, 2001 12:31 PM
Subject: Re: iSCSI: All text keys MUST be supported?


> 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
> > >
> > >
> > >
>
>