Subject: Re: I-D ACTION:draft-fenner-literal-zone-02.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 05 Nov 2005 09:23:41 +0900

(Assuming [email-masked] is the right place for this document)

>>>>> On Mon, 24 Oct 2005 18:50:01 -0400, 
>>>>> [email-masked] said:

> 	Title		: Formats for IPv6 Scope Zone Identifiers in Literal Address Formats
> 	Author(s)	: B. Fenner, M. Duerst
> 	Filename	: draft-fenner-literal-zone-02.txt
> 	Pages		: 8
> 	Date		: 2005-10-24

I'm feeling this draft has suddenly make a big jump...when I discussed
the previous version(s) of this document, we faced the following set of
questions [1,2]:

  -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?
   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 "%"?

Whereas we had several opinions on questions 1, 2, or 3, questions -1
and 0 were more fundamental, which could make the discussion about 1-3
meaningless.  My understanding is that we then made a consensus about
questions -1 and 0 with the answer of "YES", and hence this version.
(Is my understanding correct?)

Now I'm surprised to see the new version provides the answer to
questions 1-3 with removing alternatives.  Have we already made a
consensus which I simply missed?

FWIW, I personally prefer option 3 [3].

[1] http://www1.ietf.org/mail-archive/web/ipv6/current/msg04605.html
[2] http://www1.ietf.org/mail-archive/web/ipv6/current/msg04605.html
[3] http://www1.ietf.org/mail-archive/web/ipv6/current/msg04632.html

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

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

---

From: Bill Fenner <[email-masked]>
Date: Fri, 4 Nov 2005 17:01:33 -0800

>My understanding is that we then made a consensus about

Yes.

>consensus which I simply missed?

The sense of the room that I got in Paris was that moving forward
with option 1 was reasonable.  I admit to having forgotten to check
on the list before proceeding with the document update.

I think that of options 2 or 3, only 2 is feasible, after updating
RFC 3986 to allow pct-encoded in IPvFuture.  My impression is that
the role of % as introducing a pct-encoded sequence is too deeply
ingrained into the URI spec (i.e., section 2.1 and 2.4 of 3986)
to be able to specify that a bare "%" is permitted to mean just "%".

Given that my impression was that the URI community would
absolutely refuse option 3 (bare %) and it would be an uphill
battle to use option 2 (pct-encoded %25) [since it would mean
updating RFC3986], I chose to try to move forward with option 1.
If the IPv6 WG cannot come to a consensus that option 1 is
"good enough", then I'm happy to let someone else try to move
forward with this document.

  Bill

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 07 Nov 2005 02:54:18 +0900

>>>>> On Fri, 4 Nov 2005 17:01:33 -0800, 
>>>>> Bill Fenner <[email-masked]> said:

> forward with this document.

I see your point, but IMO it's a compromise based on formalism that
sacrifices users.  Perhaps I'm in the minority, in which case I won't
stop this approach further.  But at least I'd like to see a clear
consensus on this.

Details are below:

In the only practical example I've seen where this proposal is useful,
that is, configuring an on-link router using link-local addresses and
web UI, the user would probably first get the router's link-local
address by some diagnostic tools, e.g.:

% ping6 ff02::1%fxp0
PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1%fxp0
16 bytes from fe80::1234%fxp0, icmp_seq=0 hlim=64 time=0.23 ms
16 bytes from fe80::abcd%fxp0, icmp_seq=0 hlim=64 time=0.78 ms (DUP!)

(Then the router's address should be fe80::abcd%fxp0).

With option 1, the user will then have to convert this to the new form
by hand and provide "http://[v1.fe80::abcd+fxp0]/" for the browser.

On the other hand, if the system supports the "default zone" and the
default zone is the only physical interface, the ping6 example might
become:

% ping6 ff02::1
PING6(56=40+8+8 bytes) fe80::1234 --> ff02::1
16 bytes from fe80::1234, icmp_seq=0 hlim=64 time=0.23 ms
16 bytes from fe80::abcd, icmp_seq=0 hlim=64 time=0.78 ms (DUP!)

And then the user can simply provide "http://[fe80::abcd]/" this time.

It would be very confusing for the user to see they can simply reuse
the output of the diagnostic tool in some cases and they need to
convert the output in some other cases.

Meanwhile, since the use of scope-zone notation must be limited within
a single node, the auxiliary notation (with v1 and +) that conforms to
the URI syntax doesn't actually help/affect interoperability.

It also doesn't help ensure compatibility with existing parsers, since
the parsers will still need to understand the special format and need
to do special processing specific to this particular format (stripping
"v1" and "+fxp0", converting "fe80::abcd+fxp0" to "fe80::abcd%fxp0"
and passing the latter to getaddrinfo(), etc) anyway.

So, for me, option 1

- sacrifices users
- doesn't help interoperability (just like other options don't)
- doesn't help existing parser implementations (just like other
  options don't)
+ but satisfies the URI community for its formality

If this is a matter of interoperability or compatibility, I agree the
formality or compliance should be highly honored.  But since this case
can actually only be informational in that the format cannot be
disclosed outside the node, I'd rather prefer satisfying users.

Again, I see the point of the opposite opinion, and I'd let it go if
that's in the majority.  But I'd like to see the consensus clearly.

					JINMEI, Tatuya

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 06 Nov 2005 19:10:53 +0100

On Mon, Nov 07, 2005 at 02:54:18AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:

[...]

> convert the output in some other cases.

I am with you here. And it might happen that implementations actually
accept the cut'n'paste friendly format #3, even if that is not what
the spec calls for.

> the URI syntax doesn't actually help/affect interoperability.

I would be careful about this. Management applications, for example,
might write URIs containing zone ids to boxes to tell them what to do
or read them just to find out what is going on. I agree that the
interpretation is only meaningful within the context of the node; the
interpretation, however, may happen very well outside the node.

What is my position on this? I am undecided. As a user, I strongly
dislike the notation #1 (and I doubt many humans will ever use it) but
at the same time I do understand why the notation #3 makes people feel
pretty unhappy.

/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, 08 Nov 2005 11:17:49 +0900

>>>>> On Mon, 07 Nov 2005 19:04:13 +0900, 
>>>>> Martin Duerst <[email-masked]> said:

> An additional idea would be to change some of the tools such as
> ping6 to accept and use '+' rather than '%'. Given the software
> counts for URI-processing software and IPv6 software, that's
> probably much easier than trying to force the non-escaping
> '%' into URI syntax (already a full standard).

IMO (admitting YMMV), URI-processing software and IPv6 software are
both so deployed that we cannot simply make "this one is not fully
deployed so fixing this side should be easier".  I indeed made a
similar argument about a year ago:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03987.html

In addition, while I might buy this argument if the proposed syntax in
draft-fenner-... could avoid forcing special processing in
URI-processing software, it actually doesn't.  The fact is that
"URI-processing software" will need modification anyway, whether we
adopt the draft-fenner-... syntax or just allow the RFC4007 format.

Meanwhile, requiring the existing tools that understand the RFC4007
'%' format to support '+' effectively means deprecating the current
description of RFC4007 and updating the RFC itself, since this is
exactly the case when the proposed format defined in RFC4007 is
expected to be used.

On the other hand, I'm not sure whether the 'special processing'
required for the URI-processing software means requiring of the URI
standard itself.  If we regard this as a user interface issue for
applications (see below), can't we regard the conversion from
"http://[fe80::abcd%fxp0]/" to "http://[fe80::abcd]/ within the
application as a "pre-processing before URI-processing", without
breaking the URI standard?  (I'm afraid this 'wording trick' is
actually not acceptable by the URI community, but I'll see
anyway...)

> There is interoperability across the network and interoperability
> among applications on the same machine.

Sorry, I'm not sure what is "interoperability across the network".
I'm also not sure if we call interaction among applications on the
same machine "interoperability" (particularly in the context of the
IETF), but I understand what you meant here.  So, in this sence, this
is a matter of how to deal with user interface incompatibility among
applications based on different standards.

> The URI community has a lot of experience with URIs leaking
> (the first experience was that URIs themselves were not
> inteded for end-user consumption).

If leaking is (part of) the concern, we'd rather modify URI-processing
software so that it can deal with the bare '%' format because many
users will still blindly copy-and-paste the %-format no matter what
the standard document says (unless, of course, we're going to require
updating RFC4007 and obsoleting the %-format itself).

So, adopting the '+'-format with the concern of leaking of the '%'
format would simply double the workload of the URI-processing
software.  I don't think that makes sense.

> Also, this is not a matter of formality, it is a matter of
> deployment. What if something like "http://[v1.fe80::abcd%fxp0]/"
> suddenly gets converted into "http://[v1.fe80::abcd<0x0F>xp0]/"
> (<0x0F> standing for a 0F byte, which is Shift In).

This would be bad, of course.  But I don't think that matter much
because "http://[v1.fe80::abcd+fxp0]/" doesn't work either with
today's URI parsers.  Whether we prefer "http://[v1.fe80::abcd+fxp0]/"
or "http://[v1.fe80::abcd%fxp0]/" or "http://[fe80::abcd%fxp0]/" (my
preference), we'll need to modify the parser.  If we use unmodified
parser, it doesn't work as expected anyway.  If we fix the preferred
format and use modified parser, either one will work as expected.  If
we use modified but misimplemented parser, it also doesn't work.  But
I don't think we are discussing buggy software.

In any event, as I repeatedly said, I believe we should primarily act
as users' point of view.

If the majority of users don't mind converting fe80::abcd%fxp0 to
v6.fe80::abcd+fxp0 by hand, we can simply go with the current
draft-fenner-... format (in which case I won't oppose to that action).

If users mind, there are several possible approaches:
  - revise RFC4007, replacing the '%'-format with '+'
  - accept the "pre-URI processing" approach as a compromise
  - if either of them is unacceptable, then we are trying to standard
    something useless and should probably discard the attempt itself.

					JINMEI, Tatuya

---

From: Martin Duerst <[email-masked]>
Date: Mon, 07 Nov 2005 19:04:13 +0900

Hello Tatsuya, others,

[cross-posting the uri mailing list]

 >stop this approach further.  But at least I'd like to see a clear

A consensus obviously should include people working on URIs, too.
I am cross-posting the uri list.

 >by hand and provide "http://[v1.fe80::abcd+fxp0]/" for the browser.

In the latest version of the draft, v1. is used. I think my
original proposal was to use v6., because we are talking about
IPv6. Roy, others, what was the original intention for the vX.
syntax? IP version, or just a sequential id?

 >And then the user can simply provide "http://[fe80::abcd]/" this time.

We could probably make "http://[v1.fe80::abcd]/" valid, too,
to make things a bit simpler.

Regards,    Martin.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 7 Nov 2005 12:58:08 -0800

> >stop this approach further.  But at least I'd like to see a clear

There is no other solution that works with existing and deployed
URI technology.  Since that is far more of a requirement than even
supporting this (highly questionable) use of link-local addresses,
the only real question is what other reserved character to use.

> syntax? IP version, or just a sequential id?

v1 should be used.  This is the second IPv6 form and there may
be others in the future -- the v has nothing to do with IPv.

> >convert the output in some other cases.

Then change the diagnostic tool to use '+' as a separator instead
of '%'.

> intended for end-user consumption).

What?  Of course they were intended for user consumption -- where
on earth did you get that idea?  There are whole sections on
transcription in the URI spec.

> (<0x0F> standing for a 0F byte, which is Shift In).

It is a matter of it not working with deployed practice because
some parsers will simply puke and die, some will correctly interpret
it as an error, some will interpret it as a %xx encoding, and some
will just pass it on to gethostbyname().  It cannot be standardized
because we are talking about 75 million deployed servers and
600+ million deployed browsers that will be on the Internet for a
long time and will not handle such an address in a predictable
manner.  If it simply failed in a predictable manner (as with
UTF-8 encoded hostnames), then we could have handled it as a
workaround.

As it is, we are better off changing the format delimiter to
something that isn't inherently incompatible with URIs.  Meanwhile,
IPv6 is fully capable of making it easier on users by adopting
the new format in all cases -- IPv6 tools that print link-local
addresses are not as widely deployed as Web browsers and servers,
are not even standard in format across different OSes, and are far
easier to update (via OS patches) in a uniform manner.

> >that's in the majority.  But I'd like to see the consensus clearly.

Consensus is good, but it cannot replace facts.  The fact of the
matter is that STD 66 will not be changed to allow the % to be
used as a delimiter because doing so would encourage people to
use identifiers that are known to cause working, deployed, and
interoperable systems on the Internet to fail.  The IETF standards
process does not allow us to make such a change for good reason.

If people want to use a link-local address in a URI, then they need
a syntax that works within the known interoperability constraints
of URI.  There is no other option that can be standardized.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Martin Duerst <[email-masked]>
Date: Tue, 08 Nov 2005 19:22:44 +0900

Hello Tatsuya,

I think Roy Fielding has expressed the URI side of this
story way more succinctly than I could ever do. I fully
agree with him. Below a few additional points.

 >adopt the draft-fenner-... syntax or just allow the RFC4007 format.

Yes. But as Roy has explained, it's the effect of this syntax
on URI-processing software that isn't updated that is the main
concern. We can't expect a user to know which software is updated
and which is not.

 >exactly the case when the proposed format defined in RFC4007 is

Well, it wouldn't be the first RFC to be updated. The URI spec
was updated several times. And if zone ids in URIs are not
an interoperability issue, then zone ids in other places
shouldn't be an interoperability issue either.

 >actually not acceptable by the URI community, but I'll see

Well, There are indeed some processing steps that happen in
that way. The best example I know is that it's possible to
put a space e.g. in a src attribute in an <img> tag, and
browsers will just convert that to %20. Similar in the
address/location bar of a browser. But that's something
that can happen on an uniform base, with any URI.

What you are asking for would be much more special, and
would require careful parsing. And it would mean that it
has to be added to *every* URI processor, otherwise the
'%' will confuse the further processing of the URI. But
adding it to every processor isn't really possible, of
course. Please note that '%' is the only character that
has a special function in every part of an URI.

If it's only about changing "http://[fe80::abcd%fxp0]/"
to "http://[fe80::abcd]/", I don't see why the user
can't do that. And how many users are there actually
who will use raw ipv6 addresses with zone identifiers
in URIs? I'm all for making it easy for users, if there's
really lots of them.

What we probably could do as a compromize would be to
keep the 'gethostbyname' interface at using '%', if that
is already strongly established (the new URI implementations
can easily convert from an '+' in an URI to a '%' in a
'gethostbyname', in particular if our draft tells them
do do that). On the other hand, visible notation would
then move to use the '+' for overall user convenience.
I haven't seen any inherent arguments against the '+'
from your side, and I haven't overlooked anything.
If this is true, then the situation is actually quite
asymetric:

RFC 4007 uses '%', but any other character would work
as well (and libraries could easily accept more than
one character, if that was necessary for backwards
compatibility). On the other hand, RFC 3986 already
uses '%' for something else, so that character is
no longer available. Many others would work, indeed
'+' is only one example, if you want another one,
that might work, too.

 >today's URI parsers.

If "doesn't work" means "maybe doesn't resolve", then yes.
This is true even for something like http://www.ietf.org.
The network is never perfect. But as Roy described, for
'%', we are looking at a much more varied, and trubling,
pattern of failure.
Same argument for various schemes: No URI resolver is
required to understand all schemes (how could it).

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 08 Nov 2005 19:03:09 +0900

Hello Roy,

 >be others in the future -- the v has nothing to do with IPv.

Thanks for this clarification. Sorry I got this wrong.

 >transcription in the URI spec.

Well, I have to admit that I got that from Tim Berners-Lee himself.
He was probably talking about the time around 1990 or even earlier,
long before there was an URI spec.

Regards,   Martin.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Nov 2005 00:40:59 +0200 (EET)

>    something useless and should probably discard the attempt itself.

FWIW, I don't think the applications and the parsers (except for 
network diagnostic etc. very, very basic tools) should need to know 
about zones.

-- 
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Nov 2005 17:58:01 +0900

>>>>> On Mon, 7 Nov 2005 12:58:08 -0800, 
>>>>> "Roy T. Fielding" <[email-masked]> said:

> Then change the diagnostic tool to use '+' as a separator instead

It would still be confusing since the user still needs to add "v1.".
But that's not my main point.

> UTF-8 encoded hostnames), then we could have handled it as a

As I repeatedly said, I don't buy this argument, since
the format described in draft-fenner-literal... also requires changes
to the 600+ million deployed browsers (BTW: this is irrelevant to the
75 million deployed servers because the extended format is not passed
to the server).  Also, as I said in a separate message, people will
blindly keep copy-and-pasting the '%' format.  So standardizing the
"v1." + "+" doesn't keep the parsers from puking or dying or producing
errors, etc.

> easier to update (via OS patches) in a uniform manner.

Again, with all due respect, I don't buy this argument.  I don't know
how many numbers of BSDs, Linux, Windows XP, and Mac OS X have
shipped, but the fact is URI-processing software and IPv6 software are
both so deployed that we cannot simply make "this one is not fully
deployed so fixing this side should be easier".  I respect the
deployed number of URI parsers and so I don't make this argument, but
I cannot accept underestimating the deployment status of the IPv6
tools understanding RFC4007.

People tend to underestimate the impact on areas they are not familiar
with, and I don't think any arguments based on this type of
underestimation solve this issue.

> of URI.  There is no other option that can be standardized.

As I said (or indicated) before, I do not necessarily think this needs
to be "standardized" in that it's published as a standard track RFC,
updating the existing URI standard.  But I admit the URI community
will never even accept that option (perhaps that's why Bill submitted
this version with the "v1" + "+" format).

Now, let me clarify my main point.  I'm not pushing the idea of making
"http://[fe80::abcd%fxp0]" acceptable for the URI parsers.  My
impression about the current proposal is this has just become a
useless format for users (if any) for the reason because the URI
community will never accept the bare % format.  I showed why I believe
this is useless (in that it's confusing for users), and my fundamental
question is whether there are really serious users with the yet
another format.  If there are, and if they don't mind the
inconvenience I showed, I won't make further objection.  But so far,
I've only seen negative responses (with an implicit exception of Bill,
who seems to be a user who can live with this format).  According to
Pekka's response, he seems to feel it's useless (or at least it
doesn't worth being standardized).  I guess you and Martin are also
dubious about the use of link-local addresses in the URI.  I'm dubious
about that, too.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Nov 2005 18:08:54 +0900

>>>>> On Tue, 08 Nov 2005 19:22:44 +0900, 

> agree with him. Below a few additional points.

Overall, his argument seems something like "this one is not fully
deployed so fixing this side should be easier; that one has already
been fully deployed and will never change".  While I respect the
deployment status of the URI standard, I simply don't think this kind
of argument solves the issue.

In summary, I showed (why I think) the proposed format is very
inconvenient for users and I'm now asking whether there are serious
(possible) users of the proposed format despite the inconvenience.  If
they are, I won't make further objection, and both the users and the
URI community will be happy.

The difficult problem will only arise when there are serious users who
want to use link-local addresses in URIs but cannot accept the
inconvenience of the proposed format.  But I don't think we've not
reached that stage.

					JINMEI, Tatuya