Internet DRAFT - draft-melnikov-rfc1278bis
draft-melnikov-rfc1278bis
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-
Drafts.
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/1id-abstracts.html
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
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",
"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
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
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-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., 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
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:
"256"/NS+a433bb93c1_NS+aa3106
#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<<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
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
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
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.
+-------------------+----------------------------+
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
<<TBD>>
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).
<<TBD>>
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-
ipv6-XX.txt.
[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
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 (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
"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.
Kille Expires: May 2006 [Page 10]
INTERNET DRAFT A string encoding of Presentation Address November 2005
3) Updated references. Split references into Normative and
Informative.
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]
