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

Dave Thaler <> Fri, 06 July 2012 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DD4E11E8122 for <>; Thu, 5 Jul 2012 18:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.579
X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kaseCsHsxufB for <>; Thu, 5 Jul 2012 18:28:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2903C11E8120 for <>; Thu, 5 Jul 2012 18:28:48 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Fri, 6 Jul 2012 01:26:56 +0000
Received: from mail16-ch1 (localhost []) by (Postfix) with ESMTP id D22E52C0187; Fri, 6 Jul 2012 01:26:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -33
X-BigFish: VS-33(zz9371Ic89bh936eI542M1432Izz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah107ah)
Received-SPF: pass (mail16-ch1: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail16-ch1 (localhost.localdomain []) by mail16-ch1 (MessageSwitch) id 1341538014157878_25747; Fri, 6 Jul 2012 01:26:54 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id 1A42812004B; Fri, 6 Jul 2012 01:26:54 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 6 Jul 2012 01:26:53 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 6 Jul 2012 01:28:58 +0000
Received: from ([]) by ([]) with mapi id 14.02.0309.003; Thu, 5 Jul 2012 18:28:58 -0700
From: Dave Thaler <>
To: =?iso-8859-1?Q?Ole_Tr=F8an?= <>, " Mailing List" <>
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/Dg
Date: Fri, 6 Jul 2012 01:28:57 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " Chairs" <>, "" <>
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: Fri, 06 Jul 2012 01:28:49 -0000

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

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


> -----Original Message-----
> From: [] On Behalf Of
> Ole Trøan
> Sent: Wednesday, June 13, 2012 5:18 AM
> To: Mailing List
> Cc: Chairs; draft-ietf-6man-uri-
> 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
> Administrative Requests:
> --------------------------------------------------------------------