jonas’this one threatens to become non-boring, hence I was a bit distracted
jonas’2) Agenda Bashing
jonas’please mention any AOB during the meeting—I know that Ge0rG had some AOB, but it seems that we’re now lacking Ge0rG
jonas’3) Editor’s Update
jonas’- Last Call on XEP-0313 expired (last week already)
- Last Call on XEP-0280 expired yesterday (2021-04-06)
jonas’4) Items for voting
jonas’4a) Decide on Advancement of XEP-0313: Message Archive Management
Abstract: This document defines a protocol to query and control an archive of messages stored on a server.
jonas’I share Ge0rGs concerns about the security considerations section
jonas’his AOB is related
dwdIs the AOB about CVE listing in XEPs?
Zashon-list, haven't read all the LC replies yet
danielOn list as well
danielI have complicated feelings about both of these xeps...
jonas’do you want to share your feelings with the group, daniel? :)
dwdI would like to understand the CVE position, and run that past the list ideally, before voting.
ZashI'd say they feel like pretty large parts of Modern XMPP
danielBoth feel like rather temporary fixes to more fundamental issues in the protocol
jonas’daniel, are you hinting at Bind2 + IM-NG?
ZashTowards Future XMPP?
danielMaybe. But even IM-NG is going to be complicated
danielMore like what Zash said
KevThey’re both pretty temporary. If either lasts more than a couple of decades I’d be surprised.
SamObligatory advertisement for next week's office hours: Towards XMPP 2.0 roundtable discussion
danielBut that said that shouldn't necessarily stood us from advancing them
danielIt's just an explanation towards why we are never really going to be happy about those two xeps
jonas’daniel, that’s certainly true
KevI think if one doesn’t have complicated thoughts about these XEPs (at least carbons, maybe MAM), they probably don’t understand :)
ZashHm, it'd probably be good to go through previous LCs (there has been a couple, right?) and check if everything raised there has been adressed
ZashSomething something representing a big shift in how XMPP works 🤷️
jonas’Zash, do you volunteer? :)
ZashI did not say that 🙂
danielIIRC a lot of the previous LCs were it doesn't cover this specific edge case
danielAnd I don't think it will ever do that
danielWe just have to live with that. Probably...
jonas’I mean at this stage, the XEPs are certainly a 80%-95% solution to the problem of "how to get all relevant messages on all devices"
ZashUntil IM-NG et all?
dwdActually, thinking more about this, +1 to advancing. We can add the CVE bits in afterward just fine.
Ge0rGI've gone through my LC feedback for 0280 at least
jonas’they’re worth moving to Draft based on that.
Ge0rGI'm on-list for 313 because I really want to see a discussion of the points I brought up
jonas’Ge0rG, I skimmed them and my summary is mostly "Bind2"
Ge0rGAnd honestly I'm most interested in properly specified storage rules in 313
jonas’Ge0rG, I skimmed them and my summary is mostly "Bind2" (for the long part at the bottom)
ZashI'm wondering if those rules aren't going to have to evolve as we go forward, with new XEPs etc.
ZashSame with carbons
Ge0rGjonas’: well, bind2 won't solve all problems of 313
jonas’Ge0rG, see the parenthesis I added
Ge0rGZash: yes, so having them under a separate namespace is a good idea
daniel> I'm wondering if those rules aren't going to have to evolve as we go forward, with new XEPs etc.
> Same with carbons
Yes. We don't really have a good definition of what a message is
danielThat's the problem with both of these xeps
Ge0rGNot in the context of IM
ZashGe0rG, I think I meant like, new XEPs should maybe describe whether the payloads they describe should/should not be stored.
jonas’IM-NG has an idea how to address (pun intended) this, I think it deserves more experimentation
Ge0rGI hope that my work on the 0280 rules can be applied equally to 313
ZashTho a whole new $XEP Rules XEP could work too
SamFWIW, this is all part of why I think these two need to advance. We probably can't get them perfect, they may need to change in the future, but they're both already extremely widely implemented so we probably can't change them that much. That sounds like draft to me.
Ge0rGZash: like Hints?
ZashIn my experience you want subtly different rules for MAM, Carbons and CSI, but there's definitely a bunch of overlap.
ZashOh and cloud notify stuff.
Ge0rGZash: I'm very much interested in extracting those subtle differences
ZashCould be wrong tho, but I still think they'll probably have to continue evolving in the future.
jonas’likely, especially when push services evolve the cloud notify stuff will have to evolve
Keve.g. as long as they’re in <message/>s, you want CSN sent to carbons but not MAM.
jonas’either way… I doubt that this’s something we can solve in this meeting, I’d propose we move on through the formalities and the discussion can then be had later on?
jonas’(I don’t seem to be getting typing notifications in this channel anymore, so I hope I don’t cut anyone off)
Ge0rGI'm here from yaxim
4a) Decide on Advancement of XEP-0280: Message Carbons
Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources.
ZashI don't think Dino sends typing notifications to this kind of chat
Zashon list here too
Ge0rGI'm also very much interested in more list feedback, especially from server developers
Ge0rGThe LC feedback wasn't appropriate to the importance of the XEP, but I don't know what that means.
Ge0rGMaybe it's just working perfectly for everybody.
jonas’probably the community is worn out after the ten dozen LCs this already had
jonas’but I haven’t experienced any carbons issue in the past years
Zashprobably the case
KevI think everyone understands that carbons is a necessary evil at the moment.
Kev(Some may disagree on the ‘evil’ part)
Ge0rGIt's a hack on top of a hack on top of a bad design from the last millennium
moparisthebestyes but how are we planning to reduce carbons by 2030
jonas’alright, same procedure as '313 I suppose
jonas’5) Pending Votes
- dwd on deprecation of '13
dwdSorry, major incident at work, I need to drop.
jonas’ok, good luck!
jonas’moving on then
jonas’6) Date of Next
jonas’hands the mic to Ge0rG
Ge0rGYeah, CVEs in XEPs. This is not strictly a protocol thing, as it doesn't affect the protocol itself but only its implementations, but I think that it goes in a similar direction as DOAP, where we map out which implementations support which XEP
Ge0rGI'm currently working on a first draft of a `<cve/>` XML element for XEPs that works in a similar way as a `<code>` block
jonas’I think that having references to past CVEs in the Security Considerations of affected XEPs is a good thing to show the severity and also the rationale for specific rules.
jonas’no objections with either of my hats
ZashIn the XEPs themselves or, like DOAP, merged in during rendering?
jonas’in the XEPs themselves
Ge0rGfirst rendered example at https://op-co.de/tmp/xep-0280.html#security
jonas’having it in the metadata of the document feels wrong because CVEs are about implementations, not about protocols (in most cases anyway… https://xmpp.org/extensions/xep-0223.html#revision-history-v1.1 might be a notable exception)
So adding a list of CVEs to a protocol seems incorrect (in general).
Ge0rGWhat jonas’ said
Ge0rGAnd having a custom element hopefully gives us enough rope to extract it later on.
jonas’in addition, for the CVEs which are more like implementation notes / security considerations, embedding the metadata-cve-list at the right place in the document becomes a non-trivial XSL task
jonas’Ge0rG, that looks great already
Ge0rGjonas’: if you have some CSS magic to add a red warning sign to the left and to the right, I'd be very grateful
Ge0rGXSL magic works as well.
jonas’we’d need artwork for that, unicode is not good enough as I learnt recently
Ge0rGdon't we have some obscure math symbol we can use?
Ge0rGAlso what's wrong with ⚠?
jonas’depends on how it’s used it’s an accessibility issue
jonas’needs to be looked at in detail anyway
Ge0rGjonas’: you just volunteered? :)
jonas’Ge0rG, I can fix you up with some CSS in your PR, yes
jonas’if and only if it is solvable without :before/:after, because I haven’t found a good solution for those yet
jonas’any other notes on this topic?
Ge0rGwell, I actually wanted to do some more talking about my LC comments on both 313 and 280
Ge0rGbut we are also over time and I need to get into a business that closes at 1800CEST
jonas’yeah, I’m also super hungry
jonas’any other AOB?
jonas’(I suggest you bring the general '280/'313/cloud-notify? discussions on-list and/or try to schedule an A/V call with interested participants)
jonas’assuming no other AOB
jonas’8) Ite Meeting est
jonas’8) Ite Meeting Est
ZashThanks jonas’, all.
Ge0rGjonas’: do the LC mails count as "bringing up"?
Ge0rGI have a feeling that I should -1 the 0313 as-is, because of lack of business rules. My feeling is that the 0280 rules were a huge step forward, even if they aren't perfect, and that having them in 0313 would be another huge benefit. That and business rules for clients.
Ge0rGI can live without the bind2 stuff
ZashI'm thinking you probably want to make the CVEs count as references, wrt the XML magic.
Ge0rGZash: my head might explode if I try that.
Ge0rGI'm largely copy&pasting stuff from other places in the xsl
jonas’Ge0rG, I think you’re not wrong about the rule stuff
ZashHmm, there was that talk about dusting off https://xmpp.org/extensions/xep-0226.html or something similar