[EMAIL PROTECTED] wrote:
From: Paul Kyzivat <[EMAIL PROTECTED]>
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.
That's the case if handling is 'optional'. But if handling is
'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.
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.
Gee - you're rarely sloppy. :-)
Thanks,
Paul
_______________________________________________
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
