[Standards] XEP 203 nits
stpeter at stpeter.im
Mon Nov 2 21:07:50 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 10/31/09 1:41 PM, Kurt Zeilenga wrote:
> In looking at this spec recently, I found a few oddities...
> The specification is not clear whether a stanza can contain multiple
> <delay/> elements such as when its delayed by multiple entities. While
> I cannot find any example or discussion of multiple <delay/> elements in
> any XEP, I assume multiple <delay/> elements are allowed as multiple
> entities can delay a stanza. But oddly I cannot find any discussion of
> multiple <delay/> elements in XEP 203 or any specification which calls
> for <delay/> elements to be added.
> Presuming the stanza can contain multiple <delay/> elements when its
> delayed by multiple entities, the specification language could be read
> as disallows an entity which delays a stanza multiple times from
> indicating that it has done so by including multiple <delay/> elements.
> For instance, when a server delays a stanza to a chatroom (hosted on
> another server entity) and than delays the forwarding of that stanza to
> one or more of the subscribers of the chat room.
> The specification recommends (in security considerations) that an entity
> remove delay notices which indicate that they were provided by the
> entity, or bounce the stanza, without at all noting that an entity
> should not remove it's own delay notices (or bounce a stanza it
> previously delayed). IMO, an entity SHOULD NOT remove <delay/>
> purporting to be from it unless it believes they weren't from it.
> There also seems to be issues in subsequent handling of previously
> delayed messages as well... but first the above.
If the specification does not forbid multiple <delay/> elements, then
such a usage is permitted. Indeed, I'm not sure how the spec could
forbid it, except by saying that if an entity receives a stanza that
already contains a <delay/> element then it MUST NOT add another
<delay/> element -- though IMHO that would introduce the potential for a
denial of service attack....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Standards