KevI believe I'm now current on all Council votes.
DaveKev, In email?
vanitasvitaehas left
KevYes, I owed three weeks ago, which I sent last week, and two weeks ago, which I just sent.
KevLast week had no outstanding votes.
jerehas joined
Davehas left
dwdhas joined
Davehas left
dwdhas left
dwdhas joined
dwdhas left
Davehas left
dwdhas joined
Davehas left
dwdhas left
Davehas left
moparisthebesthas joined
dwdhas joined
Davehas left
dwdhas left
dwdhas joined
moparisthebesthas joined
dwdhas left
Davehas left
dwdhas joined
Davehas left
dwdhas left
dwdhas joined
Davehas left
dwdhas left
danielhas left
dwdhas joined
dwdhas left
Davehas left
Davehas left
SouLhas left
danielhas left
Davehas left
Davehas left
danielhas left
Davehas left
dwdhas joined
dwdhas left
moparisthebesthas joined
Davehas left
Zashhas left
Davehas left
moparisthebesthas joined
dwdhas joined
Davehas left
dwdhas left
Davehas left
Davehas left
Davehas left
Davehas left
Davehas left
Davehas left
dwdhas joined
Zashhas left
Zashhas joined
dwdhas left
Davehas left
dwdhas joined
Davehas left
dwdhas left
Lancehas left
Lancehas joined
Davehas left
ralphmhas left
dwdhas joined
bearhas left
Davehas left
dwdhas left
dwdhas joined
dwdhas left
Davehas left
danielhas left
dwdhas joined
dwdhas left
moparisthebesthas joined
Davehas left
moparisthebesthas joined
Davehas left
dwdhas joined
Davehas left
Davehas left
dwdhas left
Davehas left
Davehas left
Davehas left
jerehas left
jerehas joined
Davehas left
danielhas left
Davehas left
Zashhas left
ralphmhas joined
dwdhas joined
Davehas left
dwdhas left
Davehas left
Zashhas joined
ralphmhas joined
Davehas left
Davehas left
Davehas left
ralphmhas left
Davehas left
Davehas left
Davehas left
vanitasvitaehas left
vanitasvitaehas left
Davehas left
Davehas left
ralphmhas left
dwdhas joined
Davehas left
Davehas left
dwdhas left
ralphmhas left
Tobiashas joined
dwdhas joined
dwdhas left
danielhas left
danielhas left
danielhas left
Ge0rGhas joined
danielhas left
DaveTime, gentlemen, please.
Dave1) Role Call
Ge0rG.o/
Davedaniel, Kev SamWhited ?
danielhere
SamWhitedI'm here
KevI'm here.
KevAt least in body, if not in mind.
Ge0rG🙋
Dave2) Extrcting chunks of XEPs
DaveActually, no.
Dave2) For fork's sake, can somebody else take the minutes?
Dave(Found my agenda copy)
DaveAnyone want to do the minutes?
Ge0rGAlright.
SamWhitedWhile 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
DaveTa. I should try to be more forthright on the list.
DaveSamWhited, Me neither.
KevI can only do it if I'm chairing, so the meeting naturally pauses when I need it to.
Ge0rGMe neither, but we need a volunteer.
DaveSamWhited, I tend to do them afterward then, but they're never quite the same.
DaveOK.
SamWhitedYah, I don't like doing it afterwards because I always end up having questions, context goes missing, etc. anyways, thanks Ge0rG
Dave3) 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.
KevIn the context of 13 I think the new XEP becomes:
Ge0rGI don't actually think that it is a good idea for the specific 0013 case.
Kev2.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'/>
DaveSo I spotted another case of this, which is that eSessions has what appears to be a perfectly reasonable full-stanza encryption definition.
KevJob done.
Kev(Not quite job done, but bloody close)
Ge0rGKev: but race conditions!
SamWhitedIn 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.
Ge0rGI'm in favor of killing 13 once we have a way to properly do MAM without offline.
DaveAnyone want to volunteer for the XEP-0013 case?
danielwasn't my idea of putting current mam settings in disco info rejected because people didn't like 13's purge?
Ge0rG13 is not a way to properly do it.
DaveGe0rG, Sure. But it's better than nothing, and extracting it means we can ditch the rest (I think).
danielwithout that i don't see how we can savefly purge anyway
danielno matter if that's actual xep13 or xep405 purge
SamWhitedMaybe 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.
DaveSamWhited, I'd rather a new XEP, to shoehorning things into MAM.
KevSomething better than -13's "purge offline" is even better, naturally. Like "Disable offline until this session ends" or something.
Ge0rGdaniel: I haven't had time to think through the implications of your proposal yet.
SamWhitedIt 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
Ge0rGKev: what about adding to MAM: "if a client performs a MAM query before sending initial presence, no offline messages will be sent"
danielGe0rG, just not sending them will make them pile up though
KevGe0rG: That works if it's "and they're purged", I think.
Ge0rGdaniel: on a MAM server, the offline messages queue should be merely a pointer into the archive
Ge0rGMattJ had an interesting idea with maintaining per-client offline-message pointers
danielGe0rG, should…
DaveNot wishing to stop this discussion, but I'd like to bring the discussion around somewhat.
Ge0rGDave: do you have other cased for extracting goo ideas from bad XEPs?
Ge0rGDave: do you have other cases for extracting good ideas from bad XEPs?
DaveIn 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?
DaveGe0rG, eSessions full stanza encryption?
HolgerBlocking non-contacts from 0016?
KevIf it wasn't Draft, I'd suggest cutting the other stuff from the XEP. But I don't think that's appropriate at Draft.
SamWhitedDepends on the situation, I don't think we can make a general statement here
Ge0rGKev: how is forking a part of a Draft into a new XEP and deprecating the Draft better?
DaveOK, I don't think we're coming to a conclusion here.
KevI don't think there's a general conclusion to come to, other than 'it's an option'.
DaveWhich isn't a bad thing, indeed.
DaveSo, moving on:
Dave4) Dusty Drafts
Note thread - Sam wanted to place this on the agenda.
SamWhitedCan we decide what to do in this specific place before we move on?
KevMy preference would be a 'good' fix, and get rid of all of 13.
Ge0rGwhat Kev said
KevIf we can't do that, just keeping that one bit of 13 alive through a new XEP would work for me.
Ge0rGrecycling that bit of 13 is bad.
Lancehas left
Ge0rGit's a shortcut that's going to bite users.
DaveI don't have a strong preference here, though currently we're stuck in Clausevitz's dilemma.
DaveRight, I'm going to move on.
Ge0rGI 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
SamWhitedProposal: 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.
SamWhited4. remove the notice from MAM and depend on the new thing.
KevI'm not sure it's a case of legacy systems. Offline messages haven't been deprecated or anything.
SamWhitedStill doing partial 0016, I mean.
KevBut 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.
ZashOffline messages aren't technically a spec, right?
Kev*than wording
danielinterestingly 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
danielso it doesn't really matter if you purge explictiy or implicitly
DaveReally moving on, please.
Dave4) Dusty Drafts
Note thread - Sam wanted to place this on the agenda.
DaveSo we've a bunch of Draft XEPs that haven't been touched in years.
KevI think you want each XEP as a Council agendum for CFE.
SamWhitedCFE?
KevCall For Experience.
KevLast Call, but for Final.
DaveThat'd be to move to Final. But I'd have thought many of them should be moving to Deprecated.
KevI was thinking we'd discuss CFEing each, and when we decide 'no', we'd then vote on deprecated, but whatever.
DaveOh, I can do that.
Ge0rGSounds good to me. CFE -> deprecated|final
DaveIf everyone's happy with that concept, we can do that next week?
KevWFM
SamWhitedWe don't need to actually issue a CFE for some of these do we? I feel like a few of them are obvious
SamWhiteds/obvious/uncontroversial/
KevSamWhited: For deprecating, or going to Final?
KevWe have to CFE if we're going to Final.
SamWhitedFor deprecating
DaveSamWhited, We wouldn't be CFEing any we want to deprecate.
KevNo, that's what I was (trying to) say.
Ge0rGSo we need to decide which ones to CFE.
KevWe ask "Shall we CFE?" for each one, and when Council says "No", we then say "Shall we deprecate then?" and we say "Yes".
SamWhitedahh, I see, we don't actually go to CFE. Yah, that seems sensible.
DaveWhat Kev says seems reasonable to me.
KevOtherwise we have a discussion about which one we should CFE and which we should vote to deprecate, and this just seemed cleaner/quicker.
DaveBut, 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...)
SamWhitedWe could probably vote on at least two of them right now, I suspect.
DaveCan everyong commit to that?
danielwfm
KevI wouldn't want to vote on anything without reading the XEP first, so wouldn't like to vote on anything today.
DaveGreat.
KevBut yes, my general policy is Wednesday morning I spend reviewing stuff that's on the Agenda before Council.
Ge0rG+1 for vote next week
SamWhitedReally? Because SOAP and Internet Metadata seem like obvious candidates to deprecate, we might as well get those off the table
DaveKev, I'll get the next agenda out in advance properly.
KevSamWhited: Except there's interesting stuff in SHIM :)
Lancehas joined
DaveSamWhited, I'm willing to bet SHIM is used for vital stuff in pubsub. And I dislike the protocol.
DaveOK.
SamWhitedJust SOAP then
Dave5) AOB
DaveAnything else?
Ge0rGI've got some
DaveSamWhited, I've been to FOSDEM, SOAP is very much deprecated already it seems.
SamWhitedRight, so let's go ahead and formalize that and have less to do next week
DaveGe0rG, Shoot.
Ge0rG5.1: I'd like to re-call the MUC rewriting @id's discussion from https://mail.jabber.org/pipermail/standards/2014-July/028988.html
Ge0rGBack 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
Ge0rGSo 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])."
DaveGe0rG, Can you run up a specific patch to vote on for next week?
Ge0rGDave: I can put the above sentence into a PR, if you wish so.
Ge0rGI'm aware that this is changing a Draft, but it's reflecting what most implementations are doing anyway.
Ge0rGI've got more AOBs.
DaveGe0rG, Keep going, then. :-)
Ge0rGFlow 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)
KevGe0rG: If you're proposing text that breaks MUC, please note that in that text.
Kev(I actually think a disco feature might be appropriate)
DaveGe0rG, Again, I'd like to see a specific PR to vote on, but given 5.1 I'd see 5.2 as desirable.
Ge0rGand 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
Ge0rGKev: 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>?
KevGe0rG: 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.
KevGe0rG: Can out of band the details, and get something I'm happy with, I think.
Ge0rGKev: I'd be glad to get your input on this, even in short form.
KevSure, but out of band, so the meeting can stop overrunning :)
Ge0rGI'm sure I had another AOB, but I forgot to write about it to standards@
DaveGe0rG, 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. :-)
Ge0rGmaybe it was about more feedback regarding the non-dataforms extension of 401, but Kev made a good point on that on list
Dave6) Next Meeting
DaveSame Time Next Week?
danielWfm
KevWFM
SamWhitedWFM
DaveLovely.
Ge0rGI can't guarantee yet.
Ge0rGWill be on mobile probably, but I'll try hard.
DaveGe0rG, If we're going to run through these Draft XEPs, it'd be really useful to have you around.
Ge0rGDave: I know.
DaveOK.
Dave7) Ite, Meeting Est.
DaveThanks all.
KevThanks all.
Ge0rGThanks
KevGe0rG: I suggest something like urn:...stable-id as the feature, on the MUC itself.
Ge0rGKev: that means we need to disco#info each MUC, as opposed to each MUC domain, right?
KevAnd 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".
Ge0rGdisco#items/disco#info on your own domain's services is free essentially
Ge0rGKev: thanks!
KevThe disco feature is kinda assuaging my guilt at making a breaking change to a Draft XEP, as much as anything.
KevI'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.
Ge0rGKev: I can promise I'm not going to use that disco#info feature.
KevBut it could be put on the MUC domain and the MUC room, I guess, or just on the domain, or whatever.
Ge0rGbut then again, just opening tickets with broken implementations won't solve the problem either
KevI 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
jonaswas much as I’d like to take minutes, the council meeting is unfortunately exactly during my commute until at least june :(
XMPP Council - 2018-02-28