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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 07, 2005 2:59 AM To: Steve Cipolli Cc: [email protected] Subject: Re: Ordering of % and / in RFC 4007 >>>>> On Wed, 6 Apr 2005 10:09:22 -0400, >>>>> "Steve Cipolli" <[EMAIL PROTECTED]> said: > Can someone explain the rational for why RFC 4007 mandates the scope > zone index before the prefix in the textual representation? (snip) > Section 11.7 says its important to put the scope zone index first for > parsing by name-to-address functions and references a document that I > was unable to find. I understand the "name-to-address functions" to > mean getaddrinfo. However I'm not clear why getaddrinfo should care > that scope zone index appeared first assuming the substring "ip6 ['/' > prefix]" were handled by a function similar in6_addr_pton above. The intended function is getaddrinfo, yes. And the expected usage in this case is as follows: (assume variable "prefix" points to a string like "fe80::%5/64") char *addr, *p; int plen; p = strchr(prefix, '/'); *p++ = '\0'; getaddrinfo(p, NULL, hints, res); plen = atoi(p); (Note: error handling or proper handling of constant variables are ignored for simplicity) Then ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr = fe80:: ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id = 5 plen = 64 If we represented the scoped prefix as, e.g., "fe80::/64%5", the above code couldn't be that straightforward. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
