Subject: RE: markup v. sip-events, was: (Re: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping] RE: I-D ACTION:draft-culpepper-sipping-ap p-interact-reqs-00.txt))

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 17 May 2002 06:20:31 -0700

I thought I'd chime in with my thoughts on the current situation. I think
the issues are now muddied but easily separable.

Neither presented draft (in my opinion) is a complete solution and each
focuses on different aspects of the problem space. A lot of the application
interaction problem in my mind is need to separate content, transport and
application component framework [by framework I mean creating & destroying
components, correlating applications and user interface spaces, etc, etc].

Both the drafts being discussed (markup & key-events) present a solution
trying to solve all parts. Markup uses markup for the content, HTTP for
transports & very little component framework (apart from the initial URI
reference & App-Info header). Key-Events uses a purpose-designed content
(which is both a good & bad thing) and SIP Events for the framework &
transport. Additionally, Key-Events focuses only on the input-based contents
and defines a framework for defining packages whereas Markup focuses on
presentation-interfaces and pre-determined input-based interfaces.

I think we all agree that
- Support for Markup is needed at least for HTML, VoiceXML and perhaps
others such as DML. Key-Events (or rather the problem that Key-Event is
trying to solve) only addresses the input-based portion of the problem
space. 
- SIP Events is not a good basis for _general purpose_ application
interaction framework but it is okay for just collecting stimulus (such as
Key-Events). However, whether SIP Events is the best framework for
input-based interaction is a another separable issue.
- It would be nice to have a unified protocol framework for application
interaction (if feasible) so that different components can be treated
homogeneously. [I have not seen any disagreements posted anyway.]

I also contend that
- Markup draft does not adequately define how application components are
defined, updated & destroyed.
- Markup draft does not currently adequately address (IMO) the input-based
functionality that the Key-Events draft was designed for. (This is not to
say that it cannot be or that it is the role of the IETF to define such
mechanisms).

I propose that we treat the Key-Events and Markup drafts as examples of
problems to be solved for particular application components. For example,
yes we need to support HTML, VoiceXML and other markup, yes we want to be
able to interact with new devices interfaces (without requiring a new
version of HTML to be published). 

I propose that these components are treated just as Content (within a SIP
session) - just like media - with a proper SDP usage profile (HTML,
key-events, whatever). 

This allows the debate to move on from the current arguments whether this or
that draft is better - neither draft is complete IMO.  Let's focus on the
framework. Maybe all the transport for application interaction will ONLY be
HTTP or RTP - that's fine. Maybe all the content for application interaction
will ONLY be markup or AVP - that's fine. However, this approach allows
components to be associated in a content-generic manner that is not tied to
just pre-established audio or video media sessions with proper application
control for created components. 

So: An application interaction component is just content in a SIP session.
For all components, an application can homogeneously make use of all
privacy, authentication, encryption, routing, etc features of SIP to
establish the component (in addition to the important session update and
closure functionality). 

Do people have problems with this direction? Yes it needs to be fleshed out
more (especially in the way that a client identifies co-operating
applications, etc) but is it a good direction?

Regards,

Robert.

PS, In relation to Key-Events, if we do proceed in this direction then
Key-Events could be very simply rewritten as a SDP Profile which creates a
TCP connection over which Key-Event Format messages are exchanged (or HTTP
messages). We rewrote the key-events draft (-01) so that there IS a
separation between Key-Event content and the transport framework.

> -----Original Message-----
> From: Bert Culpepper [mailto:[email-masked]]
> Sent: Friday, May 17, 2002 3:05 AM
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]; [email-masked]
> Subject: RE: markup v. sip-events, was: (Re: Side Effects of SUBSCRIBE
> are Harmful (was RE: [Sipping] RE: I-D
> ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt))
> 
> 
> comments (some confirmation) below...
> 
> Jonathan Rosenberg wrote:
> >
> > I think there is general agreement that putting markup in
> > SUBSCRIBEs in
> > order to elicit input is over the edge, so let us move on. I
> > want to get
> > to the heart of the matter, which Bert discusses below.
> >
> > Bert Culpepper wrote:
> > >
> > > For the problem at hand, a SIP Events solution has been
> > proposed and an
> > > even
> > > "richer" approach has been documented.
> >
> > I assume you are talking about draft-rosenberg-sipping-markup.
> 
> Yes, I am.
> 
> >
> > > The SIP Events approach is
> > > simply a
> > > "primitive" that applications can use to derive "user
> > input".  It's an
> > > "indirect" solution to address user application
> > interaction.  But one
> > > that
> > > seemed to be the "right" direction in many folks minds from my
> > > visibility.
> > > It does have the benefit, IMHO, that is uses the same
> > protocol as the
> > > session control protocol.  In addition, it more tightly couples an
> > > "interaction session" with a SIP session, without trying to
> > invent too
> > > much
> > > new semantics.  (Not that defining semantics for a new
> > mechanism is bad
> > > or
> > > hard to do.)
> >
> > I would very much like to see broader discussion of this
> > general issue,
> > which is the framework for solving app interaction
> > requirements. We have
> > two concrete proposals on the table now, which are:
> >
> > draft-rosenberg-sipping-markup
> > draft-culpepper-sip-key-events
> >
> > and some suggestions by Robert for another approach based 
> on sessions,
> > which I think needs some more fleshing out, so I'll focus for
> > now on the
> > above two.
> >
> > Bert, I think, is indirectly arguing above for his
> > sip-key-events draft,
> > based on the following points that he alludes to above (Bert please
> > correct me if I mis-represent your views):
> >
> > * using a sip events mechanism is perceived as "right" by a lot of
> > people
> 
> That's my thinking, based on my perceived "scope" of an 
> acceptable solution
> within the WG.  (however, my perception is changing.)
> 
> >
> > * people like to have one protocol, not multiple (the markup
> > draft uses
> > http)
> >
> > * the key-events draft doesn't try to solve a broader problem (my
> > interpretation of his statement "In addition, it more tightly
> > couples an
> > "interaction session" with a SIP session, without trying to 
> invent too
> > much new semantics. "
> >
> 
> Yes, I have been trying to balance the goals of "solving 
> general problems"
> with "primitives".
> 
> >
> > The first one is not a technical argument, and there has been
> > insufficient list discussion to draw consensus on anything, although
> > rough consensus at the iterm was that the markup approach was
> > a good way
> > forward. The second point to me is totally bogus. The
> > draft-ietf-sip-guidelines has long ago argued that we don't pick
> > protocols based on the goal of minimziation, its about the 
> right tool
> > for the right job. I don't think anyone can legitimately 
> argue that a
> > baseline HTTP implementation is hard, costly, or rare in any devices
> 
> I'll agree here.  And I will say that I often times consider practical
> aspects of solutions.  I'd rather implement a service using a single
> application layer protocol for the interface vs. multiple 
> application layer
> protocols.  But this is not a technical argument, and 
> HTTP/HTML is/should be
> supported by any device that "attaches" to the Internet.
> 
> > these days. The third point is one of perspective. I think
> > that the job
> > of the sipping group is to think about the broader context of
> > problems.
> > In my view, considering user input as restricted to DTMF, keys, and
> > buttons as found on hard phones is limiting. I want to have 
> a unified
> > framework that handles all forms of input, including ones
> > with displays
> > (which inlcude many SIP phones). Thus, I think it is a
> > mistake to pursue
> > a direction which cannot support devices with displays, 
> PCs, or other
> > forms of user input (such as speech recognition).
> 
> Now here I'll say speech recognition is out-of-scope (of what 
> I thought the
> problem is).  Speech recognition requires access to the audio media.
> However, if we're also trying to support an interface between 
> an AS and a
> separate "media server" then the markup framework can cover 
> this.  But a
> separate WG is forming in this area I believe.
> 
> >
> > Robert has argued that the markup framework is not adequate
> > to solve the
> > user input requirements of devices that have knobs, 
> sliders, buttons,
> > and other things. I can't imagine that this is so; markup can be
> > anything. Indeed, one can argue that we already have markups
> > defined for
> > devices with jog dials and soft buttons - its called WAP.
> >
> > So, I encourage folks to have a look at these drafts and 
> provide some
> > input. The conclusion of the interim (as documented in the notes) is
> > that there was agreement that the markup approach was a good
> > one to move
> > forward with, but I'd like to see some list discussion.
> >
> > -Jonthan R.
> >
> >
> 
> I think the main difference between the two proposals is in 
> their scope.
> The markup framework is certainly applicable to many more 
> aspects of user
> interaction than a SIP Events solution that only conveys 
> physical actions.
> I would like to see clear direction on the way forward.
> 
> Thanks,
> Bert
> 
> >
> >
> > --
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > [email-masked]                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH:  (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > 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: Fri, 17 May 2002 11:24:46 -0400

"Fairlie-Cuninghame, Robert" wrote:

> defined, updated & destroyed.

The draft describes a lifecycle. Can you please make a concrete
statement about a problem.

> say that it cannot be or that it is the role of the IETF to define such

You are confusing the framework with a specific markup. I have argued
that one could define a markup (just as you have designed rules in the
key-events draft) that covers an arbitrary user input. Whether there
exists a markup today that fits this need is a good question, to which I
don't know the answer. But, my point is, it is the framework that is
important here.

> session) - just like media - with a proper SDP usage profile (HTML,

I am not sure I agree with this. We are talking about *control*, the
realm of protocols and signaling, not media. 

> applications, etc) but is it a good direction?

I am not convinced at all, but I will withold judgement until there is a
draft.

-Jonathan R.