moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 01:32:22 -05:00
Code Issues Releases Wiki Activity

1.0 DRAFT

Browse Source
This commit is contained in:
Peter Saint-Andre 2013-10-02 10:12:54 -07:00
parent 9cb8250400
commit 05ef0d73ed
1 changed files with 43 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
xep-0297.xml
View File

@ -10,8 +10,7 @@
<abstract>This document defines a protocol to forward a stanza from one entity to another.</abstract>
&LEGALNOTICE;
<number>0297</number>
<status>Proposed</status>
<lastcall>2012-12-14</lastcall>
<status>Draft</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@ -19,19 +18,24 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>forwarding</shortname>
<schemaloc/>
<shortname>forward</shortname>
<schemaloc>
<url>http://xmpp.org/schemas/forward.xsd</url>
</schemaloc>
&mwild;
&ksmith;
&stpeter;
<revision>
<version>1.0</version>
<date>2013-10-02</date>
<initials>psa</initials>
<remark><p>Per a vote of the XMPP Council, advanced status to Draft.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2013-06-05</date>
<initials>mw</initials>
<remark>
<p>Incorporated Last Call feedback, including; clarify that client handling of non-message stanzas,
add a disco feature, remove references to deferred XEPs, tighten up the schema to allow only stanzas
to be forwarded.</p>
<p>Incorporated Last Call feedback, including; clarify that client handling of non-message stanzas, add a disco feature, remove references to deferred XEPs, tighten up the schema to allow only stanzas to be forwarded.</p>
</remark>
</revision>
<revision>
@ -39,8 +43,7 @@
<date>2012-07-05</date>
<initials>mw</initials>
<remark>
<p>Added recommendation that forwarded messages as part of another specification should be nested under an
element of that protocol's namespace.</p>
<p>Added recommendation that forwarded messages as part of another specification should be nested under an element of that protocol's namespace.</p>
<p>Adapted text to indicate that stanzas other than messages may be forwarded. Updated title to reflect this.</p>
</remark>
</revision>
@ -121,25 +124,10 @@
</section2>
<section2 topic='Business rules'>
<ol>
<li><p>Forwarded stanzas SHOULD include all relevant child elements of the original stanza by default.
However, an implementation MAY omit elements it deems irrelevant and safe to discard. An example
would be omitting &xep0085; elements from &lt;message&gt; stanzas which typically do not make sense
outside the context of a conversation session. However it should be noted that removing such
elements can invalidate any digital signature on a stanza. If preserving a signature is important
in the context this extension is used then child elements SHOULD NOT be removed.</p></li>
<li><p>The forwarding entity SHOULD add a &lt;delay/&gt; child to the &lt;forwarded/&gt; element
to indicate to the recipient the date/time that the forwarding entity received the original
stanza. The format of this element is described in &xep0203;.</p></li>
<li><p>The namespace of the forwarded stanza MUST be preserved (this is typically 'jabber:client').
If no 'xmlns' is set for the stanza then as per XML namespacing rules it would inherit the
'urn:xmpp:forward:0' namespace, which is wrong.</p></li>
<li><p>When this extension is employed simply for a user to forward a given message to a contact, the
outer &lt;message/&gt; SHOULD contain a body (even if empty) and a receiving client should pay
particular attention to ensure it renders both the sender's text and the forwarded message
unambiguously.</p></li>
<li><p>When a forwarded stanza forms part of an encapsulating protocol, the &lt;forwarded/&gt; element
SHOULD be a child of a tag of that protocol, and SHOULD NOT be included as a direct child of the
transmitted stanza.</p></li>
<li><p>Forwarded stanzas SHOULD include all relevant child elements of the original stanza by default. However, an implementation MAY omit elements it deems irrelevant and safe to discard. An example would be omitting &xep0085; elements from &lt;message&gt; stanzas which typically do not make sense outside the context of a conversation session. However it should be noted that removing such elements can invalidate any digital signature on a stanza. If preserving a signature is important in the context this extension is used then child elements SHOULD NOT be removed.</p></li>
<li><p>The forwarding entity SHOULD add a &lt;delay/&gt; child to the &lt;forwarded/&gt; element to indicate to the recipient the date/time that the forwarding entity received the original stanza. The format of this element is described in &xep0203;.</p></li> <li><p>The namespace of the forwarded stanza MUST be preserved (this is typically 'jabber:client'). If no 'xmlns' is set for the stanza then as per XML namespacing rules it would inherit the 'urn:xmpp:forward:0' namespace, which is wrong.</p></li>
<li><p>When this extension is employed simply for a user to forward a given message to a contact, the outer &lt;message/&gt; SHOULD contain a body (even if empty) and a receiving client should pay particular attention to ensure it renders both the sender's text and the forwarded message unambiguously.</p></li>
<li><p>When a forwarded stanza forms part of an encapsulating protocol, the &lt;forwarded/&gt; element SHOULD be a child of a tag of that protocol, and SHOULD NOT be included as a direct child of the transmitted stanza.</p></li>
</ol>
</section2>
</section1>
@ -172,6 +160,17 @@
expected to display the &lt;body&gt; of a message as well as any forwarded stanza therein.
</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'urn:xmpp:forward:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Forwarding stanzas can reveal information about the original sender, including possible presence leaks as well as the stanza payloads themselves. Any extensions using this format must therefore consider the implications of this.</p>
<p>Forwarding can either be used as-is, or in the context of another specification, with different security considerations as described below.</p>
@ -196,8 +195,19 @@
xmlns='urn:xmpp:forward:0'
elementFormDefault='qualified'>
<xs:import namespace='jabber:client'/>
<xs:import namespace='jabber:server'/>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0297: http://www.xmpp.org/extensions/xep-0297.html
</xs:documentation>
</xs:annotation>
<xs:import namespace='jabber:client'
schemaLocation='http://xmpp.org/schemas/jabber-client.xsd'/>
<xs:import namespace='jabber:server'
schemaLocation='http://xmpp.org/schemas/jabber-server.xsd'/>
<xs:import namespace='urn:xmpp:delay'
schemaLocation='http://xmpp.org/schemas/delay.xsd'/>
<xs:element name='forwarded'>
<xs:complexType>
@ -220,11 +230,11 @@
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</xs:schema>
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Matt Miller, Florian Zeitz, Jefry Lagrange, Kim Alvefur and Kurt Zeilenga for their feedback.</p>
<p>Thanks to Kim Alvefur, Jefry Lagrange, Matt Miller, Peter Saint-Andre, Kurt Zeilenga, and Florian Zeitz for their feedback.</p>
</section1>
</xep>