SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: All text keys MUST be supported?



    
    
    The current text reads:
    
       The data length of a text command or response SHOULD not exceed 4096
       bytes.  Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed
       255 characters.
    
       The reaseon for 63, 255 is to enable a separator in the 256 (64) count.
    
       Julo
    
    "Eddy Quicksall" <ESQuicksall@hotmail.com> on 28-06-2001 20:43:48
    
    Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
    
    To:   "Matt Wakeley" <matt_wakeley@agilent.com>, ips@ece.cmu.edu
    cc:
    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
    > > >
    > > >
    > > >
    >
    >
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:22 2001
6315 messages in chronological order