Entity
Click on the red underlined text to get to the source
... jabber:server'
namespace are used to "push" information to another entity. Common
uses in instant messaging applications include single messages,
...
... "normal" is the default). The "error" type MUST be generated only in
response to an error related to a message received from another
entity.
Although the 'type' attribute is OPTIONAL, it is considered polite to
...
... 'jabber:server' namespace to express an entity's current network
availability (offline or online, along with various sub-states of the
...
... sender is online and available for communication.
If included, the 'type' attribute specifies a lack of availability, a
request to manage a subscription to another entity's presence, a
request for another entity's current presence, or an error related to
...
... request to manage a subscription to another entity's presence, a
request for another entity's current presence, or an error related to
a previously-sent presence stanza. If included, the 'type' attribute
...
...
o unavailable -- Signals that the entity is no longer available for
communication.
...
...
o probe -- A request for an entity's current presence; SHOULD be
generated only by a server on behalf of a user.
...
... human-readable XML
character data that specifies the particular availability status of
an entity or specific resource. A presence stanza MUST NOT contain
more than one <show/> element ...
... presence stanza):
o away -- The entity or resource is temporarily away.
o chat -- The entity ...
... entity or resource is temporarily away.
o chat -- The entity or resource is actively interested in chatting.
o dnd -- The entity ...
... entity or resource is actively interested in chatting.
o dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
o xa -- The entity ...
... entity or resource is busy (dnd = "Do Not Disturb").
o xa -- The entity or resource is away for an extended period (xa =
"eXtended Away").
...
... any implementation (aside from the extended namespaces defined
herein). If an entity does not understand such a namespace, the
entity ...
... entity does not understand such a namespace, the
entity's expected behavior depends on whether the entity is (1) the
recipient or (2) an entity ...
... namespace, the
entity's expected behavior depends on whether the entity is (1) the
recipient or (2) an entity that is routing ...
... entity's expected behavior depends on whether the entity is (1) the
recipient or (2) an entity that is routing the stanza to the
...
... associated application (if any). In particular:
* If an entity receives a message or presence stanza that
contains XML data ...
... namespace SHOULD be ignored.
* If an entity receives a message stanza whose only child element
...
... stanza.
* If an entity receives an IQ stanza of type "get" or "set"
containing a child element ...
... element qualified by a namespace it does not
understand, the entity SHOULD return an IQ stanza of type
"error" with an error condition ...
... Router: If a routing entity (usually a server) handles a stanza that
contains a child element ...
... address is of the form <user@domain/resource>, after which the
entity is now said to be a "connected resource" in the
terminology of [XMPP-CORE].
...
... a user generates a message stanza that is addressed to another
entity. As defined under Server Rules for Handling XML Stanzas
(Section 11), the sender ...
... client SHOULD specify an intended recipient for
a message by providing the JID of an entity other than the sender in
the 'to' attribute of the <message/> stanza ...
... client MAY send
directed presence information to another entity by including a 'to'
address, normally presence notifications ...
... broadcasted by the server to any
entities that are subscribed to the presence of the sending entity
(in the terminology of RFC 2778 [IMP-MODEL ...
... service, it MAY provide presence information about the user to
that entity). Specifically:
* if the user is in the contact's roster with a subscription
...
...
A user MAY send directed presence to another entity (i.e., a presence
stanza with a 'to' attribute whose value is the JID of the other
...
... presence
stanza with a 'to' attribute whose value is the JID of the other
entity and with either no 'type' attribute or a 'type' attribute
whose value is "unavailable"). There are three possible cases:
...
...
2. If the user sends directed presence to an entity that is not in
the user's roster with a subscription type of "from" or "both"
after having sent initial presence and before sending unavailable
presence ...
... full XML of that presence stanza to the entity but MUST NOT
modify the contact's status regarding available presence
broadcast (i.e., it MUST NOT include the entity ...
... entity but MUST NOT
modify the contact's status regarding available presence
broadcast (i.e., it MUST NOT include the entity's JID in any
subsequent broadcasts ...
... MUST broadcast that unavailable presence to the entity (if the
user has not yet sent directed unavailable presence to that
...
... user has not yet sent directed unavailable presence to that
entity).
3. If the user sends directed presence ...
... 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
...
... other entities, presence and availability information is disclosed
only to other entities that the user has approved. When a user has
agreed that another entity may view its presence, the entity is said
to have a subscription to the user's presence information. A
...
... only to other entities that the user has approved. When a user has
agreed that another entity may view its presence, the entity is said
to have a subscription to the user's presence information. A
subscription lasts across sessions ...
...
A request to subscribe to another entity's presence is made by
sending a presence stanza of type "subscribe ...
... When a client receives a subscription request from another entity, it
MUST either approve the request by sending a presence stanza of type
...
... Cancelling a Subscription from Another Entity ...
... Unsubscribing from Another Entity's Presence ...
... If a user would like to unsubscribe from the presence of another
entity, it sends a presence stanza of type "unsubscribe".
...
...
Example: Unsubscribing from an entity's presence:
<presence to='juliet@example.com' type='unsubscribe ...
... 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 ...
... <default/> element, or one <list/> element); if a sending entity
violates this rule, the receiving entity ...
...
In this example, the user has three lists: (1) 'public', which allows
communications from everyone except one specific entity (this is the
default list); (2) 'private', which allows communications only with
...
... Server-side privacy lists enable a user to block incoming messages
from other entities based on the entity's JID, roster group, or
...
...
As a result of creating and applying the foregoing list, the user
will not receive messages from the entity with the specified JID.
...
... privacy lists enable a user to block incoming presence
notifications from other entities based on the entity's JID, roster
group ...
... As a result of creating and applying the foregoing list, the user
will not receive presence notifications from the entity with the
specified JID.
...
... privacy lists enable a user to block outgoing presence
notifications to other entities based on the entity's JID, roster
group ...
... As a result of creating and applying the foregoing list, the user
will not send presence notifications to the entity with the specified
JID.
...
... privacy lists enable a user to block incoming IQ stanzas
from other entities based on the entity's JID, roster group, or
...
... As a result of creating and applying the foregoing list, the user
will not receive IQ stanzas from the entity with the specified JID.
...
... privacy lists enable a user to block all stanzas from and
to other entities based on the entity's JID, roster group, or
...
... will not receive any communications from, nor send any stanzas to,
the entity with the specified JID.
...
... 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 ...
... the user, the user's server SHOULD silently drop the stanza and MUST
NOT return an error to the sending entity.
If a blocked entity ...
... entity.
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
...
... stanza of type "get" or
"set" to the user, the user's server MUST return to the sending
entity a <service-unavailable/> stanza ...
... by the server.
Example: Blocked entity attempts to send IQ get:
<iq type='get'
...
... </iq>
Example: Server returns error to blocked entity:
<iq type='error'
...
... hostname of the server itself, the server MUST deliver the stanza to
a local entity according the rules for Inbound Stanzas (Section
11.1).
...
... server's hostnames, the server MUST NOT reveal the user's presence
information if the sender is an entity that is not authorized to
receive that information as determined by presence subscriptions
...