[Standards] LAST CALL: XEP-0280 (Message Carbons)
flo at geekplace.eu
Thu Jun 23 07:49:43 UTC 2016
On 22.06.2016 18:16, Peter Saint-Andre wrote:
> On 6/22/16 10:06 AM, Georg Lukas wrote:
>> * Peter Saint-Andre <stpeter at stpeter.im> [2016-06-22 17:44]:
>>> A <message/> is not eligible for carbons delivery if it is
>>> determined to have been sent by a MUC room or service, even if it
>>> would be otherwise eligible (this also includes private messages
>>> from MUC participants).
>> IMHO, this rule is more relevant than ever. A client that has enabled
>> Carbons has no way to know to which MUCs other clients of the user are
>> joined. Therefore, it has no sane way to participate in a MUC, and would
>> misunderstand incoming MUC PMs for regular messages.
>> If a client wants to receive the content of a MUC, it should explicitly
>> join this MUC.
> Aha, OK. I think it would be helpful to add a note about that in
> XEP-0280 so client developers know what to do.
>>> 3. §10.3 uses the term "forked messages", but that term is not used
>>> elsewhere. I suggest that we call these carbon copies or (as in §11)
>>> forwarded copies.
>> +1 for either carbon or forwarded. I think the notion "forked message"
>> should rather be used for multiple deliveries by means of RFC 6121
>> §8.5.3, or in the above MUC MSN PM scenario.
>> I'm not sure if LC is the correct
>> place to address this issue, and whether it would be a good idea to kill
>> <private/>. The respective discussion is here:
>> And it looks like people all have their strong opinions on how to
>> proceed, maybe this needs to be voted upon?
> IMHO it would be good to settle this before moving XEP-0280 to Draft.
> Specifically, if we don't have consensus on this point then I suggest
> that we remove <private/> for now, move the rest of Carbons to Draft
> (since there is no controversy there), and figure out what to do about
> <private/> vs. <no-copy/>.
A generic element like <no-copy/> makes much more sense then <private/>.
E.g. the new OpenPGP XEPs use the <store/> hint of xep334. Your approach
of removing the controversial parts seems like a handy compromise, but
Matthew's suggestion at
appears to be something we all could agree on, no?
I also still think that we should clarify somewhere if the carbons state
is kept after a stream resumption or not . Not sure if the right
place for this would be xep280 or xep198.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards