Re: Candidate draft-ietf-6man-uri-zoneid-02

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 10 July 2012 14:21 UTC

Return-Path: <brian.e.carpenter@gmail.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 323F521F8766 for <ipv6@ietfa.amsl.com>; Tue, 10 Jul 2012 07:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.736
X-Spam-Level:
X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, 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 ef4mjaYrTxxZ for <ipv6@ietfa.amsl.com>; Tue, 10 Jul 2012 07:21:43 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A254C21F8777 for <ipv6@ietf.org>; Tue, 10 Jul 2012 07:21:42 -0700 (PDT)
Received: by eekd4 with SMTP id d4so10715eek.31 for <ipv6@ietf.org>; Tue, 10 Jul 2012 07:22:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2afyPwt6HfIKZrBwNMBgt6V020+nl5cbVV0ifGaVtBA=; b=A9adGttOpUESdW9yZpuOQg+TMBWpeDKDD4mMRMDdsu8rBgt7RJZIBcMblWdYgzrjOm mlsqVZb7ENX/vSrgeABwbBZsGavEWnRDDLzUHUvKt3+2DPwWwQVLc/8Ck+cd+bczhHe9 fD0bM1ESmdVbiWkXZLV5SKyukIcpILTLBOWFQJ3iSteXGPYbWFfzwvC86uzOAfQQ4XMD nNhY4o3AX/z36TFpsPUKQQMxpkfJn7lCsevYPXcFSvGvP12UPBT67CqmI+zVFzWuxSgx OVoThDmc/R/PwpeDTWBX0HrzZUJmJLQUVNJaJPEjT6HoBVP3vfKdrFDp1aOWc9pOfudj SRPQ==
Received: by 10.14.96.10 with SMTP id q10mr10390829eef.14.1341930129578; Tue, 10 Jul 2012 07:22:09 -0700 (PDT)
Received: from [128.232.100.215] (c0215.aw.cl.cam.ac.uk. [128.232.100.215]) by mx.google.com with ESMTPS id h53sm103030747eea.1.2012.07.10.07.22.07 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 07:22:08 -0700 (PDT)
Message-ID: <4FFC3A94.4070501@gmail.com>
Date: Tue, 10 Jul 2012 15:22:12 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
CC: "ipv6@ietf.org Mailing List" <ipv6@ietf.org>
Subject: Re: Candidate draft-ietf-6man-uri-zoneid-02
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> <9B57C850BB53634CACEC56EF4853FF653B6A4C51@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4FFBD616.4050208@gmail.com> <4FFC3406.30604@gmail.com>
In-Reply-To: <4FFC3406.30604@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Tue, 10 Jul 2012 14:21:44 -0000

Sorry - thought I'd deleted the cc to the list.

Regards
   Brian Carpenter




On 10/07/2012 14:54, Brian E Carpenter wrote:
> Bob (as co-author) and Dave (as reviewer),
> 
> Here's a proposed update and a diff file.
> 
> Please let me know ASAP if this is OK for you, as the cutoff is approaching.
> 
> Regards
>    Brian
> 
> On 10/07/2012 08:13, Brian E Carpenter wrote:
>> Dave, we do of course make the point that it's only locally significant, but
>> a reference to that paragraph of 3986 would complete the story.
>>
>> Regards
>>    Brian
>>
>>
>> On 09/07/2012 19:54, Dave Thaler wrote:
>>> 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
>>>> --------------------------------------------------------------------
>>