[Standards] review of XEP-0301, sections 6-14

Peter Saint-Andre stpeter at stpeter.im
Thu Aug 23 02:40:08 UTC 2012

Hash: SHA1

In this message I continue my review of XEP-0301, starting with
Section 6 (my previous message contained 32 comments, so I begin this
list with #33).

33. "with heavy packet-bursting tendencies" -- perhaps "susceptible to
significant packet loss".

34. Section 6.2 still has some confusing text. I suggest the following

a. Remove the paragraph directly before 6.2.1. It appears to be
talking about whether RTT features are enabled by default in a client
or require user interaction to enable. That topic is outside the scope
of this specification, and in any case reflects a different meaning of
activation than addressed by 6.2.1 and 6.2.2.

b. Move the last paragraph of 6.2.1 ("Before sending real-time
text...") so that it is the first paragraph of 6.2.1, then remove the
current first paragraph ("Sender clients can...") since it is covered
in the last paragraph.

c. In 6.2.2, change "respond to deactivation with appropriate
response(s)" to "handle deactivation in several ways" -- not all of
these involve generating a response that is sent over the stream to
the sending client. (Once again, a bit of confusion between write
protocol and internal processing or user interaction.)

35. "input method editors (e.g. Chinese)" -- in fact, input method
editors were originally used in computing for Chinese, Japanese, and
Korean ("CJK") users, although they are now also used more widely.
It's not particularly helpful to mention only one such language, I think.

36. In Section 6.6.1 or elsewhere, I think it would be helpful to
mention the commonality of rate-limiting (often called "karma") in
XMPP deployments. See also below regarding congestion control.

37. In Section 6.6.4, it would be good to mention the PAUSED and
INACTIVE chat states from XEP-0085.

38. In Section 9, I don't see how the (proposed) International Symbol
of Real-Time Text has any impact on the internationalization
considerations of the protocol itself. Please remove this paragraph.

39. "Users of real-time text needs" -- this is just one of many
instances of text violating subject-verb agreement. I have not
mentioned all the ones I found in Sections 6, 7, 8, and 9. Please fix
them all.

40. In Section 10.2, why are we citing XEP-0200? I hesitate to cite
*any* object encryption specification here, given that we have failed
so miserably in this regard.

41. I think Section 10.3 could be improved with some more focused
review. Mentioning karma (see above) would be good. XEP-0184 and
XEP-0198 are not latency monitoring mechanisms per se, although one
byproduct of using them can be an indication that messages are taking
longer than expected to be delivered to the end recipient (XEP-0184)
or handled by the next hop on the communications path (XEP-0198). The
sender could respond to those congestion signals by backing off or
disabling RTT entirely (see RFC 2914 for a more general discussion
about the principles of congestion control, and RFC 5783 for pointers
to other RFCs). The classic best practice is to stop sending so much
data, but if the recipient's stream is truly congested then the sender
might not even receive any congestion signals from the recipient's
client. What are the DoS scenarios in MUC? Can you cite any of the
university studies on message length? The main problem here, however,
is not so much length as the sheer number of messages (although lots
of longer messages would be even more problematic). In sum, this
section isn't really providing much advice about how to *control*
congestion (e.g., back off on sending so much data), or the advice is
lost amongst the other text. Let's make this stronger.

42. In the schema definition of the <rtt/> element, I think you want
xs:choice, not xs:sequence for the child elements.

Thanks for listening!


- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Standards mailing list