[Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)

Georg Lukas georg at op-co.de
Wed Nov 14 11:47:09 UTC 2018


* Holger Weiß <holger at zedat.fu-berlin.de> [2018-11-14 10:41]:
> * Georg Lukas <georg at op-co.de> [2018-11-13 18:29]:
> > §3 point 2 should probably be changed from
> > 
> > | Stanza ID generating entities, which encounter a <stanza-id/> element
> > | where the 'by' attribute matches the 'by' attribute they would otherwise
> > | set, MUST delete that element even if they are not adding their own
> > | stanza ID.
> > 
> > to
> > 
> > | Entities which receive a stanza with a <stanza-id/> element
> > | where the 'by' attribute matches the entiy's own JID, MUST delete that
> > | element even if they are not adding their own stanza ID.
> 
> I guess the former wording was chosen deliberately to avoid the
> ambiguity about who exactly the "entities wich receive a stanza" might
> be.  §3, point 7 says: "For one-on-one messages the assigning entity is
> the account.  In groupchats the assigning entity is the room."  With
> your wording, readers might assume the entity is the server itself.

Maybe then the wording needts to be "where the 'by' attribute matches a
JID that the entity is responsible for"? I just want to prevent somebody
injecting stanzas into my administrative domain with one of my JIDs.

On the other hand you could argue that the entity is the user's account,
running on the server.

> For the same reason, I don't really like the wording in §2.1:
> 
> | In order to create a <stanza-id/> extension element, the creating XMPP
> | entity generates and sets the value of the 'id' attribute, and puts its
> | own XMPP address as value of the 'by' attribute.

Again, "user's account" is an entity as well.


Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20181114/aba5b6c6/attachment.sig>


More information about the Standards mailing list