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

Dave Cridland dave at cridland.net
Tue Jul 17 07:53:03 UTC 2012

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 option. The fact
we're discussing different ways of using the field suggests extensibility
may well be needed.
On Jul 17, 2012 12:44 AM, "Gunnar Hellström" <gunnar.hellstrom at omnitor.se>

> 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 the reason attribute?
>>    <decloak reason="audio video text" />
>>  >Answers should include details about the presence, such as supported
>>> codecs, and parameters, and encryption capabilities.
>> Any supported protocols, codecs, etc would be found via disco/entity caps.
>> The reason value is really just a hint or suggestion, since the requester
>> may well attempt to subsequently establish a different type of session than
>> originally requested, or none at all (this should be mentioned in security
>> considerations, I think). Attempting to layer much more meaning than that
>> seems more complex than necessary.
> Good reasoning,
> if we make it:
> <decloak reason="audio video real-time-text message-text" />
> Real-time text and message text has very different usability
> characteristics, so they should not be intermixed. Real-time text is rapid
> without the wait for message composition that appears in message text. It
> is time to modernize text communication. Merging them under the single
> label "test" is as asking for streamed video and conversational video at
> the same time.
> /Gunnar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120717/2bb9fc19/attachment.html>

More information about the Standards mailing list