String P-Address: A string encoding of Presentation Address
A plain-text way to write down an OSI presentation address so a person can read and type it.
Hardcastle-Kille, S.E., "A string encoding of Presentation Address", RFC 1278, DOI 10.17487/RFC1278, November 1991, <https://www.rfc-editor.org/info/rfc1278>.
@misc{rfc1278,
series = {Request for Comments},
number = 1278,
howpublished = {RFC 1278},
publisher = {RFC Editor},
doi = {10.17487/RFC1278},
url = {https://www.rfc-editor.org/info/rfc1278},
author = {S.E. Hardcastle-Kille},
title = {{A string encoding of Presentation Address}},
pagetotal = 7,
year = 1991,
month = nov,
} RFC text
Contents
Network Working Group S.E. Hardcastle-Kille
Requests for Comments 1278 University College London
November 1991
A string encoding of Presentation Address
Status of this Memo
This memo provides information for the Internet community. It
does not specify an Internet standard. Distribution of this memo
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.
1 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. This Internet Draft 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 managers rather than for end users. It is not
intended for internal storage.
This Internet Draft was originally published as UCL Research Note
RN/89/14 [Kil89]. It was agreed as a unified syntax for the THORN and
ISODE projects. It is used throughout ISODE.
Christian Huitema of Inria and Marshall Rose of PSI Inc. gave much
useful input to this document.
2 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.
Hardcastle-Kille Page 1
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.
-- General Hexadecimal
o Should give special encodings for the ad hoc encoding proposed in
``An interim approach to use of Network Addresses'' [HK91].
-- X.25(80) Networks
-- TCP/IP Networks
o Should be extensible for additional forms.
o Should provide a reasonably compact representation .
3 Format
The_BNF_is_given_in_figure_1.__________________________________________
<digit> ::= [0-9]
<other> ::= [0-9a-zA-Z+-.]
<domainchar> ::= [0-9a-zA-Z-.]
<hexdigit> ::= [0-9a-fA-F]
<hexoctet> ::= <hexdigit> <hexdigit>
<decimaloctet> ::= <digit> | <digit> <digit>
| <digit> <digit> <digit>
<digitstring> ::= <digit> <digitstring> 10
| <digit>
<otherstring> ::= <other> <otherstring>
| <other>
Hardcastle-Kille Page 2
<domainstring> ::= <domainchar> <otherstring>
| <domainchar>
<hexstring> ::= <hexoctet> <hexstring> | <hexoctet>
<dotstring> ::= <decimaloctet> "." <dotstring>
| <decimaloctet> "." <decimaloctet>
20
<dothexstring> ::= <dotstring> | <hexstring>
<presentation-address> ::=
[[[ <psel> "/" ] <ssel> "/" ] <tsel> "/" ]
<network-address-list>
<network-address-list> ::= <network-address> "_" <network-address-list>30
| <network-address>
<psel> ::= <selector>
<ssel> ::= <selector>
<tsel> ::= <selector>
<selector> ::= '"' <otherstring> '"' -- IA5
-- For chars not in this
-- string use hex
| "#" <digitstring> -- US GOSIP 40
| "'" <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 Compatability 50
<idp> ::= <digitstring> -
<dsp> ::=
| "d" <digitstring> -- Abstract Decimal
| "x" <dothexstring> -- Abstract Binary
| "l" <otherstring> -- IA5: local form only
Hardcastle-Kille Page 3
| "RFC-1006" "+" <prefix> "+" <ip>
[ "+" <port> [ "+" <tset> ]]
| "X.25(80)" "+" <prefix> "+" <dte> 60
[ "+" <cudf-or-pid> "+" <hexstring> ]
| "ECMA-117-Binary" "+" <hexstring> "+" <hexstring>
"+" <hexstring>
| "ECMA-117-Decimal" "+" <digitstring> "+"
<digitstring> "+" <digitstring>
<idi> ::= <digitstring>
<afi> ::= "X121" | "DCC" | "TELEX" | "PSTN" | "ISDN"
| "ICD" | "LOCAL"
70
<prefix> ::= <digit> <digit>
<ip> ::= <domainstring>
-- dotted decimal form (e.g., 10.0.0.6)
-- or domain (e.g., twg.com)
<port> ::= <digitstring>
<tset> ::= <digitstring>
<dte> ::= <digitstring>
<cudf-or-pid> ::= "CUDF" | "PID" 80
________________________Figure_1:__String_BNF__________________________
Four 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
Note that the RFC 1006 encoding permits use of either a DNS Domain
Name or an IP 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. The DNS Domain Name form is
Hardcastle-Kille Page 4
for convenient input. When mapping from an encoded address to string
form, the IP address form should always be used.
4 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 )
Then the leading string is taken as a Macro, which is substituted.
This may be applied recursively. When presenting Network Address to
humans, the longest available substitution should 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''.
6 Standard Macros
No Macros should ever be relied on. However, the following are
suggested as standard.
Hardcastle-Kille Page 5
________________________________________________
|_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+_|
7 References
References
[CCI88] The Directory --- overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[HK91] S.E. Hardcastle-Kille. Encoding network addresses to support
operation over non-osi lower layers. Request for Comments
RFC 1277, Department of Computer Science, University College
London, 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.
[Kil89] S.E. Kille. A string encoding of presentation address.
Research Note RN/89/14, Department of Computer Science,
University College London, February 1989.
8 Security Considerations
Security considerations are not discussed in this memo.
9 Author's Address
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
Hardcastle-Kille Page 6
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille Page 7
ISO Plain Language
On this page
§1Why a String Form
OSI Application Entities use presentation addresses to address other Application Entities, and the model for this comes from the ISO reference on naming and addressing. Logically, a presentation address consists of a presentation selector, a session selector, a transport selector and a set of network addresses. The selectors are all octet strings, but they often have IA5 character representations. The format of the network addresses is defined in the ISO network services reference.
The OSI Directory stores these addresses using an ASN.1 representation. RFC 1278 adds a string encoding for the many contexts that need one. The memo says it is for display to human users, typically system managers rather than end users, and that its use is recommended whenever this needs to be done. It is not intended for internal storage.
The syntax was originally published as a University College London research note and was agreed as a unified syntax for the THORN and ISODE projects. It is used throughout ISODE.
An address is normally stored as a bundle of structured data. This memo gives it a written form that a person can read and type without special software.
§2What the Format Must Do
The format must be able to specify any legal value. It must also deal with selectors in four encodings: IA5, decimal digits encoded as IA5, a number encoded as a 16 bit unsigned integer (US GOSIP), and general hexadecimal. Decimal digits as IA5 is the most common syntax in Europe, because X.400(84) requires it, and the memo says it should receive a straightforward encoding. The US GOSIP number is mapped onto two octets, with the first octet being the high order byte of the integer.
The format should be clean in the common case, where a presentation address holds network addresses and no selectors. It should give special encodings for the ad hoc encoding proposed in RFC 1277 for X.25(80) networks and TCP/IP networks, should be extensible for additional forms, and should provide a reasonably compact representation.
The text format has to be able to write every possible address, keep the usual simple case tidy, and leave room for new kinds of address later.
§3The String Syntax
A presentation address string has up to three selectors, each followed by a slash, and then a list of network addresses. The selectors appear in the order presentation, session and transport. The leading ones may be left out: a transport selector on its own is allowed, but a session selector needs a transport selector as well. Several network addresses are joined with an underscore.
A selector is written in one of four ways: a quoted IA5 string, where characters outside that string are written in hex; a hash sign followed by decimal digits, which is US GOSIP; a hex string in single quotes followed by H; or nothing at all, meaning empty but present.
A network address has three forms. NS+ followed by a dotted decimal or hex string is the compact concrete binary form. The user oriented form is an afi, an idi and an optional dsp, where the afi is one of X121, DCC, TELEX, PSTN, ISDN, ICD or LOCAL. The third form is a digit string plus a hex string, for compatibility with ISO 8348. The dsp part can be abstract decimal (d), abstract binary (x), local IA5 (l), or one of the special forms RFC-1006, X.25(80), ECMA-117-Binary and ECMA-117-Decimal.
The RFC-1006 form takes either a dotted decimal IP address or a DNS domain name. The domain name is there for ease of entry. If the 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 should always be used.
The address is written left to right: optional labels for the program, then the machine address itself. Several machine addresses can be joined with an underscore when one place has more than one.
- "text"IA5 — A quoted string of allowed characters; write other characters in hex.
- #123US GOSIP — A hash sign and decimal digits, mapped onto two octets.
- '3a'HHex — Hex digits in single quotes followed by H.
- (nothing)Empty but present — The selector is there and has no characters.
§4Encoding and Example Addresses
Section 4 explains what the two notations mean. In the NS notation, the concrete binary form of a network address is given. Otherwise the string notation provides a mechanism for representing the abstract syntax of a network address, and that abstract syntax must be encoded according to Addendum 2 of ISO 8348.
Figure 1 gives the grammar, and four example addresses follow it. The first has one transport selector and two network addresses. The second has all three selectors written in US GOSIP form, followed by an X.121 address. The third mixes a hex selector with a TELEX address that carries an X.25(80) part. The fourth is a bare RFC 1006 address with no selectors at all, which shows the clean common case the requirements ask for.
These are four sample addresses, from a simple one with no labels to a longer one with every part filled in.
"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§5Macros for Common Addresses
Some addresses recur often enough to deserve a short name, and the memo calls these macros. If a network address can be parsed as a string, then =, then anything else, the leading string is taken as a macro and substituted for. Substitution may be applied recursively. When a network address is presented to people, the longest available substitution should be used.
The example in the memo is a two-level table. UK.AC stands for DCC+826+d110000, and Leeds stands for UK.AC=120 with more characters. Under that scheme, Leeds=22 expands to DCC+826+d11000012022.
The memo warns that no macro should ever be relied on, but it suggests four as standard: Int-X25(80), Janet-X25(80), Internet-RFC-1006 and IXI. Each expands to a TELEX prefix followed by an X.25(80) or RFC-1006 part.
A macro is a nickname for a long piece of an address. The computer swaps the nickname for the full text when it needs the full text.
§8Security Considerations
The memo states only that security considerations are not discussed. The string format is a notation for people to read, so it defines no protections of its own.
The memo does not discuss safety. It is only about how to write an address down.