Subject: RE: iSCSI - re-phrase of 4.1

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 2 May 2002 17:09:58 -0600

hex-constant: unsigned hexadecimal constant described by regu-lar expression
"0[xX][0-9a-zA-Z]+" 

Hexidecimal only uses the alphabet up to F so the regular expression should
be: "0[xX][0-9a-fA-F]+" 

Pat
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Saturday, April 27, 2002 9:15 AM
To: [email-masked]
Subject: iSCSI - re-phrase of 4.1

Here is an attemp to re-phrase 4.1. 
Please note that the only substantive change introduced is the limit of
2**64 for the decimal encoding. 
The fact that key names must start with a letter and that binaries are all
unsigned is made explicit. 

Please comment: 

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 docu-ment 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) - point 
"-" (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 is key-name followed by "=". 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
separator - that separates one key value from the next 

A value is either a simple-value or a list-of-values. 

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

key-name: a string defined by the regular expression 
"[A-Z][a-zA-Z0-9.-+@_]*" 

text-value: a string defined by the regular expression 
"[][a-zA-Z0-9.-+@_/\[\]=]*" 

boolean-value: a string defined by the regular expression 
"Yes|No" 

hex-constant: unsigned hexadecimal constant described by regu-lar expression
"0[xX][0-9a-zA-Z]+" 

base-64-constant: unsigned base-64 constant described by regu-lar expression
"0b[A-Za-z0-9+/=]+" 

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

large-binary-value :  an unsigned integer larger than 2**64-1 encoded as a
hex constant, or base-64 constant 

binary-value: a regular-binary-value or a large binary-value 

numeric-range: two binary-values separated by a tilde 

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

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

Key names MUST NOT exceed 63 bytes.  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 indicat-ing support for
very long authentication items such as public key cer-tificates in which
case they MUST support receiving at least 64 kilobytes of key=value data.

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 03 May 2002 10:18:53 -0400

> "THALER,PAT (A-Roseville,ex1)" wrote:
> 
> hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+"
> Hexidecimal only uses the alphabet up to F so the regular expression should be:
> "0[xX][0-9a-fA-F]+"

Wasn't there some consenus that there will be no extra leading 0, unless
part of the base identifier (and thus at most one)? Else I can
put 1e9 zeros like this: 0x0000...03 to be a valid hex const.

Also why do we need to _restrict_ as to the sign of
a hex constant. I'm sure that sooner or later it will
have its applications. If a value cannot be negative
and a node sent it as negative then the peer will
reply with Reject or appropriately.

Isn't all this the whole point of interoperability and
the use of Reject, et al?

Thus,
hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]*

And similarly for the others.

-- 
Luben

---

From: "Randy Jennings" <[email-masked]>
Date: Thu, 2 May 2002 19:57:42 -0700

Comments in text

> reply with Reject or appropriately.
Granted, I am a young engineer, but I have never seen a signed hex constant.
I've always seen decimal when signed.  In my (vast :-> ) experience, hex is
always used to represent straight bits.  Period.  You have enough zeros for
place holders for the bits and that is all you ever have.  If it happens to
translate into a numeric value, that is ducky, but not necessary.

> hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]*
In any case, with this regex, 0x0 is no longer valid.  If you persist in not
wanting leading zeros, try:
hex const: 0[xX](([1-9A-Fa-f][0-9A-Fa-f]*)|0)
                 ^                       ^
I do not know if these are needed, but they should not hurt

I also removed the + because the * after the second term takes care of it.

Sincerely,
Randy
Data Transit

---

From: Mark Bakke <[email-masked]>
Date: Fri, 03 May 2002 11:28:49 -0500

The problem with not allowing leading zeroes in binary (hex)
encodings is that some keys, such as CHAP_C, are not guaranteed
to always be the same length.  Currently, we get the length
from counting the number of hex digits for the key.  If leading
zeroes are not allowed, this won't work.

Since leading zeroes don't hurt a hex constant anyway (e.g. these
would come after the 0x, so we won't confuse them with octal),
we should allow them so we don't have to introduce length fields.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054