Discussion:IG missive
Pourriez-vous me dire à quoi sert la balise RcvDtTm dans la missive ?
91.135.184.215 7 août 2012 à 17:21 (CEST)
Oui, à stocker la date et heure de réception de la missive par son destinataire. --Olivier.jousselin (discussion) 7 août 2012 à 17:42 (CEST)
Missive de type Acquittement (1206)
Quel est l'intérêt de conserver le type de missive Acquittement alors que l'on ajoute Acknowledgment ? (dans la mesure où la compatibilité entre 1202 et 1206 est d'ores et déjà cassée).
Aucun sans doute, mais en quoi est-ce vraiment gênant ?
Olivier.jousselin (discussion) 17 octobre 2012 à 18:21 (CEST)
Ce n'est probablement pas *vraiment* gênant mais ça introduit un doute qui pourrait être évité
Je vais ajouter ceci comme Change Request pour une future version.
Olivier.jousselin (discussion) 19 octobre 2012 à 08:39 (CEST)
Use of acknoledgement missive
Dans le paragraphe "Use of the acknowledgement missive", la troisième phrase commence par "Generally", cela signifie-t-il que, dans certains cas, l'identifiant de la missive d'acquittement et son numéro d'ordre sont différents de ceux de la missive nominale à acquitter ? Si oui quels sont ces cas ?
Dans la phrase d'après, que signifie "the non-acknowledgement of all lower ranks" ? Par "non-acknowledgement" entend-on "absence d'acquittement" ou "acquittement négatif" ?
Quels sont les cas particuliers évoqués dans la proposition "except in special cases (detailed non-acknowledgement already sent, for instance)" ? Que signifie "non-acknowledgement already sent" ?
matthieu.dambrin (discussion) 5 novembre 2012 à 13:32 (CEST)
Concrètement, l'acquittement SEPAmail est multi-forme...
L'acquittement pose de nombreux problèmes aux implémenteurs, à juste titre à mon sens...
Voilà quelques unes des problématiques rencontrées :
- le serveur SEPAmail en réception est innaccessible, comment je renvoie un code 432 ?
- quels sont les équivalents d'un code retour smtp 550 en mode flash ? Sur quelle couche l'implémenter ?
- pourquoi devrais-je acquitter une enveloppe non signée correctement, une missive non conforme au schéma et comment le faire puisque je ne suis pas alors censé accéder au contenu de la missive ? Dois-je envoyer une missive d'acquittement pré-fabriquée (comme le fait le CMCIC) ? Dois-je envoyer un code smtp et lequel en mode canonique ? Dois-je envoyer une Soap-Fault en mode falsh SOAP ?
- qu'apporte réellement l'acquittement sepamail ? Il est souvent comparé à l'accusé réception de la poste, pourquoi ?
- Pourquoi est-il rappelé dans la missive "SMIRK MIS1202" des contrôles à réaliser sans définir comment le système de réception doit réagir en cas de contrôle négatif ?
- Pourquoi est-il rappelé dans la directive d'implémentation "Reciprocally, an acknowledgement missive is only used to transmit information about the routing of a nominal missive, or about the sender or recipient addresses." ? Comment acquitter les autres cas ? Pourquoi la liste des codes retour décrit-elle des codes en dehors de ces deux fonctionnalités (routage et adressage)
- Que signifie la mention "Generally, the missive identifier and rank, in the missive header, must match exactly those of the nominal missive it acknowledges." ? Cela autorise-t-il des missives pré-fabriquées, un peu comme les erreurs 404 ou 500 du protocole HTTP ? Quels sont les cas où nous ne sommes pas dans le cas général ?
Le groupe "Norme" discute de ces sujets en ce moment.
Je crois utile que chaque implémenteur (moa, moe et exploitant) donne son retour d'expérience sur ces sujets.
Manfred S. OLM, cabinet deciBI (discussion) 18 décembre 2012 à 11:55 (CET)
Usage rule sur l'identifiant de la missive
"Usage Rule The format of this identifier is YYYYMMDDhhmmssxxx + "_" + sender_id The first part is the creation date and time, including milliseconds The second part can be used freely by the sender."
Ceci pose plein de problème à l'implémentation et confond allégrement identifiant et classe/nomenclature.
Je propose pour s'en sortir de lire cette magnifique usage rule qui contredit la notion même d'identifiant en supposant que la "creation date and time" soit celle de SEPAmail, c'est à dire le 1er avril 2008 vers 13h14 pour tous, comme cela, on en sera quitte pour un poisson d'avril à expliquer aux implémenteurs
donc 20080401131415926
Manfred S. OLM, cabinet deciBI (discussion) 20 février 2014 à 14:14 (CET)
PriorityCode et RoutingWarning
Le type PriorityCode est une énumération pouvant prendre les valeurs suivantes :
- HIGHEST
- HIGH
- NORMAL
- LOW
- LOWEST
Le type RoutingCode est une énumération pouvant prendre les valeurs suivantes :
- BAD_TIME
- PRIO_HIGH
- PRIO_NORM
- PRIO_LOW
- PRIO_XLOW
On peut mettre plusieurs routing code dans la balise RoutingWarning, ce qui permet bien de dire que le serveur pair n'est pas à la bonne heure et que l'on va traiter la missive en changeant sa priorité.
Mais que signifie l'utilisation conjointe de PRIO_HIGH et PRIO_XLOW ?
De plus, je trouverai cela normal que l'on ne présume pas de la possibilité de ne traiter qu'avec la priorité très haute, donc il faudrait rajouter le ode PRIO_XHIGH.
Manfred S. OLM, cabinet deciBI (discussion) 13 mars 2014 à 10:20 (CET)