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 -- Peter Saint-Andre https://stpeter.im/
