> >> 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 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 prefi
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 07, 2005 2:59 AM
To: Steve Cipolli
Cc: ipv6@ietf.org
Subject: Re: Ordering of % and / in RFC 4007
>>>>> On Wed, 6 Apr 2005 10:09:22 -0400,
>>>>> "Steve Cipolli&quo
>
> 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 cle
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 07, 2005 2:59 AM
To: Steve Cipolli
Cc: ipv6@ietf.org
Subject: Re: Ordering of % and / in RFC 4007
>>>>> On Wed, 6 Apr 2005 10:09:22 -0400,
>>>>> "Steve Cipolli&quo
> 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 fi
