RE:

[pat_thaler@agilent.com]

John,

You have left out the third thing being discussed which is decimal numbers for binary-value fields (which are used in SRP and CHAP). The current draft allows them when the binary-value represents a value less than 64 bits. This is a problem as it does currently require a 58-bit decimal to binary conversion. 

Pat

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Friday, July 05, 2002 11:41 AM
To: Julian Satran (Actcom)
Cc: Martins Krikis; ips
Subject: Re:



Julian's point is valid.  However, I think we are getting two things mixed
together.

The two items are,
1. should a decimal number be usable for string fields.  Julian's examples
are correct.  That, in my opinion should end that part of the discussion.
2. should decimal numbers be larger than what would fit in a 32 bit field.

My opinion is that we should future proof our specification to permit
decimal numbers which are larger then 32 bits.

An implementation can clearly chose not to support 64-bit decimal numbers
now,  and thus be less easily extensible in the future.  However, that may
be a trade-off which some think they need to make now.  (This is possible
since we have not currently identified a hard requirement.)

However, the decimal value for 64 bit fields, permits the spec to fully
support any vendor "x" keys that permit it, and permits the spec to move
forward in the future without revisiting this discussion.

In summary, in my opinion, for point 1. decimal numbers do currently map to
binary fields so I think that discussion should be over, and for point 2, I
think defining 64 bit fields for Decimal Numbers is the right thing to do
for future-proofing reasons.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Julian Satran \(Actcom\)" <Julian_Satran@actcom.net.il>@ece.cmu.edu on
07/05/2002 08:37:51 AM

Sent by:    owner-ips@ece.cmu.edu


To:    "Martins Krikis" <mkrikis@yahoo.com>, "ips" <ips@ece.cmu.edu>
cc:
Subject:    Re:



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).

As for IP addresses they are just for illustration - each of the address
item is a an 8 bit  binary string of fixed length usually encoded decimal.

There are no good examples that need decimals other than TPGT but I see no
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.

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 5:02 PM
Subject: Re:


>
> --- "Julian Satran (Actcom)"
> <Julian_Satran@actcom.net.il> wrote:
> > Leading 0 where forbidden after a brief discussion.
> > As for unlikely to be used - I could argue for the
> > contrary - as in the examples I gave in a previous
> > notes.
> > Many string copied from humanly readable documents
> > tend to be decimal-encoded.
>
> Julian,
>
> You are right about the leading 0, thus Bill's
> example was a bad one. He is right however about
> the inability to express the leading nul-bytes of
> a binary string when it is encoded in decimal.
>
> The examples you gave previously (unless some
> have escaped me) were really bad. I have yet to
> see a true "binary string" (and not a number)
> encoded in decimal.
>
> Martins Krikis, Intel Corp.
>
> Disclaimer: these opinions are mine and may not
>             be those of my employer.
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com