KevShould be back in time for 4. Today's getting away from me, so sorry if I'm not.
Ge0rGdwd: 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
Ge0rGhttps://github.com/xsf/xeps/pull/752 is actually a submarine to make 0045 better.
Ge0rGI hope that I'll be available in time for the Meeting, because my client scheduled a meeting at "around" 15:30
Ge0rGSo please excuse me if I'm late, and feel free to put "my" Agenda items to the end of the list
Ge0rGHe's not here yet, so I *am* going to be late.
Ge0rGMaybe he'll be so late that we can have Meeting before. But somehow I have doubts about that.
Ge0rGIf you don't read anything from me, it's either xmpp.org connectivity or I'm AFK-busy.
KevBeen for a jog. Dripping. Can't sit like this, might be 2mins late.
dwd1) Wrap Call [healthier]
dwdKev's in the shower and will be doing the meeting wearing only a towel. Keep a hold of that image.
dwdAnd Ge0rG has been swallowed by a meeting, I think.
jonas’thank you very much, dwd.
dwdjonas’, I'd say it's my pleasure, but really, it's not.
KevDon't worry, I don't have a towel.
jonas’that doesn’t improve anything, Ke.
jonas’that doesn’t improve anything, Kev.
ralphmI'm here for PR 744
zinidhere for XOR
dwdfetches the mind-bleach.
jonas’oookay, maybe let’s get on with the agenda.
dwd2) Agenda bashing
dwdThanks to jonas’ I think we caught everything.
dwdThough Ge0rG said #739 wasn't really Council and had been merged (good).
dwdSo moving on:
dwd3) Items for voting:
dwda) #739: XEP-0410: pre-LC and LC feedback
dwd(Merged as noted)
Kev(To save time, I'm going to be on-list on pretty much everything, sorry)
dwdI'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
dwdd) #745: XEP-0234: Use <hash-used/> to signify the hash function being used, instead of an (invalid) empty <hash/>
Link MauveSo, for this one I have a big set of changes stacked in a branch somewhere.
Link MauveI’d like to avoid bumping the namespace before merging those.
dwdLink Mauve, Meaning what?
Link MauveAs 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 MauveYeah, and I for more than that.
dwdLink Mauve, Meaning you want us to delay this?
Link MauveThe 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 Mauvedwd, 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.
dwdI think this does need a namespace bump. And I'm not happy about delaying it for PRs we don't have, sorry.
ralphmrelease 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
dwdjonas’, 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 Mauvedwd, it’s used in quite a lot of places already, has many implementations, bumping the namespace temporarily sounds indeed meh.
Link Mauvejonas’, I’ll put that as a high priority, so somewhat likely.
dwdYou may have a point, actually - the hash -> hash-used change means that an application expecting hash simply sees no hash at all.
dwdWhich is allowed by the spec. So I can live without the namespace change on that basis.
dwdKev, assuming on-list.
jonas’I’m +1 on this without namespace change
jonas’(-1 with namespace change)
KevYes, on-list please.
dwdI'm +1, I think.
dwdLink Mauve, ?
Link MauveI’m +1 without namespace change.
dwde) Adopt Proposed XMPP Extension: XMPP Over RELOAD (XOR)
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.
jonas’I have no knowledge about RELOAD.
dwdI'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 MauveI 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.
dwdGe0rG, 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 MauveBut I don’t know much about RELOAD itself.
Ge0rGjonas’: not even as Experimental?
jonas’Ge0rG, not even as experimental
dwdjonas’, It's Experimental, in fairness, but yes, it might need splitting for that basis.
zinidif only I knew in what I should split it
jonas’ralphm, if you happen to be around, a quick suggestion on this?
ralphmYeah, I'm thinking
jonas’zinid, anything where it says "the XSF has to" needs to be removed, I think
zinidwhere is the pattern for writing proposals for Board?
Ge0rGI 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.
ralphmI think it is kind of weird to have the XSF as the only entity to set up something like this.
dwdzinid, 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)
zinidjonas’, 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.
Ge0rGwhy XSF-based at all? It can be completely external as long as somebody documents it as the trust root for RELOAD-XMPP
dwdzinid, The problem is that it requires a single CA? Or simply signed certificates?
ziniddwd, only signed
zinidby trusted CA
ralphmI.e. the greater XMPP network is not a thing that is, or should be, controlled by the XSF?
dwdzinid, Right. So the practical problem is that nobody signs end-user EE certs for jids?
zinidalso, "trusted" in the sense that the CA should not produce massive amount certificates for attackers
zinidthat's the only requirement
dwdzinid, 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).
zinidokay 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
zinidjonas’, yes, I will
zinidso reject it, will be ready to the next meeting
jonas’zinid, fine by me
dwdzinid, 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 MauveYup, -1 waiting for the next version. :)
jonas’so that’s sorted
ralphmjonas’: I don't agree this is a requirement for rejecting it as experimental.
ralphmI do agree that Board should be involved if we need to setup a CA.
dwdI'd rather the Board chose whetheror not to adopt an XSF-CA document.
jonas’I agree with dwd.
dwdf) #744: XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft
ralphmdwd: I agree with that of course
Ge0rGI'm pretty sure the XSF doesn't want to participate in the CA ~racket~ business.
Link Mauvedwd, +1, but IIRC we already agreed on this change a few weeks ago.
ralphmdwd: I'm not sure if adopting it as experimental means we're going to do it, though.
Link MauveI’m fine with the wording of it.
ralphmOn 744, I understand that Kev had issues with it
jonas’+1 on #744
KevLet me remind myself.
Ge0rG+1 on #744
KevOh, yes, so this means that someone can automatically take authorship of a spec by proposing it.
Ge0rGOh. 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
KevI think that's wrong, and asking for it to be advanced, and changing authorship, should be independent things.
Ge0rGBut how else do we want to handle it?
jonas’I hate reading diffs
jonas’I agree with Kev
dwdGe0rG, Anyone can ask for a Deferred doc to be advanced seems fine.
Ge0rGDo we want to accept Proposal from anybody?
Ge0rGdwd: 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
dwdGe0rG, 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
Ge0rGI 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
Kevdwd: And the way I read it, also bumping off the old Author.
dwdI am strictly ambivalent to it.
KevOr, at least, it's not clear that it /doesn't/ mean that.
ralphmKev: 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>
dwdKev, I don';t think we explicitly have to kill them.
Kevralphm: 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>
ralphmI 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.
dwdralphm, That's definitely not what it says.
ralphmIf 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"?
KevI think just removing ", thereby taking up the role of XEP author" is easiest.
dwdRight, I think the objections are clear.
Ge0rGralphm: what responsibilities does an author have for the purpose of moving a XEP in the process?
ralphmThe problem is that you need an XEP Author to process LC feedback
dwdNote that, as a point of order, we don't get a binding vote on this as Council since the Approving Body is Board.
dwdralphm, Oh, that is actually a good point.
Kevralphm: Sure, but Council can look at getting a new Author where needed.
jonas’ralphm, indeed a good point
KevAnd Deferred and Abandoned are not equivalent.
Ge0rGCouncil can also (theoretically) incorporate LC feedback.
dwdKev, 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
Ge0rGBut I think it makes sense to put that burden on the Proposer.
ralphmdwd: 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.
Kevdwd: 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
ralphmAnd indeed, my intent was that in case of abandonment, somebody proposing to move further would be interested in taking up ownership.
dwdOr simply that the Proposer may be required to take the role of Author during Last Call.
ralphmIf proposer is allowed to process LC feedback, why doesn't that make him an author of sorts?
KevI think we're at the stage of some new text being a good idea, and may as well move on.
Ge0rGdwd: and after Last Call, until all feedback is incorporated
Ge0rGWe are also overdue with our time and underdue with our Agenda.
dwdralphm, Do you have enough feedback from us to clarify the text?
peterThis sounds a bit like the Document Shepherd role at the IETF.
dwdpeter, That also.
ralphmdwd: I don't know yet how to process the feedback into new text
Kevralphm: 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.
ralphmpeter: I'm not familiar with that concept
jonas’maybe take the details to the list?
dwdralphm, OK - but I'm going to move on, because I think we're just getting bogged down in detail.
dwdg) #746: XEP-0060: Add missing @publisher in pubsub schema
ralphmKev: but if somebody who has abandoned authorship isn't involved, but the document changes anyway, isn't that a problem, too?
Link Mauveg) I’m obviously +1, as I am its author.
ralphmdwd: I'd still like to somehow discuss details with council
peterthat's why I prefaced with `ralpphm:` :P
petergoes back to $dayjob
dwdh) #747: XEP-0084: Bump the maximum of @width and @height to 65535
Link Mauve+1 too, for the same reason.
Ge0rGThis 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
<remark><p>Removed image size requirements.</p></remark>
Link MauveGe0rG, uh, why?
dwdI'm going to have to be on-list for this one. I'm going to have to dig a little.
dwdMostly on the question of whether Ge0rG is right or not.
Link MauveDo we have any mention that schemas are normative that way?
Ge0rGLink Mauve, jonas’: if you followed the old schema and implemented it as u8, you'll end up overflowing your data field
KevSchemas are non-normative in XEPs.
dwdWe 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 MauveKev, that’s what I remember too.
Link Mauvejonas’, and if you do validate it, as it is you will reject way too many otherwise valid images.
Ge0rGI'm not saying I'm -1, just interpreting the consequences of the change.
dwdGe0rG, Are you -1 as-is, or not, then?
jonas’(please don’t namespace-bump avatars...)
Ge0rGdwd: +1 because I want to see the world burn
dwdLooping back to the beginning, then.
Ge0rGAlso Link Mauve owes me a no-namespace-bump XEP change then :D