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

Mark Rejhon markybox at gmail.com
Fri Aug 24 16:33:08 UTC 2012


On Fri, Aug 24, 2012 at 11:56 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>> 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').

Aha, I understand now.
Yes, I am trying to address both.  This might necessitate a new
section (and doing a slight expansion).  Since both different things
are important to mention in the spec.  So I'll need to split this
section.   I understand some may disagree about including both, but
both is very important based on implementer feedback in the last two
years.

(Ideas and suggested paragraphs welcome)


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

Thanks.  It's possibly one of the most important parts of the spec (Section 6.2)


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

Aha.  Just so you know, disposition of stale messages (unfinished
real-time messages that might conceivably never become finished) is
something recommended to be done only after an extended period --
wihch would be more for <inactive/> rather than <paused/>.  That said,
a reference to XEP-0085 is useful here.


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

Gotcha, good idea -- I'll remove the XEP-0045 mention, since RTT isn't
an enhanced DoS vector on MUC in a properly-engineered application.

Thanks,
Mark Rejhon



More information about the Standards mailing list