Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 16 July 2012 07:02 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 C305911E80A6 for <ipv6@ietfa.amsl.com>; Mon, 16 Jul 2012 00:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.29
X-Spam-Level:
X-Spam-Status: No, score=-101.29 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 pDHAb0oW1qo0 for <ipv6@ietfa.amsl.com>; Mon, 16 Jul 2012 00:02:27 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBED11E8079 for <ipv6@ietf.org>; Mon, 16 Jul 2012 00:02:26 -0700 (PDT)
Received: by eaaq13 with SMTP id q13so1609110eaa.31 for <ipv6@ietf.org>; Mon, 16 Jul 2012 00:03:10 -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:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YzTwMfQ5aTUv7SihkmXjvuryjJf66mPybmF6SZsaYFI=; b=r/o9g3Y54Oibr8CYP5N7DxrE0NejgBz6i6LOiLZD43UgpHoxEp4OL0kIkk3MLOfRYh 2ZKxJm6vznJUZuQgFgUwlfZ/IUcOjdfcAmIK9nLtufPXGSB85+tmf+PoRVIqZ1yWRU38 6b3clKSzxwxDjEcXqw1g6qo10bpXrbapFPhTIezs4sTterBcEuGPEfPe/BYO9yF6k5oH BlNnVzVj9GqCOw4f8F+sAzGYc3slwTFUR2H4GyA2kQHgQQORiWzQ/qcqb3gpqdZLs4jI k0UQc0H4k5i0mzK5bIA6eA0GQZHHFhTihMWKRIp0n3FBZgngxMyMi7HVkHONnOiIazLT UHRQ==
Received: by 10.14.204.72 with SMTP id g48mr7771071eeo.36.1342422190290; Mon, 16 Jul 2012 00:03:10 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-217-126.as13285.net. [2.102.217.126]) by mx.google.com with ESMTPS id w3sm15980717eep.2.2012.07.16.00.03.08 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 00:03:09 -0700 (PDT)
Message-ID: <5003BCA7.5070208@gmail.com>
Date: Mon, 16 Jul 2012 08:03:03 +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
To: j.schoenwaelder@jacobs-university.de, Simon Perreault <simon.perreault@viagenie.ca>, ipv6@ietf.org
Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
References: <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <5002AAC9.1000506@viagenie.ca> <5002ED98.3030907@gmail.com> <20120715164957.GB685@elstar.local>
In-Reply-To: <20120715164957.GB685@elstar.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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, 16 Jul 2012 07:02:27 -0000

Juergen,

> The "%"
> separator is also embedded in other IETF standards-track specifications;

Can you be specific about that? The context here is very specific and
I am not aware of any other standards that are relevant to IPv6 literals.

There clearly isn't consensus in the WG on a change to the draft that can be
made before today's cutoff.

More below:

On 15/07/2012 17:49, Juergen Schoenwaelder wrote:
> On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote:
>> ... OK, as a result of Dave's comments, we now say:
>>
>> "  Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the
>>    preceding delimiter of a ZoneID."
>>
>> What we do *not* say is to recommend or suggest that all tools that
>> support RFC 4007 should be updated. Should we also add that?
> 
> I believe this direction is wrong. Allowing "-" does not replace "%"
> anytime soon and hence we simply make the problem worse. 

The problem at the moment is the lack of *uniform* support for ZoneIDs
in URIs. The cause of that problem is that the delimiter chosen some years
ago is an escape charater in URIs. IMHO that was a collective error;
we would never have chosen "$" as the delimiter because everybody knows
that's an escape character in many CLIs; we just made a mistake by
overlooking that "%" is also an escape character.

The WG has already decided to fix this by adding a second delimiter "-".

> The "%"
> separator is also embedded in other IETF standards-track specifications; I
> doubt they will all be revised soon to add "-". And then there is of
> course the question what the canonical format is for comparisions etc.

Correct, we have added a reference to the IAB draft on this topic, but
comparison isn't very important for this case because the URIs concerned
have no meaning outside the originating host.

> 
> I believe cut'n'paste from utilities to browsers and back to utilities
> is desirable (it is not just one direction). All utilities I have
> understand "%". How many years will cut'n'paste be a hassle if we
> allow both formats?

Less than infinity, which is the problem today, since most browsers simply
can't handle ZoneIDs at all.

> 
>>From a user experience point of view, the only really sensible thing
> to do for a browser is to accept %en1 literally. And apparently, this
> can be done. 

Or not, according to which browser you consider. Remember that it was
intentionally removed from Firefox because it violates the URI standard.
And IE accepts %25en1, so we have an existing incompatibility.

> Changing all our standards to support "-" and then
> waiting years for this to be supported by all the system tools is from
> a users' perspective pretty much a disaster.

It is annoying, but seems better than having no solution at all.

   Brian