Hi,I understand that the conclusion of this thread is that we may want to tackle the issue of large SIP messages (not only bodies) at some point but that this is not the appropriate draft to do so. So, I will not make any changes to the draft.
Thanks for all your comments, Gonzalo Paul Kyzivat wrote:
Hadriel Kaplan wrote:-----Original Message----- From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Well, a message includes the body. At least in the case of a proxy I think it would be unreasonable to claim that you support a message that large yet reject the message because the body is too large.Which is why you're not in marketing. ;)Aside from an overall limit on message size, IMO a node ought not reject a message because some body part it doesn't process is "too large" for it. If it has reason to process the body part then perhaps it may have cause to reject a part that is too large.Even a proxy may need to really. Imagine an outbound proxy handling numerous endpoints to the registrar, with one TCP connection to the registrar - if it passes any body size up to the registrar willy-nilly, any endpoint's random 10MB body will impact message forwarding for all others due to HOL. (heck, given the horsepower of some nodes, a 64KB body could too) Then there's also the reality of TCP not being exactly ubiquitous, to put it mildly, and the odds of a >64KB message making it not being too high.Note that I said "Aside from an overall limit on message size". I can see imposing some limit on message size. But if the message doesn't exceed that, why would a proxy reject the request because the body was too large?I can see rejecting for a body too large if the proxy needed to process that body and it was too big for the proxy to process. But if the body is something that is not the proxies business then it has no business being fussy about it. Its a distinction between unable and unwilling.Of course it may have a *policy* about it - that is different. Having a policy about the size of a body part is roughly equivalent to having a need to process that part.This of course starts to get ugly with multipart. (E.g. The proxy wants to verify the SDP but runs into the 1mb jpg picture of the caller.) Depending on how you implement, you may need a lot of storage just to deal with the parts you don't care about on the way to finding the one(s) you do care about. If you are careful you can do it without a lot of storage beyond buffering the message, but I don't know how clever we should mandate that people be.Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip