> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 06, 2008 9:01 AM > > Is this really a problem for non-INFO message bodies? There is no CID > for SDP, but clients seem to be able to deal with it anyway.
There is no CID, but there is a C-D: an implicit C-D of "session" for app/sdp, and "render" for everything else. And I am not at all advocating that we use CID for the body-parts that actually belong to the message context. Quite the contrary, I think it would be silly to do that. And yes it is a potential problem for non-INFO message bodies, in exactly the same way it's a potential problem for INFO. There is nothing unique about INFO which makes the problem only applicable to it. To reiterate the "problem": the issue is not that messages can have multiple body-parts. The issue is that one or more body-parts may not actually be intended for the message's context. In other words, they're not intended for the application-layer processing logic specific to that method (and package if there is one). For example, when I send a SUBSCRIBE request, the method name "SUBSCRIBE" and the Event header package name identify a specific context - a specific use-case of the message with its own set of rules and for a specific application-layer above, which actually understands that package's specific semantics and how to process the higher-level "subscription". So if the SIP message has body-parts, and one of them is actually not intended for that package but is instead just a generic add-on, like geoloc for example, we need to dis-ambiguate that add-on body-part(s) from the others. -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
