Кратко

  • draft-ietf-regext-balance-02 позволяет вошедшему в систему клиенту EPP запросить доступный баланс, денежный остаток, кредитную линию, а также необязательные предел исполнения и порог уведомления.
  • Ответ пригоден для автоматизации, но не содержит проводок, времени расчёта, происхождения валютного курса, версии политики и зарезервированных обязательств, которые сформировали число.
  • Если баланс влияет на разрешение платной команды, реестру и регистратору следует хранить отдельную квитанцию финансового состояния, связанную с сессией, правилом и результатом. Это предложение по управлению, а не требование проекта IETF.

Перед праздниками регистратор запускает пакет продлений. Запрос баланса возвращает положительное значение. Несколько команд проходят, следующая получает финансовый отказ. У эксплуатации есть идентификаторы EPP, у бухгалтерии — внутренний журнал, у поддержки — возможно, снимок экрана. Однако ни один из этих фрагментов не показывает, какие списания, резервы, курсы и пределы действовали в момент отказа.

Это не обязательно ошибка арифметики. Так проявляется граница между операционным протоколом и закрытой учётной системой за ним.

Редакция 02 проекта была опубликована 14 августа 2026 года как действующий документ рабочей группы REGEXT с предполагаемым продвижением по стандартному треку. Это всё ещё Internet-Draft, а не RFC; он также не доказывает внедрение каким-либо конкретным реестром.

Стандартизация полезна: регистратору не должны быть нужны несовместимые порталы, письма и частные обозначения, чтобы узнать платёжную способность. Но общий формат значения не превращает его происхождение в общий набор доказательств.

Доступность — это вычисленная возможность, а не выписка

balanceAvailable определяется как сумма creditLine и cashBalance. Денежный остаток — средства, которые оператор сервера держит для клиента; кредитная линия — предоставленный оператором кредит. Начисления отрицательны, возвраты и пополнения положительны, вывод средств отрицателен.

Такая терминология точнее слова «баланс» без уточнения. Она также не смешивает доступную сумму с непогашенной задолженностью — отдельным понятием, которое в этом отображении не используется.

Схема XML, однако, не перечисляет операции, образовавшие остаток: регистрации, продления, пополнения, возвраты, выводы и корректировки. Нет явного момента «по состоянию на», закрытого периода, статуса спорной суммы или списка зарезервированных, но ещё не проведённых обязательств.

Клиент узнаёт, какое значение сервер показывает сейчас, но не может независимо пересчитать его по одному ответу. Для EPP это разумное ограничение. Оно становится проблемой, когда проекция управляет доступом к операции, а затем выдаётся за исчерпывающее объяснение.

Предел исполнения меняет фактическую границу

Необязательный executionLimit задаёт уровень, ниже которого платные клиентские транзакции могут быть отклонены. По умолчанию это 0,00, но допускаются положительные и отрицательные значения.

Положительный предел сохраняет запас выше нуля. Проект приводит в пример инициированные сервером операции, включая автоматические продления. Хотя доступная сумма положительна, её нельзя полностью потратить новой командой: оператор защищает средства для обязательств, которые возникнут без нового запроса клиента.

Отрицательный предел действует наоборот и позволяет продолжать платные операции ниже нуля в установленном диапазоне. Реальная граница получается из доступного баланса, предела и стоимости предполагаемой команды.

Ответ показывает текущий предел, но не управляющее им правило. Кто утвердил запас? Когда его поменяли? Как оценили объём автопродлений? Различается ли политика по продуктам? Действует ли временное исключение? В протоколе этого нет.

Запрос баланса также не резервирует деньги. Другая сессия может выполнить операцию раньше, учётное состояние может измениться, а команда — получить отказ по нефинансовой причине. Ответ является входом для решения, а не обещанием принятия.

Уведомление доказывает событие очереди, но не сверку

Необязательный notificationThreshold позволяет создать сообщение о низком балансе при пересечении порога. Атрибут basedOn обязан использовать ту же основу, что и предел исполнения. Предупреждение и блокировка не должны незаметно относиться к разным величинам.

Сообщение идёт через очередь опроса EPP. Базовый протокол даёт дату постановки и идентификатор сообщения, а команды и ответы несут клиентский и серверный идентификаторы транзакции. Клиент подтверждает сообщение обычным циклом poll. Проект предусматривает одно уведомление при пересечении, а не повтор при каждом запросе.

Это подтверждает техническую доставку и обработку. Оно не доказывает, что финансовый отдел прочитал предупреждение, что средства пополнены, что регистратор согласен с расчётом или что при последующем отказе действовал тот же порог. Доставка, осведомлённость, согласие и исправление — разные события.

Валютная раскладка не сообщает происхождение курса

При нескольких валютах денежный остаток можно разложить на компоненты: валюту, сумму, курс и пересчитанное значение в опорной валюте. Сумма пересчитанных компонентов должна равняться cashBalance. Используется прямая котировка: исходная сумма умножается на курс.

Клиент может проверить показанную арифметику, а коды ISO 4217 однозначно задают единицы. Но ответ не называет поставщика курса, время наблюдения, версию правила округления и резервный источник при сбое данных. У самого баланса нет явной метки расчётного времени.

При большом запасе это может ничего не изменить. Рядом с пределом небольшая разница конвертации решает судьбу пакета операций. Валютная инфраструктура получает скрытое влияние на управление именами, хотя её происхождение не следует за решением.

EPP не должен превращаться в валютный рынок. Достаточно, чтобы уполномоченная система доказательств сохраняла источник и время курса, когда конвертация имела операционное последствие.

Конфиденциальность разделяет материалы расследования

Проект считает финансовые сведения конфиденциальными и ограничивает доступ текущим вошедшим клиентом. Это правильное решение: конкуренты не должны видеть деньги, кредит и пороги другого регистратора.

Одновременно следы оказываются у разных организаций. Подрядчик ведёт EPP-сессию, не владея средствами. Бухгалтерия видит проводки, не зная точной последовательности команд. Реестр знает правило, но не может раскрывать весь журнал. Каждый участник владеет лишь частью картины.

Ответом не должна быть публичность или копирование бухгалтерии в EPP. Нужен узкий защищённый документ для уполномоченных сторон: он раскрывает меньше полного регистра, но объясняет больше снимка баланса.

Квитанция состояния, которое действительно решало

Я предлагаю создавать квитанцию финансового состояния, когда правило баланса существенно предупреждает о платной команде EPP, разрешает её или отклоняет. Это редакционное предложение по управлению, а не положение Internet-Draft.

Первая часть связывает аутентифицированного клиента, контекст сессии, clTRID и svTRID запроса, время получения, опорную валюту, доступный и денежный балансы, кредитную линию, предел исполнения и порог уведомления. Для каждой валюты сохраняются сумма, применённый курс, источник, время наблюдения и правило округления.

Вторая часть указывает на основу вне EPP: неизменяемый снимок учёта или ссылку на выписку, существенные ожидающие дебеты и кредиты, резерв автопродлений, версию политики и временное исключение. Хэш либо контролируемая ссылка обеспечат целостность без копирования коммерческих подробностей.

Третья часть фиксирует команду: класс объекта, основание цены, время запроса и решения, результат, код EPP и оба идентификатора транзакции. Нефинансовая причина должна быть названа. Если состояние изменилось между запросом и командой, сохраняются оба значения.

Тогда утверждение «не хватило средств» становится проверяемой последовательностью. Стороны могут отделить конкуренцию сессий, пересчёт валют, резерв, задержку проводки, изменение политики и иной источник отказа.

Минимализм протокола не должен стирать память

Отображение предназначено только для запроса. Оно не определяет поведение баланса для check, create, delete, renew, transfer или update. Это полезная граница: разные модели оплаты не стоит встраивать в универсальный протокол снабжения.

Риск появляется, когда стандартизированное поле становится окончательной истиной для поддержки и автоматизации, а придавшие ему силу условия не сохраняются. Единый интерфейс способен скрыть разнообразие внутренних правил.

Редакция 02 уже уточнила язык: balance переименован в balance available, добавлен basedOn, пространство имён обновлено до 0.3. «Доступный» означает условную операционную способность. Следующий шаг управления — сохранить условия, которые действительно управляли решением.

Источники