> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 03, 2008 2:58 PM > > - "Render" as the c-d is probably not 100% waterproof, since other body > types may also use it.
Nope, they actually can't. Not in the INFO context. Nor for that matter in the SUBSCRIBE, NOTIFY, or PUBLISH contexts. If you add a body with the "render" C-D to one of those message method types, you're actually telling the far-end to give that body-part to its "user", which is the package application. INFO is not the same context as MESSAGE. > - I DO still strongly support a new c-d for the package body, but it > seems that others have issues with that. In my mind, content-disposition is for a value that is basically a verb. If each package-body needs a new verb to describe giving it to the package, or even if we create a common verb for all packages to give that body part to the package, then all we're doing is re-inventing the wheel. The wheel is the INFO method name and Info-Package header value, which create the necessary and sufficient context with which to extract bodies of disposition "render" (or any specific disposition defined by the package). The wheel is already capable of turning, since it appears to be turning fine in legacy INFO use. We don't need to add hubcaps to make it more expensive. :) -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
