RE: iSCSI: All text keys MUST be supported?

["Rod Harrison" <rod.harrison@windriver.com>]

	We could make "none" required to be offered, alternatively
remove the restriction that prevents <key>=none if "none"
isn't explicitly offered.

	- Rod

  >  -----Original Message-----
  >  From: owner-ips@ece.cmu.edu
  >  [mailto:owner-ips@ece.cmu.edu]On Behalf Of
  >  Eddy Quicksall
  >  Sent: Thursday, June 28, 2001 6:44 PM
  >  To: Matt Wakeley; ips@ece.cmu.edu
  >  Subject: Re: iSCSI: All text keys MUST be supported?
  >
  >
  >  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
  >  > > >
  >  > > >
  >  > > >
  >  >
  >  >