Eric,
I don't understand how to apply this to sip. 3459 defines the criterion
for REQUIRED as:
If the content gateway cannot pass a body part marked REQUIRED, then
the entire message has failed. In this case, the content gateway
MUST take the appropriate failure action.
That makes sense for a mail gateway. (I don't know if it makes sense for
a mail user agent.) But attempting to apply it to sip still leaves a lot
of questions.
In particular, I can see that in a mail message the multipart bodies
themselves are actually rendered in the sense that they are shown as
nested containers. In sip, in general that won't be the case - much of
the content won't be "rendered", though it may be "processed" in some
sense. Unless we define what we mean by "processing" then I think we
haven't finished.
Consider a few cases:
1. content-type SDP, content-disposition session;handling=required
We know what that means, if in a message where an offer or answer is
allowed, or a preview of an offer or answer, or in an OPTIONS response.
We don't have a meaning for this in other contexts, such as SUBSCRIBE,
NOTIFY, MESSAGE or their responses. If you were to receive the body in
one of those, what should be done? Should that be a 415 response?
2. content-type text/plain, content-disposition render;handling=required
We know what this means in MESSAGE. What should be done in other
requests, or in responses?
3. c-t multipart/mixed, c-d ???;handling=required
c-t SDP, c-d session;handling=required
c-t application/ISUP, c-d signal;handling=optional
I think this should be legal all the same places where (1) is legal.
But a recipient that doesn't understand multipart/mixed will return a 415.
I don't know what the content-disposition should be for the multipart.
I guess for mail the default of render works, because it can really be
rendered. That doesn't make sense for sip in this case.
I have never seen an example using a multipart/mixed that included a
content-disposition for it. AFAIK the default should be
"render;handling=required". But for sip I don't know what it means to
"render" a multipart.
4. c-t multipart/mixed; c-d ???;handling=required
c-t SDP, c-d session;handling=required
This is a little silly, but seems legal. If you can handle (3) then you
should be able to handle this. Somebody that doesn't handle the
multipart would return 415.
5. c-t multipart/mixed; c-d ???;handling=required
c-t multipart/mixed; c-d ???;handling=required
c-t SDP, c-d session;handling=required
This is even sillier. But it raises more issues. If you handle (4), must
you also handle this? If it is acceptable to handle (4) and not handle
this, then what response should there be?
AFAIK these are questions about the application of MIME to sip, that
don't seem to have been handled by the mail work because the issues just
didn't come up there.
Thanks,
Paul
Eric Burger wrote:
Correct. That is the mechanism specified by RFC 3459.
On 6/3/07 6:47 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
From: "DRAGE, Keith \(Keith\)" <[EMAIL PROTECTED]>
Well, at the moment, what I am trying to do is get some understanding of
what we should scope as valid SIP work.
I've been busy, so I may be behind in the discussion, but it's not
clear to me that there is anything that needs to be done specifically
for SIP. I may well be wrong, but my impression is that MIME already
has the features and specifications neede so that a receiver can
decide whether it has adequately "understood" the document when it
only understands some components. These mechanisms are all inherited
by SIP and I would expect be a sufficient set of rules.
E.g., a UAC that sends a request with a multipart body must expect
that some UASs will respond with 415, and have some strategy in place
for dealing with that situation. Similarly, a UAC that sends a nested
multipart body must expect that some UASs will be unable to process
the nested multipart, and will either ignore it or reject the request
(as specified), and the UAC must be prepared to deal with that
situation.
Is there a reason we need to define new, narrower subsets of allowed
behaviors and define a SIP mechanism to negotiate these?
Dale
_______________________________________________
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
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
_______________________________________________
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
