[Standards] XMPP Council Minutes 2018-05-30

Dave Cridland dave at cridland.net
Wed Jun 6 16:42:47 UTC 2018

On 6 June 2018 at 17:30, Jonas Wielicki <jonas at wielicki.name> wrote:

> 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
> now.)
> 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
> there.
> 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.

Right, I'm probably +1 for all the same reasons as Sam is -1, oddly enough.

We need a ToS mechanism, I think. We also, as you point out, need one
that's IQ-based and can be actuated in mid-stream - this is going to be
useful in cases such as a ToS policy for muc.xmpp.org. It'd be great if
this mechanism builds on ad-hoc, as this one does.

But we also need something that'll work before the login. There's a number
of deployments I work on where the organisation would probably want a ToS
ack before (or during) *every* login - currently they work with MOTD
plugins and similar, but that's clearly not ideal.

I really don't want to have any IQ based flows prior to login if possible -
with my server-dev hat on, I find it worrying to have to do deep inspection
of IQ stanzas during pre-auth.

SASL2 et al will go some way to addressing these, but won't satisfy legacy
clients - maybe that's going to have to be good enough, or maybe we'll
figure out something better.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180606/1de7df14/attachment-0001.html>

More information about the Standards mailing list