2010/2/2 Jiří Zárevúcky <[email protected]> > 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. >
Why not have the new status value as an attribute but in a new namespace? eg: <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' ns1:status="self-presence" xmlns:ns1='urn:xmpp:muc-status:0'/> </x> </presence> > 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 > > > > > > -- Peter Mount e: [email protected] w: http://retep.org xmpp:[email protected] <xmpp%[email protected]> MSN: [email protected]
