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

Hello Tatsuya, others,

[cross-posting the uri mailing list]

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.

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

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

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

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
inteded for end-user consumption).
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).

Regards,    Martin.

 >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
 >					Communication Platform Lab.
 >					Corporate R&D Center, Toshiba Corp.
 >					jinmei@isl.rdc.toshiba.co.jp

Received on Monday, 7 November 2005 10:22:03 UTC