[Standards] UPDATED: XEP-0276 (Presence Decloaking)

Mark Rejhon markybox at gmail.com
Mon Jul 16 21:27:17 UTC 2012


On Mon, Jul 16, 2012 at 4:56 PM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120716/7f14c6f0/attachment.html>


More information about the Standards mailing list