Groupe de travail Réseau	E. O'Tuathail, Clipcode.com	
Request for Comments : 4227	M. Rose, Dover Beach Consulting, Inc.	
RFC rendue obsolète : 3288		
Catégorie : Sur la voie de la normalisation		
Traduction Claude Brière de L'Isle	janvier 2006	

Utilisation du protocole simple d'accès aux objets (SOAP) dans le protocole d'échange de blocs extensible (BEEP)

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
(Cette traduction incorpore les deux errata en cours au 16 avril 2020)

Notice de copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent mémoire spécifie un lien du protocole simple d'accès aux objets (SOAP, Simple Object Access Protocol) avec le cœur du protocole d'échange de blocs extensible (BEEP, Blocks Extensible Exchange Protocol). Un lien SOAP décrit comment les messages SOAP sont transmis dans le réseau.

SOAP est un protocole de messagerie fondé sur XML (langage de balisage extensible) utilisé pour mettre en œuvre une grande variété de modèles de messagerie répartie. Il définit un format de message et décrit divers schémas de message, incluant, sans s'y limiter, l'appel de procédure distante (RPC, Remote Procedure Calling), la notification asynchrone d'événement, les messages sans accusé de réception, et la transmission via des intermédiaires SOAP.
Table des matières
1. Introduction	2
2. BEEP Profile Identification	2
2.1 Initialisation de profil	3
3. Paquetages de messages SOAP	4
4. Schémas de message SOAP	5
4.1. Message unilatéral	5
4.2 Échange demande-réponse 	5
4.3 Échange demande/N-réponses	5
4.4 Traitement d'erreur 	5
5. Conformité au cadre de lien de protocole SOAP	6
5.1 Nom de lien	6
5.2 URI de base	6
5.3 Schémas d'échange de message SOAP pris en charge	6
5.4 Caractéristiques prises en charge	6
5.5 Fonctionnement du MEP	6
6. Schémas d'URL	7
6.1 Schéma d'URL soap.beep	7
6.2 Schéma d'URL soap.beeps	8
7. Gabarits d'enregistrement	8
7.1 Gabarit d'enregistrement de caractéristique de profil SOAP	8
8. Enregistrements initiaux	8
8.1 Enregistrrment : profil SOAP	8
8.2 Enregistrement : schéma d'URL soap.beep	8
8.3 Enregistrement : schéma d'URL soap.beeps	9
8.4 Enregistrement : système (bien connu) de numéro d'accès TCP pour SOAP sur BEEP	9
9. Considérations sur la sécurité	9
10. Considérations relatives à l'IANA	9
11. Changements depuis la RFC 3288	10
12. Remerciements	10
13. Références	10
13.1 Références normatives	10
13.2 Références pour information	10
Appendice A. SOAP avec pièces jointes (Information)	11
Adresse des auteurs	12
Déclaration complète de droits de reproduction	12

 	1.	Introduction

Le présent mémoire spécifie comment les enveloppes SOAP [SOAP1.2-0] sont transmises en utilisant un profil BEEP [RFC3080]. Les mises en œuvre conformes DOIVENT prendre en charge SOAP version 1.2 [SOAP1.2-0] et PEUVENT prendre en charge d'autres versions, comme SOAP version 1.1 [SOAPNote]. Le présent mémoire spécifie comment les enveloppes SOAP [SOAP1.2-0] sont transmises en utilisant un profil BEEP [RFC3080]. À la différence de son prédécesseur, la [RFC3288], le présent mémoire ne rend pas obligatoire l'utilisation de SOAP version 1.1.

Tout au long du présent mémoire, le terme "enveloppe" se réfère à l'élément de niveau supérieur échangé par les envoyeurs et receveurs SOAP. Par exemple, quand on se réfère à SOAP version 1.2, le terme "enveloppe" se réfère à l'élément "Envelope" défini au paragraphe 5.1 de [SOAP1.2-1]. De plus, les termes "homologue", "client", "serveur", "un à un", et "un à plusieurs" sont utilisés dans le contexte de BEEP. En particulier, les paragraphes 2.1 et 2.1.1 de la [RFC3080] discutent des rôles et styles d'échange de BEEP.

 	2.	BEEP Profile Identification

Le profil BEEP pour SOAP est identifié comme : "http://iana.org/beep/soap/VERSION" dans l'élément "profile" de BEEP durant la création de canal. où "VERSION" se réfère au numéro de version de la spécification SOAP.

Par exemple, http://iana.org/beep/soap/1.2 se réfère à la version 1.2.

Noter que la [RFC3288] a utilisé http://iana.org/beep/soap aux fins d'identification de profil pour les enveloppes SOAP version 1.1 [SOAPNote]. Si une mise en œuvre du présent mémoire choisit de mettre en œuvre SOAP version 1.1, elle devrait alors prendre en charge cet identifiant de ressource universel (URI, Uniform Resource Identifier) pour l'identification de profil aussi bien que "http://iana.org/beep/soap/1.1".

Dans BEEP, quand le premier canal est bien créé, l'attribut "serverName" dans l'élément "start" identifie "l'hôte virtuel" associé à l'homologue qui agit dans le rôle de serveur, par exemple,

<start number='1' serverName='stockquoteserver.example.com'>
    <profile uri='http://iana.org/beep/soap/1.2' />
</start>

L'attribut "serverName" est analogue au champ d'en-tête de demande HTTP "Host" (voir paragraphe 14.23 de la [RFC2616]).

Il y a deux états dans le profil BEEP pour SOAP, "boot" (amorçage) et "ready" (prêt) :

o	Dans l'état "boot", l'homologue qui demande la création du canal envoie un "bootmsg" (message d'amorçage) (durant l'initialisation du canal ou dans un message "MSG").
*	Si l'autre homologue envoie une "bootrpy" (réponse d'amorçage) (durant l'initialisation du canal ou dans un message "RPY") on entre alors dans l'état "ready"
*	Autrement, l'autre homologue envoie une "erreur" (durant l'initialisation du canal ou dans un message "ERR") et aucun changement d'état ne survient.
o	Dans l'état "ready", l'un ou l'autre homologue commence un schéma de message SOAP par l'envoi d'un message "MSG" contenant une enveloppe. L'autre homologue complète le schéma de message soit :
*	en renvoyant le message "RPY" contenant une enveloppe, soit
*	en renvoyant zéro, un ou plusieurs messages "ANS", dont chacun contient une enveloppe, suivi par un message "NUL".
Dans les deux cas, aucun changement d'état ne survient.

 	2.1	Initialisation de profil
Le message "boot" a deux usages :

identification de ressource : chaque canal lié au profil BEEP pour SOAP fournit l'accès à une seule ressource (un objet ou service de données de réseau).

négociation de caractéristique : si de nouvelles caractéristiques de SOAP (comme la compression) émergent, leur utilisation peut être négociée.

La syntaxe de déclaration de type de données (DTD, Data Type Declaration) pour le message "boot" et sa réponse est :

<!ELEMENT bootmsg                VIDE>
<!ATTLIST bootmsg
          resource    CDATA            #EXIGÉ
          features    NMTOKENS     "">

<!ELEMENT bootrpy                  VIDE>
<!ATTLIST bootrpy
          features    NMTOKENS     "">

Le message "boot" contient un attribut obligatoire et un attribut facultatif :
o	l'attribut "resource" qui est analogue au paramètre d'URI de demande "abs_path" de HTTP (voir au paragraphe 5.1.2 de la [RFC2616])
o	l'attribut "features" qui, s'il est présent, contient un ou plusieurs jetons de caractéristiques, dont chacun indique une caractéristique facultative du profil BEEP pour SOAP dont l'utilisation possible sur le canal est demandée.

Le paragraphe 7.1 définit un gabarit d'enregistrement pour les caractéristiques facultatives.

Si l'homologue qui agit dans le rôle de serveur reconnaît la ressource demandée, il répond avec la réponse "boot" qui contient l'attribut facultatif:

o	L'attribut "features", s'il est présent, contient un sous ensemble des jetons de caractéristiques du message "boot", indiquant quelles caractéristiques peuvent être utilisées sur le canal. (Si il n'est pas présent, ou s'il est vide, aucune caractéristique ne peut être utilisée.)

Autrement, si le message "boot" est improprement formé, ou si la ressource demandée n'est pas reconnue, l'homologue qui agit dans le rôle de serveur répond avec un message d'erreur (voir le paragraphe 7.1 de la [RFC3080]). Normalement, le message "boot" et sa réponse sont échangés durant l'initialisation de canal (voir le paragraphe 2.3.1.2 de la [RFC3080]).

Voici par exemple, le message "boot" et sa réponse échangés durant l'initialisation du canal :

C: <start number='1' serverName='stockquoteserver.example.com'>
C:    <profile uri='http://iana.org/beep/soap/1.2'>
C:       <![CDATA[<bootmsg resource='/StockQuote' />]]>
C:     </profile>
C: </start>

S: <profile uri='http://iana.org/beep/soap/1.2'>
S:     <![CDATA[<bootrpy />]]>
S: </profile>

Le canal lié au profil BEEP pour SOAP est maintenant dans l'état "ready".

Autrement, voici un exemple dans lequel l'échange "boot" ne réussit pas :

C: <start number='1' serverName='stockquoteserver.example.com'>
C:     <profile uri='http://iana.org/beep/soap/1.2'>
C:         <![CDATA[<bootmsg resource='/StockPick' />]]>
C:     </profile>
C: </start>

S: <profile uri='http://iana.org/beep/soap/1.2'>
S:     <![CDATA[<code d'erreur='550'>ressource non prise en charge</erreur>]]>
S: </profile>

Malgré la réussite de la création du canal , il reste dans l'état "boot".

 	3.	Paquetages de messages SOAP

Le profil BEEP pour SOAP transmet des enveloppes codées en UTF-8 et DEVRAIENT utiliser le type de support "application/soap+xml" [RFC3902], par exemple,

MSG 1 1 . 0 284
Content-Type: application/soap+xml

<env:Envelope
     xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Header>
   <m:GetLastTradePrice xmlns:m="Some-URI" />
  </env:Header>
  <env:Body>
    <symbol xmlns:p="Some-URI" >DIS</symbol>
  </env:Body>
</env:Envelope>
FIN

Pour assurer la compatibilité avec la [RFC3288], on PEUT utiliser le type de support "application/xml" [RFC3023].

De plus, une mise en œuvre du profil BEEP pour SOAP PEUT prendre en charge la transmission d'enveloppes utilisant la technique de paquetage MTOM [SOAPmtom] / XOP [XMLbOP], par exemple,

MSG 1 2 . 283 1436
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=
Content-Description: message SOAP avec mon pic et ma sig dedans.

--MIME_boundary
Content-Type: application/xop+xml;
    charset=UTF-8;
    type="application/soap+xml; action=
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo
  xmlmime:contentType='image/png'><xop:Include
    xmlns:xop='http://www.w3.org/2004/08/xop/include'
    href='cid:http://example.org/me.png'/></m:photo>
      <m:sig
  xmlmime:contentType='application/pkcs7-signature'><xop:Include
    xmlns:xop='http://www.w3.org/2004/08/xop/include'
    href='cid:http://example.org/my.hsh'/></m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// octets binaires pour png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// octets binaires pour la signature

--MIME_boundary--
FIN

Consulter le paragraphe 4.1 de XOP [XMLbOP] pour des lignes directrices sur l'usage de MIME Multipart/Related. Comme BEEP fournit un chemin de 8 bits de large, on ne devrait pas utiliser un codage de transfert de contenu "transformatif" (par exemple, "base64" ou "quoted-printable"). Noter que MIME [RFC2045] exige que la valeur de l'en-tête "Content-ID" soit unique au monde. Comme déclaré à la Section 4 de [XMLbOP], XOP peut être utilisé avec divers mécanismes de paquetage. Quand une mise en œuvre de BEEP dans SOAP ne prend pas en charge MTOM/XOP, elle DEVRAIT prendre en charge le format de paquetage MIME Multipart/Related XOP, et PEUT en prendre en charge d'autres. Des formats supplémentaires pourraient, à l'avenir, inclure des formats de paquetage XOP spécifiques de BEEP (par exemple, envoyer les pièces jointes sur un canal différent du canal SOAP, ce qui éviterait de chercher les étiquettes de limites MIME et permettait une livraison "paresseuse" des pièces jointes, ne les livrant que quand elles sont réellement nécessaires.)

 	4.	Schémas de message SOAP
 	4.1.	Message unilatéral
Un message unilatéral est l'envoi d'un message sans qu'aucune réponse ne soit retournée.

Le profil BEEP pour SOAP réalise cela en utilisant un échange de un à plusieurs, dans lequel le client envoie un message "MSG" contenant une enveloppe, et le serveur renvoie immédiatement un message "NUL", avant de traiter le contenu de l'enveloppe.

 	4.2	Échange demande-réponse 
Un échange demande/réponse est l'envoi d'une demande, qui résulte en le retour d'une réponse.

Le profil BEEP pour SOAP réalise cela en utilisant un échange de un à un, dans lequel le client envoie un message "MSG" contenant une enveloppe, et le serveur renvoie un message "RPY" contenant une enveloppe.

 	4.3	Échange demande/N-réponses
Un échange demande/N-réponses est l'envoi d'une demande qui résulte en le retour de zéro, une ou plusieurs réponses.

Le profil BEEP pour SOAP réalise cela en utilisant un échange de un à plusieurs, dans lequel le client envoie un message "MSG" contenant une enveloppe, et le serveur renvoie zéro, un ou plusieurs messages "ANS" dont chacun contient une enveloppe, suivi par un message "NUL".

 	4.4	Traitement d'erreur 
Le profil BEEP pour SOAP n'utilise pas le message "ERR" pour les fautes de SOAP. Quand on effectue des échanges de un à un, toute réponse SOAP quelle qu'elle soit (y compris de fautes SOAP) générée par le serveur est toujours retournée dans le message "RPY". Lorsque on effectue des échanges de un à plusieurs, toute réponse SOAP quelle qu'elle soit (y compris de fautes SOAP) générée par le serveur est toujours retournée dans les messages "ANS".

Si il y a une erreur dans le message BEEP sans relation avec l'enveloppe SOAP (par exemple, un message MIME mal formé ou un type de contenu MIME non accepté) le serveur répond alors par un message ERR (voir au paragraphe 7.1 de la [RFC3080]) avec un code de réponse approprié (par exemple, voir la Section 8 de la [RFC3080]).

 	5.	Conformité au cadre de lien de protocole SOAP
 	5.1	Nom de lien
Ce lien est identifié par un URI qui est exactement le même que l'URI de profil pour BEEP dans SOAP (voir la Section 2).

 	5.2	URI de base
L'URI de base pour l'enveloppe SOAP est l'URI de la ressource identifiée dans le message d'amorçage (bootmsg).

 	5.3	Schémas d'échange de message SOAP pris en charge
Une mise en œuvre de ce lien DOIT prendre en charge le schéma d'échange de message (MEP, Message Exchange Pattern) SOAP : "http://www.w3.org/2003/05/soap/mep/request-response/" (voir le paragraphe 6.2 de [SOAP1.2-2])

 	5.4	Caractéristiques prises en charge
Une mise en œuvre de ce lien PEUT prendre en charge la caractéristique suivante : "http://www.w3.org/2003/05/soap/features/action/" (voir le paragraphe 6.5 de [SOAP1.2-2].)

 	5.5	Fonctionnement du MEP
Pour les instances de lien conformes à la présente spécification :
o	un nœud SOAP instancié chez l'homologue BEEP qui a initié l'échange de messages peut assumer le rôle (c'est-à-dire, la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role) de "RequestingSOAPNode" ;(nœud SOAP demandeur)
o	un nœud SOAP instancié chez l'autre homologue BEEP peut assumer le rôle (c'est-à-dire, la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role) de "RespondingSOAPNode" (nœud SOAP répondeur).

 	5.5.1	Comportement du nœud SOAP demandeur
Le flux global du comportement d'un nœud SOAP demandeur suit une description d'automate à états conforme au paragraphe 6.2 de [SOAP1.2-2].

Afin d'éviter un blocage dans l'écoulement de flux (voir le paragraphe 6.2.3 de [SOAP1.2-2]), le nœud SOAP demandeur DOIT être capable de traiter les informations de réponse SOAP entrantes pendant que la demande SOAP est encore en cours d'émission.

 	5.5.1.1	Init
Dans l'état "Init" (initialisation) un message BEEP est formulé conformément à la Section 3, la transmission du message commence, et ensuite l'état passe à "Requesting" (demande).

 	5.5.1.2	Requesting
Dans l'état "Requesting", plus du message de demande est transmis et l'arrivée de la réponse est attendue. Quand le début du message de réponse est reçu, si c'est un message BEEP ERR, l'état passe alors à "Échec" ; autrement, l'état passe à "Sending+Receiving".

 	5.5.1.3	Sending+Receiving
Dans l'état "Sending+Receiving", la transmission du message de demande et la réception du message de réponse sont achevées. Le message de réponse est supposé contenir une enveloppe SOAP mise en série conformément aux règles de transport des messages SOAP dans le type de support donné dans le champ d'en-tête Content-Type. Une fois achevée la réception de la réponse, l'état passe à "Succès".

 	5.5.1.4.	Succès et Échec
"Succès" et "Échec" sont les états terminaux pour l’automate à états.

 	5.5.2	Comportement du nœud SOAP qui répond
Le flux global du comportement d'un nœud SOAP qui répond suit une description d'automate à états cohérente avec le paragraphe 6.2 de [SOAP1.2-2]

 	5.5.2.1	Init
Dans l'état "Init"; le lien attend le début de la demande entrante. Dans cet état, il peut seulement générer des messages ERR (conformément au paragraphe 4.4).

 	5.5.2.2	Receiving
Le lien commence à recevoir le message de demande et prépare le début de la réponse, conformément à la Section 3. Quand il est prêt à transmettre la réponse, l'état passe à "Receiving+Sending".

 	5.5.2.3	Receiving+Sending
Le lien achève la réception de la demande et l'envoi de la réponse et passe ensuite à l'état "Succès".

 	5.5.2.4.	Succès et Échec
"Succès" et "Échec" sont les états terminaux qui indiquent l'achèvement de l'échange de message.

 	6.	Schémas d'URL

Le présent mémoire définit deux schémas d'URL, "soap.beep" et "soap.beeps", qui identifient l'utilisation de SOAP sur BEEP avec TCP. Noter qu'à présent, un schéma "générique" d'URL pour SOAP n'est pas défini.

 	6.1	Schéma d'URL soap.beep
Le schéma d'URL "soap.beep" utilise la syntaxe "URI générique" définie à la Section 3 de la [RFC3986], précisément :
o	la valeur "soap.beep" est utilisée pour le composant de schéma ;
o	l'autorité de désignation fondée sur le serveur définie au paragraphe 3.2.2 de la [RFC3986] est utilisée pour le composant d'autorité ;
o	le composant de chemin se transpose en le composant "ressource" du message d'amorçage envoyé durant l'initialisation du profil (si il est absent, il prend par défaut "/").

Les valeurs des deux schémas et des composants d'autorité sont insensibles à la casse.

Par exemple, l'URL soap.beep://stockquoteserver.example.com/StockQuote peut résulter en l'exemple du paragraphe 2.1.

 	6.1.1	Résolution des informations d'adresse IP/TCP
Le schéma d'URL "soap.beep" indique l'utilisation du profil BEEP pour SOAP fonctionnant sur TCP/IP.

Si le composant d'autorité contient un nom de domaine et un numéro d'accès, par exemple, "soap.beep://stockquoteserver.example.com:1026" alors le DNS est interrogé pour les enregistrements d'adresse (c'est-à-dire "A" pour IPv4, "AAAA" pour IPv6 sur la base des spécifications de résolveur de l'hôte) correspondant au nom de domaine, et le numéro d'accès est utilisé directement.

Si le composant d'autorité contient un nom de domaine et pas de numéro d'accès, par exemple, "soap.beep://stockquoteserver.example.com" l’algorithme d'enregistrement de service [RFC2782] est utilisé avec un paramètre de service de "soap-beep" et un paramètre de protocole de "tcp" pour déterminer les informations d'adressage de IP/TCP. Si aucun RR SRV approprié n'est trouvé (par exemple, pour "_soap-beep._tcp.stockquoteserver.example.com") le DNS va alors être interrogé sur les enregistrements de ressource d'adresse correspondant au nom de domaine et le numéro d'accès utilisé est alloué par l'IANA pour l'enregistrement au paragraphe 8.4.

Si le composant d'autorité contient une adresse IP, par exemple, "soap.beep://192.0.2.0:1026" le DNS n'est pas interrogé et l'adresse IP est utilisée directement. Si un numéro d'accès est présent, il est utilisé directement ; autrement, le numéro d'accès est alloué par l'IANA pour l'enregistrement du paragraphe 8.4.

Alors que l'utilisation des adresses IPv6 littérales dans les URL est déconseillé, si une adresse IPv6 littérale est utilisée dans un URL "soap.beep", elle doit se conformer à la syntaxe spécifiée dans la [RFC3986].

 	6.2	Schéma d'URL soap.beeps
Le schéma d'URL "soap.beeps" est entièrement identique au schéma d'URL "soap.beep" spécifié au paragraphe 6.1, à l'exception qu'avant de commencer le profil BEEP pour SOAP, la session BEEP doit être réglée sur la confidentialité. En particulier, noter que les deux schémas d'URL utilisent des algorithmes et paramètres identiques pour la résolution d'adresse comme spécifié au paragraphe 6.1.1 (par exemple, le même nom de service pour les recherches de SRV, le même numéro d'accès pour TCP, et ainsi de suite).

Il y a deux façons d'effectuer le réglage de confidentialité sur une session BEEP :
o	un profil de sécurité du transport peut être commencé avec succès ; ou
o	un profil d'authentification d'utilisateur qui prenne en charge la sécurité du transport peut être commencé avec succès.

De toutes façons, à l'achèvement du procès de négociation, une réinitialisation des réglages se produit, dans laquelle les deux homologues BEEP produisent un nouvel accueil. Consulter la Section 3 de la [RFC3080] pour un exemple de la façon dont un homologue BEEP peut choisir de produire des accueils différents sur la base de l'utilisation ou non de la confidentialité.

 	7.	Gabarits d'enregistrement
 	7.1	Gabarit d'enregistrement de caractéristique de profil SOAP
Quand est enregistrée une caractéristique pour le profil BEEP pour SOAP, les informations suivantes sont fournies :
Identification de caractéristique : spécifier une chaîne qui identifie cette caractéristique. Sauf si la caractéristique est enregistrée auprès de l'IANA, l'identification de caractéristique doit commencer par "x-".
Sémantique de caractéristique : spécifie la sémantique de la caractéristique.
Informations de contact : spécifient les informations électroniques de contact pour l'auteur de la caractéristique.

 	8.	Enregistrements initiaux
 	8.1	Enregistrement : profil SOAP
Identification de profil : http://iana.org/beep/soap/VERSION
Messages échangés durant la création de canal : bootmsg, bootrpy
Messages commençant les échanges de un à un : bootmsg, une "enveloppe" SOAP
Messages dans les réponses positives : bootrpy, une "enveloppe" SOAP
Messages dans les réponses négatives : error
Messages dans les échanges de un à plusieurs : une "enveloppe" SOAP
Syntaxe de message : une enveloppe SOAP
Sémantique de message : correspond à la spécification SOAP pertinente, par exemple, pou SOAP v1.2, cf. [SOAP1.2-1].
Informations de contact : Eamon O'Tuathail <eamon.otuathail@clipcode.com>, Marshall Rose <mrose@dbc.mtview.ca.us>

 	8.2	Enregistrement : schéma d'URL soap.beep
Nom de schéma d'URL : soap.beep
Syntaxe de schéma d'URL : cf. paragraphe 6.1
Considérations de codage de caractères : cf. syntaxe d'URI générique définie à la Section 3 de la [RFC3986]
Usage de destination : identifie une ressource SOAP rendue disponible en utilisant le profil BEEP pou SOAP
Applications qui utilisent ce schéma : cf. "Usage de destination", ci-dessus
Considérations d'interopérabilité : n/a
Considérations de sécurité : cf. Section 9
Publications pertinentes : cf. [SOAP1.2-1] pour SOAP version 1.2
Informations de contact : Eamon O'Tuathail <eamon.otuathail@clipcode.com>, Marshall Rose <mrose@dbc.mtview.ca.us>
Auteur/contrôleur des changements : IESG

 	8.3	Enregistrement : schéma d'URL soap.beeps
Nom de schéma d'URL : soap.beeps
Syntaxe de schéma d'URL : cf. paragraphe 6.2
Considérations de codage de caractères : cf. syntaxe d'URI générique définie à la Section 3 de la [RFC3986]
Usage de destination : identifie une ressource SOAP rendue  disponible en utilisant le profil BEEP pour SOAP après que la session BEEP a été réglée à assurer la confidentialité
Applications qui utilisent ce schéma : cf. "Usage de destination", ci-dessus
Considérations d'interopérabilité : n/a
Considérations de sécurité : cf. Section 9
Considérations de sécurité : cf. Section 9
Informations de contact : Eamon O'Tuathail <eamon.otuathail@clipcode.com>, Marshall Rose <mrose@dbc.mtview.ca.us>
Auteur/contrôleur des changements : 

 	8.4	Enregistrement : The System (Well-Known) TCP Port Number for SOAP over BEEP
Numéro de protocole : TCP
Formats, types, opcodes, et séquences de message : cf. paragraphe 2.1
Fonctions : cf. [SOAP1.2-1] pour SOAP version 1.2
Utilisation de diffusion/diffusion groupée : aucune
Nom proposé : SOAP dur BEEP
Nom abrégé : soap-beep
Informations de contact : Eamon O'Tuathail <eamon.otuathail@clipcode.com>, Marshall Rose <mrose@dbc.mtview.ca.us>

 	9.	Considérations sur la sécurité

Bien que le provisionnement de service soit une affaire de politique, au minimum, toutes les mises en œuvre DOIVENT fournir les profils de réglage suivants :
pour l'authentification : http://iana.org/beep/SASL/DIGEST-MD5
pour la confidentialité : http://iana.org/beep/TLS (en utilisant le chiffrement TLS_RSA_WITH_AES_128_CBC_SHA)
pour les deux : http://iana.org/beep/TLS (en utilisant le chiffrement TLS_RSA_WITH_AES_128_CBC_SHA prenant en charge les certificats côté client)

De plus, les mises en œuvre peuvent choisir d'offrir les services de sécurité fondés sur MIME fournissant la protection de l'intégrité du message et la confidentialité, comme OpenPGP [RFC3156] ou S/MIME [RFC3851].

De toutes façons, consulter la Section 9 de la [RFC3080] pour une discussion sur les questions de sécurité spécifiques de BEEP.

 	10.	Considérations relatives à l'IANA

L'IANA avait antérieurement enregistré "http://iana.org/beep/soap" pour l'usage de la [RFC3288]. Le présent mémoire demande que l'IANA enregistre un préfixe d'URI de http://iana.org/beep/soap/VERSION pour correspondre à la famille de profils définie au paragraphe 8.1.

L'IANA a enregistré "soap.beep" et "soap.beeps" comme schémas d'URL, comme spécifié respectivement aux paragraphes 8.2 et 8.3.

L'IANA a aussi enregistré "SOAP sur BEEP" comme numéro d'accès TCP comme spécifié au paragraphe 8.4.

L'IANA élargit maintenant ces trois registres pour prendre en charge la famille des profils BEEP définie par ce préfixe d'URL.

Finalement, l'IANA tient une liste de caractéristiques de profil SOAP, cf. paragraphe 7.1. L'IESG est chargé de désigner un expert pour revoir la spécification avant que l'IANA fasse l'allocation. Avant de contacter l'IESG, les développeurs de caractéristiques de profil SOAP doivent utiliser la liste de diffusion beepwg@lists.beepcore.org pour solliciter des commentaires.

 	11.	Changements depuis la RFC 3288

Le présent mémoire diffère de la [RFC3288] d'une façon substantielle : un préfixe d'URL est défini pour prendre en charge une famille de profils BEEP correspondant aux différentes versions de SOAP. De même, les enregistrements de l'IANA aux paragraphes 8.1, 8.3, et 8.4 sont mis à jour pour refléter cet élargissement.

La prise en charge du paquetage W3C MTOM/XOP a été ajouté.

Un nouveau paragraphe a été ajouté pour discuter de l'automate a états réparti du MEP demande-réponse.

Un petit nombre d'erreur typographiques non substantielles ont été corrigées.

 	12.	Remerciements

Les auteurs remercient chaleureusement de leurs contributions Christopher Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, et Roy T. Fielding.

 	13.	Références
 	13.1	Références normatives
[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2616]	R. Fielding et autres, "Protocole de transfert hypertexte -- HTTP/1.1", juin 1999. (D.S., MàJ par 2817, 6585)

[RFC2782]	A. Gulbrandsen, P. Vixie et L. Esibov, "Enregistrement de ressource DNS pour la spécification de la localisation des services (DNS SRV)", février 2000.

[RFC3023]	M. Murata, S. St.Laurent et D. Kohn, "Types de support XML", janvier 2001. (Obsolète, voir RFC7303)

[RFC3080]	M. Rose, "Cœur du protocole extensible d'échange de blocs (BEEP)", mars 2001. (P.S.)

[RFC3156]	M. Elkins et autres, "Sécurité MIME avec OpenPGP", août 2001.(P.S.)

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC3902]	M. Baker, M. Nottingham, "Type de support "application/soap+xml"", septembre 2004. (Information)

[RFC3986]	T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, janvier 2005.

[SOAP1.2-1]	Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-soap12-part1-20030624, juin 2003.

[SOAP1.2-2]	Nielsen, H., Hadley, M., Moreau, J., Mendelsohn, N., and M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC REC-soap12-part2-20030624, juin 2003.

[SOAPmtom]	Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "SOAP Message Transmission Optimization Mechanism", W3C REC REC-soap12-mtom-20050125, janvier 2005.

[XMLbOP]	Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "XML-binary Optimized Packaging", W3C REC REC-xop10-20050125, janvier 2005.

 	13.2	Références pour information
[RFC2387]	E. Levinson, "Type de contenu MIME Multiparti/Relatif", août 1998. (P.S.)

[RFC2392]	E. Levinson, "Localisateur de ressource uniforme d'identifiant de contenu et d'identifiant de message", août 1998. (P.S.)

[RFC2557]	J. Palme, A. Hopmann et N. Shelness, "Encapsulation MIME de documents agrégés, tels que HTML (MHTML)", mars  1999.

[RFC3288]	E. O'Tuathail, M. Rose, "Utilisation du protocole simple d'accès à un objet (SOAP) dans le protocole extensible d'échange de blocs (BEEP)", juin 2002. (Obsolète, voir RFC4227) (P.S.)

[SOAP1.2-0]	Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C REC REC-soap12-part0-20030624, juin 2003.

[SOAPMA]	Barton, J., Thatte, S., and H. Nielsen, "SOAP Messages with Attachments", W3C NOTE NOTE-SOAP-attachments-20001211, décembre 2000.

[SOAPNote]	Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-SOAP-20000508, mai 2000.

 	Appendice A.	SOAP avec pièces jointes (Information)

Pour assurer la compatibilié avec la [RFC3288], un profil BEEP pour SOAP PEUT permettre que les enveloppes soient transmises par la partie racine d'un contenu "multipart/related" [RFC2387], et avec les parties subordonnées référencées en utilisant les règles de la Section 3 de [SOAPMA] (c'est-à-dire, en utilisant les en-têtes soit "Content-ID:" [RFC2392] soit "Content-Location:" [RFC2557]), par exemple,

MSG 1 2 . 278 657
Content-Type: multipart/related; boundary="MIME_boundary";
              type=application/xml;
              start="<claim061400a.xml@claiming-it.com>"

--MIME_boundary
Content-Type: application/xml
Content-ID: <claim061400a.xml@claiming-it.com>

<?xml version='1.0' ?>
<env:Envelope
     xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 ..
</env:Header>
<env:Body>
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com" />
  ..
</env:Body>
</env:Envelope>

--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>

 ...binary TIFF image...
--MIME_boundary--
END

Conformément à la Section 2 de [SOAPMA], il est fortement recommandé que la multipartie contienne un paramètre "start", et que la partie racine contienne un en-tête "Content-ID:". Cependant, parce que BEEP fournit un chemin de 8 bits de large, un codage de transfert de contenu "transformatif" (par exemple, "base64" ou "quoted-printable") ne devrait pas être utilisé. Noter de plus que MIME [RFC2045] exige que la valeur de l'en-tête "Content-ID" soit unique au monde.

 	Adresse des auteurs

Eamon O'Tuathail	Marshall T. Rose	
Clipcode.com	Dover Beach Consulting, Inc.	
24 Thomastown Road	POB 255268	
Dun Laoghaire	Sacramento, CA  95865-5268	
Dublin	US	
		
téléphone : +353 1 2350 424	mél : mrose@dbc.mtview.ca.us 	
mél : eamon.otuathail@clipcode.com 		
URI :   http://www.clipcode.com/ 		

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .
L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org .

Remerciement 
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.