Résumé

  • draft-ietf-regext-balance-03 décrit une consultation financière EPP en lecture seule ; il reste un Internet-Draft actif et ne prouve aucun déploiement.
  • Le montant disponible, la trésorerie, la ligne de crédit, la limite d’exécution et le seuil de notification n’ont ni la même fonction ni la même autorité.
  • La réponse <info> photographie un état. Elle ne bloque pas une somme et ne garantit pas l’acceptation de la prochaine opération facturable.

Un opérateur voit 800 dollars disponibles et prépare une série de renouvellements. Rien, dans le nombre 800, ne dit encore combien de commandes seront admises. Cette apparente contradiction est précisément ce que la nouvelle cartographie EPP permet de rendre explicite.

Le Balance Available résulte de l’addition entre Credit Line et Cash Balance. La première composante dépend d’instruments de crédit actifs, choisis selon la politique du serveur. La seconde évolue avec les paiements, retraits, débits et crédits facturables, taxes et frais compris. Un crédit d’urgence peut expirer sans qu’un centime quitte le compte ; le disponible baisse néanmoins. Une valeur positive n’est donc pas synonyme d’espèces détenues pour le client.

La frontière de décision se trouve ailleurs : l’Execution Limit. Le serveur peut la calculer sur le disponible ou sur la trésorerie. Zéro est la valeur par défaut, mais une limite positive réserve une marge avant épuisement, par exemple pour des renouvellements automatiques déclenchés par le serveur. Une limite négative autorise au contraire des opérations au-delà de zéro. Deux comptes affichant le même disponible peuvent ainsi offrir des capacités d’exécution différentes.

Le Notification Threshold arrive encore plus tôt. Lorsqu’il est atteint, le serveur place un message unique de solde faible dans la file EPP du compte concerné. Le seuil partage la même base que la limite d’exécution, mais il ne constitue pas cette limite. Recevoir l’alerte prouve qu’un message a été mis en file. Cela ne prouve ni refus de commande, ni dette exigible, ni facture juste, ni règlement.

La révision 03 complique utilement le tableau en autorisant plusieurs Balances dans une même relation client-serveur. Le nom du compte est alors unique. Un compte « principal » peut être en dollars, un autre en euros, un troisième porter une politique commerciale propre. Le message de solde faible peut désigner plusieurs comptes. Si un logiciel enlève le nom, la devise ou l’attribut basedOn, il conserve les chiffres tout en détruisant leur contexte de décision.

Les soldes multidevises demandent la même prudence. Le serveur peut communiquer chaque composante dans sa devise d’origine, son montant et le taux direct ayant servi à produire la trésorerie dans la devise principale. Cette transparence explique un calcul passé ou courant. Elle ne transforme pas le taux en cotation ferme pour la prochaine création de domaine, en taux de règlement ni en couverture du risque de change.

La sémantique EPP trace une ligne nette. Cette extension définit une commande d’information et des réponses de file d’attente. Elle ne définit aucune création, mise à jour, suppression, renouvellement ou transfert du Balance. RFC 5730 classe <info> parmi les requêtes en lecture seule et impose une réponse propre à chaque commande ultérieure. Le projet n’ajoute ni réservation, ni jeton de dépense, ni durée de validité d’une cotation, ni condition atomique reliant la photographie à la transformation suivante.

Entre la consultation et l’action, un autre débit peut intervenir, un remboursement être porté, une ligne de crédit expirer ou un renouvellement automatique consommer la marge. La réponse financière reste vraie pour le moment et le compte qu’elle décrit. Elle ne transporte pas dans le temps l’autorité de la future réponse EPP.

Cette distinction suit une règle plus générale : une représentation n’est pas encore une décision, et une décision n’est pas encore un résultat commercial. La couche de lecture rend la politique visible. Le serveur, au moment de la commande facturable, rend le verdict d’admission. L’objet enregistré, la facture et le règlement appartiennent à des couches ultérieures, chacune avec sa preuve.

Enfin, le statut documentaire doit rester visible. La révision 03, publiée le 24 septembre 2026, est un travail du groupe REGEXT avec l’intention Standards Track. Un schéma valide, un espace de noms ou une demande d’enregistrement IANA ne prouvent ni approbation finale, ni implémentation, ni usage réel, ni exactitude financière.

Sources