[Standards] XMPP Council Minutes 2018-05-30
jonas at wielicki.name
Wed Jun 6 16:30:32 UTC 2018
On Mittwoch, 6. Juni 2018 16:52:27 CEST Sam Whited wrote:
> I'm not af an of how this one was done. -1 for now. I'd like to discuss how
> this can be done better though; it seems to me that it would fit very well
> as part of extensible IBR and/or SASL2.
I agree that IBR or SASL2 or whatever integration is needed, but restricting
it to that is not sufficient. I planned to add this post-acceptance. (I don’t
want to open the "Develop things in Experimental vs. in ProtoXEP state" box
Here’s why I think only IBR/SASL2/other-pre-auth-things is not sufficient:
1. Long-living sessions need to be notifiable. You could of course kill the
connection, have it re-authenticate, show the user the info box, and hope they
read it in time for stream management resumption to work, but I don’t believe
that to be a good flow. I’d like to avoid blocking clients on authentication
until absolutely necessary (i.e. deadline for agreement reached). Until then,
a way to notifiy users about changes and a way for them to acknowledge those
changes (and give agreement to whatever necessary/wanted) seems useful.
2. This kind of doubles as kind of privacy settings, and I agree that this
might be feature creep and we might want to split this off. I find it logical
to combine those two things though. Especially in GDPR-land a service might
want to offer their opt-in things next to the terms of service so that users
don’t have to dig for them. In non-GDPR-land where there may exist mandatory
opt-in things, it makes sense to have them right next to the ToS in the
client. For non-mandatory opt-in things, it makes sense to be able to change
them even when a ToS change is not around the corner, so having an IQ/Ad-Hoc
flow for that makes sense.
I see that the IQ-based pre-auth flow is an issue, and integrating this in
SASL2 or something is probably the better way to handle this. However, this
also needs to work pre- or during IBR in some way.
I am hesitant to base anything on SASL2 with the current state of deployment
I also accept the criticism I got from other folks (Kev I think, but don’t
quote me on that) that the Ad-Hoc workflow looks out of place. I’ll work on
that, but first I want to be on the same page with you, Sam, because I don’t
want to waste more time on a spec which will be -1'd.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards