Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Dec 2004 14:42:53 +0100

I have to wonder whether we shouldn't go further, and RECOMMEND
the _ format and deprecate the % format in the scoping architecture.

Annoying for implementers, but then we could get cut-and-paste ability.

    Brian

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 02 Dec 2004 12:48:20 -0800

Brian,

>Annoying for implementers, but then we could get cut-and-paste ability.

I agree that getting "cut and paste" is a big usability win.  Does "_" 
create any other problems?

Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Dec 2004 22:59:06 +0100

> Annoying for implementers, but then we could get cut-and-paste ability.

Are we sure this is worth the effort it takes? So far, I have not 
seen a real-world report that zone ids are indeed needed in URIs.
This _might_ come up in the future - but do we really expect to
change all the already existing code for the reason that the %
does not fit easily into URIs?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Dec 2004 09:31:20 +1100

> create any other problems?
 
	You mean apart from it being part of some character sets.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Thu, 02 Dec 2004 14:57:12 -0800

Mark,

>         You mean apart from it being part of some character sets.

I was asking if it might be special in any other operating systems, CLI's, 
parsers, shells, etc., where it would have to be quoted or otherwise 
changed.  It is only worth considering this change if "cut and paste" works 
directly.

Bob

---

From: Atsushi Onoe <[email-masked]>
Date: Thu, 2 Dec 2004 16:18:06 -0800 (PST)

> create any other problems?

There were >100 e-mails on the ipng ML at December 1999 about the
representation.  Actually we considered the all possible characters.
One reason to reject '_' was that it should be used for <zone_id>.

Atsushi Onoe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Dec 2004 09:17:22 +0100

> does not fit easily into URIs?

I wish we had spotted this problem (and the problem in URLs
caused by : ) much earlier... but if we don't change it now, we
*never* will, which is why I asked the question. The cost of
the change is high now, but will be unthinkable once v6 is
in general use.

I'm not convinced we should change it, but now is the time to decide.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Dec 2004 09:18:50 +0100

> One reason to reject '_' was that it should be used for <zone_id>.

Why does that matter? Incompatibility with URL syntax is a much bigger
problem, IMHO.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 3 Dec 2004 11:39:37 +0000

> I'm not convinced we should change it, but now is the time to decide.

So what would the cost be of allowing the new syntax, while not removing
the old?  Then at least the capability is there to avoid the % when needed.
As and when people hit the problem, they start using the newer syntax.

Tim

---

From: Bill Fenner <[email-masked]>
Date: Fri, 3 Dec 2004 09:32:31 -0800

>One reason to reject '_' was that it should be used for <zone_id>.

There are very few messages (around 10) in the archive that actually
discuss the specifics of delimiter selection (mostly with subject "Re:
Scope ID secret Cabal (minutes)").  The only message that I saw suggesting
that "-", "." and "_" might be reserved because they could be used in
the <zone_id> also said that he preferred "-" or "_" as the delimiter.
I'd say that message could be used to argue for either side of the issue.

  Bill

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Dec 2004 22:11:22 +0100

> As and when people hit the problem, they start using the newer syntax.

Allowing both syntaxes is IMHO worse than sticking with what we have.
Lets face it: Even if we decide today to move from % to _, it will take
several years to get rid of the % notation in installed systems. If we
allow both, this process might take even longer. While IPv6 might not be
used as much as we like, it is widely implemented and the code is out 
there in customer hands.

/js

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 04 Dec 2004 14:18:33 +0900

>>>>> On Fri, 3 Dec 2004 09:32:31 -0800, 
>>>>> Bill Fenner <[email-masked]> said:

> I'd say that message could be used to argue for either side of the issue.

I've also been recalling the previous discussions, including
non-public, internal ones.  And I admit we did not find any clear
conflict with "_" at that time.  If we just started the scope-arch
work, it would definitely be better to adopt "_", not "%".  The
problem is that % as the delimiter has been in the scope-arch spec for
several years, and implementations using the spec have been quite
widely deployed, making the transition costly.

So, IMO, we need to make a decision considering following points:

1. how costly it is to change the existing implementation
2. how seriously we want (to allow) the use of scoped address syntax
   in IRIs or URIs

I'm quite sure opinions vary on these points.  Speaking for myself,
I'm very reluctant to change the existing implementations.  Regarding
the migration cost, I basically agree with Juergen.  I'd also really
like to ask others not to underestimate the deployment base.

Regarding point 2, I personally suspect the reality, at the risk of
exposing my ignorance.  I remember two possible use cases were shown:

- configuring a home router/dhcp/dns server via HTTP via a link-local
  address
- SNMP URIs that get passed between different agents/managers on the
  same system.

In the former case, I guess we can simply use the "default zone ID" in
many cases (although some implementations may not yet support that, in
which case we'll need to fix them).  I'd say the latter use case is
very minor, while I must admit just saying "it should be minor" is not
convincing.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

p.s. I've noticed the draft-ietf-ipv6-scoping-arch-02.txt has been in
the RFC editor queue for over 3 months.  Is anyone know whether this
is a usual delay or the issues with the URI syntax is working as a
showstopper?

---

From: Atsushi Onoe <[email-masked]>
Date: Sun, 5 Dec 2004 15:20:33 +0900 (JST)

> 2. how seriously we want (to allow) the use of scoped address syntax

It should be noted that the scoped address format MUST NOT be sent on
the wire.  The address part of the URI must be parsed before sending to
the proxy even when proxy server is configured.  This means additional
processing should be required for the implementation, regardless which
delimiter is used.  I think it was in justification of non-conforming URI
specification, which is usually intended to be sent over the wire.

Regards,

Atsushi Onoe

---

From: Bill Fenner <[email-masked]>
Date: Sun, 5 Dec 2004 11:54:07 -0800

I've added the following pieces to the draft to try to capture the
conversation so far.

[at the end of section 2.1:]
   o  Use '%' in the URI
      Pro:
         +  "%" is the same character.
         +  Can copy and paste between forms.
      Con:
         +  '%' is fundamentally special in URIs; parsers can be
            expected to be hard-wired to know that they start a
            percent-encoded octet.
         +  IPvFuture ABNF doesn't permit bare percent.
      Issues:
         +  Impossible to ensure that this exception to a fundamental
            URI rule would be handled properly by parsers.

[new section:]
3.  Limitations

   The usefulness of a URI or IRI using a literal scoped address is
   obviously limited to systems within the same scope.  The addition of
   the zone identifier further limits the usefulness to the system on
   which the URI or IRI was generated, since zone IDs are completely
   local to a given host.  Therefore, care must be taken to not pass
   these URIs between systems.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Sun, 5 Dec 2004 16:43:18 -0800

>is a usual delay or the issues with the URI syntax is working as a

The RFCs that have been published over the last couple of months have
had average delays of just over 4 months.  As far as I know, nobody
has suggested delaying this document's publication as RFC.

  Bill

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2004 08:53:22 +0100

>    these URIs between systems.

This phrase "passing URIs between systems" never made me really happy. 
I believe there are valid reasons to pass even URIs with zone IDs. 
The point is I think that the interpretation of such URIs is only
meaningful on a given system or set of systems which understand the
semantics of the zone ID. 

Looking at the SNMP URI as an example: It might be totally OK to have 
a manager which understands the zones within a network and which sends 
a properly constructed URI including a zone ID to a box for consumption
on that box.

/js

---

From: Bill Fenner <[email-masked]>
Date: Mon, 6 Dec 2004 09:56:37 -0800

Good point.  I replaced the last sentence with:

Therefore, care must be taken to not pass these URIs blindly between
systems.  When both systems are aware of the relevant Zone IDs, e.g.,
an SNMP manager that is aware of the zone ID configuration of an agent,
it is acceptable to pass these URIs between systems.

Wordsmithing is welcome.

  Bill

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2004 21:16:14 +0100

>             URI rule would be handled properly by parsers.

I think it is useful to explore how generic these real-world URI
parsers really are. I just tried to use

	http://%3134.169.34.18/	 and  http://134.169.34.%31%38/

to access a web page, expecting that parsers would turn that into

	http://134.169.34.18/

but I got lots of "host not found" messages. So it indeed looks like
the real-world parsers I have access to pass hostnames/IP addresses
to name lookup functions without preparsing them. I also tried things
such as <http://%77%77%77.ietf.org/> without much luck. Please make
your own tests.

The conclusion from my little series of tests is clear. The
implementations I have tried do not interpret % escape sequences
in the host portion of URIs and so the direction should be to
simply allow % for IPv6 addresses with a zone identifier and to
tell URI folks that they better do not mandate that % escape
encoding is applied to the host portion of URIs since this is
a) not really useful and b) not widely implemented. Of course,
if you find implementations that do interpret % escape sequences
in the host portion of URIs, your conclusions might be different.

/js

---

From: Noritoshi Demizu <[email-masked]>
Date: Tue, 07 Dec 2004 11:34:19 +0900 (JST)

> but I got lots of "host not found" messages.

My web browser behaves as the same for these examples.
But it is terminated by inputing the following illegal notations.

  http://134.169.34.1%8/
  http://134.169.34%.18/
  http://134.169.3%4.18/
  http://134.169.34.18%en0/

OTOH, it is not terminated by the following notations.

  http://[::1%4]/
  http://[::1%en0]/

Hence, illegal '%' notation may not be safe for some implementation.
But illegal '%' notation in [::] might be treated specially.

Regards,
Noritoshi Demizu

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Dec 2004 10:23:57 +0100

How interesting! www.%33com.com also fails, so it isn't even
being kicked into numeric addresses that does it - the parsers
simply don't interpret the escape at that point.

So they're all broken?

     Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Dec 2004 10:31:46 +0100

> simply don't interpret the escape at that point.

Either all these implementations are broken or the specification 
which requires % escape processing on the host portion of a URI
(because it makes the URI grammer look nicer). It actually does
not buy us anything to do % escape processing on the host name
and with internationalized domain names, implementations might
have even more reasons to treat the host portion of URIs in 
special ways.

/js

---

From: Atsushi Onoe <[email-masked]>
Date: Tue, 7 Dec 2004 19:00:43 +0900 (JST)

> simply don't interpret the escape at that point.

No.  As BNF states in RFC 2396, escape by '%' is not allowed for hostport.
So the implementation should not interpret '%33' as '3' when it appears
in hostname or IP address, in any cases.

Regards,

Atsushi Onoe

---

From: Noritoshi Demizu <[email-masked]>
Date: Tue, 07 Dec 2004 19:31:16 +0900 (JST)

> in hostname or IP address, in any cases.

You might already know but <draft-fielding-uri-rfc2396bis-07.txt>
allows %xx notation in host part.

Regards,
Noritoshi Demizu

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Dec 2004 13:40:39 +0100

> allows %xx notation in host part.

Really? Did the IESG know it was *changing* the syntax when it
approved 2396bis?

     Brian

---

From: Noritoshi Demizu <[email-masked]>
Date: Tue, 07 Dec 2004 22:13:21 +0900 (JST)

> Really?

I believe so.  The following ABNF is extracted from Appendix A of
<draft-fielding-uri-rfc2396bis-07.txt> (Sep 2004).

    URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
    hier-part     = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty
    authority     = [ userinfo "@" ] host [ ":" port ]
      host        = IP-literal / IPv4address / reg-name
      reg-name    = *( unreserved / pct-encoded / sub-delims )
    pct-encoded   = "%" HEXDIG HEXDIG

<draft-duerst-iri-11.txt> (Nov 2004) also allows %xx notation in host
part.  The following ABNF is extracted from section 2.2 of it.

      IRI            = scheme ":" ihier-part [ "?" iquery ]
      ihier-part     = "//" iauthority ipath-abempty
                     / ipath-absolute
                     / ipath-rootless
                     / ipath-empty
      iauthority     = [ iuserinfo "@" ] ihost [ ":" port ]
      ihost          = IP-literal / IPv4address / ireg-name
      ireg-name      = *( iunreserved / pct-encoded / sub-delims )
      pct-encoded    = "%" HEXDIG HEXDIG

Regards,
Noritoshi Demizu

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Dec 2004 14:39:13 +0100

> allows %xx notation in host part.

Does someone know the actual motivation for this change? Which problem
were they trying to solve by allowing %xx notation in the host part?

/js

---

From: Noritoshi Demizu <[email-masked]>
Date: Tue, 07 Dec 2004 23:50:43 +0900 (JST)

> > > allows %xx notation in host part.

I should also mention that <draft-fielding-uri-rfc2396bis-07.txt> does
not allow %xx notation in literal IPv6 address, as follows.

    IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"

    IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

    IPv6address   =                            6( h16 ":" ) ls32
                  /                       "::" 5( h16 ":" ) ls32
                  / [               h16 ] "::" 4( h16 ":" ) ls32
                  / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                  / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                  / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                  / [ *4( h16 ":" ) h16 ] "::"              ls32
                  / [ *5( h16 ":" ) h16 ] "::"              h16
                  / [ *6( h16 ":" ) h16 ] "::"

      unreserved     = ALPHA / DIGIT / "-" / "." / "_" / "~"
      sub-delims     = "!" / "$" / "&" / "'" / "(" / ")"
                     / "*" / "+" / "," / ";" / "="
      ls32        = ( h16 ":" h16 ) / IPv4address
      h16         = 1*4HEXDIG

Hence, a URI parser should not interpret %xx notation in IP-literal,
if it follows <draft-fielding-uri-rfc2396bis-07.txt>.

Regards,
Noritoshi Demizu

> From: Noritoshi Demizu <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: [email-masked], Margaret Wasserman <[email-masked]>
> Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt
> Date: Tue, 07 Dec 2004 22:13:21 +0900 (JST)
>

---

From: Bill Fenner <[email-masked]>
Date: Tue, 7 Dec 2004 08:20:00 -0800

The Full Standard URI spec (draft-fielding-uri-rfc2396bis-07.txt)
and the Proposed Standard IRI spec (draft-duerst-iri-11.txt) both
specify percent-encoding in the host part, particularly for support
of internationalization.

It's a shame that the [email-masked] list got dropped off of the cc list,
since that's where all the experts on URI parsers etc. live.  I'd like
to request that those who would like to discuss using the raw '%' resend
their message cc'ing both lists, so that discussion can include the
relevant people.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Tue, 7 Dec 2004 08:49:41 -0800

Percent encoding in the host part is an idn/i18n extension only;
the grammar is more permissive than the text.  The text restricts
percent-escaping to UTF-8 encoding of non-ASCII names.

This was part of a significant rewrite of the grammar from an ad-hoc
BNF to ABNF; see appendix D of draft-fielding-uri-rfc2396bis.

  Bill

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 7 Dec 2004 21:49:17 +0100

I tried all the addresses Juergen gave and they all worked for me with
Internet
Explorer (6.0) - perhaps the world's commonest browser but perhaps not
so common for those on the ipv6 list;-)

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Bill Fenner" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 06, 2004 9:16 PM
Subject: Re: I-D ACTION:draft-fenner-literal-zone-00.txt
> http://%3134.169.34.18/ and  http://134.169.34.%31%38/
both worked fine

> to access a web page, expecting that parsers would turn that into
worked fine
> such as <http://%77%77%77.ietf.org/> without much luck. Please make
worked fine
> your own tests.
all works fine

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 10 Dec 2004 18:35:51 +0900

>>>>> On Sun, 5 Dec 2004 16:43:18 -0800, 

> has suggested delaying this document's publication as RFC.

Ah, I see.  Thanks for the clarification.

					JINMEI, Tatuya