Subject: RE: [REMOTEUI] Widex charter proposal draft

From: [email-masked]
Date: Fri, 2 Sep 2005 09:22:24 +0300

I'll have to disagree on this issue. One of the ideas behind the RUI BoF was that the protocol must be service discovery and session setup independent; there was a debate on what this "independent" really means and the answer was that the protocol should be usable with any existing service discover and session mechanism, e.g. SIP/SDP, UPnP, Rendezvous/Bonjour, etc., and that the protocol should not depend on a particular one. The reason behind this assumption/requirement is that we should be able to use the protocol in multiple environments regardless of what is the session setup mechanism in a particular one. For example, in a cellular network SIP/SDP is the right choice but in a home network (see www.dlna.org) where UPnP is used for service discovery we'll have to use UPnP Remote UI to start the ui remoting session.

In order to accommodate this situation and because it is clear that the service discovery and session setup mechanisms needs to negotiate something, the working group should provide the needed parameters to facilitate session setup but we should not include these service discovery and session setup mechanisms in the charter.

Vlad

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Eric Burger
> Sent: 02 September, 2005 05:02
> To: Dave Raggett
> Cc: [email-masked]
> Subject: RE: [REMOTEUI] Widex charter proposal draft
> 
> 
> I would agree on limiting the protocol to SIP, but we should have a
> draft explaining why.  Namely, it is because the updates are
> bi-directional.  If they were uni-directional, HTTP would probably do.
> 
> I would volunteer, but I have to finish my thesis first, and that
> wouldn't make it as a chapter :)
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dave Raggett
> Sent: Thursday, September 01, 2005 10:42 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [REMOTEUI] Widex charter proposal draft
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Some further questions.
> 
> To make the protocol more concrete we might want to bind it to
> SIP and to mention this in the charter.
> 
> SIP is an obvious choice because of its use for establishing
> sessions and for distributing events (represented in XML),
> although the focus has hitherto been on presence information.
> SIP is also widely deployed on desktop and mobile devices.
> Web Services and the widespread deployment of HTTP make the
> latter another candidate worthy of discussion.
> 
> We could also use the charter to constrain the work by mentioning
> technical assumptions. Here are two that I have thought of:
> 
> First, when an event is raised in the user interface, the DOM is 
> responsible for passing it to event handlers according to the
> DOM event capture/bubble model. If an event is passed to a remote 
> handler, the User interface should be able to pass the event to
> the next handler without having to worry about whether or not the
> remote handler calls the stopPropagation method. A similar concern
> relates to the preventDefault method. I therefore suggest that
> these two methods have no effect when called by a remote handler
> of a DOM event. This ensure that events can be asynchronously
> passed off to remote handlers.
> 
> Second, if the user interface wants to modify the document, it
> is required to pass the request as an event to the document owner
> which is then responsible for making the corresponding changes.
> Note that the user interface may involve more than one document
> and that these may have different owners. Moreover, this only
> applies to documents that are under synchronization. Other
> documents may be freely updated by default event handlers or
> local scripts.
> 
> We may also want to constrain what we intend for the framework
> for session initiation. For instance, in:
> 
>    http://whatwg.org/specs/web-apps/current-work/#server-sent
> 
> section 6.1.2 defines an extension to the DOM for a 
> RemoteEventTarget interface that should be supported by any
> object that implements the DOM EventTarget interface. The idea
> is to use URIs to specify the means to subscribe to an event
> or list of events and correspondingly to unsubscribe:
> 
>     // src is used for a URI in both cases
>     interface RemoteEventTarget {
>        void addEventSource(in DOMString src);
>        void removeEventSource(in DOMString src);
>     };
> 
> This is fine for sourcing events from a remote device, but 
> inadequate for our purposes where the UI device needs to
> send selected events to a sink on the application server,
> and to receive DOM mutation/update operations from that
> server. Is this information expressed in the UI markup and
> acted upon by the markup language interpreter, or is it set
> up via an out of band mechanism such as the SIP/SDP etc.
> where the information is passed separately to the markup.
> 
> - -- 
>   Dave Raggett <[email-masked]>  W3C lead for multimodal interaction
>   http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFDFxNIb3AdEmxAsUsRAmelAJ9B9BHwRNY/G42HoRcYzk7LWa26fQCgrabi
> daEL4h0/Myo+4Us6Ct4WbSw=
> =2qaf
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> REMOTEUI mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/remoteui
> 
> _______________________________________________
> REMOTEUI mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/remoteui
> 

_______________________________________________
REMOTEUI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/remoteui

---

From: Dave Raggett <[email-masked]>
Date: Fri, 2 Sep 2005 08:59:02 +0100 (BST)

On Fri, 2 Sep 2005 [email-masked] wrote:

> One of the ideas behind the RUI BoF was that the protocol must be 
> service discovery and session setup independent; there was a 
> debate on what this "independent" really means and the answer was 
> that the protocol should be usable with any existing service 
> discover and session mechanism, e.g. SIP/SDP, UPnP, 
> Rendezvous/Bonjour, etc., and that the protocol should not depend 
> on a particular one.

Sorry for not having made myself clearer. I believe we all agree on 
defining the message formats for DOM events and updates using XML in 
a way that is independent of the transport protocol. However, I feel 
it would be valuable to also provide a normative binding to at least 
one transport protocol such as SIP so that people can implement the 
solution in an interoperable way.

> The reason behind this assumption/requirement is that we should be 
> able to use the protocol in multiple environments regardless of 
> what is the session setup mechanism in a particular one. For 
> example, in a cellular network SIP/SDP is the right choice but in 
> a home network (see www.dlna.org) where UPnP is used for service 
> discovery we'll have to use UPnP Remote UI to start the ui 
> remoting session.

Which event transport protocol would you use in a home network,
and why couldn't we include bindings to that in the spec?

Providing explicit bindings makes the proposal much more concrete
and will attract more implementers.

- --