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

From: Cullen Jennings <[email-masked]>
Date: Sat, 09 Aug 2003 11:51:55 -0700

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

---

From: Tim Melanchuk <[email-masked]>
Date: Mon, 11 Aug 2003 09:17:32 -0700

will NEW_METHOD also be able to satisfy the requirements for an app
asynchronously pushing messages to a client (e.g. for pre-paid
calling cards) as defined in REQ 4 & 7 of the app-interaction-
framework-01.

alternatively, what SIP message would be used here? the requirements
and context from that draft are below.

timm

from draft-rosenberg-sipping-app-interaction-framework-01:

    In this case, there is no message already in transit that can be used
    as a vehicle for pushing a user interface component. This requires
    that applications can generate their own messages to push a new
    component to a UA:

    REQ 4: A UA application must be able to send a SIP message to the UA
       at the other end of the dialog, asking it to create a new
       interface component.

<snip>

    However, synchronous updates are not sufficient for many
    applications. Frequently, the interface will need to be updated
    asynchronously by the application, without an explicit user action. A
    good example of this is, once again, the pre-paid calling card
    application. The application might like to update the user interface
    when the timer runs out on the call. This introduces several
    requirements:

    REQ 7: It must be possible for an application to asynchronously push
       an update to an existing user interface component, either in a
       message that was already in transit, or by generating a new
       message.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Aug 2003 23:37:45 -0400

I will not stand in the way of concensus on this. A new method is 
acceptable to me.

	Paul