On Mon, Jul 16, 2012 at 4:56 PM, Gunnar Hellström < [email protected]> wrote: > > 6. The reason Attibute > > To signal the type of communication that is desired, the entity that first > shares session presence MAY include a 'reason' attribute on the <decloak/> > element. Multiple values are allowed. The following values for the 'reason' > attribute are defined: > *video* > Presence is requested for video medium of a call party, e.g. via Jingle > RTP Sessions <http://xmpp.org/extensions/xep-0167.html> > [8<http://xmpp.org/extensions/xep-0276.html#nt-id337164> > ]. *audio* > Presence is requested for audio medium of a call party, e.g. via Jingle > RTP Sessions <http://xmpp.org/extensions/xep-0167.html> > [8<http://xmpp.org/extensions/xep-0276.html#nt-id337164> > ]. ** > *real-time-text* Presence is requested for a real-time text conversation > using a medium of the call party or an extension that requires real-time > text capabilities to be disclosed, such as In-Band Real Time > Text<http://xmpp.org/extensions/xep-0301.html> > [11 <http://xmpp.org/extensions/xep-0276.html#nt-id343682>], or Jingle > RTP Sessions <http://xmpp.org/extensions/xep-0167.html> > [8<http://xmpp.org/extensions/xep-0276.html#nt-id337164>] > or real-time text capabilities beyond a gateway. *message-text* Presence > is requested for a text communication using a message medium of the call > party or an extension that requires text message capabilities to be > disclosed, such asXHTML-IM <http://xmpp.org/extensions/xep-0071.html> > [9<http://xmpp.org/extensions/xep-0276.html#nt-id343644> > ], Chat State Notifications <http://xmpp.org/extensions/xep-0085.html> > [10<http://xmpp.org/extensions/xep-0276.html#nt-id343663> > ], or text message capabilities beyond a gateway. ***file* Presence is > requested for one or more file transfers, e.g. via Jingle File > Transfer<http://xmpp.org/extensions/xep-0234.html> > [12 <http://xmpp.org/extensions/xep-0276.html#nt-id343702>] or Stream > Initiation <http://xmpp.org/extensions/xep-0095.html> > [13<http://xmpp.org/extensions/xep-0276.html#nt-id343721> > ]. >
Gunnar's ideas seem good (though the implementation details could be reduced somewhat). I wonder if there's a need for that many granular reasons, because I consider real-time text to be the same category as message-text. However, it is my understanding that this isn't the case for the SIP / RFC4103 side of things, because the SIP RTT / SIP messaging are more independent of each other. On the other hand, the text transmitted over RFC4103/T.140 over SIP (for real time text) and SIP Message/MSRP can be brought into sync by the implementor, much like <rtt/> (XEP-0301) and <body/> (XMPP Core) is kept in sync by an implementation. Side note: Right now, as far as I know, I don't see any standardization (as far as I know) for synchronizing the text between RFC4103/T.140, and the text in SIP Mesage, but it is possible, likely by transmitting the SIP Message everytime someone hits Enter, or after a certain number of characters. (which may introduce ambiguity in backspacing to previous message, but there are some solutions to even this too. On the XMPP side of things, it's XEP-0308 last message editing and a very minor extension to XEP-0301 (It's just an "id" parameter for <rtt/> elements containing a event='new'/'reset') can theoretically allow XEP-0301 on last message editing, and permit backspacing to the previous message, for backwards compatibility to "linear RTT" (textphone style). Implementations would have to be responsible for merging the user interface presentation. But this side-note paragraph is not XMPP talk, and probably needs to be brought up on the appropriate IETF mailing list, to synchronize the text of the messaging with the real-time text. Thanks Mark Rejhon
