Folks,FYI: we have requested the apps folks to have a look at this draft in order to make sure we get all the MIME stuff right. We will make sure the review is posted to this list.
Cheers, Gonzalo Gonzalo Camarillo wrote:
Hi,to be more concrete in our discussions, we need to make decisions on the following two issues:1) Where in a SIP message is it allowed to reference a body part?a) in header fields and body parts within the same multipart/related as the referenced body part b) in header fields and body parts that appear before the referenced body partc) in header fields and any body partWe discussed that doing c) would require to parse SIP messages twice to look for potential references. Therefore, we decided to do a) or b). The current draft specifies a), we doing b) might make sense as well (it would be less restrictive).2) If a receiver does not understand a reference to a body part:a) it should process (handle) it solely based on its disposition type (as a fall-back mechanism). If the sender does not want this to happen, it can use an option tag.b) the body part will have a disposition type of "only-by-reference". This way, since the receiver did not understand the reference, it knows it should not process the body.The current draft specifies a), but b) would be an interesting optimization (no need to use option tags and reissue requests). However, we would need to get the opinion of a MIME person on b).Cheers, Gonzalo Paul Kyzivat wrote:Eric Burger wrote:I agree 100% with Paul. However, one thing I would like to hear opinions onis the following: Do we way body parts are always processed, no matter what?It would be convenient to say body parts get processed as needed. If there is a related part that never gets referenced, then a conforming processormight not process that part, as an optimization.This gets into semantics...For one thing, I guess we should talk about "handling" rather than "processing" - this is tied to the C-D "handling=" parameter.But the key thing is what does it *mean* to say you have handled something? Its one thing to understand the meaning of the type and disposition. What you actually *do* once that is understood is something else entirely.I would expect that somewhere there would be a normative specification for each C-D of what it means to *handle* body parts with that disposition. This is where we get into trouble with "render", where we need a different definition for SIP than is used for email.I presume that if we had such normative definitions, then that would determine what sort of optimizations, such as lazy processing, are allowed.For example, 3261 defines (barely) the C-D "alert". It says this "should" (lower case) be rendered. Together with some words elsewhere about Alert-Info that warn of security issues, its seems clear that the UA is given discretion about actually rendering this. (But it is not a stellar example of clarity.) I would interpret this to mean that you can consider the "alert" body part to have been "handled" if you have indeed understood it and then *either* rendered it or made an explicit not to render it.However, one thing we need to be mindful of are side effects. MIME body parts can make external references. Those external references (tohttp/https URI's) may hit application servers. Those application servers may do something based on the receipt of the URI. It could be as simple as recording the fact the body part was read (like a web beacon), or it couldbe as complex as changing application state.We have similar issues with headers that contain URL references, that might or might not be resolved. E.g. Call-Info.Again, I don't see any general answer better than the specification of the particular header or C-D.Based on this discussion I am beginning to conclude that we might as well treat each body part almost as if it were a header whose name is its C-D.What do people think of this? Do we say that SIP engines are opportunistic, and the side effect MUST happen if the body gets used, buy the side effectMAY happen if the body does not get used? That would be my vote, as thealternative, that all side effects (external references get resolved) happenputs a pretty big burden on User Agents.This is further complicated by intermediate nodes. They are *permitted* to look at body parts. If, as a result, an intermediate node dereferences a reference within a body part, you will potentially have another side effect.I also agree that we should give the UA latitude in what processing it does. For example, even though a request has a geopriv header with a body part containing location data, and has specified "handling=required", the UAS may have no use for the location. If it doesn't intend to use it then why should it process it?PaulOn 8/29/07 8:57 AM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote:To clarify futher my last point below... What I am saying is that IMO body parts must always be processedaccording to their type and disposition, whether there are references tothem or not. If there is a reference, and it is understood, then it can modify or supplement the processing, but if the reference is not recognized or understood then the other processing still occurs. If we want to support the possibility of a reference to a body part, where there is to be no processing of the body part when the reference is not understood, then we need a content-disposition that says "don't do anything with this unless you process a reference to it." An alternative is to simply assume there are no such cases, and warn people that use references to select a C-D for the referenced part that will have an appropriate result if the reference is not understood.For instance, we have both the Alert-Info header and the "alert" C-D. If you use an A-I with a CID reference, then you can use "alert" as the C-Dof that part. In that case, the A-I header is redundant unless it contains something that modifies the processing. An example where the problem I am concerned about may exist is in draft-ietf-sip-location-conveyance-08. It has an example of a Geolocation header referencing a body part. There is no C-D header inthe example, so by default it is "render;handling=required". And its C-Tis application/pidf+xml. If a recipient of this message didn't understand the Geolocation header it would reach the conclusion that it should render the pidf. Its debatable whether that is the desired conclusion - I think not. IMO the intent is that if the Geolocation header isn't processed then the pidf should be ignored. So, IMO this body part ought to contain: Content-Disposition: by-reference;handling=optional(I don't care what name we use for the disposition, just that we have one.)Thanks, Paul Paul Kyzivat wrote:Gonzalo, Obviously we allow a "forward" reference from the sip message itself (which from a mime perspective are just a bunch of mime headers.) I think that establishes a precedent that needs to be continued. An example of why can be seen in sipfrag:If we had a valid sip response that had a reference into one of its body parts, then if that was turned into a sipfrag and stuffed into the bodyof a NOTIFY, then it must still be valid. I just did a quick scan of the new draft, so the following is a tentative comment, until I can read it more carefully: I think the draft is now saying that the decision about whether to process a body part according to a reference to it, or processindependently, is decided based on whether a reference is found. We hadthis discussion before, and I think we agreed that wouldn't work well, and that instead we would have a special C-D type for body parts that are disposed of based on a reference. I don't think the introduction of issues related to multipart/related changes this. The obvious cases are when there is a single multipart/mixed containing some body parts. Some of those may bereferenced from CID URIs in sip headers, and others (e.g. SDP) may standon their own. It is entirely possible that a body part might be referenced from some extension header that the recipient doesn't understand. In that case it may erroneously decide to process the body part on its own, when it should instead have ignored it because the header isn't being processed. Thanks, Paul Gonzalo Camarillo wrote:Folks,I have just submitted a new revision of the body handling draft. Untilit appears on the archives, you can fetch it from:http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txtPer our discussions in Chicago, the draft now states that only body parts within the same 'multipart/related' can reference each other using cid URIs. If this is too restrictive, we could also allow using forward references in any context (with no 'multipart/related' at all). Comments? Thanks, Gonzalo _______________________________________________ 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_______________________________________________ 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_______________________________________________ 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 sipNotice: 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
_______________________________________________ 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
