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?



    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