Hi Paul,
> The interaction with handling=required would be that if you are not able
> to find a reference to a 'by-reference' body part with
> handling=required, you report an error because you have not been able to
> process the body part.
Hmm. I guess that makes sense. It means that any time there is an
optional header with a reference to a body part then the handling of
that body part needs to be optional. But again I guess that makes good
sense.
Not really. I create an extension that consists of a header field (which
is optional as any other new header field) that points to a body of
disposition type 'by-reference'. If I want to make sure that the UAS
understands the extension, I set the body's handling parameter to required.
If the UAS does not understand the header field, it will not find any
reference to the body. Therefore, it will not be able to process it and
will return an error response.
Of course, this could also be done with an option-tag in a Require
header field.
Some interesting questions arise when body parts are being processed by
middleboxes. (Maybe we aren't supposed to talk about that here.) The
whole issue of handling=required gets messy there. The middlebox isn't
the intended recipient, so the handling parameter doesn't really apply
to it.
Well, this is true (or we want to think it is true) in SIP. But this is
what RFC 3459 has to say about optional body parts:
An OPTIONAL body part is one the sender doesn't care whether the
receiving system delivers it or not. A content gateway can silently
delete such body parts if the receiving system cannot deliver the
part.
Maybe we should add some clarifying text in the draft before B2BUA
implementers decide to remove all optional body parts they get their
hands on :o)
So presumably it processes whatever headers and body parts it
likes. That is another motivation for making the decision about
processing be explicit - so it can be selective.
yes, being explicit is always good.
Cheers,
Gonzalo
_______________________________________________
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
