Subject: [clue] Changes in framework-14

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 10 Feb 2014 16:54:52 -0800

Hello,

I implemented the changes we've been talking about.  There are still a few open issues we can continue to discuss, I'll go over those at the design team meeting Feb 11.

Please review the MCC example in section 12.3.3.  I think it is okay now as a complete example, but we might want to add another example, or change this one, pending results of the discussion "How to choose from multiple scenes".

draft-ietf-clue-framework-14 has these changes:

   Changes from 13 to 14:

     1. Fill in section for Security Considerations.

     2. Replace Role placeholder with Participant Information,
        Participant Type, and Scene Information attributes.

     3. Spatial information implies nothing about how constituent
        media captures are combined into a composed MCC.

     4. Clean up MCC example in Section 12.3.3.  Clarify behavior of
        tiled and PIP display windows.  Add audio.  Add new open
        issue about associating incoming packets to original source
        capture.

     5. Remove editor's note and associated statement about RTP
        multiplexing at end of section 5.

     6. Remove editor's note and associated paragraph about
        overloading media channel with both CLUE and non-CLUE usage,
        in section 5.

     7. In section 10, clarify intent of media encodings conforming
        to SDP, even with multiple CLUE message exchanges.  Remove
        associated editor's note.

Regards,
Mark

---

From: Christian Groves <[email-masked]>
Date: Tue, 11 Feb 2014 20:51:06 +1100

Hello Mark,

I've just had a quick look and it looks pretty good.

A nit in Table 19 and 20, CSEs don't have IDs. The CSEs should just be 
CSE, CSE not CSE1 and CSE2.

In Table 22 I'm not sure why the MCCs for the audio don't reference the 
source? Wouldn't they list AC1 to AC5?

Regards, Christian

On 11/02/2014 11:54 AM, Duckworth, Mark wrote:
>
> Hello,
>
> I implemented the changes we’ve been talking about. There are still a 
> few open issues we can continue to discuss, I’ll go over those at the 
> design team meeting Feb 11.
>
> Please review the MCC example in section 12.3.3. I think it is okay 
> now as a complete example, but we might want to add another example, 
> or change this one, pending results of the discussion “How to choose 
> from multiple scenes”.
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 11 Feb 2014 05:29:14 -0800

inline
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, February 11, 2014 4:51 AM
> To: [email-masked]
> Subject: Re: [clue] Changes in framework-14
> 
> Hello Mark,
> 
> A nit in Table 19 and 20, CSEs don't have IDs. The CSEs should just be CSE, CSE
> not CSE1 and CSE2.

[Duckworth, Mark] I think it doesn't really matter if they have IDs or not for this example.  But in fact they do have IDs.  From the data model:
15.2. sceneEntryID attribute
The sceneEntryID attribute is a mandatory attribute containing the
identifier of the capture scene entry represented by the <sceneEntry>
element.

> source? Wouldn't they list AC1 to AC5?

[Duckworth, Mark] They could, but they don't have to.  I think the example works either way.

> > I implemented the changes we've been talking about. There are still a
> > few open issues we can continue to discuss, I'll go over those at the
> > or change this one, pending results of the discussion "How to choose
> > from multiple scenes".
> >

---

From: Christian Groves <[email-masked]>
Date: Wed, 12 Feb 2014 09:34:39 +1100

Hello Mark,

Please see below.

Regards, Christian

> [Duckworth, Mark] They could, but they don't have to.  I think the example works either way.
[CNG] I think we need to clarify this in the framework. We first didn't 
need to provide an ID for CSEs. Then it seems we added the ability for 
CSEs to be included in STSs. This then means that CSEs do need IDs. 
There is text in the framework about Captures needing a Advertisement 
unique Identity but there is no text regarding CSEs (and Scenes due to 
them being added to STSs) needing unique identities. This would also 
mean that all the examples need to be updated to have unique CSE ids. 
i.e. in section 7.1 key points are given for media Captures including 
information about identity. We should do something similar for Scenes 
and CSEs.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 12 Feb 2014 06:25:12 -0800

Hi Christian,
I don't think the framework needs to have any more detail about specific identifiers for CSEs.  It is covered in the data model.
Mark

> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, February 11, 2014 5:35 PM
> To: Duckworth, Mark; [email-masked]
> >> A nit in Table 19 and 20, CSEs don't have IDs. The CSEs should just
> >> be CSE, CSE not CSE1 and CSE2.
> > [Duckworth, Mark] I think it doesn't really matter if they have IDs or not for
> this example.  But in fact they do have IDs.  From the data model:
> >> In Table 22 I'm not sure why the MCCs for the audio don't reference
> >> the source? Wouldn't they list AC1 to AC5?
> [CNG] I think we need to clarify this in the framework. We first didn't need to
> provide an ID for CSEs. Then it seems we added the ability for CSEs to be
> included in STSs. This then means that CSEs do need IDs.
> unique Identity but there is no text regarding CSEs (and Scenes due to them
> being added to STSs) needing unique identities. This would also mean that all
> the examples need to be updated to have unique CSE ids.
> information about identity. We should do something similar for Scenes and
> CSEs.
> 
> 
> 
> >
> >> Regards, Christian
> >>
> >>> I implemented the changes we've been talking about. There are still
> >>> a few open issues we can continue to discuss, I'll go over those at
> >>> the design team meeting Feb 11.
> >>>