-
Kev
Should be back in time for 4. Today's getting away from me, so sorry if I'm not.
-
Ge0rG
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
-
Ge0rG
https://github.com/xsf/xeps/pull/752 is actually a submarine to make 0045 better.
-
Ge0rG
I hope that I'll be available in time for the Meeting, because my client scheduled a meeting at "around" 15:30
-
Ge0rG
So please excuse me if I'm late, and feel free to put "my" Agenda items to the end of the list
-
Ge0rG
He's not here yet, so I *am* going to be late.
-
jonas’
:(
-
Ge0rG
Maybe he'll be so late that we can have Meeting before. But somehow I have doubts about that.
-
Ge0rG
If you don't read anything from me, it's either xmpp.org connectivity or I'm AFK-busy.
-
jonas’
good luck
-
Kev
Been for a jog. Dripping. Can't sit like this, might be 2mins late.
-
ralphm
TMI
-
dwd
1) Wrap Call [healthier]
-
dwd
Who's here?
-
jonas’
I am
-
Link Mauve
o/
-
dwd
Kev's in the shower and will be doing the meeting wearing only a towel. Keep a hold of that image.
-
dwd
And Ge0rG has been swallowed by a meeting, I think.
-
jonas’
thank you very much, dwd.
-
dwd
jonas’, I'd say it's my pleasure, but really, it's not.
-
Kev
I'm here.
-
Kev
Don't worry, I don't have a towel.
-
jonas’
that doesn’t improve anything, Ke.✎ -
jonas’
that doesn’t improve anything, Kev. ✏
-
ralphm
I'm here for PR 744
- zinid here for XOR
- dwd fetches the mind-bleach.
-
jonas’
oookay, maybe let’s get on with the agenda.
-
dwd
2) Agenda bashing
-
dwd
Thanks to jonas’ I think we caught everything.
-
dwd
Though Ge0rG said #739 wasn't really Council and had been merged (good).
-
dwd
So moving on:
-
dwd
3) Items for voting:
-
dwd
a) #739: XEP-0410: pre-LC and LC feedback https://github.com/xsf/xeps/pull/739
-
dwd
(Merged as noted)
-
Kev
(To save time, I'm going to be on-list on pretty much everything, sorry)
-
dwd
b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752
-
jonas’
postpone until Ge0rG is maybe there, dwd?
-
dwd
I'm fine with doing things a bit out of order in case Ge0rG manages to make it, yes. So parking this.
-
jonas’
same for c) then
-
dwd
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
-
Link Mauve
So, for this one I have a big set of changes stacked in a branch somewhere.
-
Link Mauve
I’d like to avoid bumping the namespace before merging those.
-
dwd
Link Mauve, Meaning what?
-
Link Mauve
As in, what is the content of these changes?
-
jonas’
Link Mauve, to be honest, I’ve been waiting for your changes for over a year now
-
Link Mauve
Yeah, and I for more than that.
-
dwd
Link Mauve, Meaning you want us to delay this?
-
Link Mauve
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.
-
Link Mauve
dwd, or that yes.
-
jonas’
I don’t have a strong opinion either way.
-
jonas’
the :2 version is "broken" anyways due to what Link Mauve said.✎ -
Link Mauve
:5*
-
dwd
I think this does need a namespace bump. And I'm not happy about delaying it for PRs we don't have, sorry.
-
ralphm
release early, release often?
-
jonas’
the ~:2 (that’s hashes, not ft)~ :5 version is "broken" anyways due to what Link Mauve said. ✏
-
jonas’
dwd, NS-bumping Jingle-FT is meh though
-
dwd
jonas’, What do you mean?
-
jonas’
(NS-bumping *anything* is, but file transfer is particularly frustrating when it fails in non-obvious ways)
-
jonas’
Link Mauve, how realistic is it that you get your changes in order ’til next meeting?
-
Link Mauve
dwd, it’s used in quite a lot of places already, has many implementations, bumping the namespace temporarily sounds indeed meh.
-
Link Mauve
jonas’, I’ll put that as a high priority, so somewhat likely.
-
dwd
You may have a point, actually - the hash -> hash-used change means that an application expecting hash simply sees no hash at all.
-
dwd
Which is allowed by the spec. So I can live without the namespace change on that basis.
-
dwd
Anyway votes:
-
dwd
Kev, assuming on-list.
-
jonas’
I’m +1 on this without namespace change
-
jonas’
(-1 with namespace change)
-
Kev
Yes, on-list please.
-
dwd
I'm +1, I think.
-
dwd
Link Mauve, ?
-
Link Mauve
I’m +1 without namespace change.
-
dwd
OK.
-
dwd
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
-
jonas’
I have no knowledge about RELOAD.
- Ge0rG .o/
-
jonas’
Ge0rG, wb
-
dwd
I'm +1 on this. (I don't know more about RELOAD than the abstract of the RFC says, but it seems believable)
-
jonas’
I’d also like to mention that the XEP contains stuff which definitely does not belong into standards track
-
Link Mauve
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.
-
dwd
Ge0rG, To save you skimming back, we've shuffled the order form the agenda to put the '410 stuff at the end.,
-
jonas’
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.
-
jonas’
I don’t think we can accept this without Board involvement.
-
Link Mauve
But I don’t know much about RELOAD itself.
-
Ge0rG
jonas’: not even as Experimental?
-
jonas’
Ge0rG, not even as experimental
-
dwd
jonas’, It's Experimental, in fairness, but yes, it might need splitting for that basis.
-
zinid
if only I knew in what I should split it
-
jonas’
ralphm, if you happen to be around, a quick suggestion on this?
-
ralphm
Yeah, I'm thinking
-
jonas’
zinid, anything where it says "the XSF has to" needs to be removed, I think
-
zinid
where is the pattern for writing proposals for Board?
-
Ge0rG
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.
-
jonas’
zinid, same format, but different track. it needs to be different documents.
-
ralphm
I think it is kind of weird to have the XSF as the only entity to set up something like this.
-
dwd
zinid, Could you note that it requires a single CA, and then create a distinct XEP you define an XSF-based CA?
-
jonas’
(i.e. you switch "Standards TRack" to "Procedural" or something and describe how the CA should operate)
-
zinid
jonas’, I can of course remove that from the protoxep, easily, but that doesn't solve the problem
-
jonas’
zinid, what dwd says is correct and sensible.
-
Ge0rG
why XSF-based at all? It can be completely external as long as somebody documents it as the trust root for RELOAD-XMPP
-
dwd
zinid, The problem is that it requires a single CA? Or simply signed certificates?
-
zinid
dwd, only signed
-
zinid
by trusted CA
-
ralphm
I.e. the greater XMPP network is not a thing that is, or should be, controlled by the XSF?
-
dwd
zinid, Right. So the practical problem is that nobody signs end-user EE certs for jids?
-
zinid
dwd, yes
-
zinid
also, "trusted" in the sense that the CA should not produce massive amount certificates for attackers
-
zinid
*of certificates
-
zinid
that's the only requirement
-
dwd
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).
-
zinid
okay for me
-
jonas’
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?
-
jonas’
ah, yes that
-
zinid
jonas’, yes, I will
-
jonas’
excellent
-
zinid
so reject it, will be ready to the next meeting
-
jonas’
zinid, fine by me
-
dwd
zinid, Sounds good. In that case I'll -1 this on the expectation that a new submission will pass.
-
jonas’
I’m -1 on the basis that the presented ProtoXEP has Procedural content which needs to be acked by Board.
-
zinid
(probably you will have some time for RELOAD itself, it's very good RFC :) )
-
Link Mauve
Yup, -1 waiting for the next version. :)
-
jonas’
so that’s sorted
-
ralphm
jonas’: I don't agree this is a requirement for rejecting it as experimental.
-
ralphm
I do agree that Board should be involved if we need to setup a CA.
-
dwd
I'd rather the Board chose whetheror not to adopt an XSF-CA document.
-
jonas’
I agree with dwd.
-
dwd
f) #744: XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft https://github.com/xsf/xeps/pull/744
-
ralphm
dwd: I agree with that of course
-
Ge0rG
I'm pretty sure the XSF doesn't want to participate in the CA ~racket~ business.
-
Link Mauve
dwd, +1, but IIRC we already agreed on this change a few weeks ago.
-
ralphm
dwd: I'm not sure if adopting it as experimental means we're going to do it, though.
-
Link Mauve
I’m fine with the wording of it.
-
ralphm
On 744, I understand that Kev had issues with it
-
jonas’
+1 on #744
-
Kev
Let me remind myself.
-
ralphm
Go ahead
-
Ge0rG
+1 on #744
-
Kev
Oh, yes, so this means that someone can automatically take authorship of a spec by proposing it.
-
Ge0rG
Oh. good point.
-
dwd
+0 on this. I think in practise it doesn't matter, but the authorship change is curious.
-
jonas’
oh, I totally missed that part of the sentence O_O
-
Kev
I think that's wrong, and asking for it to be advanced, and changing authorship, should be independent things.
-
Ge0rG
But how else do we want to handle it?
-
jonas’
I hate reading diffs
-
jonas’
I agree with Kev
-
dwd
Ge0rG, Anyone can ask for a Deferred doc to be advanced seems fine.
-
Ge0rG
Do we want to accept Proposal from anybody?
-
Ge0rG
dwd: even without an author?
-
jonas’
Ge0rG, no, we still vote on it
-
jonas’
Ge0rG, yes, if a XEP is ready for Draft, it doesn’t matter if the author is still around
-
dwd
Ge0rG, We do, under this PR. It's just that this PR *also* magics the proposer into a XEP Author.
-
jonas’
afterwards, the Council will be the gatekeeper for changes anyways
-
Ge0rG
I kind-of-like that you can't Propose without commiting to maintain it.
-
jonas’
yeah, I don’t like that authorship change, I think it’s unnecessary
-
Kev
dwd: And the way I read it, also bumping off the old Author.
-
dwd
I am strictly ambivalent to it.
-
Kev
Or, at least, it's not clear that it /doesn't/ mean that.
-
ralphm
Kev: my thinking was that accepting changing ownership would be up to the Editor
-
Ge0rG
-1 as it is +1 with <del>, thereby taking up the role of XEP author</del>
-
dwd
Kev, I don';t think we explicitly have to kill them.
-
Kev
ralphm: I don't think that's what this text says.
-
jonas’
-1 as it is +1 with <del>, thereby taking up the role of XEP author</del>
-
ralphm
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.
-
jonas’
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.
-
dwd
ralphm, That's definitely not what it says.
-
ralphm
If that's not clear (or you think that's actually not different), that was at least my attempt.
-
jonas’
ralphm, oooh, I see the intent now
-
jonas’
maybe ", thereby taking up the role of the XEP author for the purpose of proposing"?
-
Kev
I think just removing ", thereby taking up the role of XEP author" is easiest.
-
dwd
Right, I think the objections are clear.
-
Ge0rG
ralphm: what responsibilities does an author have for the purpose of moving a XEP in the process?
-
ralphm
The problem is that you need an XEP Author to process LC feedback
-
dwd
Note that, as a point of order, we don't get a binding vote on this as Council since the Approving Body is Board.
-
dwd
ralphm, Oh, that is actually a good point.
-
Kev
ralphm: Sure, but Council can look at getting a new Author where needed.
-
jonas’
ralphm, indeed a good point
-
Kev
And Deferred and Abandoned are not equivalent.
-
Ge0rG
Council can also (theoretically) incorporate LC feedback.
-
dwd
Kev, Right, but ralphm's suggestion mean that if you propose a Deferred XEP, you are taking responsibility for it.
-
jonas’
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
-
Ge0rG
But I think it makes sense to put that burden on the Proposer.
-
ralphm
dwd: but only if there's no active Author to collaborate with.
-
jonas’
this is, by default, limited to processing the LC feedback, in my mind.
-
Kev
dwd: Yes - but I think automatically making someone Author is the wrong thing.
-
jonas’
I think thath makes a lot of sense✎ -
jonas’
I think that line of thinking ("Proposer manages LC feedback if author(s) are unavailable") makes a lot of sense✎ ✏ -
jonas’
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 ✏
-
ralphm
And indeed, my intent was that in case of abandonment, somebody proposing to move further would be interested in taking up ownership.
-
dwd
Or simply that the Proposer may be required to take the role of Author during Last Call.
-
ralphm
If proposer is allowed to process LC feedback, why doesn't that make him an author of sorts?
-
Kev
I think we're at the stage of some new text being a good idea, and may as well move on.
-
Ge0rG
dwd: and after Last Call, until all feedback is incorporated
-
Ge0rG
We are also overdue with our time and underdue with our Agenda.
-
dwd
ralphm, Do you have enough feedback from us to clarify the text?
-
peter
This sounds a bit like the Document Shepherd role at the IETF.
-
dwd
Ge0rG, Indeed.
-
dwd
peter, That also.
-
ralphm
dwd: I don't know yet how to process the feedback into new text
-
Kev
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.
-
ralphm
peter: I'm not familiar with that concept
-
jonas’
maybe take the details to the list?
-
dwd
ralphm, OK - but I'm going to move on, because I think we're just getting bogged down in detail.
-
dwd
g) #746: XEP-0060: Add missing @publisher in pubsub schema https://github.com/xsf/xeps/pull/746
-
ralphm
Kev: but if somebody who has abandoned authorship isn't involved, but the document changes anyway, isn't that a problem, too?
-
Link Mauve
g) I’m obviously +1, as I am its author.
-
dwd
I'm +1 on '746, this looks satrightforward.
-
peter
ralphm: https://www.ietf.org/blog/iesg-statement-document-shepherds/
-
jonas’
+1
-
dwd
ralphm, peter - sorry, we've moved on.
-
peter
yep
-
ralphm
dwd: I'd still like to somehow discuss details with council
-
peter
that's why I prefaced with `ralpphm:` :P
-
Ge0rG
+1
- peter goes back to $dayjob
-
ralphm
peter: thanks!
-
dwd
h) #747: XEP-0084: Bump the maximum of @width and @height to 65535 https://github.com/xsf/xeps/pull/747
-
Link Mauve
+1 too, for the same reason.
-
Ge0rG
This is a schema change, technically it requires a namespace bump.
-
jonas’
+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>
-
Link Mauve
Ge0rG, uh, why?
-
dwd
I'm going to have to be on-list for this one. I'm going to have to dig a little.
-
dwd
Mostly on the question of whether Ge0rG is right or not.
-
Link Mauve
Do we have any mention that schemas are normative that way?
-
Ge0rG
Link Mauve, jonas’: if you followed the old schema and implemented it as u8, you'll end up overflowing your data field
-
Kev
Schemas are non-normative in XEPs.
-
dwd
We have usually held within the XSF that schemas are non-normative.
-
jonas’
Ge0rG, if you parse XML strictly by schema without validating it, you’re doing it wrong
-
Link Mauve
Kev, that’s what I remember too.
-
Link Mauve
jonas’, and if you do validate it, as it is you will reject way too many otherwise valid images.
-
Ge0rG
I'm not saying I'm -1, just interpreting the consequences of the change.
-
dwd
Ge0rG, Are you -1 as-is, or not, then?
-
jonas’
(please don’t namespace-bump avatars...)
-
Ge0rG
dwd: +1 because I want to see the world burn
-
dwd
:-)
-
jonas’
🔥
-
dwd
Looping back to the beginning, then.
-
Ge0rG
Also Link Mauve owes me a no-namespace-bump XEP change then :D
-
dwd
b) #752: XEP-0410: add application-specific <not-an-occupant/> condition https://github.com/xsf/xeps/pull/752
-
Ge0rG
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
-
jonas’
+1 on this, or any other of the commonly-encountered RFC 6120 stanza error condition for accompanying not-an-occupant
-
dwd
Is there any reason why this isn't using the `@by` attribute of the error element?
-
Ge0rG
But I didn't want to PR MUC yet.
-
Ge0rG
But really I want this new condition added to 0045.
-
jonas’
dwd, that’s a good addition actually
-
Ge0rG
dwd: you mean the example?
-
Link Mauve
Is there any reason this isn’t part of 0045 instead?
-
Ge0rG
Link Mauve: namespace-bumping-MUC
-
Zash
The entire thing?!
-
jonas’
dwd, but having a distinct muc-specific <not-an-occupant/> in addition is a good thing
-
Ge0rG
Zash: all of it
-
dwd
Ge0rG, So do it a MUC extension that adds it under a different namespace?
-
jonas’
urn:xmpp:muc:1!
-
Ge0rG
dwd: why not have a feature for it on MUC and use the MUC namespace?
-
dwd
Ge0rG, <feature var="urn:xmpp:muc:errors:0"/><!-- sends application-specific errors for MUC -->
-
Ge0rG
Ah, and use that NS.
-
dwd
Ge0rG, Using another XEP's namespace doesn't really sit well with me.
-
Link Mauve
A feature sounds like the way forward.
-
Ge0rG
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
-
dwd
I agree this is useful (though also, @by needs more implementation and use), but it's useful and generic.
-
Link Mauve
+1
-
Ge0rG
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.
-
dwd
So, I think overall this is a -1 from me, sorry. That said, I don't think this needs to mean '410 needs delaying.
-
Ge0rG
What about jonas’ writing a separate Application Specific Errors for MUC XEP?
-
jonas’
why me
-
Ge0rG
jonas’: you brought that mess upon me.
-
jonas’
dammit
-
Ge0rG
I add a @by into 0410, and we publish it.
-
jonas’
I don’t have a weekend this week, so I can’t promise anything
-
Ge0rG
is anybody against having @by in 0410?
-
jonas’
@by is a good thing here
-
dwd
Ge0rG, jonas’ - votes?
-
jonas’
I’m +0
-
Ge0rG
and I'm -1 on #752, despite being the author
-
jonas’
ha
-
Ge0rG
because it needs its own XEP.
-
Link Mauve
^^
-
dwd
Awesome.
-
Ge0rG
Thank you for the discussion, everyone.
-
dwd
Great when people reject their own stuff. :-)
-
dwd
c) Advance XEP-0410 to Draft https://xmpp.org/extensions/xep-0410.html
-
Ge0rG
The main part of the PR was this: > Please have a Council discussion.
-
Ge0rG
+1 to advance 0410 (with a @by added into the error)
-
dwd
Same for me - +1 (with @by)
-
jonas’
+1 to advance 410, with @by added
-
Link Mauve
Same here, +1.
-
Ge0rG
jonas’: shall I make a PR or will you do it with your Editor Hat on?
-
jonas’
Ge0rG, please make a PR
-
dwd
OK. I think we're done with items for voting.
-
jonas’
Ge0rG, I like to have more eyes (even if it’s just four) on it before merging stuff
-
dwd
4) Outstanding Votes
-
dwd
If anyone has anything, please do so on list given the overrun.
-
dwd
5) Next Meeting
-
dwd
Same time next week?
-
jonas’
+1w is ok for me
-
Link Mauve
Same.
-
dwd
6) AOB
-
dwd
(Please no)
-
jonas’
Thanks to Tedd Sterr for doing the minutes all the time and the vote summaries.
-
Ge0rG
+1 to that
-
dwd
Yes, that is amazingly helpful.
-
jonas’
tremendously helpful in both of my roles here
-
Ge0rG
I have a proto-proto-XEP about Simple Encryption for XMPP in the works, but I don't dare Ask Council.
-
dwd
It'd be great if they joined as a member, though that'd involve a real name.
-
Kev
Indeed, yay to minutes etc.
-
dwd
Assuming no other business...
-
dwd
7) Ite, Meeting Est
-
Kev
I have a non-AOB AOB.
-
Kev
Please let's keep to 30mins.
-
dwd
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.
-
jonas’
dwd, we could’ve moved the remaining items to +1w
-
Kev
Quite.
-
jonas’
I don’t want to cut down on in-meeting discussions, I think those are valuable
-
dwd
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.
-
Ge0rG
jonas’: https://github.com/xsf/xeps/pull/754
-
dwd
So, you know, sorry-not-sorry. :-)
-
Kev
I think the likely outcome is the opposite of the desired one if it becomes a habit.
-
Kev
Which is all votes going to onlist.
-
Ge0rG
Kev: all votes or just the ones cast after the first 30 minutes? ;-)
-
Kev
Once upon a time Council meetings were a mess, usually ran over, stuff was invariably onlist.
-
Kev
We eventually sorted that out and got down to sensible 30 minute meetings, with most stuff happening during them.
-
Kev
I'm keen not to go back.
-
Kev
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.
-
Ge0rG
I'm really sorry for being late.
-
Kev
Stuff happens.
-
Kev
I was late too.
-
Kev
I don't think either were what caused the running over.
- ralphm waves
-
pep.
> 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?