[Standards] XMPP Council Minutes 2018-05-30

Jonas Wielicki 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.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180606/92d4a6a8/attachment.sig>

More information about the Standards mailing list