Movatterモバイル変換
[0]ホーム
Art thou not Romeo, and a Montague? If the message is being sent in reply to a message previously received from an address of the form (e.g., within the context of a one-to-one chat session as described under Section 5.1), the value of the 'to' address SHOULD be of the form rather than of the form unless the sender has knowledge (e.g., via presence) that the intended recipient's resource is no longer available. Neither, fair saint, if either thee dislike.5.2.2. Type Attribute Common uses of the message stanza in instant messaging applications include: single messages; messages sent in the context of a one-to- one chat session; messages sent in the context of a multi-user chat room; alerts, notifications, or other information to which no reply is expected; and errors. These uses are differentiated via the 'type' attribute. Inclusion of the 'type' attribute is RECOMMENDED. If included, the 'type' attribute MUST have one of the following values:Saint-Andre Standards Track [Page 71] RFC 6121 XMPP IM March 2011 o chat -- The message is sent in the context of a one-to-one chat session. Typically an interactive client will present a message of type "chat" in an interface that enables one-to-one chat between the two parties, including an appropriate conversation history. Detailed recommendations regarding one-to-one chat sessions are provided under Section 5.1. o error -- The message is generated by an entity that experiences an error when processing a message received from another entity (for details regarding stanza error syntax, refer to [XMPP-CORE]). A client that receives a message of type "error" SHOULD present an appropriate interface informing the original sender regarding the nature of the error. o groupchat -- The message is sent in the context of a multi-user chat environment (similar to that of [IRC]). Typically a receiving client will present a message of type "groupchat" in an interface that enables many-to-many chat between the parties, including a roster of parties in the chatroom and an appropriate conversation history. For detailed information about XMPP-based groupchat, refer to [XEP-0045]. o headline -- The message provides an alert, a notification, or other transient information to which no reply is expected (e.g., news headlines, sports updates, near-real-time market data, or syndicated content). Because no reply to the message is expected, typically a receiving client will present a message of type "headline" in an interface that appropriately differentiates the message from standalone messages, chat messages, and groupchat messages (e.g., by not providing the recipient with the ability to reply). If the 'to' address is the bare JID, the receiving server SHOULD deliver the message to all of the recipient's available resources with non-negative presence priority and MUST deliver the message to at least one of those resources; if the 'to' address is a full JID and there is a matching resource, the server MUST deliver the message to that resource; otherwise the server MUST either silently ignore the message or return an error (see Section 8). o normal -- The message is a standalone message that is sent outside the context of a one-to-one conversation or groupchat, and to which it is expected that the recipient will reply. Typically a receiving client will present a message of type "normal" in an interface that enables the recipient to reply, but without a conversation history. The default value of the 'type' attribute is "normal".Saint-Andre Standards Track [Page 72] RFC 6121 XMPP IM March 2011 An IM application SHOULD support all of the foregoing message types. If an application receives a message with no 'type' attribute or the application does not understand the value of the 'type' attribute provided, it MUST consider the message to be of type "normal" (i.e., "normal" is the default). Guidelines for server handling of different message types is provided under Section 8. Although the 'type' attribute is OPTIONAL, it is considered polite to mirror the type in any replies to a message; furthermore, some specialized applications (e.g., a multi-user chat service) MAY at their discretion enforce the use of a particular message type (e.g., type='groupchat').5.2.3. Body Element The element contains human-readable XML character data that specifies the textual contents of the message; this child element is normally included but is OPTIONAL. Wherefore art thou, Romeo? There are no attributes defined for the element, with the exception of the 'xml:lang' attribute. Multiple instances of the element MAY be included in a message stanza for the purpose of providing alternate versions of the same body, but only if each instance possesses an 'xml:lang' attribute with a distinct language value (either explicitly or by inheritance from the 'xml:lang' value of an element farther up in the XML hierarchy, which from the sender's perspective can include the XML stream header as described in [XMPP-CORE]).Saint-Andre Standards Track [Page 73] RFC 6121 XMPP IM March 2011 Wherefore art thou, Romeo? PročeŽ jsi ty, Romeo? The element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).5.2.4. Subject Element The element contains human-readable XML character data that specifies the topic of the message.I implore you! Wherefore art thou, Romeo? There are no attributes defined for the element, with the exception of the 'xml:lang' attribute inherited from [XML]. Multiple instances of the element MAY be included for the purpose of providing alternate versions of the same subject, but only if each instance possesses an 'xml:lang' attribute with a distinct language value (either explicitly or by inheritance from the 'xml:lang' value of an element farther up in the XML hierarchy, which from the sender's perspective can include the XML stream header as described in [XMPP-CORE]).Saint-Andre Standards Track [Page 74] RFC 6121 XMPP IM March 2011I implore you! Úpěnlivě prosím! Wherefore art thou, Romeo? Pročež jsi ty, Romeo? The element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).5.2.5. Thread Element The primary use of the XMPP element is to uniquely identify a conversation thread or "chat session" between two entities instantiated by stanzas of type 'chat'. However, the XMPP element MAY also be used to uniquely identify an analogous thread between two entities instantiated by stanzas of type 'headline' or 'normal', or among multiple entities in the context of a multi-user chat room instantiated by stanzas of type 'groupchat'. It MAY also be used for stanzas not related to a human conversation, such as a game session or an interaction between plugins. The element is not used to identify individual messages, only conversations or messaging sessions. The inclusion of the element is OPTIONAL. Because the element identifies the particular conversation thread to which a message belongs, a message stanza MUST NOT contain more than one element. The element MAY possess a 'parent' attribute that identifies another thread of which the current thread is an offshoot or child. The 'parent' attribute MUST conform to the syntax of the element itself and its value MUST be different from the XML character data of the element on which the 'parent' attribute is included.Saint-Andre Standards Track [Page 75] RFC 6121 XMPP IM March 2011 Implementation Note: The ability to specify both a parent thread and a child thread introduces the possibility of conflicts between thread identifiers for overlapping threads. For example, one element might contain XML character data of "foo" and a 'parent' attribute whose value is "bar", a second element might contain XML character data of "bar" and a 'parent' attribute whose value is "baz", and a third element might contain XML character data of "baz" and a 'parent' attribute whose value is once again "foo". It is up to the implementation how it will treat conflicts between such overlapping thread identifiers (e.g., whether it will "chain together" thread identifiers by showing "foo" as both a parent and grandchild of "baz" in a multi-level user interface, or whether it will show only one level of dependency at a time). The value of the element is not human-readable and MUST be treated as opaque by entities; no semantic meaning can be derived from it, and only exact comparisons can be made against it. The value of the element MUST uniquely identify the conversation thread either between the conversation partners or more generally (one way to ensure uniqueness is by generating a universally unique identifier (UUID) as described in [UUID]). Security Warning: An application that generates a ThreadID MUST ensure that it does not reveal identifying information about the entity (e.g., the MAC address of the device on which the XMPP application is running). The element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).I implore you! Úpěnlivě prosím! Wherefore art thou, Romeo? Pročež jsi ty, Romeo? 0e3141cd80894871a68e6fe6b1ec56faSaint-Andre Standards Track [Page 76] RFC 6121 XMPP IM March 2011 For detailed recommendations regarding use of the element, refer to [XEP-0201].5.3. Extended Content As described in [XMPP-CORE], an XML stanza MAY contain any child element that is qualified by a namespace other than the default namespace; this applies to the message stanza as well. Guidelines for handling extended content on the part of both routing servers and end recipients are provided in Section 8.4 of [XMPP-CORE]. (In the following example, the message stanza includes an XHTML- formatted version of the message as defined in [XEP-0071]).) Wherefore art thou, Romeo?Whereforeart thou,Romeo?
6. Exchanging IQ Stanzas As described in [XMPP-CORE], IQ stanzas provide a structured request- response mechanism. The basic semantics of that mechanism (e.g., that the 'id' attribute is mandatory) are defined in [XMPP-CORE], whereas the specific semantics needed to complete particular use cases are defined in all instances by the extended namespace that qualifies the direct child element of an IQ stanza of type "get" or "set". The 'jabber:client' and 'jabber:server' namespaces do not define any children of IQ stanzas other than the element common to all stanza types. This document defines one such extended namespace, for Managing the Roster (Section 2). However, an IQ stanza MAY contain structured information qualified by any extended namespace.Saint-Andre Standards Track [Page 77] RFC 6121 XMPP IM March 20117. A Sample Session The examples in this section illustrate a possible instant messaging and presence session. The user is, he has an available resource whose resourcepart is "orchard", and he has the following individuals in his roster: o (subscription="both" and she has two available resources, "chamber" and "balcony") o (subscription="to") o (subscription="from") First, the user completes the preconditions (stream establishment, TLS and SASL negotiation, and resource binding) described in [XMPP-CORE]; those protocol flows are not reproduced here. Next, the user requests his roster. Example 1: User requests current roster from server UC: Example 2: User receives roster from server US:- Friends
[8]ページ先頭