> On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote: > > I am not going to dive in here and increase my responses on this > > thread and eat up my limited messages I will bombard this list with > > ok, supporting the mail model less mail is better and > keeping low on > > Rob's messages list each week. > > Better waste less bandwidth with the above and send a bit > more messages ;)
OK one more. This suggestion does not have consenus as Bob stated thus my last email on this one. > > > But, besides v4mapped being widely deployed on "vendor" > "production" > > shipping code bases, used today by applications, > > Please name these 'vendor's and 'applications' I am quite > sure if you ask them that they think it should be removed if > they have made to try the code run on more than a single platform. I will not name applications but HP, IBM, Sun, and vendors who productize Linux and FreeBSD to name a few. V4-mapped addresses are part of the POSIX standards as stated in the Literature reference below. > > > believe v4mapped is a very useful and elegant solution for > application > > providers to provide a common binary v4+v6 solution as an option > > "technically" and superior to not using it. > > Please look at the Apache2 APR code which demonstrates how 'elegant' > this solution is because it is not default. The default is up to the software developer Netscape chose differently. It is a choice in the standard. > > > I emphatically disagree > > with Itojun, cmetz, et al referenced and we had this debate > many years > > ago, then again had the debate, and that view lost and we > should not > > revisit it again. > > You mean some people shoved the arguments away without having > any background in the subject? That is a baldface indirect lie, and slander in the form of a question to the team that worked on this for a long time, and you were not in those conversations or on the api-list or part of the team, which was where the in depth technical debate took place. Now that you have decided to question the honor of the team that worked on this discussion, and I was part of that team, I suggest you and I take this offline in person face to face if you happen to be in Minneapolis around March 6-9. I will look forward to it unless you can only dishonor persons behind an indirect email message and don't have the guts to do it in person? > > > No one has to implement a port to IPv6 or a new application with > > v4mapped addresses. It is merely an option that is available to a > > programmer and upto them and it is available on production > platforms > > today. > > The production platforms mostly use KAME stacks, the other is Windows. KAME is one version and view of FreeBSD. I have no response regarding what Windows supports or does not support. > Guess what both of these platform don't have, at least turned on per > default: ipv4-mapped. That is fine and not the point of this discussion. The point of this discussion is to continue to support the ability to use v4-mapped addresses. That I believe has consensus. > > Please name the platforms you call 'production'. Did above your repeating yourself. > > > Mark Andrews point is quite valid and that is the responsibility of > > each implementation to document their use of v4mapped, and out of > > scope for the IETF as that is an implementation manner. > Whether it is > > useful to document various behaviors (INFO, BCP) is not clear to me > > that is necesary and see UNIX Network Programming Volume I > Third Edition. > > Which nicely mentions the use of getaddrinfo() and separately doing :: > and 0.0.0.0 with IPV6_ONLY sockets because of the inherit > issues mentioned by Itojun. Give me a break Jeroen. Read pp's 315 and on; the authors presented all cases and v4-mapped is in the tables and it provides an unbiased view presenting both solutions, I saw preliminary versions of this section before it was published from one of the reviewers and I recall then it was an unbiased version as was the Second Edition (minus the new IPv6-ONLY option). The compromise we defined in the API is to support IPv6-ONLY option there is no problem here at all. I see no point of further responses to this email it has all been discussed before, and the bogus accusations like the one you made above too. /jim > > Greets, > Jeroen > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
