Subject: RE: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jul 2003 08:47:12 -0500

> 7. SIP MESSAGE
> 
> Send a SIP MESSAGE request from the client to the application, 
> containing the digit sequence to report.
> 
> This was a bit of a bending of the semantic of MESSAGE, which is 
> really meant for conveying information for display to a user. 
> However, the issue is mostly philosophical in nature. We didn't
> see any particular technical issue that would prevent this from
> working, unlike all of the above ones which had technical issues.

If we're throwing philosophical objections about the intended
semantics of a method out the window, I'm left wondering why
MESSAGE was selected over OPTIONS for this purpose.

All other things being equal, receipt of a misdirected OPTIONS
will never have harmful effects; meanwhile, receipt of a
MESSAGE with an unrecognized content type has an extremely
high probability of causing a nonzero number of implementations
to pop up a window saying something like:

 +------------------------------------------------------------+
 |  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] |
 +------------------------------------------------------------+

This is what I most emphatically do *not* want to happen. It is
the key reason that I push back against use of MESSAGE for
anything that is not to be rendered to a user, and it is a
proof point that the objections to abusing MESSAGE for general
purpose RPC go beyond philosophy into user experience.

/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: Adam Roach <[email-masked]>
Date: Fri, 18 Jul 2003 02:52:14 -0500

Jonathan Rosenberg [mailto:[email-masked]] writes:

> I must say for the life of me, at this moment I cannot enumerate what 
> kind of issues we have had with implicit subscriptions. Adam 
> - can you 
> enumerate them and we can see which ones might or might not 
> apply here?

I can't create an exhaustive list at the moment, but I can offer
a few problems (many from the SIPPING meeting). Hopefully
Robert can offer additional areas of difficulty, since he's
the one who most deeply regretted choosing implicit subscriptions
for REFER.

 - 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:

   - 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.

   - 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.

 - 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.

 - 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.

 - 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.

I'm certain there were other problems, just based on the
frequency with which the issue arose in REFER; I can't
remember what they were, though.

/a