SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Section 4.1 clarifications




    And you where not very successful as many management tools have already their own representation.
    Limiting the maximum decimal integer is the best practical solution now.

    Julo


    Mark Bakke <mbakke@cisco.com>
    Sent by: mbakke@cisco.com

    04/25/2002 11:48 PM
    Please respond to Mark Bakke

           
            To:        Paul Koning <ni1d@arrl.net>
            cc:        Julian Satran/Haifa/IBM@IBMIL, michael.krueger@windriver.com, ips@ece.cmu.edu
            Subject:        Re: Section 4.1 clarifications

           


    Paul Koning wrote:
    >
    > >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
    >
    >  Julian> Michael, The integer representation was discussed a long time
    >  Julian> ago on the list and it was decided that decimal should be
    >  Julian> allowed as it might be copied from some human readable
    >  Julian> tables. I would hate to make this type of changes this late.
    >
    > Was it ever the intent that things like Diffie-Hellman parameters
    > could be expressed in decimal?  That seems like a VERY VERY bad idea;
    > where is someone going to find a function that converts a decimal
    > string to a bignum?
    >
    > Decimal is fine for any parameter that's a "normal size" integer,
    > i.e., a 32 bit or even -- probably -- a 64 bit integer.  But bignums
    > should only ever be expressed in hex or base64.

    I agree.

    We tried to bring this up last summer.  Each key should specify
    one and only one format, whether that's hex, base64, decimal,
    whatever, that it MUST use, and leave it at that.  There is absolutely
    no reason why an implementation should be able to choose to send
    decimal for a key today, and hex tomorrow.  That way, there would
    have been no need to parse "0x" in front of hex strings, etc.
    It would have kept this a lot simpler, and I don't see a good reason
    why anyone would want more flexibility than this.  Also, the
    ability to use either upper or lower case for hex is a bit
    unnecessary, but at least this shouldn't cause too much trouble.

    Anyway, we already have a little section for each key specifying
    what it does, and who can sent it.  It would be little trouble,
    and probably greatly benefit interoperability, to just specify
    for each text key which format its value uses, and stick with
    it.  Why make life any harder for the receiver than it has to
    be?

    >
    >        paul

    --
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054




Home

Last updated: Fri Apr 26 10:18:21 2002
9806 messages in chronological order