[Standards] Proposed XMPP Extension: Terms of Services
jonas at wielicki.name
Wed May 23 15:55:39 UTC 2018
Thanks for your feedback, Ivan.
On Mittwoch, 23. Mai 2018 16:38:08 CEST Ivan Vučica wrote:
> 184.108.40.206 Protocol support required
> If the client did not include a <tos-support/> element in the initiating
> request and the server requires support for the Terms of Service protocol,
> it replies with an error:
> On first reading, it's unclear what is the "initiating request" that
> 220.127.116.11 addresses. Is this intended to be a response for
> jabber:iq:registration-related requests? When does the user get the
> opportunity to respond with or without <tos-support/>?
You rightfully expect IBR to play a role in the ProtoXEP. Right now, it does
not, because I didn’t have the time yet to integrate IBR. The initiating
request is w.r.t. the Ad-Hoc Command session flow (id='cmd1' in the examples).
> For that matter -- why is <tos-support/> in the adhoc command required in
> the first place? The point is to show the adhoc command dialog for TOS to
> the user upon request.
Ad-Hoc commands may be invoked by clients which do not support the TOS
protocol. This is a feature to allow legacy clients to interact with a less
fancy version of the ToS flow. However, a service may require the fancy
version (for whatever reason). At the moment, the XEP does not contain
anything which would require <tos-support/> to be enforced by the server. It
is there as a provision for the future.
> Next up:
> Your client does not support the Terms of Service protocol.
> Please review the Terms of Service online at
> If the protocol is not supported, how does the user indicate acceptance
> before IBR?
Not at all. But keep in mind that existing users may need to be migrated to
new TOSes and servers might want to do this in-band.
In addition, the Ad-Hoc Command is useful to modify privacy settings connected
with the ToS (as given in the example) later on.
> Or in general -- if the user reviews the TOS, how do we know
> they accepted them?
If a server requires explicit "acceptance" of the ToS, it has to request that
using a checkbox as shown in the examples. The client presents the boolean
field (checkbox) to the user, the user ticks it and submits the command, at
which point the server knows the user has accepted it.
> Should we standardize a chat session where the user is
> displayed the same messages, and required to enter "agree/disagree" _in
> addition_ to providing better UX through adhoc commands?
No, I find chat sessions weird and flaky for this type of thing.
> Next up:
> 4.4.1 Reject bind attempt before agreement
> If a client attempts to bind a resource before agreeing to the Terms of
> Service, the server rejects the request with a <policy-violation/> type
> 'cancel' error including an application defined condition of
> <agreement-required> in the namespace of this protocol.
> In 4.4.1, should a mention of in-band registration be made? How is IBR
> affected? Is it affected at all?
IBR needs to be considered in the XEP. It is not affected by 4.4.1 because
4.4.1 is post-authentication (IBR is pre-authentication, obviously).
> Why does the client care about version of the documents -- is this so it
> can avoid bothering the user to agree?
If the service is in the process of switching TOS documents, it is important
to know which version the client is currently acting on. This eliminates a
race condition between a client/user reviewing and modifying their privacy
settings and the service rolling out a new version of their documents.
> The server is the one that remembers
> whether the user agreed to TOS (it should do so, so it can be proven that
> the user has indeed agreed to a revision of TOS); does the client need to
> remember the last agreed version of the TOS?
> The server could simply send
> an adhoc form that says "your acceptance is not required" if the user has
> already agreed.
It should not do that to allow users to easily (re-)discover the ToS documents
of the service and modify opt-ins/opt-outs later on.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards