Hi, >> - "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.
So, there is no risk that someone would insert a legacy INFO body part with "render"? >> - 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. :) So, you are basically saying: we don't need to do anything as far as find-the-body-part-with-the-info-package is concerned? We simple specify that one inserts a Info-Package header with the package name, and that's it? Whatever C-D/C-T value is used is then defined by the package itself. Well, since I assume most INFOs will be sent with a single body part anyway, I guess it would work for those cases... Regards, Christer _______________________________________________ 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
