XMPP Council - 2021-01-13

theadmiralty, explain your amusement please

jonas’: the portion regarding zash and ipv6

Looks like I'll be late to the party. I'm having fun yelling at incompetent consultants.

> theadmiralty, explain your amusement please The Tedd style of writing boring facts down in an amusing way probably. 😃

Strategic brewing of coffee successful

Coffee overflow.

> Coffee overflow. Terrible. Get bigger coffee cups! ✏

mdosch: I have a 370ml cup already. The overflow happens in my body

Wow, the call ended just on time for the Council, only 27 minutes overtime.

3 minutes of rest!

similar here

also fun: I still need to write emails

I’m going to be distracted, I’m sorry for that

1) Roll Call

Hi

Hello

yay

Hiya

*ahem*

2) Agenda Bashing

any notes?

C sharp.

(this time with correct date!)

What Tedd pointed out earlier

yep, that

thanks

3) Editor’s Update

- Proposed XMPP Extensions: - DOAP usage in XMPP - OMEMO Media Sharing

4) Items for Voting

I started reading the agenda multiple times, but then got distracted over and over again. Sorry.

4a) Proposed XMPP Extension: DOAP usage in XMPP URL: https://xmpp.org/extensions/inbox/doap-usage-in-xmpp.html Abstract: This specification defines how XMPP projects can provide a machine-readable description of their abilities, and how external entities can interact with it.

I am on list, I did not have a minute of non-work time today yet.

Also on-list

+1

are XEPs the right format to specify something that isn’t an extension?

i mean as a spec the document looks fine

daniel, if it defines how XEPs are to be used or referenced to, I think it’s borderline OK

I hadn't seen the submission. Not sure what track this should be. Happy for it to be a XEP, though - perhaps even Procedural?

Informational, not Standards Track, so I think that's fine

dwd, hmm

I’d suggest informational, it’s not a procedure of the XSF or the Council

or is it, if it touches on management of the website?

I'll got for "on-list" as far as a vote is concerned, but I'm heavily leaning toward +1.

+1

Zash, it doesn’t seem to

Zash, I can see arguments for it being STandards Track, as it's trying to define an interoperable wire format for the community.

depends on which wires, I suppose

but true, the typical Last Call / CFE questions would apply to this one

I suggest we bring that question up to the list

I don't have a strong opinion either way

However, with Standards Track, I'll start pondering about namespace versioning the schema.org schema

(sent the ProtoXEP mail just now, forgot that yesterday, so we have a thread to go on)

moving on

4b) Proposed XMPP Extension: OMEMO Media Sharing URL: https://xmpp.org/extensions/inbox/omemo-media-sharing.html Abstract: An informal way of sharing media files despite limitations in the OMEMO encryption Note: We had this one as Standards Track in the past, but it was resubmitted as Historical.

the first fun question is whether Link Mauve got the IPR agreement from daniel to resubmit his work under a different Track

What happened to the "this one as Standards Track in the past" document?

rejected by council

because evilness

didnt council back then decided that moving it to a different track isn’t enough?

because i vaguely remember offering to do this but it was rejected

2018-05-30

so if we now +1 we overrule previous council decisions

so technically it was submitted as Standards Track, but never landed there?

no, not 2018-05-30

still finding it

on-list, I'll wait for the XEP-0001 taskforce to decide what our legitimate options are.

same, on-list

2018-06-06

can we at least fix the example before publishing it

on list too

https://mail.jabber.org/pipermail/standards/2018-June/035135.html

finally, there you go. I think the gist is historical would be ok ("although not fond of")

any other votes?

So, Informational was rejected but Historical was not.

I am +1

(with any editorial fixes needed)

better to have it documented than not

dwd, do you want to vote?

I think we need to figure out what to do with the URL scheme. It feels like treading on another SDO's territory.

I think the document is rather clear on that

I don't think there are any ambitions do establish that as a generic URL scheme

Right, but technically it would still need registering nonetheless.

OK, I'm on-list.

dwd: I don't think so.

But I'll muse over this on-list instead of just being silent.

jonas’, what would be the best way to fix the examples?

daniel, send me a diff?

either as PR or mail or whatever works for you

daniel, FWIW, I'm perfectly happy to accept with broken examples and fix them.

dwd: IMO, defining a non-standard URL scheme for the use in a specific, strictly defined context is fair game

I can incorporate (rebase/am) it to the released or the protoxep version, whichever works for me

oh right. i can just PR the inbox

We should all read https://tools.ietf.org/html/rfc7595

i was briefly confused.never mind

I am running out of time a little today, so I’ll push forward, sorry for that

4c) Cancelled, thanks theTedd

5) Pending Votes

a bunch of votes are pending on the MUC Mention Notifications ProtoXEP

does anyone want to cast votes here?

(it expires next week)

Sorry.

I think I plus-oned that already.

dwd, that is correct :)

I assume noone wants to cast further votes here, moving on

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

+1wwfm

+1w wfm

excellent

7) AOB

any?

daniel, did you formally give permission to resubmit that OMEMO one?

no

daniel, OK, so unless and until you do that, we can't accept it anyway.

how would i do that?

dwd: isn't IPR permission explicitly required when submitting a ProtoXEP?

so even when the ProtoXEP is rejected, the permission remains?

Ge0rG, Yes, but we'll have asked Link Mauve, as I understand things, rather than daniel.

no, it is "upon acceptance", Ge0rG

Ge0rG, Ah, no. If we don't accept it, I assume that permission expires.

Ah, thanks

Ge0rG, Or at least, I don't think it's safe to assume otherwise.

dwd, formally, Link Mauve is liable here because they accepted the XSF IPR when reproposing ;)

jonas’, True.

though we are now acutely aware that there is a problem

daniel, I think it’d be good and sufficient if you stated on-list that you are OK with resubmission in the protoxep thread.

daniel, To give permission, I assume just a message here or an email would be enough.

yes i'm fine with resubmitting it

daniel, Replying to the submission email would probably be most sensible. Assuming of course that you want to give permission.

daniel, thank you very much :)

Note for Tedd: Please make sure that's minuted.

any other AOB?

none here

I got nothing

thanks

7) Ite Meeting Est

Thanks jonas’. Thanks everyone

gotta run, see you later

Thanks all

daniel, do you accept me resubmitting your ProtoXEP under a different track?

i do. and that's already on the record

Oh sorry.

Perfect then. :)