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 <[EMAIL PROTECTED]> 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.
> [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
