> >> While the "MAY" doesn't specify a requirement, it seems like it would be > helpful to implementers in light of the exhaustion/DoS possibilities > presented by huge frames and fragmentation. I would even argue that it
Why should that impose exhaustion/DoS possibilities? A WS impl. offering a streaming API has no problem. A WS impl. offering a frame-based API can fail as soon as the buffered amount for a frame exceeds some limit. A WS impl. offering a message-based API can fail as soon as the total buffered amount for the message exceeds some limit. All of these seem pretty straight forward. Where is the attack surface? > should be a "SHOULD". > >> > > I am Ok with changing MAY to SHOULD. > > I'm assuming from your response below that you're OK with going to MUST > as well? I'm not sure: does this refer to 10.4. Implementation-Specific Limits? So you suggest an implementation MUST impose limits on frame size AND message size? If that is your suggestion (which I hope not, since it's .. breathtaking), I really would welcome a broad discussion within the WG .. There was a long and heated debate about announcing frame-size limits and related error codes. Never (as far as I know) was there discussion about limiting message size. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
