[Standards] Advancing XEP-0280 Carbons

Christian Schudt christian.schudt at gmx.de
Wed Apr 1 18:17:21 UTC 2015


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 <dave at cridland.net>:

> 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.




More information about the Standards mailing list