Hi Werner, RFC 8748 (the Fee extension) uses an almost identical set of XML elements, and describes them fairly well. So this could be addressed by simply referring to the definitions in that document.
G. > On 4 Dec 2025, at 20:24, Werner Staub (axone) <[email protected]> wrote: > > 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]> >> Sent: Thursday, December 4, 2025 3:09 AM >> To: [email protected] >> <[email protected]>; [email protected] >> <[email protected]>;[email protected] <[email protected]>; Jorge Cano >> <[email protected]> >> Subject: [regext] Re: Call for adoption: draft-gould-regext-balance-00 (Ends >> 2025-12-15) >> This Message Is From an External Sender This message came from outside your >> organization. I support adoption. >> >> // Eric SkoglundFrom: Jorge Cano via Datatracker <[email protected]> >> Sent: 01 December 2025 18:15 >> To: [email protected] >> <[email protected]>; [email protected] >> <[email protected]>;[email protected] <[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/ >> >> 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/ >> [2] https://datatracker.ietf.org/doc/bcp79/ >> [3] https://datatracker.ietf.org/doc/rfc6701/ >> >> >> >> _______________________________________________ >> regext mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> regext mailing list -- [email protected] >> To unsubscribe send an email to [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 > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
