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

/K



More information about the Standards mailing list