diff --git a/xep-0297.xml b/xep-0297.xml index a4c16f10..e53a3713 100644 --- a/xep-0297.xml +++ b/xep-0297.xml @@ -10,8 +10,7 @@ This document defines a protocol to forward a stanza from one entity to another. &LEGALNOTICE; 0297 - Proposed - 2012-12-14 + Draft Standards Track Standards @@ -19,19 +18,24 @@ - forwarding - + forward + + http://xmpp.org/schemas/forward.xsd + &mwild; &ksmith; - &stpeter; + + 1.0 + 2013-10-02 + psa +

Per a vote of the XMPP Council, advanced status to Draft.

 + 0.5 2013-06-05 mw -

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.

+

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.

 @@ -39,8 +43,7 @@ 2012-07-05 mw -

Added recommendation that forwarded messages as part of another specification should be nested under an - element of that protocol's namespace.

+

Added recommendation that forwarded messages as part of another specification should be nested under an element of that protocol's namespace.

Adapted text to indicate that stanzas other than messages may be forwarded. Updated title to reflect this.

 @@ -121,25 +124,10 @@
    -

  1. 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 <message> 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.

    2. -

  2. The forwarding entity SHOULD add a <delay/> child to the <forwarded/> 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;.

    3. -

  3. 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.

    4. -

  4. When this extension is employed simply for a user to forward a given message to a contact, the - outer <message/> 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.

    5. -

  5. When a forwarded stanza forms part of an encapsulating protocol, the <forwarded/> element - SHOULD be a child of a tag of that protocol, and SHOULD NOT be included as a direct child of the - transmitted stanza.

    6. +

  6. 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 <message> 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.

    7. +

  7. The forwarding entity SHOULD add a <delay/> child to the <forwarded/> 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;.

  8. 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.

    9. +

  9. When this extension is employed simply for a user to forward a given message to a contact, the outer <message/> 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.

    10. +

  10. When a forwarded stanza forms part of an encapsulating protocol, the <forwarded/> element SHOULD be a child of a tag of that protocol, and SHOULD NOT be included as a direct child of the transmitted stanza.

 @@ -172,6 +160,17 @@ expected to display the <body> of a message as well as any forwarded stanza therein.

+ +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes 'urn:xmpp:forward:0' in its registry of protocol namespaces (see &NAMESPACES;).

+ + + &NSVER; + +

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.

Forwarding can either be used as-is, or in the context of another specification, with different security considerations as described below.

@@ -196,8 +195,19 @@ xmlns='urn:xmpp:forward:0' elementFormDefault='qualified'> - - + + + The protocol documented by this schema is defined in + XEP-0297: http://www.xmpp.org/extensions/xep-0297.html + + + + + + @@ -220,11 +230,11 @@ - + ]]> -

Thanks to Matt Miller, Florian Zeitz, Jefry Lagrange, Kim Alvefur and Kurt Zeilenga for their feedback.

+

Thanks to Kim Alvefur, Jefry Lagrange, Matt Miller, Peter Saint-Andre, Kurt Zeilenga, and Florian Zeitz for their feedback.