idnits 2.17.1 draft-melnikov-rfc1278bis-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 453. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1278, but the abstract doesn't seem to directly say this. It does mention RFC1278 though, so this could be OK. 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 (November 2005) is 6737 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'CCI88' is mentioned on line 60, but not defined == Unused Reference: 'RFC1888' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'NSAP-IPV6' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'ITOT' is defined on line 389, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO87a' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO87b' ** Obsolete normative reference: RFC 1888 (Obsoleted by RFC 4048) -- No information found for draft-melnikov-nsap-ipv6-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NSAP-IPV6' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: A string encoding of Presentation Address S. Kille 3 Document: draft-melnikov-rfc1278bis-02.txt A. Melnikov 4 Expires: May 2006 Isode Ltd. 5 Intended category: Standard Track November 2005 6 Obsoletes: RFC 1278 (if approved) 8 A string encoding of Presentation Address 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 A revised version of this draft document will be submitted to the RFC 34 editor as a Proposed Standard for the Internet Community. Discussion 35 and suggestions for improvement are requested, and should be sent 36 directly to the authors. Distribution of this draft is unlimited. 38 Abstract 40 There are a number of environments where a simple string encoding of 41 Presentation Address is desirable. This specification defines such a 42 representation. This is a revision of RFC 1278. 44 This document also defines a string representation for IPv6 network 45 addresses as defined in RFC 1888 and draft-melnikov-nsap-ipv6-XX.txt. 47 1. Conventions Used in this Document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 52 Editorial comments/questions or missing paragraphs are marked in the 53 text with << and >>. 55 2. Introduction 57 OSI Application Entities use presentation addresses to address other 58 Application Entities. The model for this is defined in [ISO87b]. 59 Presentation addresses are stored in the OSI Directory using an ASN.1 60 representation defined by the OSI Directory [CCI88]. Logically, a 61 presentation address consists of: 63 o A presentation selector 65 o A session selector 67 o A transport selector 69 o A set of network addresses 71 The selectors are all octet strings, but often have IA5 character 72 representations. The format of network addresses is defined in 73 [ISO87a]. There is a need to represent presentation addresses as 74 strings in a number of different contexts. For example, in order to 75 set up a connection system administrators often need to communicate 76 Presentation addresses by email or other mechanisms, and having a 77 common notation to write down Presentation addresses facilitates this 78 communication. 80 This document defines a format for use on the Internet. It is for 81 display to human users, and its use is recommended whenever this 82 needs to be done. Typically, this will be for system administrators 83 rather than for end users. It is not intended for internal storage, 84 however the note in section 4 gives an example when this might be 85 advisable. 87 3. Requirements 89 The main requirements are: 91 o Must be able to specify any legal value. 93 o Should be clean in the common case of the presentation address 94 containing network addresses and no selectors. 96 o Must deal with selectors in the following encodings: 98 -- IA5 100 -- Decimal digits encoded as IA5 (this is the most common syntax 101 in Europe, as it is required by X.400(84) and should receive a 102 straightforward encoding) 104 -- Numeric encoded as a 16 bit unsigned integer (US GOSIP). This 105 is mapped onto two octets, with the first octet being the high 106 order byte of the integer (network byte order). 108 -- General Hexadecimal 110 o Should give special encodings for the ad hoc encoding proposed in 111 "An interim approach to use of Network Addresses" [RFC1277]. 113 -- TCP/IP Networks 115 -- X.25(80) Networks 117 o Should be extensible for additional forms. 119 o Should provide a reasonably compact representation. 121 o Should be human friendly. 123 4. Format 125 The following syntax specification uses the Augmented Backus-Naur 126 Form (ABNF) notation as specified in [ABNF]. The IPv6address, 127 IPv4address and reg-name non-terminals are defined in [RFC 3986]. 128 Other non terminals not defined in this document are defined in 129 Section 6.1 [ABNF] ("Core Rules"). 131 other = ALPHA / DIGIT / "+" / "-" / "." 133 any = other / ":" / "[" / "]" / "/" / "_" / '"' / <"> 134 / "#" / "(" / ")" / "|" / "=" 136 hexoctet = HEXDIG HEXDIG 138 decimaloctet = DIGIT / DIGIT DIGIT 139 / DIGIT DIGIT DIGIT 140 ; 0 - 255, no leading 0 allowed 142 digitstring = 1*DIGIT 144 otherstring = 1*other 146 hexstring = 1*hexoctet 148 dotstring = decimaloctet "." dotstring 149 / decimaloctet "." decimaloctet 151 dothexstring = dotstring / hexstring 153 presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ] 154 network-address-list 156 network-address-list = network-address network-addr-delimit network-address-list 157 / network-address 159 network-addr-delimit = "_" / "|" 161 psel = selector 163 ssel = selector 165 tsel = selector 167 selector = '"' otherstring '"' 168 ; IA5 169 ; For characters not in this string use hex 170 / "#" digitstring 171 ; US GOSIP 172 / "'" hexstring "'H" 173 ; Hex 174 / "" 175 ; Empty but present 177 network-address = "NS" "+" dothexstring 178 ; Concrete Binary Representation 179 ; This is the compact encoding 180 / afi "+" idi [ "+" dsp ] 181 ; A user oriented form 182 / idp "+" hexstring 183 ; ISO 8348 Compatibility 185 idp = digitstring 186 ; This is afi + idi 188 dsp = "d" digitstring 189 ; Abstract Decimal 191 / "x" dothexstring 192 ; Abstract Binary 193 / "l" otherstring 194 ; IA5: local form only 195 / dsp_rfc1006 196 / "X.25(80)" "+" prefix "+" dte 197 [ "+" cudf-or-pid "+" hexstring ] 198 / "ECMA-117-Binary" "+" hexstring 199 "+" hexstring "+" hexstring 200 / "ECMA-117-Decimal" "+" digitstring "+" 201 digitstring "+" digitstring 203 dsp_rfc1006 = "RFC-1006" "+" [prefix] "+" iphost 204 [ "+" port [ "+" tset ]] 205 ; The "tset" and the "prefix" MUST NOT be used 206 ; with "IPV6ADDR" or "IPV6FULL" AFIs. 207 ; 208 ; The port MUST NOT be used with "IPV6ADDR" AFI. 209 ; 210 ; The "prefix" is REQUIRED for all other AFIs. 212 idi = digitstring / "" 213 ; IDI can be empty, e.g. for AFI "LOCAL" 215 afi = "X121" / "DCC" / "TELEX" / "PSTN" / "ISDN" 216 / "ICD" / "LOCAL" / ipv6_afi 218 ipv6_afi = "IPV6ADDR" / "IPV6FULL" 219 ; "IPV6ADDR" is AFI=35 as defined in section 6 220 ; of RFC 1888. 221 ; "IPV6FULL" is for the AFI defined in 222 ; draft-melnikov-nsap-ipv6-XX.txt 224 ipv6reference = "[" IPv6address "]" 226 prefix = DIGIT DIGIT 228 iphost = reg-name | IPv4address | ipv6reference 229 ; domain (e.g., example.com) or 230 ; dotted decimal form of IPv4 address 231 ; (e.g., 10.0.0.6) or an IPv6 address 232 ; (e.g., [1234::567f:890a:bcde]) 234 port = digitstring 235 ; 1-65535 237 tset = digitstring 238 dte = digitstring 240 cudf-or-pid = "CUDF" / "PID" 242 Six examples: 244 "256"/NS+a433bb93c1_NS+aa3106 246 #63/#41/#12/X121+234219200300 248 '3a'H/TELEX+00728722+X.25(80)+02+00002340555+CUDF+"892796" 250 TELEX+00728722+RFC-1006+03+10.0.0.6 252 IPV6FULL+0+RFC-1006++[1234::567:890a:bcde]+399 254 IPV6ADDR+0+RFC-1006++[1234::567:890a:bcde] 256 Note that the dsp_rfc1006 non-terminal permits use of either a DNS 257 Domain Name or an IP (IPv4 or IPv6) address. The former is primarily 258 for ease of entry. If this DNS Domain Name maps onto multiple IP 259 addresses, then multiple network addresses SHOULD be generated. When 260 mapping from an encoded address to string form, the IP address form 261 MUST<> be used. 263 <> 268 4.1. Encoding 270 Selectors are represented in a manner which can be easily encoded. 271 In the NS notation, the concrete binary form of network address is 272 given. Otherwise, this string notation provides a mechanism for 273 representing the Abstract Syntax of a Network Address. This must be 274 encoded according to Addendum 2 of ISO 8348 [ISO87a]. 276 5. Macros 278 There are often common addresses, for which a cleaner representation 279 is desired. This is achieved by use of Macros. If a can be parsed as: 282 otherstring "=" *any 283 where: 285 macro_name = otherstring 287 Then the leading string is taken as a Macro, which is substituted. 288 (Note that macro names are case-insensitive.) This MUST be applied 289 recursively. However, implementations MUST limit the maximal number 290 of substitutions, as it is possible to construct a string that will 291 cause an infinite loop. <> When a macro 292 substitution is performed, the longest available substitution MUST be 293 used. For example: 295 +-------+----------------+ 296 | Macro | Value | 297 +-------+----------------+ 298 | UK.AC |DCC+826+d110000 | 299 | Leeds |UK.AC=120 | 300 +-------+----------------+ 302 Then "Leeds=22" would be expanded to "DCC+826+d11000012022". 304 5.1. Standard Macros 306 All implementations of this document MUST support the following 307 macros: 309 +-------------------+----------------------------+ 310 | Macro | Value | 311 +-------------------+----------------------------+ 312 | ITOT-IPv4 |TELEX+00728722+RFC-1006+03+ | 313 | ITOT-IPv6 |IPV6FULL+0+RFC-1006++ | 314 | NS-IPv6 |IPV6ADDR+0+RFC-1006++ | 315 +-------------------+----------------------------+ 317 Note, that the "ITOT-IPv4" macro has the same value as the "Internet- 318 RFC-1006" macro specified in the following section. 320 5.2. Obsoleted Macros 322 The following macroses were specified in RFC 1278. They MAY be 323 supported by implementations. 325 +-------------------+----------------------------+ 326 | Macro | Value | 327 +-------------------+----------------------------+ 328 | Int-X25(80) |TELEX+00728722+X25(80)+01+ | 329 | Janet-X25(80) |TELEX+00728722+X25(80)+02+ | 330 | Internet-RFC-1006 |TELEX+00728722+RFC-1006+03+ | 331 | IXI |TELEX+00728722+RFC-1006+06+ | 332 +-------------------+----------------------------+ 334 6. Acknowledgment 336 This document is a revision of RFC 1278. 338 David Wilson and Chris Ridd gave valuable suggestions on this 339 revision of the document. 341 7. IANA Considerations 343 <> 345 8. Security Considerations 347 An implementation that supports conversion from a string encoding of 348 Presentation Address into binary form, MUST be designed to guard 349 itself from buffer overflows and MUST properly reject invalid input 350 (including input that causes overflow). 352 <> 354 9. References 356 9.1. Normative References 358 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 359 Requirement Levels", RFC 2119, Harvard University, March 1997. 361 [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax 362 Specifications: ABNF", RFC 2234, November 1997. 364 <<[CCI88] The Directory --- overview of concepts, models and 365 services, December 1988. CCITT X.500 Series Recommendations.>> 367 [RFC1277] Kille, S., "Encoding network addresses to support operation 368 over non-osi lower layers", RFC 1277, November 1991. 370 [ISO87a] Information processing systems - data communications - 371 network services definition: Addendum 2 - network layer addressing, 372 March 1987. ISO TC 97/SC 6. 374 [ISO87b] ISO DIS 7498-3 on naming and addressing, May 1987. 375 ISO/IEC/JTC-1/SC 21. 377 [RFC1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. 378 and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. 380 [NSAP-IPV6] Wilson, D., S. Kille and A. Melnikov, "Network Address to 381 support OSI over IPv6", work in progress, draft-melnikov-nsap- 382 ipv6-XX.txt. 384 [RFC 3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 385 Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. 387 9.2. Informative References 389 [ITOT] Pouffary, Y. and A. Young, "ISO Transport Service on top of 390 TCP (ITOT)", RFC 2126, March 1997. 392 10. Author's Address 394 Steve Kille 395 Isode Ltd. 396 5 Castle Business Village, 397 36 Station Road, 398 Hampton, Middlesex, 399 TW12 2BX, United Kingdom 401 EMail: Steve.Kille@isode.com 403 Alexey Melnikov (Editor) 404 Isode Ltd. 405 5 Castle Business Village, 406 36 Station Road, 407 Hampton, Middlesex, 408 TW12 2BX, United Kingdom 410 Email: Alexey.Melnikov@isode.com 412 11. Full Copyright Statement 414 Copyright (C) The Internet Society (2005). This document is subject 415 to the rights, licenses and restrictions contained in BCP 78, and 416 except as set forth therein, the authors retain all their rights. 418 This document and the information contained herein are provided on an 419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 421 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 422 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 423 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Acknowledgement 428 Funding for the RFC Editor function is currently provided by the 429 Internet Society. 431 12. Intellectual Property 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed to 435 pertain to the implementation or use of the technology described in 436 this document or the extent to which any license under such rights 437 might or might not be available; nor does it represent that it has 438 made any independent effort to identify any such rights. Information 439 on the procedures with respect to rights in RFC documents can be 440 found in BCP 78 and BCP 79. 442 Copies of IPR disclosures made to the IETF Secretariat and any 443 assurances of licenses to be made available, or the result of an 444 attempt made to obtain a general license or permission for the use of 445 such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository at 447 http://www.ietf.org/ipr. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights that may cover technology that may be required to implement 452 this standard. Please address the information to the IETF at ietf- 453 ipr@ietf.org. 455 13. Appendix A. Changes since RFC 1278 457 1) Updated boilerplate, copyright, IPR, etc. 459 2) Updated contact information. 461 3) Updated references. Split references into Normative and 462 Informative. 464 4) Converted BNF to ABNF. Changed "ip" to "iphost", made it reference 465 RFC 3986. 467 5) Fixed "idi" to allow it to be an empty string. 469 6) Changed text to use MUST/SHOULDs. 471 7) Added support for IPv6. 473 8) Clarified that macro names are case-insensitive. 475 9) Added two new mandatory macros. 477 10) Allow for "|" as a delimiter between network addresses, "_" is 478 a typo in RFC 1278. 480 14. Appendix B. ToDo list. 482 This appendix will be deleted before publication. 484 1) Rewrite/remove any text enclosed in <<>>. 486 2) Need to update ISO references. 488 3) Need to clarify where network byte order must be used.