[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 address text representation
Andrew,
Andrew Main wrote:
>
> The update of the URI syntax RFC, draft-fielding-uri-rfc2396bis,
> gives a precise ABNF syntax for IPv6 address textual format, on which
> Roy Fielding and I collaborated. This really ought to be in the IPv6
> Addressing Architecture document -- RFC2373 had a faulty attempt at an
> ABNF grammar -- but the URI work came too late to get the grammar into the
> Addressing Architecture update that was being worked on at the time, now
> published as RFC3513. Bob Hinden suggested that the IP address textual
> representation work could be published as a standalone document instead.
>
> I've submitted a draft of this standalone document; it's
> draft-main-ipaddr-text-rep-00. In working out the syntax details with
> Roy, I ended up with a lot of historical material and rationale, which
> I think makes such a narrow-topic document worthwhile.
Agreed. I'm glad someone finally got the ABNF right.
In your history, I think you might mention the <dotnum> BNF
in [MTP] which was inherited by RFC 821.
Embarassingly, I can add to the history by admitting that the faulty
ABNF in [IPV6-AA-2] was mine (see the message appended below).
A few other comments on the draft.
Should it be Informational? Wouldn't it be better to have it available
as a normative reference?
I suggest adding after the first paragraph of the Introduction something
like:
It is generally considered undesirable for numeric IP addresses to
be stored anywhere but in the DNS system, to avoid operational problems
when hosts or networks are renumbered for any reason [RFC 1900].
However, this does not remove the need to represent addresses textually
in documents, user interfaces, configuration files, and some protocols.
> 4.3 Delimitation
...
> In contexts where an IP address needs to be distinguished from
> similar-looking data that can appear in the same place, there is
> precedent (from email addresses and URLs) for enclosing an IP address
> in brackets ("[]") as a distinguisher.
You could usefully refer here to RFC 821, RFC 2732, and [URI].
Brian
---------
Date: Mon, 27 Oct 1997 13:56:49 GMT
Message-Id: <9710271356.AA35978@hursley.ibm.com>
From: "(Brian E Carpenter)" <brian@hursley.ibm.com>
Subject: (IPng 4705) draft-ietf-ipngwg-addr-arch-v2-03.txt
To: ipng@sunroof.eng.sun.com
Reply-To: brian@hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@eng.sun.com
Precedence: bulk
Just some minor points on draft-ietf-ipngwg-addr-arch-v2-03.txt
1. Given the difficulty we have in persuading the URL and SMTP
folks to do the right thing with the textual representation,
I suggest including a BNF syntax version as an annex.
A rough cut is annexed to this email.
2. I know why we say
> o An anycast address must not be assigned to an IPv6 host, that
> is, it may be assigned to an IPv6 router only.
but is this really going to be tenable? It certainly isn't
enforceable.
3. For the record: I know I lost this one, but I still
think it is wrong to invert the universal/local bit in EUI-64.
Brian Carpenter
In the variant of BNF used for URL syntax:
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*hex
hex = digit | "A" | "a" | "B" <etc>
digit = "1" | "2" | "3" <etc>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------