XMPP Council - 2019-02-06

Should be back in time for 4. Today's getting away from me, so sorry if I'm not.

dwd: https://github.com/xsf/xeps/pull/739 was merged, so it's technically a pre-advancement thing and not something to vote on. However, it's an indication of what changed in the XEP since it was last read by Council, so it might be good background info

https://github.com/xsf/xeps/pull/752 is actually a submarine to make 0045 better.

I hope that I'll be available in time for the Meeting, because my client scheduled a meeting at "around" 15:30

So please excuse me if I'm late, and feel free to put "my" Agenda items to the end of the list

He's not here yet, so I *am* going to be late.

:(

Maybe he'll be so late that we can have Meeting before. But somehow I have doubts about that.

If you don't read anything from me, it's either xmpp.org connectivity or I'm AFK-busy.

good luck

Been for a jog. Dripping. Can't sit like this, might be 2mins late.

TMI

1) Wrap Call [healthier]

Who's here?

I am

o/

Kev's in the shower and will be doing the meeting wearing only a towel. Keep a hold of that image.

And Ge0rG has been swallowed by a meeting, I think.

thank you very much, dwd.

jonas’, I'd say it's my pleasure, but really, it's not.

I'm here.

Don't worry, I don't have a towel.

that doesn’t improve anything, Kev. ✏

I'm here for PR 744

oookay, maybe let’s get on with the agenda.

2) Agenda bashing

Thanks to jonas’ I think we caught everything.

Though Ge0rG said #739 wasn't really Council and had been merged (good).

So moving on:

3) Items for voting:

a) #739: XEP-0410: pre-LC and LC feedback https://github.com/xsf/xeps/pull/739

(Merged as noted)

(To save time, I'm going to be on-list on pretty much everything, sorry)

b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752

postpone until Ge0rG is maybe there, dwd?

I'm fine with doing things a bit out of order in case Ge0rG manages to make it, yes. So parking this.

same for c) then

d) #745: XEP-0234: Use <hash-used/> to signify the hash function being used, instead of an (invalid) empty <hash/> https://github.com/xsf/xeps/pull/745

So, for this one I have a big set of changes stacked in a branch somewhere.

I’d like to avoid bumping the namespace before merging those.

Link Mauve, Meaning what?

As in, what is the content of these changes?

Link Mauve, to be honest, I’ve been waiting for your changes for over a year now

Yeah, and I for more than that.

Link Mauve, Meaning you want us to delay this?

The addition of <hash-used/> was already a breaking change without a namespace bump, so we can probably do so once more, and then bump once I’m ready for pushing mine.

dwd, or that yes.

I don’t have a strong opinion either way.

:5*

I think this does need a namespace bump. And I'm not happy about delaying it for PRs we don't have, sorry.

release early, release often?

the ~:2 (that’s hashes, not ft)~ :5 version is "broken" anyways due to what Link Mauve said. ✏

dwd, NS-bumping Jingle-FT is meh though

jonas’, What do you mean?

(NS-bumping *anything* is, but file transfer is particularly frustrating when it fails in non-obvious ways)

Link Mauve, how realistic is it that you get your changes in order ’til next meeting?

dwd, it’s used in quite a lot of places already, has many implementations, bumping the namespace temporarily sounds indeed meh.

jonas’, I’ll put that as a high priority, so somewhat likely.

You may have a point, actually - the hash -> hash-used change means that an application expecting hash simply sees no hash at all.

Which is allowed by the spec. So I can live without the namespace change on that basis.

Anyway votes:

Kev, assuming on-list.

I’m +1 on this without namespace change

(-1 with namespace change)

Yes, on-list please.

I'm +1, I think.

Link Mauve, ?

I’m +1 without namespace change.

OK.

e) Adopt Proposed XMPP Extension: XMPP Over RELOAD (XOR) Abstract: This specification defines an XMPP Usage of REsource LOcation And Discovery (RELOAD). The XMPP usage provides an ability for XMPP clients to discover other peers' location through the peer-to-peer overlay. Once a peer location is determined, the RELOAD AppAttach method is used to establish a direct connection between peers through which XMPP streams are exchanged. https://xmpp.org/extensions/inbox/xor.html

I have no knowledge about RELOAD.

Ge0rG, wb

I'm +1 on this. (I don't know more about RELOAD than the abstract of the RFC says, but it seems believable)

I’d also like to mention that the XEP contains stuff which definitely does not belong into standards track

I skimmed through it, read what zinid said about this protocol a while ago on conversations@ and am +1 on the basis that it looks good and sounds like an interesting proposal.

Ge0rG, To save you skimming back, we've shuffled the order form the agenda to put the '410 stuff at the end.,

specifically, in §8.2: > The root certificate of the overlay MUST be created by the XSF. All intermediate authority's certificates MUST be signed by this root certficate.

I don’t think we can accept this without Board involvement.

But I don’t know much about RELOAD itself.

jonas’: not even as Experimental?

Ge0rG, not even as experimental

jonas’, It's Experimental, in fairness, but yes, it might need splitting for that basis.

if only I knew in what I should split it

ralphm, if you happen to be around, a quick suggestion on this?

Yeah, I'm thinking

zinid, anything where it says "the XSF has to" needs to be removed, I think

where is the pattern for writing proposals for Board?

I think that a wire format for exchanging CSRs and CRTs between XMPP entities, based on the entity JIDs, would be a welcome addition and solve the *technical* issue.

zinid, same format, but different track. it needs to be different documents.

I think it is kind of weird to have the XSF as the only entity to set up something like this.

zinid, Could you note that it requires a single CA, and then create a distinct XEP you define an XSF-based CA?

(i.e. you switch "Standards TRack" to "Procedural" or something and describe how the CA should operate)

jonas’, I can of course remove that from the protoxep, easily, but that doesn't solve the problem

zinid, what dwd says is correct and sensible.

why XSF-based at all? It can be completely external as long as somebody documents it as the trust root for RELOAD-XMPP

zinid, The problem is that it requires a single CA? Or simply signed certificates?

dwd, only signed

by trusted CA

I.e. the greater XMPP network is not a thing that is, or should be, controlled by the XSF?

zinid, Right. So the practical problem is that nobody signs end-user EE certs for jids?

dwd, yes

also, "trusted" in the sense that the CA should not produce massive amount certificates for attackers

*of certificates

that's the only requirement

zinid, OK. On that basis, I think it'd be best to note that requirement, and then remove the XSF-CA part (and if you want, submit that as a different protoXEP for the Board to consider).

okay for me

zinid, I understand that certificates are needed here. Could you replace 8.1 and 8.2 with something more generic, leaving the XSF out of that, and make a follow-up document where you describe what’s necessary, on a procedural level, to make this work securely?

ah, yes that

jonas’, yes, I will

excellent

so reject it, will be ready to the next meeting

zinid, fine by me

zinid, Sounds good. In that case I'll -1 this on the expectation that a new submission will pass.

I’m -1 on the basis that the presented ProtoXEP has Procedural content which needs to be acked by Board.

(probably you will have some time for RELOAD itself, it's very good RFC :) )

Yup, -1 waiting for the next version. :)

so that’s sorted

jonas’: I don't agree this is a requirement for rejecting it as experimental.

I do agree that Board should be involved if we need to setup a CA.

I'd rather the Board chose whetheror not to adopt an XSF-CA document.

I agree with dwd.

f) #744: XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft https://github.com/xsf/xeps/pull/744

dwd: I agree with that of course

I'm pretty sure the XSF doesn't want to participate in the CA ~racket~ business.

dwd, +1, but IIRC we already agreed on this change a few weeks ago.

dwd: I'm not sure if adopting it as experimental means we're going to do it, though.

I’m fine with the wording of it.

On 744, I understand that Kev had issues with it

+1 on #744

Let me remind myself.

Go ahead

+1 on #744

Oh, yes, so this means that someone can automatically take authorship of a spec by proposing it.

Oh. good point.

+0 on this. I think in practise it doesn't matter, but the authorship change is curious.

oh, I totally missed that part of the sentence O_O

I think that's wrong, and asking for it to be advanced, and changing authorship, should be independent things.

But how else do we want to handle it?

I hate reading diffs

I agree with Kev

Ge0rG, Anyone can ask for a Deferred doc to be advanced seems fine.

Do we want to accept Proposal from anybody?

dwd: even without an author?

Ge0rG, no, we still vote on it

Ge0rG, yes, if a XEP is ready for Draft, it doesn’t matter if the author is still around

Ge0rG, We do, under this PR. It's just that this PR *also* magics the proposer into a XEP Author.

afterwards, the Council will be the gatekeeper for changes anyways

I kind-of-like that you can't Propose without commiting to maintain it.

yeah, I don’t like that authorship change, I think it’s unnecessary

dwd: And the way I read it, also bumping off the old Author.

I am strictly ambivalent to it.

Or, at least, it's not clear that it /doesn't/ mean that.

Kev: my thinking was that accepting changing ownership would be up to the Editor

-1 as it is +1 with <del>, thereby taking up the role of XEP author</del>

Kev, I don';t think we explicitly have to kill them.

ralphm: I don't think that's what this text says.

-1 as it is +1 with <del>, thereby taking up the role of XEP author</del>

I am not saying it changes the Author, it takes up the role for the purpose of moving it in the process as further described.

if the Approving Body (AB) decides that a specification should have an active author to advance, they can still require that and make the proposer author, if needed.

ralphm, That's definitely not what it says.

If that's not clear (or you think that's actually not different), that was at least my attempt.

ralphm, oooh, I see the intent now

maybe ", thereby taking up the role of the XEP author for the purpose of proposing"?

I think just removing ", thereby taking up the role of XEP author" is easiest.

Right, I think the objections are clear.

ralphm: what responsibilities does an author have for the purpose of moving a XEP in the process?

The problem is that you need an XEP Author to process LC feedback

Note that, as a point of order, we don't get a binding vote on this as Council since the Approving Body is Board.

ralphm, Oh, that is actually a good point.

ralphm: Sure, but Council can look at getting a new Author where needed.

ralphm, indeed a good point

And Deferred and Abandoned are not equivalent.

Council can also (theoretically) incorporate LC feedback.

Kev, Right, but ralphm's suggestion mean that if you propose a Deferred XEP, you are taking responsibility for it.

ralphm, can you put some wording together which makes this clear? making the proposer responsible for processing (at least by making concrete proposals for) the LC feedback would be good, methinks

But I think it makes sense to put that burden on the Proposer.

dwd: but only if there's no active Author to collaborate with.

this is, by default, limited to processing the LC feedback, in my mind.

dwd: Yes - but I think automatically making someone Author is the wrong thing.

I think that line of thinking ("Proposer manages LC feedback (and only that if no other agreements with the AB exist about that) if author(s) are unavailable") makes a lot of sense ✏

And indeed, my intent was that in case of abandonment, somebody proposing to move further would be interested in taking up ownership.

Or simply that the Proposer may be required to take the role of Author during Last Call.

If proposer is allowed to process LC feedback, why doesn't that make him an author of sorts?

I think we're at the stage of some new text being a good idea, and may as well move on.

dwd: and after Last Call, until all feedback is incorporated

We are also overdue with our time and underdue with our Agenda.

ralphm, Do you have enough feedback from us to clarify the text?

This sounds a bit like the Document Shepherd role at the IETF.

Ge0rG, Indeed.

peter, That also.

dwd: I don't know yet how to process the feedback into new text

ralphm: largely because I forsee that someone is going to go through every deferred XEP, propose it for advancement, and get their name at the top of it automatically because of it.

peter: I'm not familiar with that concept

maybe take the details to the list?

ralphm, OK - but I'm going to move on, because I think we're just getting bogged down in detail.

g) #746: XEP-0060: Add missing @publisher in pubsub schema https://github.com/xsf/xeps/pull/746

Kev: but if somebody who has abandoned authorship isn't involved, but the document changes anyway, isn't that a problem, too?

g) I’m obviously +1, as I am its author.

I'm +1 on '746, this looks satrightforward.

ralphm: https://www.ietf.org/blog/iesg-statement-document-shepherds/

+1

ralphm, peter - sorry, we've moved on.

yep

dwd: I'd still like to somehow discuss details with council

that's why I prefaced with `ralpphm:` :P

+1

peter: thanks!

h) #747: XEP-0084: Bump the maximum of @width and @height to 65535 https://github.com/xsf/xeps/pull/747

+1 too, for the same reason.

This is a schema change, technically it requires a namespace bump.

+1, it doesn’t change any normative part, and is probably an oversight of <revision> <version>0.11</version> <date>2007-07-25</date> <initials>psa</initials> <remark><p>Removed image size requirements.</p></remark> </revision>

Ge0rG, uh, why?

I'm going to have to be on-list for this one. I'm going to have to dig a little.

Mostly on the question of whether Ge0rG is right or not.

Do we have any mention that schemas are normative that way?

Link Mauve, jonas’: if you followed the old schema and implemented it as u8, you'll end up overflowing your data field

Schemas are non-normative in XEPs.

We have usually held within the XSF that schemas are non-normative.

Ge0rG, if you parse XML strictly by schema without validating it, you’re doing it wrong

Kev, that’s what I remember too.

jonas’, and if you do validate it, as it is you will reject way too many otherwise valid images.

I'm not saying I'm -1, just interpreting the consequences of the change.

Ge0rG, Are you -1 as-is, or not, then?

(please don’t namespace-bump avatars...)

dwd: +1 because I want to see the world burn

:-)

🔥

Looping back to the beginning, then.

Also Link Mauve owes me a no-namespace-bump XEP change then :D

b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752

the background of #752 was a list discussion, of which I concluded that it would be great to have an application-specific <not-an-occupant/> or maybe <not-in-room/> condition in MUC

+1 on this, or any other of the commonly-encountered RFC 6120 stanza error condition for accompanying not-an-occupant

Is there any reason why this isn't using the `@by` attribute of the error element?

But I didn't want to PR MUC yet.

But really I want this new condition added to 0045.

dwd, that’s a good addition actually

dwd: you mean the example?

Is there any reason this isn’t part of 0045 instead?

Link Mauve: namespace-bumping-MUC

The entire thing?!

dwd, but having a distinct muc-specific <not-an-occupant/> in addition is a good thing

Zash: all of it

Ge0rG, So do it a MUC extension that adds it under a different namespace?

urn:xmpp:muc:1!

dwd: why not have a feature for it on MUC and use the MUC namespace?

Ge0rG, <feature var="urn:xmpp:muc:errors:0"/><!-- sends application-specific errors for MUC -->

Ah, and use that NS.

Ge0rG, Using another XEP's namespace doesn't really sit well with me.

A feature sounds like the way forward.

dwd, Link Mauve: the specific reason for having this in 0410 was because I wanted to have this discussion, but didn't want to further delay 0410

I agree this is useful (though also, @by needs more implementation and use), but it's useful and generic.

+1

if we add <not-an-occupant xmlns="urn:xmpp:muc:errors:0"/> into 0410, we are now defining MUC errors in a XEP that's actually doing something different.

So, I think overall this is a -1 from me, sorry. That said, I don't think this needs to mean '410 needs delaying.

What about jonas’ writing a separate Application Specific Errors for MUC XEP?

why me

jonas’: you brought that mess upon me.

dammit

I add a @by into 0410, and we publish it.

I don’t have a weekend this week, so I can’t promise anything

is anybody against having @by in 0410?

@by is a good thing here

Ge0rG, jonas’ - votes?

I’m +0

and I'm -1 on #752, despite being the author

ha

because it needs its own XEP.

^^

Awesome.

Thank you for the discussion, everyone.

Great when people reject their own stuff. :-)

c) Advance XEP-0410 to Draft https://xmpp.org/extensions/xep-0410.html

The main part of the PR was this: > Please have a Council discussion.

+1 to advance 0410 (with a @by added into the error)

Same for me - +1 (with @by)

+1 to advance 410, with @by added

Same here, +1.

jonas’: shall I make a PR or will you do it with your Editor Hat on?

Ge0rG, please make a PR

OK. I think we're done with items for voting.

Ge0rG, I like to have more eyes (even if it’s just four) on it before merging stuff

4) Outstanding Votes

If anyone has anything, please do so on list given the overrun.

5) Next Meeting

Same time next week?

+1w is ok for me

Same.

6) AOB

(Please no)

Thanks to Tedd Sterr for doing the minutes all the time and the vote summaries.

+1 to that

Yes, that is amazingly helpful.

tremendously helpful in both of my roles here

I have a proto-proto-XEP about Simple Encryption for XMPP in the works, but I don't dare Ask Council.

It'd be great if they joined as a member, though that'd involve a real name.

Indeed, yay to minutes etc.

Assuming no other business...

7) Ite, Meeting Est

I have a non-AOB AOB.

Please let's keep to 30mins.

Kev, I generally agree. But we had 7 items to vote on, and I infinitely prefer voting in-meeting to voting on-list where possible.

dwd, we could’ve moved the remaining items to +1w

Quite.

I don’t want to cut down on in-meeting discussions, I think those are valuable

Sure, but I think the first meeting after Summit is always going to be busy - lots of energy, plus a missed meeting the week before.

jonas’: https://github.com/xsf/xeps/pull/754

So, you know, sorry-not-sorry. :-)

I think the likely outcome is the opposite of the desired one if it becomes a habit.

Which is all votes going to onlist.

Kev: all votes or just the ones cast after the first 30 minutes? ;-)

Once upon a time Council meetings were a mess, usually ran over, stuff was invariably onlist.

We eventually sorted that out and got down to sensible 30 minute meetings, with most stuff happening during them.

I'm keen not to go back.

And I'd rather punt items to the following week than have people sitting appearing to be in the meetings but actually not because they're doing something else once the meeting overruns.

I'm really sorry for being late.

Stuff happens.

I was late too.

I don't think either were what caused the running over.

> dwd> It'd be great if they joined as a member, though that'd involve a real name. Would it? There's no reaction on the LC for 345. I am the only one to have replied to it?