[Standards] XMPP APIs and duplicate extension elements

Florian Schmaus flo at geekplace.eu
Wed Feb 4 11:37:13 UTC 2015


If I'm not mistaken, no XMPP specification forbids duplicate extension
elements, i.e. same element name and namespace, as direct child of the
stanza element. For example

<message …>
  <foo xmlns="http://example.org" data='42' />
  <foo xmlns="http://example.org" data='1337' />
</message>

is perfectly valid XMPP XML. This means that in order to allow retrieval
of *all* elements, XMPP APIs need to provide a method like


List<Element> Stanza.getExtensions(String name, String namespace)


but a quick survey did not reveal any API that actually does this. Most,
if they are not low-level, have something like


Element Stanza.getExtension(String name, String namespace)


I like to propose that a future RFC (or another normative spec) forbids
duplicate extension elements. Now I know this is likely a controversial
proposal. But please have a look my arguments first:

- Most APIs don't support duplicate extension elements, this leads to
the conclusion that nobody noticed that they are not supported, i.e.
nobody is missing that feature.

- They make implementations more complex, in terms of LOC (at least if
you want to support fast lookup of extension element a stanza has).

- In return, forbidding duplicate extension elements would make XMPP
easier to use.

- I can think only of two XEPs that introduce duplicate extension
elements: <delay/> (1) and *maybe* <forwarded/>


Slightly related and for similar reasons, I'd like to propose that the
order of stanza extension elements must not yield any semantic, i.e. the
order of extension elements doesn't matter.

Re 1.: Yeah, i know that xep203 is final, but I think it's still not to
late to make that change and have implementations create an extra
exception for xep203, which is not nice too, but still better than
allowing duplicate extension elements IMHO.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 668 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150204/824ba100/attachment.sig>


More information about the Standards mailing list