RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt
Dave Thaler <dthaler@microsoft.com> Mon, 09 July 2012 18:54 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0212611E80F3 for <ipv6@ietfa.amsl.com>; Mon, 9 Jul 2012 11:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.211
X-Spam-Level:
X-Spam-Status: No, score=-105.211 tagged_above=-999 required=5 tests=[AWL=1.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZArhgrruTVU for <ipv6@ietfa.amsl.com>; Mon, 9 Jul 2012 11:54:55 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id A8DFE11E80E2 for <ipv6@ietf.org>; Mon, 9 Jul 2012 11:54:55 -0700 (PDT)
Received: from mail136-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Jul 2012 18:53:03 +0000
Received: from mail136-tx2 (localhost [127.0.0.1]) by mail136-tx2-R.bigfish.com (Postfix) with ESMTP id 7F05C6014D; Mon, 9 Jul 2012 18:53:03 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -39
X-BigFish: VS-39(zz98dI9371Ic89bh936eI1b0bM542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h93fhd25hf0ah107ah)
Received-SPF: pass (mail136-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail136-tx2 (localhost.localdomain [127.0.0.1]) by mail136-tx2 (MessageSwitch) id 134185996679579_3630; Mon, 9 Jul 2012 18:52:46 +0000 (UTC)
Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.235]) by mail136-tx2.bigfish.com (Postfix) with ESMTP id 066532029D; Mon, 9 Jul 2012 18:52:46 +0000 (UTC)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Jul 2012 18:52:45 +0000
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 9 Jul 2012 18:54:53 +0000
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 9 Jul 2012 11:54:52 -0700
Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.191]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Mon, 9 Jul 2012 11:54:52 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: Dave Thaler <dthaler@microsoft.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Bob Hinden <bob.hinden@gmail.com>
Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt
Thread-Topic: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt
Thread-Index: AQHNSV6WE3ShC1aRY0CMvMGykLyPMZcbk/DggAE9goCAABCNgIAAMTuA//+TqrCABM4kMA==
Date: Mon, 09 Jul 2012 18:54:51 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6A4C51@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com> <F9D7BDB7-D90F-4FCB-A31F-6BD9F359641D@gmail.com> <4FF718C7.5060206@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B690A00@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-uri-zoneid@tools.ietf.org" <draft-ietf-6man-uri-zoneid@tools.ietf.org>, "ipv6@ietf.org Mailing List" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 18:54:57 -0000
One additional gap that I think SHOULD be addressed. RFC 3986 says: URIs have a global scope and are interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user's context. For example, "http://localhost/" has the same interpretation for every user of that reference, even though the network interface corresponding to "localhost" may be different for each end-user: interpretation is independent of access. However, an action made on the basis of that reference will take place in relation to the end-user's context, which implies that an action intended to refer to a globally unique thing must use a URI that distinguishes that resource from all other things. URIs that identify in relation to the end-user's local context should only be used when the context itself is a defining aspect of the resource, such as when an on-line help manual refers to a file on the end- user's file system (e.g., "file:///etc/hosts"). It should be pointed out in the zoneid document that adding a zone id changes the scope to be localhost rather than the scope of the address. So "http://[fe80::1]/blah" is valid anywhere on the same link. But "http://[fe80::1-id]/blah" is valid only within the same host. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Friday, July 6, 2012 10:33 AM > To: Brian E Carpenter; Bob Hinden > Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- > zoneid@tools.ietf.org; ipv6@ietf.org Mailing List > Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt > > It's documented on the page in my original email. > > However it's not sufficient. Remember my second piece of feedback was > that the document contradicts itself, implying the specified syntax supports > cut and paste, but then doesn't provide a section updating RFC 4007 section > 11. > > If the document both mentions that alternative 3 is used by many things > today (IE, Windows, applications) within APIs that take URI-like strings, and > also adds a section updating RFC 4007 section 11, then I'd be happy with it. > > -Dave > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > Sent: Friday, July 06, 2012 9:57 AM > > To: Bob Hinden > > Cc: Dave Thaler; 6man-chairs@tools.ietf.org Chairs; > > draft-ietf-6man-uri- zoneid@tools.ietf.org; ipv6@ietf.org Mailing List > > Subject: Re: 6MAN WG [second] Last Call: > > draft-ietf-6man-uri-zoneid-01.txt > > > > I'd be happy with that, or a small appendix. Dave, is it documented > anywhere? > > > > Regards > > Brian > > > > On 2012-07-06 15:00, Bob Hinden wrote: > > > With my co-author hat on, would it help to include a description of > > > what IE > > supports in Section 3. Web Browsers? > > > > > > Bob > > > > > > > > > On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: > > > > > >> Dave, > > >> > > >> 1) FYI, the deadline we gave the URI list to comment on this has > > >> just passed, with only one (positive) reply. > > >> > > >> 2) It's for the WG Chairs to say if they want another version in > > >> view of your comments. > > >> > > >> 3) I don't see how the % format is currently legal. There's no > > >> provision for any characters after the IPv6 address, whether > > >> percent-encoded or not. We heard of browsers that previously > > >> allowed full RFC 4007 syntax (% *not* treated as an escape) but > > >> this is the first I've heard of IE allowing a zone index at all. > > >> > > >> Regards > > >> Brian > > >> > > >> On 2012-07-06 02:28, Dave Thaler wrote: > > >>> I know it's after the designated end of WGLC, but here's my > feedback... > > >>> > > >>> The document appears to call out existing practice in several > > >>> places, such as > > in section 1: > > >>>> Some versions of some browsers accept the RFC 4007 syntax for > > >>>> scoped > > >>>> IPv6 addresses embedded in URIs, i.e., they have been coded to > > >>>> interpret the "%" sign according to RFC 4007 instead of RFC 3986. > > >>> and in Appendix A point 1: > > >>>> Advantage: works today. > > >>> However, it's missing discussion of other alternatives already in > > >>> common > > practice. > > >>> For example alternative 3 (escaping the escape character as > > >>> allowed by RFC > > 3986) has: > > >>>> Advantage: allows use of browser. > > >>>> > > >>>> Disadvantage: ugly and confusing, doesn't allow simple cut and > > >>>> paste. > > >>> The disadvantage is certainly true. However the main advantage > > >>> are notably lacking, which is that it's already in common practice > > >>> in many places (to the extent that using a zone id at all is > > >>> common practice > > anyway). > > >>> > > >>> You'll see at > > >>> http://msdn.microsoft.com/en- > us/library/windows/desktop/aa385325(v > > >>> =v s.85).aspx that alternative 3 is what is supported in IE7 and > > >>> above, and the APIs are generally available to Windows > > >>> applications (i.e. > > >>> not just IE7). > > >>> > > >>> The document does not state whether the existing legal use is > > >>> suddenly declared to be illegal, or just another legal way of > > >>> doing the same > > thing. > > >>> > > >>> If you're telling existing applications and OS's that use alternative 3 that > they > > >>> have to change, that doesn't sound like a good thing. That's because > many > > apps > > >>> want to be OS-version-independent and use URI parsing libraries > > >>> provided > > by > > >>> the OS. We don't want apps to code their own URI parsing (it's very > easy to > > >>> get wrong, especially when you add various internationalization > issues). > > >>> As a result, apps will tend to code to the lowest common denominator > of > > >>> OS's they want to work on. That means I expect to see apps coding to > > >>> alternative 3 for the foreseeable future. When they don't use them in > > >>> edit boxes, the disadvantage of not being able to cut and paste is > > >>> not a real disadvantage. > > >>> > > >>> Personally I don't have an issue with allowing both formats if the > > >>> WG feels strongly that a cut-and-paste-friendly format is needed > > >>> in addition to what's existing practice, though having two does > > >>> affect the rules for comparison (see > > >>> draft-iab-identifier-comparison section 3.1.2) but not noticeably. > > >>> > > >>> Finally, the stated disadvantage of alternative 3 is only a disadvantage > if the > > >>> specified scheme in section 2 *does* allow cut-and-paste. For that to > > >>> happen, it means the zone id separator has to work outside the > context of > > >>> URIs. That is, section 2 says: > > >>>> Thus, the scoped address fe80::a%en1 would appear in a URI as > > >>>> http://[fe80::a-en1]. > > >>> To support cut-and-paste, that means that "ping fe80::a-en1" > > >>> needs to work. But this document is titled > > >>> " Representing IPv6 Zone Identifiers in Uniform Resource Identifiers" > > >>> and similarly the abstract limits its scope to URIs. > > >>> > > >>> Hence section 2 is in contradiction with the analysis of alternative 3. > > >>> The document already says it "updates 4007" so it seems that > > >>> what's lacking is a section specifically updating RFC 4007 section > > >>> 11 which would declare that both '%' and '-' are acceptable > > >>> separators in the textual representation. > > >>> > > >>> -Dave > > >>> > > >>>> -----Original Message----- > > >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > >>>> Behalf Of Ole Trøan > > >>>> Sent: Wednesday, June 13, 2012 5:18 AM > > >>>> To: ipv6@ietf.org Mailing List > > >>>> Cc: 6man-chairs@tools.ietf.org Chairs; draft-ietf-6man-uri- > > >>>> zoneid@tools.ietf.org > > >>>> Subject: 6MAN WG [second] Last Call: > > >>>> draft-ietf-6man-uri-zoneid-01.txt > > >>>> > > >>>> All, > > >>>> > > >>>> This message starts a one-week 6MAN Working Group Last Call on > > advancing: > > >>>> Title : Representing IPv6 Zone Identifiers in Uniform > > >>>> Resource Identifiers > > >>>> Author(s) : Brian Carpenter > > >>>> Robert M. Hinden > > >>>> Filename : draft-ietf-6man-uri-zoneid-01.txt > > >>>> Pages : 9 > > >>>> Date : 2012-05-29 > > >>>> > > >>>> > > >>>> as a Proposed Standard. Substantive comments should be directed > > >>>> to the mailing list or the co-chairs. Editorial suggestions can > > >>>> be sent to the > > authors. > > >>>> This last call will end on June 20, 2012. > > >>>> Regards, > > >>>> Bob, & Ole > > >>>> ----------------------------------------------------------------- > > >>>> -- > > >>>> - IETF IPv6 working group mailing list ipv6@ietf.org > > >>>> Administrative > > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > >>>> ----------------------------------------------------------------- > > >>>> -- > > >>>> - > > >>> > > >>> ------------------------------------------------------------------ > > >>> -- IETF IPv6 working group mailing list ipv6@ietf.org > > >>> Administrative > > >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > >>> ------------------------------------------------------------------ > > >>> -- > > >>> > > >> ------------------------------------------------------------------- > > >> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > >> ------------------------------------------------------------------- > > >> - > > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- 6MAN WG [second] Last Call: draft-ietf-6man-uri-z… Ole Trøan
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Randy Bush
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Rajiv Asati (rajiva)
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Dave Hart
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Rémi Després
- RE: 6MAN WG [second] Last Call: draft-ietf-6man-u… Dave Thaler
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Brian E Carpenter
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Bob Hinden
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Brian E Carpenter
- RE: 6MAN WG [second] Last Call: draft-ietf-6man-u… Dave Thaler
- RE: 6MAN WG [second] Last Call: draft-ietf-6man-u… Dave Thaler
- RE: 6MAN WG [second] Last Call: draft-ietf-6man-u… Dave Thaler
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Brian E Carpenter
- Re: Candidate draft-ietf-6man-uri-zoneid-02 Brian E Carpenter
- Candidate draft-ietf-6man-uri-zoneid-02 Brian E Carpenter
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… t.petch
- Re: 6MAN WG [second] Last Call: draft-ietf-6man-u… Stuart Cheshire