[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D Action:draft-kawamura-ipv6-text-representation-01.txt



Hi Jeroen,

On 2009-04-23 01:43, Jeroen Massar wrote:
> Brian E Carpenter wrote:
>> As I understand it, this draft defines a canonical form
>> of address representation and recommends that it be used
>> to minimise human confusion.
>>
>> That isn't a bad idea, but IMHO we need a clear statement
>> that humans and algorithms SHOULD generate this format,
>> and that all implementations MUST accept any legitimate
>> RFC4291 format.
> 
> What I tend to do in my programs is accept any and then "rewrite" the
> address, generally just using getaddrinfo(), then only using the data
> returned by getaddrinfo; representation to the user can then be done by
> getnameinfo(). This way one always(*) has the same format. It is a bit
> 'bad' that one can't store eg /64 inside that structure, now one always
> have to keep it separate.
> 
> Greets,
>  Jeroen
> 
> * = unless the function calls do random changes at output time but from
> what I have seen all platforms do lowercase hex fully compressed hex output.

Does "fully compressed" express :0: as ::? The draft recommends against that.

However, I agree that making the canonical format the same as is generated
by the existing API code seems like a Good Thing.

    Brian