2) For fork's sake, can somebody else take the minutes?
Dave
(Found my agenda copy)
Dave
Anyone want to do the minutes?
Ge0rG
Alright.
SamWhited
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
Dave
Ta. I should try to be more forthright on the list.
Dave
SamWhited, Me neither.
Kev
I can only do it if I'm chairing, so the meeting naturally pauses when I need it to.
Ge0rG
Me neither, but we need a volunteer.
Dave
SamWhited, I tend to do them afterward then, but they're never quite the same.
Dave
OK.
SamWhited
Yah, I don't like doing it afterwards because I always end up having questions, context goes missing, etc. anyways, thanks Ge0rG
Dave
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.
Kev
In the context of 13 I think the new XEP becomes:
Ge0rG
I don't actually think that it is a good idea for the specific 0013 case.
Kev
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'/>
Dave
So I spotted another case of this, which is that eSessions has what appears to be a perfectly reasonable full-stanza encryption definition.
Kev
Job done.
Kev
(Not quite job done, but bloody close)
Ge0rG
Kev: but race conditions!
SamWhited
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.
Ge0rG
I'm in favor of killing 13 once we have a way to properly do MAM without offline.
Dave
Anyone want to volunteer for the XEP-0013 case?
daniel
wasn't my idea of putting current mam settings in disco info rejected because people didn't like 13's purge?
Ge0rG
13 is not a way to properly do it.
Dave
Ge0rG, Sure. But it's better than nothing, and extracting it means we can ditch the rest (I think).
daniel
without that i don't see how we can savefly purge anyway
daniel
no matter if that's actual xep13 or xep405 purge
SamWhited
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.
Dave
SamWhited, I'd rather a new XEP, to shoehorning things into MAM.
Kev
Something better than -13's "purge offline" is even better, naturally. Like "Disable offline until this session ends" or something.
Ge0rG
daniel: I haven't had time to think through the implications of your proposal yet.
SamWhited
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
Ge0rG
Kev: what about adding to MAM: "if a client performs a MAM query before sending initial presence, no offline messages will be sent"
daniel
Ge0rG, just not sending them will make them pile up though
Kev
Ge0rG: That works if it's "and they're purged", I think.
Ge0rG
daniel: on a MAM server, the offline messages queue should be merely a pointer into the archive
Ge0rG
MattJ had an interesting idea with maintaining per-client offline-message pointers
daniel
Ge0rG, should…
Dave
Not wishing to stop this discussion, but I'd like to bring the discussion around somewhat.
Ge0rG
Dave: do you have other cased for extracting goo ideas from bad XEPs?✎
Ge0rG
Dave: do you have other cases for extracting good ideas from bad XEPs? ✏
Dave
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?
Dave
Ge0rG, eSessions full stanza encryption?
Holger
Blocking non-contacts from 0016?
Kev
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.
SamWhited
Depends on the situation, I don't think we can make a general statement here
Ge0rG
Kev: how is forking a part of a Draft into a new XEP and deprecating the Draft better?
Dave
OK, I don't think we're coming to a conclusion here.
Kev
I don't think there's a general conclusion to come to, other than 'it's an option'.
Dave
Which isn't a bad thing, indeed.
Dave
So, moving on:
Dave
4) Dusty Drafts
Note thread - Sam wanted to place this on the agenda.
SamWhited
Can we decide what to do in this specific place before we move on?
Kev
My preference would be a 'good' fix, and get rid of all of 13.
Ge0rG
what Kev said
Kev
If we can't do that, just keeping that one bit of 13 alive through a new XEP would work for me.
Ge0rG
recycling that bit of 13 is bad.
Lancehas left
Ge0rG
it's a shortcut that's going to bite users.
Dave
I don't have a strong preference here, though currently we're stuck in Clausevitz's dilemma.
Dave
Right, I'm going to move on.
Ge0rG
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
SamWhited
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.
SamWhited
4. remove the notice from MAM and depend on the new thing.
Kev
I'm not sure it's a case of legacy systems. Offline messages haven't been deprecated or anything.
SamWhited
Still doing partial 0016, I mean.
Kev
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.
Zash
Offline messages aren't technically a spec, right?
Kev
*than wording
daniel
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
daniel
so it doesn't really matter if you purge explictiy or implicitly
Dave
Really moving on, please.
Dave
4) Dusty Drafts
Note thread - Sam wanted to place this on the agenda.
Dave
So we've a bunch of Draft XEPs that haven't been touched in years.
Kev
I think you want each XEP as a Council agendum for CFE.
SamWhited
CFE?
Kev
Call For Experience.
Kev
Last Call, but for Final.
Dave
That'd be to move to Final. But I'd have thought many of them should be moving to Deprecated.
Kev
I was thinking we'd discuss CFEing each, and when we decide 'no', we'd then vote on deprecated, but whatever.
Dave
Oh, I can do that.
Ge0rG
Sounds good to me. CFE -> deprecated|final
Dave
If everyone's happy with that concept, we can do that next week?
Kev
WFM
SamWhited
We don't need to actually issue a CFE for some of these do we? I feel like a few of them are obvious
SamWhited
s/obvious/uncontroversial/
Kev
SamWhited: For deprecating, or going to Final?
Kev
We have to CFE if we're going to Final.
SamWhited
For deprecating
Dave
SamWhited, We wouldn't be CFEing any we want to deprecate.
Kev
No, that's what I was (trying to) say.
Ge0rG
So we need to decide which ones to CFE.
Kev
We ask "Shall we CFE?" for each one, and when Council says "No", we then say "Shall we deprecate then?" and we say "Yes".
SamWhited
ahh, I see, we don't actually go to CFE. Yah, that seems sensible.
Dave
What Kev says seems reasonable to me.
Kev
Otherwise we have a discussion about which one we should CFE and which we should vote to deprecate, and this just seemed cleaner/quicker.
Dave
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.
Dave
(Otherwise this could drag on for a month...)
SamWhited
We could probably vote on at least two of them right now, I suspect.
Dave
Can everyong commit to that?
daniel
wfm
Kev
I wouldn't want to vote on anything without reading the XEP first, so wouldn't like to vote on anything today.
Dave
Great.
Kev
But yes, my general policy is Wednesday morning I spend reviewing stuff that's on the Agenda before Council.
Ge0rG
+1 for vote next week
SamWhited
Really? Because SOAP and Internet Metadata seem like obvious candidates to deprecate, we might as well get those off the table
Dave
Kev, I'll get the next agenda out in advance properly.
Kev
SamWhited: Except there's interesting stuff in SHIM :)
Lancehas joined
Dave
SamWhited, I'm willing to bet SHIM is used for vital stuff in pubsub. And I dislike the protocol.
Dave
OK.
SamWhited
Just SOAP then
Dave
5) AOB
Dave
Anything else?
Ge0rG
I've got some
Dave
SamWhited, I've been to FOSDEM, SOAP is very much deprecated already it seems.
SamWhited
Right, so let's go ahead and formalize that and have less to do next week
Dave
Ge0rG, Shoot.
Ge0rG
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
Ge0rG
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.
Lancehas left
Lancehas joined
Ge0rG
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.
Ge0rG
| "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])."
Dave
Ge0rG, Can you run up a specific patch to vote on for next week?
Ge0rG
Dave: I can put the above sentence into a PR, if you wish so.
Ge0rG
I'm aware that this is changing a Draft, but it's reflecting what most implementations are doing anyway.
Ge0rG
I've got more AOBs.
Dave
Ge0rG, Keep going, then. :-)
Ge0rG
Flow said today that <origin-id/> was supposed as a MUC workaround. With 5.1 addressed, I'd like to remove <origin-id/>
Ge0rG
(this being 5.2)
Kev
Ge0rG: If you're proposing text that breaks MUC, please note that in that text.
Kev
(I actually think a disco feature might be appropriate)
Dave
Ge0rG, Again, I'd like to see a specific PR to vote on, but given 5.1 I'd see 5.2 as desirable.
Ge0rG
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
Ge0rG
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>?
Kev
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.
Kev
Ge0rG: Can out of band the details, and get something I'm happy with, I think.
Ge0rG
Kev: I'd be glad to get your input on this, even in short form.
Kev
Sure, but out of band, so the meeting can stop overrunning :)
Ge0rG
I'm sure I had another AOB, but I forgot to write about it to standards@
Dave
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. :-)
Ge0rG
maybe it was about more feedback regarding the non-dataforms extension of 401, but Kev made a good point on that on list
Dave
6) Next Meeting
Dave
Same Time Next Week?
daniel
Wfm
Kev
WFM
SamWhited
WFM
Dave
Lovely.
Ge0rG
I can't guarantee yet.
Ge0rG
Will be on mobile probably, but I'll try hard.
Dave
Ge0rG, If we're going to run through these Draft XEPs, it'd be really useful to have you around.
Ge0rG
Dave: I know.
Dave
OK.
Dave
7) Ite, Meeting Est.
Dave
Thanks all.
Kev
Thanks all.
Ge0rG
Thanks
Kev
Ge0rG: I suggest something like urn:...stable-id as the feature, on the MUC itself.
Ge0rG
Kev: that means we need to disco#info each MUC, as opposed to each MUC domain, right?
Kev
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".
Ge0rG
disco#items/disco#info on your own domain's services is free essentially
Ge0rG
Kev: thanks!
Kev
The disco feature is kinda assuaging my guilt at making a breaking change to a Draft XEP, as much as anything.
Kev
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.
Ge0rG
Kev: I can promise I'm not going to use that disco#info feature.
Kev
But it could be put on the MUC domain and the MUC room, I guess, or just on the domain, or whatever.
Ge0rG
but then again, just opening tickets with broken implementations won't solve the problem either
Kev
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.
danielhas left
peterhas joined
danielhas left
ralphmhas left
danielhas left
danielhas left
danielhas left
ralphmhas joined
danielhas left
danielhas left
Lancehas left
Lancehas joined
Lancehas left
Lancehas joined
danielhas left
ralphmhas joined
Davehas left
Davehas left
danielhas left
jonasw
as much as I’d like to take minutes, the council meeting is unfortunately exactly during my commute until at least june :(