[Standards] LAST CALL: XEP-0280 (Message Carbons)

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

+1

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

+1

>> 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:
>>
>> http://mail.jabber.org/pipermail/standards/2015-September/030288.html
>>
>> 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.

Exactly.

> 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

http://mail.jabber.org/pipermail/standards/2015-September/030341.html

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 [1]. Not sure if the right
place for this would be xep280 or xep198.

- Florian


1: http://mail.jabber.org/pipermail/standards/2015-August/030221.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160623/ef295b34/attachment.sig>


More information about the Standards mailing list