[Standards] XEP-0301 0.5 comments [Sections 6 and beyond]

Kevin Smith kevin at kismith.co.uk
Wed Jul 25 09:33:44 UTC 2012

Splitting thread, as requested...

On Tue, Jul 24, 2012 at 12:37 AM, Mark Rejhon <markybox at gmail.com> wrote:
> On Mon, Jul 23, 2012 at 10:32 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
>> 6.2.1 - That said, if people disagree and want another 85-ish
>> non-disco mess, I think this can be clarified a bit - at the moment it
>> sounds like disco and init discovery are alternatives, rather than
>> init only being a fallback for when disco isn't available. Perhaps
>> something like:
>> """
>> Activation of real-time text in a chat session (immediate or
>> user-initiated) can be done by:
>> * Immediately transmitting real-time text (if the feature is
>> advertised in by the recipient, as described in Determining Support);
>> or
>> * Where Disco knowledge isn't available (e.g. sending to an entity for
>> which presence information isn't available, and thus the full JID
>> isn't known and can't be queried) by sending a <message/> stanza
>> containing only a "<rtt event='init'/>". In this case there MUST be no
>> further transmission of RTT elements until the recipient indicates
>> support - either by exposing information necessary to use service
>> discovery, or by replying with a (non-cancel event) RTT element of its
>> own.
> [Comment]
> One observation, section 5.1 of XEP-0085:
> http://xmpp.org/extensions/xep-0085.html#support
> "Before generating chat state notifications, a User SHOULD explicitly
> discover whether the Contact supports the protocol defined herein ..."
> Likewise, XEP-0301 already allows implicit negotiation simply by sending
> <rtt event='init'/> which is also valid anyway even if you do "Determining
> Support".  The primary purpose of <rtt event='init'/> is not for disco, but
> to decouple activation timing from creation of a new real-time message.  It
> just happens to be the best "first rtt element" to use.  (It happens to be a
> conveniently valid element to use with or without a sending client
> determining disco first, in the same style as XEP-0085)
> As XEP-0301 was also designed to also behave as an extended chat state, I'd
> rather keep it synchronous with XEP-0085 requirements
> (I should have studied it more closely months ago, and synced up
> requirements much earlier -- to keep the debate simpler).
> I'll stay in sync with future changes to XEP-0085, too (if that's ever
> done).
> [If discussion is needed on this point, let's split reply to a separate
> thread again -- it's an a topic meriting its own separate thread, since this
> could distract from all the other good minor changes in this thread]
> Technically, that <rtt event='init'/> isn't "messy" because its purpose is
> not designed for disco --
> it simply permits decoupling of the activation moment from the moment of
> creating a new real-time message.

The point I was making, perhaps unclearly, is that once you have done
disco if you've established that the entity doesn't support RTT you
don't then start sending an init. That is - 6.2.1 makes it sound like
you are allowed to choose to ignore caps and to always use init, even
when you know the recipient doesn't support RTT.


More information about the Standards mailing list