Hi, >>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.
Sure. But, assume we would also be using SDPng. It would also have a C-D value of "session", but I assume the C-T value would be different than "app/sdp". You need to know what is in the body, so you can process and parse it correctly. >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. It should be defined in what SIP messages geoloc information may be transported, and what the receiver supporting it is supposed to do with it. As we do for SDP. SDP in CANCEL has no meaning, for example, so it is seen as a protocol error to send SDP in CANCEL. I see no reason why we should solve things so that one can insert whatever, wherever... And, as far as INFO is concerned, I guess we all agree that info packages are within the context of INFOs. BUT, you still need to know body part(s) contain info package bodies, and what info package is containded in a specific body part. C-T can do that, as it does for XML. 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
