I appreciate the idea, that it should advance to Draft. I’ve implemented it in Openfire and didn’t saw any major flaws in the spec. However, while I did, I often thought „why is it restricted to chat-type only?“.
I think enhancing it to „normal“ messages is a good idea, e.g. to let carbons-enabled clients receive (direct) MUC invitations or any other non-chat message (I am thinking of structured data that are transported via normal messages, e.g. IOT). With regard to the <private/> element: Yes, there’s XEP-0334. But there’s also XEP-0079, which has already appropriate rules (and is in Draft status): "Drop the message if it would be delivered to a resource other than that specified.“ (for action=„drop“ value=„other“) In fact, the no-store hint from XEP-334 is covered by XEP-0079, too. => Ending up with 3 different ways to suppress delivery to another resource is a pain to implement. Maybe it’s a good idea to drop the <private> element from the spec and instead refer to XEP-0079 (well, unless you want XEP-0280 to be independent of other protocols)? — Christian Am 01.04.2015 um 18:37 schrieb Dave Cridland <[email protected]>: > Folks, > > Matthew Miller and Joe Hildebrand's Carbons XEP has been unchanged for 18 > months, and represents a useful and well-deployed protocol, implemented in > most (if not all) of the mainstream servers. > > Mobile and Desktop clients alike appear to implement this widely. > > I appreciate that the last Summit raised suggestions that it needed to do > more, but it is not clear to me that the "more" cannot be phrased as a new > XEP, and moreover that breaking compatibility given the deployment status is > warranted. > > It is also not clear to me what, exactly, the "more" consists of. I have > heard: > > - Reflection of messages to the source. > - Addition of MAM identifiers. > - Other types beyond 'chat'. > > Therefore I would like to suggest that this specification be advanced to > match its de-facto state of Draft. > > Dave.
