XMPP Council - 2018-08-01

cold water even

1) Roll Call

here

Here, obviously.

(by phone, replies may be slow)

No Daniel, but I'm assuming he's still on his travels?

So Dave arranged the Chair.

I think he promised to come back this week?

I wasn't sure. I know we were missing multiple last week hence the skip, but I thought Daniel was away longer.

pinged daniel in private.

Anyway, four of us will do.

2) Agenda Bashing

Any updates to the Agenda?

I liked it, so I propose to change the subject of #2

(I'm hoping not, but in case I've missed something...)

3) Items for voting:

3a) XEP-0050: Remove the status attribute from the request #681 https://github.com/xsf/xeps/pull/681

This seems like a pretty straightforward case to me - optional inclusion of an attribute that the receiver is mandated to ignore. So I'm +1.

I think this is a typo actually.

+1, this seems very sensible.

What is? The statement being removed?

I think it's a typo of 'status' instead of 'action', and the better fix might be to fix the typo.

From my reading -50 earlier.

Why have an optional attribute at all? Feels rather pointless.

SamWhited, If it's restating a default, that makes more sense.

+1

Kev, that makes sense

then it should be required still so you can rely on it

having to check 'is it the default value or does it not exist' is just cumbersome for no reason in my mind

SamWhited: Possibly, but that's orthogonal to this patch, I think.

SamWhited, If it's not the default value it could be cancelling, though.

I think Kev is right and it was meant to say "action"

But in any case, Kev, can you make a comment to that effect and I'll look at it in more detail - could be an example that clarifies too.

oh yah, I guess so

3b) Proposed XMPP Extension: File Sharing Notifications https://xmpp.org/extensions/inbox/fsn.html

A comment where? Not on the PR, presumably.

(in reply to the minutes probably)

I think Kev is right regarding the typo, but the typo is in the XEP and not in the PR, and the PR is self-consistent.

Also the PR removes the typo.

I don't like several things about FSN, and think we could almost certainly do it a better way, but I don't see anything preventing Experimental, so +1.

I don't like that there is no enumeration of all possible FSN states, and that there is no example of how to stop FSN. But I like the idea, so +1

I think a protocol in this space would be useful (even if this changes quite a bit on the way). +1.

It might be good to put FSN as a payload into CSN, but I have no strong opinion on that.

what kev said, except that I'm not sure if I think it should go to experimental or not. on list though.

Ge0rG, There was some discussion around that, but I forget what.

Dave: it was in the xsf@ MUC

Ge0rG, reasons against doing that: (a) (weak) CSN is final, (b) FSN states should be orthogonal to CSN states (see the business rules)

3c) XEP-0065, XEP-0363: Document exposing the service on the user’s domain #682 https://github.com/xsf/xeps/pull/682

FWIW, I understand why this is a single PR against multiple XEPs, but I'm not sure it's a good idea. XEP-0001 suggests these two changes should be voted upon distinctly by Council.

I think the intention here is right, but I'm afraid I think the way this is formulated is adding confusion rather than resolving it. I think you lead with "Here's how you see a domain has the feature" and then go with "And here's how you check the subdomains if it doesn't>

Dave, council doesn’t need to vote on the second change, because '363 isn’t draft yet

council only needs to vote on the change to '65, and if you reject that one, I guess Link Mauve will split

oh interesting, I mussed this one. on list, but looking forward to reading it.

jonasw, Yes, true, good point.

missed, even.

SamWhited, Mussed you have mist it?

Ain't phones great?

onlist.

I think I'll vote on list with this one as well, mostly to take on board Kev's comment and see if I agree.

Kev, Is that a -1?

I don't understand the PR against 65 as is, will have to research the context first.

I feel that -1 sends not quite the right message, because I agree with the change in principle, just not the execution, but yes. I'd at least like to be persuaded I'm wrong before it's merged.

Kev, An easy-rectifiable -1, then.

Yes.

3d) Proposed XMPP Extension: Schrödinger's Chat https://xmpp.org/extensions/inbox/muc-selfping.html

+1 obviously. AMA

I have comments on this, but nothing that'd prevent it going onto Experimental.

This was discussed in October last year already on standards@

.oO(what if another MSN-client changes your nickname while your ping is in-flight and you get an item-not-found or whatever back because your ping target vanished…)

My only imediate concern is the title. Assuming it's changed to something more discoverable before going to experimental I'm +1

jonasw: that's a very interesting one. Do you know of implementations that will change your nickname with MSN?

SamWhited: is that a -1?

I think I might quibble about the 'sometimes, without warning, intercept, optionally', but otherwise it seems sane enough. +1

yes, I suppose it's a temporary -1

(Other than the name, but I'm not blocking on that even if it pushes the envelope of silliness too far for me)

I liked the proposal by Zash, "Schrödinger's chat (Or, how I learned to stop worrying and self-ping in MUCs)"

Ge0rG, same can happen if you’re changing your nickname yourself (although this can probably be solved by deferring the ping for some time after requesting a nick change)

Kev, It's far, far too late for you to pretend to be the sensible one.

jonasw: I'm sure you won't first change the nick and then send a ping to your old nick

I wouldn't dare. I'm suggesting I'm not sensible, and this is too far even for me.

Ge0rG, why not, I have to wait until I get the server ack for my nickchange before I update internal records…

Ge0rG, so which name would you like to have?

jonasw: want to document that in the Business Considerations?

"MUC Self-Ping (Schrödinger’s Chat)"?

ah, we have to wait for daniel anyways

jonasw: I like the existing name and I'm sad that some Council members consider it silly.

4) Outstanding Votes

Ge0rG, for the record, I consider it silly (not in a bad way) and undiscoverable (bad) too

Ge0rG, I also consider the name silly. I'm just basically fine with that.

I would far prefer jonasw's suggestion.

I don't think having "Schrödinger's Chat" in parens will have the desired effect, so my only sane option is "MUC Self-Ping". But I demand a record of the rename in the changelog

So, outstanding - I think given the skip, everything has expired.

I don't mind silliness, but I think it's obsfucating here, and that's bad.

5) Next Meeting

Next week, same time, same place?

Dave, you have lost any right to argue since "Bookmarks 2 (This time it’s serious)" ✏

wfm

*obfuscating

Unless Sam and Kev would agree on "Schrödinger's Chat (MUC Self-Ping)", which would be my second best choice.

Kev, That's a fair point.

WFM

Ge0rG, do it yourself then :)

bookmarks 2 still tells you what it does

SamWhited: having numbers in titles is... not optimal.

please make 'MUC self ping' the first bit.

we already have numbered namespaces.

let’s not open this can of worms

Anyone any objections to next week?

Ge0rG, you need to "wfm" next week

+1W WFM

6) AOB

... Assuming none.

Nothing here.

okay, so I'll go with "MUC Self-Ping (Schrödinger's Chat)" then.

7) Ite, Meeting Est.

Thanks all.

And use Bookmarks 2 as the precedent.

WFM

Thanks all.

Thanks Dave. Thanks Tedd.

I can live with that.

thanks everyone