Subject: draft-ietf-6man-uri-zoneid-02

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Wed, 01 Aug 2012 09:42:44 -0700

Wouldn't it be an option to have all applications & systems accept as 
input both formats, but only give as output the new one?
i.e. browsers already rewrite URIs.

-- 
Tassos

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Aug 2012 19:16:33 +0200

On Wed, Aug 01, 2012 at 09:42:44AM -0700, Tassos Chatzithomaoglou wrote:
> Wouldn't it be an option to have all applications & systems accept
> as input both formats, but only give as output the new one?

There are other standards that currently state that % is the canonical
format for zone identifier separation. We would have to revise those
standards (and all standards using those standards) and for some of
them this is not just a simple update due to the way versioning works.
As such, a new '-' notation won't be accepted by certain interfaces
for a long time. In other words, we cause problems (perhaps for 10-20
years) where there are currently no problems. And the question is
whether this price is justified to address the zone identifier in URI
issue.

For me, the priority is this:

a) Check seriously whether %en1 is really not acceptable since there
   really is no ambiguity. Using this notation is what the user wants.

b) If a) is indeed not possible, simply apply the URI escaping rules,
   that is %25en1. This is consistent with URI escaping (which might
   happen on other parts of the zone index as well). Provide advise that
   URI parser implementors may accept %en1 (when it is unambiguous) and
   turn it into %25en1. (Many browsers already do this kind of thing
   today for other characters that need escaping.)

I see no value in introducing a new separator.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2012 11:10:40 +0100

>    really is no ambiguity. Using this notation is what the user wants.

Of course we have done that, twice (a few years ago and this year).
Dead end.

>    today for other characters that need escaping.)

This, to my understanding, was already rejected by 6man some months ago,
with the conclusion that a new separator is needed. It's not my job
to make the consensus call, however.

> I see no value in introducing a new separator.

The value is providing a long-term path to cut and paste. Otherwise,
I assume we would indeed choose the %25 approach.

    Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 18:29:13 +0200

> I assume we would indeed choose the %25 approach.

OK, I change my statement to:

  I do not believe that the value of introducing a new separator
  justifies its costs.

/js

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 2 Aug 2012 13:57:27 -0400

On Thu, Aug 2, 2012 at 12:29 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> Is there any value in trying to add "%%" to the URI BNF?  This would
seem to give us *almost* cut and paste (which we don't quite have now
anyway, since we must add '[' and ']') while disambiguating whether
"%251" means "%1" or "%251" to the browser UI ("%%1" -> "%251").

Lots of systems use ESC ESC to really mean ESC.

-K-

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>