Network Working Group S.E. Kille INTERNET--DRAFT University College London November 1990 A string encoding of Presentation Address Status of this Memo There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET--DRAFT String encoded P-Address November 1990 1 Introduction There is a need to represent presentation addresses as strings in a number of different contexts. This Internet Draft defines one possible format. This Internet Draft was originally published as UCL Resarch Note RN/89/14 [Kil89b]. 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 no selectors o Needs to deal with selectors in the following encodings: -- IA5 -- Digits encoded as IA5 (this is the most common syntax in Europe, as it is required by X.400(84) and should receive an optimal encoding) -- Numeric encoded as 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'' [Kil89a]. -- X.25(80) Networks -- TCP/IP Networks o Should be extensible for additional forms Kille Page 1 INTERNET--DRAFT String encoded P-Address November 1990 o Should provide a compact representation (e.g., for use in a TSEL encoding). 3 Format The_BNF_is_given_in_figure_1.______________________________________ ::= [0-9] ::= [0-9a-zA-Z+-.] ::= [0-9a-zA-Z-.] ::= [0-9a-fA-F] ::= ::= | | ::= 10 | ::= | ::= | ::= | ::= "." | "." 20 ::= | ::= [[[ "/" ] "/" ] "/" ] ::= "_" 30 | ::= ::= ::= ::= '"' '"' -- IA5 -- For chars not in this Kille Page 2 INTERNET--DRAFT String encoded P-Address November 1990 -- string use hex | "#" -- US GOSIP 40 | "'" "'H" -- Hex | "" -- Empty but present ::= "NS" "+" -- Concrete Binary Representation -- This is the compact encoding | "+" [ "+" ] -- A user oriented form | "+" -- ISO 8348 Compatability 50 ::= - ::= | "d" -- Abstract Decimal | "x" -- Abstract Binary | "l" -- IA5: local form only | "RFC-1006" "+" "+" [ "+" [ "+" ]] | "X.25(80)" "+" "+" 60 [ "+" "+" ] | "ECMA-117-Binary" "+" "+" "+" | "ECMA-117-Decimal" "+" "+" "+" ::= ::= "X121" | "DCC" | "TELEX" | "PSTN" | "ISDN" | "ICD" | "LOCAL" 70 ::= ::= -- dotted decimal form (e.g., 10.0.0.6) -- or domain (e.g., twg.com) ::= ::= ::= ::= "CUDF" | "PID" 80 _______________________Figure_1:__String_BNF_______________________ Kille Page 3 INTERNET--DRAFT String encoded P-Address November 1990 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 domain or IP address. The former is primarily for ease of entry. If this domain maps onto multiple IP addresses, then multiple network addresses should be generated. When mapping from an encoded address to string form, the reverse mapping (dotted quad to domain) should not 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 [ISO87]. 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: "=" *( 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: Kille Page 4 INTERNET--DRAFT String encoded P-Address November 1990 ________________________ |_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. ________________________________________________ |_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+_| 7 References References [ISO87] Information processing systems - data communications - network services definition: Addendum 2 - network layer addressing, March 1987. ISO TC 97/SC 6. [Kil89a] S.E. Kille. An interim approach to use of network addresses. Research Note RN/89/13, Department of Computer Science, University College London, February 1989. Internet Draft: DRAFT-UCL-KILLE-NETWORKADDRESSES-00.PS.1. [Kil89b] S.E. Kille. A string encoding of presentation address. Research Note RN/89/14, Department of Computer Science, University College London, February 1989. Internet Draft: DRAFT-UCL-KILLE-PRESENTATIONADDRESSES-00.PS.1. 8 Security Considerations Security considerations are not discussed in this INTERNET--DRAFT . 9 Author's Address Steve Kille Kille Page 5 INTERNET--DRAFT String encoded P-Address November 1990 Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK Kille Page 6