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

Mark Rejhon markybox at gmail.com
Fri Aug 24 04:32:26 UTC 2012


Hello Peter,

Thanks for addressing these!  I agree with the majority of this group
of comments.
Some questions and inquiries below:

On Wed, Aug 22, 2012 at 10:40 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 33. "with heavy packet-bursting tendencies" -- perhaps "susceptible to
> significant packet loss".

I meant erratic ping, not packet loss.  Situations where some
transmissions are delayed by a second, and other transmissions delayed
by only a hundred milliseconds.   How about I say "with very variable
latency."
However, packet loss, is indeed compensated by "Keeping Real-Time Text
Synchronized".


> 34. Section 6.2 still has some confusing text. I suggest the following
> modifications.
>
> 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.

I noticed that the second sentence is clearly redundant (to a part of
the sentence in the next section).
However, the first sentence is more useful than I thought because
people have asked what the right way to turn on/off real time text,
while other people have "Different Ideas" about how to turn on/off
real time text.   So I feel I must mention a single sentence at least.
 It's caused big discussion threads before.   This paragraph was 4 or
5 sentences in the last revision (0.6) before being reduced to 2
sentences, but I now see it can be reduced to 1 sentence, and the last
sentence relocated to a different paragraph ("There are many ways to
turn on/off real-time text") or modify one of the other existing
sentences...


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

Actually, I wonder if I should leave the first paragraph unmodified,
and move this discovery paragraph to a separate section. (e.g.
"Business Rules" ala XEP-0085) -- That's one of the discussions of
section 6.2, some people think that this paragraph needs to be
upgraded with RFC2119.


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

I'll say "(common in some countries)" -- I originally included the
example since some implementers North America don't even know what an
IME is, so context is useful.


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

Yes -- though I believe the rate-limiting talk belongs in the
"Congestion Considerations" section; I'll add a mention.
Section 6.6.1 talks of message length instead of message rate (as a
standalone problem by itself that's a problem even when it's not a
congestion consideration)


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

I cover it with:
"Other chat states are handled as specified by XEP-0085 Chat States"
Since behavior of those chat states are essentially unmodified:

I can change:
"Other chat states are handled as specified by XEP-0085 Chat States"

Into:
"Other chat states (e.g. PAUSED, INACTIVE) are handled as specified by
XEP-0085 Chat States"


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

I see what you mean -- I need to change "Users of real-time text needs"
into "Users of real-time text need" -- as one of the many examples.
I will read some grammar instructions on the web, and try to catch
them all.  Thanks!

(Gunnar, et cetra -- feel free to help save my time in my edit queue
by highlighting
all of these occurances of subject-verb disagreements.  You can email
me privately)


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

Should I just remove (e.g. XEP-0200), or should I remove the whole
bullet entirely?


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

DoS scenario for MUC is simply high stanza rate, but you can always
send <body/> at a high stanza rate -- same problem, I'm just
mentioning the same DoS scenario.
I've carefully made the spec to not cause amplification attacks (e.g.
stanzas don't cause extra stanzas to be generated) since activation is
self-initiated with no handshaking/signalling back and fourth during
MUC.
So it's no more/less immune to amplification attacks than sending
<body/> or XEP-0085 chat states.


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

Gunnar cited one of these university studies.  I could add it as a citation.


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

I checked documentation, can you confirm, this is proper.
<t/>, <e/> and <d/> can be any number (zero or more) in any order.

<xs:choice minOccurs='0' maxOccurs='unbounded'>
    <xs:element ref='t' '/>
    <xs:element ref='e' />
    <xs:element ref='w' />
</xs:choice>


> Thanks for listening!

You're welcome!

Mark Rejhon



More information about the Standards mailing list