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

[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