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

From: "Eric Burger" <[email-masked]>
Date: Mon, 14 Jul 2003 11:30:13 -0400

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

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 14 Jul 2003 14:46:22 -0400

Hmmm.  Alan pointed out that would be equivalent to INFO.  You know, the application-to-application signaling message.

> From: Eric Burger 
> Sent: Mon, July 14, 2003 11:30 AM
> To: Adam Roach; Jonathan Rosenberg; sipping
> 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.
>

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 14 Jul 2003 15:25:59 -0400

I like it -- say what we mean.

> Sent: Mon, July 14, 2003 3:10 PM
> To: Eric Burger; sipping
> 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
> 
> 
> > From: Eric Burger [mailto:[email-masked]]
> > Sent: Monday, July 14, 2003 13:46
> > To: sipping
> > Hmmm.  Alan pointed out that would be equivalent to INFO.  
> > You know, the application-to-application signaling message.
> > 
> > > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 17 Jul 2003 05:30:13 -0400

Mostly goofs on my part.

Thoughts in-line.

> -----Original Message----- From: Steve Fisher [mailto:[email-masked]]
[snip]
> 1) The framework document refers to both "one shot" and "monitor"
> models, and while KPML supports both, support for the 
> "monitor" model is
> somewhat awkward (requires having the device quarantine 
> digits and then
> issue a new KPML document via a re-INVITE). Is there a reason the
> initial KPML document couldn't just specify which model was 
> desired for
> that particular interaction, and, if "monitor" was desired, 
> simply keep
> monitoring for the specified digits? If we've adandoned HTTP 
> reporting,
> I don't see what the downside to this would be.

I realized that I didn't have that described.  It will be an attribute to the kpml tag.

> 2) I think that some example message flows would be helpful to tie all
> these pieces together, and I would be happy to help draft 
> some if you'd like.

I like :-)

> 3) An Jonathan said in the note below, the KPML draft still describes
> HTTP reporting, and also mentions NOTIFY. Just to clarify -- are these
> mistakes, and the team is now only proposing to use MESSAGE?

That is still up for discussion.  I'm leaning toward NOTIFY/FEEDBACK/FOO rather than HTTP.  However, there is a contingent that feels HTTP is a reasonable mechanism.  The nice thing is KPML exists outside either.  It is up to the interpreter to "do the right thing" if it encounters a sip: or a http: or a bar: scheme.

> 4) I also would prefer a new SIP method, instead of 
> overloading MESSAGE.

Yes.

> 5) I'm confused how the device determines the Request-URI for the
> MESSAGE. The KPML document says:
> 
>    When the
>    user enters keypress(es) that match a <regex> tag, the user device
>    will issue a SIP MESSAGE to the Request-URI specified by the href
>    attribute. 
>  
> and
> 
>    The specification of any scheme-specific part, that is, anything
>    following the colon in "sip:", is an error.  The interpreter MUST
>    reject the request.
> 
> If the href attribute can't specify any scheme-specific part, how does
> the device determine the Request-URI from the href attribute?

Definite cut & paste error where I forgot to cut :-)

Thanks for the close reading!

--
- Eric

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 23 Jul 2003 14:02:45 +0100

I don't really see this as a major problem either BUT I still don't like
the fact that we are 'bending' the use of MESSAGE in the first place.
By defining a new METHOD, all of these discussions go away.

Chris.

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: 23 July 2003 13:42
>To: Rohan Mahy
>Cc: Jonathan Rosenberg; sipping
>Subject: Re: [Sipping] How to report DTMF - conclusion of the app
>Rohan - see below.
>	Paul
>Rohan Mahy wrote:
>> On Thursday, July 17, 2003, at 02:58 PM, Paul Kyzivat wrote:
>>
>>>
>>>
>>> Jonathan Rosenberg wrote:
>>>
>>>> 7. SIP MESSAGE
>>>> However, the issue is mostly philosophical in nature. We didnt see
>>>> any particular technical issue that would prevent this from
working,
>>>> unlike all of the above ones which had technical issues.
>>>
>>>
>>> Adam gave some good examples of bad things that might happen if the
>>> UAS was confused and attempted to render this to a user. But there
are
>>> mechanisms already in place to deal with this.
>>>
>>> For one thing, the application already has an opportunity to pick
the
>>> address to which the MESSAGEs are sent. So it should be able to
ensure
>>> that the recipient knows these messages shouldn't be displayed
>>> directly to an end-user.
>>>
>>> Beyond that, there is the Content-Disposition header, which seems
>>> intended for purposes like this. In the normal use of MESSAGE for
IM,
>>> the obvious content type is "render". Here we don't want that, so we
>>> should pick some other content type.
>>
>>
>> Paul,
>>
>> small comment here.  KPML *is* rendered to the user.  The distinction
>> that you are seeking between "just through this up on the
>> display/speaker" vs. "interpret this markup and show the result to
the
>> user"  does not exist and in fact is the antithesis of the motivation
>> for the term render.  You "render" HTML and XML+XSL and VoiceXML to a
>> user.  KPML should be no different.
>
>I think we are talking about different things. AFAIK this discussion is
>about how the results of processing the KPML are reported back. I agree
>the KPML is rendered, but the results aren't (at least necessarily)
>rendered to the requesting application's "user".
>
>I don't really see a big problem with using MESSAGE here even without
>content-disposition, but some people do, so I am proposing a way out of
>the perceived problem.
>
>	Paul
>
>