Subject: Re: Move forward with scoped literal URI format?

From: Bill Fenner <[email-masked]>
Date: Sun, 3 Apr 2005 11:17:17 -0800

>The essential point is, at least to me, is that we did not want to
>force applications (like URI/URL parsers) to be aware of scope zones
>and/or the dedicated syntax for scoped addresses.

My reading was that we don't want applications to have to examine an
arbitrary address and decide whether or not they have to deal with
it specially.  Since this format is unique and is only used for scoped
addresses, the application doesn't have to decide based on the address -
it's already been told based on the URI format.

>-in my understanding, one major reason [that people were enthusiastic
>about killing site-local] was they did not want to force applications
>to know details about scopes and/or zones for behaving correctly.

This was at least partly about having to derive the information from
the address; I think that communicating the fact that a zone is
present seperately from the address at least partly alleviates these
concerns.

  Bill

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bill Fenner <[email-masked]>
Date: Sun, 3 Apr 2005 19:40:36 -0800

>>>>>> On Sun, 3 Apr 2005 11:17:17 -0800, 
>>>>>> Bill Fenner <[email-masked]> said:
>> Since this format is unique and is only used for scoped
>I guess I don't understand the latter sentence...
>
>- what is "this format"? (perhaps it's "fe80::1(some delimiter)de0"
>  for URI)

It's [v6.fe800:1(some delimiter)de0].

>- what do you mean by unique?

I mean the [v6. ... ] part is different from any other URI format.

>- what do you mean by "it's already been told based on the URI format"?

I mean that the application knows based on the fact that the
URI that it's parsing has [v6. (something) ] - it knows that
the (something) is an address with a scope zone.

>I also seem to fail to understand this sentence...what do you mean by
>"the fact that a zone is present separately from the address"?

It's the communication that is separate from the address; the same
point as above.

  Bill

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Apr 2005 11:36:00 +0900

JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 04 Apr 2005 16:33:00 +0900

>>>>> On Sun, 3 Apr 2005 19:40:36 -0800, 

> It's [v6.fe800:1(some delimiter)de0].

Ah, I see.  Then I've been misunderstanding the point from the
beginning, sorry about that.

Let me confirm my understanding once again...

(assuming "some delimiter" is "_" for simplicity)

- for IPv6 addresses without scope zones, we'll type
  http://[2001:db8::1234]/
  as specified in RFC3986.

- for IPv6 addresses with scope zones, we'd type
  http://[v6.fe80::1234_de0]/

  ("v6." is attached deliberately to indicate it's an IPv6 "scoped"
   address with zone, not an ordinary IPv6 address.  RFC3986 prohibits
   the use of "v6." (or any other "vX.") before an IPv6 literal
   address, but it doesn't matter since "fe80::1234_de0" is not a
   standard IPv6 literal address.)

And, going back to the concrete example I showed:

1. assume we type "http://[v6.fe80::1_de0]/" in "the URL bar" of the
   browser.
2. then the browser parser parses the entire URL and extracts
   "v6.fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]"
   as delimiters.
3. the parser then recognizes it is a representation of an IPv6 scoped
   address with a zone ID from the "v6." part, and extracts
   "fe80::1_de0".
4. the parser replaces "_" in "fe80::1_de0" with "%", and passes the
   result (fe80::1%de0) to getaddrinfo(), getting a sockaddr_in6
   structure (whose sin6_addr member is "fe80::1" and sin6_scope_id
   member is the link ID corresponding to interface "de0").  The
   browser uses the sockaddr_in6 structure with connect(2) to connect
   to the remote web server.
5. the parser also extracts "fe80::1" from "fe80::1_de0" in parallel
   with step 4, and sets "Host:" to it when sending an HTML request to
   the server.

The rationale behind the proposal is that the extra work for the
application in step 3 should justify the other extra work in step 5
(and step 4).

Is my understanding now correct?

					JINMEI, Tatuya

---

From: Perry Lorier <[email-masked]>
Date: Mon, 04 Apr 2005 23:47:55 +1200

Bill Fenner wrote:
> I usually think of the small home router configuration problem -
> buy a box, plug it in, it wants you to configure it using a web
> page, and it's probably fe80::1.  I don't have any systems in my
> house that have fewer than two non-loopback interfaces.  Since
> this is presumably a one-off, I guess the default interface
> configuration is an option, if a little clumsy.

I don't understand this use case.  Assuming I have a router and it's
manual says type in http://<some-link-local-address><some-delimiter>de0/
it's going to fail on my Linux machine that uses eth0, and if it says
use "eth0" it's going to fail on the other Linux machine that has eth1
on that network.  Link local addresses (that include an interface
identifier) don't make sense outside of the local machine, including in
printed documentation.

I don't think that URI's that don't make sense off a single machine are
a good idea in general, but assuming that we do want this, are we
expecting users to transcribe these addresses?  how about just using
(fe80::1,de0) as http://de0.1.0.0.0.0.0.0.0.fe80.fin6.arpa/ no special
delimiters are needed, and it "looks" like a normal IP, normal software
doesn't need to be upgraded to handle this format, libraries can be
easily upgraded to support this format easily and shortcut the round
trip to a DNS server, the fin6.arpa (forward in6) tree can be
automatically populated with AAAA's on the fly for software that doesn't
work, it can be easily cut and pasted between url's and applications
that expect a "hostname".  the only downside I see is that it's a pain
to take an address (not a hostname) and make a hostname out of it (as
you have to reverse it).

---

From: Bill Fenner <[email-masked]>
Date: Mon, 4 Apr 2005 07:37:45 -0800

On Mon, 04 Apr 2005 16:33:00 +0900,
>Is my understanding now correct?

Yes, that looks right.  And even if getaddrinfo took whatever
form directly (either the separator is '%' or getaddrinfo is
modified to accept the URI character as well), I think it's
reasonable to expect step 5 to occur even if step 4 doesn't
have to.

  Bill

---

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Apr 2005 18:00:03 +0300 (EEST)

> 1. assume we type "http://[v6.fe80::1_de0]/" in "the URL bar" of the

I doubt hardly any parsers accept this "v6." notation, and I'd rather 
they even wouldn't.

Best just to forget about the whole thing? :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Apr 2005 21:46:26 -0400

> identifier) don't make sense outside of the local machine, including in

Right. It's important to remember that zone ids are a local name space
-- one doesn't know what the zone names are on someone else's machine
or at a different site. Thus, anyone shipping a product that says
"configure me by typing in the following address into your browser"
can't include a zone id.

A very sophisticated user might know about scopes and be able to add
an appropriate zone id in some cases, but for the general user, this
is well beyond what can be reasonably expected.

So I don't see how literals with zone ids play a useful part of
simplifying config, as in the home router config case.

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 22 Apr 2005 00:02:26 +0900

(Just coming back to normal work from a vacation, sorry for the
delayed response)

>>>>> On Mon, 4 Apr 2005 07:37:45 -0800, 

> reasonable to expect step 5 to occur even if step 4 doesn't

I'll be surprised if others, particularly those who were eager for the
deprecation of site-local addresses, are convinced with this
explanation, I'm fine with continuing the discussion if they are.

So, I guess the appropriate next step for this work is to make
consensus on this, which mostly equals to my question -1:

  -1. are we okay with forcing URL/URI parsers to understand the
      detailed semantics of the scoped address syntax and to strip the
      zone ID (+ delimiter) part by itself for the reason because the
      parsers would already need to do some extra work for the special
      syntax?
(slightly modified based on the discussion so far)

					JINMEI, Tatuya