mirror of https://github.com/moparisthebest/xeps
initial version
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1126 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
1d3f4adda6
commit
5d57ce9fa6
|
|
@ -0,0 +1,163 @@
|
|||
<?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>
|
||||
Loading…
Reference in New Issue