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

Brian E Carpenter <> Mon, 16 July 2012 10:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87BBF21F8711 for <>; Mon, 16 Jul 2012 03:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.297
X-Spam-Status: No, score=-101.297 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bW6mH6jfrmhv for <>; Mon, 16 Jul 2012 03:50:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 185F821F86FD for <>; Mon, 16 Jul 2012 03:50:31 -0700 (PDT)
Received: by eekd4 with SMTP id d4so1705486eek.31 for <>; Mon, 16 Jul 2012 03:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=s2GAlqVaGW9g33tSQaWk5b0DiolkX8TljGPnvZQ3UXw=; b=ltQTCBNXm2PsLzC5XALAP0IV7SG3qVseMaHZ3QDsbrP4NwFgde8k+UqTMzKAUb58tP luS7/qw0w6HaHtpjH0fujue6ddRLrDaDqMwlABpbaA8ThlL/rdtjRa4MJr5mTGVlWpxf +5cblvzcZqTZ6bEwap4WkNMVCkbD4w8D5MgdgMn9Hh63yBdURYVwYmbPzIF1hGO0ggFz IyT5zZZ0DTxBwLslKvGqGH7nZv4+u7kXjSLkBw6Grm3c+9MprAiJ112W0QXJAPScXRs5 O1CbKApfKrywV8oL3mAhDr4KbEzukfmgfJUAyaOSVKMRJivA7hL6I0GI6tF9l/R5S+AQ MQSg==
Received: by with SMTP id h41mr8702317eem.2.1342435875689; Mon, 16 Jul 2012 03:51:15 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id k48sm17653121eep.13.2012. (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 03:51:14 -0700 (PDT)
Message-ID: <>
Date: Mon, 16 Jul 2012 11:51:13 +0100
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
References: <> <> <> <> <> <> <> <> <20120715164957.GB685@elstar.local> <> <20120716095836.GA11013@elstar.local>
In-Reply-To: <20120716095836.GA11013@elstar.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jul 2012 10:50:33 -0000

   Brian Carpenter

On 16/07/2012 10:58, Juergen Schoenwaelder wrote:
> On Mon, Jul 16, 2012 at 08:03:03AM +0100, Brian E Carpenter wrote:
>> 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.
> RFC 4001 and RFC 6021. These are the ones I have edited. There may be
> more. And RFC 4001 seems pretty widely used, pretty much in all more
> recent IP related MIB modules:
> According to 
> RFC 4007 is used by 9 other RFCs. We could check whether any of the
> other 7 RFCs may use a literal IPv6 address format with a zone
> identifier.

>From a quick check, none of them do so.

More below...

>> 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 "-".
> I am concerned that we are simply too late in the game for changing
> this delimiter, in particular if we start allowing both via an update
> to RFC 4007.
> Also note that RFC 4001 has a DISPLAY-HINT, hence the text in section
> 1 may be somewhat misleading. On the wire, SNMP ships a number but it
> is most likely presented as a rendered value to the user or databases.

Yes, but of course the name/number mapping is entirely local to the
host in which it applies. At the other end of an SNMP transaction,
that mapping is lost, so the rendered value is not very significant.
I agree that the DISPLAY-HINT will generate a % delimiter (unless the
community decides to update the textual convention).

> RFC 6021 clearly uses a textual format on the wire.

Yes, but there's a problem IMHO. 6021 says:

"  The canonical format for the zone index is
   the numerical format as described in RFC 4007, Section

That implies that 4007 does truly define a canonical format; but it
doesn't. It says that a host SHOULD support numerical indices and
MAY support other kinds of implementation-depedent non-null strings.
That's underspecified when it comes to mapping into a strictly defined
format such as a URI or yang. And (as in the SNMP case) the ASCII string
is completely meaningless outside the originating host. "1" might not
even refer to interface 1, as far as I can see.

>>> 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 am not sure this is generally true. While the interpretation of the
> URI is certainly host specific (or even more precise specific to the
> nodes' interfaces), this does not necessarily mean those URIs are
> never compared outside the host.

True; I just meant that it doesn't seem to matter much in practice.
These URIs are intended to be of use during testing and diagnosis,
and if they show up somewhere else in the network, they are garbage

>>> 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.
> If it were that simple, we could simply recommend that browsers should
> be lenient and accept the %en1 format. The question is really whether
> Internet Explorer people would do so and whether Firefox people would
> go back to support what they apparently did before. This would enable
> round-trip cut'n'paste and we would be done.

I am not interested personally in taking that fight to the URI community;
that's why I pursued the current direction. Of course, the WG can decide

>>> >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.
> I understand. That is a standardization / implementation issue to
> solve.  Solving it by introducing a new notation and pushing the
> conversions to users for years to come seems a not very user friendly
> resolution.
>>> 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.
> I am not even sure about that. The "%" notation works reasonably well
> across many applications today. I would be bad if side-effects of an
> attempt to settle the URI issue and the desire to support cut'n'paste
> at the end causes other things to start disagreeing about the
> separator.
> Bottom line: I guess my concern mostly boils down to an update of RFC
> 4007 that allows multiple separators and the effects this might have
> by system tools producing and consuming different notations.
> /js