SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    
    
    
    
    
    


Home

Last updated: Sat Jul 06 23:18:43 2002
11148 messages in chronological order