RE: [XCON] New draft on manipulating state in a conference

["Orit Levin" <oritl at microsoft.com>]

Inline.

> -----Original Message-----
> From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf
Of
> Cullen Jennings
> Sent: Friday, February 18, 2005 6:51 PM
> To: Markus.Isomaki at nokia.com
> Cc: adam at nostrum.com; XCON-IETF
> Subject: Re: [XCON] New draft on manipulating state in a conference
> 
> On 2/18/05 4:59 AM, "Markus.Isomaki at nokia.com"
<Markus.Isomaki at nokia.com>
> wrote:
> 
> > I suppose the main distinction that needs to be made is whether the
> conference
> > control protocol will be based on "data manipulation" vs. "remote
> procedure
> > call" (I'm not sure if this is the best terminology).
> >
> > It seems that the consensus in XCON WG has been that "data
manipulation"
> is
> > not the right way, and that has led to the abandoning of the XCAP
CPCP
> > application usage.
> 
> I don't believe this is the consensus of the WG.

[OL] Based on Marcus posting and the list of companies that I am aware
of and are in favor for the remote procedure approach - I don't think
that we have a consensus or even a clear majority for either of the
approaches.

> So far there is not even
> a
> draft proposal on how to make a "remote procedure" style scheme where
you
> call a operation like "mute" Cullen.
 
[OL] This is not correct: please, open
http://www.ietf.org/internet-drafts/draft-levin-xcon-cccp-01.txt and
search for the modifyMediaStatus primitive. The defined protocol is
fundamentally semantics-oriented (or in other words "remote-procedure"
like) where each primitive "parameters" being strongly typed (using XML
type definitions).

Indeed, for each operation there is a protocol definition question: how
far we want to go. For example, the "mute" operation could be defined
instead as modifyMediaStream or muteMedia operations. Note that this
kind of questions exists at any SW design phase. In our case - the
protocol design phase.

[OL] BTW, just to refer to Marcus previous comment, the proposed
protocol also defines the concept of an atomic request being built as a
sequence of individual operations.
 
>If you consider the type of use cases
> that we have in the media, you realize this is very difficult. It may
be
> close to impossible to do it without inventing a new procedure call or
> parameter list every time someone make a different type of device that
> provides different functionality.

[OL] The beauty of any remote-procedure protocol is that it can include
a function call or calls that "manipulate a data object" without
explicitly defining the internal object semantics. This is exactly to
address the cases you are pointing to.

If you start with a strictly "data manipulation" proposal, the opposite
is not true. As Adam rightly pointed out in his recap of the interim
meeting discussions, it is advantageous to use explicit function calls
to the common part and "the data manipulation approach" for the
"Template" part.

The only way you can achieve both with the same protocol is by having an
umbrella remote-procedure protocol with dedicated functions for data
manipulation "inline" operations.

> Anyways, if we get a concrete proposal,
> we
> can figure out how well it meets our needs.

[OL] Please, do. We will be resubmitting the draft with some
clarifications and more co-authors.

> At the interim meeting I
> thought
> that Henning and I disagreed on this but the more he described what he
was
> thinking of, it sounded very inline with what Brian and I were saying
so
> perhaps other people also mean the same thing as the three of us.
> 
> This is why I have been on the path of the conference has knobs,
dials,
> sliders, and buttons that you manipulate. Now, I don't know that this
> extension to BFCP is the right way to do that - it might be an awful
way.
> XCAP might be better. Something completely different might be better.
> However, I feel fairly strongly that we want to stay on the path we
have
> been on for a long time in the basic semantics of what we are trying
to
> accomplish.
> 
> Cullen
> 
> 
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon