Can you post a (anonymized) version? It would be very interesting.

        Thanks,
        Paul

Bob Penfield wrote:
I was just looking at a traces today from a well known vendor that included 
many NOTIFY requests with multi-part bodies. One included 16 body parts of two 
different Content-Types.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hadriel Kaplan
Sent: Tuesday, December 02, 2008 5:42 PM
To: Dean Willis
Cc: SIP List
Subject: Re: [Sip] Multiple body-parts in one INFO



-----Original Message-----
From: Dean Willis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2008 4:07 PM

Seriously - you expect us to put in a Require header
option-tag when multi-part mime is used, so it can fail against every
SIP device that is deployed on the planet??
If understanding how to decode the multipart MIME is critical to the
success of the request, then I expect the request to fail if the UAS
cannot decode it. Further, I want it to fail predictably in a way that
the request originator can understand, not in some cryptic
application/version dependent way.


What you are suggesting is that to use multi-part MIME in current SIP methods, 
we cannot rely on currently deployed system behavior.  So you're basically 
proposing we either:
1) Never do multi-part MIME.
2) Do a new SIP version.

I'm ok with doing #1, but I don't think things are *that* bad anyway.  I think 
we can rely on systems to behave sanely enough to do a backwards-compatible 
multi-part that should work in most cases - for the cases it doesn't, I think 
it will fail explicitly (with a failure response), and *then* one can argue if 
you can re-send it without the other body parts, or if you just fail the call 
hard.  But at least by then you've actually hit an error, and it's not ALL 
deployed systems that will have the problem.

Although I do wonder about how much of a Red Herring this topic is - what exact 
use-cases do you guys have for multi-part bodies in SUBSCRIBE, NOTIFY, PUBLISH, 
and INFO that is not actually defined in a package for them?  Or are we in some 
theoretical La-La land? [no offense meant - I like La-La land]

-hadriel
_______________________________________________
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

_______________________________________________
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

Reply via email to