On Thu, Feb 4, 2010 at 10:45 AM, Peter Saint-Andre <[email protected]>wrote:
> 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. :) > > I have an alternative suggestion :) <x xmlns='http://jabber.org/protocol/muc#user'> <status code='210'/> <status xmlns='urn:xmpp:mucstatus:0'> <roomnick-rewritten/> <real-jid-enforced/> <custom xmlns='helo:wrld'/> </status> </x> Using <mucstatus xmlns='urn:xmpp:mucstatus:0'/> instead of <status xmlns='urn:xmpp:mucstatus:0'/> might make some folks happier, though existing implementations wont break on either. Advantages of this approach.. It's concise. It's cleanly separated from legacy status codes. The other suggestions seem like patches tacked on legacy status codes (they are children of the legacy status element, which is an unnecessary dependency IMHO). Argument against keeping the <status/> element.. The <status/> element can appear multiple times. <status xmlns='urn:xmpp:mucstatus:0'> <roomnick-rewritten/> <real-jid-enforced/> </status> seems cleaner to me than <status> <roomnick-rewritten xmlns='urn:xmpp:mucstatus:0'/> </status> </status> <real-jid-enforced xmlns='urn:xmpp:mucstatus:0'/> </status> What exactly is the advantage of keeping the old <status/> element? I don't see it making implementation or documentation easier. -- Waqas Hussain
