Skip to main content
La position d’OxiMail est simple : une extension de protocole qui mérite d’être livrée mérite d’être spécifiée. Chaque surface d’extension que le serveur sert sous urn:oximail:params:jmap:* est en cours de rédaction comme Internet-Draft destiné à être soumis à l’IETF, dans la tradition JMAP où la spécification et une implémentation réelle et déployée se développent l’une contre l’autre.

​
La discipline

Le programme de spécification suit une méthodologie publiée (docs/jmap-v2-amendments-discipline.md dans le dépôt du serveur) : chaque changement du serveur qui touche une surface spécifiée se termine par un audit de conformité contre le texte du draft, et chaque divergence trouvée est tranchée explicitement. Le code suit le draft, ou le draft est amendé pour coller à la réalité, ou les deux ont tort et les deux changent. Les divergences ne sont jamais laissées « à régler plus tard » ; le corpus de drafts reste fidèle au code par construction, et c’est ce qui le rend digne d’être soumis.

​
Les domaines couverts

Le corpus de drafts en cours couvre, au niveau de détail qui convient avant soumission :
  • Le chat sur JMAP : les salons, les messages, les accusés, et le modèle de capacité, tels que servis aujourd’hui.
  • Les appels en temps réel : l’objet de session ancré sur un salon, le bail d’adhésion, et le relais qui transporte une poignée de main WebRTC entre participants sans jamais la stocker.
  • La fédération de serveur à serveur : comment deux serveurs JMAP indépendants échangent et déposent du contenu pour les utilisateurs l’un de l’autre. Un nœud est authentifié par la clé que son pair a épinglée à l’appairage, et requêtes comme réponses sont signées par HTTP Message Signatures (RFC 9421) ; l’ancienne option de transport mtls-dane a quitté le texte, puisqu’elle n’a jamais existé dans le serveur. Un domaine qui fédère annonce son point d’entrée sous son propre enregistrement _jmap-federation._tcp, distinct du _jmap._tcp des clients. Le serveur implémente la lecture de disponibilité relayée et le profil Drive en lecture seule (FileNode/get, /query, /changes et le contenu par blocs signés) ; le dépôt est spécifié, pas servi (fédération).
  • La sémantique de remise et de dépôt : un profil mince des primitives de fédération pour le dépôt de messages.
  • La garde documentaire : la rétention et le classement immuable, bâtis sur la même primitive de dépôt.
  • Le transfert de propriété de collection : déplacer une collection partagée fédérée (un salon de chat, un calendrier partagé) d’un serveur à un autre quand l’organisation propriétaire ferme, fusionne ou change d’opérateur, pour qu’une collection partagée vivante reste portable au lieu d’être captive de son hôte.
  • Le journal d’audit infalsifiable : le journal d’événements en ajout seul, chaîné par SHA-256, et sa vérification, séparés de la politique de ce qu’un déploiement choisit de journaliser.
  • Les surfaces de modernisation v2 : les familles de capacités décrites sur la page JMAP v2.
Le chiffrement de bout en bout ne fait pas partie du corpus. OxiMail ne l’implémente pas (le serveur lit ce qu’il stocke, et la protection au repos est celle du volume, voir chiffrement au repos), et le draft qui le décrivait a été retiré de l’ensemble publié en septembre 2026.

​
Statut

Pré-soumission. Les drafts sont des documents de travail dans le dépôt du serveur, qui évoluent avec l’implémentation ; la passe de pré-soumission (relecture éditoriale, réconciliation des amendements, considérations IANA) est la porte avant le premier draft-*-00 dans le datatracker de l’IETF. Cette page liera chaque draft au moment de sa soumission. D’ici là, le fil servi fait référence : tout ce que les drafts décrivent se détecte depuis les capacités de session d’un serveur qui tourne, et les pages développeur de ce site documentent le comportement tel que construit.