+1
Lars Eggert wrote: > Hi, > > what Bob outlines below is pretty exactly what I thought the intent of this > ID was supposed to be, and going in this direction would certainly address my > discuss. > > Lars > > On 2010-2-5, at 22:47, Bob Hinden wrote: > >> Jari, >> >>> Then we talked about the strictness. I explained that this is largely a >>> specification style issue, and in the real world there will always be old >>> code that doesn't produce the canonical form, and that we hope that this >>> RFC will convince all new code to do the right thing. However, we came up >>> with the following proposal to make the specification stricter: >>> >>> - Use RFC 2119 language and MUST. Implementations conforming to this >>> specification MUST ... >>> - Provide a reference to the currently defined WKPs >>> - In the section that talks about ports, please make sure that for URIs >>> everyone MUST follow RFC 3986, and for the rest, the default can be again >>> RFC 3986. The current language leaves everything open, even for URIs. >>> - There's a part about reducing longest sequence of 0s -- it would be great >>> if we could point to some publicly available code that already does this, >>> as an informational reference to implementors >>> - We will keep the specification on the Standards Track, i.e., publish it >>> as a Proposed Standard >>> - This specification Updates RFC 4291 >>> >>> Would these changes be acceptable to the working group? >> [No hats on] >> >> I was thinking about this over the past few days after reading the IESG >> comments and a discussion with Brian Haberman. My personal take is that we >> lost sight of the original goal while trying to meet the broad requirements >> of the different variants of embedded addresses. >> >> I was thinking that we should have a strict canonical form along the line of >> what is proposed in Section 8. This format SHOULD always be used when an >> IPv6 address is saved to a file or log as text (as opposed to binary). The >> canonical format would not support any of the embedded formats. Everything >> would look like: >> >> 2001:db8:0:0:1:22::1 >> >> 2001:db8:0:0:1::1 >> >> 2001:db8:0:11:222:3333:c000:0201 >> >> Tools could be built that would allow alternative ways to display the >> addresses in the file. For example in the second case above, it could be >> displayed as: >> >> 2001:db8:0:11:222:3333:192.0.2.1 >> >> All operations used to compare and search against entries in the file would >> performed against the canonical format. A search tool could allow an >> address to be entered in an embedded format (or any format defined in >> RFC4291), but it would convert the address to the canonical format before >> the search is performed. >> >> This is similar to the way something a spread sheet deals with dates and >> times. The underlying data does not change if the user decides to change >> the format it is displayed. Or this is the way that I think tools like >> tcpdump deal with saved packet traces. It gives the user control over how >> the data is displayed, but the data in the file is in a general format. >> >> In this approach, a specific tool would always work to show the user >> consistent address formats and avoid the problems enumerated in the draft. >> For example, if a tool knew how to detect and show IPv6 addresses with >> embedded IPv4 addresses, it would show everything that way. If the tool >> didn't it would still provide the user a consistent view of the addresses. >> I think this is the overall intent of this draft. >> >> I think this would be a better approach and allow us to solve the problem >> originally as intended when the w.g. took this work on. >> >> I would appreciate your and the w.g.'s comments. >> >> Thanks, >> Bob >> >> >> >> >> >> >> >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
