> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 06, 2008 4:09 PM > > > >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.
Of course, but the C-T helps you determine exactly what you just described: the parsing of it. Not the parsing of the SIP message, but the parsing of that specific body part's content; and not the purpose of that body part either - that's C-D essentially. The SIP stack may have no idea how that content is parsed whatsoever. All it needs to know is what upper-layer logic to pass it up to. We're not preventing an integrated stack from processing it all at once - we're just continuing to allow a layered stack to separate it out. So let's take the SDPng example - let's ignore that INVITE basically has special handling of session descriptions in particular, and is generally "special" in SIP for lots of things, which make the example not really applicable for the discussion. So instead assume it's possible to handle it exactly as other messages could handle their body parts. Just the C-D of "session" tells the SIP stack the body-part's purpose/semantic is to describe a session. It could actually stop right there, and pass it up to a common process which handles all session descriptions, which would figure out how to parse an "application/sdpng". Or the stack could have information about what formats the process can handle, which are just opaque strings to it, and thus determine that "application/sdpng" is not a type the process can handle and reject it right then. Or the stack could even know how the content handled by the app process should be formatted, and reject them if they're not right. Or the session description handling could be completely integrated into the stack. > 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. But C-T does NOT do that for XML. I can use an application/pidf+xml for any number of things. The C-D tells me the semantic purpose of it. I.e., what to do with it. And again, a "package" is NOT contained in a body part. A package may define body part content-types to use, or none at all. The way you can know what body-parts are for the package is by those body-parts that have a C-D of "render" (unless the package defines a specific C-D value). And since "render" is implicit/default, you don't even need to include C-D in the message. Neat and tidy. :) -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
