idnits 2.17.1 draft-fenner-literal-zone-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '...s "An implementation MAY support other...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2005) is 6762 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2234' is defined on line 143, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Fenner 3 Internet-Draft AT&T Labs -- Research 4 Expires: April 24, 2006 M. Duerst 5 World Wide Web Consortium 6 October 21, 2005 8 Formats for IPv6 Scope Zone Identifiers in Literal Address Formats 9 draft-fenner-literal-zone-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 24, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies the format to be used when specifying a zone 43 identifier with a literal IPv6 address in URIs and IRIs, and in SMTP 44 and Internet Mail Messages. While this combination is expected to be 45 needed rarely, it is useful to specify the exact syntax. 47 1. Introduction 49 RFC 3986 [RFC3986] defines the IPv6address production for the rare 50 case that a literal IPv6 address is required in a URI. IRIs 51 [RFC3987] copy this syntax. The IPv6 Scoping Architecture [RFC4007] 52 describes the syntax for specifying a zone ID to disambiguate an 53 ambiguous scoped address. Unfortunately, the IPv6address production 54 does not permit the format including the zone ID, so this document 55 defines a method to specify a zone ID with a literal IPv6 address in 56 URIs and IRIs. 58 The Simple Mail Transfer Protocol [RFC2821]'s IPv6-address-literal 59 production provides the same ability for SMTP, so this document 60 defines a similar syntax to specify a zone ID with a literal IPv6 61 address for SMTP. 63 While part of the reason for the deprecation of Site-Local scoped 64 addresses [RFC3879] was due to applications needing to know about 65 scope zones, the formats described in this document do not have the 66 problem described in section 2.1 of that document - specifically, 67 they always contain the zone ID, so are never ambiguous. 69 2. Format in URIs and IRIs 71 The IPvFuture production in URIs and IRIs was created to allow for 72 flexibility in defining new IP address formats. We use this 73 flexibility in this format, to add a previously unanticipated address 74 format for IPv6. Therefore, strings matching this grammar also match 75 the IPvFuture production in URIs and IRIs. While the form specified 76 in the IPv6 Scoping Architecture [RFC4007] uses a percent ("%") to 77 separate the zone ID from the address, this form separates the zone 78 ID from the address using an plus sign ("+"), to avoid the special 79 meaning of the percent ("%") in URIs. 81 ; An address matching IPv6scoped-literal also matches 82 ; the URI/IRI spec's IP-literal with IPvFuture 83 IPv6scoped-literal = "[v1." IPv6scoped-address "]" 84 IPv6scoped-address = IPv6address "+" IPv6zone-id 85 IPv6zone-id = 1*( unreserved / sub-delims / ":" ) 87 3. Format in SMTP 89 Although it usage is expected to be even more rare, there may be a 90 reason to use a zone ID in an IPv6 literal address in SMTP. An 91 addition to the ABNF grammar used in the Simple Mail Transfer 92 Protocol [RFC2821] follows. 94 ; An address matching IPv6-address-scoped-literal 95 ; also matches RFC 2821's General-address-literal production 96 IPv6-address-scoped-literal: "IPv6z:" IPv6-addr "+" 1*dcontent 98 (Note: while it's possible to use "%" in the SMTP case, we use "+" in 99 order to align the SMTP and URI syntaxes.) 101 4. Limitations 103 The usefulness of a URI or IRI using a literal scoped address is 104 obviously limited to systems within the same scope. The addition of 105 the zone identifier further limits the usefulness to the system for 106 which the URI or IRI was generated, since zone IDs are completely 107 local to a given host. Therefore, care must be taken to not pass 108 these URIs blindly between systems. When both systems are aware of 109 the relevant Zone IDs, e.g., an SNMP manager that is aware of the 110 zone ID configuration of an agent, it is acceptable to pass these 111 URIs between systems. 113 Caution should be used when storing these URIs or IRIs in files. It 114 is recommended to use an FQDN instead of a literal IPv6 address in a 115 URL, whenever an FQDN is available. 117 5. IANA Considerations 119 IANA is requested to assign the "IPv6z" tag identifying a domain 120 literal. This registry may not have been created yet; it is 121 described in [RFC2821] but this will be the first assignment. 123 This is also the first use of the IPvFuture extension mechanism 124 described in [RFC3986]; that RFC did not create a registry for these 125 mechanisms. Should there be one? 127 6. Security Considerations 129 RFC 3986 [RFC3986] describes security considerations for URIs; this 130 specification does not add any new security considerations. 132 7. Acknowledgements 134 Margaret Wasserman first pointed out that the original literal IPv6 135 form didn't support zone IDs. This document was created based on 136 discussions between Steve Bellovin, Brian Carpenter, Roy Fielding, 137 Ted Hardie, Larry Masinter, and Thomas Narten. Further revisions 138 were based on feedback from the IPv6 working group and the IETF 139 applications area. 141 8. Normative References 143 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 144 Specifications: ABNF", RFC 2234, November 1997. 146 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 147 April 2001. 149 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 150 Addresses", RFC 3879, September 2004. 152 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 153 Resource Identifier (URI): Generic Syntax", STD 66, 154 RFC 3986, January 2005. 156 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 157 Identifiers (IRIs)", RFC 3987, January 2005. 159 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 160 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 161 March 2005. 163 Appendix A. To Do 165 o Pick another character if necessary from URI chars available: - . 166 _ ~ ! $ & ' ( ) * + , ; = 168 o Check with Keith if text saying why not to use this is sufficient 170 o Expand text on 2821 usage? 172 o Resolve URI IPv6zone-id vs. SMTP dcontent (make sure they allow 173 more or less the same things); compare with grammar in scoping- 174 arch (more or less no restrictions there?) 176 * IPv6zone-id = 1*( unreserved / sub-delims / ":" ) = unreserved 177 = ALPHA / DIGIT / "-" / "." / "_" / "~" , sub-delims = "!" / 178 "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" 180 * Atom = 1*atext = atext = ALPHA / DIGIT / ; Any character except 181 controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used 182 for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / 183 "_" / "`" / "{" / "|" / "}" / "~" 185 * dcontent = dtext/quoted-pair; dtext = NO-WS-CTL / ; Non white 186 space controls %d33-90 / ; The rest of the US-ASCII %d94-126 ; 187 characters not including "[", ; "]", or "\" 189 * scoping-arch just says "An implementation MAY support other 190 kinds [than numerical -wcf] of non-null strings as . 191 However, the strings must not conflict with the delimiter 192 character." 194 * 195 U = URI 196 S = SMTP Atom 197 A = scoping-arch 198 sp ! " # $ % & ' 199 A? ASU A AS ASU AS ASU ASU 200 ( ) * + , - . / 201 AU AU ASU ASU AU ASU AU AS 202 0 1 2 3 4 5 6 7 203 ASU ASU ASU ASU ASU ASU ASU ASU 204 8 9 : ; < = > ? 205 ASU ASU AU AU A ASU A AS 206 @ A B C D E F G 207 A ASU ASU ASU ASU ASU ASU ASU 208 H I J K L M N O 209 ASU ASU ASU ASU ASU ASU ASU ASU 210 P Q R S T U V W 211 ASU ASU ASU ASU ASU ASU ASU ASU 212 X Y Z [ \ ] ^ _ 213 ASU ASU ASU A A A AS ASU 214 ` a b c d e f g 215 AS ASU ASU ASU ASU ASU ASU ASU 216 h i j k l m n o 217 ASU ASU ASU ASU ASU ASU ASU ASU 218 p q r s t u v w 219 ASU ASU ASU ASU ASU ASU ASU ASU 220 x y z { | } ~ del 221 ASU ASU ASU AS AS AS ASU - 223 * so: we can't use SMTP Atom - use 1*dcontent. can we get away 224 with updating [RFC4007] to add something like zone-id = 225 1*(ALPHA / DIGIT / "-" / "." / "_" / "~" / "!" / "$" / "&" / 226 "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" / ":")? (This is 227 (I think) the expansion of IPv6zone-id; which is a superset of 228 dcontent.) 230 o Check with w3c URI 232 o Check with [who did Brian suggest in Paris?] 234 o Check with apps area 236 Appendix B. Change Log 238 B.1. Changes from -01 to -02 240 Changed "v6" to "v1", since the version number is of the literal 241 form, not of the address. 243 Changed "_" to "+", since an underscore disappears when underlined 244 as URLs are wont to be. 246 Added section on SMTP IPv6z: 248 Removed list of tradeoffs. 250 Authors' Addresses 252 Bill Fenner 253 AT&T Labs -- Research 254 75 Willow Rd 255 Menlo Park, California 94025 256 USA 258 Phone: +1 650-330-7893 259 Email: fenner@research.att.com 261 Martin Duerst 262 World Wide Web Consortium 263 5322 Endo 264 Fujisawa, Kanagawa 252-8520 265 Japan 267 Phone: +81 466 49 1170 268 Email: duerst@w3.org 270 Intellectual Property Statement 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org. 294 Disclaimer of Validity 296 This document and the information contained herein are provided on an 297 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 298 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 299 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 300 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 301 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 302 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 304 Copyright Statement 306 Copyright (C) The Internet Society (2005). This document is subject 307 to the rights, licenses and restrictions contained in BCP 78, and 308 except as set forth therein, the authors retain all their rights. 310 Acknowledgment 312 Funding for the RFC Editor function is currently provided by the 313 Internet Society.