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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
