16:03:50Ge0rGIt'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.

16:04:24Ge0rGrendered version at https://op-co.de/tmp/xep-0045.html#privatemessage

16:06:03Link MauveKev, it should be aware that the room isn’t non-anonymous by doing disco#info on it.

16:06:13dwdI 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).

16:06:16Ge0rG> 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

16:09:34dwdGe0rG, Well, blah. I disagree that it does apply in non-caps, but it's somewhat irrelevant.

16:09:58Ge0rGdwd: if lowercasing it will please you, I can surely do that ;)

16:09:59KevSo 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.

16:10:10Link 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).

16:10:12KevBut this breaks things, so if we really want to vote now, I'm -1.

16:14:52dwdBut 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.

16:16:04Link 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.

16:16:10KevGe0rG: 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.

16:30:34dwdIt'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.

16:31:18dwdThat part is just XSLT stuff that's an Editor job. Sorry. But it'll allow us to move more easily on the issue.

16:31:34flowand we could at least update the boilerplate text regarding 2119 at least for new XEPs