Hello,
(don't mind if any copies of this message arrive; I'm trying to wrestle
Gmane into sending to this list)
<[email protected]> писал в своём письме Tue, 10 Nov 2009 07:30:01
+0300:
Title : A Recommendation for IPv6 Address Text Representation
Author(s) : S. Kawamura, M. Kawashima
Filename : draft-ietf-6man-text-addr-representation-02.txt
Pages : 14
Date : 2009-11-09
Reading this the second time, I'm not sure I'm satisfied with how Section
5 turned out to be. In particular, this:
However, there may be
situations where hexadecimal representation is chosen to meet certain
needs. Addressing those needs is out of the scope of this document.
It's rather vague, and I think the recently added Section 3.2.5 offers an
example that's close having such needs. If for some reason a textual
comparison of addresses is done in the course of a protocol (don't know
how likely it is, but can certainly happen), a strictly canonical format
is required, and Section 5 currently gives some leeway in this matter
(since different systems may have different knowledge about existing
address types). Perhaps, especially since this is a standards track
document now, such a strict format should be specified, to save protocol
developers the trouble of doing it themselves.
I think that for such a "really canonical" representation, we can just
forbid using the mixed notation. The reasons for this are that it's the
simplest definition, the easiest to implement and doesn't single out any
particular transition technologies. An alternative would be to mandate
mixed notation for IPv4-mapped and IPv4-compatible addresses and
hexadecimal representation for everything else, for compatibility with
current implementations of inet_ntop. However, I don't think that such
compatibility matters much, because there are no consistency requirements
for inet_ntop and to ensure canonicity developers will be required to
implement their own functions, anyway.
Another difference, however nominal, is that for such a strict
representation, the recommendations in Section 7 will become requirements.
More comments:
In
cases where there is a choice of whether to express the address as
fully hexadecimal or hexadecimal and decimal mixed,
I think this can be safely removed. I maintain that the decription in RFC
4291 allows to use the mixed notation for any addresses, making this
fragment a tautology.
Plus, the next fragment makes it redundant in any case:
if the
address type can be distinguished as having IPv4 addresses embedded
in the lower 32 bits solely from the 128bits of the address field
itself
While I'm at it, typo patrol: there's a space missing between "128" and
"bits", and it should probably say just "address", not "address field".
Finally, I suggest to place an example of mixed notation in Section 1, so
that it fully covers the address syntax.
Regards,
Roman.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
