Cet acquittement est obligatoire dans tous les cas pour tous les fournisseurs d'accès à SEPAmail, quel que soit l'expéditeur et le destinataire, dans les cas où l'acquittement est possible.
Ces règles sont décrites dans la directive d'implémentation de la missive.
Cet acquittement permet à l'expéditeur du message, ainsi qu'à son fournisseur d'accès à SEPAmail d'être assuré :
- de la bonne réception du message émis (contenu dans une missive nominale), réception, horodatage, validité, authentification des fournisseurs d'accès et de sécurité SEPAmail
- du routage qui sera réalisé vers le destinataire du message (défini par l'entête de la missive)
- de la capacité de distribution du message au destinataire
L'acquittement se présente sous la forme d'un statut succès (ACK) ou échec (NAK) avec, facultativement, un code de retour pour expliquer le statut. Ces codes retour sont décrits ici et sont tous valides sauf ceux correspondant au sujet 4, à savoir les codes 541, 248, 249 (ces trois codes ont été utilisés dans le cadre de l'expérimentation mais ils ne correspondent pas à des retours possibles pour une messagerie; ils sont liés à l'application de SEPAmail RUBIS).
Comme pour tout protocole en couche, il est important que la messagerie SEPAmail ne se substitue pas aux couches au dessus et en dessous (en amont et en aval du traitement) pour son action.
Prenons un exemple dans le cadre d'une demande de règlement RUBIS pour bien comprendre la portée de l'acquittement.
Supposons qu'une personne A veuille transmettre à une personne B une demande de règlement.
Les fournisseur d'accès a SEPAMail de A (FasA) et B (FasB) leur proposent le service RUBIS.
Voici trois cas d'usage de réception par FasB de la missive nominale contenant la demande de réglement :
- cas 1 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest n'étant pas conforme au schéma XML
- cas 2 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest conforme au schéma mais pas à la directive d'implémentation RUBIS de ce message
- cas 3 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivtationRequest conforme au schéma et à la directive d'implémentation RUBIS du message avec une seule demande de paiement en trois fois que FasB ne propose pas à son client B
Remarque : on voit par ce retour que SEPAmail permet d'acquitter la présence d'un message conforme (au sens des schéma XML) au sein de la missive, ce qui dépasse en fontionnalité l'accusé de réception postal.
Le cas 2 pourrait être, par exemple, un champ PaymentMethod à CHQ alors que ce champs, au sein du pain.013 est annoncé dans la directive d'implémentation comme "Mandatory. The only value currently accepted here is "TRF". Note : if the OtherPmtMtd field, in the non-ISO part, is used, this field will be ignored"ou un élément ChargeBearer qui ne serait pas à la valeur "SLEV" comme exigé par l'implémentation de RUBIS.
Ce cas ne relève pas de la messagerie SEPAmail puisque le message PaymentActivationRequest est intègre du point de vue de son schéma.
C'est l'application RUBIS de SEPAmail qui doit (ou peut) répondre. Si FasB pense que c'est une bonne idée dans sa relation avec FasA de boucler le processus, FasB devrait donc préparer un PaymentActivationReport négatif avec une mention de non prise en charge des ces options de la demande de règlement pour non conformité à la norme RUBIS.
Le cas 3 est cas de conformité à la norme SEPAmail et à la norme RUBIS non pris en charge par FasB. FasB est donc peut-être dans l'impossibilité de transmettre le message et prendre en charge la demande fonctionnelle associée à ce message.
Selon les cas de la relation et du contrat que FasB et B ont signé, FasB peut:
- transmettre le message pour seule prise en compte du signifiant,
- répondre pour le compte de son client de façon négative en motivant le refus
- ne rien faire
Dans les cas 2 et 3, la missive nominale a été acquittée normalement (code retour 219) car la missive a bien été reçue conforme et relayée en terme de messagerie.
Certains sont tentés de reporter l'impossibilité fonctionnelle du fournisseur d'accès à SEPAmail de transmettre le message (ce message ne répond pas à la norme RUBIS ou le cas n'est pas traité par le fournisseur d'accès du destinataire) au sein de l'acquittement de la messagerie.
Il ne faut pas céder à cette tentation, au risque de confondre la couche SEPAmail (messagerie) et la couche RUBIS (application de SEPAmail). En faisant cela, on dénature l'acquittement et son intérêt en terme d'accusé réception.
SEPAmail.eu pourrait, à mon sens, pour lever les ambiguités sur ce sujet :
- préciser des cas d'usage, pour bien expliquer l'interprétation qui doit être faite de la norme autour de l'acquittement
- séparer la norme de messagerie SEPAmail de chacune des normes des applications utilisant SEPAmail
- enlever les scories due à l'expérimentation, comme les codes retour d’acquittement de sujet 4
5 commentaires:
Il me semble que la portée de l'acquittement va un peu plus loin dans les engagements réciproques entre adhérents.
L'acquittement joue le rôle d'accusé de réception d'un message reçu.
Ainsi, à partir du moment où FasB transmet un acquittement à l'adhérent expéditeur, il s'engage à remettre le message à son destinataire.
Dans le cas où il n'est pas en mesure de remettre ce message, il me semble qu'il devrait être tenu d'en informer l'expéditeur.
De quels engagements réciproques parle-t-on ?
De l'engagement SEPAmail ou de l'engagement RUBIS ?
Quelle est exactement la nature de la fonction "remettre un message" ?
Il y a, de toute façon, des cas d'usage qui sont difficiles à dénouer ou boucler de façon universelle.
C'est pour cela qu'il y a une couche messagerie distincte de la couche applicative.
Selon ma compréhension des deux couches, le cas d'un message non conforme aux directives d'implémentation de RUBIS doit être dénoué sur la couche applicative et non la couche messagerie.
L'acquittement ne porte, à mon sens, pas sur le message, mais sur la missive, qui est l'élément de routage dans SEPAmail.
Le destinataire accuse réception d'une missive conforme à la norme, en termes de cryptographie, de contenu et de capacité à la traiter -- en tant que missive.
Le traitement peut être, soit un routage (acquittement de transfert), soit une mise à disposition du client, soit une capacité à répondre (cas de DIAMOND), d'autres cas étant envisageables.
Dans l'absolu, le SMART ne devrait pas avoir connaissance du message. Ceci interdit donc, de façon assez formelle, à la missive d'acquittement de se fonder sur un élément du message pour déterminer le type d'acquittement.
Tout le reste doit se faire au niveau applicatif, donc par le biais d'un message de réponse.
Précision pour le néophyte : SMART est décrit sur ce billet
La génération de la missive d'acquittement nécessite certaines informations de la missive originelle.
Or, dans le cas où le message n'est pas conforme à un schéma XML défini pour la norme, la missive qui incorpore ce message ne l'est pas non plus !
Tout dépend du mode de parsing utilisé pour analyser la missive. en DOM, cela devrait échouer. en SAX, il y a peut-être des chances de récupérer quelque chose.
Enregistrer un commentaire