Subject: RE: [Sipping] DTMF: Why Not A New Method?

From: "Chris Boulton" <[email-masked]>
Date: Mon, 11 Aug 2003 10:18:46 +0100

NEW_MTHOD gets my vote.

Chris.

>-----Original Message-----
>From: Cullen Jennings [mailto:[email-masked]]
>Sent: 09 August 2003 19:52
>To: sipping
>Cc: Adam Roach
>Subject: Re: [Sipping] DTMF: Why Not A New Method?
>
>
>There has been some discussion on the MESSAGE vs. NEW_METHOD for
reporting
>the information from KPML. I don't think I have heard any strong
argument
>for MESSAGE over NEW_METHOD but I have gotten a little lost on the
whole
>argument.
>
>I think we might have consensus on NEW_METHOD but I'm not sure. I don't
>care
>but I think we need to make a decision on this and get on with it. Do
we
>have consensus on this?
>
>Cullen
>
>
>
>On 7/24/03 13:56, "Adam Roach" <[email-masked]> wrote:
>
>> Oh, in that case...
>>
>> +------------------------------------------------------------+
>> |  You have received an IM of type "application/kpml+xml",   |
>> |  which is not a registered media type.                     |
>> |                                                            |
>> |  [x] Save it as a file                                     |
>> |  [ ] Open it with application: ________________            |
>> |                                                            |
>> |  [x] Always ask when handing type "application/kpml+xml"   |
>> |                                                            |
>> |                                             [OK]  [Cancel] |
>> +------------------------------------------------------------+
>>
>> /a
>>
>
>
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Mon, 11 Aug 2003 11:41:58 +0100

Cullen and others,

I haven't been following the discussion too closely, but if we do decide to have a new method, could we aim to make it reasonably generic?  I don't have a proposal really, but it seems there are a few problems floating around already where people end up suggesting that MESSAGE can be (ab)used to solve them.  I guess we're talking about a way of passing 'information' that, unlike INFO, is NOT necessarily related to an ongoing session?

Regards,

Duncan

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
Sent: 09 August 2003 19:52
To: sipping
Cc: Adam Roach
Subject: Re: [Sipping] DTMF: Why Not A New Method?

There has been some discussion on the MESSAGE vs. NEW_METHOD for reporting
the information from KPML. I don't think I have heard any strong argument
for MESSAGE over NEW_METHOD but I have gotten a little lost on the whole
argument.

I think we might have consensus on NEW_METHOD but I'm not sure. I don't care
but I think we need to make a decision on this and get on with it. Do we
have consensus on this?

Cullen

---

From: "Mills, Duncan, D, CND Tech Dev, VF UK" <[email-masked]>
Date: Tue, 12 Aug 2003 09:03:50 +0100

Tim,

You appear to be coming from the same angle as me.  If we are considering having a new method for KPML, because MESSAGE is being abused, then we may well find that we need other new methods to cover other areas where MESSAGE could be abused.  Pushing something from an application server to an end-user is one area where people are already wrongly proposing to use MESSAGE.

I never really meant to say that we define a generic method with very broad semantics.  (Wrist slapped, mouth washed).  My mail was probably worded badly.  I merely meant to say that there are probably a couple of areas where a new method is perhaps needed, and maybe if we think about it, we only need one method to meet the requirements of these areas?

I guess any new method would be bi-directional anyway, so for instance, if the new method was called "PUSH", then it could be used from an end-user to an application to push key-presses and it could be used from an application server to an end-point to push (e.g.) an interface component.

Rather than having a new method to solve the key press issue and a second new method to solve the 'push' issue.  Maybe this is obvious to everyone?

Cheers,

Duncan

-----Original Message-----
From: Tim Melanchuk [mailto:[email-masked]]
Sent: 11 August 2003 23:12
To: Adam Roach
Cc: Cullen Jennings; sipping
Subject: Re: [Sipping] DTMF: Why Not A New Method?

fine, i'm all for precisely defined semantics.

the app-interaction-framework seems to me to identify a requirement
for an application to asynchronously push an interface component.
am i reading this correctly? if not, fine. if so, what method should
be used there, and, if we need a new method for that as well, perhaps
we should look at 2 new methods. one to "request" stimulus and one
to "convey" the requested stimulus.

note, i'm simply trying to understand how different proposals/drafts
fit together. i'm not advocating violating sacrosanct principles of
protocol design :-)

timm

Adam Roach wrote:

>>will NEW_METHOD also be able to...
> 
> 
> No!
> 
[snip]
> 
> The new method that we define for KPML should also mean precisely
> one thing: "I'm conveying requested stimulus from the user."
> 
> If you need to define something else with different semantics
> than that, I would argue that there's a fair chance that a new
> method is indicated.
> 
[snip]

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Wed, 13 Aug 2003 12:44:04 -0400

Folks:

Unless Adam would explain to us why MESSAGE is not good to transfer
DTMF, we would probably not know precisely why we need to a new METHOD
for DTMF reporting.

Similarly, Jonathan also explained why INFO is a problem for DTMF
reporting.

The semantics of all other methods in SIP seem to be pretty clear how to
use them, and no controversies appear how and when to use them to
satisfy many needs.

Can I request Adam and Jonathan to write the BCP drafts for both MESSAGE
and INFO method, respectively, explaining the things how to use these
methods as they have been explaining in the email threads?

Best regards,

Radhika R. Roy
[email-masked]

PS: Vendors are implementing many things using INFO and MESSAGE method,
and let us minimize those non-interoperable implementations.