Ge0rGI 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.
Ge0rGAlso the PR removes the typo.
KevI 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.
Ge0rGI 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
DaveI think a protocol in this space would be useful (even if this changes quite a bit on the way). +1.
Ge0rGIt might be good to put FSN as a payload into CSN, but I have no strong opinion on that.
SamWhitedwhat kev said, except that I'm not sure if I think it should go to experimental or not. on list though.
DaveGe0rG, There was some discussion around that, but I forget what.
Ge0rGDave: it was in the xsf@ MUC
jonaswGe0rG, reasons against doing that: (a) (weak) CSN is final, (b) FSN states should be orthogonal to CSN states (see the business rules)
Dave3c) XEP-0065, XEP-0363: Document exposing the service on the user’s domain #682
https://github.com/xsf/xeps/pull/682
DaveFWIW, 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.
KevI 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>
jonaswDave, council doesn’t need to vote on the second change, because '363 isn’t draft yet
jonaswcouncil only needs to vote on the change to '65, and if you reject that one, I guess Link Mauve will split
SamWhitedoh interesting, I mussed this one. on list, but looking forward to reading it.
Davejonasw, Yes, true, good point.
SamWhitedmissed, even.
DaveSamWhited, Mussed you have mist it?
kasper.dementhas joined
SamWhitedAin't phones great?
Ge0rGonlist.
DaveI think I'll vote on list with this one as well, mostly to take on board Kev's comment and see if I agree.
DaveKev, Is that a -1?
Ge0rGI don't understand the PR against 65 as is, will have to research the context first.
KevI 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.
DaveI have comments on this, but nothing that'd prevent it going onto Experimental.
Ge0rGThis was discussed in October last year already on standards@
guus.der.kinderenhas left
guus.der.kinderenhas joined
jonasw.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…)
SamWhitedMy only imediate concern is the title. Assuming it's changed to something more discoverable before going to experimental I'm +1
Ge0rGjonasw: that's a very interesting one. Do you know of implementations that will change your nickname with MSN?
Ge0rGSamWhited: is that a -1?
KevI think I might quibble about the 'sometimes, without warning, intercept, optionally', but otherwise it seems sane enough. +1
SamWhitedyes, I suppose it's a temporary -1
Kev(Other than the name, but I'm not blocking on that even if it pushes the envelope of silliness too far for me)
Ge0rGI liked the proposal by Zash, "Schrödinger's chat (Or, how I learned to stop worrying and self-ping in MUCs)"
guus.der.kinderenhas left
guus.der.kinderenhas joined
jonaswGe0rG, 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)
danielhas joined
guus.der.kinderenhas left
DaveKev, It's far, far too late for you to pretend to be the sensible one.
Ge0rGjonasw: I'm sure you won't first change the nick and then send a ping to your old nick
guus.der.kinderenhas joined
KevI wouldn't dare. I'm suggesting I'm not sensible, and this is too far even for me.
jonaswGe0rG, why not, I have to wait until I get the server ack for my nickchange before I update internal records…
jonaswGe0rG, so which name would you like to have?
Ge0rGjonasw: want to document that in the Business Considerations?
jonasw"MUC Self-Ping (Schrödinger’s Chat)"?
jonaswah, we have to wait for daniel anyways
Ge0rGjonasw: I like the existing name and I'm sad that some Council members consider it silly.
Dave4) Outstanding Votes
jonaswGe0rG, for the record, I consider it silly (not in a bad way) and undiscoverable (bad) too
DaveGe0rG, I also consider the name silly. I'm just basically fine with that.
KevI would far prefer jonasw's suggestion.
jonaswDave, you have lost any ground to argue with "Bookmarks 2 (This time it’s serious)"
Ge0rGI 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
DaveSo, outstanding - I think given the skip, everything has expired.
KevI don't mind silliness, but I think it's obsfucating here, and that's bad.
Dave5) Next Meeting
DaveNext week, same time, same place?
jonaswDave, you have lost any right to argue since "Bookmarks 2 (This time it’s serious)"
SamWhitedwfm
Kev*obfuscating
Ge0rGUnless Sam and Kev would agree on "Schrödinger's Chat (MUC Self-Ping)", which would be my second best choice.
DaveKev, That's a fair point.
KevWFM
jonaswGe0rG, do it yourself then :)
SamWhitedbookmarks 2 still tells you what it does
Ge0rGSamWhited: having numbers in titles is... not optimal.
SamWhitedplease make 'MUC self ping' the first bit.
jonaswhides behind Entity Capabilities 2.0
Ge0rGwe already have numbered namespaces.
Davecoughs
jonaswlet’s not open this can of worms
DaveAnyone any objections to next week?
jonaswGe0rG, you need to "wfm" next week
Ge0rG+1W WFM
Dave6) AOB
Dave... Assuming none.
SamWhitedNothing here.
Ge0rGokay, so I'll go with "MUC Self-Ping (Schrödinger's Chat)" then.
XMPP Council - 2018-08-01