Re: Proposed XMPP Extension: Payment Required
JC Brand <[email protected]> Mon, 15 Jun 2026 15:54:36 +0200
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============2368134393070791846==
Content-Type: multipart/alternative;
boundary="------------2vHqhP1OMlav6UEM19N9Tdkz"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------2vHqhP1OMlav6UEM19N9Tdkz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
I've pushed a commit to my PR that removes the "display-amount" element.
https://github.com/xsf/xeps/pull/1546/changes/dc44f516f0b9c404103072db2c6=
deec4b10c2ca6
On 6/13/26 19:56, Tedd Sterr wrote:
> > Perhaps we should just remove it, but then clients which don't know=20
> the URI scheme won't be able to show the amount to the user, which suck=
s.
>
> If a client can't display the amount because it doesn't understand the=20
> scheme, it's better to tell the user that explicitly ("Unknown payment=20
> scheme.") rather than some vague warning that the value might not be=20
> accurate, while still displaying the amount as if it's correct. And=20
> where the client does understand the scheme, that value is redundant=20
> and should be ignored by the client anyway.
>
>
> > Also, if we removed "display-amount", there's still a "label" field=20
> which could lie about the actual payment amount.
>
> If we're going to have one potentially misleading=C2=A0value, let's go =
the=20
> whole way and have multiple? No.
> It's possible the label could mention an amount, but it won't be=20
> displayed in the same way as the explicitly unknown transaction=20
> amount, and the sender would have to expect the recipient doesn't have=20
> support for the scheme, otherwise the mismatch will be clear.
>
>
> _______________________________________________
> Standards mailing list [email protected]
> To unsubscribe send an email [email protected]
--------------2vHqhP1OMlav6UEM19N9Tdkz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
</head>
<body>
<p>I've pushed a commit to my PR that removes the "display-amount"
element.<br>
<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/xsf/xeps/pu=
ll/1546/changes/dc44f516f0b9c404103072db2c6deec4b10c2ca6">https://github.=
com/xsf/xeps/pull/1546/changes/dc44f516f0b9c404103072db2c6deec4b10c2ca6</=
a><br>
<br>
</p>
<div class=3D"moz-cite-prefix">On 6/13/26 19:56, Tedd Sterr wrote:<br=
>
</div>
<blockquote type=3D"cite"
cite=3D"mid:[email protected].=
PROD.OUTLOOK.COM">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DU=
TF-8">
<style type=3D"text/css" style=3D"display:none;">P {margin-top:0;ma=
rgin-bottom:0;}</style>
<div
style=3D"margin-top: 0px; margin-bottom: 0px; font-family: "Arial&qu=
ot;, "Helvetica", sans-serif; font-size: 10pt; color: rgb(0, 0,=
0);"
class=3D"elementToProof">
> Perhaps we should just remove it, but then clients which
don't know the URI scheme won't be able to show the amount to
the user, which sucks.</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
If a client can't display the amount because it doesn't
understand the scheme, it's better to tell the user that
explicitly ("Unknown payment scheme.") rather than some vague
warning that the value might not be accurate, while still
displaying the amount as if it's correct. And where the client
does understand the scheme, that value is redundant and should
be ignored by the client anyway.</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt;">
<span style=3D"color: rgb(0, 0, 0);">> </span><span
style=3D"color: rgb(0, 0, 0);">Also, if we removed
"display-amount", there's still a "label" field which could
lie about the actual payment amount.</span></div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
If we're going to have one potentially misleading=C2=A0value, let=
's
go the whole way and have multiple? No.</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
It's possible the label could mention an amount, but it won't be
displayed in the same way as the explicitly unknown transaction
amount, and the sender would have to expect the recipient
doesn't have support for the scheme, otherwise the mismatch will
be clear.</div>
<div class=3D"elementToProof"
style=3D"font-family: "Arial", "Helvetica", sans-seri=
f; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<br>
<fieldset class=3D"moz-mime-attachment-header"></fieldset>
<pre wrap=3D"" class=3D"moz-quote-pre">____________________________=
___________________
Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" href=3D"m=
ailto:[email protected]">[email protected]</a>
To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
f=3D"mailto:[email protected]">[email protected]</a>
</pre>
</blockquote>
</body>
</html>
--------------2vHqhP1OMlav6UEM19N9Tdkz--
--===============2368134393070791846==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--===============2368134393070791846==--