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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Martin J. Dürst

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 <[hidden email]> 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.
 > [hidden email]


Reply | Threaded
Open this post in threaded view
|

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

Roy T. Fielding

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 <[hidden email]> 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
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.

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


Cheers,

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


Reply | Threaded
Open this post in threaded view
|

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

Martin J. Dürst

Hello Roy,

At 05:58 05/11/08, Roy T. Fielding wrote:
 >On Nov 7, 2005, at 2:04 AM, Martin Duerst wrote:

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

Thanks for this clarification. Sorry I got this wrong.


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

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.


Reply | Threaded
Open this post in threaded view
|

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

Martin J. Dürst
In reply to this post by Martin J. Dürst

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.

At 11:17 05/11/08, JINMEI Tatuya / 神明達哉 wrote:
 >>>>>> On Mon, 07 Nov 2005 19:04:13 +0900,
 >>>>>> Martin Duerst <[hidden email]> said:
 >
 >>> 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).
 >
 >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.

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.

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

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.

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

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.

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

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.