Q6.1 : Renvoi, doit-on changer la date ?
La question peut se poser ainsi : si je renvoie une missive comme cela est possible, est-ce que je change la date ?
Une réponse rapide est : NON, on ne change que l'ordre quand on renvoie une missive, en l'incrémentant de un.
Voici une explication détaillée de cette réponse rapide :
On trouve la règle à appliquer dans la directive d'implémentation de la missive :
""If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged."
Quel est le sens de cette règle ?
Pour le comprendre, il faut une petite explication :
- Le message SEPAmail, c'est le signifiant échangé entre les utilisateurs
- La missive SEPAmail, c'est l'enveloppe de messagerie du réseau privé SEPAmail
- L'enveloppe SEPAmail, c'est l'enveloppe de sécurité en cas de transport (mode flash ou canonique) sur un réseau public.
- cette double encapsulation,
- une authentification des parties par les relais,
- un accusé de réception par l'adhérent pour le compte de son utilisateur, quelque soit le cas d'usage (l'application, le nombre d'acteurs...)
- une forme de "garantie" pour un utilisateur émetteur que son envoi sera acquittée (renvoi, escalade, acquittement obligatoire 24/24 7/7 par l'adhérent récepteur selon la priorité)
Par contre, acquitter une missive, c'est obligatoire.
Quand l'émetteur renvoie une missive, voilà ce qu'il dit à son récepteur de missive : "je vous ai déjà émis une missive pour telle personne à telle heure. Comme mon système n'a pas encore enregistré d'accusé réception et que j'ai besoin de cet accusé de réception, je vous renvoie, comme j'en ai la possibilité, la même missive. Pour vous signifier que c'est un renvoi, j'incrémente de 1 l'ordre de la missive. Merci de m'acquitter, comme vous en êtes obligé en tant qu'adhérent, cette missive et les précédentes, si vous les avez reçues."
Quand on raisonne sur ces sujets, il faut absolument ne pas vouloir connaître le statut précis ou le comportement précis de son interlocuteur; mais appliquer le protocole de son point de vue.
Celui qui spécifie le composant qui envoie et reçoit les missives des parties, doit, bien entendu imaginer tous les cas, dont celui pour lequel la contrepartie essaie de frauder ou pour lequel la contrepartie a un système défaillant. Des systèmes de régulation de ces comportements sont présents dans SEPAmail et dépasse le simple cadre de l'acquittement des missives. Pour mémoire, ce sont l'engagement contractuel des adhérents, le procédé d'escalade, la surveillance du réseau par SEPAmail.eu.
Q6.2 : Pourquoi y a-t-il Acquittement et Aknowledgement dans les types de missives ?
Les schémas XML autour de SEPAmail sont écrits en anglais, pour pouvoir être lus par tous. Les types de missives étaient écrits en français, ce qui ne posait pas de problème pour Service, Nominal et SMAPI qui sont équivalents en anglais mais ce n'est pas le cas pour Acquittement.
En 2010, le committer a donc accepté ma demande de transformer Acquittement en Aknowledgment, tout en conservant Acquittement à des fins de rétro-comptabilité. Les deux termes sont donc équivalents, comme annoncé dans la directive d'implémentation de la missive.
La règle implicite est donc la suivante :
Tout composant mettant en œuvre le standard SEPAmail DOIT accepter en réception les types Acquittement et Aknowledgment.
Mon conseil est de rajouter :
Tout composant mettant en oeuvre le standard SEPAmail DEVRAIT utiliser en émission le type Aknowledgment.
Q6.3 Où peut-on trouver des exemples de flux ?
Cette question revient souvent; elle est tout à fait licite.
J'ai créé en 2013 un espace communautaire pour partager nos exemples.
Il se trouve sur la plateforme google code et a pour petit nom SMITE : SEPAmail I want TEst !
L'espace pourrait être augmenté de nos exemples.
Le problème de chacun est de savoir si son exemple est bien conforme à:
- les schémas XML
- les directives d'implémentation
- les règles opérationnelles entre les adhérents
Pour le premier point, c'est facile puisque tous les outils existent et les schémas sont publiés et stables.
Pour le deuxième point, les directives d'implémentation sont publiées mais certaines règles semblent être encore porteuses d’ambiguïté. La démarche est donc de demander au comitter SEPAmail via l'espace communautaire son avis, soit en direct, soit par la fonctionnalité discuter du wiki.
Pour le troisième point, c'est plus compliqué car ces règles ne sont pas publiées. Pour les avoir consultées, je peux vous assurer qu'il n'y a peu de règles qui touchent aux flux messages ou missive dedans (la taille maximale des flux acceptée pour le moment) mais plus des règles pour connecter entre elles les infrastructures et piloter la mise en production après expérimentation.
Je propose à tous ceux qui souhaitent partager leurs exemples de les aider dans leur démarche. N'hésitez pas à me contacter.
Ces pages sont également ouvertes pour ceux qui désirent partager un billet sur ces sujets.
Je souhaite que nous ne faisions pas comme d'autres communautés à écrire les règles sans partager des exemples qui facilitent leur compréhension.
Q6.4 SEPAmail et RUBIS, c'est la même chose ?
SEPAmail est une messagerie sécurisée fournie par des adhérents SEPAmail à leurs clients ou leurs agents, ceux que l'on appelle des utilisateurs SEPAmail.
RUBIS, comme GEMME, JADE, DIAMOND, sont des applications de SEPAmail qui répondent à un besoin précis des utilisateurs.
Donc, SEPAmail et RUBIS ne sont pas la même chose. Les utilisateurs ne devraient pas entendre parler de RUBIS puisque les cinq adhérents actuels se sont entendus sur la notion de "règlement (via) SEPAmail" pour parler de RUBIS. RUBIS reste un nom de code interne à la communauté SEPAmail.
Q6.5 Quelle est la limite en taille d'un message, d'une missive, d'une enveloppe ?
C'est l'une des exceptions à ce que j'ai dit plus haut. La limite a été fixée dans les règles opérationnelles et elle est de 200kos pour l'enveloppe SEPAmail, c'est à dire trop peu. En effet, comme un fichier pdf (par exemple une facture) est encapsulé dans un message SEPAmail, puis une missive SEPAmail et enfin une enveloppe SEPAmail.
Q6.6 SEPAmail, c'est une norme, un standard, un protocole ?
SEPAmail est un protocole, puisqu'il précise un ensemble de règles pour des acteurs qui cherchent à organiser entre eux une fonctionnalité.
Les français distinguent la norme du standard : la norme est un texte normalisé par un organisme de normalisation reconnue (ou officiel). Le standard est un texte utilisé par une communauté.
Si on reconnait SEPAmail.eu comme un organisme de normalisation officiel, alors SEPAmail est une norme. Ce n'est à mon avis pas encore le cas.
Il existe aujourd'hui une communauté de fait autour de SEPAmail, c'est donc bien un standard de fait.
Q6.7 Quel est le statut de votre blog et de vos réponses ? Puis-je m'y fier ?
Notre blog (nous sommes pour le moment deux rédacteurs) se veut un point de rassemblement de ceux qui participent à la communauté SEPAmail (les lecteurs) et de ceux qui veulent partager des points de vues et des informations sur SEPAmail (les rédacteurs, les interviewés...).
Le blog n'est pas le blog officiel de SEPAmail.eu.
Les éclairages amenés n'engagent donc pas SEPAmail.eu et n'engagent, d'une manière générale, que leur auteur.
Il n'y a pas de comité de validation des billets rédigés.
Comme le blog est lu et (de temps en temps) commenté, vous pouvez, à mon sens, vous fier à ce qui est écrit et vous forger une opinion sur son contenu.
Les deux auteurs sont :
- Olivier Jousselin, comitter du standard de 2009 à 2013, rédacteur de la SMIRK Jade en 2013
- Manfred Olm, co-auteur du premier draft en 2008, de quelques SMIRKs en 2011 et 2012, missionné de 2010 à 2012 pour réaliser le contrôle de cohérence entre le standard et les expérimentations ayant été réalisées.
Nous partageons ainsi avec vous le plaisir que vous avez, nous l'espérons.
Aucun commentaire:
Enregistrer un commentaire