From: Paul Kyzivat <[EMAIL PROTECTED]> One implication of this is that body parts need to be processed twice in a content-type+content-disposition+context dependent way: once to extract references, and again for final effect.
That does seem to be unavoidable in the general case. (Though every practical case I know of can avoid two-pass processing.) (Hmm - is extracting of references dependent on the disposition and context?) Presumably it could be, depending on the definition of how the simple parts are to be processed. In any case, it doesn't seem to add complexity to the implementation to allow for it. If you imagine that various content types are handled by plugins, then the plugins will each require two entry points - one for each of these processing modes. While that is certainly possible, it might mean that plugins that already exist for non-sip applications (e.g. email or html) may not be reusable for sip. (I am not familiar with the content-type plugins for other protocols such as email. But I presume that email plugins may be useful in some cases, at least for MESSAGE.) Do plugins for email have this complexity? Since two-pass processing is required for processing the full set of MIME constructions, plugins for e-mail processing would theoretically have to allow this. I've never heard of any that do. An alternative is to do all the processing in one pass, and then at the end check if all body parts have been processed. BUT that means all the side effects of processing will have been realized before discovering that the message is in error. That is certainly not ideal. It wouldn't be correct, either. How would you process a multipart/alternative? > This example also points out that the requirement that references > appear before the parts they reference is needed to make the problem > tractable. Otherwise, there could be circular dependencies between > the choices for different multipart/alternatives, which might be > impossible to analyze by an algorithm as simple as a tree-walk. This requirement is satisfied by lots of simple cases. But it means that it is impossible to describe any kind of circular structure. I'm not familiar enough with the use of multipart/related to know if it is a restriction that is tolerable there. Perhaps someone can comment on that. The requirement is in the current I-D: 8.2. UA Behavior to Generate References to Message Bodies UAs MUST only include forward references in the SIP messages they generate. Dale _______________________________________________ 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
