Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 16 Jul 2014 14:25:22 -0700

Hi Paul,
Thanks for all the comments. Responses inline.
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Sunday, June 29, 2014 8:23 PM
> To: [email-masked]
> Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt
>
> I apologize for being late with my own pre-WGLC review comments on this.
> I ended up spending a lot more time on it than I allotted. (And I
> procrastinated.) Also, I know there are some overlaps between my
> comments and Christians. I've left them in because it is easier than removing
> them and I may have some different nuances.
>
> And here I am speaking as an individual, not a chair.
>
> References:
>
> There is no separate section for References. They are found at the end of
> the "Changes since last version" section. I assume this is a bug.
[Duckworth, Mark] I think you mean it should be section number 17?  I'll fix that.  It's been that way for a long time, not sure why.

> Section 1:
>
> In the following:
>
>     The signaling details and data model are provided
>     in subsequent documents.
>
> ISTM that the documents aren't "subsequent", in that there is no natural
> ordering relationship among them. I suggest "separate" (or "companion")
> documents. E.g.,
[Duckworth, Mark] I agree

>     Companion documents describe signaling details [reference] and
>     the data model. [reference]
> (These documents aren't currently in the references.)
[Duckworth, Mark] I agree we should add those to the references.  Should we itemize all the "companion documents" here, with very brief description of them?

> Section 3:
>
> Re Capture Device:
>
>     Capture Device: A device that converts audio and video input into
>     an electrical signal, in most cases to be fed into a media encoder.
>
> This definition only applies to audio and video. (E.g., it excludes real-time
> text.) The grouping taxonomy defines it as:
>     a physical entity performing a Media Capture transformation.
[Duckworth, Mark] How about changing the definition to: "A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder "
This should cover cameras, microphones, keyboards...

> Re Capture Encoding:
>
> Can we relate this directly to the grouping taxonomy? The taxonomy already
> does so, saying it is
>
>     a term to describe an Encoded Stream
>
> I'm not certain this is quite right - I think the description is of more than the
> Encoded stream - maybe a "Source RTP Stream". Whatever we decide, we
> should ensure that the fw and the taxonomy are updated to be consistent.
[Duckworth, Mark] Previous discussion led to Bo updating the taxonomy to say "Telepresence specifications from CLUE WG uses this term to describe an Encoded Stream (Section 2.1.7) related to CLUE specific semantic information."  Do you think we need further clarification?  Is this an issue for the taxonomy document?

[Duckworth, Mark] The definitions in CLUE framework are supposed to be normative, so we can't define them in terms of the Informational taxonomy document, can we?

> Re Endpoint: I think we could align better with the taxonomy. (We are pretty
> close.)
[Duckworth, Mark] I think it's not close, it's a different concept.  My understanding is that A CLUE endpoint can have multiple taxonomy end points.  An MCU is not a CLUE endpoint, but an MCU includes taxonomy end points.  What do you suggest we change?

> Re Front:
>
>     Front: the portion of the room closest to the cameras.  In going
>     towards back you move away from the cameras.
>
> Do we need this? It is only referenced once, in the definition of spatial
> relationships.
>
> Also, unless all the cameras are placed on the same side of the room it is not
> unique. (There is a separate Front for each camera.)
[Duckworth, Mark] I think we need the definition, but maybe just in the spatial relation section and not explicitly in the definitions section, is that what you mean?  I understand your point about cameras in different locations.  I think each Capture Scene must have a unique Front direction, because it is supposed to have a single coordinate system for everything in the scene, even if cameras are in different places.  Should we try to clarify this in the document?

> Re MCU:
>
> The taxonomy now has what seems to be a good definition of MCU. Can we
> refer to that one? We may have to specialize the definition for our purposes
> - requiring that it support CLUE. (That might mean we need to have a
> different name, such as CLUE MCU.)
[Duckworth, Mark] The taxonomy does have a good description of MCU, describing how current common usage of the term MCU maps to other terms defined in taxonomy.  I agree this is consistent with CLUE's usage of MCU.  Maybe we should update the CLUE definition to be more like the taxonomy definition?  Or help me understand how a reference to the Informational taxonomy doc could work.

> Re Media Capture:
>
> Our definition differs from the taxonomy in a significant way. Ours describes
> it as a form of "data" while the taxonomy describes it as a process. I'm not
> quite sure what to recommend for aligning these. I suspect one or the other
> needs to be renamed.
[Duckworth, Mark] I think it is good the way it is.  CLUE definition is "a source of Media, such as from one or more Capture Devices or constructed from other Media streams".  I think the source of media can be from a process (or transformation, as the taxonomy calls it).  Taxonomy says : "Telepresence specifications from CLUE WG uses this term to describe either a Media Capture (Section 2.1.2) or a Media Source (Section 2.1.4), depending on in which context the term is used."  I think this is accurate.

> Re Media Consumer:
>
>     Media Consumer: an Endpoint or middle box that receives Media
>     streams
>
> I think "Media Streams" is too general here. I suggest:
>
>     Media Consumer: an Endpoint or middle box that is capable of
>     receiving Media Encodings.
[Duckworth, Mark] Do you mean "... capable of receiving Capture Encodings"?  I would agree with that.

> Re Media Provider:
>
> Similar to above I suggest:
>
>     Media Provider: an Endpoint or middle box that is capable of
>     sending Media Encodings.
[Duckworth, Mark] I would agree with "... capable of sending Capture Encodings"

> Re Multiple Content Capture:
>
> This is limited to audio and video. Couldn't we potentially have an MCC for
> switched or mixed real-time text? How about:
>
>     Multiple Content Capture: A Capture that mixes and/or switches
>     other Captures of a single type. (E.g. all audio or all video.)
>     Particular Media Captures may or may not be present in the
>     resultant Capture Encoding depending on time or space.  Denoted as
>     MCCn in the example cases in this document.
[Duckworth, Mark] I agree.

> Instead of just mentioning that MCCn may be used in examples, shouldn't
> we actually define MCC as an abbreviation?
[Duckworth, Mark] I agree.  How about just using "Multiple Content Capture (MCC): A Capture that mixes...", which is how we do it for defining CSE.

> Re Stream:
>
> Can we relate this to the taxonomy? I think this corresponds to both a
> "Source RTP Stream" and a "Received RTP Stream".
[Duckworth, Mark] I agree.  Can we keep our current definition, and add an informative reference to the taxonomy about this?

> Re Middlebox:
>
> This term isn't defined but it is used. I think it deserves a definition.
[Duckworth, Mark] I agree, but I don't have a good suggestion for a definition :(  Is it more general than an MCU?  Is a device that has user agents for signaling, but no media handling, considered a middle box?

> Section 4:
>
> The following:
>
>     ... In a few circumstances, a CLUE Endpoint middlebox
>     includes only Consumer or Provider functionality, such as
>     recorder-type Consumers or webcam-type Providers. ...
>
> I *think* this should say "Endpoint *or* middlebox".
[Duckworth, Mark] I agree.

> Section 5:
>
> The following:
>
>     This Advertisement and Configure MUST occur during call initiation
>     but MAY also happen at any time throughout the call, whenever there
>     is a change in what the Consumer wants to receive or (perhaps less
>     common) the Provider can send.
>
> seems overly restrictive. This need not occur during *call* initiation.
> It is possible to initiate a call, but not enable clue until later. How
> about:
>
>     This Advertisement and Configure MUST occur once use of CLUE has
>     been enabled in a call, but MAY also happen at any time throughout
>     the call, whenever there is a change in what the Consumer wants to
>     receive or (perhaps less common) the Provider can send.
[Duckworth, Mark] I agree

> Figure 1 doesn't include the Global Capture Scene Entry List.
[Duckworth, Mark] It is there in version -16

> Section 6 says:
>
>     X increases from Camera-Left to Camera-Right
>     Y increases from front to back
>
> (Also see my comment on the definition of "Front".)
>
> Defining the coordinates relative to a camera is problematic since there can
> be multiple cameras. (Consider case where we have cameras facing the
> audience and others facing speakers in front of the audience.)
>
> I'm not sure we can say anything better than that the X,Y coordinates should
> be chosen to be sensible for the set of captures to be offered.
> Perhaps an example where all the cameras point in generally the same
> direction would get the point across.
[Duckworth, Mark] We could clarify this.  I'll try to propose something more specific.

> Section 7.1.1:
>
> Isn't mono/stereo now gone as a capture attribute?
[Duckworth, Mark] Yes, I'll remove that.

> Section 7.1.1.2:
>
> Perhaps we should say that the Point on Line of Capture actually defines not
> just the axis, but a vector indicating the direction of capture?
[Duckworth, Mark] I agree

> Section 7.1.1.3:
>
> I guess some restructuring is needed to limit area of capture to video.
[Duckworth, Mark] Does area of capture apply only to video?  Or can it apply to any media type other than audio?  framework-16 simply says it does not apply to audio.

> Section 7.1.1.5:
>
> Didn't we agree to remove this. (That it will be handled as part of an
> encoding.)
[Duckworth, Mark] The "Audio Channel Format" section is removed in framework-16.

> Section 7.2.1.2:
>
> The explanation of 'index' is pretty fuzzy. ISTM that the meaning really needs
> to be specified separately for each token. E.g., for SoundLevel N means the
> N'th most recent loudest speaker. For RoundRobin it is harder to describe.
[Duckworth, Mark] Makes sense for SoundLevel.  Do we want to have an index for RoundRobin?  I suppose it could make sense there too.  But I think the current definition of the index is adequate.

> Section 7.2.1.3:
>
> I have read this several times, and while I know this is about site switching I
> cannot figure it out from the words written here. Even the example isn't
> helping me (and I don't think it should take an example to make it
> understandable.)
[Duckworth, Mark] I think there is a word missing: "To indicate that the Capture Encodings associated with MCCs contain captures from the *same*source at the same time..."  It seems clear to me, so does anybody else have a suggestion for how to make this more clear?

> For instance, ISTM that the synchronization id and the policy can give
> conflicting criteria for what is included at each point in time. And also the max
> captures may define a composition policy that would violate the
> synchronization.
[Duckworth, Mark] I agree it is possible for a provider to do that in an advertisement.  I don't think we can prevent this syntactically in the data model.  I think it is okay to leave it this way.

> Section 7.3:
>
> I have a question: Can a scene have captures that are not included in any
> CSE? If not, then there probably ought to be something that says that. If so,
> then there are other issues. If so, then presumably it should be possible to
> have scenes with no CSEs. (Did we have this discussion previously?)
[Duckworth, Mark] I thought we didn't want to have captures that were not in a CSE.  But then maybe the addition of MCC concept would change that.  An MCC can include an individual capture from the same scene, and that individual capture might not have an encoding group, so then maybe in some cases it wouldn't make sense to put that capture into a CSE?  I'm not sure what problems there would be if there are captures that are not in a CSE.  What problems do you see?

> I suggest that the following:
>
>     ... A Capture Scene includes one
>     or more Capture Scene entries, with each entry including one or
>     more Media Captures. ...
>
> be tweaked by: s/Media Captures/Media Captures of the same media type/
[Duckworth, Mark] I agree.

> In the following:
>
>     A provider MAY express spatial relationships between Captures that
>     are included in the same Capture Scene.  However, there is not
>     necessarily the same spatial relationship between Media Captures
>     that are in different Capture Scenes.  In other words, Capture
>     Scenes can use their own spatial measurement system as outlined
>     above in section 6.
>
> saying capture scenes *can* user their own spatial measurement system
> suggests the contrary is a possibility - that they may share a spatial
> measurement system. That isn't really true. We assume that each scene is
> spatially unrelated to every other scene. So I suggest revising this as:
>
>     A provider MAY express spatial relationships between Captures that
>     are included in the same Capture Scene.  However, there is no
>     spatial relationship between Media Captures from
>     different Capture Scenes.  In other words, Capture
>     Scenes each use their own spatial measurement system as outlined
>     above in section 6.
[Duckworth, Mark] I agree.

> While reading this section I find Capture Scene *Entry* to be a poor name for
> what it represents. ISTM that each CSE selects a set of captures that,
> together, represent a view of the entire scene. (Some better than others.) I
> think a better name for this would be *Scene View*.
>
> (I realize that while only a nomenclature change, this is a fundamental
> element we use in talking to one another and so is mentally hard to change.
> But I think we at least ought to consider it as making clue more
> understandable to outsiders. And of course we can consider other names.)
>
> Making such a change would of course result in renaming a number of other
> things. I won't call those out specifically.
[Duckworth, Mark] We can consider this.

> Section 7.3.3:
>
> The following isn't quite right:
>
>     ... Each item in this list is a set of one or more
>     Capture Scene Entries of the same media type. ...
>
> I can read this and think that CSEs are actually contained in this. It is important
> that what is included are *references* to CSEs defined in scenes. So I
> suggest:
>
>     ... Each item in this list is a set of references to one or more
>     of the Capture Scene Entries of the same media type that are
>     defined within scenes of the same advertisement. ...
[Duckworth, Mark] I agree

> And, in line with my comment about the naming of CSE, I think we can find a
> more understandable name for this thing than Global CSE List.
> (IIRC the current name was my idea.)
>
> I'm thinking *Global View* would work as the name for one element of this
> list. And then I guess the list of them would be *Global View List*.
>
> If we did all that, then 7.3.3 would start out as:
>
>     7.3.3. Global View List
>
>     An advertisement can include an optional Global View List.
>     Each item in this list is a Global View. Each Global
>     View is a set of one or more references to Scene Views of the same
>     media type, defined within scenes of the same advertisement.
>     Each Global View is a suggestion from the Provider to the
>     Consumer for some Scene Views that provide a complete view of the
>     simultaneous captures provided by the provider, across the multiple
>     scenes of the advertisement.  The Provider can include a Global
>     View List to help a consumer to choose sets of captures appropriate
>     to its capabilities or application. The choice of how to make these
>     suggestions in the Global View List, for what represents all
>     the scenes for which the provider can send media, is up to the
>     provider.  This is very similar to how each Scene View represents a
>     particular scene.
>
> (But we would certainly add Global View to the definitions, and so part of the
> above might appear there rather than here.)
[Duckworth, Mark] I think we should consider these suggestions to improve the naming of these things.

> Section 8:
>
> The following:
>
>     ... If a
>     Capture Scene is included in a Simultaneous Transmission Set, then
>     all its Capture Scene Entries (of the corresponding media type) are
>     included in the Simultaneous Transmission Set. ...
>
> implies that there is some mechanism to determine the media type of the
> simultaneous transmission set. Currently it is only determined by the type of
> its entries. But if all the entries are scenes, then that isn't good enough. I can
> think of a variety of fixes for this. We should discuss how to fix this.
[Duckworth, Mark] I think this is an issue for the data model, not the framework.

> I find the following ambiguous or at least hard to understand:
>
>     If an Advertisement does not include Simultaneous Transmission
>     Sets, then the Provider MUST be able to provide all Capture Scenes
>     simultaneously.  If multiple capture Scene Entries are in a Capture
>     Scene then the Consumer chooses at most one Capture Scene Entry per
>     Capture Scene for each media type.  Likewise, if there are no
>     Simultaneous Transmission Sets and there is a global CSE list, then
>     the Consumer chooses at most one set of CSEs of each media type,
>     from the global CSE list.
>
> It switches from what the provider MUST do (be able to provide all capture
> scenes simultaneously), to what the consumer does, which doesn't seem to
> be normative.
[Duckworth, Mark] I agree we should reword it, to describe what the provider's advertisement means, without describing it as what the consumer does.

> What is missing is a definition of what it means to be able to provide a
> capture scene. I think "be able to provide a capture scene" means: be able to
> simultaneously provide all of the captures in any single CSE of the scene.
>
> If that is right, then the question is how to write that as a clear normative
> statement. Either we can try to come up with text that says the above, or
> else we could say that there is a default simultaneous transmission set and
> come up with an algorithm to derive it from the CSEs in the advertisement.
> (The algorithm is straightforward, but describing it in text is not.) Here is a cut
> at the text:
>
>     If an Advertisement does not include Simultaneous Transmission
>     Sets, then the Provider MUST be able to simultaneously provide
>     all the captures from any one CSE of each media type from each
>     capture scene.
[Duckworth, Mark] This is an improvement for the beginning of the paragraph.  Then I think the rest of the paragraph should continue to describe what the provider's advertisement means rather than describing what the consumer does.

> Section 9.3:
>
> I have some concerns with the first paragraph:
>
>     Each Media Capture MAY be associated with at least one Encoding
>     Group, which is used to instantiate that Capture into one or more
>     Capture Encodings.  Typically MCCs are assigned an Encoding Group
>     and thus become a Capture Encoding.  The Captures (including other
>     MCCs) referenced by the MCC do not need to be assigned to an
>     Encoding Group. This means that all the Media Captures referenced
>     by the MCC will appear in the Capture Encoding according to any MCC
>     attributes. This allows an Advertiser to specify Capture attributes
>     associated with the Media Captures without the need to provide an
>     individual Capture Encoding for each of the inputs.
>
> The construction "MAY be associated with at least one" seems awkward, and
> doesn't not the key point that if a capture is to be eligible for configuration it
> MUST be associated with at least one. And then, "Typically MCCs are
> assigned an Encoding Group and thus become a Capture Encoding" implies
> that the assignment of the MCC to an encoding group
> *causes* to become a Capture Encoding, which isn't right. I think the
> following clarifies both of those points:
>
>     Each Media Capture, including MCCs, MAY be associated with one or
>     more Encoding Groups. To be eligible for configuration, a Media
>     Capture MUST be associated with at least one Encoding Group, which
>     is used to instantiate that Capture into one or more Capture
>     Encodings. When an MCC is configured all the Media Captures
>     referenced by the MCC will appear in the Capture Encoding according
>     to the attributes of the chosen encoding of the MCC. This allows an
>     Advertiser to specify encoding attributes associated with the Media
>     Captures without the need to provide an individual Capture Encoding
>     for each of the inputs.
[Duckworth, Mark] That is a good improvement.

> Section 10:
>
> Some of the text in this section is out of date with changes we have made
> along the way. This is most obvious in:
>
>     For each Capture the Consumer wants to receive, it configures one
>     or more of the encodings in that capture's encoding group.  The
>     Consumer does this by telling the Provider, in its Configure
>     Message, parameters such as the resolution, frame rate, bandwidth,
>     etc. for each Capture Encodings for its chosen Captures.  ...
>
> This suggests that resolution, frame rate, bandwidth, etc. are specified as
> part of the Configure, which is no longer true.
>
> (I have been getting a similar feeling in earlier sections, but in each case I
> could read it as ok, because "parameters" could mean other things.)
>
> For the moment I'm not going to suggest a specific fix. It could be fixed
> "here" with some minor rewording. But if we want to fix it document wide
> then that should be done in a unified way.
[Duckworth, Mark] This is fixed in version -16.  I tried to fix it in all places in the document.  Please let me know if you find any more problems like this.

> And related to that is:
>
>     In order to meaningfully create and send an initial Configure, the
>     Consumer needs to have received at least one Advertisement from the
>     Provider.
>
> It is now also necessary to have received an offer defining encodings of the
> captures of interest to the consumer. I think some rewording is required.
[Duckworth, Mark] I agree.

> Section 12.1.1:
>
> Area of Capture needs to come out for the audio captures, replaced by point
> of capture and point on line of capture.
[Duckworth, Mark] Done in version -16.

> More important, based on our audio discussions, does it make sense to
> provide separate audio captures for each camera? If not, what does make
> sense? Perhaps just a single mono audio, a single surround sound audio, and
> an audio for the presentation?
[Duckworth, Mark] I don't know what you mean.  The example already has three separate captures (AC0, AC1, AC2) corresponding to the three cameras.  Plus AC3 for the whole room.  Plus AC4 to go with the presentation video.

> There is a reference to MCC5, which is not defined.
[Duckworth, Mark] It should be VC5.

> Section 12.2:
>
> This says:
>
>     A sane, basic, algorithm might be for the consumer to go through
>     each Capture Scene in turn and find the collection of Video
>     Captures that best matches the number of screens it has ...
>
> But this doesn't say anything about CSEs - implying that ignoring them is
> sensible. It is *possible*, but explaining how to decide in that case is very
> complex. I would think for the purposes here we would want to recommend
> going through the CSEs looking for one that best exploits the locally available
> equipment.
>
> Did the above mean to say "... go through each CSE in turn ..."?
[Duckworth, Mark] Yes, that makes more sense.

> Section 12.3.1:
>
> Table 14 doesn't leave the consumer with much choice. For instance there is
> no choice that works for a consumer that can handle only one video stream.
>
> ISTM that it would be better to merge tables 13 and 14, so that the consumer
> can have both one-encoding and two-encoding options.
[Duckworth, Mark] I think either way is just as good for the purpose of the example, which is to illustrate basic usage of MCCs.

> Section 12.3.3:
>
> The following appears after Table 20:
>
>     Rather than considering what is displayed the CLUE concentrates
>     more on what the MCU sends. The MCU doesn't know anything about
>     the number of screens an endpoint has.
>
> Something is wrong with this - "the CLUE" makes no sense. Should "the"
> be omitted, or was "this example" intended?
[Duckworth, Mark] "the" should be omitted.

> I also see a reference to section 7.3.2 that isn't linked (in the html) to the
> actual section. Perhaps it is by value rather than reference in the source???
[Duckworth, Mark] Yes, I think there are multiple instances of using text values rather than actual references in the source.  I have to fix those.  Right now our source is Microsoft Word format.  I have to decide whether to keep it in Word, or port it back to XML.  Are there any good reasons to port it back to XML?

> Section 15:
>
> There is a reference to "section x", that needs to be updated to reference to
> proper section.
[Duckworth, Mark] Yes.

> THE END
>       Thanks,
>       Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 16 Jul 2014 14:36:58 -0700

Christian,
Thanks for the suggestions.  Comments below.
Mark

... snip...

> >> Cl.3 General: Do we need a term to describe when multiple Capture
> >> Scenes are used to give an overall "picture" of the endpoint, i.e. GCSE?
> > [Duckworth, Mark] I don't think we need a new term in section 3.
> [CNG] I see Paul has a comment about GCSEs.
[Duckworth, Mark] Yes, let's continue the discussion based on Paul's comments.
..snip

> >> Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no
> >> spatial relationship between scenes. However this paragraph is a little
> "fuzzy"
> >> implying there may be relationship between scenes. Whilst physically
> >> there may a relationship a consumer has no way of knowing this. The
> >> default behaviour will not be to associate scenes.
> > [Duckworth, Mark] I don't see anything that implies a relationship between
> scenes.  Which sentences specifically do you mean?
> [CNG] The sentence I'm referring to is "However, there is not necessarily the
> same spatial relationship between Media Captures that are in different
> Capture Scenes." "Not necessarily" to me means there may or may not be a
> spatial relationship between capture in different scenes.
[Duckworth, Mark] Paul had a good suggestion to improve this.
..snip

> >> Cl.9.2: There is no explicit mention of whether individual encodings
> >> of multiple media types i.e. audio and video can belong to a single group.
> > [Duckworth, Mark] The data model restricts an encoding group to a
> particular media type.
> [CNG] Yes but you shouldn't have to look at the data model to find this out. I
> think the inclusion of a sentence to the effect that encoding groups are
> limited to a single media type would be beneficial.
[Duckworth, Mark] See separate email dedicated to this issue.

> >> Cl.10 para.2: I don't see the "special" handling outlined in this
> >> paragraph. A consumer would have a separate CLUE channel with each
> >> provider and treat the associations differently?
> > [Duckworth, Mark] I don't understand your point.  Do you think this
> paragraph is unnecessary?
> [CNG] Yes, it doesn't seem to add alot. An endpoint or an MCU need to
> respond with a Configure based on the Advertisement and the MC
> capabilities.
[Duckworth, Mark] Okay with me to remove this paragraph, the one that starts with "If multiple Providers connect to the same Consumer..."  Does anybody else think removing this is a good idea?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Jul 2014 19:39:29 -0400

I'll reply more fully later. But I want to start discussion on one thing:

You ask how we make a normative document like this depend on definitions 
in an informative document - the taxonomy.

I don't know the answer to this. I'm interested to hear if somebody 
feels qualified to give a definitive answer.

But my common sense answer to this is: ISTM that a document that only 
contains definitions can never be normative. But I think it is still ok 
for another document to make normative references to it.

What do others think? Who can we ask for an authoritative answer?

	Thanks,
	Paul

---

From: John Leslie <[email-masked]>
Date: Thu, 17 Jul 2014 14:52:16 -0400

Paul Kyzivat <[email-masked]> wrote:
> [<[email-masked]> wrote:]
> 
>> [Duckworth, Mark] The taxonomy does have a good description of MCU,
>> describing how current common usage of the term MCU maps to other
>> terms defined in taxonomy. I agree this is consistent with CLUE's
>> usage of MCU. Maybe we should update the CLUE definition to be
>> more like the taxonomy definition? Or help me understand how a
>> reference to the Informational taxonomy doc could work.
> 

   The magic word is "downref"

   A good starting point is the DOWNREF Registry:

http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

   The standards-track document must contain a Normative Reference
to the document with the needed definiton, and the IETF LastCall
must specifically note the "downref".

   (The Document Shephard should make sure that happens -- it's
common to have to repeat the LastCall to call out the downref.)

   RFC 3987 is _not_ exhaustive in its listing of conditions where
this is appropriate: in practice, it's rare today for anyone to
object to a downref.

--
John Leslie <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jul 2014 17:51:30 -0400

Hi Mark,

Comments scattered throughout.

> [Duckworth, Mark] I think you mean it should be section number 17?  I'll fix that.  It's been that way for a long time, not sure why.

Yes. Normally the top level section would be "References" with 
subsections for Normative References and Informative References.

> [Duckworth, Mark] I agree we should add those to the references.  Should we itemize all the "companion documents" here, with very brief description of them?

This has already been separately discussed.

> This should cover cameras, microphones, keyboards...

OK

> [Duckworth, Mark] Previous discussion led to Bo updating the taxonomy to say "Telepresence specifications from CLUE WG uses this term to describe an Encoded Stream (Section 2.1.7) related to CLUE s…

I'm not sure what the best way is to align these.
Maybe we can find time to have a discussion with Bo about it.

> [Duckworth, Mark] The definitions in CLUE framework are supposed to be normative, so we can't define them in terms of the Informational taxonomy document, can we?

Discussed elsewhere. I think the answer is "yes we can".

> [Duckworth, Mark] I think it's not close, it's a different concept.  My understanding is that A CLUE endpoint can have multiple taxonomy end points.  An MCU is not a CLUE endpoint, but an MCU inclu…

Again I think we need to talk with Bo. The taxonomy is confusing. It has 
"End Point" and "Endpoint". (Where Endpoint is taken from CLUE.)

I also think it is a problem that, because we say an MCU is not an 
Endpoint, we have no term that describes something that "does" CLUE. 
This has been fixed in the signaling draft. It defined CLUE-capable device.

Perhaps we should import its definitions into the framework. Then both 
Endpoint and MCU are CLUE-capable devices.

We might be better off formally make our terms "CLUE-Endpoint" and 
"CLUE-MCU", and then say that we often shorten them to just Endpoint and 
MCU in text. Then we can define CLUE-MCU as a MCU (from taxonomy) that 
supports CLUE.

> [Duckworth, Mark] I think we need the definition, but maybe just in the spatial relation section and not explicitly in the definitions section, is that what you mean?

I meant maybe we don't need a defined term at all. In the few places we 
need the concept just say more explicitly what we mean.

> I understand your point about cameras in different locations.  I think each Capture Scene must have a unique Front direction, because it is supposed to have a single coordinate system for everything in the scene, even if cameras are in different places.

We have clearly defined that a scene has a single coordinate system.
That doesn't mean that we must define front/back/left/right for a 
coordinate system. I don't see why that is helpful.

ISTM that if we need them at all, then we should have "Camera-Front" and 
"Camera-Back".

Also, I think there are problems with camera-left/right too. They are 
defined from the perspective of a person observing rendered media. That 
only works for a consumer, not a provider. And two consumers doing 
identical configurations of the same advertisement might choose to 
render differently so as to get different camera-left/right.

ISTM that camera-* should be defined from the perspective of the axis of 
capture of the capture device, treated as a vector. Then Camera-Front is 
the direction of axis of capture, while Camera-Back is the opposite. And 
then for Camera-Left and Camera-Right construct a line perpendicular to 
both the axis of capture and the vertical axis. Left and Right are 
opposite directions on that - but I can't think how to choose which. 
Probably the "right hand rule". (Note this isn't well defined for 
cameras that point straight up or down.)

> Should we try to clarify this in the document?
>
>> Re MCU:
>>

See above.

> [Duckworth, Mark] I think it is good the way it is.  CLUE definition is "a source of Media, such as from one or more Capture Devices or constructed from other Media streams".  I think the source of…

OK

> [Duckworth, Mark] Do you mean "... capable of receiving Capture Encodings"?  I would agree with that.

OK. But based on my earlier reference to signaling defs, how about:

    Media Consumer: a CLUE-Capable device that is capable of receiving
       Media Encodings.

> [Duckworth, Mark] I would agree with "... capable of sending Capture Encodings"

Same comment.

> [Duckworth, Mark] I agree.  How about just using "Multiple Content Capture (MCC): A Capture that mixes...", which is how we do it for defining CSE.

OK

> [Duckworth, Mark] I agree.  Can we keep our current definition, and add an informative reference to the taxonomy about this?

OK

> [Duckworth, Mark] I agree, but I don't have a good suggestion for a definition :(  Is it more general than an MCU?  Is a device that has user agents for signaling, but no media handling, considered…

I think we *might* be able to just use MCU and drop use of middlebox.
If there are cases where that isn't sufficient, then somebody needs to 
explain to me what was intended.

> [Duckworth, Mark] I agree.

Looking again, I think thisis an appropriate place to use CLUE-capable 
device.

> [Duckworth, Mark] It is there in version -16

OK. Ideally the figure would show the relationships between the GCSE and 
the CSE entries. But I don't think it is feasible to show in one figure, 
especially with ascii art.

> [Duckworth, Mark] Does area of capture apply only to video?  Or can it apply to any media type other than audio?  framework-16 simply says it does not apply to audio.

Well, what types of media do we currently know of: audio, video, text.

area of capture applies to video, not audio.

What about text? I don't think so. *Maybe* point of capture applies. 
(Center of the keyboard?)

Does axis of capture apply to text? I don't think so.

So I think each type of media has distinct geometric attributes that 
describe it.

What would we use for smell? (Actually it may be similar to audio.)

> [Duckworth, Mark] Makes sense for SoundLevel.  Do we want to have an index for RoundRobin?  I suppose it could make sense there too.  But I think the current definition of the index is adequate.

I suspect there is a reason to have have an index for each kind. But 
what that index *means* has to be defined separately for each kind.

> [Duckworth, Mark] I think there is a word missing: "To indicate that the Capture Encodings associated with MCCs contain captures from the *same*source at the same time..."  It seems clear to me, so…

Still not working for me. How about:

"All MCCs sharing a common value for Synchronization Identity MUST, at 
each point in time, contain captures from a single source."

I think that is close, but "source" is wrong. I think we want "Site", 
but that isn't a defined term. Maybe "Endpoint" works:

"All MCCs sharing a common value for Synchronization Identity MUST, at 
each point in time, contain captures from a single Endpoint."

> [Duckworth, Mark] I agree it is possible for a provider to do that in an advertisement.  I don't think we can prevent this syntactically in the data model.  I think it is okay to leave it this way.

My head aches now. So for now I guess its ok to ignore this.

> [Duckworth, Mark] I thought we didn't want to have captures that were not in a CSE.  But then maybe the addition of MCC concept would change that.  An MCC can include an individual capture from the…

Yeah, I guess that is a good enough reason to allow this.

> [Duckworth, Mark] We can consider this.

I'm glad you agree. I think it is important, though perhaps painful to 
make the change. But I am biased since it is my idea. I think we need to 
talk about it.

> [Duckworth, Mark] I think this is an issue for the data model, not the framework.

I think it is still a semantic issue. The data model will be constructed 
to be consistent with the FW.

I forget whether we allow captures of different media types to be in the 
same STS. I *think* we discussed this and decided it was ok.

*If* that is so, then I think you can simply omit "(of the corresponding 
media type)" from the above. But, if we want to restrict a single STS to 
a single media type and we want to allow including whole scenes in an 
STS, then we must provide a way to break the ambiguity. I can think of a 
couple of ways, but its easier to allow STSs to include all types. (Even 
if most of them won't.)

> [Duckworth, Mark] This is an improvement for the beginning of the paragraph.  Then I think the rest of the paragraph should continue to describe what the provider's advertisement means rather than…

OK

> [Duckworth, Mark] This is fixed in version -16.  I tried to fix it in all places in the document.  Please let me know if you find any more problems like this.

OK

> [Duckworth, Mark] I don't know what you mean.  The example already has three separate captures (AC0, AC1, AC2) corresponding to the three cameras.  Plus AC3 for the whole room.  Plus AC4 to go with…

I know it does. And I am questioning whether that makes sense.

Doing some very rough plotting on paper, it appears that the AC0 is in 
front of VC0, AC1 is in front of VC2, and AC2 is in front of VC1. They 
are not in a line - AC2 is further back. All have axis of capture 
pointing (roughly) toward their corresponding screen.

(I find the axis of capture surprising. I would expect it to point in 
the opposite direction - in the direction that the microphones 
presumably point.)

But how much do these overlap in coverage? If somebody configures these, 
how would they render them to get reasonable results?

But maybe it is good to have such an example because it will force 
confronting such issues.

> [Duckworth, Mark] It should be VC5.

OK

> [Duckworth, Mark] Yes, I think there are multiple instances of using text values rather than actual references in the source.  I have to fix those.  Right now our source is Microsoft Word format.…

I am not going to ask you to convert to xml at this point. (It's a huge 
job.) If you have gotten this far with Word and have no compelling 
reason to change then just continue on.

---

From: Christian Groves <[email-masked]>
Date: Mon, 21 Jul 2014 14:47:34 +1000

Hello Mark and Paul,

A few comments.

Regards, Christian

On 19/07/2014 7:51 AM, Paul Kyzivat wrote:
> ..snip..
>> [Duckworth, Mark] Does area of capture apply only to video?  Or can 
>> it apply to any media type other than audio?  framework-16 simply 
>> says it does not apply to audio.
>
[CNG] Maybe we should just focus on video? We can always add an extra 
attributes for other media types if they become necessary.
> ..snip..
>> [Duckworth, Mark] Makes sense for SoundLevel.  Do we want to have an 
>> index for RoundRobin?  I suppose it could make sense there too.  But 
>> I think the current definition of the index is adequate.
>
[CNG] I don't see we need to define the index per kind. The index is the 
n x last speaker, no matter the kind. I can't see the concern with round 
robin here?
>> [Duckworth, Mark] I think there is a word missing: "To indicate that 
>> the Capture Encodings associated with MCCs contain captures from the 
>> *same*source at the same time..."  It seems clear to me, so does 
>> anybody else have a suggestion for how to make this more clear?
>
[CNG] I think endpoint works OK.

> ..snip..
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jul 2014 11:37:31 -0400

Inline

> attributes for other media types if they become necessary.

My point here was to distinguish things that are defined generically for 
all captures from those that are defined specifically for a particular 
type of capture.

The question is whether there are any spatial attributes that are 
generic. If not (and AFAIK that seems to be the case) then we pick and 
choose for each type. Audio and Video can both choose to include point 
of capture and axis of capture. Video also includes area of capture. 
What is appropriate for text is unclear - maybe none, maybe point of 
capture but not axis.

> n x last speaker, no matter the kind. I can't see the concern with round

IIUC, with round robin who is speaking is irrelevant to switching, so 
the index can't mean n x last speaker.

I *guess* that for round robin the alternatives are arranged in a 
sequence (the same sequence used in the MCC?) containing captures 
C(0)...C(N-1). Then we can imagine an integer cursor K that is 
periodically incremented modulo N. With that in place, then RoundRobin X 
identifies capture C( (K+X) mod N ).

My point is that defining what the index means for RoundRobin requires 
something like that. (There may be an easier way to describe it.)

Thinking more, maybe you can say that each switching policy defines a 
sequence of choices from among the candidates. And then index 0 means 
the most recent choice from the sequence, while index I selects prior 
choices from that sequence.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 25 Jul 2014 10:21:46 +1000

Hello Paul,

I don't see the complexity in round robin. Even in round robin there 
will be the active site, then the previously active site is the last 
speaker, the previously active site to that is the n x last speaker, 
etc. So if site A has index 0, when site B is selected as has index 0 
then site A will have index 1.

I don't think we need to go into mathematical definitions for this nor 
specific behaviour for each type of queue. I think the concept of 
current instance and prior instance/s is a generic enough concept. The 
current text from the draft is:

    An index is used to represent an instance in the policy setting. A
    index of 0 represents the most current instance of the policy, i.e.
    the active speaker, 1 represents the previous instance, i.e. the
    previous active speaker and so on.

It already talks about "instances" rather than "speakers" so I can't 
really see the issue.

Regards, Christian

> periodically incremented modulo N. With that in place, then RoundRobin 
> X identifies capture C( (K+X) mod N ).
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 25 Jul 2014 11:29:37 -0700

I agree with Christian, I don't see a need for any change.
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Thursday, July 24, 2014 8:22 PM
> To: [email-masked]
> I don't see the complexity in round robin. Even in round robin there will be
> the active site, then the previously active site is the last speaker, the
> previously active site to that is the n x last speaker, etc. So if site A has index
> 0, when site B is selected as has index 0 then site A will have index 1.
> 
> I don't think we need to go into mathematical definitions for this nor specific
> behaviour for each type of queue. I think the concept of current instance and
> prior instance/s is a generic enough concept. The current text from the draft
> is:
> 
> It already talks about "instances" rather than "speakers" so I can't really see
> the issue.
> 
> Regards, Christian
> 
> >>> ..snip..
> >>>>
> >>>>> Section 7.2.1.2:
> >>>>>
> >>>>> The explanation of 'index' is pretty fuzzy. ISTM that the meaning
> >>>>> really needs to be specified separately for each token. E.g., for
> >>>>> SoundLevel N means the N'th most recent loudest speaker. For
> >>>>> RoundRobin it is harder to describe.
> >>>> [Duckworth, Mark] Makes sense for SoundLevel.  Do we want to have
> >>>> an index for RoundRobin?  I suppose it could make sense there too.
> >>>> But I think the current definition of the index is adequate.
> >>>
> >> [CNG] I don't see we need to define the index per kind. The index is
> >> the n x last speaker, no matter the kind. I can't see the concern
> >> with round robin here?
> >