XMPP Council - 2018-02-28

I believe I'm now current on all Council votes.

Kev, In email?

Yes, I owed three weeks ago, which I sent last week, and two weeks ago, which I just sent.

Last week had no outstanding votes.

Time, gentlemen, please.

1) Role Call

daniel, Kev SamWhited ?

here

I'm here

I'm here.

At least in body, if not in mind.

🙋 ✏

2) Extrcting chunks of XEPs

Actually, no.

2) For fork's sake, can somebody else take the minutes?

(Found my agenda copy)

Anyone want to do the minutes?

Alright.

While I normally would, I have a hard time focusing on minutes and paying attention, so I don't like to do it for meetings I'm participating in

Ta. I should try to be more forthright on the list.

SamWhited, Me neither.

I can only do it if I'm chairing, so the meeting naturally pauses when I need it to.

Me neither, but we need a volunteer.

SamWhited, I tend to do them afterward then, but they're never quite the same.

OK.

Yah, I don't like doing it afterwards because I always end up having questions, context goes missing, etc. anyways, thanks Ge0rG

3) Good Idea Extraction Kev suggested (on the list I think) that extracting good ideas from otherwise out of date XEPs might be useful, in the context of XEP-0013. I wanted to explore this idea for 5 minutes to see if this seems sensible, and figure out what our next steps might be.

In the context of 13 I think the new XEP becomes:

I don't actually think that it is a good idea for the specific 0013 case.

2.7 Removing All Messages The user removes all message by sending the "purge" command: Example 13. User Requests Removal of Offline Messages <iq type='set' id='purge1'> <offline xmlns='http://jabber.org/protocol/offline'> <purge/> </offline> </iq> If the requester is a JID other than an authorized resource of the user, the server MUST return a <forbidden/> error. If the requester is authorized but the node does not exist, the server MUST return a <item-not-found/> error. Otherwise, the server MUST remove all messages and inform the user: Example 14. Server Informs User of Successful Purge <iq type='result' to='romeo@montague.net/orchard' id='purge1'/>

So I spotted another case of this, which is that eSessions has what appears to be a perfectly reasonable full-stanza encryption definition.

Job done.

(Not quite job done, but bloody close)

Kev: but race conditions!

In this case I don't like the idea very much and still think we just need to deprecate the whole old XEP. However, it would get rid of all the other stuff and possibly reduce confusion, so I'm not against it.

I'm in favor of killing 13 once we have a way to properly do MAM without offline.

Anyone want to volunteer for the XEP-0013 case?

wasn't my idea of putting current mam settings in disco info rejected because people didn't like 13's purge?

13 is not a way to properly do it.

Ge0rG, Sure. But it's better than nothing, and extracting it means we can ditch the rest (I think).

without that i don't see how we can savefly purge anyway

no matter if that's actual xep13 or xep405 purge

Maybe that section could be moved into MAM as a "this XEP is deprecated, but if people are still supporting it you might want to do this to clear" note? That would continue to be useful even if a new mechanism was introduced later.

SamWhited, I'd rather a new XEP, to shoehorning things into MAM.

Something better than -13's "purge offline" is even better, naturally. Like "Disable offline until this session ends" or something.

daniel: I haven't had time to think through the implications of your proposal yet.

It seems to only affect MAM, no? That's when you're going to need to do this workaround, so it seems worth having it in the thing you're already reading that's going to require this

Kev: what about adding to MAM: "if a client performs a MAM query before sending initial presence, no offline messages will be sent"

Ge0rG, just not sending them will make them pile up though

Ge0rG: That works if it's "and they're purged", I think.

daniel: on a MAM server, the offline messages queue should be merely a pointer into the archive

MattJ had an interesting idea with maintaining per-client offline-message pointers

Ge0rG, should…

Not wishing to stop this discussion, but I'd like to bring the discussion around somewhat.

Dave: do you have other cases for extracting good ideas from bad XEPs? ✏

In principle, if we want to deprecate a XEP which still has a single widely used task within it, is our current recommendation that we extract that useful portion into a new XEP?

Ge0rG, eSessions full stanza encryption?

Blocking non-contacts from 0016?

If it wasn't Draft, I'd suggest cutting the other stuff from the XEP. But I don't think that's appropriate at Draft.

Depends on the situation, I don't think we can make a general statement here

Kev: how is forking a part of a Draft into a new XEP and deprecating the Draft better?

OK, I don't think we're coming to a conclusion here.

I don't think there's a general conclusion to come to, other than 'it's an option'.

Which isn't a bad thing, indeed.

So, moving on:

4) Dusty Drafts Note thread - Sam wanted to place this on the agenda.

Can we decide what to do in this specific place before we move on?

My preference would be a 'good' fix, and get rid of all of 13.

what Kev said

If we can't do that, just keeping that one bit of 13 alive through a new XEP would work for me.

recycling that bit of 13 is bad.

it's a shortcut that's going to bite users.

I don't have a strong preference here, though currently we're stuck in Clausevitz's dilemma.

Right, I'm going to move on.

I don't want to leave something behind where in a decade, people will have to draw complex flow-charts on a huge flipboard to understand how to correctly disable offline messaging for a MAM client

Proposal: 1. add a note to MAM saying "you might need a workaround from this XEP because some legacy systems are still doing this", 2. deprecate the old XEP, 3. wait for someone to come up with a better solution.

4. remove the notice from MAM and depend on the new thing.

I'm not sure it's a case of legacy systems. Offline messages haven't been deprecated or anything.

Still doing partial 0016, I mean.

But other than working, that seems like a reasonable enough approach to me, I guess. Pointing to a deprecated XEP from a Draft one seems odd, but it's likely to be stable.

Offline messages aren't technically a spec, right?

*than wording

interestingly the request mam purges offline messages still breaks the case where the user has disabled mam for themselves. because we make a request. that request will have an empty result but offline messages will be gona anyway

so it doesn't really matter if you purge explictiy or implicitly

Really moving on, please.

4) Dusty Drafts Note thread - Sam wanted to place this on the agenda.

So we've a bunch of Draft XEPs that haven't been touched in years.

I think you want each XEP as a Council agendum for CFE.

CFE?

Call For Experience.

Last Call, but for Final.

That'd be to move to Final. But I'd have thought many of them should be moving to Deprecated.

I was thinking we'd discuss CFEing each, and when we decide 'no', we'd then vote on deprecated, but whatever.

Oh, I can do that.

Sounds good to me. CFE -> deprecated|final

If everyone's happy with that concept, we can do that next week?

WFM

We don't need to actually issue a CFE for some of these do we? I feel like a few of them are obvious

s/obvious/uncontroversial/

SamWhited: For deprecating, or going to Final?

We have to CFE if we're going to Final.

For deprecating

SamWhited, We wouldn't be CFEing any we want to deprecate.

No, that's what I was (trying to) say.

So we need to decide which ones to CFE.

We ask "Shall we CFE?" for each one, and when Council says "No", we then say "Shall we deprecate then?" and we say "Yes".

ahh, I see, we don't actually go to CFE. Yah, that seems sensible.

What Kev says seems reasonable to me.

Otherwise we have a discussion about which one we should CFE and which we should vote to deprecate, and this just seemed cleaner/quicker.

But, we'll all need to be prepared on this one, so please do ensure you're ready to vote in the meeting next week.

(Otherwise this could drag on for a month...)

We could probably vote on at least two of them right now, I suspect.

Can everyong commit to that?

wfm

I wouldn't want to vote on anything without reading the XEP first, so wouldn't like to vote on anything today.

Great.

But yes, my general policy is Wednesday morning I spend reviewing stuff that's on the Agenda before Council.

+1 for vote next week

Really? Because SOAP and Internet Metadata seem like obvious candidates to deprecate, we might as well get those off the table

Kev, I'll get the next agenda out in advance properly.

SamWhited: Except there's interesting stuff in SHIM :)

SamWhited, I'm willing to bet SHIM is used for vital stuff in pubsub. And I dislike the protocol.

OK.

Just SOAP then

5) AOB

Anything else?

I've got some

SamWhited, I've been to FOSDEM, SOAP is very much deprecated already it seems.

Right, so let's go ahead and formalize that and have less to do next week

Ge0rG, Shoot.

5.1: I'd like to re-call the MUC rewriting @id's discussion from https://mail.jabber.org/pipermail/standards/2014-July/028988.html

Back then, there were voices against doing so, and now we ended up with origin-id, which is supposed to work around broken MUCs, but doesn't work in practice anyway.

So I'd like to get the wording (final suggestion at the bottom of https://mail.jabber.org/pipermail/standards/2014-July/028996.html) into 0045.

| "The service SHOULD reflect the message with the same 'id' that was | generated by the client. If the client did not provide an 'id', the | server MAY generate one 'id' and use it for all reflections of the | same message (e.g. using a UUID as defined in RFC 4122 [18])."

Ge0rG, Can you run up a specific patch to vote on for next week?

Dave: I can put the above sentence into a PR, if you wish so.

I'm aware that this is changing a Draft, but it's reflecting what most implementations are doing anyway.

I've got more AOBs.

Ge0rG, Keep going, then. :-)

Flow said today that <origin-id/> was supposed as a MUC workaround. With 5.1 addressed, I'd like to remove <origin-id/>

(this being 5.2)

Ge0rG: If you're proposing text that breaks MUC, please note that in that text.

(I actually think a disco feature might be appropriate)

Ge0rG, Again, I'd like to see a specific PR to vote on, but given 5.1 I'd see 5.2 as desirable.

and 5.3: RFC 6120 does mandate that if a stanza has an ID, it should be unique globally or in the current session. As we are using @ids end-to-end, the session limitation doesn't make sense. And when we send an error, we must return the original ID, for which we can't guarantee anything

Kev: that was suggested some months ago as well. Should it be on the MUC service or on the individual MUC JID? What would you like it to be called? <will-not-break-ids>?

Ge0rG: We've always assumed that what this really means is that between two JIDs they'll be unique, and glossed over that this also isn't really true.

Ge0rG: Can out of band the details, and get something I'm happy with, I think.

Kev: I'd be glad to get your input on this, even in short form.

Sure, but out of band, so the meeting can stop overrunning :)

I'm sure I had another AOB, but I forgot to write about it to standards@

Ge0rG, Your 5.3 doesn't seem to be more than a statement. But if you'd like to vote on things, next meeting, I'm entirely happy to have these raised and discussed on the mailing list. :-)

maybe it was about more feedback regarding the non-dataforms extension of 401, but Kev made a good point on that on list

6) Next Meeting

Same Time Next Week?

Wfm

WFM

WFM

Lovely.

I can't guarantee yet.

Will be on mobile probably, but I'll try hard.

Ge0rG, If we're going to run through these Draft XEPs, it'd be really useful to have you around.

Dave: I know.

OK.

7) Ite, Meeting Est.

Thanks all.

Thanks all.

Thanks

Ge0rG: I suggest something like urn:...stable-id as the feature, on the MUC itself.

Kev: that means we need to disco#info each MUC, as opposed to each MUC domain, right?

And then some text that says something like "MUST have a stable id, advertised with ...stable-id.... Previous versions of this spec didn't have this requirement, and so some deploments might not follow this rule".

disco#items/disco#info on your own domain's services is free essentially

Kev: thanks!

The disco feature is kinda assuaging my guilt at making a breaking change to a Draft XEP, as much as anything.

I'm not actually sure that it's something people will genuinely use, because what do you do if it's not there? Stuff just breaks.

Kev: I can promise I'm not going to use that disco#info feature.

But it could be put on the MUC domain and the MUC room, I guess, or just on the domain, or whatever.

but then again, just opening tickets with broken implementations won't solve the problem either

I doubt it's something we're going to address in M-Link immediately, but we've got a rewrite of the MUC code going on at the moment for assorted reasons, including MIX, and I'm intending that to reflect ids.

as much as I’d like to take minutes, the council meeting is unfortunately exactly during my commute until at least june :(