idnits 2.17.1 draft-masinter-url-ipv6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 171 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (April 15, 1999) is 9115 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) == Missing Reference: 'RFC 2133' is mentioned on line 100, but not defined ** Obsolete undefined reference: RFC 2133 (Obsoleted by RFC 2553) == Unused Reference: 'RFC2133' is defined on line 115, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2133 (Obsoleted by RFC 2553) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Masinter, J. Gettys, B. Carpenter 2 draft-masinter-url-ipv6-02 3 Expires six months after publication date April 15, 1999 5 An ".ipv6" Top Level Pseudo-Domain 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as ``work in 21 progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Abstract 35 The normal textual representation for IPv6 addresses as a set 36 of colon-separated hexadecimal numbers does not work well with 37 most deployed URL-parsing software. This document describes an 38 alternate format which will pass unharmed through most URL-parsing 39 software. 41 1. Introduction 43 The normal textual representation for IPv6 addresses as a set of 44 colon-separated hexadecimal numbers does not work well with most 45 deployed URL-parsing software. This document describes an alternate 46 format which will pass unharmed through most URL-parsing software. 48 Rather than describing an alternative syntax for IPv6 49 addresses only within URLs, it proposes a pseudo-domain ".ipv6" 50 for using a domain-name-like syntax that actually represents 51 the literal IPv6 address. 53 2. Background 55 The standard representation for IPv6 addresses in text is defined 56 in section 2.2 of [RFC2373] ("Text Representation of Addresses"). 57 This representation uses hexadecimal values separated by colon ":", 58 double colon "::", and optionally ending period-separated decimal 59 values for the four low-order 8-bit pieces of the address. 61 Unfortunately, using this IPv6 syntax within URLs [RFC2396] would 62 be disruptive for many applications. Within the "hostport" section 63 of the generic URI syntax, the colon is used to separate the host 64 name or address from an (optional) port number. Thus, in some 65 addresses, a colon followed by a decimal number could ambiguously 66 be interpreted as a port designator or as a part of the IPv6 67 address. 69 Even if there were no ambiguity, this syntax is incompatible with a 70 many deployed applications that parse (but do not resolve) URLs, 71 including many CGI scripts, robots, search engines, and so forth. 73 3. Syntax 75 This specification defines a simple, safe representation for IPv6 76 addresses which can be used within URLs and also in other contexts. 77 It does so by defining a syntax which will look like a domain name 78 to otherwise unaware software. 80 The syntax is best described as a transformation of the 81 normal IPv6 syntax as defined in section 2.2 of [RFC2373]; 82 starting with such an address: 84 1) replace every colon ":" with a "-" 85 2) append ".ipv6" to the end 87 Thus, an HTTP service available at port 70 of IPv6 address 88 "ABCD:EF01::2345:10.9.8.7" could be written as 90 http://ABCD-EF01--2345-10.9.8.7.ipv6:70/ 92 This syntax should always be used. Internet software that resolves 93 host names and addresses in URLs should be modified to recognize 94 the "ipv6" pseudo-domain. 96 4. Implementation considerations 98 It would be useful for systems to uniformly recognize 99 the "ipv6" pseudo-domain throughout, e.g., as a special 100 case within "gethostbyname". [RFC 2133]. 102 5. IANA considerations 104 IANA is requested to reserve the "ipv6" top level pseudo-domain for 105 the purpose outlined in this memo. 107 6. References 109 [RFC2396] R. Fielding, L. Masinter, T. Berners-Lee, "Uniform Resource 110 Identifiers: Generic Syntax", August, 1998. 112 [RFC2373] R. Hinden, S. Deering. "IP Version 6 Addressing 113 Architecture", July, 1998. 115 [RFC2133] R. Gilligan, S. Thomson, J. Bound, W.Stevens. 116 "Basic Socket Interface Extensions for IPv6". 118 7. Authors' Addresses 120 Larry Masinter 121 Xerox Palo Alto Research Center 122 3333 Coyote Hill Road 123 Palo Alto, CA 94034, USA 124 Fax: +1 650 812 4365 125 EMail: masinter@parc.xerox.com 127 James Gettys 128 MIT Laboratory for Computer Science 129 545 Technology Square 130 Cambridge, MA 02139, USA 131 Fax: +1 617 258 8682 132 Email: jg@w3.org 134 Brian Carpenter 135 IBM United Kingdom Laboratories 136 MP 185, Hursley Park 137 Winchester, Hampshire SO21 2JN, UK 138 Email: brian@hursley.ibm.com 140 7. Full Copyright Statement 142 Copyright (C) The Internet Society (1999). All Rights Reserved. 144 This document and translations of it may be copied and furnished to 145 others, and derivative works that comment on or otherwise explain 146 it or assist in its implementation may be prepared, copied, 147 published and distributed, in whole or in part, without restriction 148 of any kind, provided that the above copyright notice and this 149 paragraph are included on all such copies and derivative works. 150 However, this document itself may not be modified in any way, such 151 as by removing the copyright notice or references to the Internet 152 Society or other Internet organizations, except as needed for the 153 purpose of developing Internet standards in which case the 154 procedures for copyrights defined in the Internet Standards process 155 must be followed, or as required to translate it into languages 156 other than English. 158 The limited permissions granted above are perpetual and will not be 159 revoked by the Internet Society or its successors or assigns. 161 This document and the information contained herein is provided on 162 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 163 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 164 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 165 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 166 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.