Hi, I also preferred the special Content-Disposition. And, since C-D is per MIME, I see no difference in having a single package or a mutlipart with multiple packages - each package will have an associated C-D.
The CID mechanism also works, but I think we would need that even if we only allow a single package, but at the same time still allow mutlipart. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2008 11:07 PM To: Hadriel Kaplan Cc: SIP List; Christer Holmberg Subject: Re: [Sip] Multiple body-parts in one INFO Hadriel, I agree that the problem of identifying which body part is the info package is not a unique problem to INFO. 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. 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). 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. Thanks, Paul Hadriel Kaplan wrote: > Ignoring the multiple *packages* per INFO for this email - this one is about multiple *body parts* per INFO. > > Was there consensus/hum on documenting that explicitly in this draft, in Minneapolis? > > Of course the INFO message has to support multiple body-parts, as does any SIP message. > > The question is: > 1) can we just say in the draft it must support it and point to the relevant RFCs, or... > 2) do we have to explicitly describe how it's supported/handled for INFO in particular? > > Doing 2 implies handling multiple body-parts has some unique issues for INFO. > > Since the Subscribe/Notify RFC does not have any such text, AFAICT, I fail to see what is unique about INFO package usage from Subscribe/Notify event packages or even just MESSAGE messages, with regards to handling of multiple body-parts. > I have tried to glean that answer from the numerous emails about this issue, but they were intertwined with multiple packages per INFO, and I can't seem to find the answer. > > -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
