* Holger Weiß <hol...@zedat.fu-berlin.de> [2018-11-14 10:41]: > * Georg Lukas <ge...@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
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
