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

From: Dave Thaler <[email-masked]>
Date: Fri, 6 Jul 2012 01:28:57 +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 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=vs.85).aspx
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
noticeably.

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

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ole Trøan
> Sent: Wednesday, June 13, 2012 5:18 AM
> To: [email-masked] Mailing List
> Cc: [email-masked] Chairs; draft-ietf-6man-uri-
> [email-masked]
> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jul 2012 14:01:13 +0100

Dave,

1) FYI, the deadline we gave the URI list to comment on this has just
passed, with only one (positive) reply.

2) It's for the WG Chairs to say if they want another version
in view of your comments.

3) I don't see how the % format is currently legal. There's
no provision for any characters after the IPv6 address, whether
percent-encoded or not. We heard of browsers that previously
allowed full RFC 4007 syntax (% *not* treated as an escape)
but this is the first I've heard of IE allowing a zone index
at all.

Regards
   Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 6 Jul 2012 07:00:27 -0700

With my co-author hat on, would it help to include a description of what IE supports in Section 3. Web Browsers?

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jul 2012 17:56:39 +0100

I'd be happy with that, or a small appendix. Dave, is it documented anywhere?

Regards
   Brian

---

From: Dave Thaler <[email-masked]>
Date: Fri, 6 Jul 2012 17:29:26 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, July 06, 2012 6:01 AM
> To: Dave Thaler
> Cc: Ole Trøan; [email-masked] Mailing List; [email-masked] Chairs;
> [email-masked]
> Subject: Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt
> 
> Dave,
> 
> 1) FYI, the deadline we gave the URI list to comment on this has just passed, with
> only one (positive) reply.
> 
> 2) It's for the WG Chairs to say if they want another version in view of your
> comments.
> 
> 3) I don't see how the % format is currently legal. There's no provision for any
> characters after the IPv6 address, whether percent-encoded or not. We heard
> of browsers that previously allowed full RFC 4007 syntax (% *not* treated as an
> escape) but this is the first I've heard of IE allowing a zone index at all.

It's not currently legal in a URI, and I meant to fix one sentence of mine before
sending, but missed it.   But that's why the page says
"The URI standard, documented in RFC 3986, does not define the syntax for the 
scope ID, and the URI is considered non-uniform when the scope ID is present."
I might quibble with the language but the "non-uniform" means it's not a standard
URI.   It's not legal to appear on the wire in any protocol that passes URIs. However,
there are APIs that take strings that need not be well-formed URIs, e.g.
"http://foo/Hello World" is not a legal URI because " " would be %20 in a URI.
So the %25 syntax is used in such APIs that pass around things that are URI-like
strings.   I only just found that page myself, but there's a bunch of things in Windows
that pass around URI-like strings with zone IDs via APIs (not on the wire).

-Dave

> > 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
> > http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=vs.
> > 85).aspx 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).
> >

Above is the sentence I meant to delete, it's not correct :)

> > 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 noticeably.
> >
> > To support cut-and-paste, that means that "ping fe80::a-en1"
> > lacking is a section specifically updating RFC 4007 section 11 which
> > would declare that both '%' and '-' are acceptable separators in the
> > textual representation.
> >
> > -Dave
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Ole Trøan
> >> 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.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 6 Jul 2012 17:32:49 +0000

It's documented on the page in my original email.

However it's not sufficient.  Remember my second piece of feedback was
that the document contradicts itself, implying the specified syntax supports
cut and paste, but then doesn't provide a section updating RFC 4007 section 11.

If the document both mentions that alternative 3 is used by many things today
(IE, Windows, applications) within APIs that take URI-like strings, and also adds
a section updating RFC 4007 section 11, then I'd be happy with it.

-Dave

> Sent: Friday, July 06, 2012 9:57 AM
> To: Bob Hinden
> Cc: Dave Thaler; [email-masked] Chairs; draft-ietf-6man-uri-
> [email-masked]; [email-masked] Mailing List
> >> 2) It's for the WG Chairs to say if they want another version in view
> >> of your comments.
> >>
> >> 3) I don't see how the % format is currently legal. There's no
> >> provision for any characters after the IPv6 address, whether
> >> percent-encoded or not. We heard of browsers that previously allowed
> >> full RFC 4007 syntax (% *not* treated as an escape) but this is the
> >> first I've heard of IE allowing a zone index at all.
> >>
> >> Regards
> >>   Brian
> >>
> >>> 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
> >>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=v
> >>> s.85).aspx 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.
> >>>
> >>> 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
> >>> the rules for comparison (see draft-iab-identifier-comparison
> >>> section 3.1.2) but not noticeably.
> >>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Ole Trøan
> >>>> -------------------------------------------------------------------
> >>>> - IETF IPv6 working group mailing list [email-masked] Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Dave Thaler <[email-masked]>
Date: Mon, 9 Jul 2012 18:54:51 +0000

One additional gap that I think SHOULD be addressed.  RFC 3986 says:

   URIs have a global scope and are interpreted consistently regardless
   of context, though the result of that interpretation may be in
   relation to the end-user's context.  For example, "http://localhost/"
   has the same interpretation for every user of that reference, even
   though the network interface corresponding to "localhost" may be
   different for each end-user: interpretation is independent of access.
   However, an action made on the basis of that reference will take
   place in relation to the end-user's context, which implies that an
   action intended to refer to a globally unique thing must use a URI
   that distinguishes that resource from all other things.  URIs that
   identify in relation to the end-user's local context should only be
   used when the context itself is a defining aspect of the resource,
   such as when an on-line help manual refers to a file on the end-
   user's file system (e.g., "file:///etc/hosts").

It should be pointed out in the zoneid document that adding a zone id
changes the scope to be localhost rather than the scope of the address.

So "http://[fe80::1]/blah" is valid anywhere on the same link.
But "http://[fe80::1-id]/blah" is valid only within the same host.

-Dave

> Dave Thaler
> Sent: Friday, July 6, 2012 10:33 AM
> To: Brian E Carpenter; Bob Hinden
> Subject: RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt
> 
> If the document both mentions that alternative 3 is used by many things
> today (IE, Windows, applications) within APIs that take URI-like strings, and
> also adds a section updating RFC 4007 section 11, then I'd be happy with it.
> 
> -Dave
> 
> > Cc: Dave Thaler; [email-masked] Chairs;
> > draft-ietf-6man-uri- [email-masked]; [email-masked] Mailing List
> > > With my co-author hat on, would it help to include a description of
> > > what IE
> > supports in Section 3. Web Browsers?
> > >
> > > Bob
> > >
> > >
> > >> 1) FYI, the deadline we gave the URI list to comment on this has
> > >> just passed, with only one (positive) reply.
> > >>
> > >> 2) It's for the WG Chairs to say if they want another version in
> > >> view of your comments.
> > >>
> > >> allowed full RFC 4007 syntax (% *not* treated as an escape) but
> > >> this is the first I've heard of IE allowing a zone index at all.
> > >>
> > >> Regards
> > >>   Brian
> > >>
> > >>> The document appears to call out existing practice in several
> > >>> places, such as
> > in section 1:
> > >>> 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:
> > >>> 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
> > >>> http://msdn.microsoft.com/en-
> us/library/windows/desktop/aa385325(v
> > >>> =v s.85).aspx 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).
> > >>>
> > >>> 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
> > >>> 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 noticeably.
> > >>>
> > >>> 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 representation.
> > >>>
> > >>> -Dave
> > >>>
> > >>>> 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.
> > >>>> -
> > >>> ------------------------------------------------------------------
> > >>> -- IETF IPv6 working group mailing list [email-masked]
> > >>> Administrative
> > >> -

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2012 08:13:26 +0100

Dave, we do of course make the point that it's only locally significant, but
a reference to that paragraph of 3986 would complete the story.

Regards
   Brian

On 09/07/2012 19:54, Dave Thaler wrote:
>>>>>> --

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2012 15:22:12 +0100

Sorry - thought I'd deleted the cc to the list.

Regards
   Brian Carpenter

On 10/07/2012 14:54, Brian E Carpenter wrote:
> Bob (as co-author) and Dave (as reviewer),
> 
> Here's a proposed update and a diff file.
> 
> Please let me know ASAP if this is OK for you, as the cutoff is approaching.
> 
> Regards
>    Brian
> 
> On 10/07/2012 08:13, Brian E Carpenter wrote:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2012 14:54:14 +0100

Regards
   Brian

---

From: t.petch <[email-masked]>
Date: Wed, 18 Jul 2012 09:30:01 +0100

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Bob Hinden" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Dave
Thaler" <[email-masked]>
Sent: Friday, July 06, 2012 5:56 PM
Subject: Re: 6MAN WG [second] Last Call:
draft-ietf-6man-uri-zoneid-01.txt

> I'd be happy with that, or a small appendix. Dave, is it documented
anywhere?

Non-normative Appendix, Please.

Tom Petch

> > With my co-author hat on, would it help to include a description of
what IE supports in Section 3. Web Browsers?
> >> 1) FYI, the deadline we gave the URI list to comment on this has
just
> >>> However, it's missing discussion of other alternatives already in
common practice.
> >>> The disadvantage is certainly true.  However the main advantage
are notably
> >>> that using a zone id at all is common practice anyway).
http://msdn.microsoft.com/en-us/library/windows/desktop/aa385325(v=vs.85
).aspx
> >>> The document does not state whether the existing legal use is
suddenly
> >>> want to be OS-version-independent and use URI parsing libraries
provided by
> >>> edit boxes, the disadvantage of not being able to cut and paste is
not a
> >>> Personally I don't have an issue with allowing both formats if the
WG feels
> >>> The document already says it "updates 4007" so it seems that
what's
> >>>> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> >>>> as a Proposed Standard. Substantive comments should be directed
to the
-
> >>>> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
-
> >>> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 19 Jul 2012 23:20:13 -0700

> available to Windows applications (i.e. not just IE7).

Surely Dave, in the spirit of escaping characters that really didn't need to be escaped, you could have been a bit more creative with the URL :-)

Maybe something like this?

<http://msdn.microsoft.com/en%2Dus/library/windows/desktop/aa%33%38%35%33%32%35%28%76%3D%76%73%2E%38%35%29%2E%61%73%70%78>

Stuart Cheshire