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

From: Adam Roach <[email-masked]>
Date: Mon, 11 Aug 2003 13:10:02 -0500

> will NEW_METHOD also be able to...

No!

This is precisely what I'm trying to avoid happening. Methods
have actual semantics associated with them. They should mean
exactly one thing, not several. INVITE means you're starting
a session. SUBSCRIBE means that you're subscribing to the state
of a resource. MESSAGE means you're sending an instant message.

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.

Otherwise, the actual method names become meaningless. If that's
the path we are going down, consistency would argue for deprecating
all existing methods in favor of a single method (perhaps, "DO"),
and inferring all semantics from some horribly complex combination
of Content-Type, Content-Disposition, Accept, Supported, and similar
header fields.

/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 15:12:20 -0700

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

>>will NEW_METHOD also be able to...
[snip]
> than that, I would argue that there's a fair chance that a new
[snip]

---

From: Dean Willis <[email-masked]>
Date: 13 Aug 2003 10:06:08 -0500

> to "convey" the requested stimulus.

We already have an extensible mechanism for asynchronous non-dialog
"push" type operations.

I really don't yet understand why the UA that supports
interface-component notification doesn't just SUBSCRIBE to the
interface-component-notification event package and then get NOTIFYed
with the new interface component.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Aug 2003 17:07:29 -0400

Having had a chance to think about all of this some more, here are my 
thoughts.

One - I give up on MESSAGE. You (Adam) are right, the semantics don't 
match.

The method we want, I think, has a semantic of "here is the 
information you requested". In this case, it was requested with the 
deposit of the KPML script onto the device. As such, I believe we have 
such a method, and its called NOTIFY (well, I REALLY think its called 
HTTP POST, but I seem to be the only one in that boat...). Also note 
that this is NOT an implicit subscription. It is quite explicit. Its 
just not done with SUBSCRIBE. Given that, lets examine each of the 
concerns you raised about implicit subscriptions and see if they apply:

Adam wrote:
 > - Duration of subscription. RFC 3265 includes an "expires"
 >    parameter on the "Subscription-State" header field for each
 >    NOTIFY. A major implication of this is that you can't
 >    run a subscription for an indeterminate length of time
 >    (such as the duration of an INVITE dialog).  Subscription
 >    duration has two sub-issues:

The duration is exactly equal to the length of the validity of the 
KPML script. That lifetime is defined in the framework. It terminates 
when the dialog terminates. Otherwise, the application can 
"unsubscribe" by pushing a new App-Info header w/o a KPML script for 
that instance (Tim had asked how this is done - see my answer in a 
reply to his note).

 >
 >    - If anything other than a SUBSCRIBE is used to put
 >      the subscription in place, then the subscriber can't
 >      even provide a suggested duration. The notifier must
 >      provide one unilaterally. This is what REFER does.

The duration is as defined above.

 >
 >    - Once this value reaches 0, the subscriber must
 >      resubscribe or the subscription will disappear.
 >      In many cases, this requires an actual SUBSCRIBE
 >      message, which tends to eliminate whatever slight
 >      gain was expected by not having an explicit SUBSCRIBE
 >      in the first place.

Here, the subscription is bound to the lifetime of the dialog, and 
there is no need or possibility to extend it beyond that.

 >
 >  - Correlation. In the general case, whatever mechanism
 >    creates the implicit subscription must include sufficient
 >    information to create a dialog. In the KPML case, it is
 >    not clear how this would happen. For many calls, the
 >    dialog between the calling endpoint and the server
 >    receiving KPML feedback is not the same dialog as the
 >    dialog between the calling and called parties.

In all cases, its not the same dialog.

Correlation is easy. The KPML script IS the subscription. The place to 
send the notify is implied from the URI in the KPML script. We would 
need to clarify in KPML that once that URI is used, subsequent 
notificatiosn to the same URI ought to go on the dialog established by 
the NOTIFY. But, this is a KPML issue.

 >
 >  - Handling of multiple subscriptions in the same dialog.
 >    It was asserted in the SIPPING meeting that this does
 >    not apply to the KPML case. This assertion is *probably*
 >    true, depending on how the "correlation" problem is solved.

See above.

 >
 >  - Filtering. Unless there is a way to add filtering to
 >    the mechanism that creates the subscription, installation
 >    of filters must be provisioned or performed via some
 >    other out-of-band mechanism. With KMPL, it is arguable that
 >    the script itself provides a filtering mechanism.

Exactly. Because the KPML script is the subscription. The digit maps 
in the KPML are EXACTLY a filter.

My argument against a new method, as a result, is the same as the 
general argument against two methods for doing the same thing. I can 
easily see applications later on where, in fact, a SUBSCRIBE gets used 
to get this information, instead of pushing a KPML script in App-Info. 
As a result of this, a NOTIFY would be sent. I think it would be bad 
if the server had to have support for two different methods even 
though they both contain the same information.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Aug 2003 17:13:49 -0400

> to "convey" the requested stimulus.

The new scripts are pushed in App-Info headers. If the application is 
a UA application, it would presumably use a re-INVITE or INFO. If its 
a proxy that started the application, it can't initiate new messages, 
and therefore it needs to wait for something to fly by in which it can 
insert an App-Info header.

An alternative, which we considered, was to have the application do a 
separate session just for the application interaction. So, it would 
generate an INVITE towards the UA. In that case, a "proxy" would be 
able to initiate pushes of new KPML scripts at any time by sending a 
re-INVITE on the separate dialog it just created, for which it is the 
UA. However, this quickly becomes complicated, with a lot more 
messages being exchanged. It also has the drawback of makign security 
harder. If you use sips, and you have scripts pushed in headers in 
in-dialog messages, you can get the property that only proxies on the 
call path (and the UAS) can send scripts to the UA. THats an important 
property. By allowing separate dialogs for this, you now need a 
different authorization tactic. You'd also need GRUUs to allow the 
server in the network to target a request to that device instance.

I would go so far as to say that I wouldn't even mind eliminating the 
push requirement for new scripts. We don't have this in the web. I 
suspect most applications don't really need it - we seem to get by on 
the web without it.

-Jonathan R.