Subject: Re: [clue] CLUE media capture description

From: Mary Barnes <[email-masked]>
Date: Thu, 1 Nov 2012 09:35:26 -0500

I'll let other WG members respond to the details of this proposal.  It
would be helpful if you could forward the document submitted to Q5 unless
it really is as brief as you suggest.  I also have one important comment
below. [MB]

Mary.
CLUE WG co-chair

On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves <
[email-masked]> wrote:

>
> CLUE media capture description
> draft-groves-clue-capture-**attr-00
>
> I won't be attending the IETF next week so as a pre-cursor to next weeks
> CLUE WG meeting  I thought i'd put a few words together about
> draft-groves-clue-capture-**attr-0
> http://datatracker.ietf.org/**doc/draft-groves-clue-capture-**attr/<http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/>
>
> The main idea behind the draft is that a CLUE advertisement should include
> enough information for the receiver to make an educated decision about what
> captures it chooses. Having a had a close look at the content attribute I
> think (for the reasons outlined in the draft) it is insufficient to fully
> describe the multi-stream conferencing environments that CLUE is
> addressing/enabling.
>
> A contribution with essentially the same text as the draft was submitted
> to the recent Q.5/16 meeting to solicit feedback from the people at the
> meeting about the different parameters presented in the draft. In general I
> think people were in agreement that the current Content attribute was not
> sufficient. However it was noted that it needs to be considered how CLUE
> maps to the existing usages of the content attribute and mapping to H.239.
>
[MB] While Q.5 might need to do this, it is absolutely out of scope for the
CLUE WG. It is not in our charter and the requirements clearly state such:
   "Non IETF protocol based systems, such as
   those based on ITU-T Rec. H.323, are out of scope."
[/MB]

>
> Below is a list of attributes and comments. If I've left out anything or
> mispoken hopefully Steve Botzko can correct me.
>
> Presentation
> ------------
> People thought it was worthwhile to know if a capture related to a
> presentation. There was some questioning if it was worthwhile to know if
> the capture was slides, images etc. It was thought it may help where
> multiple presentation streams were used.
>
> View
> ----
> It was clarified that the aim of the attribute is to allow a remote end to
> make an automatic decision on what region of the scene it wants to see. The
> idea is that there is a standard keyword that the remote end could scan for
> e.g. lectern. This is a way of providing meaning to a particular spatial
> area.
>
> Language
> --------
> There seemed to be general support for a language parameter.
>
> Role
> ----
> It was thought that role could be related to "participants" or "material".
> Currently the attribute only discusses role from the aspect of a
> participant. It was also noted that the role may change based on meeting
> type. For example: in the medical use case there could be "Surgeon",
> "Professor", in an accessible conference there could be an "Interpreter" or
> "signer". With respect to Materials it was thought presentation could show
> something like "Agenda", "Contribution".
>
> Priority
> --------
> There was some discussion as to whether this was needed. It was thought
> that if captures were properly described then priority wouldn't be needed
> as the remote end could make an educated decision about what it wants. At
> the moment with the minimal set of attributes it was thought that priority
> at least helped the remote end make a decision.
>
> Dynamic
> -------
> I think people were OK with this being optional.
>
>
> Embedded Text
> -------------
> Again I think people thought it was reasonable. It was clarified this
> could also be used to indicate captioning was being used with the capture.
>
>
> Supplementary description
> -------------------------
> There was some question about how this related to side bar conferences. It
> was clarified this was mainly about the case where information (captures)
> were provided by people (or devices) who were not captured by the
> conference video.
>
> Telepresence
> ------------
> This parameter probably had the least support/understanding. I was noted
> that CLUE was to allow multi-stream operation it didn't necessarily
> indicate/mandate a telepresence experience.
>
> Hopefully this provides some further background for the CLUE discussions.
> If the group could come to some general agreement about each of the
> parameters then I could work on some specific text for the framework (or
> whatever document we decide).
>
> Regards, Christian
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Roni Even <[email-masked]>
Date: Thu, 1 Nov 2012 14:53:45 +0000

Mary,

This draft was submitted more than a month ago and the purpose is to add more content options to allow the consumer to get a better selection and relates to ticket #10 http://trac.tools.ietf.org/wg/clue/trac/ticket/10

Roni Even

________________________________
From: [email-masked] [[email-masked]] on behalf of Mary Barnes [[email-masked]]
Sent: Thursday, November 01, 2012 4:35 PM
To: Christian Groves
Cc: [email-masked]
Subject: Re: [clue] CLUE media capture description

I'll let other WG members respond to the details of this proposal.  It would be helpful if you could forward the document submitted to Q5 unless it really is as brief as you suggest.  I also have one important comment below. [MB]

Mary.
CLUE WG co-chair

On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves <[email-masked]<mailto:[email-masked]>> wrote:

CLUE media capture description
draft-groves-clue-capture-attr-00

I won't be attending the IETF next week so as a pre-cursor to next weeks CLUE WG meeting  I thought i'd put a few words together about draft-groves-clue-capture-attr-0
http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/

The main idea behind the draft is that a CLUE advertisement should include enough information for the receiver to make an educated decision about what captures it chooses. Having a had a close look at the content attribute I think (for the reasons outlined in the draft) it is insufficient to fully describe the multi-stream conferencing environments that CLUE is addressing/enabling.

A contribution with essentially the same text as the draft was submitted to the recent Q.5/16 meeting to solicit feedback from the people at the meeting about the different parameters presented in the draft. In general I think people were in agreement that the current Content attribute was not sufficient. However it was noted that it needs to be considered how CLUE maps to the existing usages of the content attribute and mapping to H.239.
[MB] While Q.5 might need to do this, it is absolutely out of scope for the CLUE WG. It is not in our charter and the requirements clearly state such:
   "Non IETF protocol based systems, such as
   those based on ITU-T Rec. H.323, are out of scope."
[/MB]

Below is a list of attributes and comments. If I've left out anything or mispoken hopefully Steve Botzko can correct me.

Presentation
------------
People thought it was worthwhile to know if a capture related to a presentation. There was some questioning if it was worthwhile to know if the capture was slides, images etc. It was thought it may help where multiple presentation streams were used.

View
----
It was clarified that the aim of the attribute is to allow a remote end to make an automatic decision on what region of the scene it wants to see. The idea is that there is a standard keyword that the remote end could scan for e.g. lectern. This is a way of providing meaning to a particular spatial area.

Language
--------

Role
----
It was thought that role could be related to "participants" or "material". Currently the attribute only discusses role from the aspect of a participant. It was also noted that the role may change based on meeting type. For example: in the medical use case there could be "Surgeon", "Professor", in an accessible conference there could be an "Interpreter" or "signer". With respect to Materials it was thought presentation could show something like "Agenda", "Contribution".

Priority
--------
There was some discussion as to whether this was needed. It was thought that if captures were properly described then priority wouldn't be needed as the remote end could make an educated decision about what it wants. At the moment with the minimal set of attributes it was thought that priority at least helped the remote end make a decision.

Dynamic
-------

Embedded Text
-------------
Again I think people thought it was reasonable. It was clarified this could also be used to indicate captioning was being used with the capture.

Supplementary description
-------------------------
There was some question about how this related to side bar conferences. It was clarified this was mainly about the case where information (captures) were provided by people (or devices) who were not captured by the conference video.

Telepresence
------------
This parameter probably had the least support/understanding. I was noted that CLUE was to allow multi-stream operation it didn't necessarily indicate/mandate a telepresence experience.

Hopefully this provides some further background for the CLUE discussions. If the group could come to some general agreement about each of the parameters then I could work on some specific text for the framework (or whatever document we decide).

Regards, Christian
_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 1 Nov 2012 12:11:53 -0400

I have a couple of clarifications in-line.

Steve B.

On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes <[email-masked]>wrote:

>> The main idea behind the draft is that a CLUE advertisement should
>> include enough information for the receiver to make an educated decision
>> about what captures it chooses. Having a had a close look at the content
>> attribute I think (for the reasons outlined in the draft) it is
>> insufficient to fully describe the multi-stream conferencing environments
>> that CLUE is addressing/enabling.
>>
> [MB] While Q.5 might need to do this, it is absolutely out of scope for
> the CLUE WG. It is not in our charter and the requirements clearly state
> such:
[SB]
I'd like to make three clarifications on this:

-Q5/16 itself is not endorsing Christian's contribution and is not
requesting any action on it from either CLUE or the IETF.  Q5/16 of course
would use the normal liaison mechanisms for that kind of communication.
Christian's draft is an individual draft like any other.

-Q5/16 is following the CLUE work closely, because there is strong support
there for using a consistent approach for multiple streams.  Generally it
has focused most of its attention on aspects of telepresence systems that
are out-of-scope for CLUE, but which are still needed to get good
interoperability.  For instance, specifications for audio levels, video
color space, etc.

-Q5/16 was not considering H.323 specifically when it provided feedback on
Christian's contribution.

Personally I think the draft makes some good points that we should consider.
[/SB]

>> It was clarified that the aim of the attribute is to allow a remote end
>> to make an automatic decision on what region of the scene it wants to see.
>> The idea is that there is a standard keyword that the remote end could scan
>> for e.g. lectern. This is a way of providing meaning to a particular
>> spatial area.
>>
>> Language
>> --------
>> It was thought that role could be related to "participants" or
>> "material". Currently the attribute only discusses role from the aspect of
>> a participant. It was also noted that the role may change based on meeting
>> There was some question about how this related to side bar conferences.
>> It was clarified this was mainly about the case where information
>> (captures) were provided by people (or devices) who were not captured by
>> the conference video.
>>
>> Telepresence
>> ------------

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Nov 2012 11:41:41 +1100

Hello Steve and Mary

Steve, I fully agree with your points. The contribution was provided for 
information as there is a Q5 document which uses much of the work of 
CLUE. The contents of the contribution was the same as the draft apart 
from templates issues so all the information is in 
draft-groves-clue-capture-attr.

With respect to the comment about the scope, I don't think it was 
suggested that CLUE have a work item to define things for H.323 systems. 
The point was more that there are existing uses of the values related to 
the Content Attribute in both SIP and H.323 systems that work in with 
the control that H.239 offers. I think that interoperability with these 
systems should at least be considered when making protocol/design 
decisions. If we can make a choice which allows easier interworking why 
wouldn't we do that? I don't see that as out of scope.

Regards, Christian

On 2/11/2012 3:11 AM, Stephen Botzko wrote:
> On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I'll let other WG members respond to the details of this proposal.
>      It would be helpful if you could forward the document submitted
>     to Q5 unless it really is as brief as you suggest.  I also have
>     one important comment below. [MB]
>
>     Mary.
>     CLUE WG co-chair
>
>     On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         I won't be attending the IETF next week so as a pre-cursor to
>         next weeks CLUE WG meeting  I thought i'd put a few words
>         together about draft-groves-clue-capture-attr-0
>         The main idea behind the draft is that a CLUE advertisement
>         should include enough information for the receiver to make an
>         educated decision about what captures it chooses. Having a had
>         a close look at the content attribute I think (for the reasons
>         outlined in the draft) it is insufficient to fully describe
>         the multi-stream conferencing environments that CLUE is
>         addressing/enabling.
>
>         A contribution with essentially the same text as the draft was
>         submitted to the recent Q.5/16 meeting to solicit feedback
>         from the people at the meeting about the different parameters
>         presented in the draft. In general I think people were in
>         agreement that the current Content attribute was not
>         sufficient. However it was noted that it needs to be
>         considered how CLUE maps to the existing usages of the content
>         attribute and mapping to H.239.
>
>     [MB] While Q.5 might need to do this, it is absolutely out of
>     scope for the CLUE WG. It is not in our charter and the
>     requirements clearly state such:
> requesting any action on it from either CLUE or the IETF. Q5/16 of 
> course would use the normal liaison mechanisms for that kind of 
> communication.  Christian's draft is an individual draft like any other.
>
> -Q5/16 is following the CLUE work closely, because there is strong 
> support there for using a consistent approach for multiple streams.  
> Generally it has focused most of its attention on aspects of 
> telepresence systems that are out-of-scope for CLUE, but which are 
> still needed to get good interoperability.  For instance, 
> specifications for audio levels, video color space, etc.
>
> -Q5/16 was not considering H.323 specifically when it provided 
> feedback on Christian's contribution.
>
>         Below is a list of attributes and comments. If I've left out
>         anything or mispoken hopefully Steve Botzko can correct me.
>
>         Presentation
>         ------------
>         People thought it was worthwhile to know if a capture related
>         to a presentation. There was some questioning if it was
>         worthwhile to know if the capture was slides, images etc. It
>         was thought it may help where multiple presentation streams
>         were used.
>
>         View
>         ----
>         It was clarified that the aim of the attribute is to allow a
>         remote end to make an automatic decision on what region of the
>         scene it wants to see. The idea is that there is a standard
>         keyword that the remote end could scan for e.g. lectern. This
>         is a way of providing meaning to a particular spatial area.
>
>         Language
>         --------
>         "material". Currently the attribute only discusses role from
>         the aspect of a participant. It was also noted that the role
>         may change based on meeting type. For example: in the medical
>         use case there could be "Surgeon", "Professor", in an
>         accessible conference there could be an "Interpreter" or
>         "signer". With respect to Materials it was thought
>         presentation could show something like "Agenda", "Contribution".
>
>         Priority
>         --------
>         There was some discussion as to whether this was needed. It
>         was thought that if captures were properly described then
>         priority wouldn't be needed as the remote end could make an
>         educated decision about what it wants. At the moment with the
>         minimal set of attributes it was thought that priority at
>         least helped the remote end make a decision.
>
>         Dynamic
>         -------
>         Again I think people thought it was reasonable. It was
>         clarified this could also be used to indicate captioning was
>         being used with the capture.
>
>
>         There was some question about how this related to side bar
>         conferences. It was clarified this was mainly about the case
>         where information (captures) were provided by people (or
>         devices) who were not captured by the conference video.
>
>         Telepresence
>         ------------
>         This parameter probably had the least support/understanding. I
>         was noted that CLUE was to allow multi-stream operation it
>         didn't necessarily indicate/mandate a telepresence experience.
>
>         Hopefully this provides some further background for the CLUE
>         discussions. If the group could come to some general agreement
>         about each of the parameters then I could work on some
>         specific text for the framework (or whatever document we decide).
>
>         Regards, Christian
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 2 Nov 2012 11:55:53 -0500

On Thu, Nov 1, 2012 at 7:41 PM, Christian Groves <
[email-masked]> wrote:

> information as there is a Q5 document which uses much of the work of CLUE.
> The contents of the contribution was the same as the draft apart from
> templates issues so all the information is in draft-groves-clue-capture-**
> attr.
>
> the Content Attribute in both SIP and H.323 systems that work in with the
> control that H.239 offers. I think that interoperability with these systems
> should at least be considered when making protocol/design decisions. If we
> can make a choice which allows easier interworking why wouldn't we do that?
> I don't see that as out of scope.
>
 [MB] It's WBN if it works with H.323 - it is not in scope and we will not
be making decisions based on that interworking.  It is not in scope for
CLUE nor the IETF.  Certainly, you as an individual can bring contributions
that you have evaluated that would work for both, but our decisions within
this WG will be based upon what works best for the CLUE protocol being
defined in IETF which is based on using SIP signaling. [/MB]

>> On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes <[email-masked]<mailto:
>> mary.ietf.barnes@**gmail.com <[email-masked]>>> wrote:
>>
>>     <mailto:Christian.Groves@**nteczone.com<[email-masked]>>>
>> wrote:
>>
>>
>>         together about draft-groves-clue-capture-**attr-0
>>         http://datatracker.ietf.org/**doc/draft-groves-clue-capture-**
>> attr/ <http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/>
>>
>>  Generally it has focused most of its attention on aspects of telepresence
>> systems that are out-of-scope for CLUE, but which are still needed to get
>> good interoperability.  For instance, specifications for audio levels,
>> video color space, etc.
>>
>> -Q5/16 was not considering H.323 specifically when it provided feedback
>> on Christian's contribution.
>>

---

From: Christian Groves <[email-masked]>
Date: Mon, 05 Nov 2012 13:07:44 +1100

Hello Mary,

I don't see why considering interoperability with H.323 (or other open 
standards) is absolutely out of scope?

I understand the requirements document mentions that H.323 is in out of 
scope of the document however, from the approved CLUE charter (Charter 
charter-ietf-clue-01):

"The working group may identify interoperability obstacles in existing 
open standards. If so, the WG will develop requirements to be 
communicated to other IETF WGs or Standards Forums, or recharter as 
appropriate."

All I was trying to do was point out that there may be some issues 
around the use of Content.

Regards, Christian

On 3/11/2012 3:55 AM, Mary Barnes wrote:
>
>
> On Thu, Nov 1, 2012 at 7:41 PM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello Steve and Mary
>
>     Steve, I fully agree with your points. The contribution was
>     provided for information as there is a Q5 document which uses much
>     of the work of CLUE. The contents of the contribution was the same
>     as the draft apart from templates issues so all the information is
>     in draft-groves-clue-capture-attr.
>
>     suggested that CLUE have a work item to define things for H.323
>     systems. The point was more that there are existing uses of the
>     values related to the Content Attribute in both SIP and H.323
>     systems that work in with the control that H.239 offers. I think
>     that interoperability with these systems should at least be
>     considered when making protocol/design decisions. If we can make a
>     choice which allows easier interworking why wouldn't we do that? I
>     don't see that as out of scope.
>
>  [MB] It's WBN if it works with H.323 - it is not in scope and we will 
> not be making decisions based on that interworking.  It is not in 
> scope for CLUE nor the IETF.  Certainly, you as an individual can 
> bring contributions that you have evaluated that would work for both, 
> but our decisions within this WG will be based upon what works best 
> for the CLUE protocol being defined in IETF which is based on using 
> SIP signaling. [/MB]
>
>
>     Regards, Christian
>
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked]>
>             <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>
>         -Q5/16 itself is not endorsing Christian's contribution and is
>         not requesting any action on it from either CLUE or the IETF.
>         Q5/16 of course would use the normal liaison mechanisms for
>         that kind of communication.  Christian's draft is an
>         individual draft like any other.
>
>         -Q5/16 is following the CLUE work closely, because there is
>         strong support there for using a consistent approach for
>         multiple streams.  Generally it has focused most of its
>         attention on aspects of telepresence systems that are
>         out-of-scope for CLUE, but which are still needed to get good
>         interoperability.  For instance, specifications for audio
>         levels, video color space, etc.
>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>