XMPP Council - 2016-01-13

hi

it is time

Hiya

0) Roll call

Here.

Tobi MattJ

here

here

There is currently nothing on the agenda, unless anyone as AOB.

We are still tracking the Jingle ICE XEP that was approved, but not yet published.

Here

1) Date of next

sbtsbc?

wfm

Works for me.

Who's coming to the Summit from the Council?

wfm

AOB: Whatever happened to deprecating privacy lists? Probably something I was supposed to do and forgot about

I'm not Council, but I'll be there.

m&m, They don't allow anyone with a beard on a plane anymore.

I will not be there this year

clearly

i'll be there

but Chirs Deering and Jerome should be able to help you all out

Chris even

Chairs Deering.

I believe MattJ signed up

I believe Ralph is in contact with Chris.

Yes, he is

Lance, No, Wild Matthew signed up.

Ah, right :)

must be his good twin

2) AOB: Privacy lists

Lance, yep, I'll be there

re jingle-ice — we'll get that published by next week

Were there still action items left to do here?

as Wild Matthew

(might be nothing to discuss with privacy lists; I'm looking to see if there was some action that I or anyone else was supposed to do, but I can't remember)

Grr, lag

I don't think we ever voted. I think we merely discussed on the list.

I'm not sure if there was clear consensus

translation from British: there was no clear consensus

If we do vote, I'd like to gather the user requirements that came from the discussion and see if we can come up with "modern" case-specific XEPs to handle them.

(ie, I'd vote not to deprecate it)

IIRC, the missing use case was blocking groups

There was another - blocking non-roster contacts

And non-roster people.

I'd volunteer to add group/non-roster blocking to the blocking command XEP (blocking non-roster contacts appears to work for me, even if it's not compliant with the spec actually)

SamWhited: I'd suggest getting that discussion rolling again by proposing some updates to the blocking XEP then

Jinx. Will do.

3) AOB?

Sounds like a no

none here

thanks all

thanks you Lance

SamWhited: I think Lance was probably there too.

SamWhited, to be clear it's blocking *all* non-roster contacts

MattJ: ahh, gotcha, thanks.

Some servers do it already (optionally), but it isn't per-user configurable

SamWhited, Putting in asides into the minutes? That's disgraceful behaviour.

SamWhited, Well done.

Could be made so with ad-hoc commands, but the privacy-list supporters want a standard protocol

It was mentioned in the meeting by me :) it's legit.

Standardized ad-hoc would do it, mind.

I have another question about handling the Jingle XEPs, mostly for the Editor Team but partly also for Lance. Unfortunately I worked on them all (166, 167, 176, 177) in a single branch, and then we forked 176 into a new XEP. I would be happy to set up separate branches for each XEP if that's easier to process. I think that I have 167 and 177 done but I'd like some feedback on the list for those changes, so posting temporary versions would be good (we used to do that at http://xmpp.org/extensions/tmp/ but haven't done so in a while, I think). 166 is close to done but Lance was interested in adding some implementation notes and I'm not sure where he stands with that. And then we need to publish the new / replacement jingle-ice spec. IMHO a good next step would be publishing both 167 and 177 in the temp dir.

> <domain> (the domain itself matches, as does any user@domain or domain/resource)

Am I missing something; that sounds like domain blocking IS implemented.

psa: I'd say it doesn't matter; separate branches would keep the commit history cleaner and make review easier, but it shouldn't be hard to process either way.

SamWhited, Did we mention domain blocking?

Pretty sure that was one of the things people said… or at least that I was reading on the old topic.

Hey, what's up? // I implemented blocking from scratch

Zash: Just discussing deprecation again; I was trying to address the things people said were missing from the blocking command.

deprecation of privacy lists, that is.

Right, I got that much

Ah, nope, it was groups, not domains. Nevermind.

Groups and blocking people by default IIRC

I really don't see the use for groups, just added complication IMO, but it's not that much complication, so I'll add it if the council thinks it's really necessary.

Actually, I change my mind, I'll bring it up on list again, but I think groups does just add needless complication and shouldn't be used that way. Now clients that get a block list have to do extra work to check if any given contact is a member of a group, that's a lot of extra logic over just checking if their JID is in a list.

SamWhited, The logic has to be there for PEP nodes with access-model roster, anyway.

Hmm… fair point.

SamWhited: It gets more complicated for clients if they have a group that is blocked and you add someone to it

And potential cross-client-sync issues

Do groups not do any sort of pub-sub? I should go check how that works.

(not the XEP pub sub, but just getting a push down when a group changes)

SamWhited: Sure

But someone creating a group and blocking it with one client that does this thing will be very confused when they add someone to that group from another client and they don't get blocked.

FWIW I agree this is not something I think groups should be used for

psa: +1 to publishing tmp versions for review

SamWhited / Lance OK I'll get busier so we can finish the Jingle revision process

psa: what all is actually left?

other than expanding 166 with implementation guidance?

and more diagrams :)

and evil things you do not want to talk aboutÃ? :-p

heh

Lance: I think that's mostly it

i'd love to talk about them

psa: ah, good. those changes don't need to be done before the slew of other xeps are published then, but i'll start writing

there is however, one item i'll bring up on list later: adding a framed transport type in addition to datagram and streaming

I would also like to triple-check the jingle-ice spec against RFC 5245, RFC 6544, and draft-ietf-ice-trickle

psa: i'll see if I can find some time for that

OK: http://xmpp.org/extensions/tmp/xep-0166-1.2.html and http://xmpp.org/extensions/tmp/xep-0167-1.1.html and http://xmpp.org/extensions/tmp/xep-0177-1.2.html

Lance: super

and of course, it would be great to get feedback from folks like Fippo and Xander

I'll post to standards@ with the links

message sent

psa: thanks for being awesome, as always

haha

just putting one foot in front of the other, as always ;-)