See
http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt
Content-Disposition is another part of the puzzle, as is use of headers
that refer to body parts using cid: URIs. And the method is another
criterion.
As a more difficult example, what do you suppose you should do if you
receive an INFO message in a dialog, with a content-type of text/plain
and a content-disposition of "render"? How would that handling differ
from what you would do if it was a MESSAGE but otherwise the same?
You can pick out special cases and say "duh - what else could you do
with DTMF digits"? But when you sit down to program a UA you need to
come up with well defined algorithms to decide this stuff. As UAs get
more and more sophisticated in the range of things they can do it will
get more and more important to have semantics be well defined.
My problem with INFO is precisely because it has no semantics of how it
should be processed, or how body parts that it carries should be
processed differently than if the same parts were in some other message.
If there is some header and/or body part that should be processed the
same, regardless of what message it is delivered in, then I have no
problem with using INFO to convey it. But I don't think we have any of
those.
Paul
[EMAIL PROTECTED] wrote:
From: "Christer Holmberg (JO/LMF)" <[EMAIL PROTECTED]>
>Here is another major problem with INFO - there is no header
>that states the purpose of INFO.
>The event header in subscriptions helps identify an event package.
>Therefore an implementation can easily detect if this event
>package is supported or not. With INFO it is much harder to
>detect the purpose of this INFO message. Currently AFAIK the
>content-type in INFO implicitly denotes this.
If I send a DTMF digit, the purpose is to send a DTMF digit :)
>If you are aiming towards a solution that keeps INFO for more
>usages, I would say that we need to resolve this issue first.
I am just trying to figure out what the problem really is.
There is an ambiguity in what Content-Type means: "what sort of media
does this encoded data represent" vs. "what you should do with this
data". I don't think there are any cases in current SIP
implementations where this is a practical problem. I expect that in
most cases where "what you should do with this data" is not completely
implied by "what sort of media this represents", the situation will be
complex enough that the applications will define extension headers to
disambiguate the situation, define extension media types to carry the
"intention", or more likely, represent the data as an XML structure
which explicitly states the intended action.
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
_______________________________________________
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
