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 14:09:44 -0500

Yes, except without the "in a dialog" requirement. You could
call it "CALL" (borrowing the term from RFC 1057).

More realistically, a specific new method (say, FEEDBACK) that
has semantics of collecting input from a user would seem to be
a well-scoped and reasonable way to go about sending this
information.

/a

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Monday, July 14, 2003 13:46
> To: sipping
> Subject: RE: [Sipping] How to report DTMF - conclusion of the app
> interaction design team: SIP MESSAGE
> 
> 
> Hmmm.  Alan pointed out that would be equivalent to INFO.  
> You know, the application-to-application signaling message.
> 
> > -----Original Message-----
> > From: Eric Burger 
> > Sent: Mon, July 14, 2003 11:30 AM
> > To: Adam Roach; Jonathan Rosenberg; sipping
> > Subject: RE: [Sipping] How to report DTMF - conclusion of the app
> > interaction design team: SIP MESSAGE
> > 
> > 
> > That is incredibly sensible.
> > 
> > Sounds like time for a dip into the well of method space for 
> > a new method name.  Can we get away with, "just like MESSAGE, 
> > but without the user interaction expectations"?  That is what 
> > it is, after all.
> > 
> > > -----Original Message-----
> > > From: Adam Roach [mailto:[email-masked]]
> > > Sent: Mon, July 14, 2003 9:47 AM
> > > To: Jonathan Rosenberg; sipping
> > > Subject: RE: [Sipping] How to report DTMF - conclusion of the app
> > > interaction design team: SIP MESSAGE
> > > 
> > > 
> > > > 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
> > 
> > 
> 
> 
> _______________________________________________
> 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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Jul 2003 19:41:24 -0400

To be honest, I am starting to warm on an implicit subscription 
(though HTTP remains my preference), since NOTIFY is really the method 
we already have for FEEDBACK.

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?

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