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
