Hi, >>And, if we define a DTMF mime-type, we should of course also say in >>which SIP message it can be used etc. But, again, we should not >>specify the applications that are going to use it. > >But MIME types aren't just defined for SIP. There's a whole >slew of protocols that can use any of the thousands of >definede MIM types for millions of different reasons. SIP is >just one protocol among many.
I don't think we need to say very much about different content types themselves. Because, again, the transport data itself is not directly related to the SIP session, but to the application above. I think we should focus more on whether we need some generic rules when sending application data over SIP, e.g. Whether some content disposition values are not allowed etc. >>On my GSM phone, however, I don't need to active DTMF. If I am asked >>to give my PIN code, I simply press buttons and they are sent as DTMF >>tones. > >But what happens when your GSM phone receives a JPEG image? >How about when it receives a Symbian executable stored in a ZIP file? I don't know - I've only had my phone for a few months, so I'm still in the how-to-use-the-phone-book stage :). But, in any case, I think that is a question for the people implementing the phone applications, and not for the people specifying the protocol used to transport the image. >>IF there are missing parts in the negotiation mechanism, we need to fix that. >> >>Something like: >> >>Accept: application/my-dtmf;method=INFO > >Well, we agree it's broken. We're just debating the >mechanism, and whether it's worth fixing. You and I seem to >think it's worth fixing, others would just rather say "If it >hurts' don't do it!". If something needs to be fixed, I definately think we should do it. >>OR, in the draft defining the content type, we specify that content >>type X can only be sent using this and that method. I belive we do the >>same thing for SDP. > >Once again, content types are defined more broadly than SIP. > >> >>But, so far we haven't been interested in looking into these issues. >>We just say that using INFO is against the spirit of SIP, it causes >>all kind of problems etc etc. > >Not at all. I've said we need a registry of usage contexts >that defines what specific content types and dispositions >mean within that context usage. Lacking that, the safe thing >is not to use INFO. I think Paul has said exactly the same >thing, and that's pretty much what Jonathan has said -- >although I think Jonathan is leaning more towards the "since >defining these usages is hard, let's not use INFO" model. That's probably because people have different opinions about what needs to be defined and registered. I still think that we do NOT need to register how the applications work and what they are actually going to do with the application data sent/received over SIP. Regards, Christer _______________________________________________ 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
