mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-10 03:15:00 -05:00
164 lines
8.5 KiB
XML
164 lines
8.5 KiB
XML
|
<?xml version='1.0' encoding='UTF-8'?>
|
||
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||
|
|
%ents;
|
||
|
|
]>
|
||
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||
|
|
<xep>
|
||
|
|
<header>
|
||
|
|
<title>Message Stanza Profiles</title>
|
||
|
|
<abstract>This document specifies best practices for generating and handling extended content in XMPP message stanzas.</abstract>
|
||
|
|
&LEGALNOTICE;
|
||
|
|
<number>0226</number>
|
||
|
|
<status>Experimental</status>
|
||
|
|
<type>Informational</type>
|
||
|
|
<sig>Standards</sig>
|
||
|
|
<approver>Council</approver>
|
||
|
|
<dependencies/>
|
||
|
|
<supersedes/>
|
||
|
|
<supersededby/>
|
||
|
|
<shortname>N/A</shortname>
|
||
|
|
&infiniti;
|
||
|
|
&stpeter;
|
||
|
|
<revision>
|
||
|
|
<version>0.1</version>
|
||
|
|
<date>2007-08-08</date>
|
||
|
|
<initials>psa</initials>
|
||
|
|
<remark><p>Initial published version; specified more granular profiles; renamed transmission elements to metadata elements.</p></remark>
|
||
|
|
</revision>
|
||
|
|
<revision>
|
||
|
|
<version>0.0.2</version>
|
||
|
|
<date>2007-08-01</date>
|
||
|
|
<initials>psa</initials>
|
||
|
|
<remark><p>Clarified that message profiles apply to sending entities as well as receiving entities.</p></remark>
|
||
|
|
</revision>
|
||
|
|
<revision>
|
||
|
|
<version>0.0.1</version>
|
||
|
|
<date>2007-08-01</date>
|
||
|
|
<initials>jk/psa</initials>
|
||
|
|
<remark><p>First draft.</p></remark>
|
||
|
|
</revision>
|
||
|
|
</header>
|
||
|
|
<section1 topic='Introduction' anchor='intro'>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>Consider the following hypothetical example, which as we shall see is invalid.</p>
|
||
|
|
<example caption='A confusing message'><![CDATA[
|
||
|
|
<message from='romeo@montague.lit' to='juliet@capulet.com'>
|
||
|
|
<body>Shall we meet?</body
|
||
|
|
<html xmlns='http://jabber.org/protocol/xhtml-im'>
|
||
|
|
<body xmlns='http://www.w3.org/1999/xhtml'>
|
||
|
|
<p style='font-weight:bold'>Shall we meet?</p>
|
||
|
|
</body>
|
||
|
|
</html>
|
||
|
|
<feature xmlns='http://jabber.org/protocol/feature-neg'>
|
||
|
|
<x xmlns='jabber:x:data' type='form'>
|
||
|
|
<field var='FORM_TYPE' type='hidden'>
|
||
|
|
<value>romantic_meetings</value>
|
||
|
|
</field>
|
||
|
|
<field type='list-single' var='places-to-meet'>
|
||
|
|
<option><value>Secret Grotto</value></option>
|
||
|
|
<option><value>Verona Park</value></option>
|
||
|
|
</field>
|
||
|
|
<field type='list-single' var='times-to-meet'>
|
||
|
|
<option><value>22:00</value></option>
|
||
|
|
<option><value>22:30</value></option>
|
||
|
|
<option><value>23:00</value></option>
|
||
|
|
</field>
|
||
|
|
</x>
|
||
|
|
</feature>
|
||
|
|
<headers xmlns='http://jabber.org/protocol/shim'>
|
||
|
|
<header name='Urgency'>high</header>
|
||
|
|
</headers>
|
||
|
|
<amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
|
||
|
|
<rule condition='expire-at'
|
||
|
|
action='drop'
|
||
|
|
value='2007-08-01T23:30:00Z'/>
|
||
|
|
</amp>
|
||
|
|
<geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
|
||
|
|
<country>Italy</country>
|
||
|
|
<lat>45.44</lat>
|
||
|
|
<locality>Venice</locality>
|
||
|
|
<lon>12.33</lon>
|
||
|
|
</geoloc>
|
||
|
|
<mood xmlns='http://jabber.org/protocol/mood'>
|
||
|
|
<flirtatious/>
|
||
|
|
</mood>
|
||
|
|
</message>
|
||
|
|
]]></example>
|
||
|
|
<p>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.)</p>
|
||
|
|
<p>To clarify such matters, in this document we introduce the concept of "message stanza profiles".</p>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Profiles' anchor='profiles'>
|
||
|
|
<p>We propose the following profiles.</p>
|
||
|
|
<section2 topic='IM' anchor='profiles-im'>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>The extended content defined in the following specifications is considered to be in the IM profile:</p>
|
||
|
|
<ul>
|
||
|
|
<li>&xmppim;</li>
|
||
|
|
<li>&xep0045; (e.g., invitations)</li>
|
||
|
|
<li>&xep0066;</li>
|
||
|
|
<li>&xep0071;</li>
|
||
|
|
<li>&xep0085;</li>
|
||
|
|
<li>&xep0144;</li>
|
||
|
|
<li>&xep0172;</li>
|
||
|
|
</ul>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='Data Forms' anchor='profiles-dataforms'>
|
||
|
|
<p>Extended content elements defined in &xep0004; are considered to be in the Data Forms profile.</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='RPC' anchor='profiles-rpc'>
|
||
|
|
<p>Extended content elements defined in &xep0009; are considered to be in the RPC profile.</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='Feature Negotiation' anchor='profiles-featureneg'>
|
||
|
|
<p>Extended content elements defined in &xep0020; are considered to be in the Feature Negotiation profile.</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='HTTP Authentication' anchor='profiles-httpauth'>
|
||
|
|
<p>Extended content elements defined in &xep0070; are considered to be in the HTTP Authentication profile.</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='SOAP' anchor='profiles-soap'>
|
||
|
|
<p>Extended content elements defined in &xep0072; are considered to be in the SOAP profile.</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='Stanza Session Negotiation' anchor='profiles-ssn'>
|
||
|
|
<p>Extended content elements defined in &xep0155; are considered to be in the Stanza Session Negotiation profile.</p>
|
||
|
|
</section2>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Metadata Elements' anchor='metadata'>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>The extended content elements defined in the following specifications are considered to be metadata elements:</p>
|
||
|
|
<ul>
|
||
|
|
<li>&xep0033;</li>
|
||
|
|
<li>&xep0079;</li>
|
||
|
|
<li>&xep0131;</li>
|
||
|
|
<li>&xep0203;</li>
|
||
|
|
</ul>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Rules' anchor='rules'>
|
||
|
|
<p>We stipulate the following rules:</p>
|
||
|
|
<ol>
|
||
|
|
<li>A single profile applies to each message stanza (i.e., a message is not in two or more profiles).</li>
|
||
|
|
<li>Transmission elements do not affect the profile.</li>
|
||
|
|
<li>Each element is part of some profile. Unless otherwise stated, the same profile applies to every element of a given namespace.</li>
|
||
|
|
<li>Unknown elements have no affect on determining the profile.</li>
|
||
|
|
<li>When determining which profile applies to a stanza, consider the IM profile as a last resort.</li>
|
||
|
|
<li>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).</li>
|
||
|
|
</ol>
|
||
|
|
<p>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;.</p>
|
||
|
|
<example caption='Message not acceptable'><![CDATA[
|
||
|
|
<message from='juliet@capulet.com' to='romeo@montague.lit'>
|
||
|
|
<error code='406' type='cancel'>
|
||
|
|
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||
|
|
</error>
|
||
|
|
</message>
|
||
|
|
]]></example>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Security Considerations' anchor='security'>
|
||
|
|
<p>This document adds no security concerns or consideration above and beyond those specified in the specifications to which it refers.</p>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
||
|
|
<p>This document requires no interaction with &IANA;.</p>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||
|
|
<p>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.</p>
|
||
|
|
</section1>
|
||
|
|
</xep>
|