Peter Saint-Andre píše v Út 02. 02. 2010 v 09:57 -0700:
> On 2/2/10 9:47 AM, Jiří Zárevúcky wrote:
> > This approach seems sensible only as long as there is only one status
> > per stanza. When there are more than one, then it would be necessary to
> > have a separate 'status' element for each (to maintain compatibility),
> > which IMO would be quite ugly.
> > 
> > What I propose it to add the named status elements as an independent
> > extension.
> 
> Sure, that is possible:
> 
> [...]
>  
> versus:
> 
> <presence
>     from='[email protected]/thirdwitch'
>     to='[email protected]/pda'>
>   <x xmlns='http://jabber.org/protocol/muc#user'>
>     <item affiliation='member' role='participant'/>
>     <status code='100'>
>       <non-anonymous xmlns='urn:xmpp:mucstatus:0'/>
>     </status>
>     <status code='110'>
>       <self-presence xmlns='urn:xmpp:mucstatus:0'/>
>     </status>
>     <status code='210'>
>       <roomnick-rewritten xmlns='urn:xmpp:mucstatus:0'/>
>     </status>
>   </x>
> </presence>
> 
> However, the following two pieces of information mean the same thing, so
> I would prefer to have that data in one place:
> 

Well, I was counting on the fact that the numerical codes should be
deprecated and eventually removed, in which case <status/> just as a
wrapper with no more informational or functional value would look a bit
strange.

> 
>     <status code='210'/>
> 
>     <mucstatus xmlns='urn:xmpp:mucstatus:0'>
>       <roomnick-rewritten/>
>     <mucstatus>
> 
> Furthermore, applications might want to include some special information
> of their own:
> 
>     <status code='210'>
>       <roomnick-rewritten xmlns='urn:xmpp:mucstatus:0'/>
>       <stringprep-transform xmlns='http://example.com/i18n'/>
>     </status>
> 
> or:
> 
>     <status code='210'>
>       <roomnick-rewritten xmlns='urn:xmpp:mucstatus:0'/>
>       <real-jid-enforced xmlns='http://example.com/policy'/>
>     </status>
> 
> Where does that go in your proposal? Would it go in the <status/>
> element or the <mucstatus/> element or the child of <mucstatus/>? To me,
> the approach I outline is more natural because it is exactly the same as
> in RFC 3920.
> 

Good point. For this, the <status/> element does make sense to keep. 

> Peter
> 


Attachment: signature.asc
Description: Toto je digitálně podepsaná část zprávy

Reply via email to