> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Friday, November 28, 2008 4:07 PM > > It is however a problem that hasn't been clearly and adequately > addressed in any of the RFCs, leading to the need for the body handling > draft. As we move forward we are well advised to do a better job of what > we now realize is not quite as simple as people had assumed, mostly > because they rarely thought about multiple body parts.
Yup, we must reference that draft - no debate there. > I agree that we ought not have *special* normative language in one > draft, for behavior that should be general. But IMO it is still > advisable to provide informative language about this. And, there does > need to be *some* way to associate the info package semantics with the > proper body part(s). If we don't support multiple packages, then I assume the case for multiple body-parts in an INFO is what I'll call the "piggy-back" case. You've got something going on that piggy-backs its bodies onto messages of all/any type. Like for example sipfrag or geo-loc. Right? So let me ask this: how would one handle multiple body-parts in SUBSCRIBE, NOTIFY, or MESSAGE as defined today? Or in INFO today? MESSAGE, for example, has native support for text/plain and message/cpim, so what if the piggy-backer happens to use one of those content-types in a MESSAGE request? I think/guess there are three possible answers: 1) We have to go back and update Sub/Not and Message for them to do CID's as well. 2) We make only piggy-backers use CID for their body parts. 3) We say "don't do that". Would (2) work?? > Hence the cid reference in the Info-Package header. > The alternative would have been a special Content-Disposition, which I > suggested. Either would work, and Eric preferred the CID reference, > which is fine with me. I'm with Eric: cid handling has to be done for other things anyway, so if we *have* to do something let's keep it to CID. -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
