Some comments and corrections about the 0308 example and proper usage: On 2012-08-04 2:38 AM, "Paul E. Jones" <[email protected]> wrote: > > Peter, > > > > Section 4.2.3 > > > > > > XEP-0308 specifies use of "id" in <message> and <replace>. Could we > > > not just use "<replace>" along with "<rtt>"? It would require some > > > text in > > > XEP-0308 that says that if <replace> is received without <body>, it > > > shall be ignored. In -0301, it would not be ignored. "id" works, but > > > I would not immediately recognize what that was for if I had not read > > > this part of the spec. > > > > I don't quite follow your line of reasoning here. > > Sorry for the lack of clarity on that one. > > I'm wondering how we enable text to be sent real-time for messages that are being replaced as described in XEP-0308. Consider examples 3 and 4 in XEP-0308. Can we do the following? > > User types: > > <message to='[email protected]/balcony' id='bad1'> > <rtt><t>But soft, what</t></rtt> > </message> > <message to='[email protected]/balcony' id='bad1'> > <rtt><t> light through yonder airlock breaks?</t></rtt> > </message> > <message to='[email protected]/balcony' id='bad1'> > <body>But soft, what light through yonder airlock breaks?</body> > </message> > > Now, the user wants to replace the word "airlock" with "window": > > <message to='[email protected]/balcony' id='good1'> > <rtt><e p="36" n="7/></rtt> > <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> > </message> > <message to='[email protected]/balcony' id='good1'> > <rtt><w n="300"/><t p="36">bre</t></rtt> > <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> > </message> > <message to='[email protected]/balcony' id='good1'> > <rtt><w n="120"/><t p="39">ks</t></rtt> > <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> > </message> > <message to='[email protected]/balcony' id='good1'> > <rtt></rtt> > <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> > </message> > <message to='[email protected]/balcony' id='good1'> > <body>But soft, what light through yonder window breaks?</body> > <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> > </message> > > If this is valid, we need to say somewhere that <replaces> might be transmitted without a <body> element. XEP-0308 defines use of <replaces>, so it might need some wording. XEP-0301 might likewise need to consider some wording to describe this. >
Your example would work if XMPP allowed it but it is not possible -- it is illegal because XMPP require unique id for subsequent message stanzas. You are using duplicate id's which is not done by XMPP servers. Also your example is not backwards compatible in a graceful degrade manner. Originally, <replace/> was designed to replace the whole stanza. This is harder to implement, and is less backwards compatible. Do this thought experiment mentally. Pretend to run all the stanzas above, through to client that supports 0301 but not 0308. It will cause problems. (Example: MUC where some clients support 0308 and other clients do not support 0308). There isn't a "graceful degrade" like the protocol that me, Peter, Kevin et cetra agreed on for unifying 0301 and 0308. The method we agreed is more backwards compatible. Now, modify it so that it uses the current protocol. Your first three stanzas almost stay the same, except the XMPP core protocol requires that message must always use a different "id" for each stanza (that is the flaw in your example, since your example is impossible due to XMPP always using a unique id for each subsequent stanza in the same chat session). I also include the event and seq attributes in these examples, as required by the 0301 protocol. <message to='[email protected]/balcony' id='bad1'> <rtt event='new' seq='3000'><t>But soft, what</t></rtt> </message> <message to='[email protected]/balcony' id='bad2'> <rtt seq='3001'><t> light through yonder airlock breaks?</t></rtt> </message> <message to='[email protected]/balcony' id='bad3'> <body>But soft, what light through yonder airlock breaks?</body> </message> See, the three stanzas have three separate id's, because it is required by XMPP protocol. bad1, bad2, bad3. Next, we use existing protocol (the way Kevin and I agreed) to allow the user to replace the word "airlock" with "window": <message to='[email protected]/balcony' id='good1'> <rtt event='reset' seq='4321' id='bad3'> But soft, what light through yonder airlock breaks?</rtt> </message> <message to='[email protected]/balcony' id='good2'> <rtt seq='4322' id='bad3'><e p="36" n="7/></rtt> </message> <message to='[email protected]/balcony' id='good3'> <rtt seq='4323' id='bad3'><w n="300"/><t p="36">bre</t></rtt> </message> <message to='[email protected]/balcony' id='good4'> <rtt seq='4324' id='bad3'><w n="120"/><t p="39">ks</t></rtt> </message> <message to='[email protected]/balcony' id='good5'> <body>But soft, what light through yonder window breaks?</body> <replace id='bad3' xmlns='urn:xmpp:message-correct:0'/> </message> (Note, need to add xmlns for rtt, consider this assumed for above examples) The example above is based on protocol that has been unamiously agreed between me and Kevin. It accomodates: - Proper usage of unique ID's, and intended usage of <replace/> in the original 0308 spirit. - The <replace> is not used in the same message stanzas as <rtt> for the above reasons. (The unique id's) - Message reset occurs at beginning of editing a specific message. - For mixed MUC, gracefully compatible with non-0301 participants (the rtt is simply ignored, no real time text) Do the thought experiment and run without 0301 - For mixed MUC, gracefully compatible with non-0308 participants (the <replace/> elements and the 'id' attributes are simply ignored, the RTT and BODY behaves like a new message, since reset is specified to begin a new message if no new message exists) Do the thought experiment and run without 0308-related features - For mixed MUC, also gracefully compatible with non-0301/0308 clients. (Combination of both the above bullets) - This also includes situations where a client may inadvertently transmit to a different client (simultaneous login, sending to bare jid rather than full jid) -- This is contrary to XMPP recommendation, but can occur during resource unlocked state, or when server is doing carbon copying of stanzas to all resources (google does this, against XSF recommendations). Regardless, we don't want the protocol to suddenly 'mess up' during such various edge cases of multi resource scenarios that have different caps than others. We don't want failure conditions. - You had one blank rtt in your example; Blank rtt's are not transmitted. Skip unecessary transmission if the rtt is blank. (e.g. no <rtt> transmissions during idle periods). Already mentioned in section 4.1 (was it unclear; and need clarifications?) So as you can see, it is a design that gracefully degrades, I prefer the method that Kevin (0308 author) and me (0301 author) agreed upon. What do you think, Paul? By now, I imagine you understand why 0301+0308 interop is done this way. Based on this info, what clarifications and improvements can be done -- we're all ears! Thanks, Mark Rejhon
