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 > > > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
