W3C home > Mailing lists > Public > uri@w3.org > November 2005

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 7 Nov 2005 12:58:08 -0800
Message-Id: <2f1b97034b715561e35a2b370ec13d19@gbiv.com>
Cc: ipv6@ietf.org, uri@w3.org, Bill Fenner <fenner@research.att.com>, JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: Martin Duerst <duerst@it.aoyama.ac.jp>

On Nov 7, 2005, at 2:04 AM, Martin Duerst wrote:

> At 02:54 05/11/07, JINMEI Tatuya / 神明達哉 wrote:
> >>>>>> On Fri, 4 Nov 2005 17:01:33 -0800,
> >>>>>> Bill Fenner <fenner@research.att.com> said:
> >
> >>> 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?
> >
> >> 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.
> >
> >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.

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.

> >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.
> 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?

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.

> >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.
> We could probably make "http://[v1.fe80::abcd]/" valid, too,
> to make things a bit simpler.
> >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.

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

> 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).
> >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.
> There is interoperability across the network and interoperability
> among applications on the same machine.
> >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
> The URI community has a lot of experience with URIs leaking
> (the first experience was that URIs themselves were not
> 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.

> 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).

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

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.

> >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.

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.


Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>
Received on Monday, 7 November 2005 20:59:03 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:48 UTC