Re: Multiple body-parts in one INFO

Christer Holmberg wrote:
> 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"?

No matter what we do, legacy info usage will have body parts with "render".

I guess maybe you mean they might *combine* the use of a single INFO for 
one legacy INFO usage *and* one info-package??? They can only do that if 
we define that they may, which I expect we will not, if we are not 
allowing multiple packages. If we define that they can't, its just a 
matter of what the error is: either its
- erroneous attempt to use INFO for both legacy and info-package
- or its: too many package bodies for info package

And note that you can screw up with cid references too, by including the 
same Content-ID in two different body parts.

People will always find a way to screw up. They will just have to deal 
with it until they get smarter.

>>> - 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.

I don't know what he is saying. But IMO we can't have just any old 
combination of C-D/C-T be the package.

No matter what, each body part does have a C-D - either explicitly or 
implicitly. And each brings its own "verb" with it. If a new one is not 
defined and used, and none is specified, then that verb will be "render".

But I don't agree that the C-D is a verb. "render" is a verb. But 
"inline", "attachment", "session", "early-session", "icon", 
"by-reference" are not verbs. And "alert" and "signal" (from 3204) might 
be nouns or verbs.

	Thanks,
	Paul

> 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