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. Peter Saint-Andre píše v Út 02. 02. 2010 v 09:37 -0700: > The numerical approach to status codes is ugly: > > <presence > from='[email protected]/thirdwitch' > to='[email protected]/pda'> > <x xmlns='http://jabber.org/protocol/muc#user'> > <item affiliation='member' role='participant'/> > <status code='110'/> > </x> > </presence> > > I think it could be easily extended as we did for core XMPP stanza errors: > > <presence > from='[email protected]/thirdwitch' > to='[email protected]/pda'> > <x xmlns='http://jabber.org/protocol/muc#user'> > <item affiliation='member' role='participant'/> > <status code='110'> > <self-presence/> > <status> > </x> > </presence> > > The question is: should the new child elements be qualified by a > namespace other than muc#user? I think that would be cleaner and less > likely to cause problems, because XMPP implementations ignore data from > unknown namespaces. So I propose this: > > <presence > from='[email protected]/thirdwitch' > to='[email protected]/pda'> > <x xmlns='http://jabber.org/protocol/muc#user'> > <item affiliation='member' role='participant'/> > <status code='110'> > <self-presence xmlns='urn:xmpp:muc-status:0'/> > <status> > </x> > </presence> > > If that approach seems sensible, I will define appropriate child > elements for the existing status codes. Naturally, the <status/> element > could be extended with other child elements, too. I'll copy appropriate > text about application-specfic child elements from RFC 3920. > > Peter >
signature.asc
Description: Toto je digitálně podepsaná část zprávy
