>>
>> The code below would be straightforward if the "/64" prefix were
>> accepted by getaddrinfo.
>>
>> Besides, I don't think the textual representation should be defined
to
>> make only Basic Socket API functions straightforward. IMHO, the
order
>> should be logical on its own. The prefix is clearly more tightly
>> related to the IP address (in6_addr) and the scope zone index is
>> clearly (by virtual of the fact that scope_id is in sockaddr_in6)
>> related to the transport address. So the textual representation as
it
>> stands now mixes IP address and Transport address information.
>>
>> --Stephen
>
> No they are both properties that can be associated with a
> address. If anything the scope ties closer than the prefix
> as a link-local address or prefix is meanless w/o the scope.
I'm not sure what you mean by "address" above. My argument is that the
prefix is associated with IP addresses (represented by struct in6_addr
in the API) and the scope is associated with transport addresses
(represented by struct sockaddr_in6 in the API). They are both
"addresses", but they are different layer addresses. If I map what
textual representation to what data structure it has effect on:
[ipaddr%scope/prefix]:port is mapped into
[in6_addr%sockaddr_in6/in6_addr]:sockaddr_in6
>From my view the the textual representation and the Basic socket API
structures are inconsistent.
>
> Mark
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
