dwdI've a vague recollection Kev said he'd likely miss this one.
KevMaybe
dwd2) Agenda Bashing
KevI'm here.
dwdI don't think there's anything, but I see Ge0rG wants to fight with me on this. :-)
Ge0rG15:23:18 Ge0rG> dwd: can we add https://github.com/xsf/xeps/pull/854 to tomorrow's agenda? The worst thing that can happen is that it will be re-voted by New Council
dwdOh, fair enough.
Ge0rGIt's a PR adding to MUC-PM:
> Private messages are meant to hide a user's real JID from occupants they are talking to. In <link url='#enter-nonanon'>non-anonymous rooms</link>, a client SHOULD NOT resort to private messages, but instead make use of direct messages to the other occupant's real bare JID. However, if the user knows the other JID for other reasons, e.g. because they are a room admin, private messages SHOULD be used anyway.
Ge0rGrendered version at https://op-co.de/tmp/xep-0045.html#privatemessage
dwdAnyone have anything else?
jonas’+1 from me
jonas’oh, we’re not even voting yet
dwdjonas’, Patience.
jonas’sorry, no, nothing from e
jonas’sorry, no, nothing from me
dwdOK. In that case:
Link MauveNeither from me.
dwd3) Items for a vote.
dwda) XEP-0045: Direct messages SHOULD be used over PMs in non-anonymous rooms #854
dwdhttps://github.com/xsf/xeps/pull/854
jonas’+1 on #854
Link Mauve+1 for that, it’s making the UX easier for users with no downside.
Ge0rG+1
Ge0rGI'm sure some people will consider this a Breaking Change, though.
KevHow does the client know that it's 'other reasons'?
Link MauveKev, it should be aware that the room isn’t non-anonymous by doing disco#info on it.
dwdI think I'm going to be difficult. I understand the rationale (I think), but it remains unclear why this is a good idea, and it's unclear there are any interoperability concerns (which makes me question RFC 2119 language).
Ge0rG> If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service MUST warn the user by including a status code of "100" in the initial presence that the room sends to the new occupant
jonas’!100_received && jid_known => other_reasons
Kevdwd: I think there potentially /are/ interoperability concerns. Those messages might get swallowed because the users aren't in each other's roster and they're blocking messages from such.
Link MauveOr 100 yeah.
Ge0rGdwd: direct messages are typically much more robust than MUC-PMs, delivery-wise
Link MauveKev, or s2s is broken for $reasons.
dwdKev, Oh, that's true. Although if they're blocking the user deliberately - I see arguments pro and con.
Kevdwd: But if they're simply not allowing non-roster messages...
Link MauveKev, shouldn’t they also block MUC PMs in this case?
KevOr non-presence messages, I should say.
dwdMy problem isn't even if this is a good idea, it's that it's marked as a SHOULD without really explaining the considerations involved.
Ge0rGnot allowing non-roster messages is a very bad practice.
jonas’Kev, but isn’t that already an interop problem in and of itself?
KevLink Mauve: I meant non-presence, really, rather than non-roster.
Ge0rGdwd: I started typing it as "should", but then I realized that RFC2119 applies either way and made it explicit
KevWe started doing this in Swift, and actually ended up with messages not getting through that previously did.
Ge0rGdwd: what are the considerations that are missing?
dwdGe0rG, Well, blah. I disagree that it does apply in non-caps, but it's somewhat irrelevant.
Ge0rGdwd: if lowercasing it will please you, I can surely do that ;)
KevSo I think rushing this through at the last moment of this Council is ill-advised. Better to wait for a Council who have full voting periods to consider the implications.
Link MauveKev, on the other hand, I’ve had users report that it was terribly confusing to have two different chats with me (due to clicking on me from the MUC vs. from their roster, but they didn’t know that).
KevBut this breaks things, so if we really want to vote now, I'm -1.
Ge0rGKev: we still have a week left.
Ge0rGWhat Link Mauve said.
jonas’Ge0rG, put it into modernxmpp.org
Link Mauvejonas’, it already is there.
jonas’ah, good.
KevLink Mauve: Indeed. And it's worth discussing that. But normative language here in this way isn't right.
Ge0rGI actually experienced that with a coworker, who was confused about how those two chats are different.
dwdLink Mauve, I've had users say they like the seperation of 1:1 messages and private messages relating to a groupchat.
Link MauveKev, I think this is what this change is about. :)
Ge0rGdwd: did those users grasp the difference?
KevAs I say - we implemented this in Swift because it seemed like the Obviously Right thing to do - and then found it wasn't, necessarily.
dwdLink Mauve, And if a client wishes to combine those into a single UX, what prevents it?
Ge0rGKev: your description rather sounds like it still is the Obviously Right thing to do, but there are technical implementation problems associated
Link Mauvedwd, nothing, they perfectly can avoid this recommendation.
Ge0rGalso something about trust domains and how a MUC can manipulate all and everything coming in through it
dwdLink Mauve, No, I mean, if a client wishes to present PMs in a non-anonymous room in the same message stream as 1:1 messages, surely it can?
dwdFinally, I think there's a security issue wherein a semi-anonymous room could easily confuse a MUC admin's client into revealing the MUC admin's jid.
KevSo I think these are the right questions to be asking, but I don't think this text is the right way to answer them.
KevOr not in isolation, at least.
dwdBut yes, I get, entirely, there are reasons why clients might want to send messages directly, and present PMs as direct messages. I'm not not comfortable putting a blanket requirement into '45 without some explanation of the considerations involved.
dwdSo I'm going to be awkward and -1 this.
Ge0rGdwd, Kev: do you have specific advice on how to move on?
Link Mauvedwd, a client can, but for instance multiple clients may not and it will be even more confusing to see half of the discussion happening on one client, and the full conversation on the other, as if Carbons wasn’t enabled.
KevGe0rG: Off the hoof, I'm not sure I have a complete answer. It at least involves relaxing the language from SHOULD and having a discussion of the implications of both options, I think.
Kev(And Security Considerations, as Dave says)
dwdI have a feeling a lot more text will be involved. But more or less what Kev says.
Ge0rGKev: I'm aiming for consistency here, which is why I wanted the SHOULD
KevIt's possible that appropriate discussion text means that a SHOULD is possible, I'm not sure at this point.
Ge0rGI agree that more text about the trade-offs would be helpful, but historically we aren't good at offering such text, and I'm missing an appropriate XML element to style it as such
dwdGe0rG, If the text said "generally prefer" instead of SHOULD I would be more comfortable.
Ge0rGdwd: noted
dwdGe0rG, But I don't think it's anywhere close to "Always do this and if you don't expect things to break", which is the approximate translation of SHOULD.
KevHaving a SHOULD means that a receiving client should be able to make assumptions, too.
Ge0rGre Security Considerations, the MUC can fake everything and anything, and I hoped that the text is clear about when NOT to do it
Ge0rGdwd: isn't that the approximate translation of MUST, with SHOULD being more like "you should be knowing very well what you do if you violate a SHOULD"
dwdGe0rG, The gap between MUST and SHOULD is very small indeed. :-)
Ge0rGdwd: it SHOULD be larger, though.
dwdAnyway. Moving on?
Ge0rGSorry.
Ge0rGdoes it make sense to bring this up again, next week, with relaxed text and pros and cons added?
Ge0rGalso please provide clearer advice re your expectations of what kind of Security Considerations to add
dwdSure. And if it's well-discussed on the list it stands a good chance.
jonas’maybe, but if you’ve got it prepared for next council it doesn’t harm
KevI think there might be people outside this room who have experience here that is relevant, so I think listing it is important.
Keve.g. it's coincidence that I happen to be on Council (this week) and could say "We tried this and some things break".
Ge0rGdwd: I can't promise a list discussion happening within a week
Link MauveEven if it takes two, it should be fine.
Ge0rGKev: but if I send a mail to standards@, and you reply to it, maybe more people will notice.
dwdGe0rG, Sounds good.
KevI will promise to try to respond :)
Ge0rG> also please provide clearer advice re your expectations of what kind of Security Considerations to add
dwdAnyway, really moving on.
dwd4) Next Meeting
dwdNext week?
KevI *think* I can.
jonas’+1w wfm
dwdI think we'll try then. :-)
Ge0rG+1W WFM
dwd5) Any Other Business?
Ge0rGnone here
KevNewp.
dwdReally?
dwd:-)
dwdIn that case:
dwd6) Ite, Meeting Est
Link Mauve\o_
Ge0rG> also please provide clearer advice re your expectations of what kind of Security Considerations to add
dwdOne more to go, and the hopefully someone else will wat to have a go.
jonas’thanks, dwd
pep.> dwd: if lowercasing it will please you, I can surely do that ;)
We haven't settled on changing 2119 to the update have we. That was never resolved
dwdYes, I think it was resolved, in the sense of "Not without individually checking every document carefully".
Ge0rGpep.: yes, that went down on some TODO list
dwdIt'd probably be useful to do the groundwork allowing us to change them one by one, and adopt the updated version (that I can't recall the number of) for new documents and revisions ona case-by-case.
dwdThat part is just XSLT stuff that's an Editor job. Sorry. But it'll allow us to move more easily on the issue.
flowand we could at least update the boilerplate text regarding 2119 at least for new XEPs