I've finally had the time to reduce the contents of draft-ietf-sip-body-handling-03 into a semi-algorithm for how SIP bodies are processed. As far as I can tell, everything I've written is either stated or unambiguously implied by the draft. The advantage of this formulation is its relative brevity and that it makes it easier to examine the conequences of the various rules.
I will air my comments in a later message. At this point, I'd like people to check over what I've written to see if they agree that I am representing the draft correctly. ---------------------------------------------------------------------- 1. The questions Specifying SIP body processing requires answering three questions: - For any body part, is is processable? - For any body part that is processable, what actions are to be taken to process it? - For any body part, what is the processing context which determines what external entities are affected by processing the body part? It appears that, in general, determining how a body is to be processed cannot be done in one pass over the body. 2. Body parts and terminology Body parts are either "simple" or "multipart". Body parts that are "multipart" are of three types: multipart/mixed, multipart/alternative, and multipart/related. When describing the handling of a multipart body part, we call the multipart body part the "part", and we call the sub-parts of it the "components". 3. Processing context The processing context of parts is generally inherited from parts to their components. The processing context of the SIP message body as a whole (the root part) is provided by the method of the SIP message and context provided by the SIP protocol. 4. Simple parts A simple part can be processed if the processor understands its MIME type and disposition. If a simple part is to be processed, it is processed directly by the processor within the processing context that the part has inherited. 5. multipart/mixed A multipart/mixed part can be processed if all of the components with handling 'required' can be processed, and if the processor can see a reference to each component with Content Disposition 'by-reference' and handling 'required'. A multipart/mixed part is processed by processing each of its components which can be processed, excepting any component with Content Disposition 'by-reference' for which the processor cannot see a reference (and perforce, which has handling 'optional'). The processing context of a component is that of the part, unless the processor can see a reference to it, in which case the context is provided by the reference. (The 'required' status of a multipart/mixed part is the AND of the 'required' statuses of its componets.) 6. multipart/alternative A multipart/alternative part can be processed if any component can be processed. A multipart/alternative part is processed by processing the textually last of its components that can be processed. The processing context of the component is that of the part. (The handling of each component should be 'optional', but it is ignored. [problem:] This rule makes it impossible to express that a component of a multipart/mixed component of a multipart/alternative is required.) 7. multipart/related A processor is not rquired to implement multipart/related. If multipart/related is not implemented, such a part is treated as multipart/mixed. [problem:] It is not clear that this will give useful results. In order that a multipart/related part can be processed, the root component must be processable. From the root, all references to other components are followed, and references in those components are recursively followed, etc. (These components may be outside the multipart/related part.) A reference to another component that exists in a component may not be visible to the processor because it is embedded in an extension that the processor does not understand; such references are perforce ignored. A component that is referenced may not be processable by the processor, in which case if its handling is 'optional' the referenced component and the reference are both ignored, and if its handling is 'required' the multipart part is deemed not processable. (How such a reference is to be ignored is determined by the semantics of the component.) If there is a component (of the part) whose handling is 'required and the processor cannot see a reference to it, the part is deemed not processable. A multipart/related part is processed by processing the root component and all the processable components that are reached by recursively following references from it. The processing context of the root component that of the part. The processing contexts of the other components are provided by the references to them. [addition:] Components other than the root component should have Content-Disposition 'by-reference'. ---------------------------------------------------------------------- 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
