"0. Yes, 1. Yes, 2. No, 3. No" About the character used, I was in favor of "_" before I read Brian's comment about "_" being vanishing when the URI is underlined. Considering the number of places where URIs are underlined (word underlines the URIs, web pages underline the URIs etc), I don't think using "_" will be a good idea.
Regards Mukesh > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > ext Bill Fenner > Sent: Monday, March 28, 2005 6:20 PM > To: [email protected] > Subject: Move forward with scoped literal URI format? > > > > Dear all, > > At the IETF meeting in Minneapolis, I talked about the URI > format for > scoped addresses, described in > http://www.ietf.org/internet-drafts/draft-fenner-literal-zone-01.txt > > I had 3 questions prepared, but the time didn't really allow for > asking them in a sensible way (and Dave Thaler pointed out a pre- > question). So: > > 0. Should we solve this problem at all? > > The problem is of reaching [fe80::cafe:f00d] via a URI from a > system attached to multiple links. (note that loopback counts > as a link on some implementations.) The URI literal format (RFC > 2732) didn't address this issue, so when RFC 3986 integrated this > format it didn't address it either. The current proposal is to > use the expansion literal format from RFC 3986, to allow a URI like > http://[v6.fe80::cafe:f00d_de0]/ . > > If the answer is yes, then the question of a delimiter comes up. > Percent, as the scoping architecture uses, is problematic because > percent is such a special character in URIs. > > 1. Should we proceed using "_" (or some other non-percent character)? > > "_" fits within the current RFC 3986 grammar for the > expansion of the > literal format (the grammar basically reduces to the regexp > \[v[0-9A-Fa-f]+\.[-0-9A-Za-z._~!$&'()*+,;=:]+\]) > > Note that I picked "_" after going through the ipng mailing list > archives for the discussion about the scope zone format and > judging that "_" had about the same amount of support as "%" in > that discussion. I'm not wedded to it; if we can come to > consensus on another character that is allowed by the grammar > I'll be happy. > > If so, how should this update the scoping architecture draft? > E.g., should it talk about using "_" as a seperator or just > leave that to the literal URI format? > > 2. If not, should we proceed using "%25"? > > This is a percent-encoded percent, and is the only way that > a percent may appear in a URI. However, even this is not allowed > by the current grammar, so this would require an update to the > full standard RFC 3986. > > 3. If not, should we proceed using "%"? > > A simple percent as delimiter matches with the scoping arch > spec, but is even more problematic for URIs, since percents > have always been so special in URIs. Even if we revised the > full standard RFC 3986, it's not clear that parsers would all > be properly revised (especially if the zone ID is something > like "de0" - "%de0" could be a percent-encoded 0xde followed > by a zero). > > > > My personal opinions are that we should proceed using "_" (or > some other character), or decide that it's not important > enough. It's worth solving if we can come to consensus on > a lightweight solution; if we decide that we need to update > RFC 3986 then I think the right path is to abandon the work. > (That summarizes as "0. Yes, 1. Yes, 2. No, 3. No") > > Any other input? > > Thanks, > Bill > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
