[Standards] multiple <forwarded/> elements in a stanza (XEP 297)

Kurt Zeilenga kurt.zeilenga at isode.com
Wed Nov 12 13:27:26 UTC 2014

The language of XEP 297 does not preclude a stanza from containing as direct children multiple <forwarded/> elements, each containing a forwarded stanza.    And given the feature is noted as being ‘rather like email forwards’ and one can forward multiple email messages in one email, it seems that an implementor could implement multiple stanza forwarding by encapsulating multiple stanzas in one stanza.

I think the XEP 297 should be clarified as to how implementors should (or must) encapsulated multiple stanzas when the user desires to forward multiple stanzas to someone.

There are pro/cons for each approach.   Consider, for instance, annotations.  If a user indicates multiple stanzas are to be forwarded, the user can provide a single note covering the set “Here’s a discussion thread…” and, if we had a decent signing extension, sign the stanza forwarding that thread in mass.   Of course, it can make for very large stanzas. The multiple approach allows for per forwarded stanza body elements and such, though this requires a more complex UI.  

I have no strong opinion on which approach (recommend individual forwards, recommend in-mass forwards), but I very much would like to seem some clarification of what is recommended here.

If the intent is one <forwarded/> child per stanza, then the following text could be added:

Forwarding Multiple Stanzas
     When forwarding multiple stanzas to an entity, each SHOULD be forwarded in separate stanza as detailed in Section 3.  That is, generally a stanza SHOULD NOT contain multiple  <forwarded/> elements as direct children.

If the intent is to allow multiple <forwarded/> child per stanza, the the following text could be added.
     Forwarding Multiple Stanzas
     When forwarding multiple stanzas to an entity, the forwarder SHOULD send a stanza which contains one <forwarded/> element for each stanza to be forwarded to the entity together.

— Kurt

More information about the Standards mailing list