Difference between revisions of "Extended Stanza Addressing (XEP-0033)"

From XMPP WIKI
Jump to navigation Jump to search
 
m
 
(9 intermediate revisions by one other user not shown)
Line 1: Line 1:
Some notes about revisions:
+
Links related to this protocol:  
 +
* Published protocol: [https://xmpp.org/extensions/xep-0033.html XEP-0033: Extended Stanza Addressing]
  
* Define active and passive modes more clearly
+
 
* Discourage relaying and specify in a separate section
+
= Some notes about revisions =
 +
 
 +
 
 +
== Packet Relay support ==
 +
 
 +
On XEP-0033, section Discovering Server Support, it says: 'The server MAY choose to limit whether non-local servers can send address headers that require the local server to send to third parties (relaying).'
 +
 
 +
Packet relay does not seem such an important feature. This feature must be explained with more detail, and make it optional both for implementation and deployments.
 +
 
 +
Proposed changes related to packet relay:
 +
* it needs to be specified more clearly: what is packet relay?
 +
* describe all this on a separate section, for example: 6. Packet Relay
 +
* packet relay is not a required feature on software
 +
* it is an optional feature
 +
* server devs may implement it (disabled by default), just in case somebody wants to use it
 +
* usage of relay on XMPP network is discouraged. right now the spec says you SHOULD allow relaying (since you MAY decide not to allow it). Let's change the wording to discourage relaying (SHOULD NOT allow relaying)
 +
* specify more clearly when relaying might be allowable (e.g., if there is trust between the servers) because otherwise this could be abused
 +
 
 +
http://badlop.blogspot.com/2007/06/packet-relay-no-thanks.html
 +
 
 +
[http://www.jabber.org/muc-logs/jdev@conference.jabber.org/2007-06-12.html#12:28:41 MUC logs]
 +
 
 +
 
 +
== Don't send multicast packet to replyto and replyroom ==
 +
 
 +
This may seem obvious, but it should me explicitely mentioned somewhere on the XEP: the destinations that the multicast service should send the packet are the ones with TYPE=TO or CC or BCC, and DELIVERED != TRUE. This means that replyto and replyroom addresses are not destinations of the packet at all.
 +
 
 +
 
 +
== Multicast Usage: don't require to check delivery ==
 +
 
 +
On XEP-0033, section Multicast Usage, it says: 'The server checks to see if it can deliver to all of the specified addresses. If not, the stanza is returned with a "Forbidden" error, and processing stops.'
 +
 
 +
This step should be completely removed, since it would require a lot of work and delay on the server.
 +
 
 +
 
 +
== Server Active Multicasting (SAM) ==
 +
 
 +
What is SAM: http://badlop.blogspot.com/2007/06/xep33-and-server-active-multicasting.html
 +
 
 +
SAM guidelines: http://badlop.blogspot.com/2007/06/guidelines-for-server-active.html
 +
 
 +
SAM+MUC: http://badlop.blogspot.com/2007/06/multi-user-chat-and-extended-stanza.html
 +
 
 +
 
 +
== Limit number of addresses ==
 +
 
 +
Summary: http://badlop.blogspot.com/2007/08/summary-of-xep33-addresses-limits.html
 +
 
 +
===Obsolete posts:===
 +
 
 +
Initial ideas: http://badlop.blogspot.com/2007/07/limit-of-addresses-on-xep33-must-be.html
 +
 
 +
Tell in disco#info: http://badlop.blogspot.com/2007/07/xep33-tell-limits-in-discoinfo-response.html
 +
 
 +
Types of limits: http://badlop.blogspot.com/2007/07/xep33-types-of-limits-and-default.html
 +
 
 +
Fixes: http://badlop.blogspot.com/2007/08/modifications-to-xep33-limits-proposal.html
 +
 
 +
 
 +
== Potential abuse of replyto/replyroom headers ==
 +
 
 +
http://badlop.blogspot.com/2007/08/multiple-replyto-and-enforce-all-them.html
 +
http://chatlogs.jabber.ru/ejabberd@conference.jabber.ru/2007/08/16.html#01:59:49

Latest revision as of 01:09, 18 December 2020

Links related to this protocol:


Some notes about revisions

Packet Relay support

On XEP-0033, section Discovering Server Support, it says: 'The server MAY choose to limit whether non-local servers can send address headers that require the local server to send to third parties (relaying).'

Packet relay does not seem such an important feature. This feature must be explained with more detail, and make it optional both for implementation and deployments.

Proposed changes related to packet relay:

  • it needs to be specified more clearly: what is packet relay?
  • describe all this on a separate section, for example: 6. Packet Relay
  • packet relay is not a required feature on software
  • it is an optional feature
  • server devs may implement it (disabled by default), just in case somebody wants to use it
  • usage of relay on XMPP network is discouraged. right now the spec says you SHOULD allow relaying (since you MAY decide not to allow it). Let's change the wording to discourage relaying (SHOULD NOT allow relaying)
  • specify more clearly when relaying might be allowable (e.g., if there is trust between the servers) because otherwise this could be abused

http://badlop.blogspot.com/2007/06/packet-relay-no-thanks.html

MUC logs


Don't send multicast packet to replyto and replyroom

This may seem obvious, but it should me explicitely mentioned somewhere on the XEP: the destinations that the multicast service should send the packet are the ones with TYPE=TO or CC or BCC, and DELIVERED != TRUE. This means that replyto and replyroom addresses are not destinations of the packet at all.


Multicast Usage: don't require to check delivery

On XEP-0033, section Multicast Usage, it says: 'The server checks to see if it can deliver to all of the specified addresses. If not, the stanza is returned with a "Forbidden" error, and processing stops.'

This step should be completely removed, since it would require a lot of work and delay on the server.


Server Active Multicasting (SAM)

What is SAM: http://badlop.blogspot.com/2007/06/xep33-and-server-active-multicasting.html

SAM guidelines: http://badlop.blogspot.com/2007/06/guidelines-for-server-active.html

SAM+MUC: http://badlop.blogspot.com/2007/06/multi-user-chat-and-extended-stanza.html


Limit number of addresses

Summary: http://badlop.blogspot.com/2007/08/summary-of-xep33-addresses-limits.html

Obsolete posts:

Initial ideas: http://badlop.blogspot.com/2007/07/limit-of-addresses-on-xep33-must-be.html

Tell in disco#info: http://badlop.blogspot.com/2007/07/xep33-tell-limits-in-discoinfo-response.html

Types of limits: http://badlop.blogspot.com/2007/07/xep33-types-of-limits-and-default.html

Fixes: http://badlop.blogspot.com/2007/08/modifications-to-xep33-limits-proposal.html


Potential abuse of replyto/replyroom headers

http://badlop.blogspot.com/2007/08/multiple-replyto-and-enforce-all-them.html http://chatlogs.jabber.ru/ejabberd@conference.jabber.ru/2007/08/16.html#01:59:49