Re: Multiple body-parts in one INFO

Dean Willis wrote:
> Hadriel Kaplan wrote:
>>> -----Original Message----- From: Christer Holmberg
>>> [mailto:[email protected]] Sent: Sunday, November 30,
>>> 2008 4:58 PM
>>>
>>> Sounds ok. But, doesn't the Info-Package header syntax still have
>>> to allow the piggy-backer to: 1) List multiple info packages 2) For
>>> each listed info package, provide the cid
>> Nope.  We've already said we're going to not bother doing multiple
>> packages. (or at least I think people have agreed with that, I hope) 
>> So the next question was on multiple body-parts.  Since INVITE,
>> UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all
>> carry bodies and not one of them defined a CID mechanism for the body
>> part that was specific to their message method context, we shouldn't
>> need to for INFO either.
> 
> No, I think this means we messed up every one of those methods when we
> didn't address the multiple-body problem earlier. The reason it isn't
> exploding yet is that the specifications are ahead of the
> implementations; when the implementations catch up with the broken
> specs, we'll have failures of biblical proportion.
> 
> Sometimes we can demux on body-type. This is obviously not a universal
> solution. We really need a generic solution that works for all methods,
> not just INFO.

Exactly.

Regardless of whether Eric thinks it was appropriate or not, 
Content-Disposition was recruited for this purpose in 3261 via its use 
for "session", "alert", and "icon". And it has been used in a few other 
RFCs in a similar fashion.

For lack of anything better, to remain backward compatible, we probably 
need to consider C-D of "render" as identifying the principal body part 
used by MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH, and presumably *legacy* 
INFO. That works in the case where there is no multipart.

When you introduce multipart to any of those, unless you are careful to 
put some other C-D on the multipart itself, it becomes ambiguous whether 
the multipart as a whole is the principle body for the method, or if it 
should be opened and a part within it sought, because the default 
disposition for the multipart will be "render". We could probably fix 
this by having a special rule for multipart/mixed with "render".

	Thanks,
	Paul

_______________________________________________
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