XMPP Council - 2020-11-18

Hi

Hey

Ho

(From new house)

jonas’, forgotten about the meeting or nah?

good morning everyone!

Sun went down hours ago, it's night now.

Zash: set your clock to UGT

Do we have a chair?

well, given an excellently prepared agenda, somebody can step in

I have a chair, thankfully. Though no desk, yet.

1) Roll Call

Oh, jonas’ said he might forget.

looks like we are missing jonas’

4/5

everybody else is here, great!

2) Agenda Bashing

are there any things to add?

3) Editor’s Update

Editor's been very busy, we have some things to vote on today.

4) Items for voting

please note that our term is closing, and we need to submit all votes until November 24th.

hahaha

Can we manage that?

yeah, it happened

I was pulling cookies out of the oven just now

here I am

welcome, jonas’!

sorry for the delay, thanks for taking over, Ge0rG

jonas’: do you want to have the chair hat back?

Ge0rG, Maybe it's a hat chair?

Ge0rG, works for me

let’s see what happens to our votes :)

I was just going to ask if everbody silently agrees with submitting all pending votes until November 24th.

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.

Ge0rG, let’s just try and hope I don’t have to read bylaws or something

This one got some discussion on list already, and seems fine, so +1.

did it?

Oh?

+1

Ages ago, IIRC.

ah

I am +1, though I do have remarks I’ll suggest to the authors on-list

Got a reference to this previous discussion?

Or at least, it all looked familiar so I assumed I'd seen it before.

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?

Yes

(so no)

Ge0rG, pretty much that

the idea is to have it separate for use in other specs and not bound to the '234 namespace, IIRC

+1

what would be the way forward when we ever have to bump file-metadata? Will a client send two <file> elements with different namespaces?

Well, given that 0234 is deferred, I think it's well worth a try, so +1

I'm not entirely convinced that another XEP fixes anything

and it's missing clarification on which file elements are mandatory

Experimental doesn't need to be perfect

the idea isn’t to make it reslient against bumps but to better use it outside of jingle, no?

Zash: me neither, but having smaller, reusable elements as their own XEPs looks like a good idea

I suppose

Ge0rG, "All child elements are OPTIONAL"

Ge0rG, Seems clear enough to me. :-)

daniel: yes, but making it reusable will make it prone to bumping.

I agree

moving on

dwd: indeed

I would appreciate a pointer to previous discussion

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.

+1

Zash, Yeah, same. Might have been in the XSF@ chatroom, but I'm sure I've seen something like this from larma before.

So this one is SIMS but based aorund the file metadata, so eradicates SIMS, right?

Eaiser to make a new XEP than to re-author SIMS?

dwd, but based around the file-metadata and *not* around references

wouldn't it be a much more sane approach to just let Marvin co-author SIMS and do all the fixes there?

Ge0rG, For this one in particular, I wondered about that approach myself.

+1. let them A/B fight for the throne of OOB

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]."

has there been a clear consensus on that we want this kind of refactor from SIMS?

because SIMS might still be useful for other things

do we need consensus before accepting this as Experimental?

jonas’: I like the first ones, and the last one is largely political

ah, from that perspective

daniel, Hard to say, see my notes on communications elsewhere.

Ge0rG, the first one and the last one are pretty much tied together

I’m also +1 on this one, same as Zash

So we are going to end up with clients sending three different "file attached" elements for compat reasons?

Ge0rG, Each supporting 19 different FT mechanisms?

dwd: each supporting the same 19 mechanisms as the other one(s).

... but in practice it's all equivalent to <body>https://foo/bar.png</>

Ge0rG, imagine the market for server-side translation modules!!!

Anyway, I'm +1 (in as much as I do not object)

Ge0rG, currently, there is only OOB, right?

so it would be at most two

jonas’: there is SIMS

Ge0rG, I love your optimism that both clients would have any FT mechanisms in common at all.

I'm on-list

Ge0rG, not in any real-world use

and with the body fallback it's probably relatively safe to just drop oob at some point

daniel, I hate body fallback, but there we are... ✏

But we have the body fallback indicator! It's just lacking a fallback...

So we have [+4, on-list]. Next?

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).

+1, I sent feedback to the list

+1

+1

(just now, so it’ll probably arrive tomorrow)

(note that this directly depends on the previous one)

i'm not seeing that feedback

was this in reply to the proposed?

daniel, as I said, I sent it just now, so it’ll take a while

the list server hates me

(peak delay for my mail was something like an hour or so.)

oh fair enough

my feedback was mainly tha the cipher list should go in its own informational XEP like we have for hashes

Well, I think this has issues, but nothing insurmountable, so we'll publish first and fix afterward. I hope.

dwd, is that a disguised +1?

jonas’, agree, especially due to overlap with JET

larma, excellent :)

I like the Security Considerations.

me too :D

i chuckled when I reached that point

+1

Ge0rG, is that a vote?

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.

jonas’: yes

Ge0rG, you do realize that esfs depends strictly on sfs?

and that you are on-list for sfs?

jonas’: damn.

I'm in a deadlock now

think about that ;)

if you can put <sources> inside of <encrypted> inside of <sources>, how many levels of encryption can you stack?

jonas’, As written, it does, but it could be "fixed" to be written around SIMS or something.

Ge0rG, :D

in that case I'm on-list.

dwd, yes

Ge0rG, thanks

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.

it doesn't duplicate SIMS functionality, so I'm less strict on that one.

the hash calculation looks very familiar

someone stole from '390 ;)

on-list; I need to think about the technical implications as well as copyright violation issues.

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.

I may be too old to fully understand what a Sticker is.

yeah this one is more complex, I’m on-list too

dwd: something like a large custom emoji

I mean, I'm *all* about the Giphy. But I'm not sure I understand Stickers. I'm going to on-list this one.

Ge0rG, Yeah, but they come in packs? Like wolves?

Zash, daniel, ?

+1

+1

although I wonder if stickers might be better of with SIMS rather than file sharing

dwd: that would be like different emoji fonts, or somesuch

alright

5) Pending Votes

I'm +1 on #1001

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.

except for those started today, we have pending votes: - everyone except Ge0rG (thanks) on #1001 - dwd on advancement of CS-2020

larma, let’s do that in addition, but being resilient against it comes at little cost

jonas’: CS-2021?

Ge0rG, yes

What's the current voting on CS-2021

?

dwd, everoyne +1, except you

well, we *could* advance CS-2020 to Final, right?

Ge0rG, no

that needs a CFE which is at least 2w long

so "we" cannot

Oh, I'll +0.

thanks!

Maybe we could ask Board to add a special compliance suite thing in XEP-0001

we’re already over our meeting time

also it needs to be 6 month old, no?

please cast votes for #1001 on-list, please

daniel, right, there was something about that ...

6) Date of Next

NOBODY KNOWS!!

7) AOB

anyone got any?

CS-2020 is over a year old now!

Ge0rG, OHH

2020

I always confuse those

technically, it needs to have been in draft for 6m, but yes

jonas’: I noticed ;)

Ge0rG, that’s anyway next council’s problem

> Update to Draft as per council vote on 2019/11/07.

we could cast a CFE just now

Ge0rG, I’m not sure how those work across council boundaries

maybe it will yield useful input for CS-2021

I know that LCs are implicitly restarted

so we don’t win much

Ge0rG, "We" don't start CFEs anyway, that's purely an Editor action.

that, too

ignore everything I've said, it was just a sophisticated byrules troll attempt.

*bylaws

Ge0rG, ok, thanks for doing that while we’re already 4 minutes over.

jonas’: I'm sorry.

Ge0rG, I think that's because whichever Council in Times Gone Past forgot that one.

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.

Ge0rG, Originally, I think neither Last Calls nor ProtoXEP Adoption/Publication were a Council thing, just Draft/Final advancements.

8) Ite Meeting Est.

jonas’, Very much +1, and thanks for your excellent and concientious chairing.

jonas’: thanks very much as well, it was great having you put structure into everything

much of that was thanks to daves spreadsheet of doom

Thanks all. It's been a pleasure serving with you.

oh and also the occasional email from Tedd with summaries of things which were forgotten about

that person is incredibly valuable and we should find a way to send them covid-safe cookies or something.

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.