I was just typing a reply, but Florian hit the same points as I was going to, so reply inline...
On 2 April 2015 at 09:35, Florian Schmaus <[email protected]> wrote: > > On 02.04.2015 10:08, Dave Cridland wrote: > > On 1 April 2015 at 18:33, Matthew Wild <[email protected] > > <mailto:[email protected]>> wrote: > > On 1 April 2015 at 17:37, Dave Cridland <[email protected] > > <mailto:[email protected]>> wrote: > > It is also not clear to me what, exactly, the "more" consists > > of. I have heard: > > > > - Reflection of messages to the source. > > > > > > I think this only really makes sense in XEP-0280. > > > > > > ... > > <feature var='urn:xmpp:carbons:2'/> > > <feature var='urn:xmpp:carbons:advanced:0'/> > > ... > > > > <iq type='set'> > > <enable xmlns='urn:xmpp:carbons:2' > > adv:xmlns='urn:xmpp:carbons:advanced:0'> > > <adv:reflection/> > > After giving it more thought I'm really undecided if I think it's better > to have this in carbons (xep280) or as extra XEP. But I think, given > that carbons is still experimental, and maybe soon deferred, I > personally would add this feature to the carbons XEP and not as extra XEP. Agreed. It's not very different to bumping the carbons namespace in the end - servers can offer multiple versions if they want. Conceptually this belongs in XEP-0280. Developers often complain about having to read too many XEPs to get anything practical done. > > - Addition of MAM identifiers. > > This can (and should) be a separate XEP. > > <adv:archive-id/> > > Noooo, IMHO message IDs are orthogonal to carbons and especially not a > feature of carbons. A few people incl myself think more of something > like http://geekplace.eu/xeps/xep-mid/xep-mid.html. Agreed. This doesn't need to be part of carbons, nor should it be. > > - Other types beyond 'chat'. > > Seems to be something we want to have. And I would tend to put this into > the carbons XEP too. I'm undecided about this. I think we could get away with just saying that normal+chat should be copied. Headlines are usually sent to the bare JID. If you want to use headlines for their no-storage policy, use normal with the no-store hint from XEP-0334. > > There is one more item, switching from <private/> to XEP-0334 > > Message Processing Hints. > > Don't care, as I see, in this specific case, neither a big advantage in > re-using existing XEPs for carbon's private semantic, nor an disadvantage. I think it's an advantage to have some consistency between our XEPs, particularly given that MAM and Carbons go hand-in-hand in any modern client. We're rapidly closing in on the ideal stack for reliable user-friendly end-to-end messaging, and when these specs are done, they're here to stay. Carbons is 99% of the way to the ideal protocol, I'd really love to plug the few remaining holes before sending it out to sea. Regards, Matthew
