[Standards] Comments on XEP-0301 (possible impact on -0308 in Section 4.2.3)
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
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. :)
More information about the Standards