Date: Wed, 25 Jun 2003 11:13:55 +0900
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| i disagree with the standpoint. if we don't standardize what
| is accepted by inet_pton(), we will have usability/portability problem.
We need to standardise what inet_pton() is expected to be able to
convert. We don't have to prohibit it from accepting anything else.
Then people should be encouraged to generate only that expected form
(or those forms). And certainly inet_ntop() should do that. But if
I am manually typing one of those addresses, I really don't want to be
penalised for accidentally typing one too many meaningless leading zeroes.
| if we leave it to "do whatever you want" state as you said, we will
| experience painful cleanup process in the near future, just like
| transition from inet_aton to inet_pton (inet_aton accepted hex/octal/
| less-than-four component format, and inet_pton only accepts decimal
| 4-component format).
As I recall, what input was legal for inet_aton() (inet_addr() really, that's
where all this started) was never defined - that is, whether 10.1 was legal
or not was just discovered by accident (and that 128.1 meant something
quite different than 10.1 - or sometimes did).
I certainly agree that we need to document the format in which addresses
should be written in order to be able to be processed everywhere. That
is "do whatever you want" isn't anyone's position here I don't think
(that would include, for example, allowing an implementation of inet_pton()
which expected a string of 32 hex digits without punctuation, and which
rejected anything else.)
But it is just silly to attempt to tell people that they're not allowed
to implement harmless extensions which make things easier to use. In
time some of those extensions may become so widely used as to become
(effectively) standard - if we had been going to actually standardise
inet_aton() 12/13 years ago (or more), then 10.1 would almost certainly
have been included as legal. Today we wouldn't do that, as classful
addresses are essentially dead (the 1918 addresses being probably
the last real hold-outs).
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
