Hi Paul,
I have added a few guidelines about this in Section 5 of the new version
of the draft:
http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt
With those guidelines and the behavior defined in other sections, we
should be OK. Let me know if you agree or want to add further
clarifications or behavior.
Thanks,
Gonzalo
Paul Kyzivat wrote:
Revising one point:
Paul Kyzivat wrote:
- What "handling" value should be used for multipart bodies and the
contained body parts?
If a body part is referenced by a cid: url in a header (or in another
body part I suppose), then the handling of the body part should be
required.
On reflection, this is tricky.
If the header containing the reference is optional (as most are), then
recipients that don't understand the header will have no need for the
referenced part. If it were required and they don't support the type,
then they would fail the request. This is bad.
So if processing of the header is optional, then the referenced body
part should have optional handling.
But then there could be a problem if the recipient does understand and
process the header, but doesn't understand the body part, and so because
it is optional doesn't process it. In that case, the cid reference will
be unsatisfied. This could also result in an inappropriate error.
I think the solution here is that if a header contains a cid url, and if
that url cannot be resolved to a body part that is supported, then the
UA should treat it the same as if the header itself was not understood -
typically ignoring it unless there is a Require in effect that demands
failing the request.
An alternative is to require that Content-ID be remembered even for
parts that are not understood, so that references can be resolved even
if they can't be processed. This would allow more precise errors to be
generated. This wouldn't be so hard at an outer level, but it might be
troublesome in conjunction with nesting.
Paul
_______________________________________________
Sip mailing list https://www1.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
