On 2012-07-17 11:39, Kevin Smith wrote:
Right, I had assumed that. However, I'm not sure the protocol and the
UI tie in as closely as might first appear (given that a malicious
entity would just pick the session type most likely to be accepted).
That is: The UI could sayAlice wants to start a
My only argument against this is that this layers a metasyntax into
attribute values - for that reason alone I'm leaning toward Kim's reworking
using a child element.
That said, Kim's has the additional benefit that it is extensible, and
previous experience suggests that this is always a good
On Mon, Jul 16, 2012 at 11:41 PM, Kim Alvefur z...@zash.se wrote:
If we want the `reason` bit to be flexible, why not make it some
combination of a text label and a registry, perhaps similar to stanza
errors.
Maybe reuse the features (XEP 30, Disco) registry, like:
decloak
reason
On 17/07/12 00:26, Lance Stout wrote:
The reason value is really just a hint or suggestion
Yes, that was my intention when I wrote the XEP. It seems a bit more
user-friendly if you can hint at the reason for requesting de-cloaking:
/---\
| Alice
On 7/17/12 2:34 AM, Kevin Smith wrote:
On Mon, Jul 16, 2012 at 11:41 PM, Kim Alvefur z...@zash.se wrote:
If we want the `reason` bit to be flexible, why not make it some
combination of a text label and a registry, perhaps similar to stanza
errors.
Maybe reuse the features (XEP 30, Disco)
On Wed, Jul 11, 2012 at 2:01 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
I suggest changing explicit user configuration with explicit user
confirmation and then adding another sentence that the user confirmation
can be per request, per first request per requestor, or by setting some
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
On Mon, Jul 16, 2012 at 4:56 PM, Gunnar Hellström
gunnar.hellst...@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
If we want the `reason` bit to be flexible, why not make it some
combination of a text label and a registry, perhaps similar to stanza
errors.
Maybe reuse the features (XEP 30, Disco) registry, like:
decloak
reason ver=urn:xmpp:jingle:apps:rtp:audioVoice call/reason
/decloak
--
Regards,
Kim
Given that entity caps are expected to be transmitted in both the sent and
received presence (or failing that you now know a full JID which can be queried
for disco), what more do we really need other than saying that you can include
multiple values in the reason attribute?
decloak
On 2012-07-17 01:26, Lance Stout wrote:
Given that entity caps are expected to be transmitted in both the sent and
received presence (or failing that you now know a full JID which can be queried
for disco), what more do we really need other than saying that you can include
multiple values in
Version 0.3 of XEP-0276 (Presence Decloaking) has been released.
Abstract: This specification defines an XMPP protocol extension that enables a
user to send directed presence with a request for the target to also share
presence information for the duration of a communications session.
Version 0.2 of XEP-0276 (Presence Decloaking) has been released.
Abstract: This specification defines an XMPP protocol extension that enables a
user to send directed presence with a request for the target to also share
presence information for the duration of a communications session.
A quick comment:
Security Considerations say Because decloaking is a presence leak (albeit
intentional), an XMPP client that implements the receiving side of this
specification MUST disable sharing of session presence by default and MUST
enable the feature only as a result of explicit user
14 matches
Mail list logo
