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:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
