Gateway pass = SIP process Work for you now?
-- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is. -----Original Message----- From: Paul Kyzivat <[EMAIL PROTECTED]> To: Eric Burger CC: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [email protected] <[email protected]> Sent: Mon Jun 18 08:11:42 2007 Subject: Re: [Sip] MIME: Nested bodies with option-tag? Eric, I don't understand how to apply this to sip. 3459 defines the criterion for REQUIRED as: If the content gateway cannot pass a body part marked REQUIRED, then the entire message has failed. In this case, the content gateway MUST take the appropriate failure action. That makes sense for a mail gateway. (I don't know if it makes sense for a mail user agent.) But attempting to apply it to sip still leaves a lot of questions. In particular, I can see that in a mail message the multipart bodies themselves are actually rendered in the sense that they are shown as nested containers. In sip, in general that won't be the case - much of the content won't be "rendered", though it may be "processed" in some sense. Unless we define what we mean by "processing" then I think we haven't finished. Consider a few cases: 1. content-type SDP, content-disposition session;handling=required We know what that means, if in a message where an offer or answer is allowed, or a preview of an offer or answer, or in an OPTIONS response. We don't have a meaning for this in other contexts, such as SUBSCRIBE, NOTIFY, MESSAGE or their responses. If you were to receive the body in one of those, what should be done? Should that be a 415 response? 2. content-type text/plain, content-disposition render;handling=required We know what this means in MESSAGE. What should be done in other requests, or in responses? 3. c-t multipart/mixed, c-d ???;handling=required c-t SDP, c-d session;handling=required c-t application/ISUP, c-d signal;handling=optional I think this should be legal all the same places where (1) is legal. But a recipient that doesn't understand multipart/mixed will return a 415. I don't know what the content-disposition should be for the multipart. I guess for mail the default of render works, because it can really be rendered. That doesn't make sense for sip in this case. I have never seen an example using a multipart/mixed that included a content-disposition for it. AFAIK the default should be "render;handling=required". But for sip I don't know what it means to "render" a multipart. 4. c-t multipart/mixed; c-d ???;handling=required c-t SDP, c-d session;handling=required This is a little silly, but seems legal. If you can handle (3) then you should be able to handle this. Somebody that doesn't handle the multipart would return 415. 5. c-t multipart/mixed; c-d ???;handling=required c-t multipart/mixed; c-d ???;handling=required c-t SDP, c-d session;handling=required This is even sillier. But it raises more issues. If you handle (4), must you also handle this? If it is acceptable to handle (4) and not handle this, then what response should there be? AFAIK these are questions about the application of MIME to sip, that don't seem to have been handled by the mail work because the issues just didn't come up there. Thanks, Paul Eric Burger wrote: > Correct. That is the mechanism specified by RFC 3459. > > > On 6/3/07 6:47 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > >> From: "DRAGE, Keith \(Keith\)" <[EMAIL PROTECTED]> >> >> Well, at the moment, what I am trying to do is get some understanding of >> what we should scope as valid SIP work. >> >> I've been busy, so I may be behind in the discussion, but it's not >> clear to me that there is anything that needs to be done specifically >> for SIP. I may well be wrong, but my impression is that MIME already >> has the features and specifications neede so that a receiver can >> decide whether it has adequately "understood" the document when it >> only understands some components. These mechanisms are all inherited >> by SIP and I would expect be a sufficient set of rules. >> >> E.g., a UAC that sends a request with a multipart body must expect >> that some UASs will respond with 415, and have some strategy in place >> for dealing with that situation. Similarly, a UAC that sends a nested >> multipart body must expect that some UASs will be unable to process >> the nested multipart, and will either ignore it or reject the request >> (as specified), and the UAC must be prepared to deal with that >> situation. >> >> Is there a reason we need to define new, narrower subsets of allowed >> behaviors and define a SIP mechanism to negotiate these? >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.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 > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and have > received this message in error, please immediately return this by email and > then delete it. > > > _______________________________________________ > Sip mailing list https://www1.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 > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.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
