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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Jul 16 20:56:33 UTC 2012

On 2012-07-16 19:58, Mark Rejhon wrote:
> I want to comment that XEP-0276 only allows mentioning "media" or
> "text" as the reason, and not both.  XEP-0276 needs to be updated to
> permit a single mechanism activating all three features simultaneously
> (audio, video, real-time text).   This might be complicated by using
> separate, concurrent negotiation mechanisms for out-of-band mechanisms
> (audio, video) and in-band mechanisms (RTT).   Even several of you
> agreed that Jingle is overkill for RTT.  It's assumed that clients
> could detect multiple authentication mechanisms that happens within a
> short period of time to each other, and an implementation can merge
> them into a single confirmation message, for potential future
> XMPP-based "Total Conversation"-compliant software clients.

I also see a great potential in XEP-0276 to make ad-hoc calls to parties 
not known in beforehand, e.g. sip adresses.

But on the SIP side there are at least the following media:
video, (Through RTP)
audio (Through RTP)
real-time text   ( through RTP  RFC 4103)
message text  ( Through SIP Message or MSRP, or maybe even some XMPP 
coexistence protocol)

on the XMPP side, there are the following media:

video ( through Jingle)
audio (through Jingle)
real-time text ( XEP-0301 in-line, or maybe even RTP based through Jingle )
message text ( plain XMPP, HTML, etc as already specified )

Of these, I think only SIP Message cause real problems , because it does 
not really have any reliable capability declaration.

More thoughts: Are there other features we would like to know of that 
need representation in the reason element?
Multi-user chat?
Camera control?
Encryption of media?

Thus, I agree with Mark that there is a need for a more simultaneous 
reasons in the <reason/> element.

I do not know if it is sufficient to just extend <reason/> to allow 
multiple values, or some more flexible way of coding the <reasons/> and 
the answer values are needed.

<reason/> seems to be an optional parameter. I guess that that means 
that the answer may contain presence information outside of what was 
requested in the <reason/> element. If that interpretation is right, we 
can start developing an application behavior responding with all media 
of possible interest until a version with proper coding of multiple 
<reason/> values is published.

Modification proposal to section 6:

    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:

    Presence is requested for video medium of a call party, e.g.
    viaJingle RTP Sessions <http://xmpp.org/extensions/xep-0167.html>[8
    Presence is requested for audio medium of a call party, e.g.
    viaJingle RTP Sessions <http://xmpp.org/extensions/xep-0167.html>[8
    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 asIn-Band Real Time Text
    <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.
    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-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.

    Presence is requested for one or more file transfers, e.g. viaJingle
    File Transfer <http://xmpp.org/extensions/xep-0234.html>[12
    <http://xmpp.org/extensions/xep-0276.html#nt-id343702>] orStream
    Initiation <http://xmpp.org/extensions/xep-0095.html>[13

Inclusion of the 'reason' attribute can be interpreted by the receiving 
client as a signal that communication is about to start; for instance, a 
call accept/reject dialog could double as a UI for accepting or 
rejecting a session presence request.

Answers should include details about the presence, such as supported 
codecs, and parameters, and encryption capabilities.

I am aware that there are gaps and complexities in this definition, and 
hope that others can contribute to refining it. .


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120716/d9fbfd83/attachment.html>

More information about the Standards mailing list