Re: Multiple body-parts in one INFO

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email protected]]
> Sent: Friday, November 28, 2008 4:07 PM
>
> 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.

Yup, we must reference that draft - no debate there.

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

If we don't support multiple packages, then I assume the case for multiple body-parts in an INFO is what I'll call the "piggy-back" case.  You've got something going on that piggy-backs its bodies onto messages of all/any type.  Like for example sipfrag or geo-loc.  Right?

So let me ask this: how would one handle multiple body-parts in SUBSCRIBE, NOTIFY, or MESSAGE as defined today?  Or in INFO today?  MESSAGE, for example, has native support for text/plain and message/cpim, so what if the piggy-backer happens to use one of those content-types in a MESSAGE request?

I think/guess there are three possible answers:
1) We have to go back and update Sub/Not and Message for them to do CID's as well.
2) We make only piggy-backers use CID for their body parts.
3) We say "don't do that".

Would (2) work??


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

I'm with Eric: cid handling has to be done for other things anyway, so if we *have* to do something let's keep it to CID.

-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