Christer Holmberg (JO/LMF) wrote: > 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. > 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? > 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!". > 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. -- Dean _______________________________________________ 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
