Subject: [clue] Status of Ticket #8 how consumer differentiates between capture scenes

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 24 Jul 2012 07:42:35 -0700

The framework includes a couple ways a provider advertisement can include information to differentiate between multiple capture scenes it is advertising.

-          Description attribute for capture scene

-          Content attribute for media captures
When we added the Description attribute, we agreed to keep Ticket #8 open.  Prior to that, we discussed Ticket #8 on the list but I don't remember any specific proposals or consensus other than the Description attribute.

Recently Espen suggested adding another description attribute for media captures<http://www.ietf.org/mail-archive/web/clue/current/msg01664.html>, which could include even more text information to differentiate between scenes, and to differentiate captures within a scene.  I didn't see any responses to Espen's proposal.  I agree this could be useful, but I'm not sure it's necessary.

So if anybody still thinks we need more information in the framework for this issue, can you make a specific proposal?  Or can we close this ticket now?

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jul 2012 11:01:09 -0400

[as individual]

On 7/24/12 10:42 AM, Duckworth, Mark wrote:
> The framework includes a couple ways a provider advertisement can
> include information to differentiate between multiple capture scenes it
> is advertising.
>
> -Description attribute for capture scene
>
> -Content attribute for media captures
>
> When we added the Description attribute, we agreed to keep Ticket #8
> open. Prior to that, we discussed Ticket #8 on the list but I don’t
> remember any specific proposals or consensus other than the Description
> attribute.
>
> Recently Espen suggested adding another description attribute for media
> captures
> <http://www.ietf.org/mail-archive/web/clue/current/msg01664.html>, which
> could include even more text information to differentiate between
> scenes, and to differentiate captures within a scene. I didn’t see any
> responses to Espen’s proposal. I agree this could be useful, but I’m not
> sure it’s necessary.

Useful but not necessary is a perfect description of an optional attribute.

I think it would be very helpful, for a couple of reasons:
- debugging
- to support manual configuration of an endpoint as a fallback
   in case automatic configuration isn't giving satisfactory results.

So I'd like to see this included.

	Thanks,
	Paul

> So if anybody still thinks we need more information in the framework for
> this issue, can you make a specific proposal? Or can we close this
> ticket now?
>
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Wed, 25 Jul 2012 10:59:21 +1000

Hello Mark,

I do think it would be worthwhile to add some further type of 
description about the individual captures. Although I'm not sure just 
including what is basically a free text field is the best way to do 
this. I think this issue of describing captures is also linked to the 
"Content" attribute. As I mentioned in another email I'm currently 
working with Paul to come up with some text / proposal to discuss 
further descriptions of individual captures.

Regards, Christian

On 25/07/2012 12:42 AM, Duckworth, Mark wrote:
> include information to differentiate between multiple capture scenes 
> it is advertising.
>
> remember any specific proposals or consensus other than the 
> Description attribute.
>
> Recently Espen suggested adding another description attribute for 
> media captures 
> <http://www.ietf.org/mail-archive/web/clue/current/msg01664.html>, 
> which could include even more text information to differentiate 
> between scenes, and to differentiate captures within a scene. I didn’t 
> see any responses to Espen’s proposal. I agree this could be useful, 
> but I’m not sure it’s necessary.
>
> So if anybody still thinks we need more information in the framework 
> for this issue, can you make a specific proposal? Or can we close this 
> ticket now?
>
> Mark
>
>
>

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 30 Jul 2012 13:52:53 +0000

What about use cases for providers expressing preferred alternatives and recommended captures. 

UC-1: Alice receives an call from Bob. Bob advertise 3 captures with descriptions VC1="speaker", VC2="audience", VC3="whiteboard". Alice decide that she only want to receive the single most important capture from Bob. 

Another example would be an endpoint two different capture scene entries with two captures, one could be a composed and the other a switched alternative. I assume a receiver would choose what the provider offer as the preferred alternative
 
There is a couple of solution is to this use case 
* We can agree that captures and captures scenes within an advertisement should be sorted in order of priority 
* Add an explicit priority attribute 
* Something else

Cheers 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 25. juli 2012 02:59
To: [email-masked]
Subject: Re: [clue] Status of Ticket #8 how consumer differentiates between capture scenes

Hello Mark,

I do think it would be worthwhile to add some further type of description about the individual captures. Although I'm not sure just including what is basically a free text field is the best way to do this. I think this issue of describing captures is also linked to the "Content" attribute. As I mentioned in another email I'm currently working with Paul to come up with some text / proposal to discuss further descriptions of individual captures.

Regards, Christian

On 25/07/2012 12:42 AM, Duckworth, Mark wrote:
> open. Prior to that, we discussed Ticket #8 on the list but I don't 
> between scenes, and to differentiate captures within a scene. I didn't 
> see any responses to Espen's proposal. I agree this could be useful, 
> but I'm not sure it's necessary.
>