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" <[email protected]> wrote: > 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 > >
