This looks like a misunderstanding of the Postel principle. Obviously, we should specify syntax that is non-redundant, i.e. no extra leading zeros. I think that is what the draft-main-ipaddr-text-rep-00.txt syntax does.
Also obviously, implementors who want to follow the Postel principle will write parsers that accept any number of leading zeros. But that isn't something we need to define in ABNF or in any API. It's just defensive programming. Brian [EMAIL PROTECTED] wrote: > > >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] > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- 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] --------------------------------------------------------------------
