>>>>> On Mon, 7 Nov 2005 12:58:08 -0800, >>>>> "Roy T. Fielding" <[EMAIL PROTECTED]> said:
>> >It would be very confusing for the user to see they can simply reuse >> >the output of the diagnostic tool in some cases and they need to >> >convert the output in some other cases. > Then change the diagnostic tool to use '+' as a separator instead > of '%'. It would still be confusing since the user still needs to add "v1.". But that's not my main point. >> Also, this is not a matter of formality, it is a matter of >> deployment. What if something like "http://[v1.fe80::abcd%fxp0]/"; >> suddenly gets converted into "http://[v1.fe80::abcd<0x0F>xp0]/" >> (<0x0F> standing for a 0F byte, which is Shift In). > It is a matter of it not working with deployed practice because > some parsers will simply puke and die, some will correctly interpret > it as an error, some will interpret it as a %xx encoding, and some > will just pass it on to gethostbyname(). It cannot be standardized > because we are talking about 75 million deployed servers and > 600+ million deployed browsers that will be on the Internet for a > long time and will not handle such an address in a predictable > manner. If it simply failed in a predictable manner (as with > UTF-8 encoded hostnames), then we could have handled it as a > workaround. As I repeatedly said, I don't buy this argument, since the format described in draft-fenner-literal... also requires changes to the 600+ million deployed browsers (BTW: this is irrelevant to the 75 million deployed servers because the extended format is not passed to the server). Also, as I said in a separate message, people will blindly keep copy-and-pasting the '%' format. So standardizing the "v1." + "+" doesn't keep the parsers from puking or dying or producing errors, etc. > As it is, we are better off changing the format delimiter to > something that isn't inherently incompatible with URIs. Meanwhile, > IPv6 is fully capable of making it easier on users by adopting > the new format in all cases -- IPv6 tools that print link-local > addresses are not as widely deployed as Web browsers and servers, > are not even standard in format across different OSes, and are far > easier to update (via OS patches) in a uniform manner. Again, with all due respect, I don't buy this argument. I don't know how many numbers of BSDs, Linux, Windows XP, and Mac OS X have shipped, but the fact is URI-processing software and IPv6 software are both so deployed that we cannot simply make "this one is not fully deployed so fixing this side should be easier". I respect the deployed number of URI parsers and so I don't make this argument, but I cannot accept underestimating the deployment status of the IPv6 tools understanding RFC4007. People tend to underestimate the impact on areas they are not familiar with, and I don't think any arguments based on this type of underestimation solve this issue. >> >If this is a matter of interoperability or compatibility, I agree the >> >formality or compliance should be highly honored. But since this case >> >can actually only be informational in that the format cannot be >> >disclosed outside the node, I'd rather prefer satisfying users. >> > >> >Again, I see the point of the opposite opinion, and I'd let it go if >> >that's in the majority. But I'd like to see the consensus clearly. > Consensus is good, but it cannot replace facts. The fact of the > matter is that STD 66 will not be changed to allow the % to be > used as a delimiter because doing so would encourage people to > use identifiers that are known to cause working, deployed, and > interoperable systems on the Internet to fail. The IETF standards > process does not allow us to make such a change for good reason. > If people want to use a link-local address in a URI, then they need > a syntax that works within the known interoperability constraints > of URI. There is no other option that can be standardized. As I said (or indicated) before, I do not necessarily think this needs to be "standardized" in that it's published as a standard track RFC, updating the existing URI standard. But I admit the URI community will never even accept that option (perhaps that's why Bill submitted this version with the "v1" + "+" format). Now, let me clarify my main point. I'm not pushing the idea of making "http://[fe80::abcd%fxp0]"; acceptable for the URI parsers. My impression about the current proposal is this has just become a useless format for users (if any) for the reason because the URI community will never accept the bare % format. I showed why I believe this is useless (in that it's confusing for users), and my fundamental question is whether there are really serious users with the yet another format. If there are, and if they don't mind the inconvenience I showed, I won't make further objection. But so far, I've only seen negative responses (with an implicit exception of Bill, who seems to be a user who can live with this format). According to Pekka's response, he seems to feel it's useless (or at least it doesn't worth being standardized). I guess you and Martin are also dubious about the use of link-local addresses in the URI. I'm dubious about that, too. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
