Re: iSCSI: Decimal encoding - why 64 bits ?

["Julian Satran \(Actcom\)" <Julian_Satran@actcom.net.il>]

The trouble with the current definition is that TPGT has no number
characteristics at all (there is no ordering defined).
For implementations the changes is irrelevant.
And you may continue to use whatever you want. I do not see how 0 will
prevent somebody encode it in decimal (as most do).
And believe me I do not change things to prove a point - I am too old for
that.

As for you conversion rules - some of the steps are  there regardless of
where you com from - hex to string may be subject to byteswap too!
(specially if you define it as a number!).

My point was that once you have decimal in the is no point is forbidding it
in some instances.

Julo
----- Original Message -----
From: "Martins Krikis" <mkrikis@yahoo.com>
To: "Julian Satran (Actcom)" <Julian_Satran@actcom.net.il>; "ips"
<ips@ece.cmu.edu>
Sent: Friday, July 05, 2002 7:25 PM
Subject: Re: iSCSI: Decimal encoding - why 64 bits ?


>
> --- "Julian Satran (Actcom)"
> <Julian_Satran@actcom.net.il> wrote:
> > Martins,
> >
> > In fact reading your note I went back and found an
> > error we may want to
> > correct:
> >
> > TargetPortalGroupTag is a 16 bit binary string and
> > not an number (there is
> > no TPGT that is lower or higher than another TPGT).
>
> Again, I don't have draft 14 in front of me but
> 13 says that TPGT is "a simple unsigned-integer
> between 1 and 65535" (2.4.1 (e)) and a "numerical-
> value-from-1-to-65535" (11.9). I would prefer it if
> you did not change this to a "binary string" just
> to prove a point that there are binary strings
> for which decimal encoding is natural. That, IMO,
> would be a very profound change at an extremely
> late stage. (If you do, I'll make sure all my
> TPGTs start with 0x00 and deny all attemts to
> encode them in decimal :-)).
>
> > There are no good examples that need decimals other
> > than TPGT but I see no
>
> Even TPGT is not a good example, as it is defined
> to be a number, for now at least.
>
> > point in disallowing them for vendor keys and future
> > extensions. Any
> > implementation will have the conversion routines.
> > Restricting the use of
> > decimals beyond what we did does not strike me as
> > useful.
>
> Others (and there are many) here seem to be
> disagreeing with you.
>
> The conversion, while possible, will likely
> first use some common library routine, then
> byteswap (if running on little-endian), then
> do a pass to eliminate leading 0-bytes, which
> are not representable in decimal.
>
> OK, my final argument. Here are two binary
> strings, encoded in hex: 0x01 and 0x0001.
> Can you give us an example of encoding both
> of them in decimal in such a way that they
> can be distinguished?
>
> Martins Krikis, Intel Corp.
>
> Disclaimer: these opinions are my own and may
>             not be those of my employer.
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com