Resumen
- La revisión 03 de EPP Balance es un Internet-Draft activo de REGEXT, no un RFC ni una prueba de uso en producción.
- El saldo disponible suma línea de crédito y saldo de caja, pero el límite de ejecución decide cuándo se bloquean futuras operaciones facturables.
- La consulta es una observación de solo lectura. No congela el valor, no reserva capacidad y no sustituye la respuesta de la orden posterior.
Imagine tres semáforos en la misma pantalla. El primero indica que hay 800 dólares disponibles. El segundo avisa que la cuenta se acerca a un umbral. El tercero decide si una nueva orden facturable puede pasar. Si una interfaz pinta solo el primer semáforo en verde, no simplifica el protocolo: borra su mecanismo de control.
draft-ietf-regext-balance-03 propone que un cliente EPP autenticado recupere uno o varios Balances. Cada uno puede llevar un nombre definido por la política del servidor y su propia moneda principal. Dentro de ese contenedor aparecen magnitudes relacionadas, pero no intercambiables.
Balance Available es la suma de Credit Line y Cash Balance. La línea de crédito reúne los instrumentos activos que el servidor reconozca, como crédito ordinario o de emergencia. Puede aumentar o disminuir aunque no haya un ingreso o retiro de efectivo. Cash Balance sí refleja pagos y movimientos facturables, incluidos tasas e impuestos. Que ambas piezas produzcan un número positivo no convierte ese número en una bolsa de dinero inmóvil.
La barrera se expresa en Execution Limit. Puede basarse en Balance Available o en Cash Balance. Con una cifra positiva, el servidor bloquea antes de agotar el saldo para conservar un colchón ante autorrenovaciones u otros cargos iniciados por él. Con una cifra negativa, permite cierto gasto más allá de cero. Por eso «saldo positivo» y «orden admisible» no son equivalentes.
Notification Threshold sirve para otra cosa. Al alcanzarlo, el servidor inserta un único mensaje de saldo bajo en la cola EPP del Balance afectado. El umbral usa la misma base que el límite de ejecución, pero es una señal anticipada. El mensaje no demuestra que una orden haya sido rechazada, que la factura sea correcta o que la contraparte sea insolvente. Solo prueba la emisión de una alerta según el estado calculado por el servidor.
La multiplicidad introducida en la revisión 03 refuerza el problema de identidad. Un registrador puede tener cuentas separadas por TLD, contrato o divisa. Dos cuentas pueden estar denominadas en USD y una tercera en EUR; cada una conserva su propio crédito, límite y umbral. Extraer los números sin su nombre y moneda crea un falso saldo general. La precisión decimal sobre el objeto equivocado sigue siendo error.
El detalle multimoneda tampoco es una cotización ejecutable. Los elementos cashBalanceByCurrency pueden mostrar moneda original, importe y tipo de conversión directa empleado para formar el Cash Balance principal. Sirven para reconstruir el agregado. No fijan el tipo para la siguiente orden, para la factura definitiva ni para la liquidación.
La propia arquitectura EPP evita confusiones si se respeta. RFC 5730 separa las consultas de solo lectura de los comandos que transforman objetos. La extensión Balance define <info> y mensajes <poll>, pero no define create, update, renew, delete o transfer para el Balance. Tampoco introduce una reserva, un identificador de retención, un plazo de cotización o una condición atómica que conecte la foto con un comando futuro.
Entre ambos instantes pueden aparecer débitos concurrentes, devoluciones, depósitos, retiros, cambios de crédito o cargos automáticos. El servidor deberá responder a la orden posterior con su resultado propio. Esa respuesta, no la pantalla anterior, es el recibo de la decisión de admisión.
La separación también protege la responsabilidad. Autenticarse permite consultar la información financiera del cliente conectado, y el borrador exige control de acceso porque esos datos son confidenciales. La autenticación no certifica la política comercial, la corrección contable, el tipo de cambio, la factura ni el mandato para comprometer a una empresa.
La revisión fue publicada el 24 de septiembre de 2026 como trabajo de REGEXT con intención de Standards Track. El espacio de nombres balance-0.4, el esquema y las solicitudes a IANA son piezas de una propuesta interoperable. No son prueba de aprobación final, despliegue, adopción ni resultado financiero observado.
Fuentes
- IETF Datatracker — EPP Balance Mapping
- IETF Datatracker — revisión 03
- Archivo IETF — revisión 03
- Anuncio del Internet-Draft del 24 de septiembre de 2026
- Índice de discusión de REGEXT
- IETF 124 — presentación EPP Balance Mapping
- Actas REGEXT de IETF 126
- RFC 5730 — Extensible Provisioning Protocol
- RFC 7451 — registro de extensiones EPP
- RFC 8748 — extensión de tarifas de registro para EPP
- IANA — parámetros EPP
- Heng Lu — On Reality Layers
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

