From: Paul Kyzivat <[EMAIL PROTECTED]>
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.
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.
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."
My assessment is that that requirement is created by marking the
referenced part handling=required. E.g.:
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 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.)
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.
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
_______________________________________________
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
