Subject: [clue] signaling - how do advertisements and configurations work?

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Dec 2012 11:21:19 -0500

Lately there have been various proposals for changing some of the 
details of advertisements and configurations. When trying to compare 
them to the "current" proposal from the framework people have argued 
that the current proposal isn't clear either. Looking back at the 
framework, I agree. I have thought that everyone understood it, whether 
written down or not, but apparently not all understand it the same way.

So here I will attempt to describe how I think advertisements and 
configurations, as currently described in the framework, are *intended* 
to work. Of course I may be wrong. I'm happy to entertain corrections.

I want to get consensus on what the current proposal intends, and then 
update the framework as necessary to be unambiguous about this.

When we are clear what the current proposal is, we can consider 
proposals to alter it.

Please comment whether you think this is as intended, and if it 
sufficiently specified for this level of abstraction.

I'm going to keep this description as abstract as I can while still 
capturing essential details. I would prefer not to get hung up on 
details of syntax. Those can be worked out later.

Advertisement message
=====================

Content:

- a unique version # / identifier, used to refer to this message

- a set of Encoding Groups

- for each Encoding Group, a set of Encodings, each with a
   unique identifier, and each with a number of attributes not relevant
   to this discussion.

- a set of Scenes, each with a number of attributes.
   The ones relevant to this discussion are:
   . one or more Capture Scene Entries.

- a set of Captures, each with a number of attributes.
   The ones relevant to this discussion are:
   . a unique identifier for the Capture
   . a reference to the containing Scene, used to qualify coordinates
   . a reference to one of the Encoding Groups

- each Capture Scene Entry contains references to one or more
   Captures

- a set of Simultaneous Transmission Sets. (set of sets.)

- each Simultaneous Transmission Set contains references to one or
   more Captures.

Rules for how the Advertisement message is constructed:

- I'm saying nothing about how the message is encoded.
   References among elements within the message can be via
   identifiers, or by nesting of xml elements, or whatever.

- Each Encoding is associated with exactly one Encoding Group.

- Each Capture is associated with exactly one Scene

- Each Capture Scene Entry is associated with exactly one Scene

- The Captures referenced from a Capture Scene Entry must
   all be associated with the same Scene that the CSE is
   associated with.

- A Capture may be referenced by more than one CSE.

- The Captures in a Simultaneous Transmission Set
   may be from the same or different Scenes.

Configure message
=================

Content:

- the version # / identifier of a previously received
   Advertisement message.

- a set of Capture Encoding references

- for each Capture Encoding reference,
   . the identifier of a Capture from the Advertisement
   . the identifier of an Encoding from the Advertisement

Rules for how the Configure message is constructed:

- I'm saying nothing about how the message is encoded.
   References among elements within the message can be via
   identifiers, or by nesting of xml elements, or whatever.

- The version # / identifier should identify the most
   recently received Advertisement.

- All of the selected Captures must appear in *one*
   of the Simultaneous Transmission Sets of the Advertisement.

- Each Encoding in the Advertisement may be referenced from
   at most one Capture Encoding reference in the Configure
   message.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 20 Dec 2012 16:13:16 +1100

Hello Paul,

Please see my replies below.

Regards, Christian

On 20/12/2012 3:21 AM, Paul Kyzivat wrote:
> framework, I agree. I have thought that everyone understood it, 
> whether written down or not, but apparently not all understand it the 
> same way.
>
> configurations, as currently described in the framework, are 
> *intended* to work. Of course I may be wrong. I'm happy to entertain 
> corrections.
>
[CNG] Hopefully not a unique "version". A unique identifier. I assume 
that the scope is unique to a CLUE association?
>   . one or more Capture Scene Entries.
[CNG] You seem to have missed attributes for "Capture Scene Entries". 
See section 6.2.2 of the framework.
>   . a unique identifier for the Capture
[CNG] Within what scope is the uniqueness? Unique in an advertisement? 
Unique of the life of the CLUE association?
>   . a reference to one of the Encoding Groups
[CNG] From the framework it seems that the "media type" is implied by 
the identifier.

>   may be from the same or different Scenes.
[CNG] Do we want to add something about media type restrictions? i.e. 
can't mix
> Configure message
[CNG] Isn't the version number related to the Content message? i.e. the 
advertiser and the consumer may in fact support a different maximum version.
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>