Should be back in time for 4. Today's getting away from me, so sorry if I'm not.
Guushas joined
Guushas joined
Guushas joined
Guushas joined
Guushas joined
Ge0rGhas joined
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
zinidhas joined
Ge0rG
He's not here yet, so I *am* going to be late.
debaclehas joined
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.
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/
Neustradamushas joined
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>
Tokodomohas joined
dwd
Kev, I don';t think we explicitly have to kill them.
Kev
ralphm: I don't think that's what this text says.
peterhas joined
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.
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?
dwd: I'd still like to somehow discuss details with council
peter
that's why I prefaced with `ralpphm:` :P
Ge0rG
+1
petergoes 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
debaclehas left
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.
ralphmwaves
Guushas joined
zinidhas left
labdsfhas left
pep.has joined
Tokodomohas left
Tokodomohas joined
Tokodomohas left
Tobiashas joined
intosihas left
intosihas joined
labdsfhas joined
debaclehas joined
Tobiashas left
Guushas left
ivucicahas left
ivucicahas joined
Zashhas left
grumpyhas joined
Guushas joined
debaclehas left
labdsfhas left
labdsfhas joined
dwdhas left
labdsfhas left
labdsfhas joined
Tokodomohas joined
Link Mauvehas joined
Tokodomohas left
Link Mauvehas joined
Zashhas left
labdsfhas left
labdsfhas joined
peterhas left
lnjhas left
lnjhas left
lnjhas joined
lnjhas left
lnjhas left
lnjhas joined
Guushas left
Guushas joined
Guushas left
Tokodomohas joined
Guushas joined
lnjhas left
lnjhas left
lnjhas joined
Link Mauvehas left
peterhas joined
Guushas left
Tokodomohas left
Guushas joined
Remkohas left
Link Mauvehas joined
grumpyhas left
Guushas left
Guushas joined
grumpyhas joined
Guushas left
olihas joined
Tobiashas joined
Zashhas left
Guushas joined
Link Mauvehas joined
pep.has joined
Link Mauvehas joined
SouLhas left
zinidhas left
peterhas left
olihas joined
lnjhas left
lnjhas left
lnjhas left
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?