|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Section 4.1 clarifications>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes: Julian> And you where not very successful as many management tools Julian> have already their own representation. Limiting the maximum Julian> decimal integer is the best practical solution now. Management tools are completely irrevent to this issue. We're talking about the encoding of bignums in the iSCSI protocol. How, or whether, those things are encoded in management protocols is a completely separate discussion. (Then again, if you look in MIBs you will find these things encoded as octet strings, i.e., binary strings -- not as integers.) Julian> Julo Julian> Mark Bakke <mbakke@cisco.com> Sent by: mbakke@cisco.com Julian> 04/25/2002 11:48 PM Please respond to Mark Bakke Julian> To: Paul Koning <ni1d@arrl.net> cc: Julian Julian> Satran/Haifa/IBM@IBMIL, michael.krueger@windriver.com, Julian> ips@ece.cmu.edu Subject: Re: Section 4.1 clarifications Julian> 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. Julian> I agree. Julian> We tried to bring this up last summer. Each key should Julian> specify one and only one format, whether that's hex, base64, Julian> decimal, whatever, that it MUST use, and leave it at that. Julian> There is absolutely no reason why an implementation should be Julian> able to choose to send decimal for a key today, and hex Julian> tomorrow. That way, there would have been no need to parse Julian> "0x" in front of hex strings, etc. It would have kept this a Julian> lot simpler, and I don't see a good reason why anyone would Julian> want more flexibility than this. Also, the ability to use Julian> either upper or lower case for hex is a bit unnecessary, but Julian> at least this shouldn't cause too much trouble. Julian> Anyway, we already have a little section for each key Julian> specifying what it does, and who can sent it. It would be Julian> little trouble, and probably greatly benefit Julian> interoperability, to just specify for each text key which Julian> format its value uses, and stick with it. Why make life any Julian> harder for the receiver than it has to be? >> paul Julian> -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 Julian> <br><font size=2 face="sans-serif">And you where not very Julian> successful as many management tools have already their own Julian> representation.</font> <br><font size=2 Julian> face="sans-serif">Limiting the maximum decimal integer is the Julian> best practical solution now.</font> <br> <br><font size=2 Julian> face="sans-serif">Julo</font> <br> <br> <br> <table Julian> width=100%> <tr valign=top> <td> <td><font size=1 Julian> face="sans-serif"><b>Mark Bakke Julian> <mbakke@cisco.com></b></font> <br><font size=1 Julian> face="sans-serif">Sent by: mbakke@cisco.com</font> <p><font Julian> size=1 face="sans-serif">04/25/2002 11:48 PM</font> <br><font Julian> size=1 face="sans-serif">Please respond to Mark Bakke</font> Julian> <br> <td><font size=1 face="Arial"> Julian> </font> <br><font size=1 face="sans-serif"> Julian> To: Paul Julian> Koning <ni1d@arrl.net></font> <br><font size=1 Julian> face="sans-serif"> cc: Julian> Julian Satran/Haifa/IBM@IBMIL, Julian> michael.krueger@windriver.com, ips@ece.cmu.edu</font> Julian> <br><font size=1 face="sans-serif"> Julian> Subject: Re: Section 4.1 Julian> clarifications</font> <br> <br><font size=1 Julian> face="Arial"> </font></table> <br> Julian> <br><font size=2 face="Courier New">Paul Koning wrote:<br> Julian> > <br> > >>>>> "Julian" == Julian> Julian Satran <Julian_Satran@il.ibm.com> writes:<br> Julian> > <br> > Julian> Michael, The integer Julian> representation was discussed a long time<br> > Julian> Julian> ago on the list and it was decided that Julian> decimal should be<br> > Julian> allowed as it Julian> might be copied from some human readable<br> > Julian> Julian> tables. I would hate to make this type of Julian> changes this late.<br> > <br> > Was it ever the intent Julian> that things like Diffie-Hellman parameters<br> > could be Julian> expressed in decimal? That seems like a VERY VERY bad Julian> idea;<br> > where is someone going to find a function that Julian> converts a decimal<br> > string to a bignum?<br> > <br> Julian> > Decimal is fine for any parameter that's a "normal Julian> size" integer,<br> > i.e., a 32 bit or even -- Julian> probably -- a 64 bit integer. But bignums<br> > Julian> should only ever be expressed in hex or base64.<br> <br> I Julian> agree.<br> <br> We tried to bring this up last Julian> summer. Each key should specify<br> one and only one Julian> format, whether that's hex, base64, decimal,<br> whatever, Julian> that it MUST use, and leave it at that. There is Julian> absolutely<br> no reason why an implementation should be able Julian> to choose to send<br> decimal for a key today, and hex Julian> tomorrow. That way, there would<br> have been no need Julian> to parse "0x" in front of hex strings, etc.<br> It Julian> would have kept this a lot simpler, and I don't see a good Julian> reason<br> why anyone would want more flexibility than Julian> this. Also, the<br> ability to use either upper or Julian> lower case for hex is a bit<br> unnecessary, but at least Julian> this shouldn't cause too much trouble.<br> <br> Anyway, we Julian> already have a little section for each key specifying<br> Julian> what it does, and who can sent it. It would be little Julian> trouble,<br> and probably greatly benefit interoperability, Julian> to just specify<br> for each text key which format its value Julian> uses, and stick with<br> it. Why make life any harder Julian> for the receiver than it has to<br> be?<br> <br> > <br> Julian> > paul<br> <br> -- <br> Mark Julian> A. Bakke<br> Cisco Systems<br> mbakke@cisco.com<br> Julian> 763.398.1054<br> </font> <br> Julian> <br>
Home Last updated: Fri Apr 26 12:18:21 2002 9810 messages in chronological order |