query re IPv6 URL format

[Matt Crawford]

Brian,

I brought this up quite some time ago and there was a little
discussion, in which you participated, but no "decision" as such that
I recall.  Here's my original message and a summary ...

------- Forwarded Messages

To: iesg@cnri.reston.va.us, ipng@sunroof.eng.sun.com
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: clash between PS rfc1884 and PS rfc1783
Date: Tue, 16 Jan 96 14:19:31 -0600

The text representation of IPv6 addresses specified in item 2 of
section 2.2 of RFC1884:

        For example the following addresses:

             1080:0:0:0:8:800:200C:417A  a unicast address
	     [...]
        may be represented as:

             1080::8:800:200C:417A       a unicast address

results in a possible ambiguity if such an IPv6 address appears in a
URL constructed according to RFC1738 (section 3.1):

       While the syntax for the rest of the URL may vary depending on the
       particular scheme selected, URL schemes that involve the direct use
       of an IP-based protocol to a specified host on the Internet use a
       common syntax for the scheme-specific data:

	    //<user>:<password>@<host>:<port>/<url-path>

(While RFC1738 only mentions IPv4 addresses appearing as <host>, it
will be widely presumed that IPv6 addresses may also be used.)

If the last 16-bit component of an IPv6 address used as <host> in a
URL contains only digits 0 through 9, it may look as if a port number
is present.  Conversely, if a port number is present and has no more
than four digits, it will resemble a part of the IPv6 address.



Solutions:

1. Change the textual representation of IPv6 addresses.

2. Forbid the "::" abbreviation of IPv6 addresses in URLs and other
contexts in which a port number might be appended with a colon.
(Then counting the fields will reveal whether a port number is
present.)

3. Forbid the use of literal IPv6 addresses in URLs.

4. Change the syntax of URLs.


All of these have drawbacks.  I suggest that #1 is better than #2,
and #3 and #4 are out of the question.
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab
  PGP: D5 27 83 7A 25 25 7D FB  09 3C BA 33 71 C4 DA 6A

------- Message 2

To: iesg@CNRI.Reston.VA.US, ipng@sunroof.Eng.Sun.COM
Cc: Robert Elz <kre@munnari.OZ.AU>,
    huitema@pax.inria.fr (Christian Huitema),
    Brian Carpenter CERN-CN <brian@dxcoms.cern.ch>,
    Francis Dupont	<Francis.Dupont@inria.fr>,
    Geert Jan de Groot <GeertJan.deGroot@ripe.net>,
    John Gardiner Myers <jgm+@CMU.EDU>
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: (IPng 1170) Re: clash between PS rfc1884 and PS rfc1783 
In-reply-to: Your message of Wed, 17 Jan 96 14:40:05 +0100.
             <v02120d08ad229015562c@[138.96.24.178]> 
Date: Wed, 17 Jan 96 09:46:16 -0600

I like kre's idea of writing 32 unadorned hex digits, but it only
works for email where there is some surrounding marker.  Dropped into
the URL format (or typed (ugh!) at a command line, you can't tell a
32 digits IPv6 address from a 32 character short-form hostname.

I like even more Francis' idea of writing literal IPv6 address as
names in ip6.int.  However, the times you'd want literal addresses
are exactly the times you suspect DNS may not be fully operational.
(As is the case now: ns.isi.edu. can't find ip6.int.: Server failed.)
So the magic would have to be wired into gethostbyname() or in the
resolver.  (Concoct a AAAA record on the spot in answer to a AAAA
query on a name in ip6.int.)

Does the gain justify the ugliness?

Steve's suggestion of using the URL quoting mechanism (so that
1080::8:800:200C:417A becomes 1080%3A%3A8%3A800%3A200C%3A417A)
works for URLs, but it starts us down a piecemeal-solution path.
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab
  PGP: D5 27 83 7A 25 25 7D FB  09 3C BA 33 71 C4 DA 6A

------- End of Forwarded Messages