Internet Draft: A string encoding of Presentation Address      S. Kille
Document: draft-melnikov-rfc1278bis-02.txt                  A. Melnikov
Expires: May 2006                                             Isode Ltd.
Intended category: Standard Track                          November 2005
Obsoletes: RFC 1278 (if approved)

               A string encoding of Presentation Address

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.


   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

Kille                       Expires: May 2006                   [Page 1]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

   Editorial comments/questions or missing paragraphs are marked in the
   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

   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

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

Kille                       Expires: May 2006                   [Page 2]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

       containing network addresses and no selectors.

    o  Must deal with selectors in the following encodings:

       --  IA5

       --  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,
   IPv4address and reg-name non-terminals are defined in [RFC 3986].
   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

Kille                       Expires: May 2006                   [Page 3]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

   digitstring          = 1*DIGIT

   otherstring          = 1*other

   hexstring            = 1*hexoctet

   dotstring            = decimaloctet "." dotstring
                          / decimaloctet "." decimaloctet

   dothexstring         = dotstring / hexstring

   presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ]

   network-address-list = network-address network-addr-delimit network-address-list
                          / network-address

   network-addr-delimit = "_" / "|"

   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

Kille                       Expires: May 2006                   [Page 4]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

                          / "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
                            "+" 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               = reg-name | IPv4address | ipv6reference
                           ;  domain (e.g., or
                           ;  dotted decimal form of IPv4 address
                           ;  (e.g., or an IPv6 address
                           ;  (e.g., [1234::567f:890a:bcde])

   port                 = digitstring
                           ; 1-65535

   tset                 = digitstring

Kille                       Expires: May 2006                   [Page 5]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

   dte                  = digitstring

   cudf-or-pid          = "CUDF" / "PID"

   Six examples:







   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<<SHOULD?>> be used.

   <<Note, that the translation from a string encoding of a presentation
   address containing a DNS domain name to the binary representation is
   not reversible, as binary form of a network address can't store a DNS
   domain name, only an IP address of the domain name.>>

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 <network-
   address> can be parsed as:

   otherstring "=" *any

Kille                       Expires: May 2006                   [Page 6]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005


   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
   cause an infinite loop.  <<Do we need to say how many?>> 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

           |      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.


Kille                       Expires: May 2006                   [Page 7]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

           |      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+ |

6.  Acknowledgment

   This document is a revision of RFC 1278.

   David Wilson and Chris Ridd gave valuable suggestions 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.

Kille                       Expires: May 2006                   [Page 8]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

   [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.

   [NSAP-IPV6] Wilson, D., S. Kille and A. Melnikov, "Network Address to
   support OSI over IPv6", work in progress, draft-melnikov-nsap-

   [RFC 3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
   Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005.

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


   Alexey Melnikov (Editor)
   Isode Ltd.
   5 Castle Business Village,
   36 Station Road,
   Hampton, Middlesex,
   TW12 2BX, United Kingdom


11.   Full Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject

Kille                       Expires: May 2006                   [Page 9]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an


   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

   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-

13.   Appendix A. Changes since RFC 1278

   1) Updated boilerplate, copyright, IPR, etc.

   2) Updated contact information.

Kille                       Expires: May 2006                  [Page 10]

INTERNET DRAFT  A string encoding of Presentation Address  November 2005

   3) Updated references. Split references into Normative and

   4) Converted BNF to ABNF. Changed "ip" to "iphost", made it reference
      RFC 3986.

   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.

   10) Allow for "|" as a delimiter between network addresses, "_" is
       a typo in RFC 1278.

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: May 2006                  [Page 11]