Ge0rGwell, given an excellently prepared agenda, somebody can step in
dwdI have a chair, thankfully. Though no desk, yet.
Ge0rG1) Roll Call
dwdOh, jonas’ said he might forget.
Ge0rGlooks like we are missing jonas’
Ge0rGeverybody else is here, great!
Ge0rG2) Agenda Bashing
Ge0rGare there any things to add?
Ge0rG3) Editor’s Update
Ge0rGEditor's been very busy, we have some things to vote on today.
Ge0rG4) Items for voting
Ge0rGplease note that our term is closing, and we need to submit all votes until November 24th.
Ge0rGCan we manage that?
jonas’yeah, it happened
jonas’I was pulling cookies out of the oven just now
jonas’here I am
jonas’sorry for the delay, thanks for taking over, Ge0rG
Ge0rGjonas’: do you want to have the chair hat back?
dwdGe0rG, Maybe it's a hat chair?
jonas’Ge0rG, works for me
jonas’let’s see what happens to our votes :)
Ge0rGI was just going to ask if everbody silently agrees with submitting all pending votes until November 24th.
jonas’4a) Proposed XMPP Extension: File metadata element
Abstract: This specification defines a generic file metadata element to be used in other specifications.
jonas’Ge0rG, let’s just try and hope I don’t have to read bylaws or something
dwdThis one got some discussion on list already, and seems fine, so +1.
dwdAges ago, IIRC.
jonas’I am +1, though I do have remarks I’ll suggest to the authors on-list
ZashGot a reference to this previous discussion?
dwdOr at least, it all looked familiar so I assumed I'd seen it before.
Ge0rGthis looks like it's copying the <file> element out of XEP-0234 for the sake of copying the <file> element out of XEP-0234. Am I missing something?
jonas’Ge0rG, pretty much that
jonas’the idea is to have it separate for use in other specs and not bound to the '234 namespace, IIRC
Ge0rGwhat would be the way forward when we ever have to bump file-metadata? Will a client send two <file> elements with different namespaces?
Ge0rGWell, given that 0234 is deferred, I think it's well worth a try, so +1
ZashI'm not entirely convinced that another XEP fixes anything
Ge0rGand it's missing clarification on which file elements are mandatory
ZashExperimental doesn't need to be perfect
danielthe idea isn’t to make it reslient against bumps but to better use it outside of jingle, no?
Ge0rGZash: me neither, but having smaller, reusable elements as their own XEPs looks like a good idea
dwdGe0rG, "All child elements are OPTIONAL"
dwdGe0rG, Seems clear enough to me. :-)
Ge0rGdaniel: yes, but making it reusable will make it prone to bumping.
ZashI would appreciate a pointer to previous discussion
jonas’4b) Proposed XMPP Extension: Stateless file sharing
Abstract: This specification describes a protocol for stateless asynchronous file sharing with integrity and transport flexibility. It allows clients to provide a good interoperable user experience in combination with Carbons and MAM.
dwdZash, Yeah, same. Might have been in the XSF@ chatroom, but I'm sure I've seen something like this from larma before.
dwdSo this one is SIMS but based aorund the file metadata, so eradicates SIMS, right?
ZashEaiser to make a new XEP than to re-author SIMS?
jonas’dwd, but based around the file-metadata and *not* around references
Ge0rGwouldn't it be a much more sane approach to just let Marvin co-author SIMS and do all the fixes there?
dwdGe0rG, For this one in particular, I wondered about that approach myself.
Zash+1. let them A/B fight for the throne of OOB
jonas’the key difference would be "No mixed content, body is used for fallback only and not to transmit additional information." + "Not relying on underspecified usage of References (XEP-0372) ."
danielhas there been a clear consensus on that we want this kind of refactor from SIMS?
danielbecause SIMS might still be useful for other things
jonas’do we need consensus before accepting this as Experimental?
Ge0rGjonas’: I like the first ones, and the last one is largely political
jonas’ah, from that perspective
dwddaniel, Hard to say, see my notes on communications elsewhere.
jonas’Ge0rG, the first one and the last one are pretty much tied together
jonas’I’m also +1 on this one, same as Zash
Ge0rGSo we are going to end up with clients sending three different "file attached" elements for compat reasons?
dwdGe0rG, Each supporting 19 different FT mechanisms?
Ge0rGdwd: each supporting the same 19 mechanisms as the other one(s).
Zash... but in practice it's all equivalent to <body>https://foo/bar.png</>
ZashGe0rG, imagine the market for server-side translation modules!!!
dwdAnyway, I'm +1 (in as much as I do not object)
jonas’Ge0rG, currently, there is only OOB, right?
jonas’so it would be at most two
Ge0rGjonas’: there is SIMS
dwdGe0rG, I love your optimism that both clients would have any FT mechanisms in common at all.
jonas’Ge0rG, not in any real-world use
danieland with the body fallback it's probably relatively safe to just drop oob at some point
dwddaniel, I hate boyd fallback, but there we are...
dwddaniel, I hate body fallback, but there we are...
ZashBut we have the body fallback indicator! It's just lacking a fallback...
ZashSo we have [+4, on-list]. Next?
jonas’4c) Proposed XMPP Extension: Encryption for stateless file sharing
Abstract: This specification provides a protocol for sharing encrypted files using the stateless file sharing protocol (XEP-xxxx).
jonas’+1, I sent feedback to the list
jonas’(just now, so it’ll probably arrive tomorrow)
jonas’(note that this directly depends on the previous one)
danieli'm not seeing that feedback
danielwas this in reply to the proposed?
jonas’daniel, as I said, I sent it just now, so it’ll take a while
jonas’the list server hates me
jonas’(peak delay for my mail was something like an hour or so.)
danieloh fair enough
jonas’my feedback was mainly tha the cipher list should go in its own informational XEP like we have for hashes
dwdWell, I think this has issues, but nothing insurmountable, so we'll publish first and fix afterward. I hope.
jonas’dwd, is that a disguised +1?
larmajonas’, agree, especially due to overlap with JET
jonas’larma, excellent :)
Ge0rGI like the Security Considerations.
jonas’me too :D
jonas’i chuckled when I reached that point
jonas’Ge0rG, is that a vote?
dwdjonas’, Yeah, +1. I was thinking mostly that it's unclear if every cipher suite will have or need a "key" and "IV" split like that. Most do, of course, but IIRC there are encrypted formats which essentially include the IV.
jonas’Ge0rG, you do realize that esfs depends strictly on sfs?
jonas’and that you are on-list for sfs?
Ge0rGI'm in a deadlock now
jonas’think about that ;)
Ge0rGif you can put <sources> inside of <encrypted> inside of <sources>, how many levels of encryption can you stack?
dwdjonas’, As written, it does, but it could be "fixed" to be written around SIMS or something.
Ge0rGin that case I'm on-list.
jonas’4d) Proposed XMPP Extension: Stickers
Abstract: This specification provides a protocol to send stickers and to create and share sticker packs.
Ge0rGit doesn't duplicate SIMS functionality, so I'm less strict on that one.
jonas’the hash calculation looks very familiar
jonas’someone stole from '390 ;)
Ge0rGon-list; I need to think about the technical implications as well as copyright violation issues.
jonas’larma, since you’re around: please consider how to re-do it around NUL instead of ASCII separators, since ASCII separators are valid XML 1.1 (as opposed to 1.0), while NUL is not valid in any XML version.
dwdI may be too old to fully understand what a Sticker is.
jonas’yeah this one is more complex, I’m on-list too
Ge0rGdwd: something like a large custom emoji
dwdI mean, I'm *all* about the Giphy. But I'm not sure I understand Stickers. I'm going to on-list this one.
dwdGe0rG, Yeah, but they come in packs? Like wolves?
jonas’Zash, daniel, ?
danielalthough I wonder if stickers might be better of with SIMS rather than file sharing
Ge0rGdwd: that would be like different emoji fonts, or somesuch
danieldoesn’t know how sticker work
jonas’5) Pending Votes
Ge0rGI'm +1 on #1001
larmajonas’, I'd rather enforce that name,desc and summary may not include ascii seperators instead of using null byte (because whatever is in those should be displayable to end-users anyway), but I see your point.
jonas’except for those started today, we have pending votes:
- everyone except Ge0rG (thanks) on #1001
- dwd on advancement of CS-2020
jonas’larma, let’s do that in addition, but being resilient against it comes at little cost
dwdWhat's the current voting on CS-2021
jonas’dwd, everoyne +1, except you
Ge0rGwell, we *could* advance CS-2020 to Final, right?
jonas’that needs a CFE which is at least 2w long
jonas’so "we" cannot
dwdOh, I'll +0.
ZashMaybe we could ask Board to add a special compliance suite thing in XEP-0001
jonas’we’re already over our meeting time
danielalso it needs to be 6 month old, no?
jonas’please cast votes for #1001 on-list, please
jonas’daniel, right, there was something about that ...
jonas’6) Date of Next
jonas’anyone got any?
Ge0rGCS-2020 is over a year old now!
jonas’I always confuse those
jonas’technically, it needs to have been in draft for 6m, but yes
Ge0rGjonas’: I noticed ;)
jonas’Ge0rG, that’s anyway next council’s problem
Ge0rG> Update to Draft as per council vote on 2019/11/07.
Ge0rGwe could cast a CFE just now
jonas’Ge0rG, I’m not sure how those work across council boundaries
Ge0rGignore everything I've said, it was just a sophisticated byrules troll attempt.
jonas’Ge0rG, ok, thanks for doing that while we’re already 4 minutes over.
Ge0rGjonas’: I'm sorry.
dwdGe0rG, I think that's because whichever Council in Times Gone Past forgot that one.
jonas’assuming no other AOB:
Thank you all for this Council term. It was pleasure working with you. And special thanks (with cookies: 🍪) go to Tedd for consistently providing fun to read and comprehensive meeting minutes.
dwdGe0rG, Originally, I think neither Last Calls nor ProtoXEP Adoption/Publication were a Council thing, just Draft/Final advancements.
jonas’8) Ite Meeting Est.
dwdjonas’, Very much +1, and thanks for your excellent and concientious chairing.
Ge0rGjonas’: thanks very much as well, it was great having you put structure into everything
jonas’much of that was thanks to daves spreadsheet of doom
ZashThanks all. It's been a pleasure serving with you.
jonas’oh and also the occasional email from Tedd with summaries of things which were forgotten about
jonas’that person is incredibly valuable and we should find a way to send them covid-safe cookies or something.
dwdAlso, while obviously I hate to lose elections, at least if I lose this one I know I'll have been beaten by people who'll be good here.