DJabberd

 view release on metacpan or  search on metacpan

doc/rfc3921-notes.txt  view on Meta::CPAN

   In addition, the user's server MUST broadcast initial presence from
   the user's new available resource to any of the user's existing
   available resources (if any).

   Upon receiving initial presence from the user, the contact's server
   MUST deliver the user's presence stanza to the full JIDs
   (<contact@example.org/resource>) associated with all of the contact's
   available resources, but only if the user is in the contact's roster
   with a subscription state of "to" or "both" and the contact has not
   blocked inbound presence notifications from the user's bare or full
   JID (as defined under Blocking Inbound Presence Notifications
   (Section 10.10)).

   If the user's server receives a presence stanza of type "error" in
   response to the initial presence that it sent to a contact on behalf
   of the user, it SHOULD NOT send further presence updates to that
   contact (until and unless it receives a presence stanza from the
   contact).

5.1.2.  Presence Broadcast

doc/rfc3921-notes.txt  view on Meta::CPAN

Saint-Andre                 Standards Track                    [Page 17]

RFC 3921                        XMPP IM                     October 2004


   has not blocked outbound presence notifications, and (3) from whom
   the server has not received a presence error during the user's
   session (as well as to any of the user's other available resources).

   If the presence stanza has a 'type' attribute set to a value of
   "unavailable", the user's server MUST broadcast the full XML of that
   presence stanza to all entities that fit the above description, as
   well as to any entities to which the user has sent directed available
   presence during the user's session (if the user has not yet sent
   directed unavailable presence to that entity).

doc/rfc3921-notes.txt  view on Meta::CPAN

   no 'to' attribute and that possesses a 'type' attribute whose value
   is "unavailable" (optionally, the final presence stanza MAY contain
   one or more <status/> elements specifying the reason why the user is
   no longer available).  However, the user's server MUST NOT depend on
   receiving final presence from an available resource, since the
   resource may become unavailable unexpectedly or may be timed out by
   the server.  If one of the user's resources becomes unavailable for
   any reason (either gracefully or ungracefully), the user's server
   MUST broadcast unavailable presence to all contacts (1) that are in
   the user's roster with a subscription type of "from" or "both", (2)
   to whom the user has not blocked outbound presence, and (3) from whom
   the server has not received a presence error during the user's
   session; the user's server MUST also send that unavailable presence
   stanza to any of the user's other available resources, as well as to
   any entities to which the user has sent directed presence during the
   user's session for that resource (if the user has not yet sent
   directed unavailable presence to that entity).  Any presence stanza
   with no 'type' attribute and no 'to' attribute that is sent after
   sending directed unavailable presence or broadcasted unavailable
   presence MUST be broadcasted by the server to all subscribers.

doc/rfc3921-notes.txt  view on Meta::CPAN

   "allow" or "deny".

   The 'order' attribute MUST be included and its value MUST be a
   non-negative integer that is unique among all items in the list.  (If
   a client attempts to create or update a list with non-unique order
   values, the server MUST return to the client a <bad-request/> stanza
   error.)

   The <item/> element MAY contain one or more child elements that
   enable an entity to specify more granular control over which kinds of
   stanzas are to be blocked (i.e., rather than blocking all stanzas).
   The allowable child elements are:

   o  <message/> -- blocks incoming message stanzas
   o  <iq/> -- blocks incoming IQ stanzas
   o  <presence-in/> -- blocks incoming presence notifications
   o  <presence-out/> -- blocks outgoing presence notifications

doc/rfc3921-notes.txt  view on Meta::CPAN

       <list name='all-global-example'>
         <item action='deny' order='7'/>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive any communications from, nor send any stanzas to,
   any other users.

10.14.  Blocked Entity Attempts to Communicate with User

   If a blocked entity attempts to send message or presence stanzas to
   the user, the user's server SHOULD silently drop the stanza and MUST
   NOT return an error to the sending entity.





Saint-Andre                 Standards Track                    [Page 83]

RFC 3921                        XMPP IM                     October 2004


   If a blocked entity attempts to send an IQ stanza of type "get" or
   "set" to the user, the user's server MUST return to the sending
   entity a <service-unavailable/> stanza error, since this is the
   standard error code sent from a client that does not understand the
   namespace of an IQ get or set.  IQ stanzas of other types SHOULD be
   silently dropped by the server.

   Example: Blocked entity attempts to send IQ get:

   <iq type='get'
       to='romeo@example.net'
       from='tybalt@example.com/pda'
       id='probing1'>
     <query xmlns='jabber:iq:version'/>
   </iq>

   Example: Server returns error to blocked entity:

   <iq type='error'
       from='romeo@example.net'
       to='tybalt@example.com/pda'
       id='probing1'>
     <query xmlns='jabber:iq:version'/>
     <error type='cancel'>
       <service-unavailable
           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>

doc/rfc3921.txt  view on Meta::CPAN

   In addition, the user's server MUST broadcast initial presence from
   the user's new available resource to any of the user's existing
   available resources (if any).

   Upon receiving initial presence from the user, the contact's server
   MUST deliver the user's presence stanza to the full JIDs
   (<contact@example.org/resource>) associated with all of the contact's
   available resources, but only if the user is in the contact's roster
   with a subscription state of "to" or "both" and the contact has not
   blocked inbound presence notifications from the user's bare or full
   JID (as defined under Blocking Inbound Presence Notifications
   (Section 10.10)).

   If the user's server receives a presence stanza of type "error" in
   response to the initial presence that it sent to a contact on behalf
   of the user, it SHOULD NOT send further presence updates to that
   contact (until and unless it receives a presence stanza from the
   contact).

5.1.2.  Presence Broadcast

doc/rfc3921.txt  view on Meta::CPAN

Saint-Andre                 Standards Track                    [Page 17]

RFC 3921                        XMPP IM                     October 2004


   has not blocked outbound presence notifications, and (3) from whom
   the server has not received a presence error during the user's
   session (as well as to any of the user's other available resources).

   If the presence stanza has a 'type' attribute set to a value of
   "unavailable", the user's server MUST broadcast the full XML of that
   presence stanza to all entities that fit the above description, as
   well as to any entities to which the user has sent directed available
   presence during the user's session (if the user has not yet sent
   directed unavailable presence to that entity).

doc/rfc3921.txt  view on Meta::CPAN

   no 'to' attribute and that possesses a 'type' attribute whose value
   is "unavailable" (optionally, the final presence stanza MAY contain
   one or more <status/> elements specifying the reason why the user is
   no longer available).  However, the user's server MUST NOT depend on
   receiving final presence from an available resource, since the
   resource may become unavailable unexpectedly or may be timed out by
   the server.  If one of the user's resources becomes unavailable for
   any reason (either gracefully or ungracefully), the user's server
   MUST broadcast unavailable presence to all contacts (1) that are in
   the user's roster with a subscription type of "from" or "both", (2)
   to whom the user has not blocked outbound presence, and (3) from whom
   the server has not received a presence error during the user's
   session; the user's server MUST also send that unavailable presence
   stanza to any of the user's other available resources, as well as to
   any entities to which the user has sent directed presence during the
   user's session for that resource (if the user has not yet sent
   directed unavailable presence to that entity).  Any presence stanza
   with no 'type' attribute and no 'to' attribute that is sent after
   sending directed unavailable presence or broadcasted unavailable
   presence MUST be broadcasted by the server to all subscribers.

doc/rfc3921.txt  view on Meta::CPAN

   "allow" or "deny".

   The 'order' attribute MUST be included and its value MUST be a
   non-negative integer that is unique among all items in the list.  (If
   a client attempts to create or update a list with non-unique order
   values, the server MUST return to the client a <bad-request/> stanza
   error.)

   The <item/> element MAY contain one or more child elements that
   enable an entity to specify more granular control over which kinds of
   stanzas are to be blocked (i.e., rather than blocking all stanzas).
   The allowable child elements are:

   o  <message/> -- blocks incoming message stanzas
   o  <iq/> -- blocks incoming IQ stanzas
   o  <presence-in/> -- blocks incoming presence notifications
   o  <presence-out/> -- blocks outgoing presence notifications

doc/rfc3921.txt  view on Meta::CPAN

       <list name='all-global-example'>
         <item action='deny' order='7'/>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive any communications from, nor send any stanzas to,
   any other users.

10.14.  Blocked Entity Attempts to Communicate with User

   If a blocked entity attempts to send message or presence stanzas to
   the user, the user's server SHOULD silently drop the stanza and MUST
   NOT return an error to the sending entity.





Saint-Andre                 Standards Track                    [Page 83]

RFC 3921                        XMPP IM                     October 2004


   If a blocked entity attempts to send an IQ stanza of type "get" or
   "set" to the user, the user's server MUST return to the sending
   entity a <service-unavailable/> stanza error, since this is the
   standard error code sent from a client that does not understand the
   namespace of an IQ get or set.  IQ stanzas of other types SHOULD be
   silently dropped by the server.

   Example: Blocked entity attempts to send IQ get:

   <iq type='get'
       to='romeo@example.net'
       from='tybalt@example.com/pda'
       id='probing1'>
     <query xmlns='jabber:iq:version'/>
   </iq>

   Example: Server returns error to blocked entity:

   <iq type='error'
       from='romeo@example.net'
       to='tybalt@example.com/pda'
       id='probing1'>
     <query xmlns='jabber:iq:version'/>
     <error type='cancel'>
       <service-unavailable
           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>