Splitting thread, as requested... On Tue, Jul 24, 2012 at 12:37 AM, Mark Rejhon <[email protected]> wrote: > On Mon, Jul 23, 2012 at 10:32 AM, Kevin Smith <[email protected]> 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
