>My take on this is that it simply doesn't matter - there is no
>need to be specific on what is permitted, and what is not.
>
>What needs to be specific is what must be permitted - if implementations
>then want to allow extensions, that's fine.
>
>So, what should be defined is a standard representation form, and
>all parsers should be required to correctly parse that form, but
>if some parser wants to handle more than that, I cannot think of
>any good reason to forbid it.
>
>So, I would not require
> :01234:
>to be handled by inet_pton() and friends, but if it happens to be
>easy to implement, or deemed useful, then fine.
>
>And the same is true for 001234 0001234 or 000000000001234 - to any
>normal human they all mean the same thing.
>
>Similarly, even though no-one I know does it, and I certainly wouldn't
>require it, if someone wants to allow
>
> 2002:10.11.12.13::/48
>
>that's just fine too (ignoring the use of a 1918 address in a 6to4
>address for this purpose).
i disagree with the standpoint. if we don't standardize what
is accepted by inet_pton(), we will have usability/portability problem.
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).
itojun
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
