Subject: Move forward with scoped literal URI format?

From: Bill Fenner <[email-masked]>
Date: Mon, 28 Mar 2005 18:20:19 -0800

Dear all,

  At the IETF meeting in Minneapolis, I talked about the URI format for
scoped addresses, described in 
http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt

  I had 3 questions prepared, but the time didn't really allow for
asking them in a sensible way (and Dave Thaler pointed out a pre-
question).  So:

0. Should we solve this problem at all?

   The problem is of reaching [fe80::cafe:f00d] via a URI from a
   system attached to multiple links.  (note that loopback counts
   as a link on some implementations.)  The URI literal format (RFC
   2732) didn't address this issue, so when RFC 3986 integrated this
   format it didn't address it either.  The current proposal is to
   use the expansion literal format from RFC 3986, to allow a URI like
   http://[v6.fe80::cafe:f00d_de0]/ .

   If the answer is yes, then the question of a delimiter comes up.
   Percent, as the scoping architecture uses, is problematic because
   percent is such a special character in URIs.

1. Should we proceed using "_" (or some other non-percent character)?

   "_" fits within the current RFC 3986 grammar for the expansion of the
   literal format (the grammar basically reduces to the regexp
   \[v[0-9A-Fa-f]+\.[-0-9A-Za-z._~!$&'()*+,;=:]+\])

   Note that I picked "_" after going through the ipng mailing list
   archives for the discussion about the scope zone format and
   judging that "_" had about the same amount of support as "%" in
   that discussion.  I'm not wedded to it; if we can come to
   consensus on another character that is allowed by the grammar
   I'll be happy.

	If so, how should this update the scoping architecture draft?
	E.g., should it talk about using "_" as a seperator or just
	leave that to the literal URI format?

2. If not, should we proceed using "%25"?

   This is a percent-encoded percent, and is the only way that
   a percent may appear in a URI.  However, even this is not allowed
   by the current grammar, so this would require an update to the
   full standard RFC 3986.

3. If not, should we proceed using "%"?

   A simple percent as delimiter matches with the scoping arch
   spec, but is even more problematic for URIs, since percents
   have always been so special in URIs.  Even if we revised the
   full standard RFC 3986, it's not clear that parsers would all
   be properly revised (especially if the zone ID is something
   like "de0" - "%de0" could be a percent-encoded 0xde followed
   by a zero).

My personal opinions are that we should proceed using "_" (or
some other character), or decide that it's not important
enough.  It's worth solving if we can come to consensus on
a lightweight solution; if we decide that we need to update
RFC 3986 then I think the right path is to abandon the work.
(That summarizes as "0. Yes, 1. Yes, 2. No, 3. No")

Any other input?

Thanks,
  Bill

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Mar 2005 16:03:11 +0900

>>>>> On Mon, 28 Mar 2005 18:20:19 -0800, 
>>>>> Bill Fenner <[email-masked]> said:

>    percent is such a special character in URIs.

I've not yet convinced that we really need usage like
  http://[v6.fe80::cafe:f00d_de0] or http://[v6.fe80::cafe:f00d%de0]
  or ..
in a reasonable scenario.

If an SNMP example that Margaret mentioned the other day is (one of)
the intended case, could someone provide a more detailed scenario so
that we can be sure about the feasibility?  The scenario would include
network topology, the relationship between implementation components
(e.g. SNMP software), and specific examples of the usage (e.g, sample
command-line usage, data flow, etc)?

Meanwhile, regarding the point that the loopback interface can make
many nodes multi-link, RFC4007 mentions a possible solution: if the
node has only one physical network interface other than the loopback
interface, we can avoid explicitlty specifying the link by introducing
the notion of the "default link".

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2005 09:19:34 +0200

> 0. Should we solve this problem at all?

[...]
 
> 1. Should we proceed using "_" (or some other non-percent character)?

[...]
 
> 2. If not, should we proceed using "%25"?

[...]
 
> 3. If not, should we proceed using "%"?

[...]
 
> (That summarizes as "0. Yes, 1. Yes, 2. No, 3. No")

I believe the proper technical solution is option 3 because it 
allows for easy cut'n paste. This is what I would implement if
I would have to solve the problem in an ad-hoc way (assuming that
I have access to the URI parser implementation). Since option 3.
is not feasible at the moment and since I believe that the problem 
is a marginal one, my answer would be "0. No, 1. No, 2. No, 3. Yes".

(It would be nice if the IETF would have a mechanism to track change
requests so that this issue can be reconsidered whenever the URI spec 
gets revised.)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Mar 2005 16:34:19 +0900

>>>>> On Tue, 29 Mar 2005 16:03:11 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> in a reasonable scenario.

Oops...I actually meant "I've not yet *been* convinced...", of course.

					JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Mar 2005 12:13:18 +0200

> is a marginal one, my answer would be "0. No, 1. No, 2. No, 3. Yes".

Although I tend towrads No for Q1, I think we'd probably better do this,
simply so that there is no ambiguity if/when someone decides to implement.

But please don't use underscore. It literally vanishes when a user agent
decides to underline a URL.

> requests so that this issue can be reconsidered whenever the URI spec 

yes it would. the RFC Editor does log errata.

    Brian

---

From: Bill Fenner <[email-masked]>
Date: Tue, 29 Mar 2005 07:46:01 -0800

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.

  Bill

---

From: Zefram <[email-masked]>
Date: Tue, 29 Mar 2005 19:22:40 +0100

>Any other input?

I agree with your analysis: proceed using "_" or some other innocuous
character; do not do anything that requires a change to the established
URI syntax.  I specifically reject the cut&paste argument in favour
of using unencoded "%": this is a sufficiently rare situation that
convenience really doesn't matter.

On the choice of innocuous character I have no strong opinion.  "_"
seems fine.  I note that ";" would be harmonious with existing syntax
elsewhere in URIs.  Almost any punctuation character looks OK, however.
Letters "g" to "z" (either case) are the only technically possible
characters that are really bad choices.

-zefram

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Wed, 30 Mar 2005 04:08:28 +0900 (JST)

> seems fine.  I note that ";" would be harmonious with existing syntax

I disagree to use "_" here because [v6.fe80::1_de0] may be 
recognized as it were [ v6 . fe80 :: 1_de0 ] (not [ v6 . fe80::1 _ de0 ])
at a glance.

--yoshfuji

---

From: David Malone <[email-masked]>
Date: Tue, 29 Mar 2005 21:51:18 +0100

>    http://[v6.fe80::cafe:f00d_de0]/ .

Isn't using "v6." here a bit misleading? RFC 3986 seems to say that
the version flag doesn't indicate the IP version, it incidates the
version of the literal format that follows.

	David.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2005 23:05:08 +0200

On Tue, Mar 29, 2005 at 07:22:40PM +0100, Zefram wrote:

> I specifically reject the cut&paste argument in favour

Users are extremly unlikely to appreciate the fact that non-global 
IPv6 addresses look different in URIs than everywhere else. URIs 
are part of the user interface - I think we win in the long run 
by simplifying the user interface by being consistent.

If scoped addresses are such a rare thing, do not bother to solve the
problem. If it is true however that scoped addresses may show up to
reach a primary configuration as someone else said, we better make
things consistent and convenient to use. (The other option is to
standardize on "_" or something else and let the implementations
silently accept "%" as well since that makes users happy and reduces
the number of support questions. ;-)

/js

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 30 Mar 2005 11:11:44 +0900

>>>>> On Tue, 29 Mar 2005 07:46:01 -0800, 

> page, and it's probably fe80::1.

With this type of usage, we would type, e.g., 

  http://[fe80::1_de0]/

in "the URL bar" of our browser, right?

Then the browser (parser) implementation would first extract
"fe80::1_de0" and pass it to getaddrinfo(3) for converting it to an
IPv6 address.  So far, so good, but then the browser would also need
to modify the entire URL to:

  http://[fe80::1]/

before sending it to the web server on the home router, since the
"_de0" part is meaningless (or perhaps even harmful) for the remote
server.  This means the browser implementation, as well as
getaddinfo(3), should understand the detailed meaning of the extended
format for scoped IPv6 addresses.  Indeed, this is exactly one of what
we wanted to avoid in RFC4007:

   However, the typed URL is often sent on the wire, and it would cause
   confusion if an application did not strip the <zone_id> portion
   before sending.  Note that the applications should not need to care
   about which kind of addresses they're using, much less parse or strip
   out the <zone_id> portion of the address.
(Section 11.7)

So, this example is not convincing to me to answer "YES" to the 0th
question:

					JINMEI, Tatuya

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 30 Mar 2005 17:40:37 +0900 (JST)

> http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt

	square bracket does not fit the RFC3986 abnf anyways.  therefore,
	i do not think addition of "v6." or use of "_" would really help.

	i would say we should stick to current
		http://[fe80::1%fxp0]:80/index.html
	notation, and document we have to make sure we parse IPv6 portion
	(inside square bracket) first, like
		http://<blah>:80/index.html
		<blah> = fe80::1%fxp0

itojun

---

From: Bill Fenner <[email-masked]>
Date: Wed, 30 Mar 2005 06:53:12 -0800

>	i do not think addition of "v6." or use of "_" would really help.

Please look again at the IP-Literal and IPvFuture productions.

>		http://[fe80::1%fxp0]:80/index.html

This is not the current notation, neither the grammar in rfc 2732 nor rfc
3986 permits it, and rfc 3986 explicitly mentions zones as not supported.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Wed, 30 Mar 2005 06:56:15 -0800

>before sending it to the web server on the home router

This part of the URL is already parsed out before it's sent -
the GET argument in this case is just "/"; and the "Host:" header
would contain fe80::1.  Since it already had to parse it out to hand
it to getaddrinfo, I don't see the problem with reusing that parsed
result in the HTTP transaction.

  Bill

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 Mar 2005 01:57:26 +0900

>>>>> On Wed, 30 Mar 2005 06:56:15 -0800, 

> result in the HTTP transaction.

I'm not sure if we are synchronized...please let me check the
scenario.  What I wanted to say is:

1. assume we type "http://[fe80::1_de0]/" in "the URL bar" of the
   browser.
2. then the browser parser parses the entire URL and extracts
   "fe80::1_de0" and (the trailing) "/" by recognizing "[" and "]" as
   delimiters.
3. the parser passes "fe80::1_de0" to getaddrinfo(), and gets 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.
4. the parser parses "fe80::1_de0" further, and decomposes the string
   to "fe80::1" and "de0" by recognizing "_" as the delimiter.
5. when the connection is established, the browser sets "Host:" to
   "fe80::1" (extracted from "fe80::1_de0" in step 4).

Is this okay so far?  And if so, are you saying that the parsing in
step 4 is not a problem since the parser already has to parse the
input in step 2?

					JINMEI, Tatuya

---

From: Bill Fenner <[email-masked]>
Date: Wed, 30 Mar 2005 09:18:15 -0800

You're right, we were out of sync;

>   connect(2) to connect to the remote web server.

I was assuming that the parser would have to turn fe80::1_de0 into
fe80::1%de0 before passing to getaddrinfo(), so would have to parse
out the zone explicitly.

RFC 4007 says that in the general case, applications shouldn't have
to know about hacking zones off - but this is format is explicitly
for a special case.

  Bill

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 Mar 2005 03:42:37 +0900

>>>>> On Wed, 30 Mar 2005 09:18:15 -0800, 

> fe80::1%de0 before passing to getaddrinfo(), so would have to parse

Ah, okay, thanks for clarifying that.

But...

> to know about hacking zones off - but this is format is explicitly

I'm feeling I'm confused again...please let me go back to question 0
"Should we solve this problem at all?".  I said answering YES to
this question was against the general sense of RFC4007.  Regarding
this point, the above logic seems to say the delimiter conflict issue
makes it (being against the sense of RFC4007) a non-problem, but it
does not seem very logical to me.

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.  This point doesn't
change regardless of how much the application needs to work to deal
with scopes (i.e., whether it only needs to split the address part or
it also first needs to convert _ to %).  In fact, if we can now allow
this as a special case, I cannot understand why people were so
enthusiastic about killing site-local addresses -in my understanding,
one major reason was they did not want to force applications to know
details about scopes and/or zones for behaving correctly.

What we should provide regarding question 0 is, IMO, a convincing
reason why we dare to be against the general sense of RFC4007 without
relying on the fact that converting _ to % would make the application
more complex.

BTW, if we can really agree on being against the sense of RFC4007 for
the particular usage of URI/URL, option 3 in
draft-fenner-literal-zone-01 (just use "%") rather seems to be the
most appropriate resolution.  Aside from the point of "syntax police",
the difficult issue of this option in practice is that we cannot be
sure if we can enforce the special case (against the URI/URL syntax)
to URI/URL parsers (or implementors).  But since we'd now be going to
enforce a special exceptional rule (i.e., enforcing to extract the
"pure address" from the "address+scope zone"), wouldn't it also be
feasible to force the parser to regard '%' in "[...]" as an exception
to RFC3987?

(Note: my primary position is still I'm not convinced of the answer to
question 0.  The last paragraph is only meaningful if we can agree
that the answer is YES.)

					JINMEI, Tatuya

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Mar 2005 17:59:15 +0200

> 3986 permits it, and rfc 3986 explicitly mentions zones as not supported.

I see the formal problem with what the current RFCs say. Still, I believe
the format quoted above is the only one that makes sense to users who
have to type these URLs and who already know how to put global IPv6
addresses into URLs. I prefer to optimize end user usability, even if 
it makes the procedural aspects getting it written down within the IETF 
more complex.

/js

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 31 Mar 2005 12:07:19 +0900 (JST)

> 3986 permits it, and rfc 3986 explicitly mentions zones as not supported.

	thanks for correcting my misunderstandings.  

itojun