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
