SOAP Version 1.2 Partie 1: Structure pour l'échange de messages

1.1 Conventions de notation

Les mots-clés "DOIT" ("MUST"), "NE DOIT PAS" ("MUST NOT"), "OBLIGATOIRE" ("REQUIRED"), "DEVRA" ("SHALL"), "NE DEVRA PAS" ("SHALL NOT"), "DEVRAIT" ("SHOULD"), "NE DEVRAIT PAS" ("SHOULD NOT"), "RECOMMANDÉ" ("RECOMMENDED"), "POURRAIT" ("MAY") et "OPTIONNEL" ("OPTIONAL") dans ce document sont à interpréter comme décrit dans la RFC 2119 [RFC 2119].

Cette spécification utilise un certain nombre de préfixes d'espaces de nommage ; ils sont répertoriés dans Table 1. Notez que le choix de tout préfixe d'espace de nommage est arbitraire et n'a pas de sémantique (voir InfoSet XML [XML InfoSet]).

Les noms d'espaces de nommage de la forme générale "http://example.org/..." et "http://example.com/..." représentent des URIs dépendantes d'une application ou d'un contexte (voir la RFC 2396 [RFC 2396]).

Toute partie de cette spécification est normative, à l'exception des exemples et des sections explicitement marquées comme "non normatifs".

1.2 Règles de conformité

Cette spécification décrit des formats de données ainsi que des règles pour générer, échanger et traiter des messages en utilisant ces formats. Cette spécification n'impose aucune portée d'une implémentation en particulier, bien qu'elle requiert des implémentations de ne violer aucune des clauses obligatoires.

Pour qu'une implémentation déclare sa conformité avec la spécification SOAP Version 1.2, elle DOIT correctement implémenter toutes les clauses obligatoires ("DOIT") exprimées dans la partie 1 de la spécification SOAP Version 1.2 (ce document) appartenant à l'activité effectuée. Notez qu'une implémentation n'est pas obligée d'implémenter toutes les clauses obligatoires. Par exemple, une implémentation dédiée qui n'envoie jamais un bloc d'en-tête SOAP peut se déclarer conforme pourvu qu'elle implémente correctement les clauses obligatoires appartenant aux messages qu'elle envoie.

Une implémentation POURRAIT implémenter un nombre quelconque des Ajouts spécifiés dans la partie 2 de SOAP 1.2 [SOAP Partie 2]. Notez qu'aucune règle de conformité n'est associée à la convention de description de caractéristiques et de liaisons (voir 3. Modèle d'extensibilité de SOAP et 4. Structure pour une liaison SOAP sur un protocole). L'implémentation d'un Ajout DOIT implémenter toutes les clauses obligatoires applicables exprimées dans la spécification des Ajouts pour se déclarer conforme avec cet Ajout.

SOAP Version 1.2 peut être utilisé comme base pour d'autres technologies fournissant des services plus riches ou plus spécialisés. Pour se déclarer conforme à la spécification SOAP Version 1.2, les spécifications et implémentations de telles technologies doivent être cohérentes avec les clauses obligatoires applicables exprimées dans la partie 1 de la spécification SOAP Version 1.2 (ce document). Les règles de conformité de ces nouvelles spécifications sont au-delà de la portée de la spécification SOAP Version 1.2 ; il est recommandé que les spécifications de telles technologies fournissent les règles de conformité appropriées.

SOAP Version 1.2 est conçu pour permettre au moins les scénarios d'utilisation décrits dans les Scenarios d'Utilisation SOAP 1.2 (Usage Scenarios) [SOAP Usage Scenarios] et éventuellement d'autres. Des descriptions informelles de représentations en XML de messages SOAP concrets utilisés dans des scénarios courants sont fournis dans la partie 0 de SOAP 1.2 [SOAP Partie 0].

1.3 Relations avec d'autres spécifications

Un message SOAP est spécifié comme un Ensemble d'Information XML (Infoset XML) [XML InfoSet]. Si tous les exemples de messages SOAP de ce document sont donnés dans la syntaxe XML 1.0 [XML 1.0], d'autres représentations POURRAIENT être utilisées pour transmettre des messages SOAP entre noeuds (voir 4. Structure pour une liaison SOAP sur un protocole).

Certains des items d'information définis par ce document (voir 5. Construction de message SOAP) sont identifiés grâce à un des [Namespaces in XML] noms qualifiés dans un espace de nommage XML. Voir Table 1 pour une liste des noms d'espaces de nommage définis dans ce document.

SOAP ne requiert pas de traitement (évaluation ou validation) du Schéma XML pour établir l'exactitude ou les valeurs 'déduites du Schéma' d'items d'information éléments ou attributs définis par les parties 1 et 2 de cette spécification. Les valeurs associées à des items d'information éléments et attributs définis dans cette spécification DOIVENT être explicitement transportées dans le message SOAP transmis sauf indication contraire (voir 5. Construction de message SOAP).

Les items d'information attributs SOAP ont des types décrits par XML Schema [XML Schema Partie 2]. Sauf indication contraire, toutes les formes lexicales représentant la même valeur dans l'espace de valeurs du Schéma XML sont considérées équivalentes pour le traitement SOAP, par exemple les formes booléennes "1" et "true" (vrai) sont interchangeables. Pour abréger, le texte de cette spécification ne fait référence qu'à une forme lexicale pour chaque valeur, par exemple "si la valeur de l'item d'information attribut mustUnderstand est 'true' (vrai)".

Les spécifications pour le traitement de données applicatives transportées dans un message SOAP mais non définies dans cette spécification POURRAIENT amener à une validation supplémentaire du message SOAP, en conjonction avec le traitement du niveau applicatif. Dans ce cas, le choix du langage de schéma et/ou de la technologie de validation est à l'appréciation de l'application.

SOAP utilise XML Base [XML Base] pour déterminer une URI de base pour les références à des URIs relatives utilisées comme valeurs dans des items d'information définis dans cette spécification (voir 6. Utilisation d'URIs dans SOAP).

Le type de média "application/soap+xml" [soap-media-type] DEVRAIT être utilisé pour les sérialisations XML 1.0 d'infoset de message SOAP (voir dans la partie 2 de SOAP 1.2 [SOAP Partie 2], Le Type de Media "application/soap+xml").

1.4 Exemple de message SOAP

L'exemple suivant montre un message de notification exprimé en SOAP. Le message contient deux données définies par l'application et non par cette spécification : Un bloc d'en-tête SOAP avec un nom local alertcontrol et un élément corps avec un nom local alert . En général, les blocs d'en-tête SOAP contiennent des informations pouvant être utiles à des intermédiaires SOAP aussi bien qu'au destinataire final du message. Dans cet exemple, un intermédiaire peut réordonner la livraison du message en fonction de la priorité et de la date d'expiration du bloc d'en-tête SOAP. Le corps contient la vraie charge du message, dans le cas présent le message d'alerte.

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Header>
  <n:alertcontrol xmlns:n="http://example.org/alertcontrol">
   <n:priority>1</n:priority>
   <n:expires>2001-06-22T14:00:00-05:00</n:expires>
  </n:alertcontrol>
 </env:Header>
 <env:Body>
  <m:alert xmlns:m="http://example.org/alert">
   <m:msg>Pick up Mary at school at 2pm</m:msg>
  </m:alert>
 </env:Body>
</env:Envelope>

1.5 Terminologie SOAP

Cette section décrit les termes et concepts introduits dans la partie 1 de la spécification SOAP Version 1.2 (ce document).

2.1 Noeuds SOAP

Un noeud SOAP peut être émetteur SOAP initial, récepteur SOAP final ou intermédiaire SOAP. Un noeud SOAP recevant un message SOAP DOIT réaliser un traitement selon le modèle de traitement SOAP tel que décrit dans cette section et le reste de cette spécification. Un noeud SOAP est identifié par une URI, voir 5.4.3 Élément SOAP Node (noeud).

2.2 Rôles SOAP et noeuds SOAP

Lorsqu'il traite un message SOAP, on dit d'un noeud SOAP qu'il remplit un ou plusieurs rôles, chacun étant identifié par une URI connue comme le nom du rôle SOAP. Les rôles joués par un noeud DOIVENT être invariants durant le traitement d'un message SOAP individuel. Cette spécification s'occupe uniquement du traitement d'un message SOAP individuellement. Aucune assertion n'est faite concernant la possibilité qu'un noeud SOAP donné puisse ou ne puisse pas remplir divers rôles en traitant plusieurs messages SOAP.

Table 2 définit trois noms de rôles ayant une signification spéciale dans un message SOAP (voir 2.6 Traitement de messages SOAP).

En plus de ceux décrits dans Table 2, d'autres rôles POURRAIENT être utilisés si nécessaire en fonction des besoins des applications SOAP.

Si le but d'un nom de rôle SOAP est d'identifier un ou des noeuds SOAP, il n'y a pas de sémantique de routage ou de séquence d'échange de messages associée au nom de rôle SOAP. Par exemple, les rôles SOAP POURRAIENT être dénommés avec une URI utilisable pour router des messages vers un noeud SOAP approprié. Inversement, il est également approprié d'utiliser des rôles SOAP ayant des noms moins directement en rapport avec le routage de message (par ex. "http://example.org/banking/anyAccountMgr") ou sans rapport avec le routage (par ex. une URI destinée à identifier "tous les logiciels de gestion de cache". Par exemple, un bloc d'en-tête SOAP pourrait être utilisé pour transporter une indication pour tout logiciel concerné signalant que le contenu du message SOAP est idempotent et peut sans risque être caché et repris).

À l'exception des trois rôles SOAP définis dans Table 2, cette spécification n'impose pas le critère selon lequel un noeud donné détermine l'ensemble de rôles qu'il remplit pour un message donné. Par exemple, les implémentations peuvent baser cette détermination sur des fonctions incluant (liste non exhaustive) : choix codés en dur dans l'implémentation, information fournie par le protocole sous-jacent (par ex. l'URI à laquelle le message a été physiquement délivré) ou information de configuration fournie par les utilisateurs lors de l'installation du système.

2.3 Ciblage des blocs d'en-tête SOAP

Un bloc d'en-tête SOAP POURRAIT transporter un item d'information attribut role (voir 5.2.2 Attribut SOAP role ) utilisé pour cibler le bloc d'en-tête sur des noeuds SOAP jouant le rôle spécifié. Cette spécification se base sur la valeur de l'item d'information attribut role comme rôle SOAP pour le bloc d'en-tête SOAP correspondant.

Un bloc d'en-tête SOAP est dit ciblé sur un noeud SOAP si le rôle SOAP pour le bloc d'en-tête est le nom d'un rôle que le noeud SOAP peut jouer. Les blocs d'en-tête SOAP ciblés sur le rôle spécial "http://www.w3.org/2003/05/soap-envelope/role/none" ne sont jamais formellement traités. De tels blocs d'en-tête POURRAIENT transporter des données nécessaires au traitement d'autres blocs d'en-tête. Sauf s'ils sont retirés par action d'un intermédiaire (voir 2.7 Relais de messages SOAP), ces blocs sont relayés avec le message jusqu'au récepteur final (voir aussi 3.3 Modules SOAP).

2.4 Comprendre les en-têtes SOAP

Il est probable que des spécifications d'une large variété de fonctions d'en-tête (c-a-d des modules SOAP) seront développées avec le temps (voir 3.3 Modules SOAP) et que des noeuds SOAP pourront inclure le logiciel nécessaire pour implémenter une ou plusieurs de ces extensions. On dit d'un bloc d'en-tête SOAP qu'il est compris par un noeud SOAP si le logiciel de ce noeud SOAP a été écrit pour implémenter complètement et en s'y conformant la sémantique spécifiée pour le nom XML étendu de l'item d'information élément le plus englobant de ce bloc d'en-tête.

Les blocs d'en-tête SOAP POURRAIENT transporter un item d'information attribut mustUnderstand (voir 5.2.3 Attribut SOAP mustUnderstand (doitComprendre)). Lorsque la valeur d'un tel item d'information attribut est "true" (vrai), le bloc SOAP est dit obligatoire.

Les blocs d'en-tête SOAP obligatoires sont supposés modifier d'une manière ou d'une autre la sémantique d'autres en-têtes ou éléments du corps. Par conséquent, chaque fois qu'un bloc d'en-tête SOAP obligatoire est ciblé sur un noeud, ce noeud DOIT soit traiter le bloc d'en-tête, soit ne pas traiter le message SOAP du tout et à la place générer une faute (voir 2.6 Traitement de messages SOAP et 5.4 Faute SOAP). Marquer des blocs d'en-tête SOAP comme obligatoires assure donc que de telles modifications ne seront pas ignorées silencieusement (et vraisemblablement à tort) par un noeud SOAP auquel le bloc d'en-tête est destiné.

L'item d'information attribut mustUnderstand n'a pas pour vocation d'être un mécanisme de détection d'erreurs dans le routage, de mauvaises identifications de noeuds, d'échecs de la part d'un noeud dans son service pour un rôle prévu, etc. N'importe laquelle de ces conditions peut résulter en un échec en essayant même de traiter un bloc d'en-tête SOAP donné dans une enveloppe SOAP. Cette spécification ne requiert donc pas de générer une faute en l'absence ou sur une valeur de l'item d'information attribut mustUnderstand dans un bloc d'en-tête SOAP non ciblé sur le noeud de traitement courant. En particulier, il n'y a pas d'erreur si un récepteur SOAP final reçoit un message contenant un bloc d'en-tête obligatoire ciblé sur un autre rôle que ceux qu'il assure. Ce cas se présente, par exemple, lorsqu'un bloc d'en-tête a survécu en raison d'une erreur de routage ou de ciblage à l'intermédiaire précédent.

2.5 Structure et interprétation de corps SOAP

Un récepteur SOAP final DOIT traiter correctement les fils directs du corps SOAP (voir 5.3 Corps SOAP). Cependant, à l'exception des fautes SOAP (voir 5.4 Faute SOAP), la partie 1 de cette spécification (ce document) n'impose aucune structure ou interprétation de ces éléments et ne fournit aucune technique standard pour spécifier le traitement à effectuer.

2.6 Traitement de messages SOAP

Cette section définit les règles selon lesquelles les messages SOAP sont traités. Rien dans cette spécification n'interdit d'utiliser l'accès simultané optimiste (collatéralité), le retour en arrière ou d'autres techniques pouvant augmenter la flexibilité dans l'ordre du traitement, Sauf mention contraire, le traitement de tous les messages SOAP générés, les fautes SOAP et les effets de bords au niveau applicatif DOIT être sémantiquement équivalent à l'exécution des étapes suivantes séparément et dans l'ordre indiqué.

1. Déterminer l'ensemble de rôles remplis par le noeud. Le contenu de l'enveloppe SOAP, tout bloc d'en-tête et corps inclus, DEVRAIT être inspecté pour cette détermination.

2. Identifier parmi les blocs d'en-tête destinés à ce noeud tous ceux qui sont obligatoires.

3. Si l'un ou plusieurs des blocs d'en-tête identifiés par l'étape précédente ne sont pas compris par le noeud, générer alors une simple faute SOAP avec la valeur Value de Code fixée à "env:MustUnderstand" (doitComprendre) (voir 5.4.8 Fautes SOAP mustUnderstand (doitComprendre)). Si une telle faute est générée, aucun traitement ultérieur NE DOIT être effectué. Les fautes liées au contenu du corps NE DOIVENT PAS être générées à cette étape.

   Note:

   Tout au long de ce document, le terme "Value de Code " est utilisé pour abréger "valeur de l'item d'information élément Value fils de l'item d'information élément Code (voir 5.4.1 Élément SOAP Code).

4. Traiter tous les blocs d'en-tête ciblés sur le noeud et, dans le cas d'un récepteur SOAP final, le corps SOAP. Un noeud SOAP POURRAIT également choisir de traiter blocs d'en-tête non-obligatoires qui lui sont destinés.

5. Dans le cas d'un intermédiaire SOAP et quand la séquence d'échange de messages et le résultat du traitement (par ex. pas de faute générée) requiert d'envoyer le message plus loin sur son chemin SOAP, relayer le message comme décrit dans la section 2.7 Relais de messages SOAP.

Dans tous les cas où un bloc d'en-tête SOAP est traité, le noeud SOAP DOIT comprendre le bloc d'en-tête SOAP et DOIT effectuer un tel traitement en conformité totale avec la spécification de ce bloc d'en-tête. Le traitement réussi d'un bloc d'en-tête ne garantit pas le traitement réussi d'un autre bloc avec le même nom XML étendu dans le même message : la spécification d'un bloc d'en-tête détermine les circonstances dans lesquelles tel traitement résulterait en une faute. Un récepteur SOAP final DOIT traiter le corps SOAP, de manière cohérente avec 2.5 Structure et interprétation de corps SOAP.

L'échec est indiqué par la génération d'une faute (voir 5.4 Faute SOAP). Le traitement d'un message SOAP POURRAIT aboutir à la génération d'au plus une faute.

Un message peut contenir ou résulter en plusieurs erreurs lors du traitement. Excepté le cas où l'ordre de détection est spécifiquement indiqué (comme dans 2.4 Comprendre les en-têtes SOAP), un noeud SOAP a la liberté de refléter n'importe laquelle des fautes de l'ensemble de fautes possibles prévues pour les erreurs rencontrées. La sélection d'une faute n'a pas besoin d'être basée sur l'application des mots-clés "DOIT", "DEVRAIT" ou "POURRAIT" pour la génération de la faute, sauf si une ou plusieurs des fautes prévues sont qualifiées par "DOIT", alors une faute de l'ensemble de ces fautes possibles DOIT être générée.

Les noeuds SOAP POURRAIENT faire référence à toute information dans l'enveloppe SOAP lors du traitement d'un bloc de corps SOAP ou d'en-tête SOAP. Par exemple, une fonction de cache peut cacher un message SOAP entier si nécessaire.

Le traitement d'un ou plusieurs blocs d'en-tête SOAP POURRAIT contrôler ou déterminer l'ordre de traitement pour d'autres blocs d'en-tête SOAP et/ou le corps SOAP. Par exemple, on pourrait créer un bloc d'en-tête SOAP pour forcer à traiter d'autres blocs d'en-têtes SOAP dans l'ordre alphabétique. En l'absence d'un tel bloc d'en-tête SOAP de contrôle, l'ordre du traitement de l'en-tête et du corps est à la discrétion du noeud SOAP. Les blocs d'en-tête POURRAIENT être traités dans un ordre arbitraire. Le traitement des blocs d'en-tête POURRAIT précéder, POURRAIT s'intercaler dans ou POURRAIT suivre le traitement du corps. Par exemple, le traitement d'un bloc d'en-tête "commencer transaction" précéderait en principe le traitement du corps, une fonction "journaliser" pourrait s'exécuter simultanément avec le traitement du corps et un en-tête "valider transaction" serait honoré après la terminaison de tous les autres travaux.

2.7 Relais de messages SOAP

Comme mentionné précédemment dans cette section, on suppose qu'un message SOAP naît dans un émetteur SOAP initial et est envoyé à un récepteur SOAP final via zéro ou plus intermédiaires SOAP. Si SOAP en lui-même ne définit pas de sémantique de routage ou de réacheminement, on peut prévoir de décrire d'une telle fonctionnalité par une ou plusieurs caractéristiques (voir 3. Modèle d'extensibilité de SOAP). Le but de cette section est de décrire comment le réacheminement de message interagit avec le modèle de traitement distribué de SOAP.

SOAP définit deux types d'intermédiaires différents : les intermédiaires de réacheminement (forwarding intermediaries) et les intermédiaires actifs (active intermediaries). Ces deux types d'intermédiaires sont décrits dans cette section.

2.8 Modèle de gestion de version SOAP

La version d'un message SOAP est identifiée par le nom XML étendu de l'item d'information élément fils de l'item d'information document. Un message SOAP 1.2 possède un item d'information élément fils de l'item d'information document avec un nom lacal Envelope et un espace de nommage "http://www.w3.org/2003/05/soap-envelope" (voir 5.1 Enveloppe SOAP).

Un noeud SOAP détermine s'il supporte ou non la version d'un message SOAP en vérifiant message par message. Dans ce contexte, "supporter" signifie comprendre la sémantique de cette version d'enveloppe SOAP. Le modèle de gestion de version s'applique uniquement à l'item d'information élément Envelope . Il ne s'occupe pas de la gestion de version des blocs d'en-tête SOAP, des encodages, des liaisons sur protocoles, etc.

Un noeud SOAP POURRAIT supporter plusieurs versions d'enveloppe. Cependant, lors du traitement d'un message, un noeud SOAP DOIT utiliser la sémantique définie par la version de ce message.

Si un noeud SOAP reçoit un message dont la version n'est pas supportée, il DOIT générer une faute (voir 5.4 Faute SOAP) avec la valeur Value de Code fixée à "env:VersionMismatch" (décalage de version). Toute autre malformation dans la construction du message DOIT aboutir à la génération d'une faute avec une valeur Value de Code fixée à "env:Sender" (émetteur).

L'annexe A. Transition de version de SOAP/1.1 à SOAP Version 1.2 définit un mécanisme de transition de SOAP/1.1 vers SOAP Version 1.2 grâce à l'item d'information élément Upgrade (Mise à niveau) (voir 5.4.7 Fautes VersionMismatch (Décalage de Version)).

3.1 Caractéristiques SOAP

Une caractéristique SOAP est une extension de la structure SOAP pour les messages. Bien que SOAP ne pose aucune contrainte sur la portée de telles caractéristiques, on trouve parmi les exemples "fiabilité", "sécurité", "corrélation", "routage" et des séquences d'échange de messages (Message Exchange Patterns, MEPs) telles que interactions requêtes/réponse, messages unidirectionnels et conversation d'égal à égal.

Le modèle d'extensibilité de SOAP fournit deux mécanismes pour exprimer les caractéristiques : le modèle de traitement SOAP et la structure pour les liaisons sur protocoles (voir 2. Modèle de traitement SOAP et 4. Structure pour une liaison SOAP sur un protocole). Le premier décrit le comportement d'un noeud SOAP pris isolément pour le traitement d'un message SOAP individuel. Le second médiatise l'acte d'émission et de réception de messages SOAP par un noeud SOAP via un protocole sous-jacent.

Le modèle de traitement SOAP permet aux noeuds SOAP qui incluent les mécanismes nécessaire à l'implémentation d'une caractéristique ou plus d'exprimer celles-ci à l'intérieur de l'enveloppe SOAP sous forme de blocs d'en-tête (voir 2.4 Comprendre les en-têtes SOAP). Ces blocs d'en-tête peuvent être destinés à n'importe quel(s) noeud(s) le long du cheminement du message (voir 2.3 Ciblage des blocs d'en-tête SOAP). La combinaison de la syntaxe et de la sémantique de blocs d'en-tête SOAP est appelée module SOAP, et chaque module est spécifié selon les règles de 3.3 Modules SOAP.

En revanche, une liaison SOAP sur un protocole agit entre deux noeuds SOAP adjacents sur un cheminement de message SOAP. Rien n'impose que ce soit le même protocole sous-jacent qui soit utilisé pour tous les bonds sur un chemin SOAP. Dans certains cas, les protocoles sous-jacents sont équipés, soit directement, soit au travers d'extensions, de mécanismes pour des caractéristiques particulières. La structure pour les liaisons SOAP sur protocoles fournit un plan pour décrire ces caractéristiques et comment elles sont reliées aux noeuds SOAP par une spécification de liaison (voir 4. Structure pour une liaison SOAP sur un protocole).

Certaines caractéristiques peuvent nécessiter une sémantique de traitement de "bout en bout" plutôt que de "proche en proche". Si la structure pour liaison sur protocole donne la possibilité d'exprimer des caractéristiques "bout en bout" en dehors de l'enveloppe SOAP, elle ne définit pas de mécanisme spécifique pour le traitement par des intermédiaires des messages résultants. Une spécification de liaison qui exprime ainsi des caractéristiques à l'extérieur de l'enveloppe SOAP nécessite de définir ses propres règles de traitement de ces caractéristiques définies extérieurement. Un noeud SOAP est censé respecter ces règles de traitement (par exemple, décrivant quelle information passe avec le message SOAP sortant de l'intermédiaire). Le traitement d'enveloppes SOAP selon des spécifications de liaisons NE DOIVENT PAS prévaloir sur le modèle de traitement SOAP (voir 2. Modèle de traitement SOAP).

Il est recommandé d'exprimer si possible les caractéristiques de "bout en bout" sous forme de blocs d'en-tête SOAP, de manière à ce que les règles définies dans le modèle de traitement SOAP puissent être employées.

3.2 Séquences d'échange de messages SOAP (Message Exchange Patterns, MEPs)

Une séquence d'échange de messages (MEP) SOAP est un squelette établissant une forme de base pour échanger des messages entre noeuds SOAP. Les MEPs sont un type de caractéristique et, en l'absence de mention contraire, les références au terme "caractéristique" dans cette spécification s'appliquent également aux MEPs. La séquence d'échange de message de type Requête-Réponse spécifiée dans la partie 2 de SOAP 1.2 [SOAP Partie 2] illustre la spécification d'une caractéristique MEP.

La spécification d'une séquence d'échange de messages DOIT :

• comme prescrit par 3.1.1 Obligations pour les caractéristiques, donner une URI pour désigner la MEP.

• décrire le cycle de vie d'un échange de message conforme à la séquence.

• décrire les relations temporelles/causales, s'il y a lieu, entre messages multiples échangés conformément à la séquence.

• décrire la terminaison normale et anormale d'un échange de message conforme à la séquence.

Les spécifications de liaisons sur protocoles sous-jacents peuvent déclarer supporter une ou plusieurs MEPs données.

Les MEPs sont des caractéristiques SOAP, une spécification de MEP DOIT donc se conformer aux obligations des spécifications de caractéristiques SOAP (voir 3.1.1 Obligations pour les caractéristiques). Une spécification de MEP DOIT aussi inclure :

1. Toute obligation de générer des messages supplémentaires (tels que des réponses aux requêtes dans une MEP requête/réponse).

2. Des règles pour la livraison ou autre disposition de faute SOAP générée pendant le déroulement de la séquence.

3.3 Modules SOAP

Le terme "module SOAP" se réfère à la spécification de la syntaxe et de la sémantique d'un ou plusieurs blocs d'en-tête SOAP. Un module SOAP réalise zéro ou plus caractéristiques SOAP. Une spécification de module suit les règles ci-après. Elle :

1. DOIT s'identifier par une URI. Ceci permet de référencer le module sans ambiguïté dans les langages de description ou pendant la négociation.

2. DOIT déclarer les caractéristiques fournies par un module (voir 3.1 Caractéristiques SOAP).

3. DOIT clairement et complètement spécifier le contenu et la sémantique des blocs d'en-tête utiliser pour implémenter le comportement en question, en incluant le cas échéant toute modification au modèle de traitement SOAP. Le modèle d'extensibilité de SOAP ne limite pas la portée des extensions de SOAP. Il n'empêche pas non plus les extensions de modifier le modèle de traitement SOAP décrit dans 2. Modèle de traitement SOAP

4. POURRAIT utiliser les conventions de propriétés définies dans la partie 2 de SOAP 1.2 [SOAP Partie 2], section Une convention pour décrire les caractéristiques et les liaisons , pour décrire les fonctionnalités que le module apporte. Si ces conventions sont suivies, la spécification du module DOIT clairement décrire la relation entre les propriétés abstraites et leur représentation dans l'enveloppe SOAP. Notez qu'il est possible d'écrire une spécification de caractéristique purement en termes de propriétés abstraites, puis d'écrire ensuite une spécification de module séparée pour implémenter cette caractéristique, en établissant une correspondance entre les propriétés définies dans la spécification de la caractéristique et les blocs d'en-tête SOAP du module.

5. DOIT clairement spécifier toute interaction connue avec le corps SOAP ou tout changement dans son interprétation. De plus, elle DOIT clairement spécifier toute interaction connue avec d'autres caractéristiques ou modules SOAP ou tout changement dans leur interprétation. Par exemple, on peut imaginer un module qui crypte et retire le corps et insère un en-tête contenant une somme de contrôle et une indication du mécanisme de cryptage utilisé. La spécification d'un tel module indiquerait que l'algorithme de décryptage du côté récepteur doit être appliqué avant tout autre module reposant sur le contenu du corps.

4.1 Objectifs de la structure pour les liaisons

Les objectifs de la structure pour les liaisons sont :

1. Mettre en place les obligations et concepts communs à toutes les spécifications de liaisons.

2. Favoriser l'homogénéité des descriptions dans une situation où de multiples liaisons supportent des caractéristiques communes, pour encourager la réutilisation entre les liaisons.

3. Favoriser la cohérence dans la spécification de caractéristiques optionnelles.

Si on a deux liaisons ou plus, des caractéristiques optionnelles comme la fiabilité de la livraison peuvent être disponibles par des méthodes différentes. Une liaison peut exploiter un protocole sous-jacent qui fournirait directement la caractéristique (par ex. le protocole est fiable) alors qu'une autre peut fournir elle-même la logique nécessaire (par ex. fiabilité assurée par journalisation et retransmission). Dans ce cas, la caractéristique peut être mise à disposition des applications de manière homogène, indépendante de la liaison utilisée.

4.2 Structure pour une liaison

La création, transmission et le traitement d'un message SOAP, éventuellement au travers d'un ou plusieurs intermédiaires, sont spécifiés en termes de machine à états distribuée. Un état constitue l'information connue d'un noeud SOAP à un instant donné, entre autres le contenu des messages assemblés pour être transmis ou reçus pour être traités. L'état de chaque noeud peut être changé soit suite à un traitement local, soit suite à une information reçue d'un noeud adjacent.

La section 2. Modèle de traitement SOAP de cette spécification décrit le traitement commun à tous les noeuds SOAP à la réception d'un message. Le but d'une spécification de liaison est d'ajouter à ces règles principales de SOAP des traitements supplémentatires spécifiques à la liaison, et de spécifier la manière d'utiliser le protocole sous-jacent pour transmettre des informations entre noeuds successifs du chemin du message.

La machine à états distribuée qui gère la transmission d'un message SOAP donné sur son chemin est la combinaison du traitement SOAP principal (voir 2. Modèle de traitement SOAP) effectué à chaque noeud et des spécifications de liaison reliant chaque paire de noeuds. Une spécification de liaison DOIT permettre une ou plusieurs MEPs.

Dans le cas où plusieurs caractéristiques sont supportées par une spécification de liaison, les spécifications de ces caractéristiques DOIVENT fournir l'information nécessaire pour les utiliser en combinaison avec succès. De même, toute dépendance d'une caractéristique sur une autre (c-a-d si le succès de l'utilisation de l'une dépend de l'utilisation ou non de l'autre) DOIT être spécifiiée. Cette structure pour les liaisons ne donne pas de mécanisme explicite assurant une telle compatibilité entre caractéristiques multiples.

La structure pour les liaisons ne fixe aucune manière de nommer ou typer l'information constituant un état d'un noeud donné. Les spécifications de caractéristiques et de liaisons sont libres d'adopter individuellement leurs propres conventions pour spécifier un état. Notez cependant que la cohérence entre liaisons et caractéristiques est susceptible d'être améliorée dans les cas où plusieurs spécifications de caractéristiques adoptent des conventions cohérentes de représentation d'états. Par exemple, plusieurs caractéristiques peuvent tirer parti d'une spécification cohérente des certificats d'authentification, identifiants de transaction, etc. La liaison sur HTTP dans la partie 2 de SOAP 1.2 [SOAP Partie 2] illustre une telle convention.

Comme décrit dans 5. Construction de message SOAP, chaque message SOAP est spécifié comme un Infoset XML constitué d'un item d'information document avec exactement un fils : l'item d'information élément enveloppe. Par conséquent, la responsabilité minimale d'une liaison dans la transmission d'un message est de spécifier d'une part les manières de transmettre l'Infoset XML du mesage SOAP et de le reconstituer à la réception par un noeud SOAP et d'autre part comment la transmission de l'enveloppe est effectuée grâce aux services du protocole sous-jacent.

La structure pour les liaisons n'oblige pas les liaisons à utiliser la sérialisation XML 1.0 [XML 1.0] comme représentation "sur le fil" de l'Infoset ; des représentations compressées, cryptées, fragmentées, etc. peuvent être utilisées le cas échéant. Une liaison POURRAIT, lorsqu'elle utilise la sérialisation XML 1.0 de l'infoset, obliger à utiliser un encodage ou un ensemble d'encodages de caractères particulier.

Les liaisons POURRAIENT supporter la lecture en flot continu (streaming) dans le traitement des messages. C'est-à-dire que les noeuds SOAP POURRAIENT commencer le traitement d'un message SOAP reçu dès que l'information nécessaire est disponible. Le traitement SOAP est spécifié en termes d'infosets XML Envelope XML infosets (voir 5. Construction de message SOAP). Même si les récepteurs SOAP en flot continu vont obtenir ces infosets XML par incréments, le traitement SOAP DOIT rendre des résultats identiques à ceux qui seraient produits si l'enveloppe était disponible en entier avant de commencer le traitement. Par exemple, comme indiqué en 2.6 Traitement de messages SOAP, l'identification des blocs d'en-tête ciblés et la vérification de tous les attributs mustUnderstand (doitComprendre) doivent être effectuées pour qu'un traitement réussi puisse commencer. Selon la représentation utilisée pour l'infoset et l'ordre dans lequel elle est transmise, cette règle peut limiter le niveau pouvant être atteint pour le flot continu.

Les liaisons POURRAIENT dépendre de l'état modélisé hors de l'Infoset XML SOAP (par ex. compteurs de tentatives) et POURRAIENT transmettre une telle information aux noeuds adjacents. Par exemple, des liaisons prennent une adresse de livraison de message (typiquement une URI) qui ne se trouve pas dans l'enveloppe.

5.1 Enveloppe SOAP

L'item d'information élément Envelope a :

• Pour [local name] Envelope .

• Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".

• Zéro ou plus items d'information attributs, qualifiés par un espace de nommage, dans sa propriété [attributes].

• Un ou deux items d'information éléments dans sa propriété [children] dans l'ordre suivant :

  1. Un item d'information élément optionnel Header (en-tête) (voir 5.2 En-tête SOAP).

  2. Un item d'information élément obligatoire Body (corps) (voir 5.3 Corps SOAP).

"http://www.w3.org/2003/05/soap-encoding"
"http://example.org/encoding/"
"http://www.w3.org/2003/05/soap-envelope/encoding/none"

5.2 En-tête SOAP

L'item d'information élément Header (en-tête) fournit un mécanisme d'extension de message SOAP de manière décentralisée et modulaire (voir 3. Modèle d'extensibilité de SOAP et 2.4 Comprendre les en-têtes SOAP).

L'item d'information élément Header a :

• Pour [local name] Header .

• Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".

• Zéro ou plus items d'information attributs, qualifiés par un espace de nommage, dans sa propriété [attributes].

• Zéro ou plus items d'information éléments, qualifiés par un espace de nommage, dans sa propriété [children].

Chaque item d'information élément fils de l'en-tête SOAP est appelé bloc d'en-tête SOAP.

<env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
 <t:Transaction xmlns:t="http://example.org/2001/06/tx" 
                env:mustUnderstand="true" >
   5
 </t:Transaction>
</env:Header>

5.3 Corps SOAP

Un corps SOAP fournit un mécanisme de transmission d'information vers un récepteur SOAP final (voir 2.5 Structure et interprétation de corps SOAP).

L'item d'information élément Body a :

• Pour [local name] Body (corps).

• Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".

• Zéro ou plus items d'information attributs qualifiés par un espace de nommage dans sa propriété [attributes].

• Zéro ou plus items d'information éléments qualifiés par un espace de nommage dans sa propriété [children].

5.4 Faute SOAP

Une faute SOAP est utilisée pour transporter de l'information d'erreur dans un message SOAP.

L'item d'information élément Fault (faute) a :

• Pour [local name] Fault .

• Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".

• Deux items d'information éléments fils ou plus dans sa propriété [children], dans l'ordre suivant :

  1. Un item d'information élément obligatoire Code (voir 5.4.1 Élément SOAP Code).

  2. Un item d'information élément obligatoire Reason (raison) (voir 5.4.2 Élément SOAP Reason (raison)).

  3. Un item d'information élément optionnel Node (noeud) (voir 5.4.3 Élément SOAP Node (noeud)).

  4. Un item d'information élément optionnel Role (voir 5.4.4 Élément SOAP Role).

  5. Un item d'information élément optionnel Detail (voir 5.4.5 Élement SOAP Detail).

Pour être reconnu comme transportant une information d'erreur SOAP, un message SOAP DOIT contenir un seul item d'information élément Fault comme seul fils du Body (corps) SOAP.

Quand ils génèrent une faute, les émetteurs SOAP NE DOIVENT PAS inclure d'items d'information éléments supplémentaires dans le Body (corps) SOAP. Un message dont le Body contient une Fault (faute) plus des items d'information éléments n'a pas de sémantique définie dans SOAP.

Un item d'information élément Fault (faute) POURRAIT apparaître dans un bloc d'en-tête SOAP ou comme descendant d'un item d'information élément fils du Body (corps) SOAP  ; dans ces cas, l'élément n'a pas de sémantique définie dans SOAP.

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
            xmlns:m="http://www.example.org/timeouts"
            xmlns:xml="http://www.w3.org/XML/1998/namespace">
  <env:Body>
   <env:Fault>
     <env:Code>
       <env:Value>env:Sender</env:Value>
       <env:Subcode>
        <env:Value>m:MessageTimeout</env:Value>
       </env:Subcode>
     </env:Code>
     <env:Reason>
       <env:Text xml:lang="en">Sender Timeout</env:Text>
     </env:Reason>
     <env:Detail>
       <m:MaxTime>P5M</m:MaxTime>
     </env:Detail>
    </env:Fault>
   </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
	xmlns:xml="http://www.w3.org/XML/1998/namespace">
 <env:Header>
  <env:Upgrade>
   <SupportedEnvelope qname="ns1:Envelope" 
             xmlns:ns1="http://www.w3.org/2003/05/soap-envelope"/>
   <SupportedEnvelope qname="ns2:Envelope" 
             xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>
  </env:Upgrade>
 </env:Header>
 <env:Body>
  <env:Fault>
   <env:Code><env:Value>env:VersionMismatch</env:Value></env:Code>
    <env:Reason>
     <env:Text xml:lang="en">Version Mismatch</env:Text>
    </env:Reason>
   </env:Fault>
 </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'>
  <env:Header>
    <abc:Extension1 xmlns:abc='http://example.org/2001/06/ext'
       env:mustUnderstand='true'/>
    <def:Extension2 xmlns:def='http://example.com/stuff'
       env:mustUnderstand='true' />
  </env:Header>
  <env:Body>
    . . .
  </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'
	    xmlns:xml='http://www.w3.org/XML/1998/namespace'>
 <env:Header>
  <env:NotUnderstood qname='abc:Extension1'
                   xmlns:abc='http://example.org/2001/06/ext' />
  <env:NotUnderstood qname='def:Extension2'
                   xmlns:def='http://example.com/stuff' />
 </env:Header>
 <env:Body>
  <env:Fault>
   <env:Code><env:Value>env:MustUnderstand</env:Value></env:Code>
   <env:Reason>
    <env:Text xml:lang='en'>One or more mandatory 
                SOAP header blocks not understood
    </env:Text>
   </env:Reason>
  </env:Fault>
 </env:Body>
</env:Envelope>

7.1 Noeuds SOAP

SOAP peut transporter des données définies par l'application comme blocs d'en-tête SOAP ou contenu de corps SOAP. Le traitement d'un bloc d'en-tête SOAP peut éventuellement inclure de traiter des effets de bord comme les changements d'état, la journalisation des informations ou la génération de messages supplémentaires. Il est fortement recommandé, pour tout scénario de déploiement, que seuls des blocs d'en-tête soigneusement spécifiés, avec des implications de sécurité de tout effet de bord bien comprises, soient traités par un noeud SOAP.

De la même manière, traiter un corps SOAP peut impliquer des effets de bord qui peuvent, s'ils ne sont pas correctement appréhendés, avoir de graves conséquences pour le noeud récepteur. Il est fortement recommandé que seuls les contenus de corps bien définis avec des implications au niveau sécurité connues soient traités.

Les considérations de sécurité ne sont pourtant pas limitées à la reconnaissance des éléments fils immédiats de l'en-tête et du corps SOAP. Les implémenteurs ont besoin de faire particulièrement attention aux implications au niveau sécurité de toutes les données transportées dans un message SOAP qui peut causer une exécution distante d'actions dans l'environnement du récepteur. Ceci inclut non seulement les données exprimées dans l'infoset XML mais aussi des données pouvant être encodées en binaire ou passées comme paramètres, par exemple des chaînes de requêtes sous forme d'URI. Avant d'accepter des données de n'importe quel type, une application devrait probablement être consciente des implications de sécurité particulières associées à ces données dans leur contexte d'utilisation présent.

Les implémenteurs SOAP doivent s'assurer que, si le traitement des diverses parties d'un message SOAP est fourni au travers d'une architecture logicielle modulaire, chaque module est conscient du contexte global au niveau sécurité. Par exemple, un corps SOAP ne devrait probablement pas être traité sans connaître dans quel contexte il a été reçu.

7.2 Intermédiaires SOAP

SOAP fournit intrinsèquement un modèle de traitement qui peut impliquer un passage de message SOAP par de multiples noeuds SOAP (voir 2. Modèle de traitement SOAP). Les intermédiaires SOAP sont par définition des tiers et représentent une opportunité pour des attaques de tiers. Des failles de sécurité sur des systèmes exécutant des intermédiaires SOAP peuvent aboutir à de sérieux problèmes de sécurité et de confidentialité. Un intermédiaire SOAP atteint ou un intermédiaire implémenté ou configuré sans attention aux considérations de sécurité et de confidentialité pourrait être utilisé pour une large étendue d'attaques potentielles.

Dans l'analyse des implications des problèmes de sécurité potentiels liés à SOAP, il est important de réaliser que la portée des mécanismes de sécurité fournis par le protocole sous-jacent n'est peut-être pas la même que pour le cheminement entier du message. Il n'est pas obligatoire dans SOAP que tous les bonds entre noeuds participants utilisent le même protocole sous-jacent et, même si c'était le cas, l'utilisation-même d'intermédiaires SOAP est susceptible de dépasser la portée de la sécurité du niveau transport.

7.3 Liaisons sur protocoles sous-jacents

Les effets sur la sécurité de ne pas implémenter un DOIT ou DEVRAIT, ou de faire quelque chose dont la spécification dit qu'elle NE DOIT PAS ou NE DEVRAIT PAS être faite peuvent être très subtils. Les auteurs de spécification de liaison doivent décrire en détails les implications de sécurité du cas où des recommandations ou obligations ne seraient pas suivies, car la plupart des implémenteurs n'auront pas le bénéfice de l'expérience et des discussions qui auront produit la spécification (voir 4. Structure pour une liaison SOAP sur un protocole).

De plus, une spécification de liaison peut ne pas se préoccuper de ou fournir de contre-mesures pour tous les aspects des risques de sécurité inhérents. Les auteurs de spécification de liaison doivent identifier tout risque qui pourrait subsister et indiquer où des contre-mesures supplémentaires seraient nécessaires au-delà de celles fournies dans la spécification de la liaison.

Les auteurs de spécifications de liaisons doivent être conscients que les modules d'extension de SOAP exprimés sous forme de blocs d'en-tête SOAP pourraient affecter le protocole sous-jacent de manière imprévue. Un message SOAP transporté sur une liaison sur un protocole particulière pourrait aboutir à des caractéristiques en apparence contradictoires. Un exemple de ceci serait un message SOAP transporté sur HTTP, utilisant le mécanisme d'authentification basique de HTTP en combinaison avec un mécanisme d'authentification basique de SOAP. Il est fortement recommandé qu'une liaison de spécification décrive toute interaction de ce genre entre des extensions et les protocoles sous-jacents.

8.1 Références normatives

[SOAP Partie 2]

W3C Proposed Recommendation "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (Voir http://www.w3.org/TR/2003/REC-soap12-part2-20030624).

[RFC 2616]

IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk Nielsen, T. Berners-Lee, January 1997. (Voir http://www.ietf.org/rfc/rfc2616.txt).

[RFC 2119]

IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (Voir http://www.ietf.org/rfc/rfc2119.txt).

[XML Schema Partie 1]

W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (Voir http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/).

[XML Schema Partie 2]

W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (Voir http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/).

[RFC 2396]

IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (Voir http://www.ietf.org/rfc/rfc2396.txt).

[Namespaces in XML]

W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (Voir http://www.w3.org/TR/1999/REC-xml-names-19990114/).

[XML 1.0]

W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (Voir http://www.w3.org/TR/2000/REC-xml-20001006).

[XML InfoSet]

W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (Voir http://www.w3.org/TR/2001/REC-xml-infoset-20011024/).

[XML Base]

W3C Recommendation "XML Base", Johnathan Marsh, 27 June 2001. (Voir http://www.w3.org/TR/2001/REC-xmlbase-20010627/).

[RFC 2732]

IETF "RFC 2732: Format for Literal IPv6 Addresses in URL's", R. Hinden, B. Carpenter, L. Masinter, December 1999. (Voir http://www.ietf.org/rfc/rfc2732.txt).

8.2 Références informatives

[SOAP Partie 0]

W3C Proposed Recommendation "SOAP Version 1.2 Part 0: Primer", Nilo Mitra, 24 June 2003 (Voir http://www.w3.org/TR/2003/REC-soap12-part0-20030624).

[XMLP Comments]

XML Protocol Comments Archive (Voir http://lists.w3.org/Archives/Public/xmlp-comments/).

[XMLP Dist-App]

XML Protocol Discussion Archive (Voir http://lists.w3.org/Archives/Public/xml-dist-app/).

[XMLP Charter]

XML Protocol Charter (Voir http://www.w3.org/2000/09/XML-Protocol-Charter).

[XMLP Requirements]

W3C Working Draft "XML Protocol (XMLP) Requirements", Vidur Apparao, Alex Ceponkus, Paul Cotton, David Ezell, David Fallside, Martin Gudgin, Oisin Hurley, John Ibbotson, R. Alexander Milowski, Kevin Mitchell, Jean-Jacques Moreau, Eric Newcomer, Henrik Frystyk Nielsen, Mark Nottingham, Waqar Sadiq, Stuart Williams, Amr Yassin, 24 June 2003. This is work in progress. (Voir http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626).

[SOAP Usage Scenarios]

W3C Working Draft "SOAP Version 1.2 Usage Scenarios", John Ibbotson 24 June 2003. This is work in progress. (Voir http://www.w3.org/TR/2002/WD-xmlp-scenarios-20020626).

[SOAP 1.1]

W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (Voir http://www.w3.org/TR/SOAP/).

[RFC 1900]

IETF "RFC 1900: Renumbering Needs Work", B. Carpenter, Y. Rekhter, February 1996. (Voir http://www.ietf.org/rfc/rfc1900.txt).