Codage de chaîne d'adresse de présentation

Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Résumé

Il y a un certain nombre d'environnements dans lesquels un simple codage de chaîne d'adresse de présentation est souhaitable. La présente spécification définit une telle représentation.

1. Introduction

Les entités d'application OSI utilisent les adresses de présentation pour s'adresser aux autres entités d'application. Le modèle en est défini dans [ISO87b]. Les adresses de présentation sont mémorisées dans le répertoire OSI en utilisant une représentation en ASN.1 définie par le répertoire OSI [CCI88]. Logiquement, une adresse de présentation consiste en :

o Un sélecteur de présentation

o Un sélecteur de session

o Un sélecteur de transport

o Un ensemble d'adresses réseau

Les sélecteurs sont tous des chaînes d'octets, mais elles ont souvent des représentations en caractères IA5. Le format des adresses réseau est défini dans [ISO87a]. Il est nécessaire de représenter les adresses de présentation comme des chaînes dans un certain nombre de contextes différents. Le présent projet Internet définit un format à utiliser sur l'Internet. Il est destiné à l'affichage à l'utilisateur humain, et son utilisation est recommandée chaque fois que ce besoin se manisfeste. Normalement, ce sera pour le gestionnaire de système plus que pour l'utilisateur final. Il n'est pas destiné à la mémorisation interne.

Ce projet Internet a été d'abord été publié comme note de recherche UCL RN/89/14 [Kil89]. Il a été accepté comme syntaxe unifiée pour les projets THORN et ISODE. Il est utilisé dans tout ISODE. Christian Huitema de l'Inria et Marshall Rose de PSI Inc. ont fait des contributions utiles au présent document.

2. Exigences

Les principales exigences sont :

o Doit être capable de spécifier toute valeur légale.

o Devrait être propre dans le cas courant de l'adresse de présentation qui contient des adresses réseau et pas de sélecteur.

o Doit traiter avec les sélecteurs dans les codages suivants :

-- IA5

-- Chiffres décimaux codés comm de l'IA5 (c'est la syntaxe la plus courante en Europe, car elle est requise par X.400(84) et devrait recevoir un codage direct)

-- Nombre codé comme entier non signé de 16 bits (US GOSIP). Ceci est transposé sur deux octets, le premier étant l'octet de poids fort de l'entier.

-- Hexadécimal général

o Devrait donner des codages spéciaux pour le codage ad hoc proposé dans "Approche intérmédiaire de l'utilisation des adresses réseau'' [HK91].

-- Réseaux X.25(80)

-- Réseaux TCP/IP

o Devrait être extensible à des formes supplémentaires.

o Devrait fournir une représentation raisonnablement compacte.

3. Format

Le BNF est donnée à la 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> | <digit> 10

<otherstring> ::= <other> <otherstring> | <other>

<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>| <network-address> 30

<psel> ::= <selector>

<ssel> ::= <selector>

<tsel> ::= <selector>

<selector> ::= '"' <otherstring> '"' -- IA5

-- Pour les caractères qui ne sont pas dans cette chaîne, utiliser hex

| "#" <digitstring> -- US GOSIP 40

| "'" <hexstring> "'H" -- Hex

| "" -- Vide mais présent

<network-address> ::= "NS" "+" <dothexstring>

-- Représentation binaire concrète

-- C'est le codage compact

| <afi> "+" <idi> [ "+" <dsp> ]

-- Forme en mode utilisateur

| <idp> "+" <hexstring>

-- Compatibilité ISO 8348 50

<idp> ::= <digitstring> -

<dsp> ::=

| "d" <digitstring> -- Décimal abstrait

| "x" <dothexstring> -- Bianire abstrait

| "l" <otherstring> -- IA5 : seulement forme locale

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

-- forme décimale séparée par des points (par exemple, 10.0.0.6)

-- ou domainr (par exemple, twg.com)

<port> ::= <digitstring>

<tset> ::= <digitstring>

<dte> ::= <digitstring>

<cudf-or-pid> ::= "CUDF" | "PID" 80

Figure 1 : Chaîne BNF

Quatre exemples :

"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

Noter que le codage de la RFC1006 permet l'utilisation aussi bien d'un nom de domaine du DNS que d'une adresse IP. Le premier est principalement pour faciliter l'entrée. Si ce nom de domaine DNS se transpose en plusieurs adresses IP, plusieurs adresses réseau devraient alors être générées. La forme nom de domaine du DNS est pour rendre l'entrée plus pratique. Lorsque on transpose d'une adresse codée en forme de chaîne, la forme adresse IP devrait toujours être utilisée.

4. Codage

Les sélecteurs sont représentés d'une manière qui peut aisément être codée. Dans la notation NS, on donne la forme binaire concrète de l'adresse réseau. Autrement, cette notation de chaîne donne un mécanisme pour représenter la syntaxe abstraite d'une adresse réseau. Cela doit être codé conformément à l'addendum 2 de la norme ISO 8348 [ISO87a].

5. Macros

Il y a souvent des adresses communes, pour lesquelles on souhaite une représentation plus propre. Cela se réalise en utilisant des macros. Si une <adresse-réseau> peut être analysée comme :

<otherstring> "=" *( any )

la chaîne en tête est prise comme macro, et elle s'y substitue. Cela peut être appliqué de façon récurrente. Lors de la présentation d'une adresse réseau à un lecteur humain, la substitution la plus longue disponible devrait être utilisée. Par exemple :

________________________

|_Macro_|Valeur__________ |

| UK.AC |DCC+826+d110000 |

|_Leeds_|UK.AC=120______ |

"Leeds=22'' serait alors étendu en "DCC+826+d11000012022''.

6. Macros Standard

On ne devrait jamais s'appuyer sur aucune macro. Cependant, ce qui suit est suggéré comme standard.

________________________________________________

|_Macro_____________|Valeur______________________ |

| 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. Références

[CCI88] Recommendation CCITT X.500, "L'annuaire --- Vue générale des concepts, modèles et services", décembre 1988.

[HK91] S. Hardcastle-Kille, "Codage des adresses réseau pour prendre en charge le fonctionnement sur des couches inférieures non OSI", RFC1277, novembre 1991. (PS)

[ISO87a] ISO TC 97/SC 6, "Systèmes de traitement de l'information - communications de données – définition des services réseau : Addendum 2 – adressage de couche réseau", mars 1987.

[ISO87b] ISO/IEC/JTC-1/SC 21, DIS 7498-3 "Désignation et adressage", mai 1987.

[Kil89] S.E. Kille, "A string encoding of presentation address", Note de recherche RN/89/14, Department of Computer Science, University College London, février 1989.

8. Considérations pour la sécurité

Les considérations de sécurité ne sont pas abordées dans le présent mémoire.

9. Adresse de l'auteur

Steve Hardcastle-Kille

Department of Computer Science

University College London

Gower Street

WC1E 6BT

England

téléphone : +44-71-380-7294

mél : S.Kille@CS.UCL.AC.UK