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

Peter Saint-Andre stpeter at stpeter.im
Sat Aug 4 02:53:11 UTC 2012

On 8/3/12 2:54 PM, Paul E. Jones wrote:
> Mark, et al,
> I re-read the draft and here are my comments.  

Thanks for the review. Paul, I agree with your comments, and I have a
few further thoughts here and there...

> Section 4.2.1:
> Why is "seq" only 31 bits?  Since the same memory is consumed for 31 or 32
> bits, why not just makes it an unsigned 32-bit integer?  And why worry about
> wrap-around?  I would allow it to occur.  Specify the behavior.

Makes sense. For example, in XEP-0047 we say that when hitting the
maximum we reset the sequence to zero.

> Section 4.2.2:
> A value for "init" is that it would remove any ambiguity related to the
> "seq" value.  The "seq" value could always start at 1 if "init" were
> required.  The problem with "init", though, is that if a sender sends three
> messages one after the other, the first two might go to client A and the
> last one might go to client B.  This would happen if I have two XMPP clients
> connected to the server and I disconnect one.  Therefore, "init" and
> "cancel" seem pointless.  I'd suggest getting rid of them entirely.  I like
> having "new" since that Client B I refer to would know that if it gets an
> <rtt> that is not "new" it must be some message somewhere in the middle of
> typing and can just ignore those until it gets a <body>, then pick up with
> RTT on the next <rtt event="new">.

I think that's sensible, and it would simplify the protocol a bit
further. Thanks for bringing up the multi-resource case.

> 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.

> Section 6.2.1:
> I think the activation logic is complex.  Let each user turn it on or off as
> he sees fit.  If you send <rtt> tags to my client, whether that gets renders
> or not depends on my local settings.  I don't see a strong need to negotiate
> this.  Just always send <rtt> and display it (if received) whenever the user
> enables RTT.

The objection here is that if my client doesn't support RTT and you send
me RTT despite that fact, I will end up receiving a lot more data than I
need to or want to (e.g., this extra data might cost me money by running
up my bandwidth usage).

> Section 9:
> How does XMPP indicate that a message should be displayed LTR or RTL?  Is
> that derived from the language indicated in the <body> tag?  This is legal:
> <body xml:lang="en">This would display left-to-right</body>
> In any case, we do need to ensure we capture directionality for languages
> like Hebrew.

This is not indicated at all in XMPP, because it is handled by the
receiving application based on the Unicode characters themselves.

I need to re-read the entire spec, myself. But not tonight. :)


Peter Saint-Andre

More information about the Standards mailing list