I like the draft - this looks like exactly they type of think I was
hoping someone would write. Thank you, Cullen
On May 27, 2007, at 12:22 PM, Gonzalo Camarillo wrote:
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
_______________________________________________
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
