Re: draft-ietf-sip-body-handling-03

Dale,

I'm kind of busy right now and can't spend a lot of time formulating a 
detailed response right now. But I think you are on a good track. Its 
just going to take me a bunch of time to check all the relations between 
the draft and your formulation.

One thing where I immediately think there is some deviation:

IMO there is nothing really special about by-reference, except that it 
is a disposition-type whose intrinsic processing is "ignore". Hence the 
only processing that it might receive is determined by a reference, if 
any. If no reference is found then there is no processing.

Also, in principle it would be possible for a single body to be 
processed multiple times, using differing contexts. This could be a body 
with c-d of by-reference and two or more distinct references. It could 
also be a body with a c-d of some other type that has some intrinsic 
meaning, as well as one or more references to the same part. I don't 
think this is likely to be important in many cases, but it seems to be a 
possibility. One example that comes to mind would be a body part 
containing a location, that is referenced from a geoloc header (to 
assist routing) and perhaps has c-d of 'render' causing it to be 
rendered to the recipient. (Yes, this is a stretch.)

	Thanks,
	Paul

[email protected] wrote:
> 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
> 
_______________________________________________
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