well, given an excellently prepared agenda, somebody can step in
dwd
I have a chair, thankfully. Though no desk, yet.
Ge0rG
1) Roll Call
dwd
Oh, jonas’ said he might forget.
Ge0rG
looks like we are missing jonas’
Zash
4/5
Ge0rG
everybody else is here, great!
Ge0rG
2) Agenda Bashing
Ge0rG
are there any things to add?
Ge0rG
3) Editor’s Update
Ge0rG
Editor's been very busy, we have some things to vote on today.
Ge0rG
4) Items for voting
Ge0rG
please note that our term is closing, and we need to submit all votes until November 24th.
jonas’
hahaha
Ge0rG
Can we manage that?
jonas’
yeah, it happened
jonas’
I was pulling cookies out of the oven just now
jonas’
here I am
Ge0rG
welcome, jonas’!
jonas’
sorry for the delay, thanks for taking over, Ge0rG
Ge0rG
jonas’: do you want to have the chair hat back?
dwd
Ge0rG, Maybe it's a hat chair?
jonas’
Ge0rG, works for me
jonas’
let’s see what happens to our votes :)
Ge0rG
I 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
URL: https://xmpp.org/extensions/inbox/file-metadata.html
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
dwd
This one got some discussion on list already, and seems fine, so +1.
jonas’
did it?
Zash
Oh?
daniel
+1
dwd
Ages ago, IIRC.
jonas’
ah
jonas’
I am +1, though I do have remarks I’ll suggest to the authors on-list
Zash
Got a reference to this previous discussion?
dwd
Or at least, it all looked familiar so I assumed I'd seen it before.
Ge0rG
this 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?
Zash
Yes
Zash
(so no)
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
Zash
+1
Ge0rG
what would be the way forward when we ever have to bump file-metadata? Will a client send two <file> elements with different namespaces?
Ge0rG
Well, given that 0234 is deferred, I think it's well worth a try, so +1
Zash
I'm not entirely convinced that another XEP fixes anything
Ge0rG
and it's missing clarification on which file elements are mandatory
Zash
Experimental doesn't need to be perfect
daniel
the idea isn’t to make it reslient against bumps but to better use it outside of jingle, no?
Ge0rG
Zash: me neither, but having smaller, reusable elements as their own XEPs looks like a good idea
Zash
I suppose
dwd
Ge0rG, "All child elements are OPTIONAL"
dwd
Ge0rG, Seems clear enough to me. :-)
Ge0rG
daniel: yes, but making it reusable will make it prone to bumping.
jonas’
I agree
jonas’
moving on
Ge0rG
dwd: indeed
Zash
I would appreciate a pointer to previous discussion
jonas’
4b) Proposed XMPP Extension: Stateless file sharing
URL: https://xmpp.org/extensions/inbox/sfs.html
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.
daniel
+1
dwd
Zash, Yeah, same. Might have been in the XSF@ chatroom, but I'm sure I've seen something like this from larma before.
dwd
So this one is SIMS but based aorund the file metadata, so eradicates SIMS, right?
Zash
Eaiser to make a new XEP than to re-author SIMS?
jonas’
dwd, but based around the file-metadata and *not* around references
Ge0rG
wouldn't it be a much more sane approach to just let Marvin co-author SIMS and do all the fixes there?
dwd
Ge0rG, 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) [3]."
daniel
has there been a clear consensus on that we want this kind of refactor from SIMS?
daniel
because SIMS might still be useful for other things
jonas’
do we need consensus before accepting this as Experimental?
Ge0rG
jonas’: I like the first ones, and the last one is largely political
jonas’
ah, from that perspective
dwd
daniel, 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
Ge0rG
So we are going to end up with clients sending three different "file attached" elements for compat reasons?
dwd
Ge0rG, Each supporting 19 different FT mechanisms?
Ge0rG
dwd: 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</>
Zash
Ge0rG, imagine the market for server-side translation modules!!!
dwd
Anyway, 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
Ge0rG
jonas’: there is SIMS
dwd
Ge0rG, I love your optimism that both clients would have any FT mechanisms in common at all.
Ge0rG
I'm on-list
jonas’
Ge0rG, not in any real-world use
daniel
and with the body fallback it's probably relatively safe to just drop oob at some point
dwd
daniel, I hate boyd fallback, but there we are...✎
dwd
daniel, I hate body fallback, but there we are... ✏
Zash
But we have the body fallback indicator! It's just lacking a fallback...
Zash
So we have [+4, on-list]. Next?
jonas’
4c) Proposed XMPP Extension: Encryption for stateless file sharing
URL: https://xmpp.org/extensions/inbox/esfs.html
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
daniel
+1
Zash
+1
jonas’
(just now, so it’ll probably arrive tomorrow)
jonas’
(note that this directly depends on the previous one)
daniel
i'm not seeing that feedback
daniel
was 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.)
daniel
oh fair enough
jonas’
my feedback was mainly tha the cipher list should go in its own informational XEP like we have for hashes
dwd
Well, 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?
larma
jonas’, agree, especially due to overlap with JET
jonas’
larma, excellent :)
Ge0rG
I like the Security Considerations.
jonas’
me too :D
jonas’
i chuckled when I reached that point
Ge0rG
+1
jonas’
Ge0rG, is that a vote?
dwd
jonas’, 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.
Ge0rG
jonas’: yes
jonas’
Ge0rG, you do realize that esfs depends strictly on sfs?
jonas’
and that you are on-list for sfs?
Ge0rG
jonas’: damn.
Ge0rG
I'm in a deadlock now
jonas’
think about that ;)
Ge0rG
if you can put <sources> inside of <encrypted> inside of <sources>, how many levels of encryption can you stack?
dwd
jonas’, As written, it does, but it could be "fixed" to be written around SIMS or something.
jonas’
Ge0rG, :D
Ge0rG
in that case I'm on-list.
jonas’
dwd, yes
jonas’
Ge0rG, thanks
jonas’
4d) Proposed XMPP Extension: Stickers
URL: https://xmpp.org/extensions/inbox/stickers.html
Abstract: This specification provides a protocol to send stickers and to create and share sticker packs.
Ge0rG
it 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 ;)
Ge0rG
on-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.
dwd
I may be too old to fully understand what a Sticker is.
jonas’
yeah this one is more complex, I’m on-list too
Ge0rG
dwd: something like a large custom emoji
dwd
I mean, I'm *all* about the Giphy. But I'm not sure I understand Stickers. I'm going to on-list this one.
dwd
Ge0rG, Yeah, but they come in packs? Like wolves?
jonas’
Zash, daniel, ?
daniel
+1
Zash
+1
daniel
although I wonder if stickers might be better of with SIMS rather than file sharing
Ge0rG
dwd: that would be like different emoji fonts, or somesuch
danieldoesn’t know how sticker work
jonas’
alright
jonas’
5) Pending Votes
Ge0rG
I'm +1 on #1001
larma
jonas’, 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
Ge0rG
jonas’: CS-2021?
jonas’
Ge0rG, yes
dwd
What's the current voting on CS-2021
dwd
?
jonas’
dwd, everoyne +1, except you
Ge0rG
well, we *could* advance CS-2020 to Final, right?
jonas’
Ge0rG, no
jonas’
that needs a CFE which is at least 2w long
jonas’
so "we" cannot
dwd
Oh, I'll +0.
jonas’
thanks!
Zash
Maybe we could ask Board to add a special compliance suite thing in XEP-0001
jonas’
we’re already over our meeting time
daniel
also 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’
NOBODY KNOWS!!
jonas’
7) AOB
jonas’
anyone got any?
Ge0rG
CS-2020 is over a year old now!
jonas’
Ge0rG, OHH
jonas’
2020
jonas’
I always confuse those
jonas’
technically, it needs to have been in draft for 6m, but yes
Ge0rG
jonas’: I noticed ;)
jonas’
Ge0rG, that’s anyway next council’s problem
Ge0rG
> Update to Draft as per council vote on 2019/11/07.
Ge0rG
we could cast a CFE just now
jonas’
Ge0rG, I’m not sure how those work across council boundaries
ignore everything I've said, it was just a sophisticated byrules troll attempt.
Ge0rG
*bylaws
jonas’
Ge0rG, ok, thanks for doing that while we’re already 4 minutes over.
Ge0rG
jonas’: I'm sorry.
dwd
Ge0rG, 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.
dwd
Ge0rG, Originally, I think neither Last Calls nor ProtoXEP Adoption/Publication were a Council thing, just Draft/Final advancements.
jonas’
8) Ite Meeting Est.
dwd
jonas’, Very much +1, and thanks for your excellent and concientious chairing.
Ge0rG
jonas’: 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
Zash
Thanks 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.
dwd
Also, 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.