Subject: Re: Last Call: Preferred Format for Literal IPv6 Addresses in URL's to Proposed Standard

From: John Stracke <[email-masked]>
Date: Tue, 14 Sep 1999 13:35:51 -0400

> The IESG has received a request from the IPNG Working Group to
> consider
> Preferred Format for Literal IPv6 Addresses in URL's
> <draft-ietf-ipngwg-url-literal-02.txt> as a Proposed Standard.

I believe that this format is ill-advised for two reasons.

First, it is insufficiently backwards compatible with existing
HTTP clients.  If a syntax were used that was compatible with the
existing http: syntax, then an existing client, even on an
IPv4-only machine, could pass the URL to an IPv6-enabled proxy to
contact an IPv6 server.  (For an example of such a syntax, see
draft-masinter-url-ipv6-02.txt, which suggests a pseudo-TLD
.ipv6, with rules for converting, say,
1080--8-800-200C-417A.ipv6, into 1080::8:800:200C:417A.) With
this format, however, an existing client may see the multiple
colons and decide that the URL is simply broken, and not worth
passing to the proxy.  (I previously brought this point up with
the authors of this draft; if I recall correctly, they were
simply not interested in older clients.)

Second, it uses the "[" and "]" characters, which are not legal
in URIs (see RFC-2396, Appendix A).  Section 2.4.3 of RFC-2396
lists these characters among those which were excluded because
they were "unwise"; that is, they were considered likely to be
used as delimiters in various contexts, and/or known to be
transformed by some gateways.

I hope that this format will be rejected in favor of
draft-masinter-url-ipv6-02.txt (or something like it).

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |No matter how tempting the prospect of unlimited|
[email-masked]|power, I will not consume any energy field      |
|                |bigger than my head.                            |
\=================================================================/

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Sep 1999 04:06:08 +1000

Date:        Tue, 14 Sep 1999 13:35:51 -0400
    From:        John Stracke <[email-masked]>
    Message-ID:  <[email-masked]>

  | I hope that this format will be rejected in favor of
  | draft-masinter-url-ipv6-02.txt (or something like it).

While I am no great lover of the current proposed draft (it makes using
IPv6 address literals way too easy), pseudo-TLDs are a MUCH worse alternative.

IPv6 address literals should essentially never appear in a URL (much
less a URI, so having them forbidden there seems like a boon indeed).
The only rational purpose for allowing the things at all is so that it
is possible to configure the necessary infrastructure to make name
translation work (given that we seem to be more and more stuck with web
based configuration these days).   Anything at all that we can do to
make it futile to attempt to pass around URLs containing embedded IPv6
addresses must be considered a win.    One way to achieve that is by
making them unusable in any but specially configured browsers.

The proposed draft is OK as it stands, and the best we're likely to get.

I'd have preferred something like simply writing the 128 bit IPv6 address
as a large decimal constant (no punctuation at all).   Browsers that know
such things would detect that it was an IPv6 literal because its value
would be bigger than 2^32 (only IPv4 addresses live in the IPv6 space with
smaller values than that).   Gross, ugly, and almost totally unusable (except
when there is truly no other way) - everything that ought to be a goal of
this specification.   Unfortunately, for some people this is a little too
unuseable (succeeds too well).

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Sep 1999 04:06:08 +1000

kre

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Sep 1999 14:12:52 -0400

Robert Elz wrote:

> IPv6 address literals should essentially never appear in a URL

Hum.  Could you elaborate, please? I don't see the problem; and I do know that
there are cases where, for whatever reason, a slightly broken Web server can't
figure out its own name, and so starts generating URLs containing its IPv4
address.  It's ugly, but it's a usable fallback.

Setting that aside, I'm still concerned about the "[" and "]", though (illegal in
URIs); can they be changed to something else?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Belief is not relevant to truth.             |
[email-masked]|                                             |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Sep 1999 14:12:52 -0400

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Sep 1999 06:20:38 +1000

Date:        Tue, 14 Sep 1999 14:12:52 -0400
    From:        John Stracke <[email-masked]>
    Message-ID:  <[email-masked]>

  | Hum.  Could you elaborate, please?

One of the aims of IPv6 is supposed to be that sites can be renumbered
relatively easily.   That means that addresses for it appear nowhere
but the places they're expected to appear and can be allowed for
(DNS configurations, DHCP configurations, etc).   As soon as addresses
start appearing in URLs, something, somewhere, will record them.
That will apply whether the address was entered manually, or generated
by a server for what it thought would be just a short term use of
the URL (fill in this form and return it here, or whatever).

Servers that can't figure out their own names (and actually need
to know them for some reason) ought just refuse to operate, so that
the problem that caused the problem can be fixed, rather than being
worked around, leaving remnants that are hard to deal with later.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Sep 1999 06:20:38 +1000

kre

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Sep 1999 16:23:12 -0400

Robert Elz wrote:

> relatively easily.

Ah, right.  OK, then; I withdraw my first objection.  The brackets are
still a problem, though (not one I care deeply about, but maybe someone
who worked on 2396 will :-).

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |No matter how subtle the wizard, a knife in the|
[email-masked]|shoulderblades will cramp his style.           |
\================================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Sep 1999 16:23:12 -0400

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Sep 1999 16:52:03 -0500

As a co-author of *both* proposals, I strongly prefer the
current one with [] delimiters. IMHO the fact that those
delimiters are not used in current URLs is a benefit, since we 
are sure that when URL parsers are upgraded to support them,
no old URLs will be accidentally broken.

IPv6 literals are certainly only needed for emergency use,
e.g. to access Web-based management systems during DNS outages.
But in that situation, cut-and-paste of the standard IPv6 address
format is a practical requirement.

  Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Sep 1999 16:52:03 -0500

Brian Carpenter

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 14 Sep 1999 21:34:15 PDT

> who worked on 2396 will :-).

I worked on RFC 2396. The brackets [] inside URLs are not so much
a problem for the URL handling software itself (the browser "Address"
box) but rather for more specialized applications, such as software that
heuristically picks out URLs from text/plain email messages and turns
them into hyperlinks, or humans trying to read a URL in a magazine
article and type it in.

I don't have a serious problem with the URL literal syntax proposed in 

   draft-ietf-ipngwg-url-literal-02.txt

even though it isn't legal in RFC 2396. It should explicitly
'update' RFC 2396, though, rather than leave the updating implicit.

I think that the syntax in 

    draft-masinter-url-ipv6-02.txt

would cause fewer problems for URL processing software, although
it would be less problematic if the ".ipv6" pseudo-domain were
consistently implemented anywhere host names were allowed, and not
just in URLs.

The converse of "Every problem in computer science can be solved
by adding a level of indirection" is that "Every level of indirection
needs a way around." This is the case for the hostname -> address
indirection; it's very useful to have a standard form of 'hostname'
which stands for an address. But if there's consensus that it's
better to do this with "[]" brackets, so be it.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 14 Sep 1999 21:34:15 PDT

Larry

---

From: John Stracke <[email-masked]>
Date: Wed, 15 Sep 1999 09:22:32 -0400

Larry Masinter wrote:

> I worked on RFC 2396.
> [...]

OK, I'll be quiet now.  :-)

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"But she calls her ship _Mercy of the Goddess_!"|
[email-masked]|"Kali." "Oh."                                   |
\=================================================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 15 Sep 1999 09:22:32 -0400