From 5d57ce9fa60ee1b148959cdbf9e13399b9fb5d77 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 8 Aug 2007 21:11:29 +0000 Subject: [PATCH] initial version git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1126 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0226.xml | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 xep-0226.xml diff --git a/xep-0226.xml b/xep-0226.xml new file mode 100644 index 00000000..316dd667 --- /dev/null +++ b/xep-0226.xml @@ -0,0 +1,163 @@ + + +%ents; +]> + + +
+ Message Stanza Profiles + This document specifies best practices for generating and handling extended content in XMPP message stanzas. + &LEGALNOTICE; + 0226 + Experimental + Informational + Standards + Council + + + + N/A + &infiniti; + &stpeter; + + 0.1 + 2007-08-08 + psa +

Initial published version; specified more granular profiles; renamed transmission elements to metadata elements.

 + + + 0.0.2 + 2007-08-01 + psa +

Clarified that message profiles apply to sending entities as well as receiving entities.

 + + + 0.0.1 + 2007-08-01 + jk/psa +

First draft.

 + +
+ +

The definition of XMPP stanzas in &xmppcore; and &xmppim; allows a &MESSAGE; stanza to include any number of child elements that define extended content. The fact that a message stanza may contain multiple instances of extended content can make it difficult for sending entities to know what is appropriate for inclusion in a message stanza and for receiving entities to know exactly how to process a message stanza.

+

Consider the following hypothetical example, which as we shall see is invalid.

+ + Shall we meet? + +

Shall we meet?

+ + + + + + romantic_meetings + + + + + + + + + + + + + +
high
+ + + + + + Italy + 45.44 + Venice + 12.33 + + + + + + ]]> +

What to make of a message like this? The import seems to be that Romeo, being in a flirtatious mood (&xep0107;) and currently located near Juliet's abode (&xep0080;), would urgently (&xep0131;) like to meet with Juliet (message body) and proposes two convenient places (&xep0020;) for an evening tryst, but no later than midnight (&xep0079;). But how is Juliet's client supposed to figure that out? That is, what should her client present to the user? And should Romeo's client even send a monstrosity such as this? (No.)

+

To clarify such matters, in this document we introduce the concept of "message stanza profiles".

+ + +

We propose the following profiles.

+ +

The instant messaging (IM) profile is the "default" profile for message stanzas. For example, if a message stanza includes only elements that are defined for the 'jabber:client' namespace then it is in the IM profile. If a message stanza includes both IM profile elements and other elements, the IM elements should be considered a fallback and the profile should be determined based on the other elements if supported (e.g., a data form). A sending entity should limit the elements it includes to IM profile elements, unless the IM elements are a fallback.

+

The extended content defined in the following specifications is considered to be in the IM profile:

+
    +
  • &xmppim;
    • +
  • &xep0045; (e.g., invitations)
    • +
  • &xep0066;
    • +
  • &xep0071;
    • +
  • &xep0085;
    • +
  • &xep0144;
    • +
  • &xep0172;
    • +
+ + +

Extended content elements defined in &xep0004; are considered to be in the Data Forms profile.

+ + +

Extended content elements defined in &xep0009; are considered to be in the RPC profile.

+ + +

Extended content elements defined in &xep0020; are considered to be in the Feature Negotiation profile.

+ + +

Extended content elements defined in &xep0070; are considered to be in the HTTP Authentication profile.

+ + +

Extended content elements defined in &xep0072; are considered to be in the SOAP profile.

+ + +

Extended content elements defined in &xep0155; are considered to be in the Stanza Session Negotiation profile.

+ + + +

Metadata elements are included to define how the message stanza shall be routed, delivered, or processed in transit. Metadata elements shall not be used to determine which profile applies. If a message stanza includes only metadata elements, it can be considered to have no profile.

+

The extended content elements defined in the following specifications are considered to be metadata elements:

+
    +
  • &xep0033;
    • +
  • &xep0079;
    • +
  • &xep0131;
    • +
  • &xep0203;
    • +
+ + +

We stipulate the following rules:

+
    +
  1. A single profile applies to each message stanza (i.e., a message is not in two or more profiles).
    2. +
  2. Transmission elements do not affect the profile.
    3. +
  3. Each element is part of some profile. Unless otherwise stated, the same profile applies to every element of a given namespace.
    4. +
  4. Unknown elements have no affect on determining the profile.
    5. +
  5. When determining which profile applies to a stanza, consider the IM profile as a last resort.
    6. +
  6. A sending entity must not mix profiles, except IM profile elements may included with with any other profile as a fallback (e.g., a message body along with a data form).
    7. +
+

Therefore, the example provided in the introduction should never be generated by a sending client because the message combines multiple profiles. If it receives a message stanza that combines multiple profiles, the receiving client MAY return a stanza error, which SHOULD be ¬acceptable;.

+ + + + + + ]]> + + +

This document adds no security concerns or consideration above and beyond those specified in the specifications to which it refers.

+ + +

This document requires no interaction with &IANA;.

+ + +

A future version of this specification may call for the ®ISTRAR; to establish a registry of message stanza profiles, so that each relevant specification shall define which profile applies to extended content qualified by the relevant namespace.

+ +