Gajim uses type=chat only (so they will get carbon copied) And Gajim still trys to do resource locking
regards Philipp Am Mo., 19. Nov. 2018 um 17:29 Uhr schrieb Jonas Schäfer < jo...@wielicki.name>: > On Mittwoch, 7. November 2018 10:19:44 CET Georg Lukas wrote: > > So I spent another half hour today debugging why the green checkmark on > > my outgoing messages only appeared on two of my three clients for one > > contact, and only on one of my clients for another contact(*). It turned > > out to be standard compliant behavior. > > > > XEP-0184 indicates (but doesn't mandate) type=normal for Receipts, which > > is followed by most implementations. And thus, Receipts don't fall under > > > > Carbon rules: > > | A <message/> is eligible for carbons delivery if it is of type > > | "normal" and it contains a <body> element. > > > > There is an old PR to improve the Carbons rules > > <https://github.com/xsf/xeps/pull/434> but it doesn't address this > > specific case: > > > > * Georg Lukas <ge...@op-co.de> [2017-06-01 13:55]: > > > Modern clients send bodyless messages with 0085 CSNs and 0184 ACKs to > > > provide additional communication metadata. There is value in > > > carbon-copying both of these message types, but there might be existing > > > use-cases for bodyless messages where carbon-copying would do harm. > > > Because I don't know all the use-cases for bodyless messages, I > struggle > > > to provide a rule for how to handle CSNs and ACKs. > > > > As XEP-0409 (IM Routing-NG) doesn't see wide adoption yet, I'd like to > > move forward with improving 0280 / 0184, by one of the following: > > > > a) make 0280 apply to all 'normal' messages to a bare JID (akin to > > Routing-NG) and state in 0184 that the Receipt should go to bare-JID. > > > > b) explicitly mention in 0184 that for chat content the Receipt should > > also be of type=chat. > > > > c) All of the above. > > > > As 0280 rules are weasel-worded, changing them doesn't require a > > namespace bump. In 0184 there is no mandate of the recipient JID form > > (bare/full) nor the message type, so adding Business Rules for those > > shouldn't require a bump either. > > I like to make '280 work more closely to what we expect IM-NG to do > (option > a), because it will give us more confidence in that IM-NG does the right > thing. > > I also like to have the type of messages related to a conversation not > flip- > flop from one type to another, so type='chat' looks sensible to me (option > b). > So maybe write in '184 to mirror the type which was used for the message > in > reply to which the receipt is? Anything wrong with that (slightly more > generic) approach? > > So all in all, I’m in for (c). > > kind regards, > Jonas_______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
