Internet Draft: A string encoding of Presentation Address S. Kille Document: draft-melnikov-rfc1278bis-00.txt A. Melnikov Expires: March 2005 Isode Ltd. Intended category: Standard Track September 2004 Obsoletes: RFC 1278 (if approved) A string encoding of Presentation Address Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent directly to the authors. Distribution of this draft is unlimited. Abstract There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This is a revision of RFC 1278. This document also defines a string representation for IPv6 network addresses as defined in RFC 1888 and draft-melnikov-nsap-ipv6-XX.txt. 1. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Editorial comments/questions or missing paragraphs are marked in the Kille Expires: March 2005 [Page 1] INTERNET DRAFT A string encoding of Presentation Address September 2004 text with << and >>. 2. Introduction OSI Application Entities use presentation addresses to address other Application Entities. The model for this is defined in [ISO87b]. Presentation addresses are stored in the OSI Directory using an ASN.1 representation defined by the OSI Directory [CCI88]. Logically, a presentation address consists of: o A presentation selector o A session selector o A transport selector o A set of network addresses The selectors are all octet strings, but often have IA5 character representations. The format of network addresses is defined in [ISO87a]. There is a need to represent presentation addresses as strings in a number of different contexts. For example, in order to set up a connection system administrators often need to communicate Presentation addresses by email or other mechanisms, and having a common notation to write down Presentation addresses facilitates this communication. This document defines a format for use on the Internet. It is for display to human users, and its use is recommended whenever this needs to be done. Typically, this will be for system administrators rather than for end users. It is not intended for internal storage, however the note in section 4 gives an example when this might be advisable. 3. Requirements The main requirements are: o Must be able to specify any legal value. o Should be clean in the common case of the presentation address containing network addresses and no selectors. o Must deal with selectors in the following encodings: -- IA5 Kille Expires: March 2005 [Page 2] INTERNET DRAFT A string encoding of Presentation Address September 2004 -- Decimal digits encoded as IA5 (this is the most common syntax in Europe, as it is required by X.400(84) and should receive a straightforward encoding) -- Numeric encoded as a 16 bit unsigned integer (US GOSIP). This is mapped onto two octets, with the first octet being the high order byte of the integer (network byte order). -- General Hexadecimal o Should give special encodings for the ad hoc encoding proposed in "An interim approach to use of Network Addresses" [RFC1277]. -- TCP/IP Networks -- X.25(80) Networks o Should be extensible for additional forms. o Should provide a reasonably compact representation. o Should be human friendly. 4. Format The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. The 'IPv6address' and the 'IPv4address' are defined in [RFC 2373] and 'hostname' is defined in [RFC 2396]. Other non terminals not defined in this document are defined in Section 6.1 [ABNF] ("Core Rules"). other = ALPHA / DIGIT / "+" / "-" / "." any = other / ":" / "[" / "]" / "/" / "_" / '"' / <"> / "#" / "(" / ")" / "=" hexoctet = HEXDIG HEXDIG decimaloctet = DIGIT / DIGIT DIGIT / DIGIT DIGIT DIGIT ; 0 - 255, no leading 0 allowed digitstring = 1*DIGIT otherstring = 1*other hexstring = 1*hexoctet Kille Expires: March 2005 [Page 3] INTERNET DRAFT A string encoding of Presentation Address September 2004 dotstring = decimaloctet "." dotstring / decimaloctet "." decimaloctet dothexstring = dotstring / hexstring presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ] network-address-list network-address-list = network-address "_" network-address-list / network-address psel = selector ssel = selector tsel = selector selector = '"' otherstring '"' ; IA5 ; For characters not in this string use hex / "#" digitstring ; US GOSIP / "'" hexstring "'H" ; Hex / "" ; Empty but present network-address = "NS" "+" dothexstring ; Concrete Binary Representation ; This is the compact encoding / afi "+" idi [ "+" dsp ] ; A user oriented form / idp "+" hexstring ; ISO 8348 Compatibility idp = digitstring ; This is afi + idi dsp = "d" digitstring ; Abstract Decimal / "x" dothexstring ; Abstract Binary / "l" otherstring ; IA5: local form only / dsp_rfc1006 / "X.25(80)" "+" prefix "+" dte [ "+" cudf-or-pid "+" hexstring ] / "ECMA-117-Binary" "+" hexstring Kille Expires: March 2005 [Page 4] INTERNET DRAFT A string encoding of Presentation Address September 2004 "+" hexstring "+" hexstring / "ECMA-117-Decimal" "+" digitstring "+" digitstring "+" digitstring dsp_rfc1006 = "RFC-1006" "+" [prefix] "+" iphost [ "+" port [ "+" tset ]] ; The "tset" and the "prefix" MUST NOT be used ; with "IPV6ADDR" or "IPV6FULL" AFIs. ; ; The port MUST NOT be used with "IPV6ADDR" AFI. ; ; The "prefix" is REQUIRED for all other AFIs. idi = digitstring / "" ; IDI can be empty, e.g. for AFI "LOCAL" afi = "X121" / "DCC" / "TELEX" / "PSTN" / "ISDN" / "ICD" / "LOCAL" / ipv6_afi ipv6_afi = "IPV6ADDR" / "IPV6FULL" ; "IPV6ADDR" is AFI=35 as defined in section 6 ; of RFC 1888. ; "IPV6FULL" is for the AFI defined in ; draft-melnikov-nsap-ipv6-XX.txt ipv6reference = "[" IPv6address "]" prefix = DIGIT DIGIT iphost = hostname | IPv4address | ipv6reference ; domain (e.g., example.com) or ; dotted decimal form of IPv4 address ; (e.g., 10.0.0.6) or an IPv6 address ; (e.g., [1234::567f:890a:bcde]) port = digitstring ; 1-65535 tset = digitstring dte = digitstring cudf-or-pid = "CUDF" / "PID" Six examples: "256"/NS+a433bb93c1_NS+aa3106 Kille Expires: March 2005 [Page 5] INTERNET DRAFT A string encoding of Presentation Address September 2004 #63/#41/#12/X121+234219200300 '3a'H/TELEX+00728722+X.25(80)+02+00002340555+CUDF+"892796" TELEX+00728722+RFC-1006+03+10.0.0.6 IPV6FULL+0+RFC-1006++[1234::567:890a:bcde]+399 IPV6ADDR+0+RFC-1006++[1234::567:890a:bcde] Note that the dsp_rfc1006 non-terminal permits use of either a DNS Domain Name or an IP (IPv4 or IPv6) address. The former is primarily for ease of entry. If this DNS Domain Name maps onto multiple IP addresses, then multiple network addresses SHOULD be generated. When mapping from an encoded address to string form, the IP address form MUST<> be used. <> 4.1. Encoding Selectors are represented in a manner which can be easily encoded. In the NS notation, the concrete binary form of network address is given. Otherwise, this string notation provides a mechanism for representing the Abstract Syntax of a Network Address. This must be encoded according to Addendum 2 of ISO 8348 [ISO87a]. 5. Macros There are often common addresses, for which a cleaner representation is desired. This is achieved by use of Macros. If a can be parsed as: otherstring "=" *any where: macro_name = otherstring Then the leading string is taken as a Macro, which is substituted. (Note that macro names are case-insensitive.) This MUST be applied recursively. However, implementations MUST limit the maximal number of substitutions, as it is possible to construct a string that will Kille Expires: March 2005 [Page 6] INTERNET DRAFT A string encoding of Presentation Address September 2004 cause an infinite loop. <> When a macro substitution is performed, the longest available substitution MUST be used. For example: +-------+----------------+ | Macro | Value | +-------+----------------+ | UK.AC |DCC+826+d110000 | | Leeds |UK.AC=120 | +-------+----------------+ Then "Leeds=22" would be expanded to "DCC+826+d11000012022". 5.1. Standard Macros All implementations of this document MUST support the following macros: +-------------------+----------------------------+ | Macro | Value | +-------------------+----------------------------+ | ITOT-IPv4 |TELEX+00728722+RFC-1006+03+ | | ITOT-IPv6 |IPV6FULL+0+RFC-1006++ | | NS-IPv6 |IPV6ADDR+0+RFC-1006++ | +-------------------+----------------------------+ Note, that the "ITOT-IPv4" macro has the same value as the "Internet- RFC-1006" macro specified in the following section. 5.2. Obsoleted Macros The following macroses were specified in RFC 1278. They MAY be supported by implementations. +-------------------+----------------------------+ | Macro | Value | +-------------------+----------------------------+ | Int-X25(80) |TELEX+00728722+X25(80)+01+ | | Janet-X25(80) |TELEX+00728722+X25(80)+02+ | | Internet-RFC-1006 |TELEX+00728722+RFC-1006+03+ | | IXI |TELEX+00728722+RFC-1006+06+ | +-------------------+----------------------------+ Kille Expires: March 2005 [Page 7] INTERNET DRAFT A string encoding of Presentation Address September 2004 6. Acknowledgment This document is a revision of RFC 1278. David Wilson gave a valuable input on this revision of the document. 7. IANA Considerations <> 8. Security Considerations An implementation that supports conversion from a string encoding of Presentation Address into binary form, MUST be designed to guard itself from buffer overflows and MUST properly reject invalid input (including input that causes overflow). <> 9. References 9.1. Normative References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. <<[CCI88] The Directory --- overview of concepts, models and services, December 1988. CCITT X.500 Series Recommendations.>> [RFC1277] Kille, S., "Encoding network addresses to support operation over non-osi lower layers", RFC 1277, November 1991. [ISO87a] Information processing systems - data communications - network services definition: Addendum 2 - network layer addressing, March 1987. ISO TC 97/SC 6. [ISO87b] ISO DIS 7498-3 on naming and addressing, May 1987. ISO/IEC/JTC-1/SC 21. [RFC1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. Kille Expires: March 2005 [Page 8] INTERNET DRAFT A string encoding of Presentation Address September 2004 [NSAP-IPV6] Wilson, D., S. Kille and A. Melnikov, "Network Address to support OSI over IPv6", work in progress, draft-melnikov-nsap- ipv6-XX.txt. <<[RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.>> <> [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 9.2. Informative References [ITOT] Pouffary, Y. and A. Young, "ISO Transport Service on top of TCP (ITOT)", RFC 2126, March 1997. 10. Author's Address Steve Kille Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom EMail: Steve.Kille@isode.com Alexey Melnikov (Editor) Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom Email: Alexey.Melnikov@isode.com 11. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Kille Expires: March 2005 [Page 9] INTERNET DRAFT A string encoding of Presentation Address September 2004 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 12. Intellectual Property 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. 13. Appendix A. Changes since RFC 1278 1) Updated boilerplate, copyright, IPR, etc. 2) Updated contact information. 3) Updated references. Split references into Normative and Informative. Kille Expires: March 2005 [Page 10] INTERNET DRAFT A string encoding of Presentation Address September 2004 4) Converted BNF to ABNF. Changed "ip" to "iphost", made it reference RFC 2373. 5) Fixed "idi" to allow it to be an empty string. 6) Changed text to use MUST/SHOULDs. 7) Added support for IPv6. 8) Clarified that macro names are case-insensitive. 9) Added two new mandatory macros. 14. Appendix B. ToDo list. This appendix will be deleted before publication. 1) Rewrite/remove any text enclosed in <<>>. 2) Need to update ISO references. 3) Need to clarify where network byte order must be used. Kille Expires: March 2005 [Page 11]