On Mon, Aug 13, 2012 at 3:00 AM, Gunnar Hellström <[email protected]> wrote: > That is both an opportunity and a risk. > It is an opportunity for other extensions adding elements to the <message/> > to consider if they want to utilize XEP-0308 for replacing the contents. > ( this could possibly be utilized by XEP-0301 instead of specifying its own > way of doing replacements of real-time text, but it requires some more > specific rules in XEP-0301 about how to apply it in that environment.)
In addition, it would likely be non-backwards compatible in a "graceful degrade manner", e.g. MUC A mixed MUC with all kinds of participants simultaneously: - Clients that don't support XEP-0301 - Clients that support XEP-0301 but not XEP-0308 - Clients that support XEP-0308 but not XEP-0301 - Clients that support both XEP-0301 and XEP-0308 The way both me and Kevin has currently specified, ensures that both 0301 and 0308 will work and interop fine in mixed-MUC situations. Therefore, I like the way XEP-0308 is specified: full stanza replacement only, and keeping 0301 retroactive editing separate of 0308 retroactive. It's far simpler and far more forgiving than trying to specify ways of replacing specific <rtt/> elements. Mark Rejhon
