datatracker.ietf.org
Sign in
Version 5.9.0, 2014-12-18
Report a bug

Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
draft-ietf-6man-uri-zoneid-06

Note: This ballot was opened for revision 05 and is now closed.

Summary: Needs 4 more YES or NO OBJECTION positions to pass.

Barry Leiba

Comment (2012-11-26 for -05)

-- Section 3, first paragraph --
The use of "older versions" and "recent versions" will be meaningless after
this RFC has been published for a while.  I suggest "some versions" instead,
for both.

-- Section 3, second paragraph --
As discussed in the AppsDir review thread, maybe it would help to add something
like this at the end of the paragraph?:

   Such bare "%" signs are for user interface convenience, and must be
   turned into properly escaped characters ("%25" encodes "%" in URIs)
   before the URI is used in any protocol.

I think it would be useful to also say something about what happens if, say,
instead of "en1", there's a ZoneID called "ee1".  A URI parser encountering
"fe80::a%ee1" would have to decide whether to interpret the "%" as "%25", or
whether to interpret "%ee" as a percent-escaped 0xEE character.  Advice would
be useful; lacking useful advice, a warning that this could happen would at
least help a little.

-- Section 4, last paragraph --
Brian's having a conversation with Yves about this on the AppsDir review
thread, with a suggestion that the document recommend stripping the ZoneID
before sending the URI out on the wire.  Recording that here for the record.

Benoit Claise

Comment (2012-11-27 for -05)

I've been really confused by the the appendix, which mentions: Appendix A.
Alternatives Considered However, the solution 3 is the selected solution AFAIT

  3.  Escaping the escape character as allowed by RFC 3986:

       http://[fe80::a%25en1]

       Advantage: allows use of browser, consistent with general URI
       syntax.

       Disadvantage: somewhat ugly and confusing, doesn't allow simple
       cut and paste.

However, the word "alternative" forced me to re-read the draft to see if I
missed something...

Editorial:
OLD
   The MIB textual convention [RFC4001] and the socket
   interface [RFC3493] define this as a 32 bit unsigned integer.

NEW
   The MIB textual convention InetZoneIndex [RFC4001] and the socket
   interface [RFC3493] define this as a 32 bit unsigned integer.

Pete Resnick

Comment (2012-11-27 for -05)

This is a user interface hack for a completely local matter. It is not related
to interoperability over the Internet. It uses error-prone mechanism ("%",
which must be escaped, and will end up being double-escaped by accident), and
is bound to leak onto the Internet in not great ways. It's not worthy of a
standards track document. But it's also not going to improve significantly by
using some other mechanism, it's better documented than not, and I don't have
the energy to argue about whether it should be other than standards track.
"Blech" I say, but I'm not going to stand in its way if that's what the
community wants to do.

Stephen Farrell

Comment (2012-11-26 for -05)

- 2nd para of section 3 says that browsers "should" accept a
bare % as input. I don't know if you mean that "should" as a
2119 SHOULD or not.

- Same place: Do you need to say that the browser MUST properly
escape that if it sends the URI anywhere, that is, that the URI
emitted MUST conform to this spec and include e.g., "%25eth0"
and not just "%eth0"?

- Idle curiosity: anyone know if its possible to use a %
character in an interface name on any common OS? If it were,
then maybe worth mentioning that that'd also need to be
escaped? On ubuntu "ifconfig 25% up" at least gives the same
error as "ifconfig foo up" so seems like if I were in a playful
mood, I could muck with udev and call an interface "25%". So
for the nittiest-nitty folks you could, if you wanted, say that
an interface called "25%" might result in a URI containing
"[fe80::a%2525%25]" :-)

- The secdir review [1] has a number of suggestions that the
authors seem happy to take on board.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03638.html

[Ralph Droms]

Comment (2012-11-28 for -05)

A very small nit in section 2:

   Note that the behaviour of an IPv6
   stack if passed a non-zero zone index for an address other than link-
   local is undefined.

s/non-zero/non-null/ ?