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:

<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'/>
    <status code='110'/>
    <status code='210'/>
    <mucstatus xmlns='urn:xmpp:mucstatus:0'>
      <non-anonymous/>
      <roomnick-rewritten/>
      <self-presence/>
    <mucstatus>
  </x>
</presence>

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:

    <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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to