RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt

Dave Thaler <dthaler@microsoft.com> Fri, 06 July 2012 17:29 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 3C15121F86B1 for <ipv6@ietfa.amsl.com>; Fri, 6 Jul 2012 10:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.721
X-Spam-Level:
X-Spam-Status: No, score=-103.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 FSwEdGY3pFFc for <ipv6@ietfa.amsl.com>; Fri, 6 Jul 2012 10:29:30 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id B4B2D21F8622 for <ipv6@ietf.org>; Fri, 6 Jul 2012 10:29:29 -0700 (PDT)
Received: from mail80-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:27:37 +0000
Received: from mail80-am1 (localhost [127.0.0.1]) by mail80-am1-R.bigfish.com (Postfix) with ESMTP id 612C0220099; Fri, 6 Jul 2012 17:27:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -39
X-BigFish: VS-39(zz98dI9371Ic89bh936eI1b0bM542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h93fhd25hf0ah107ah)
Received-SPF: pass (mail80-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail80-am1 (localhost.localdomain [127.0.0.1]) by mail80-am1 (MessageSwitch) id 1341595655458248_11127; Fri, 6 Jul 2012 17:27:35 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.226]) by mail80-am1.bigfish.com (Postfix) with ESMTP id 6B8FA480043; Fri, 6 Jul 2012 17:27:35 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:27:35 +0000
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 6 Jul 2012 17:29:26 +0000
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.28]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 10:29:26 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: Brian E Carpenter <brian.e.carpenter@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/DggAE9goD//9OmIA==
Date: Fri, 06 Jul 2012 17:29:26 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6909AE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <4CD4908C-3524-45BC-BA6F-1A595E91FFD9@employees.org> <9B57C850BB53634CACEC56EF4853FF653B68F527@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4FF6E199.5020007@gmail.com>
In-Reply-To: <4FF6E199.5020007@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.42]
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: Fri, 06 Jul 2012 17:29:31 -0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Friday, July 06, 2012 6:01 AM
> To: Dave Thaler
> Cc: Ole Trøan; ipv6@ietf.org Mailing List; 6man-chairs@tools.ietf.org Chairs;
> draft-ietf-6man-uri-zoneid@tools.ietf.org
> Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt
> 
> 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.

It's not currently legal in a URI, and I meant to fix one sentence of mine before
sending, but missed it.   But that's why the page says
"The URI standard, documented in RFC 3986, does not define the syntax for the 
scope ID, and the URI is considered non-uniform when the scope ID is present."
I might quibble with the language but the "non-uniform" means it's not a standard
URI.   It's not legal to appear on the wire in any protocol that passes URIs. However,
there are APIs that take strings that need not be well-formed URIs, e.g.
"http://foo/Hello World" is not a legal URI because " " would be %20 in a URI.
So the %25 syntax is used in such APIs that pass around things that are URI-like
strings.   I only just found that page myself, but there's a bunch of things in Windows
that pass around URI-like strings with zone IDs via APIs (not on the wire).

-Dave

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

Above is the sentence I meant to delete, it's not correct :)

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