Folks, This is the last issue for the base api . We will send in final draft for INfo RFC annouce from the chairs. The only change will be to add Jack McCann as co-author to the base API current draft spec. This request is out of scope for this API. It could be an extension to the Advanced API possibly.
I will send in new ID and to Steve and Bob to send ton IESG for INFO RFC Last Call. Thanks to the entire working group and the hard work and collaboration of the IEEE . This has been a longgggggggggggggg process. /jim > > >Date: Mon, 17 Dec 2001 09:08:32 -1000 (HST) > > >From: Antonio Querubin <[EMAIL PROTECTED]> > > >To: Bob Hinden <[EMAIL PROTECTED]> > > >cc: <[EMAIL PROTECTED]> > > >Subject: Re: IPv6 w.g. Last Call on "Basic Socket Interface > > Extensions for > > > IPv6" > > >Sender: [EMAIL PROTECTED] > > > > > >On Tue, 11 Dec 2001, Bob Hinden wrote: > > > > > > > This is a IPv6 working group last call for comments on > > advancing the > > > > following document as an Informational RFC: > > > > > > > > Title : Basic Socket Interface Extensions for IPv6 > > > > Author(s) : R. Gilligan, S. Thomson, J. > > Bound, W. Stevens > > > > Filename : draft-ietf-ipngwg-rfc2553bis-04.txt > > > > Pages : 32 > > > > Date : 27-Nov-01 > > > > > > > > This document will replace RFC2553 that is currently an > > Informational > > > > RFC. The changes from RFC2553 are listed on pages 29 and > > 30 of the draft. > > > > > > > > Please send substantive comments to the ipng mailing > > list, and minor > > > > editorial comments to the authors. This last call period > > will end two > > > > weeks from today on December 26, 2001. > > > > > > > > Bob Hinden / Steve Deering > > > > > >This may be a bit late but I do think that the API should > > address better > > >compatibility with IPv4 multicast. There was some > > discussion earlier this > > >year about this but no consensus was reached other than that > > it should be > > >fixed. > > > > > >The problem I think would be helped if, for the purposes of this API, > > >section 3.7 was extended to optionally allow for a pseudo IPv4-mapped > > >multicast address. I'm suggesting adding two sentences to > > paragraph 2 of > > >section 3.7: > > > > > >"These addresses can be generated automatically by the getaddrinfo() > > >function, when the specified host has only IPv4 addresses > > (as described in > > >Section 6.1 and 6.2). For the purposes of this API, the > > allowed range of > > ><IPv4-address> may be extended beyond that defined in RFC > > 2373 to also > > >include multicast addresses. The resulting mapped address should be > > >treated as a multicast address." > > > > > >This addition is motivated by one of the design > > considerations of the API: > > > > > >" - Where possible, applications should be able to use this > > > API to interoperate with both IPv6 and IPv4 hosts. > > Applications > > > should not need to know which type of host they are > > > communicating with." > > > > > >And further down we have: > > > > > >"Because of the importance of providing IPv4 compatibility > > in the API, > > >these extensions are explicitly designed to operate on machines that > > >provide complete support for both IPv4 and IPv6." > > > > > > > > > > > > > > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
