XMPP Council - 2020-08-05

Ge0rG, you may be intersted in what I wrote about PR#971 on-list just now.

may help guide the discussion about that PR today

jonas’: great, thanks

(Re: [Standards] Council Minutes 2020-07-22, really just now, so it’ll arrive on-list probably five minutes after the meeting started, as the list server hates me :))

jonas’: as you'll also only arrive after the meeting started, I hope this won't be much of an issue ;)

it also contians my vote on the PR as-is, which is a -1, so if any of you have strong opinions on that, it’d be good if we discussed them now...

Ge0rG, I’ll not arrive at all today, sooo...

jonas’: well, that's surely also after the meeting start ;)

indeed

Ge0rG, mail passed through

note that the vote expires this week.

Thanks

I'm working on a new variant of the MUC-PM diff

Tis time.

!

1) Roll Call

Here

hi Zash

jonas’ is excused.

Hi

Hi daniel

Do we have a dwd?

Anyway, it looks like a quorum, so let's proceed.

Does not look like we do

2) Agenda Bashing

jonas’ isn't here, so feel free to bash as much as you want.

I wanted to add a follow-up to https://github.com/xsf/xeps/pull/854 but will postpone for another Council Meeting

jonas’ provided some more context on PR#972, which we could discuss later.

Doesn't look like there are any other additions.

3) Editor’s Update

I put on my jonas’ hat.

- XEP-0048 (Bookmarks) deprecated in favour of XEP-0402 (PEP Native Bookmarks) - Ongoing Calls: - Last Call for XEP-0352 (Client State Indication), ends on 2020-08-18 - Last Call for XEP-0411 (Bookmark Conversion), ends on 2020-08-18

okay, enough of the cosplay.

4) Items for voting

4a) Discuss PR#971: XEP-0004: Clarify field type omission for 'submit' and 'result' form field types

this is a recurring topic that's apparently expiring today.

jonas’ vetoed it on-list today, with some advice on how to improve the wording

I tried to read that on my phone, it sounded sensible.

I was confused before, at how removing words can increase the clarity, but with jonas’’ remark about type="error" being undefined, I think that it actually doesn't improve the situation and should be reworded in a better way

therefore -1

same, -1, "what jonas said" 🙂

daniel: would you like to add to this?

what jonas said. -1

Thanks everyone. Looks like dwd is going to expire from this.

5) Pending Votes

I'd also like to +1 PR#963, so that I'm down to zero pending now.

Zash: did you vote on #972 already? This is just a formalism though.

The other xep4 one? I think I did

it's not in the spreadsheet of doom.

well, it's vetoed multiple times anyway, so it wouldn't make a difference.

6) Date of Next

+1W WFM

+1w wfm

+1w wfm

great! Let's assume +1W then

7) AOB

I got nothing

Anybody? I have https://github.com/xsf/xeps/pull/854 for which I wanted to discuss some wording.

Discuss ahead

I want to add a rationale along the lines of "if you send a PM to somebody who's also your contact, it might be rendered as coming from a separate person"

but I fail to find the right words that are adequate for a formal standards document

Maybe this is more for ModernXMPP?

The discoverabilty of modern xmpp is questionable at best

Also modernxmpp is not a stick you can wield to convince developers to improve their sh... app

I find should not too strong for a retroactive recommendation

SHOULD was discouraged last time I brought this topic up

And then I totally forgot to make a new proposal, which I just recently rediscovered.

Hiding it deep in 0045 isn't optimal for discoverability either 😛

Certainly not

but it's something that I can point developers to

and you can't point them to modernxmpp.org?

MattJ: I can point them to <anyrandomwebsite>, but it's not convincing.

I'm certainly not against having it in the XEP, but I don't see that much difference

well, I *can* try to convince a developer by linking to modernxmpp, just to see if it works.

It's not more discoverable, and it's a protocol document while you're discussing UX considerations

The primary benefit is that it's XSF-official

IMHO

but I am focusing on protocol considerations that arise from UX considerations.

that's a very strong benefit.

If SHOULD is too strong then maybe just an implementation note.. but then modernxmpp seems marginally better IMO

also it adds significantly to the discoverability

Yes in any case there is too much should and should not in that pr

Maybe try modernxmpp first

daniel: it's already there: https://docs.modernxmpp.org/client/groupchat/#private-messages

And come back if that didn't yield the desired results

Could you raise it on the list?

Zash: I think so

Okay, so that's probably the next step to do, then. Thanks everybody.

7a) AAOB?

None here

8) U-0004

Thanks everyone

Thanks

soo...

flow brought up what I assume is a valid point about type="cancel" (instead of type="error", I constantly mistyped that) not having any fields at all

so type="error" being undefined is pretty irrelevant