JID
Click on the red underlined text to get to the source
... and MUST be consistent throughout that conversation (a client that
receives a message from the same full JID but with a different thread
ID MUST assume that the message in question exists outside the
context ...
... instant messaging client SHOULD specify an intended recipient for
a message by providing the JID of an entity other than the sender in
...
... presence stanzas whose 'type'
attribute is set to a value of "probe") from the full JID (e.g.,
<user@example.com/resource>) of the user to all contacts to which
the user is subscribed in order to determine if they are
...
... <user@example.com/resource>) of the user to all contacts to which
the user is subscribed in order to determine if they are
available; such contacts are those for which a JID is present in
the user's roster with the 'subscription' attribute set to a
value of "to" or "both". (Note: The user's server MUST NOT send
...
...
2. Broadcast initial presence from the full JID (e.g.,
<user@example.com/resource>) of the user to all contacts that are
subscribed to the user's presence information; such contacts are
...
... <user@example.com/resource>) of the user to all contacts that are
subscribed to the user's presence information; such contacts are
those for which a JID is present in the user's roster with the
'subscription' attribute set to a value of "from" or "both".
(Note: The user's server MUST NOT broadcast ...
... 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
...
... blocked inbound presence notifications from the user's bare or full
JID (as defined under Blocking Inbound Presence Notifications
(Section 10.10)).
...
... 2. Else, if the contact is blocking presence notifications to the
user's bare JID or full JID (using either a default list or
...
... notifications to the
user's bare JID or full JID (using either a default list or
active list ...
... directed presence to another entity (i.e., a 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
...
... SHOULD NOT otherwise modify the contact's status regarding
presence broadcast (i.e., it SHOULD include the contact's JID in
any subsequent presence broadcasts initiated by the user ...
... modify the contact's status regarding available presence
broadcast (i.e., it MUST NOT include the entity's JID in any
subsequent broadcasts of available presence initiated by the
user ...
... subscription request is being
sent to an instant messaging contact, the JID supplied in the 'to'
attribute SHOULD be of the form <contact@example.org> rather than
<contact@example.org/resource>, since the desired result is normally
...
... roster items, each roster item being identified by
a unique JID (usually of the form <contact@domain>). A user's roster
is stored by the user ...
... The "key" or unique identifier for each roster item is a JID,
encapsulated in the 'jid' attribute of the <item/> element ...
... Each <item/> element MAY contain a 'name' attribute, which sets the
"nickname" to be associated with the JID, as determined by the user
(not the contact). The value of the 'name' attribute is opaque ...
... stanza MUST either have no 'from'
attribute (i.e., implicitly from the server) or have a 'from'
attribute whose value matches the user's bare JID (of the form
<user@domain>) or full JID ...
... JID (of the form
<user@domain>) or full JID (of the form <user@domain/resource>);
otherwise, the client ...
... The 'from' and 'to' addresses are OPTIONAL in roster pushes; if
included, their values SHOULD be the full JID of the resource for
that session. A client ...
... presence stanza of type
"subscribe" with the user's bare JID (i.e., <user@example.com>)
as the 'from' address (if the user provided a 'from' address ...
... address (if the user provided a 'from' address set
to the user's full JID, the server SHOULD remove the resource
identifier). If the contact is served by a different host ...
... type "subscribed" to the user, first stamping the 'from' address
as the bare JID (<contact@example.org>) of the contact; and (4)
MUST send available presence from all of the contact's available
resources to the user:
...
... unsubscribed" to the user, first stamping the 'from'
address as the bare JID (<contact@example.org>) of the contact:
<presence
...
... subscribe"
to the user, first stamping the 'from' address as the bare JID
(<contact@example.org>) of the contact:
...
... presence stanza of type "subscribed" to the contact, first
stamping the 'from' address as the bare JID (<user@example.com>)
of the user; and (3) MUST send to the contact the full XML of the
...
... unsubscribed" to the contact, first stamping the 'from'
address as the bare JID (<user@example.com>) of the user:
<presence
...
... unsubscribe" to the contact,
first stamping the 'from' address as the bare JID
(<user@example.com>) of the user:
...
... unsubscribe" to the contact,
first stamping the 'from' address as the bare JID
(<user@example.com>) of the user:
...
... unsubscribed" to the user, first
stamping the 'from' address as the bare JID
(<contact@example.org>) of the contact; and (3) SHOULD send
unavailable presence ...
... unsubscribed" to the user, first
stamping the 'from' address as the bare JID
(<contact@example.org>) of the contact; and (3) SHOULD send
unavailable presence ...
...
o Allowing or blocking inbound presence notifications based on JID,
group, or subscription type (or globally).
...
...
o Allowing or blocking outbound presence notifications based on JID,
group, or subscription type (or globally).
...
... subscription type (or globally).
o Allowing or blocking all communications based on JID, group, or
subscription type (or globally).
...
... privacy lists enable a user to block incoming messages
from other entities based on the entity's JID, roster group, or
subscription status (or globally). The following examples illustrate
...
... privacy
list pushes".)
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='msg1'>
...
... As a result of creating and applying the foregoing list, the user
will not receive messages from the entity with the specified JID.
Example: User blocks based on roster group ...
... notifications from other entities based on the entity's JID, roster
group, or subscription status (or globally). The following examples
...
... unavailable' only.
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='presin1'>
...
... notifications from the entity with the
specified JID.
Example: User blocks based on roster group ...
... notifications to other entities based on the entity's JID, roster
group, or subscription status (or globally). The following examples
...
... unavailable' only.
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='presout1'>
...
... notifications to the entity with the specified
JID.
Example: User blocks based on roster group ...
... IQ stanzas
from other entities based on the entity's JID, roster group, or
subscription status (or globally). The following examples illustrate
...
... the protocol.
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='iq1'>
...
... will not receive IQ stanzas from the entity with the specified JID.
Example: User blocks based on roster group ...
... stanzas from and
to other entities based on the entity's JID, roster group, or
subscription status (or globally). Note that this includes
...
... examples illustrate the protocol.
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='all1'>
...
... not in my roster" could be constructed in any of the following ways:
o allow communications from all JIDs in my roster (i.e., listing
each JID as a separate list item), but block communications with
...
... o allow communications from all JIDs in my roster (i.e., listing
each JID as a separate list item), but block communications with
everyone else
...
...
If the hostname of the domain identifier portion of the JID contained
in the 'to' attribute of an inbound stanza matches a hostname of the
...
... in the 'to' attribute of an inbound stanza matches a hostname of the
server itself and the JID contained in the 'to' attribute is of the
form <user@example.com> or <user@example.com/resource>, the server
MUST first apply any privacy lists ...
... then follow the rules defined below:
1. If the JID is of the form <user@domain/resource> and an available
resource matches the full JID ...
... JID is of the form <user@domain/resource> and an available
resource matches the full JID, the recipient's server MUST
deliver the stanza to that resource.
...
... stanza.
3. Else if the JID is of the form <user@domain/resource> and no
available resource matches the full JID ...
... JID is of the form <user@domain/resource> and no
available resource matches the full JID, the recipient's server
(a) SHOULD silently ignore the stanza (i.e., neither deliver it
...
... stanza.
4. Else if the JID is of the form <user@domain> and there is at
least one available resource available for the user, the
...
... stanza error.
5. Else if the JID is of the form <user@domain> and there are no
available resources associated with the user, how the stanza ...