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
