Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
RFC 6874

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

(Ron Bonica) Yes

(Brian Haberman) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-11-27 for -05)
No email
send info
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:


       Advantage: allows use of browser, consistent with general URI

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

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

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

(Ralph Droms) No Objection

Comment (2012-11-28 for -05)
No email
send info
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/ ?

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-11-26 for -05)
No email
send info
- 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.


(Russ Housley) (was Discuss) No Objection

Barry Leiba No Objection

Comment (2012-11-26 for -05)
No email
send info
-- 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.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

(Pete Resnick) Abstain

Comment (2012-11-27 for -05)
No email
send info
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.