Bob,
On 2010-02-06 09:47, Bob Hinden wrote:
...
> 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.
But this would mean losing the ability for a human to write
an address in the most appropriate way (which may or may not
show a dotted decimal suffix) and then store it in that format
for future use by both humans and software. And it would mean
that tools with misconceptions about valid WKPs would work
differently. That would break the Law of Least Astonishment.
> 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 thought we started this effort to help operators by reducing
confusion. Discarding dotted deimal when entered by a human will
not do that, IMHO.
There's no doubt that internal searches and comparisons should
be done against the canonical representation, of course. But I
believe that dotted decimal MUST NOT be discarded by tools
if entered by a human.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
