[Standards] Query Regarding MUC XEP-0045

kawaljeet singh chadha kawaljeet_singh at rediffmail.com
Tue Apr 15 13:30:10 UTC 2008


  
 Hi .
  Is there any way (under current implementation), to get the names of persistent chatrooms created by me (earlier). wherein i want to destroy the room. 
  Kindly let me know, how is that possible.
 Thanks,
   Kawaljeet.


On Tue, 15 Apr 2008 Peter Saint-Andre wrote :
>Matthew Wild wrote:
> > On Fri, Apr 11, 2008 at 10:23 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> >  >  Registered with the room or with the service? Do we need to
> >  >  differentiate between the two? If you are registered with the room then
> >  >  you are a member, whereas nick registration has meaning across the
> >  >  service. Compare Section 7.10 of XEP-0045, where you register with the
> >  >  room, to registration with the service.
> >  >
> >
> >  Good question... the problem I see is that all this is very
> >  implementation dependent. ejabberd at least doesn't allow you to
> >  register a nick in a room, and it isn't explicitly specified in the
> >  XEP (which says the server can send a data form).
> >
> >  If you are a room member, this is visible already anyway, so I am
> >  edging towards registration with the whole service (unless we
> >  implemented both).
>
>Yes I think that makes sense.
>
> >  >  > The reason I believe this is needed is because the lack of it makes nick
> >  >  > registration fairly useless in anonymous rooms. If someone can see
> >  >  > that a user's nick is registered, they have a certain level of
> >  >  > assurance that the next time they see this nick, it is the same
> >  >  > person. Without this knowledge it may as well be someone completely
> >  >  > different.
> >  >  >
> >  >  > Currently I don't believe there is any way to tell, which means that
> >  >  > even if you register your nick on a service, it provides little
> >  >  > benefit (unlike it would on IRC/NickServ).
> >  >
> >  >  The only way to tell is by trying to register the nick yourself. And
> >  >  that seems rather silly. :)
> >  >
> >
> >  Ah yes, there is that (a method I have used before, and even
> >  considered adding to HAL as a hacky workaround).
>
>HAL knows all...
>
> >  >  I see two approaches:
> >  >
> >  >  1. If someone is registered, the service includes a flag in their
> >  >  presence broadcast -- something like the following:
> >  >
> >  >  <presence
> >  >     from='darkcave at macbeth.shakespeare.lit/thirdwitch'
> >  >     to='crone1 at shakespeare.lit/desktop'>
> >  >   <x xmlns='http://jabber.org/protocol/muc#user'>
> >  >     <item affiliation='member' role='participant'/>
> >  >   </x>
> >  >   <registered xmlns='urn:xmpp:mucserv'/>
> >  >  </presence>
> >  >
> >
> >  Seems ok...
> >
> >  >  2. The service enables you to check if someone is registered:
> >  >
> >  >  <iq from='crone1 at shakespeare.lit/desktop'
> >  >     id='check-nick-1'
> >  >     to='macbeth.shakespeare.lit'
> >  >     type='get'>
> >  >   <registered xmlns='urn:xmpp:mucserv'>
> >  >     thirdwitch
> >  >   </registered>
> >  >  </iq>
> >  >
> >  >  If the nick is registered, the service returns an IQ-result, otherwise
> >  >  it returns an error (<item-not-found/> if the nick is not registered,
> >  >  <service-unavailable/> if the protocol is not supported):
> >  >
> >  >  <iq from='macbeth.shakespeare.lit'
> >  >     id='check-nick-1'
> >  >     to='crone1 at shakespeare.lit/desktop'
> >  >     type='result'/>
> >  >
> >  >  OR
> >  >
> >  >  <iq from='macbeth.shakespeare.lit'
> >  >     id='check-nick-1'
> >  >     to='crone1 at shakespeare.lit/desktop'
> >  >     type='error'>
> >  >   <error type='cancel'>
> >  >     <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
> >  >   </error>
> >  >  </iq>
> >  >
> >  >
> >
> >  Also ok...
> >
> >  I'm wondering which would be more convenient from a client UI perspective.
> >
> >  A new element in presence is a new overhead, but if you want to know
> >  up-front who is registered, we don't want clients to have to query
> >  each user in every MUC they join.
> >
> >  In my use case I don't mind querying (I only want to know about people
> >  I interact with) and the same for HAL's use case (checking that the
> >  user is the same person, when he isn't in a position to know their
> >  JID).
>
>If we don't include it in presence, clients will query everyone. I think
>I'd prefer the presence flag.
>
>Peter
>
>--
>Peter Saint-Andre
>https://stpeter.im/
>


  -- kawaljeet singh chadha

Here is the test to find whether your mission on Earth is finished: if you're alive, it isn't ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080415/91da4946/attachment.html>


More information about the Standards mailing list