Subject: iSCSI - an improved text for 4.1 & 4.2

From: "Julian Satran" <[email-masked]>
Date: Fri, 3 May 2002 20:48:02 +0300

Here is another attempt.
Julo

Text Format
The initiator and target send a set of key=value pairs encoded in UTF-8 
Unicode. All the text keys and text values specified in this document are 
to be presented and interpreted in the case they appear in this document. 
They are case sensitive. 

The following character symbols are used in this document for text items:

(a-z, A-Z) - letters
(0-9) - digits
" " (0x20) - space
"." (0x2e) - dot
"-" (0x2d) - minus
"+" (0x2b) - plus
"@" (0x40) - commercial at
"_" (0x5f) - underscore
"=" (0x3d) - equal
":" (0x3a) - colon
"/" (0x2f) - solidus or slash
"[" (0x5b) - left bracket
"]" (0x5d) - right bracket
null(0x00) - null separator
"," (0x2c) - comma
"~" (0x7e) - tilde

A key-name is whatever precedes the first = in the key=value pair. The 
term key is used frequently in this document with the meaning of key-name.

A value is whatever follows the = that follows the key-name up to a null 
delimiter that marks the end of any key=value pair (including the last in 
a PDU).

The following definitions will be used in the rest of this document:

key-name:  a string of one or more characters consisting of letters, 
digits, point, minus, plus, commercial at, and underscore, A key-name MUST 
begin with a capital letter an must not exceed 63 characters.

text-value: a string of 0 or more characters consisting of let-ters, 
digits, dot, minus, plus, commercial at, underscore, slash, left bracket, 
right bracket and colon.

iSCSI-name-value: a string of one or more characters consist-ing of minus, 
dot, colon and any character allowed by the output of the iSCSI 
string-prep template as specified in [STPREP-iSCSI] (see also Section 
2.2.6.2 iSCSI Name Encoding).

iSCSI-local-name-value: an UTF-8 string terminated by the null character 
that terminates the key=value pair; no null charac-ters are allowed in the 
string. This encoding is to be used for localized (internationalized) 
aliases.

boolean-value: the strings "Yes" or "No".

hex-constant: hexadecimal constant encoded as a string start-ing with "0x" 
or "0X" followed by 1 or more digits or the letters a, b, c, d, e, f, A, 
B, C, D, E and F.

decimal-constant: an unsigned decimal number - a string of 1 or more 
digits starting with a non-zero digit. This encoding is not used for 
numerical values equal or greater than 2**64.

base-64-constant: unsigned base-64 constant encoded as a string starting 
with "0b" or "0B" followed by 1 or more digits or letters or plus or slash 
or equal.

regular-numerical-value :  an unsigned integer less than 2**64 encoded as 
a decimal-constant, hex constant, or base-64 con-stant. For base-64 
encoding the encoding is done according to [RFC2045].

large-numerical-value :  an unsigned integer larger than or equal to 2**64 
encoded as a hex constant, or base-64 con-stant.

numerical-value: a regular-numerical-value or a large numeri-cal-value. 
Unsigned integer arithmetic applies to numeric-values.

numeric-range: two numerical-values separated by a tilde.

regular-binary-value :  a binary string less than 64 bits encoded as a 
decimal constant, hex constant or base-64 con-stant. For base-64 encoding 
the encoding is done according to [RFC2045]. The length of the string is 
either specified by the key definition or is implied by the encoding as 
the mini-mum number of bytes that can hold the encoded string.

large-binary-value :  a binary string encoded as a hex con-stant or 
base-64 constant. For base-64 encoding the encoding is done according to 
[RFC2045]. The length of the string is either specified by the key 
definition or is implied by the encoding as the minimum number of bytes 
that can hold the encoded string.

binary-value: a regular-binary-value or a large-binary-value. Operations 
on binary values are key specific.

simple-value: text-value, iSCSI-name-value, boolean-value, numeric-value, 
a numeric-range or a binary-value.

list-of-values: a sequence of text-values separated by comma

If not otherwise specified, the maximum length of a simple-value (not its 
encoded representation) is 255 bytes not including the delimiter (comma or 
null).

Any iSCSI target or initiator MUST support receiving at least 16384 bytes 
of key=value data in a negotiation sequence except when indi-cating 
support for very long authentication items by offering or selecting 
authentication methods such as public key certificates in which case they 
MUST support receiving at least 64 kilobytes of key=value data.

Text Mode Negotiation
During login, and thereafter, some session or connection parameters are 
either declared or negotiated through an exchange of textual information.

The initiator starts the negotiation and/or declaration through a 
Text/Login request and indicates when it is ready for completion (by 
setting to 1 and keeping to 1 the F bit in a Text Request or the T bit in 
the Login Request).

The format of a declaration is:

Declarer-> <key>=<valuex>

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|NotUnderstood|Irrelevant|Reject

The originator or declarer can either be the initiator or the target and 
the responder can either be the target or initiator, respec-tively. Target requests are not limited to respond to key=value pairs as offered 
by the initiator. The target may offer key=value pairs of its own. 

All negotiations are explicit (i.e., the result MUST be based only on 
newly exchanged or declared values). There are no implicit offers. If an 
explicit offer is not made then a reply cannot be expected. Con-servative 
design requires also that default values should not be relied upon when 
use of some other value has serious consequences. 

The value offered or declared can be an numerical-value, a numerical-range 
defined by lower and upper value - both integers separated by tilde, a 
binary value, a text-value, a iSCSI-name-value, an iSCSI-local-name-value, 
a boolean-value (Yes or No), or a list of comma separated text-values. A 
range MAY ONLY be offered if it is explic-itly allowed for a key.  An 
iSCSI-name-value and an iSCSI-local-name-value can be used only where 
explicitly allowed. A selected value can be an numerical-value, a 
text-value or a boolean-value.

If a specific key is not relevant for the current negotiation, the 
responder may answer with the constant "Irrelevant" for all types of 
negotiation.  However the negotiation is not considered as failed if the 
response is Irrelevant.

Any key not understood by the responder may be ignored by the responder 
without affecting the basic function. However, the Text Response for a key 
not understood MUST be key=NotUnderstood.

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are 
reserved and must only be used as described here.

None, Reject or Irrelevant are legitimate negotiation options where 
allowed but their excessive use is discouraged.
 
Some basic key=value pairs are described in Chapter 11. All keys in 
Chapter 11, except for the X- extension format, MUST be supported by iSCSI 
initiators and targets and MUST NOT be answered with NotUnder-stood. 

Implementers may introduce new keys by prefixing them with X- fol-lowed by 
their (reversed) domain name. For example the entity owning the domain 
acme.com can issue: 

X-com.acme.bar.foo.do_something=3

List negotiations
In list negotiation, the originator sends a list of values (which may 
include "None") in its order of preference.

The responding party MUST answer with the first value that it sup-ports 
(and is allowed to use for the specific originator) selected from the 
originator list. 

The constant "None" MUST always be used to indicate a missing func-tion. 
However, None is a valid selection only if it is explicitly offered. 

If a responder does not understand any particular value in a list it MUST 
ignore it. If a responder does not support, does not understand or is not 
allowed to use all of the offered options with a specific originator, it 
MAY use the constant "Reject".  The selection of a value not admissible 
under the selection rules is considered a nego-tiation failure and is 
handled as a protocol error. The selection rules are key-specific.

Simple-value negotiations
For simple-value negotiations, the responding party MUST respond with the 
same key. The value it selects, based on the selection rule spe-cific to 
the key, becomes the negotiation result. For a numerical range the value 
selected must be an integer within the offered range or "Reject" (if the 
range is unacceptable).  An offer of a value not admissible MAY be 
answered with the constant "Reject" or the responder MAY select an 
admissible value. The selection, by the responder, of a value not 
admissible under the selection rules is considered a negotiation failure 
and is handled accordingly. The selection rules are key-specific. 

For boolean negotiations (keys taking the values Yes or No), the 
responding party MUST respond with the same key and the result of the 
negotiation when the received value does not determine that result by 
itself. The last value transmitted becomes the negotiation result. The 
rules for selecting the value with which to respond are expressed as 
Boolean functions of the value received and the value that the responding 
party would select in the absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The boolean function is "AND" and the value "No" is received. The 
outcome of the negotiation is "No".
- The boolean function is "OR" and the value "Yes" is received. The 
outcome of the negotiation is "Yes".

Responses are REQUIRED in all other cases, and the value chosen and sent 
by the responder becomes the outcome of the negotiation.

---

From: Martins Krikis <[email-masked]>
Date: Fri, 03 May 2002 17:17:22 -0500

Adding regular expressions, where possible, would
have benefited the draft, IMHO. More comments follow.

> key-name:  a string of one or more characters consisting of letters, digits,
> point, minus, plus, commercial at, and underscore, A key-name MUST begin with
> a capital letter an must not exceed 63 characters.

I believe it should be "dot" instead of "point".

> iSCSI-local-name-value:  an UTF-8 string terminated by the null character that
> terminates the key=value pair; no null charac-ters are allowed in the
> string. This encoding is to be used for localized (internationalized) aliases.

Very strangely this definition starts mentioning the
terminator when others didn't. And null characters
aren't allowed in any other kind of values either,
are they? If so, how do we know where the value
really ends?

> boolean-value:  the strings "Yes" or "No".

"string".

> decimal-constant:  an unsigned decimal number - a string of 1 or more digits
> starting with a non-zero digit. This encoding is not used for numerical values
> equal or greater than 2**64.

We just disallowed the 0 itself.

> base-64-constant:  unsigned base-64 constant encoded as a string starting with
> "0b" or "0B" followed by 1 or more digits or letters or plus or slash or
> equal.
> regular-numerical-value :  an unsigned integer less than 2**64 encoded as a
> decimal-constant, hex constant, or base-64 con-stant. For base-64 encoding the
> encoding is done according to [RFC2045].

How the encoding is done would be better put higher
up with the base-64-constant definition, then it would
not need to be repeated again and again.

> numeric-range:  two numerical-values separated by a tilde.

Why not mention here that the values must come in non-decreasing order?

> regular-binary-value :  a binary string less than 64 bits encoded as a decimal
> constant, hex constant or base-64 con-stant. For base-64 encoding the encoding
> is done according to [RFC2045]. The length of the string is either specified
> by the key definition or is implied by the encoding as the mini-mum number of
> bytes that can hold the encoded string.

The last sentence is ambiguous, IMHO, and incorrect
no matter how understood. If, encoded as  
as a hex constant, the value is 0x000f, what is its
length when decoded? 6 bytes ("0x000f" w/o '\0') 
or 1 byte (containing bits 00001111)? The answer
that I think we want is 2 bytes... The problem is that
not knowing what the string is, we can't tell
how many bytes are required to hold it. Some other
description will be necessary, I'm afraid.

> simple-value:  text-value, iSCSI-name-value, boolean-value, numeric-value, a
> numeric-range or a binary-value.

iSCSI-local-name-value seems to be missing.

> All negotiations are explicit (i.e., the result MUST be based only on newly
> exchanged or declared values). There are no implicit offers. If an explicit
> offer is not made then a reply cannot be expected. Con-servative design
> requires also that default values should not be relied upon when use of some
> other value has serious consequences.

Negotiations are not explicit due to the boolean omission "feature".
Offers are explicit, negotiations aren't.

> None, Reject or Irrelevant are legitimate negotiation options where allowed
> but their excessive use is discouraged.

Why is the use of "None" discouraged? In fact, "None" is not very
special after all---it is only allowed in a response, if offered...

> ...      If a responder does not support, does not understand or is not
> allowed to use all of the offered options with a specific originator, it MAY
> use the constant "Reject".

If I don't support "all", but support at least one of the offered values,
I should answer with something I support and not with Reject. 
"Options" have not been defined or used before. Alright, I'm not a
native English speaker myself, but I'll volunteer:

  If each of the offered values is not understood or not supported,
  or the responder is not allowed to use it with the specific originator,
  it MAY use the constant "Reject".

And I would prefer a MUST instead of MAY.

>� The selection of a value not admissible under the
> selection rules is considered a nego-tiation failure and is handled as a
> protocol error. The selection rules are key-specific.

It was just said above (I didn't quote it) that the selection rule is
to pick the first value supported. Thus, I'm not sure why here the
rule is key-specific.

> For simple-value negotiations, the responding party MUST respond with the same
> key. 

We forgot to mention the same for list negotiations.

> The value it selects, based on the selection rule spe-cific to the key,
> becomes the negotiation result. For a numerical range the value selected must
> be an integer within the offered range or "Reject" (if the range is
> unacceptable). � An offer of a value not admissible MAY be answered with the
> constant "Reject" or the responder MAY select an admissible value.

What was meant here by "value not admissible"? Outside the legal range
of values or simply outside the range that the responder supports?

> The
> selection, by the responder, of a value not admissible under the selection
> rules is considered a negotiation failure and is handled accordingly. The
> selection rules are key-specific.

Rules again are key-specific, when it was just said that the rule is
to pick a value from the range (or Reject, or, well, that part was not
clear), but they don't seem to be key-specific again...

> The rules for selecting the value
> with which to respond are expressed as Boolean functions of the value received
> and the value that the responding party would select in the absence of
> knowledge of the received value.

I've mentioned this numerous times, nobody seems to care. IMO, there
is a logic flay here:

InitialR2T: function OR, default Yes.

I -> T: No

Target wants "No", too. However, in the 
"absence of the knowledge of the received value", it would have
been forced to stick with the default "Yes". 

According to the quoted sentence above, the target must reply
with OR(No, Yes) = Yes. Thus:

T -> I: Yes

Congratulations. Both parties wanted "No", but due to logic errors in
the specification were forced to settle with "Yes".

Am I right or wrong?

Besides, this sentence is in the context of value omissions, so it
should not be talking about the value to respond anyway.

I'll volunteer for a fix-up (for the whole boolean negotiation part,
until the word "Specifically"):

  For boolean negotiations (keys taking the values Yes or No), 
  the negotiation result is determined by applying the key-specific
  boolean function to the value received and the value that the
  responding party would have offered, had it been the first to do so.
  The respoponding party MUST respond with the same key and the result 
  of the negotiation when the received value does not determine that
  result by itself. The last value transmitted becomes the negotiation result.

Thanks for your attention to these issues,

    Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be those of my employer.

---

From: [email-masked]
Date: Fri, 3 May 2002 15:36:10 -0600

Martins,

RE: why iSCSI-local-name-value mentions that null characters aren't allowed
in the string while other value definitions do not. Most of the others name
a specific set of characters that is allowed so they don't have to call out
a particular character as not allowed. iSCSI-local-name-value seems to be
the only one that is described as a "UTF-8 string" rather than a string
"consisting of <character list>". That is why it has to meantion the
exclusion of null specifically.

"terminated by the null charater" is probably unnecessary the text above
says that all values are terminated by the null character.

Pat

-----Original Message-----
From: Martins Krikis [mailto:[email-masked]]
Sent: Friday, May 03, 2002 3:17 PM
To: [email-masked]
Subject: Re: iSCSI - an improved text for 4.1 & 4.2

> key-name:  a string of one or more characters consisting of letters,
digits,

> iSCSI-local-name-value:  an UTF-8 string terminated by the null character
that
aliases.

"string".

> decimal-constant:  an unsigned decimal number - a string of 1 or more
digits

> base-64-constant:  unsigned base-64 constant encoded as a string starting
with
> regular-numerical-value :  an unsigned integer less than 2**64 encoded as
a

> regular-binary-value :  a binary string less than 64 bits encoded as a
decimal

> simple-value:  text-value, iSCSI-name-value, boolean-value, numeric-value,
a

> All negotiations are explicit (i.e., the result MUST be based only on
newly

> None, Reject or Irrelevant are legitimate negotiation options where
allowed

> allowed to use all of the offered options with a specific originator, it
MAY

> The selection of a value not admissible under the

> For simple-value negotiations, the responding party MUST respond with the
same

> unacceptable).  An offer of a value not admissible MAY be answered with
the

I -> T: No

T -> I: Yes

Am I right or wrong?

  result by itself. The last value transmitted becomes the negotiation
result.

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 10 May 2002 09:54:29 +0300

We are getting close -  more comments in text. Julo

                      Martins Krikis                                                                                                        
                      <[email-masked]        To:       Julian Satran/Haifa/IBM@IBMIL                                                      
                      m>                       cc:                                                                                          
                                               Subject:  Re: iSCSI - an improved text for 4.1 & 4.2                                         
                      05/06/2002 11:26                                                                                                      
                      PM                                                                                                                    
                      Please respond to                                                                                                     
                      Martins Krikis                                                                                                        

--- Julian Satran <[email-masked]> wrote:
> comments in text - julo

Thanks for your attention to these issues.
I've deleted everything that I don't have any
more immediate comments on.

> +++ that is what regular and large attempt +++

My point was this. The draft mentions 3 times how
the base-64 encoding should be done (i.e., according
to RFC2045). It does this for regular-numerical,
regular-binary and large-binary values. It forgets
to say this for large-numerical. Instead of these
3 (should have been 4?) times, it would have sufficed
to say so once and say it where the base-64-constant
is defined. And it would have been better to say it
there because then one would know how to encode this
constant immediately, before reading about its
applicability to regular/large-numerical/binary
values...

+++ OK - now that I understand you +++

> > constant, hex constant or base-64 con-stant. For
> > base-64 encoding the
> > encoding
> > is done according to [RFC2045]. The length of the
> > string is either
> > specified
> > by the key definition or is implied by the
> > encoding as the mini-mum
> > number of
> +++ that is incorrect. the text says the minimum
> number of BYTES:
> 0xf or 0x0f fit in ONE byte, 0x000f fit in 2 bytes.

It all depends on how "fit" is defined. Since it
isn't, I can quite reasonably assume that 0x000f
does fit in 1 byte. Therefore, the draft should
say that for hex-encoded binary strings, the
leading zeroes in hex encoding do count. Each
hex digit results in 4 bits. Then we can say that
the string consists of the minimum number of bytes
that can hold all those bits.
+++ well we must be a funny sort of computer geeks if we assume that the
rest of the text is understandable but here we have an issue. How about the
following text:

   Text Format

       The initiator and target send a set of key=value pairs encoded in
       UTF-8 Unicode. All the text keys and text values specified in this
       document are to be presented and interpreted in the case they appear
       in this document. They are case sensitive.

       The following character symbols are used in this document for text
       items:

       (a-z, A-Z) - letters
       (0-9) - digits
       " " (0x20) - space
       "." (0x2e) - dot
       "-" (0x2d) - minus
       "+" (0x2b) - plus
       nul (0x00) - nul separator
       "," (0x2c) - comma
       "~" (0x7e) - tilde

       A key-name is whatever precedes the first = in the key=value pair.
       The term key is used frequently in this document with the meaning of
       key-name.

       A value is whatever follows the = that follows the key-name up to a
       zero-byte delimiter that marks the end of any key=value pair
       (includ-ing the last in a PDU).

          key-name:  a string of one or more characters consisting of
            letters, digits, dot, minus, plus, commercial at, and
            under-score, A key-name MUST begin with a capital letter an
            must not exceed 63 characters.

          text-value: a string of 0 or more characters consisting of
            let-ters, digits, dot, minus, plus, commercial at, underscore,
            slash, left bracket, right bracket and colon.

          iSCSI-name-value: a string of one or more characters consist-ing
            of minus, dot, colon and any character allowed by the output of
            the iSCSI string-prep template as specified in [STPREP-iSCSI]
            (see also Section 2.2.6.2 iSCSI Name Encoding).

          iSCSI-local-name-value: an UTF-8 string; no nul characters are
            allowed in the string. This encoding is to be used for
            local-ized (internationalized) aliases.

          boolean-value: the string "Yes" or "No".

          hex-constant: hexadecimal constant encoded as a string start-ing
            with "0x" or "0X" followed by 1 or more digits or the letters
            a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants are used
            to encode numerical values or binary strings. When used to
            encode numerical values the excesive use of leading 0 digits is
            discouraged. When used to encode binary strings hexadecimal
            constants have an implicit byte-length that includes 4 bits for
            every hexadecimal digit of the constant, including eading
            zeroes (i.e., a hex-constant of n hexadeci-mal digits has a
            byte-length of (the integer part of) (n+1)/ 2).

          decimal-constant: an unsigned decimal number - the digit 0 or a
            string of 1 or more digits starting with a non-zero digit. This
            encoding is not used for numerical values equal or greater than
            2**64. Decimal-constants are used to encode numerical values or
            binary strings. When used to encode binary strings decimal
            constants have an implicit byte-length that is the minimum
            number of bytes needed to represent the base2 encoding of the
            decimal number.

          base64-constant: base64 constant encoded as a string starting
            with "0b" or "0B" followed by 1 or more digits or letters or
            plus or slash or equal. The encoding is done according to
            [RFC2045]. base64-constants are used to encode numerical
            val-ues or binary strings. When used to encode numerical values
            the excesive use of leading 0s prior to encoding - encoded as
            "A" - is discouraged. When used to encode binary strings
            base64-constants have an implicit byte-length that includes 6
            bits for every character of the constant excluding trailing
            equals (i.e., a base64-constant of n base64 characters with m
            trailing equals has a byte-length of ((the integer part of)
            ((n+3)*3/4) - m).

          regular-numerical-value :  an unsigned integer less than 2**64
            encoded as a decimal-constant, hex constant, or
            base64-con-stant.

          large-numerical-value :  an unsigned integer larger than or equal
            to 2**64 encoded as a hex constant, or base64-constant.

          numerical-value: a regular-numerical-value or a large
            numeri-cal-value. Unsigned integer arithmetic applies to
            numeric-values.

          numeric-range: two numerical-values separated by a tilde where
            the value to the right of tilde must not be lower that the
            value to the left.

          regular-binary-value :  a binary string less than 64 bits encoded
            as a decimal constant, hex constant or base64-con-stant. The
            length of the string is either specified by the key definition
            or is implicit byte-length of the encoded string.

          large-binary-value :  a binary string encoded as a hex-con-stant
            or base64-constant.  The length of the string is either
            specified by the key definition or is implicit byte-length of
            the encoded string.

          binary-value: a regular-binary-value or a large-binary-value.
            Operations on binary values are key specific.

          simple-value: text-value, iSCSI-name-value, boolean-value,
            numeric-value, a numeric-range or a binary-value.

       If not otherwise specified, the maximum length of a simple-value
       (not its encoded representation) is 255 bytes not including the
       delimiter (comma or zero byte).

       Any iSCSI target or initiator MUST support receiving at least 16384
       bytes of key=value data in a negotiation sequence except when
       indi-cating support for very long authentication items by offering
       or selecting authentication methods such as public key certificates
       in which case they MUST support receiving at least 64 kilobytes of
       key=value data.

++++

> Hex constant encode binary strings and not numbers.
> to avoid any ambiguity I've rephrased it:
>
> The length of the string is either specified by the
> key definition or is
> implied by the encoding as the minimum number of
> bytes that can hold all
> hexadecimal digits of the encoded string. ++++

This, IMO, didn't clear the problem that I was
referring to. Furthermore it made me notice that
the length-of-string question is not applicable
to base-64-constants, and therefore the explanation
of how to determine the string length should say
that this is only for hex encoding. (Currently it
looks like this refers to all kinds of encodings,
then refers to hexadecimal digits.) How about this:

  The length of the string is either specified
  by the key definition or by its encoding.
  For strings encoded as hex-constants, every
  hexadecimal digit of the encoding, including
  leading zeroes, represents 4 bits of the original
  string. Therefore, if the hex-constant has n
  hexadecimal digits, the length of the string that
  it encodes is (the integer part of) (n+1)/2.

> > simple-value:  text-value, iSCSI-name-value,
> > boolean-value,
> > numeric-value, a
> +++ they appear later not as simple-values ... +++

Only in the subsection Text Mode Negotiation, where
all kinds of simple-values are listed again (begging
the question, why was the simple-value defined if
all this is listed again explicitly). OK, I take it
that the main reason for defining simple-value
was the 255 byte length restriction and that
iSCSI-local-name-value doesn't have it and therefore
isn't simple. If so, then please disregard my previous
comment. Please note however, that should such values
ever become negotiated, the draft hasn't described
yet how to do that (only simple-values and
lists-of-values are covered).

> I should answer with something I support
> and not with Reject. "Options" have not been
> defined or used before. Alright, I'm not a
>  If each of the offered values is not understood
>  or not supported, or the responder is not
>  allowed to use it with the specific
>  originator,it MAY use the constant "Reject".
> +++ I have made it Anyone - I am sick about this
> statement that everybody understands and
> everybody tries to rephrase +++

Sorry, I wasn't aware of this statement even being
noticed by anybody. I can't see how "Anyone" could
make it better, but I'll wait for the text.

> > The selection of a value not admissible
> > under the selection rules is considered a
> > nego-tiation failure and is handled
> > as a protocol error. The selection rules
> > are key-specific.
>
> It was just said above (I didn't quote it)
> that the selection rule is to pick the first
> value supported. Thus, I'm not sure why here the
> rule is key-specific.
>
> +++ If you are offered a range and select ouside the
> range or if you are
> offered a key=no and you respond key=yes when the
> specific rule is AND or
> if you are given a buffer-size and you select a
> larger value - those are
> each errors but each according to a separate and key
> specific rule +++

Yes, those are the generic rules, but the point
was that this text is in the context of list
negotiations, where the only rule is "pick-the-first".
And it was just said that that's the rule. Therefore
telling afterwards that the rule is key-specific
can be confusing.
+++ I'll fix the text for list +++
> > For a numerical range the value
> > selected must
> > unacceptable). An offer of a value not admissible
> > MAY be answered with the
+++ See above +++

No, sorry, the above was about selection. This is
about offers. Concrete example: IFMarkInt. The
allowed range is 1 to 65535. The range I support
is 1 to 16. If the other side sends 17 is this
"value not admissible"? If the other side sends
65536, is that "value inadmissible"? The draft
is not clear here, that's all I'm pointing out.

> Am I right or wrong?
+++ You are wrong! +++

I think I was right :-) But I am happy with how
it was rephrased so I'll move on.

Thanks,

P.S. I hope the next version will clearly address
the repetition issues regarding Reject and Irrelevant.
Previous confusion about this has severely impacted
my own implementation.

+++ 4.2 text is

Text Mode Negotiation
       During login, and thereafter, some session or connection parameters
       are either declared or negotiated through an exchange of textual
       information.

       The initiator starts the negotiation and/or declaration through a
       Text/Login request and indicates when it is ready for completion (by
       setting to 1 and keeping to 1 the F bit in a Text Request or the T
       bit in the Login Request).

       The originator or declarer can either be the initiator or the target
       and the responder can either be the target or initiator,
       respec-tively. Target requests are not limited to respond to
       key=value pairs as offered by the initiator. The target may offer
       key=value pairs of its own.

       All negotiations are explicit (i.e., the result MUST be based only
       on newly exchanged or declared values). There are no implicit
       offers. If an explicit offer is not made then a reply cannot be
       expected. Con-servative design requires also that default values
       should not be relied upon when use of some other value has serious
       consequences.

       The value offered or declared can be an numerical-value, a
       numerical-range defined by lower and upper value - both integers
       separated by tilde, a binary value, a text-value, a
       iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or
       No), or a list of comma separated text-values. A range MAY ONLY be
       offered if it is explic-itly allowed for a key.  An iSCSI-name-value
       and an iSCSI-local-name-value can be used only where explicitly
       allowed. A selected value can be an numerical-value, a text-value or
       a boolean-value.

       If a specific key is not relevant for the current negotiation, the
       responder may answer with the constant "Irrelevant" for all types of
       negotiation.  However the negotiation is not considered as failed if
       the response is Irrelevant.

       Any key not understood by the responder may be ignored by the
       responder without affecting the basic function. However, the Text
       Response for a key not understood MUST be key=NotUnderstood.

       The constants "None", "Reject", "Irrelevant", and "NotUnderstood"
       are reserved and must only be used as described here.

       Reject or Irrelevant are legitimate negotiation options where
       allowed but their excessive use is discouraged.

       Some basic key=value pairs are described in Chapter 11. All keys in
       Chapter 11, except for the X- extension format, MUST be supported by
       iSCSI initiators and targets and MUST NOT be answered with
       NotUnder-stood.

       Implementers may introduce new keys by prefixing them with X-
       fol-lowed by their (reversed) domain name. For example the entity
       owning the domain acme.com can issue:

   List negotiations

       In list negotiation, the originator sends a list of values (which
       may include "None") in its order of preference.

       The responding party MUST respond with the same key and select first
       value that it supports (and is allowed to use for the specific
       origi-nator) selected from the originator list.

       The constant "None" MUST always be used to indicate a missing
       func-tion. However, None is a valid selection only if it is
       explicitly offered.

       If a responder does not understand any particular value in a list it
       MUST ignore it. If a responder does not support, does not understand
       or is not allowed to use anyone of the offered options with a
       spe-cific originator, it MAY use the constant "Reject" or it respond
       with an admissible value.  The selection of a value not offered is
       consid-ered a negotiation failure and is handled as a protocol
       error.

       For simple-value negotiations, the responding party MUST respond
       with the same key. The value it selects, based on the selection rule
       spe-cific to the key, becomes the negotiation result. For a
       numerical range the value selected must be an integer within the
       offered range or "Reject" (if the range is unacceptable).  An offer
       of a value not admissible (e.g., not within the specified bounds)
       MAY be answered with the constant "Reject" or the responder MAY
       select an admissible value. The selection, by the responder, of a
       value not admissible under the selection rules is considered a
       negotiation failure and is handled accordingly. The selection rules
       are key-specific.

       For boolean negotiations (keys taking the values Yes or No), the
       responding party MUST respond with the same key and the result of
       the negotiation when the received value does not determine that
       result by itself. The last value transmitted becomes the negotiation
       result. The rules for selecting the value with which to respond are
       expressed as Boolean functions of the value received and the value
       that the responding party would have selected if given a choice.

          - The boolean function is "AND" and the value "No" is received.
            The outcome of the negotiation is "No".
          - The boolean function is "OR" and the value "Yes" is received.
            The outcome of the negotiation is "Yes".

       Responses are REQUIRED in all other cases, and the value chosen and
       sent by the responder becomes the outcome of the negotiation.

       __________________________________________________
       Do You Yahoo!?
       Yahoo! Health - your guide to health and wellness
       http://health.yahoo.com

---

From: Martins Krikis <[email-masked]>
Date: Fri, 10 May 2002 17:06:59 -0500

> rest of the text is understandable but here we have an issue. How about the

I never said that the rest^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H

:-)

And I am a fairly typical geek, not of the funny sort...
Seriously, though, I've deleted most everything, except where I have
something more to say.

>          hex-constant: hexadecimal constant encoded as a string start-ing

typo, late in the paragraph (not quoted here), "eading" should be "leading".

>            trailing equals has a byte-length of ((the integer part of)

Do the n base64 characters include the m equals or not? Either way,
I don't think the formula is right, but I'm too lazy to look up the RFC.
I do know however, that the RFC makes it perfectly unambiguous what the
encoded string is, so giving this formula may not be necessary.
If it is given then I think "the integer part of n*3/4" would do,
"where n is the number of base64 digits excluding the trailing equals, 
if any".

>       key=value pairs of its own.

Shouldn't "Target requests" be changed to "Targets"?

>       consid-ered a negotiation failure and is handled as a protocol

I don't think the word "anyone" (which may have been meant as "any one"?)
was any improvement, but I'll let the native english speakers object to this.
In order to really put it unambiguously the whole sentence has to be redone
(and I did offer a suggestion); just a one word change will not suffice, IMHO.
(And I think "options" should be "values".)

The phrase "or it respond with an admissible value" is new,
has an extra word "it", and is inapropriate here. After all, if the
responder could not use any of the offered values, yet instead of using
Reject it chose another "admissible" value, then this value is clearly
not from the offered list of values and therefore the next sentence
classifies it as a negotiation failure and a protocol error. I don't think
the specification should give instructions using "MAY" on how to create
protocol errors. 

>       negotiation failure and is handled accordingly. The selection rules

Why exactly is it allowed to tolerate an offer that is not admissible?
It looks like the originator that sends complete garbage may be treated
better than an originator that sends an admissible value that is not
good for the responder. I guess what I'm saying mostly applies to ranges.
This is not very important, just a weird "feature" the purpose of which
I don't really get.

Thanks,

Disclaimer: these opinions are mine and may not be those of my employer