Subject: [Sip] draft-ietf-sip-body-handling-03

From: [email-masked]
Date: Tue, 23 Sep 2008 15:21:55 -0400 (EDT)

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Sep 2008 00:54:58 -0400

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

---

From: [email-masked]
Date: Wed, 24 Sep 2008 18:23:08 -0400 (EDT)

From: Paul Kyzivat <[email-masked]>

That's the case if handling is 'optional'.  But if handling is
'required', then the containing part is un-processable:

   8.4.  The 'by-reference' Disposition Type

   [...]

   [...]  A recipient of a body part whose disposition
   type is 'by-reference' that cannot find any reference to the body
   part (e.g., the reference was in a header field the recipient does
   not support and, thus, did not process) MUST NOT process the body
   part.  Consequently, if the handling of the body part was required,
   the UA needs to report an error.

That convention gives the sender a way to enforce that the processor
can see the reference to the part in question.

   Also, in principle it would be possible for a single body to be 
   processed multiple times, using differing contexts.

Yes, I was sloppy about that.  But I believe that what I wrote handles
that situation implicitly, because in such a case, the stated rules
give two different instances where processing of the part is
specified, and the rules regarding processing context give the proper
context for each instance of processing.

I've also been sloppy about noting that the Content-Disposition
parameters of parts become part of the processing context of all their
subordinate components.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Sep 2008 20:12:52 -0400

> 'required', then the containing part is un-processable:

OK, I agree. Its really a bad idea to make a body part required if it is 
to be referenced from a header that might not be supported.

What it doesn't seem possible to say is: "if you support the header (or 
whatever) that contains a reference to this part, then you are also 
required to support the type and disposition of the referenced part."

Theoretically that could be a problem, though in practice it might not 
be. Hopefully, if you process the header, and can't process the 
referenced body part, then there is some appropriate error message to 
return.

> parameters of parts become part of the processing context of all their

Gee - you're rarely sloppy. :-)

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 26 Sep 2008 13:09:36 -0400 (EDT)

If the header is not supported by the processor, then the body part is
effectively un-referenced.  The algorithm I wrote says what to do in
the various cases of that situation.

My assessment is that that requirement is created by marking the
referenced part handling=required.  E.g.:

	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.)

I'm assuming that the processor can somehow "ignore" the reference.
But for completeness, we should allow that the processing context can
turn the broken reference into an error (which could force the choice
of a different body-part to process).

Dale