Hi James,
Having all the three variables defined and stated is helpful in that
people can cross-check to be sure they understand correctly.
The relationship to RFC 8748 is helpful, but as you point out, its
definition of the balance is literally the opposite (as in "the negative
of") the one we are considering for the present regext-balance draft.
Definitions in the abstract are hard to write. I can volunteer the
following clarifications based on the example of the response to the
info command on page 5:
<balance:infData
xmlns:balance="urn:ietf:params:xml:ns:epp:balance-0.1">
<balance:currency>USD</balance:currency>
<!-- The account is kept in USD and the balance shown
in this message is expressed in USD. -->
<balance:creditLimit>1000.00</balance:creditLimit>
<!-- The system will block certain transactions that
would bring the balance to an amount exceeding
USD 1000 in favor of the party operating the server.
* A creditLimit shown with a negative sign would
require the balance to remain in favor of the
party operating the server. -->
<balance:balance>800.00</balance:balance>
<!-- The balance is USD 800.00 in favor of the party
operating the server.
* A balance shown with a negative sign would be in
favor of the party operating the client. -->
<balance:availableCredit>200.00</balance:availableCredit>
<!-- Unless a deposit is made, the system would
block certain subsequent transactions as soon as
another USD 200 are consumed.
* An availableCredit with a negative sign would
mean that the balance has moved further in
favor of the party operating the server
than that party has agreed to permit. -->
<balance:creditThreshold>500.00</balance:creditThreshold>
<!-- When the balance is 500 or more in favor of the
party operating the server, notification messages are
sent to the client at regular intervals. -->
</balance:infData>
Writing clarifying comments into an example could be an easier-to-read
(and easier-to-write) alternative to a definitions section.
That being said, the word "credit" has many meanings by nature and is
used in widely different meanings in both RFC 8748 and in the present draft.
Instead of "Available Credit", I would propose the expression "Available
Funds", especially as RFC 8748 used "credit available" as the definition
of "credit limit".
Instead of "Credit Treshold", I would propose the expression
"Notification Threshold".
Best regards,
Werner
On 2025-12-05 13:38, Gould, James wrote:
Werner,
Thank you for your support and I agree that there is the need for
definitions and inclusion of the equation, which is Available Credit
(AC) = Credit Limit (CL) – Balance (B). Gavin’s response is helpful
with aligning the definitions with those defined in the Registry Fee
extension of RFC 8748. The Registry Fee Balance is the negative of
the Balance in the Balance Mapping with the equation Available Credit
(AC) = Balance (B) – Credit Limit (CL), where the question is whether
there is a desire to include all three variables. When the AC is zero
or negative a server MAY reject certain transactions. Do you prefer
having access to all three variables or the two that is included in
the Registry Fee extension?
I don’t believe there is any intention with implementing currency
conversion, so the currency returned is the currency that the account
is kept. I would like to learn more if currency conversion is a
desired feature for the clients.
Thanks,
--
JG
cid87442*[email protected]
*James Gould
*Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *"Werner Staub (axone)" <[email protected]>
*Date: *Thursday, December 4, 2025 at 3:24 PM
*To: *"[email protected]" <[email protected]>
*Cc: *"[email protected]" <[email protected]>
*Subject: *[EXTERNAL] [regext] Re: Call for adoption:
draft-gould-regext-balance-00 (Ends 2025-12-15)
*Caution:*This email originated from outside the organization. Do not
click links or open attachments unless you recognize the sender and
know the content is safe.
I think the draft has great merit but I would argue that a definitions
sections with the underlying financial definitions should be added to
the document before adopting it.
Expressions like "credit", "credit limit", "balance", "available
credit", "credit threshold" are not defined in the document and they
are by no means clear just by virtue of definitions one could find in
a dictionary.
When a balance is mentioned, it should always be made clear in whose
favor it is. Is a positive balance one in favor of the server? What do
each of these figures mean when they have a negative sign? Can the
credit limit be negative so that the client would be require to
maintain a credit balance with the server? (Note that I just used the
word "credit" in a totally different sense.)
The equation linking "credit limit", "balance" and "available credit"
should also be mentioned.
Even the tag "currency" requires clarification. The draft should make
clear that it is necessarily the currency in which the account is
kept. If that is not made clear, some implementations may use it
designate the currency in which a converted balance happens to be
expressed per client configuration. Of course "conversionBalance" and
"conversionCurrency" tags would be better for the latter.
Best regards,
Werner
On 2025-12-04 16:35, Jody Kolker wrote:
I support adoption also.
Thanks,
Jody Kolker
319-329-9805 (mobile)
Please contact my direct supervisor Scott Courtney
([email protected]) with any feedback.
This email message and any attachments hereto is intended for use
only by the addressee(s) named herein and may contain confidential
information. If you have received this email in error, please
immediately notify the sender and permanently delete the original
and any copy of this message and its attachments.
------------------------------------------------------------------------
*From:*Eric Skoglund
<[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, December 4, 2025 3:09 AM
*To:* [email protected]
<[email protected]>
<mailto:[email protected]>;
[email protected] <[email protected]>
<mailto:[email protected]>; [email protected] <[email protected]>
<mailto:[email protected]>; Jorge Cano <[email protected]>
<mailto:[email protected]>
*Subject:* [regext] Re: Call for adoption:
draft-gould-regext-balance-00 (Ends 2025-12-15)
I support adoption. // Eric Skoglund From: Jorge Cano via
Datatracker <noreply@ ietf. org> <mailto:noreply@ ietf. org> Sent:
01 December 2025 18: 15 To: draft-gould-regext-balance@ ietf. org
<draft-gould-regext-balance@ ietf. org>
<mailto:draft-gould-regext-balance@ ietf. org>;
regext-chairs@ ietf. org <regext-chairs@ ietf. org>
<mailto:regext-chairs@ ietf. org>;
ZjQcmQRYFpfptBannerStart
*This Message Is From an External Sender *
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
I support adoption.
// Eric Skoglund
------------------------------------------------------------------------
*From:*Jorge Cano via Datatracker <[email protected]>
<mailto:[email protected]>
*Sent:* 01 December 2025 18:15
*To:* [email protected]
<[email protected]>
<mailto:[email protected]>;
[email protected] <[email protected]>
<mailto:[email protected]>; [email protected] <[email protected]>
<mailto:[email protected]>
*Subject:* [regext] Call for adoption:
draft-gould-regext-balance-00 (Ends 2025-12-15)
Subject: Call for adoption: draft-gould-regext-balance-00 (Ends
2025-12-15)
This message starts a 2-week Call for Adoption for this document.
Abstract:
This document describes an Extensible Provisioning Protocol (EPP)
mapping for retrieving the client balance and other financial
information.
File can be retrieved from:
https://datatracker.ietf.org/doc/draft-gould-regext-balance/
<https://secure-web.cisco.com/16e_pHDoinM1uLUp4G2RyOZpKR_g1PhVUIPkOdYwU7I3Z4WZ4RDEmfoWj6Y4bBwF2t2hcIzkGz0oPfIdP8O3X_QnHPIQLMhuq9hTEHdeIzfHz0glUihbRFm188D2D6a9yamxl_LvBZ94BWWyoP5Yuw0Y28V7vxuQf0TiA5ajJIcooV9L4aKhQqBn80RdMIp16M3yWQGEpZ3yDpFeKtSXx6HHRKXKVHh-I-PtOkOU8VZ55YK46ez4QbJWP3fc_RYf-x6d1hgHzoSotaQWYrblM6J8bIAfxqv8RYkFpMs1I6SzRqZEg-EAFFLTO0mx4mN7i/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gould-regext-balance%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5ZObPHng%24>
Please reply to this message keeping [email protected] in copy by
indicating
whether you support or not the adoption of this draft as a WG
document.
Comments to motivate your preference are highly appreciated.
Authors, and WG participants in general, are reminded of the
Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [2].
Appropriate IPR disclosures required for full conformance with the
provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR
Policy can be
found at [3].
Thank you.
[1] https://datatracker.ietf.org/doc/bcp78/
<https://secure-web.cisco.com/1zLoM9qw90j7V4HlxmsrHkkgf3ao_UqLcVKHYUG2E7Dq4BSP4msor1-SstyQL3j582E_LrZsiJazQ_O5b6A4CS6dgpN5f41AyPS7bMbELEF5O4u4jD1bNF1YLoPI-al5LsngW4_vG2zTH3CfRRPaiXIYOFxksVwqqdgEo5LS31AuLnLf_D1kATJPVF5PxArHyIMuYo74Yj6Od4PhhI644P6kuHRsLqOmf86YkMskzhCen04MEFY0SaqGJOEkGfJsTCta9WUBCv58NhVFcaPIj-0HEz-g5dBtyR4SF0h_e4tvc_A6UuuAC23SpgxNIEbiB/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp78%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5Xd7Z_tL%24>
[2] https://datatracker.ietf.org/doc/bcp79/
<https://secure-web.cisco.com/1uJERsHYNkyNMf-YbgjXzIsKu_gh8VKkB72Thjqz-JTsIBcDP9rh6dmEwV3IuzE2YF0hZzmYhUo0-ERbX9Uczrh_u1T5A7kAiZwzn3wSNYbnvtFvnPUkWYs20ABhzC3ZxCtvzrJxv8Sb1xv-4FoKoUIW8TzOXe00xH2gt-fY-3Yj3oRY6OUXMOma346wdgQKT5bi1A3MF82JzOKZkMGVSFVWRYp7f0edOrmYBPVePjTJ0piPzUTpg_sBZK1EKlGoGGBabBAEMsX6sHwZjRolGnrsDSZ9VYe9fHzMFuRCvBdTCAcsvzkAl90O35TkDWsCm/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp79%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5epWYYiK%24>
[3] https://datatracker.ietf.org/doc/rfc6701/
<https://secure-web.cisco.com/1EgflcRfdRH24YSQ0q5OmeWaYyJ4iBINHSlnDi2GK-hqHU1coNfhypPzumZzbnGy0wzsn6ZQM5hbjPILl6P5_zbS-BRKpcrHypGC7lgpfumvXssRUeBDRv6UJx-cSI9GeM9Zdk77l8owZebftl88nUSt-fFQYfHDnS9pU41lZaI8p85QRWHwKImdSG9YIySHsdmLx-4VvtFv9AcB8B7prJX9QjqrvZUZqtx7eBuCTzO8uN7fof7XS8niM_wUoMo95Y158rs1ceHRPCA8DwMNy_5W9zI2kUmcjVo0Hvcyy16Lf2Shbc_Q2RXh1IhWb4ZUa/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc6701%2F__%3B%21%21Hj18uoVe_Lnx%21uxuzeerzd1LT7rYoQYPvzScvaylRwEQ2OKrB7aRHL4ufx21umhG6_js3UULadhIoGT9jBovnvf9Ag7tR8WS7dc3r5cOwlBZX%24>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
Werner Staub
Axone Services & Développement SA
2 cours de Rive
1204 Geneva
Switzerland
T: +41 22 312 5656
F: +41 22 312 5601
M: +41 79 203 4075
--
Werner Staub
Axone Services & Développement SA
2 cours de Rive
1204 Geneva
Switzerland
T: +41 22 312 5656
F: +41 22 312 5601
M: +41 79 203 4075
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
