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).
inet_ntop() and friends should only ever generate "standard form"
strings (this is what INET6_ADDRSTRLEN relates to, it is
irrelevant when considering inet_tton()) and anyone who (for
whatever bizarre reason) is writing a literal address and actually
cares about portable interpretation, should only ever write them
in standard form. But none of that says that inet_pton() should
reject addresses that aren't in that standard form.
The only note I'd add, is that implementors should use some caution
in the additions they permit, so as to avoid accidentally treating
strings which "obviously" weren't intended to be IPv6 address literals
as if they were.
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]
--------------------------------------------------------------------
