On 2/2/10 10:13 AM, Jiří Zárevúcky wrote: > 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.
I do think that we'll deprecate the 'code' attribute eventually, just as we have done for stanza errors. But it will be a long time before all MUC implementations drop support for it. >> <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. OK, good. We seem to have consensus. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
