[Standards] Comments on XEP-0301 (possible impact on -0308 in Section 4.2.3)

Mark Rejhon markybox at gmail.com
Sat Aug 4 08:06:09 UTC 2012


Some comments and corrections about the 0308 example and proper usage:

On 2012-08-04 2:38 AM, "Paul E. Jones" <paulej at packetizer.com> 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='juliet at capulet.net/balcony' id='bad1'>
>   <rtt><t>But soft, what</t></rtt>
> </message>
> <message to='juliet at capulet.net/balcony' id='bad1'>
>   <rtt><t> light through yonder airlock breaks?</t></rtt>
> </message>
> <message to='juliet at capulet.net/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='juliet at capulet.net/balcony' id='good1'>
>   <rtt><e p="36" n="7/></rtt>
>   <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/>
> </message>
> <message to='juliet at capulet.net/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='juliet at capulet.net/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='juliet at capulet.net/balcony' id='good1'>
>   <rtt></rtt>
>   <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/>
> </message>
> <message to='juliet at capulet.net/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='juliet at capulet.net/balcony' id='bad1'>
<rtt event='new' seq='3000'><t>But soft, what</t></rtt>
</message>

<message to='juliet at capulet.net/balcony' id='bad2'>
<rtt seq='3001'><t> light through yonder airlock breaks?</t></rtt>
</message>

<message to='juliet at capulet.net/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='juliet at capulet.net/balcony' id='good1'>
<rtt event='reset' seq='4321' id='bad3'> But soft, what light through
yonder airlock breaks?</rtt>
</message>

<message to='juliet at capulet.net/balcony' id='good2'>
<rtt seq='4322' id='bad3'><e p="36" n="7/></rtt>
</message>

<message to='juliet at capulet.net/balcony' id='good3'>
<rtt seq='4323' id='bad3'><w n="300"/><t p="36">bre</t></rtt>
</message>

<message to='juliet at capulet.net/balcony' id='good4'>
<rtt seq='4324' id='bad3'><w n="120"/><t p="39">ks</t></rtt>
</message>

<message to='juliet at capulet.net/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120804/e29fe403/attachment.html>


More information about the Standards mailing list