idnits 2.17.1 draft-masinter-url-ipv6-01.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 152 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. ** There is 1 instance of lines with control characters in the document. 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 (September 1, 1998) is 9363 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) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) Summary: 11 errors (**), 0 flaws (~~), 3 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-01 3 Expires six months after publication date September 1, 1998 5 Using IPv6 Addresses in URLs 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet-Drafts 17 as reference material or to cite them other than as ``work in 18 progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 23 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 24 Coast), or ftp.isi.edu (US West Coast). 26 Copyright Notice 28 Copyright (C) The Internet Society (1997). All Rights Reserved. 30 Abstract 32 The normal textual representation for IPv6 addresses as a set 33 of colon-separated hexadecimal numbers does not work well with 34 most deployed URL-parsing software. This document describes an 35 alternate format which will pass unharmed through most URL-parsing 36 software. 38 1. Introduction 40 The normal textual representation for IPv6 addresses as a set of 41 colon-separated hexadecimal numbers does not work well with most 42 deployed URL-parsing software. This document describes an alternate 43 format which will pass unharmed through most URL-parsing software. 45 2. Background 47 The standard representation for IPv6 addresses in text is defined 48 in section 2.2 of [RFC2373] ("Text Representation of Addresses"). 49 This representation uses hexadecimal values separated by colon ":", 50 double colon "::", and optionally ending period-separated decimal 51 values for the four low-order 8-bit pieces of the address. 53 Unfortunately, using this IPv6 syntax within URLs [RFC2396] would 54 be disruptive for many applications. Within the "hostport" section 55 of the generic URI syntax, the colon is used to separate the host 56 name or address from an (optional) port number. Thus, in some 57 addresses, a colon followed by a decimal number could ambiguously 58 be interpreted as a port designator or as a part of the IPv6 59 address. 61 Even if there were no ambiguity, this syntax is incompatible with a 62 many deployed applications that parse (but do not resolve) URLs, 63 including many CGI scripts, robots, search engines, and so forth. 65 3. Syntax 67 This specification defines a simple, safe representation for IPv6 68 addresses within URLs, by defining a syntax which will look like a 69 domain name to otherwise unaware software. 71 The syntax is best described as a transformation of the 72 normal IPv6 syntax as defined in section 2.2 of [RFC2373]; 73 starting with such an address: 75 1) replace every colon ":" with a "-" 76 2) append ".ipv6" to the end 78 Thus, an HTTP service available at port 70 of IPv6 address 79 "ABCD:EF01::2345:10.9.8.7" could be written as 81 http://ABCD-EF01--2345-10.9.8.7.ipv6:70/ 83 This syntax should always be used. Internet software that resolves 84 host names and addresses in URLs should be modified to recognize 85 the "ipv6" pseudo-domain. 87 4. IANA considerations 89 The Internet Assigned Names Authority is requested to reserve 90 the "ipv6" pseudo-domain for the purpose outlined in this memo. 92 5. References 94 [RFC2396] R. Fielding, L. Masinter, T. Berners-Lee, "Uniform Resource 95 Identifiers: Generic Syntax", August, 1998. 97 [RFC2373] R. Hinden, S. Deering. "IP Version 6 Addressing 98 Architecture", July, 1998. 100 6. Authors' Addresses 102 Larry Masinter 103 Xerox Palo Alto Research Center 104 3333 Coyote Hill Road 105 Palo Alto, CA 94034, USA 106 Fax: +1 650 812 4365 107 EMail: masinter@parc.xerox.com 109 James Gettys 110 MIT Laboratory for Computer Science 111 545 Technology Square 112 Cambridge, MA 02139, USA 113 Fax: +1 617 258 8682 114 Email: jg@w3.org 116 Brian Carpenter 117 IBM United Kingdom Laboratories 118 MP 185, Hursley Park 119 Winchester, Hampshire SO21 2JN, UK 120 Email: brian@hursley.ibm.com 122 7. Full Copyright Statement 124 Copyright (C) The Internet Society (1997). All Rights Reserved. 126 This document and translations of it may be copied and furnished to 127 others, and derivative works that comment on or otherwise explain 128 it or assist in its implementation may be prepared, copied, 129 published and distributed, in whole or in part, without restriction 130 of any kind, provided that the above copyright notice and this 131 paragraph are included on all such copies and derivative works. 132 However, this document itself may not be modified in any way, such 133 as by removing the copyright notice or references to the Internet 134 Society or other Internet organizations, except as needed for the 135 purpose of developing Internet standards in which case the 136 procedures for copyrights defined in the Internet Standards process 137 must be followed, or as required to translate it into languages 138 other than English. 140 The limited permissions granted above are perpetual and will not be 141 revoked by the Internet Society or its successors or assigns. 143 This document and the information contained herein is provided on 144 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 145 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 146 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 147 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 148 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.