[Standards] XEP 203 nits

Peter Saint-Andre stpeter at stpeter.im
Mon Nov 2 21:07:50 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrvSiYACgkQNL8k5A2w/vxzCQCfUh85RdJ6QsR3UGtKAYnnIT8U
DqEAniUQBXnEiRDUtmiLNRwDqXLRgdqS
=0X+B
-----END PGP SIGNATURE-----



More information about the Standards mailing list