📄 draft-ietf-xmpp-im-21.txt
字号:
If the server encounters an internal condition that prevents it from
creating the session, it MUST return an error.
Step 2 (alt): Server responds with error (internal server error):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='wait'>
<internal-server-error
Saint-Andre (ed.) Expires September 19, 2004 [Page 12]
Internet-Draft XMPP IM March 2004
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If the username or resource is not allowed to create a session, the
server MUST return an error (e.g., forbidden).
Step 2 (alt): Server responds with error (username or resource not
allowed to create session):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='auth'>
<forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If there is already an active resource of the same name, the server
MUST either (1) terminate the active resource and allow the
newly-requested session, or (2) disallow the newly-requested session
and maintain the active resource. Which of these the server does is
up to the implementation, although it is RECOMMENDED to implement
case #1. In case #1, the server SHOULD send a <conflict/> stream
error to the active resource, terminate the XML stream and underlying
TCP connection for the active resource, and return a IQ stanza of
type "result" (indicating success) to the newly-requested session.
In case #2, the server SHOULD send a <conflict/> stanza error to the
newly-requested session but maintain the XML stream for that
connection so that the newly-requested session has an opportunity to
negotiate a non-conflicting resource identifier before sending
another request for session establishment.
Step 2 (alt): Server informs existing active resource of resource
conflict (case #1):
<stream:error>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
Step 2 (alt): Server informs newly-requested session of resource
conflict (case #2):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
Saint-Andre (ed.) Expires September 19, 2004 [Page 13]
Internet-Draft XMPP IM March 2004
</error>
</iq>
After establishing a session, a client SHOULD send initial presence
and request its roster as described below, although these actions are
OPTIONAL.
Note: Before allowing the creation of instant messaging and presence
sessions, a server MAY require prior account provisioning. Possible
methods for account provisioning include account creation by a server
administrator as well as in-band account registration using the
'jabber:iq:register' namespace; the latter method is documented by
the Jabber Software Foundation [JSF] at <http://www.jabber.org/
protocol/> but is out of scope for this memo.
4. Exchanging Messages
Exchanging messages is a basic use of XMPP and is brought about when
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's server is responsible for delivering the
message to the intended recipient (if the recipient is on the same
server) or for routing the message to the recipient's server (if the
recipient is on a different server).
For information regarding the syntax of message stanzas as well as
their defined attributes and child elements, refer to Message Syntax
(Section 2.1).
4.1 Specifying an Intended Recipient
An instant messaging 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. If the message is being
sent in reply to a message previously received from an address of the
form <user@domain/resource> (e.g., within the context of a chat
session), the value of the 'to' address SHOULD be of the form
<user@domain/resource> rather than of the form <user@domain> unless
the sender has knowledge (via presence) that the intended recipient's
resource is no longer available. If the message is being sent
outside the context of any existing chat session or received message,
the value of the 'to' address SHOULD be of the form <user@domain>
rather than of the form <user@domain/resource>.
4.2 Specifying a Message Type
As noted, it is RECOMMENDED for a message stanza to possess a 'type'
attribute whose value captures the conversational context (if any) of
Saint-Andre (ed.) Expires September 19, 2004 [Page 14]
Internet-Draft XMPP IM March 2004
the message (see Type (Section 2.1.1)).
The following example shows a valid value of the 'type' attribute:
Example: A message of a defined type:
<message
to='romeo@example.net'
from='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
</message>
4.3 Specifying a Message Body
A message stanza MAY (and often will) contain a child <body/> element
whose XML character data specifies the primary meaning of the message
(see Body (Section 2.1.2.2)).
Example: A message with a body:
<message
to='romeo@example.net'
from='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cz'>PročeŽ jsi ty, Romeo?</body>
</message>
4.4 Specifying a Message Subject
A message stanza MAY contain one or more child <subject/> elements
specifying the topic of the message (see Subject (Section 2.1.2.1)).
Example: A message with a subject:
<message
to='romeo@example.net'
from='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<subject
xml:lang='cz'>Úpěnlivě prosim!</subject>
Saint-Andre (ed.) Expires September 19, 2004 [Page 15]
Internet-Draft XMPP IM March 2004
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cz'>PročeŽ jsi ty, Romeo?</body>
</message>
4.5 Specifying a Conversation Thread
A message stanza MAY contain a child <thread/> element specifying the
conversation thread in which the message is situated, for the purpose
of tracking the conversation (see Thread (Section 2.1.2.3)).
Example: A threaded conversation:
<message
to='romeo@example.net/orchard'
from='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
<message
to='juliet@example.com/balcony'
from='romeo@example.net/orchard'
type='chat'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
<message
to='romeo@example.net/orchard'
from='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>How cam'st thou hither, tell me, and wherefore?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
5. Exchanging Presence Information
Exchanging presence information is made relatively straightforward
within XMPP by using presence stanzas. However, we see here a
contrast to the handling of messages: although a client MAY send
directed presence information to another entity by including a 'to'
address, normally presence notifications (i.e., presence stanzas of
Saint-Andre (ed.) Expires September 19, 2004 [Page 16]
Internet-Draft XMPP IM March 2004
type "available" and "unavailable" with no 'to' address) are sent
from a client to its server and then 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], these entities are
subscribers). This broadcast model does not apply to
subscription-related presence stanzas or presence stanzas of type
"error", but to presence notifications only as defined above. (Note:
While presence information MAY be provided on a user's behalf by an
automated service, normally it is provided by the user's client.)
For information regarding the syntax of presence stanzas as well as
their defined attributes and child elements, refer to [XMPP-CORE].
5.1 Client and Server Presence Responsibilities
5.1.1 Initial Presence
After establishing a session, a client SHOULD send initial presence
to the server in order to signal its availability for communications.
As defined herein, the initial presence stanza (1) MUST possess no
'to' address (signalling that it is meant to be broadcasted by the
server on behalf of the client) and (2) MUST possess no 'type'
attribute (signalling the user's availability). After sending
initial presence, an active resource is said to be an "available
resource".
Upon receiving initial presence from a client, the user's server MUST
do the following if there is not already one or more available
resources for the user (if there is already one or more available
resources for the user, the server obviously does not need to send
the presence probes, since it already possesses the requisite
information):
1. Send presence probes (i.e., 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
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
presence probes to contacts from which the user is blocking
inbound presence notifications, as described under Blocking
Inbound Presence Notifications (Section 10.10).)
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
those for which a JID is present in the user's roster with the
Saint-Andre (ed.) Expires September 19, 2004 [Page 17]
Internet-Draft XMPP IM March 2004
'subscription' attribute set to a value of "from" or "both".
(Note: The user's server MUST NOT broadcast initial presence to
contacts to which the user is blocking outbound presence
notifications, as described under Blocking Outbound Presence
Notifications (Section 10.11).)
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
After sending initial presence, the user MAY update its presence
information for broadcasting at any time during its session by
sending a presence stanza with no 'to' address and either no 'type'
attribute or a 'type' attribute with a value of "unavailable".
(Note: A user's client SHOULD NOT send a presence update to broadcast
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -