Pedro Melo wrote: > Hello, > > Some comments regarding version 0.2 (2007-07-10): > > > 1. Section 4.4, Simultaneous Resources > > The error type in Example 1 is 'modify'. I think it should be cancel > because the request will never succeed no matter what you change in that > session.
Changed per rfc3920bis. > 2. Section 4.5, Stanza Size > > The first response, sending back a stanza of type='error' requires the > server to keep parsing the invalid stanza to know when it ends. With a > never ending stanza, this will cause DoS for servers. > > I think the only response to Stanza Size is the second one: as soon as > you detect an ongoing big stanza, give the stream error and close the > stream and the underlying connection. For example, at the jabber.org service we limit stanzas to 65k. If you send a stanza that's 66k, it seems unfriendly to end your session. > 3. Section 4.6, Multiple Recipients > > Although I prefer to keep this section in case I'm missing something, I > think the problem is already covered by 4.7 and 4.8 combined. I'm not sure about that. I could write a spam bot that sends hundreds of small stanzas (say, presence subscription requests). > 4. Section 4.9, Service Restrictions > > One amplifier service not mentioned is the session manager itself. The > server should limit the number of presence changes. Good point. > In particular the server should filter several presences with the exact > same payload. Or, I think, even different payloads (e.g., toggling back and forth between priority 0 and priority 1 or whatever). > The section only mentions access control features, and not DoS > protection schemes. > > Regarding MUCs, we should mention per participant limits on presence > changes and messages as concrete examples of limits to provide. > > Regarding PubSub, number of published items per time period should also > be limited. OK, I'll work those in. Peter
