Subject: [clue] Consensus Call: Add description text to a capture scene?

From: Mary Barnes <[email-masked]>
Date: Tue, 22 May 2012 11:36:34 -0500

Resending with a new Subject just to make sure folks pick up on this as a
Consensus call.

On Tue, May 22, 2012 at 11:35 AM, Mary Barnes <[email-masked]>wrote:

> Hi all,
>
> Per the design team meeting this morning, we are doing a consensus call on
> the question as to whether human readable text string should be added to
> the capture scene.
>
> Note that while this came up during discussion of Ticket #8 in a previous
> meeting, it does not impact the state of Ticket #8 which remains open:
> http://trac.tools.ietf.org/wg/clue/trac/ticket/8 (How consumer
> differentiates between multiple capture scenes)
>
> So, if folks could please respond to the following question with a "Yes"
> or "No":
>
> Should a human readable text string be added to the capture scene in the
> framework document?
>
> It would also be helpful (but not required for consensus) if folks could
> provide a brief statement justifying their response for the WG members that
> did not hear the discussion on today's call.
>
> The consensus call closes on Thursday at 5pm Pacific.
>
> Thanks,
> Mary
> CLUE WG co-chair
>
>
>
>
> On Fri, May 18, 2012 at 11:56 AM, Duckworth, Mark <
> [email-masked]> wrote:
>
>> Regarding Ticket #8 - How consumer differentiates between multiple
>> capture scenes.
>> We discussed this a bit on the list, and on the April 10 phone meeting.
>>  I think the group agreed we should add a human readable text string
>> attribute to a capture scene.
>>
>> Here is a proposal for adding text to the framework document section
>> 6.2.1 Capture scene attributes:
>>
>> Description attribute
>>
>> The description attribute is a human readable text string which describes
>> the capture scene.  A provider that advertises multiple capture scenes may
>> use different descriptions to differentiate between them.
>>
>>
>> Do we also want to add a similar description attribute to a media capture?
>>
>> Mark Duckworth
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 May 2012 13:02:39 -0400

On 5/22/12 12:36 PM, Mary Barnes wrote:

>     Should a human readable text string be added to the capture scene in
>     the framework document?

Yes.

I don't think this is sufficient, but I think it is helpful, especially 
to have a way to get things working when better forms of interop fail. 
(If what you are seeing is unacceptable to you, then ideally you could 
pull up a control UI that describes what is available and make some 
alternative choices about what is to be displayed. This might occur 
because you are interoperating with a room from another vendor that you 
have not connected to before.)

Also, AFAIK, it is valid for an MCU to "pass through" some or all of the 
scenes it receives in the advertisements it sends. This could be in lieu 
of doing its own composition into an aggregate scene, or as a 
supplement/alternative to an aggregated scene. When doing that, it would 
be very helpful to have a human description of the source for each scene.

	Thanks,
	Paul (as individual)

---

From: Mary Barnes <[email-masked]>
Date: Tue, 22 May 2012 12:11:21 -0500

Per my reposts on the question (considering Marshall's feedback), do
you believe the string should be optional or mandatory?

Thanks,
Mary.

On Tue, May 22, 2012 at 12:02 PM, Paul Kyzivat <[email-masked]> wrote:
> I don't think this is sufficient, but I think it is helpful, especially to
> have a way to get things working when better forms of interop fail. (If what
> you are seeing is unacceptable to you, then ideally you could pull up a
> control UI that describes what is available and make some alternative
> choices about what is to be displayed. This might occur because you are
> interoperating with a room from another vendor that you have not connected
> to before.)
>
> scenes it receives in the advertisements it sends. This could be in lieu of
> doing its own composition into an aggregate scene, or as a
> supplement/alternative to an aggregated scene. When doing that, it would be
> very helpful to have a human description of the source for each scene.
>
>        Thanks,
>        Paul (as individual)