Subject: Re: [dispatch] Telepresence Charter Version 3

From: stephen botzko <[email-masked]>
Date: Wed, 1 Sep 2010 07:08:10 -0400

Hi Christer

The proposed charter is to enable full interoperation of future SIP based
telepresence systems w/o such equipment, by replacing the current
proprietary extensions with a standard.

"Full" interoperation includes enabling the full immersive telepresence
experience with multiple streams (preserving visual scale, gaze awareness,
etc), since existing systems already can fall back to single-screen SIP.

Regards,
Stephen Botzko

On Wed, Sep 1, 2010 at 2:56 AM, Christer Holmberg <
[email-masked]> wrote:

>
> Hi,
>
> A question for clarification.
>
> The proposed charter says that there exists telepresence systems based on
> different standards (SIP, H.xxx etc), and that today expensive
> interworking equipment is required in order for these systems to interop.
>
> But, how can you prevent such interworking? If whatever we specify is
> supposed to be backward compatible with standards compliant systems, you
> cannot assume that every system will support e.g. SIP.
>
> Regards,
>
> Christer
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
> > Sent: 27. elokuuta 2010 2:31
> > To: Cullen Jennings (fluffy)
> > Cc: DISPATCH list
> > Subject: Re: [dispatch] Telepresence Charter Version 3
> >
> > WRT my previous note suggesting the change to Cullen's
> > sentence, people should be clear that everything not in the
> > charter is out of scope.
> > So please think about anything that you think we need to
> > cover which is not now explicitly called out in the charter.
> >
> > thanks
> >
> > -----Original Message-----
> > From: Cullen Jennings (fluffy)
> > Sent: Thursday, August 26, 2010 8:54 AM
> > To: Allyn Romanow (allyn)
> > Cc: DISPATCH list; Mary Barnes
> > Subject: Re: Telepresence Charter Version 3
> >
> >
> > I think this charter has some pretty serious issues with being way to
> > wide open on what the scope is. The fact we are actually discussing if
> > we need to add  in "Also not in scope is signaling to tell the
> > originator to which IP addresses the media streams should be sent"
> > should be a huge hint that we have the scope much too broad.
> > As I said a
> > week ago ....
> >
> > Begin forwarded message:
> >
> > > From: Cullen Jennings <[email-masked]>
> > > Date: August 18, 2010 11:16:22 AM MDT
> >
> > > Main point:
> > > When I read this charter and ask myself what is out of
> > scope, it seems
> > that anything that is "the information about media streams from one
> > endpoint to another endpoint or conference bridge including"
> > would be in
> > scope. I realize a few more things are taken our of scope
> > later but the
> > resulting space includes just about everything that MMUSIC does, and
> > much of what SIP does. Because of the "anything and
> > everything" approach
> > I don't think this is a charter that will result in work that
> > gets done
> > quickly. From the point of view of being broad enough to do the need
> > work, I think it's fine but from the point of view of being narrow
> > enough to limit the work to something that is possible to complete, it
> > seems pretty bad. I suspect that IESG would likely look at this as a
> > "blank cheque" charter and ask for some changes to it. My suggestion
> > would be just to change the "including (but not limited to):" in 3rd
> > paragraph to be
> > >
> > > This working group is chartered to specify the following information
> > about media streams from one endpoint to another endpoint:
> > >
> >
> > Note I am not arguing that there any given piece of work you
> > should not
> > do - I'm just encouraging you to say what problems you are
> > going to do.
> >
> > I would encourage you to specify what this working group is
> > going to do,
> > like you have in the bullet points, and stop leaving it open to do
> > anything including the stuff in bullet points. We should do
> > our best to
> > avoid charters that are so unspecific that they overlap with existing
> > WGs in ways that leave huge questions about which WG a new
> > piece of work
> > should go to.
> >
> > Cullen <with my DISPATCH co-chair hat on>
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>