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

Peter Saint-Andre stpeter at stpeter.im
Fri Aug 24 15:56:54 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/23/12 10:32 PM, Mark Rejhon wrote:
> 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."

Works for me.

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

As end users who are interacting with their IM clients, or as client
developers who are trying to figure out when to start sending protocol
over the wire? The two are very different things, and let's not
conflate them by using the same term ('activation').

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

Possible. I'll look at it again later today or over the weekend.

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

True, I learned about them only a year or two ago.

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

That's in 6.6.2, not 6.6.4.

I suggest this change in 6.4.4:

OLD
There are situations where senders pause typing indefinitely.

NEW
There are situations where senders pause typing indefinitely, which
might be signalled by generating a <paused/> or <inactive/> chat state
(XEP-0085).

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

If you miss some, the XEP Editor reserves the right to fix them later
on. :)

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

Just XEP-0200, please.

>> 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 think of DoS as "DoS attack", but that might be colored by my recent
experience at the jabber.org IM service. Why not remove "(e.g. during
DoS scenario in Multi-User Chat)"? Calling out XEP-0045 here doesn't
strike me as particularly helpful.

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

Yes, we've had those discussions, no need to rehash them here. :)

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

Sounds good.

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

Right, that's better.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


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

iEYEARECAAYFAlA3pEYACgkQNL8k5A2w/vwLkACfZfXybJVy43qa050nBl/9IiFo
h10An2AfPnirgL8+ycnlnapMjdwSW4G1
=6F96
-----END PGP SIGNATURE-----



More information about the Standards mailing list