Network Working Group B. Fenner Internet-Draft AT&T Labs -- Research Expires: August 23, 2005 M. Duerst World Wide Web Consortium February 19, 2005 A Format for IPv6 Scope Zone Identifiers in Literal URIs draft-fenner-literal-zone-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 23, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies the format to be used when specifying a zone identifier with a literal IPv6 address in URIs and IRIs. While this combination is expected to be needed rarely, it is important to specify the exact syntax. Fenner & Duerst Expires August 23, 2005 [Page 1] Internet-Draft IPv6 Scope Zones in Literal URIs February 2005 1. Introduction RFC 3986 [RFC3986] defines the IPv6address production for the rare case that a literal IPv6 address is required in a URI. IRIs [RFC3987] copy this syntax. The IPv6 Scoping Architecture [ipv6-scoping-arch] describes the syntax for specifying a zone ID to disambiguate an ambiguous scoped address. Unfortunately, the IPv6address production does not permit the format including the zone ID, so this document defines a method to specify a zone ID with a literal IPv6 address. 2. Format The IPvFuture production in URIs and IRIs was created to allow for flexibility in defining new IP address formats. We use this flexibility in this format, to add a previously unanticipated address format for IPv6. Therefore, strings matching this grammar also match the IPvFuture production in URIs and IRIs. While the form specified in the IPv6 Scoping Architecture [ipv6-scoping-arch] uses a percent ("%") to separate the zone ID from the address, this form separates the zone ID from the address using an underscore ("_"), to avoid the special meaning of the percent ("%") in URIs. ; An address matching IPv6scoped-literal also matches ; the URI/IRI spec's IP-literal with IPvFuture IPv6scoped-literal = "[v6." IPv6scoped-address "]" IPv6scoped-address = IPv6address "_" IPv6zone-id IPv6zone-id = 1*( unreserved / sub-delims / ":" ) 2.1 Tradeoffs o Use _ or Z or some other character as separator. Pro: + Fits current ABNF. + Doesn't require confusing percent-encoding. Con: + Have to remember different separator. + Can't copy and paste from other forms. (But that is the case also for percent-encoding, which usually doesn't happen automatically.) Issues: + Zone ID is currently loosely specified in scoping-arch; in order to fit this grammar it needs to be tighter. + Should "_" (or whatever delimiter) be allowed in the zone ID? ("No" complicates the ABNF) Fenner & Duerst Expires August 23, 2005 [Page 2] Internet-Draft IPv6 Scope Zones in Literal URIs February 2005 + Can a scoping-arch revision change the character in use? It could suggest that "_" can be used as an alternative to "%". o Use %25 as an encoded %, the scoping-arch separator. Pro: + "%" is the same character. Con: + "%25" is confusing. + Can't copy and paste from other forms where the % is not encoded. (But that is the case also when using a different character for the separator.) + IPvFuture ABNF doesn't permit percent-encoded characters. Issues: + Would need to change the IPvFuture grammar in URI [RFC3986] and IRI [RFC3987] specs to permit percent-encoded characters. 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. 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 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. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Fenner & Duerst Expires August 23, 2005 [Page 3] Internet-Draft IPv6 Scope Zones in Literal URIs February 2005 5. Security Considerations RFC 3986 [RFC3986] describes security considerations for URIs; this specification does not add any new security considerations. 6. Acknowledgements Margaret Wasserman first noticed that the original literal IPv6 form didn't support zone IDs. This document was first created based on discussions between Steve Bellovin, Brian Carpenter, Roy Fielding, Ted Hardie, Larry Masinter, and Thomas Narten. 7. Normative References [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [ipv6-scoping-arch] Deering, S., "IPv6 Scoped Address Architecture", Internet-Draft draft-ietf-ipv6-scoping-arch-02, August 2004. Authors' Addresses Bill Fenner AT&T Labs -- Research 75 Willow Rd Menlo Park, California 94025 USA Phone: +1 650-330-7893 Email: fenner@research.att.com Fenner & Duerst Expires August 23, 2005 [Page 4] Internet-Draft IPv6 Scope Zones in Literal URIs February 2005 Martin Duerst World Wide Web Consortium 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81 466 49 1170 Email: duerst@w3.org Appendix A. Change History A.1 Changes since -00 o Add "use '%' in the URI" text with pros and cons o Add "Limitations" section Fenner & Duerst Expires August 23, 2005 [Page 5] Internet-Draft IPv6 Scope Zones in Literal URIs February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fenner & Duerst Expires August 23, 2005 [Page 6]