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

From: Stuart Cheshire <[email-masked]>
Date: Thu, 09 Aug 2012 14:31:24 -0700

At the meeting in Vancouver, Dave Thaler made a point that I found  
convincing:

Where is the character set for IPv6 zone IDs specified? If we accept  
that future interface names might include non-roman characters, then  
we have to assume that to allow safe unambiguous use in URIs,  
interface names have to undergo escaping.

And if the interface name itself is going to be escaped using URI "% 
xx" notation, then why not escape the '%' the same way?

This argues in support of what Microsoft already did: Encode '%' as "% 
25".

It's not my favourite outcome, but based on Dave Thaler's comment,  
it's the one that gets my vote.

In the spirit of "be liberal with what you accept" the doc should  
also advocate that URI parsers are forgiving about accepting bare '%'  
signs -- i.e. a '%' not followed by two valid hex characters is left  
untouched. This lets a human user copy-and-paste "fe80::a%en1" from a  
"ping" command and have it work, though the strictly correct form  
(which URI generators should output) remains "fe80::a%25en1".

Stuart Cheshire

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Aug 2012 08:32:09 +0100

Stuart,

On 09/08/2012 22:31, Stuart Cheshire wrote:
> Where is the character set for IPv6 zone IDs specified?

RFC 4007 doesn't do so, but can be read to imply ASCII.

draft-ietf-6man-uri-zoneid-02 is explicit that it refers to
the URI character set, which is ASCII:

   A <zone_id> SHOULD contain only ASCII characters classified
   in RFC 3986 as "unreserved".

But it allows percent encoding in a URI, which is necessary because of
the SHOULD:

   ZoneID = 1*( unreserved / pct-encoded )

> If we accept
> that future interface names might include non-roman characters, then we
> have to assume that to allow safe unambiguous use in URIs, interface
> names have to undergo escaping.

If we want to internationalise the ZoneID, that would be a whole
other discussion.

> And if the interface name itself is going to be escaped using URI "%xx"
> notation, then why not escape the '%' the same way?

My impression is that this WG has already objected to that, which is why
we ended up with the current proposal. I leave the next step to the WG Chair.

   Brian

> This argues in support of what Microsoft already did: Encode '%' as "%25".
> 
> It's not my favourite outcome, but based on Dave Thaler's comment, it's
> the one that gets my vote.
> 
> In the spirit of "be liberal with what you accept" the doc should also
> advocate that URI parsers are forgiving about accepting bare '%' signs
> -- i.e. a '%' not followed by two valid hex characters is left
> "ping" command and have it work, though the strictly correct form (which
> URI generators should output) remains "fe80::a%25en1".
> 
> Stuart Cheshire
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Aug 2012 11:55:23 -0400

>>>>> "Stuart" == Stuart Cheshire <[email-masked]> writes:
    Stuart> This argues in support of what Microsoft already did: Encode
    Stuart> '%' as "% 25". 

okay.

May a browser process the %-escaped UTF-8 in the interface name for the
purpose of display them?  

If it does that, and a user then copies and pastes the address into the
ping command, presumeably, the copy buffer contains the UTF-8, so the
result that the parser (in the ping) sees the bare % as well?

(this is just supporting that you say that the parse must be tolerant of
a bare %)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Aug 2012 17:02:57 +0100

> (this is just supporting that you say that the parse must be tolerant of

First please solve the mystery of how such a parser can tell whether %251 is
an escaped "%1" or an unescaped "%251".

---

From: Dave Thaler <[email-masked]>
Date: Sat, 11 Aug 2012 02:59:28 +0000

How?  RFC 4007 says:
> An implementation MAY support other kinds of non-null strings as
> <zone_id>.  However, the strings must not conflict with the delimiter
> character.  The precise format and semantics of additional strings is
> implementation dependent.

So it's completely implementation dependent, the only restriction being
that % and null are disallowed.

>    ZoneID = 1*( unreserved / pct-encoded )

ZoneID needs to allow (including via percent-encoding) the same characters
as are allowed in <zone_id> in RFC 4007.  For example the ']'
character would be legal in RFC 4007 but would have to be percent
encoded in a URI.

> If we want to internationalise the ZoneID, that would be a whole

It's already allowed by RFC 4007 as far as I know.

Stuart's email is an accurate summary of my position.

-Dave

---

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

Dave,

>> implementation dependent.

Yes, it says that, but the context to me implies ASCII. We could argue
about that for a long time, so let's not bother...

>>    in RFC 3986 as "unreserved".

The draft isn't clear enough (yet) but my idea was that this was part
of the update to RFC 4007.

> character would be legal in RFC 4007 but would have to be percent

Yes

> It's already allowed by RFC 4007 as far as I know.

Well, again, it's a matter of interpretation; the question is
simply not addressed, which is a defect in the document IMHO.

> Stuart's email is an accurate summary of my position.

Yes, but that doesn't help with the %251 problem, which is where
we got stuck some months ago and came to the initial decision to
add a new delimiter. If people don't want to solve that problem,
i.e. accept that %251 in a URI is %1 in ping, and that %251 in ping
is %25251 in a URI, then we're done.

I'm here as a document editor, looking for guidance.

     Brian

     Brian

---

From: Dave Thaler <[email-masked]>
Date: Sat, 11 Aug 2012 17:14:19 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Saturday, August 11, 2012 3:40 AM
> To: Dave Thaler
> Cc: Bob Hinden; [email-masked]
> Subject: Re: draft-ietf-6man-uri-zoneid-02
> 
> Dave,
> 
> Yes, it says that, but the context to me implies ASCII. We could argue about
> that for a long time, so let's not bother...
> 
> > So it's completely implementation dependent, the only restriction
> > being that % and null are disallowed.
> >
> >> draft-ietf-6man-uri-zoneid-02 is explicit that it refers to the URI
> >> character set, which is ASCII:
> >>
> The draft isn't clear enough (yet) but my idea was that this was part of the
> update to RFC 4007.

During the Vancouver meeting, the chairs called the question of
whether to Update 4007 or not.   The clear sense of the room was not
to do so.  Assuming that consensus continues to hold on the list, I believe
this means the sentence you quote needs to be removed, and we cannot
place any restrictions on zone_id that aren't in 4007.

-Dave

> >> But it allows percent encoding in a URI, which is necessary because
> >> of the SHOULD:
> >>
> > ZoneID needs to allow (including via percent-encoding) the same
> > characters as are allowed in <zone_id> in RFC 4007.  For example the ']'
> Well, again, it's a matter of interpretation; the question is simply not
> addressed, which is a defect in the document IMHO.
> 
> >
> Yes, but that doesn't help with the %251 problem, which is where we got
> stuck some months ago and came to the initial decision to add a new
> delimiter. If people don't want to solve that problem, i.e. accept that %251 in
> a URI is %1 in ping, and that %251 in ping is %25251 in a URI, then we're done.
> 
> >> My impression is that this WG has already objected to that, which is
> >> why we ended up with the current proposal. I leave the next step to the
> WG Chair.
> >>
> >>    Brian
> >>
> >>> also advocate that URI parsers are forgiving about accepting bare
> >>> '%' signs
> >>> untouched. This lets a human user copy-and-paste "fe80::a%en1" from
> >>> a "ping" command and have it work, though the strictly correct form
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Aug 2012 08:23:38 +0100

> place any restrictions on zone_id that aren't in 4007.

In fact I agree that it's best to limit the scope of the current draft
to solving the URI problem one way or another. I believe that RFC 4007
is in need of attention, but that should be handled separately.

   Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Aug 2012 11:25:04 +0200

> it's the one that gets my vote.

+1
 
/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: t.petch <[email-masked]>
Date: Tue, 14 Aug 2012 14:30:18 +0100

----- Original Message -----
From: "Dave Thaler" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>; "Bob Hinden" <[email-masked]>
Sent: Saturday, August 11, 2012 6:14 PM
> to do so.

Unfortunately, the minutes seem to have no recollection of this
happening,
although as you later say, it is what happens on the list that takes
precedence.
Had I been in the room, I would not have concurred.

Tom Petch

Minutes extract

   Bob Hinden presented the draft about Representing IPv6 Zone
          Identifiers in Uniform Resource Identifiers,
          (draft-ietf-6man-uri-zoneid-02.txt)

======================================================================

          Erik Kline wanted to know if the authors have considered '@'
as a
          separator. He also wanted to know how to ensure that the zone
id was a
          valid production. Bob mentioned that it cannot be ensured.
Dave Thaler
          mentioned that in windows the zone id was always an integer
but it
          could be different for other OSs.

          Stuart Cheshire wanted this to be mentioned in the document as
a
          guideline to OS implementers. He wanted to do what was best
for the
          end users rather than what was best for the programmers. He
believed
          that unless the zone id was greater than 250 there were no
issues. Bob
          Hinden agreed with Stuart and thought that browsers could
easily
          handle the special case.

          Dave Thaler thought that the whole justification about cut and
paste
          was dubious, and he wanted the justification to be rewritten
          concerning other issues with using %. He talked about the
validation
          of the stuff inside [] performed by RFC4007 validators. He
wanted to
          make sure that he could reuse the validation code instead of
writing
          two sets of code that could introduce bugs. Juergen
Schoenwaelder did
          not see the value with using a new separator either.

          Stig Venaas wanted to mention that the % could become
ambiguous if %
          escapable characters are already present in the interface
names. Dave
          mentioned that if the text has any foreign characters cut and
paste
          would not work anyway. Mark Andrews agreed with Stig
concerning this
          being confusing to humans but not for computers.

          Stuart and Kerry thanked Bob for taking on this tough job.

          Bob believed that the authors had enough information to do
another
          revision with the comments received during the meeting.
==================================================

>               Assuming that consensus continues to hold on the list, I
believe
> > >>> This argues in support of what Microsoft already did: Encode '%'
as
> > "%25".