<p>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.</p>
<p>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.</p>

<div class="gmail_quote">On Jul 17, 2012 12:44 AM, "Gunnar Hellström" <<a href="mailto:gunnar.hellstrom@omnitor.se">gunnar.hellstrom@omnitor.se</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-07-17 01:26, Lance Stout wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>

<br>
   <decloak reason="audio video text" /><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>Answers should include details about the presence, such as supported codecs, and parameters, and encryption capabilities.<br>
</blockquote>
Any supported protocols, codecs, etc would be found via disco/entity caps.<br>
<br>
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.<br>

</blockquote>
Good reasoning,<br>
if we make it:<br>
<decloak reason="audio video real-time-text message-text" /><br>
<br>
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.<br>

<br>
/Gunnar<br>
<br>
</blockquote></div>