XEP33: types of limits and default values

I've talked in the past that, if we want to limit the number of destination addresses in a XEP33 stanza, we must fix the XEP. One improvement I propose is to tell the limits in disco#info response using XEP128.

Let's suppose that limiting the number of destination addresses in a XEP33 stanza really serves a purpose, for example, to prevent or reduce abuse of the multicast service. If you accept this supposition, then you probably want fine-grained limits, so you can define different limits depending in the sending entity, type of stanza...

The different characteristics of a XEP33 stanza are:

• sender is: local or remote
  
• sender is: user or server/service/component
  
• the stanza type is: message or presence. Note that iq stanzas don't directly include XEP33 addresses.
  

There are eight possible permutations, and I associate a limit to each one. Let's review them in detail:

• limit-remote-user-message: A spammer can create accounts in a remote friendly server, and send XEP33 stanzas to our multicast service. I think that if a user wants to use a multicast service, he should ask the administrator of his server to install it, instead of using our multicast service. So, this limit should be 0 by default, which means users of remote servers can't send XEP33 stanzas directly to us.
  
• limit-remote-user-presence: Same as above, default: 0.
  
• limit-remote-server-message: There are many reasons for a remote server to send us a message stanza with XEP33 addresses: MUC message, pubsub message, user message... I propose a default limit of 20.
  
• limit-remote-server-presence: A remote server sends presence stanzas when a user logins, logouts or changes presence.
  I consider that presence stanzas are not as annoying as message or iq stanzas. I propose a default limit of 100.
  
• limit-local-user-message: In a publicly accesible Jabber server with unrestricted account registration (such as jabber.org), spammers can create accounts in jabber.org and use the local multicast service to send spam messages both to local and remote users/servers. I propose a default value of 20.
  
• limit-local-user-presence: I don't see any reason for a user to send a presence stanza to several destinations. Same as with remote servers, I propose a default limit of 100.
  
• limit-local-server-message: Obviously, this limit should be infinite always, since a multicast service is expected to trust a local server.
  
• limit-local-server-presence: Same as above, default: infinite.
  

Summarizing I propose those limits::

• zero: remote-user-*
  
• infinite: local-server-*
  
• variable: remote-server-* and local-user-*
  

Once XEP33 defines exact default values, if the limits in a XEP33 deployment are the default values, those limits SHOULD NOT be reported in disco#info responses.


PD: Another possible limitations to reduce abuse of a multicast service are # of messages per minute, # of addresses per minute, # of total bytes sent... But I don't expect them to be interesting for inclusion in XEP33.