[Standards] Move Carbons to Last Call ("Proposed")

Dave Cridland dave at cridland.net
Wed Aug 12 10:22:09 UTC 2015


On 12 August 2015 at 10:54, Dave Cridland <dave at cridland.net> wrote:

>
>
> On 12 August 2015 at 09:01, Georg Lukas <georg at op-co.de> wrote:
>
>> * Steve Kille <steve.kille at isode.com> [2015-08-12 08:14]:
>> > Given that a MAM based approach may be the  preferred medium term
>> > approach, it seems to me that we should focus efforts to work out what
>> > the medium term approach is going to be.
>>
>> +1
>>
>> > Also, if there is a list of issues that some people view need fixing
>> > with carbons, I think it would be good to have that list explicitly
>>
>> I've tried to compile a more general list of issues some time ago, to
>> be found here:
>>
>> http://mail.jabber.org/pipermail/standards/2015-April/029722.html
>>
>>
> Thanks, this is well worth [re-]reading, as it's a good summary of
> multidevice issues.
>
>
>> The carbon relevant things from that list and from the last 0280 advance
>> discussion are:
>>
>> * Carbons for non-"chat" messages. Jingle signalling of incoming calls
>>   to all interested clients was mentioned IIRC.
>>
>>
> That use-case won't work anyway because Jingle calls are initiated with an
> <iq/>.
>

That sounds more abrupt than I intended.

Matthew Wild suggested just adding 'normal', back in April; that would
cover most use-cases, and 'headline' messages seem to be undesirable at
this stage.


>
>
>> * No filtering mechanism. Carbons are only for type="chat", the client
>>   can't add / remove types according to its needs.
>>
>>
> True; do we need this in order to deploy Carbons, though? I suspect we
> ultimately do to cover non-IM scenarios, but for normal IM we can probably
> handle just type='chat'.
>
>
>> * "False-positive" Carbons of MUC private messages (which are of
>>   type="chat"; see
>>   http://mail.jabber.org/pipermail/standards/2015-May/029819.html and
>>   following messages for a discussion and possible solutions). I think
>>   the solutions need to be codified in the XEP.
>>
>>
> I think there's a number of cases where a user's server needs to know that
> a remote entity is a MUC (and thankfully, with MUC, this is relatively
> simple to achieve). FWIW, the same issue also affects PEP (where PEP
> doesn't use headline, at least), but is rather simpler to solve on a
> stanza-by-stanza basis.
>
> For MUC, I'll summarize our conversation online as servers already have to
> track directed presence to chatrooms; it should be relatively low-cost to
> check responses and mark those as chatrooms as needed, and then perform a
> lookup for Carbons purposes.
>
> I think I can patch Openfire to do this, and I believe you suggested
> Prosody may do something like this already (but I may have misunderstood).
>
>
>> * Carbon notifications (not strictly an XEP issue, rather one of proper
>>   UX) - when should a client ring a bell? Recommendations for this case
>>   might or might not be appropriate in the XEP.
>>
>
> I made the comment on HN that, as a community, we tend not to try to get a
> consistent UX, and that perhaps we should, and explaining when to notify
> (and how) would be a great start - maybe we should kick that off with a
> Wiki page and see where it goes?
>
>
>>
>>
>> Georg
>> --
>> || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
>> || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
>> || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
>> ++ IRCnet OFTC OPN ||_________________________________________________||
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150812/8c2e7b69/attachment.html>


More information about the Standards mailing list