idnits 2.17.1 draft-groves-clue-scene-clarifications-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 11, 2012) is 4237 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-clue-framework' is defined on line 204, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 216, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-06 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE C. Groves, Ed. 3 Internet-Draft W. Yang 4 Intended status: Informational R. Even 5 Expires: March 15, 2013 P. Kyzivat 6 Huawei 7 September 11, 2012 9 Discussion of scene and capture scene entry concepts 10 draft-groves-clue-scene-clarifications-00 12 Abstract 14 The CLUE framework document defines the concept of media captures 15 which identify and describe the characteristics of media sent by a 16 provider. A capture scene is a grouping concept that provides ties a 17 number of captures together. Within the capture scene the media 18 captures may further be grouped into capture scene entries. The 19 current text in the CLUE framework document describing these concepts 20 could be improved and clarified so that both providers and consumers 21 use the same logic to encode/decode CLUE messages with capture 22 scenes/ capture scene entries and media captures. This draft 23 discusses these concepts and provides suggested updates. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 15, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 Recent discussion on the IETF mailing list has indicated that there 60 are different interpretations of exactly what a "Capture Scene Entry" 61 is. In the framework draft it is defined as: 63 /*Capture Scene Entry: a list of media captures of the same 64 media type that together form one way to represent the 65 capture scene./ 67 it also says: 69 /A media provider arranges media captures in a capture 70 scene to help the media consumer choose which captures it 71 wants. The capture scene entries in a capture scene are 72 different alternatives the provider is suggesting for 73 representing the capture scene./ 75 It could be interpreted as meaning that each "Capture Scene Entry" 76 shows an entire scene, or it could be interpreted as meaning that 77 each "Capture Scene Entry" could show part of the overall scene. 79 It appears from reading the framework both interpretations are 80 allowed. 82 For example: if VC1,VC2,VC3 are three main cameras, VC4 is an camera 83 that automatically zooms in on the active speaker. One could 84 construct a capture scene with one or two capture scene entries. 85 There are other possibilities but to illustrate the issue the 86 following alternatives are shown: 88 +------------------+ 89 | Capture Scene #1 | 90 +------------------+ 91 | VC1, VC2, VC3 | 92 | VC4 | 93 +------------------+ 94 or 95 +--------------------+ 96 | Capture Scene #1 | 97 +--------------------+ 98 | VC1, VC2, VC3, VC4 | 99 +--------------------+ 101 Figure 1 103 Depending on how the consumer is designed it may not see the two 104 options as equivalent. In the first example a consumer may only 105 chose the first capture scene entry as it has been designed with the 106 premise that a capture scene entry represents the whole scene and 107 therefore it is sufficient to choose only one line. If it choses one 108 line it missing out on part of the scene. Another consumer may 109 choose both as it recognises multiple capture scene entries. Clearly 110 there is an interoperability problem if the provider and consumer are 111 using different logic to encode / decode captures from scenes. It is 112 also noted that there may be additional complexity for consumers if 113 the method of using capture scene entries to represent partial scenes 114 is used. A consumer would have to parse the characteristcis of each 115 capture to see how they are related. 117 A further issue is if the entire scene is depicted how does the 118 consumer determine which captures are closely related within a 119 capture scene entry. For example: which of the capture must be 120 processed together to form a continuous image. The area of capture 121 attribute does provide positioning information however determining 122 which captures make up a continuous image may be non-trivial and 123 would become more complicated as the number of captures in a scene 124 entry rose. It would be compounded in situations where different 125 providers have different gaps and scales as there would be different 126 thresholds as to what captures would appear to be continuous. It is 127 believed that having a way to indicated closely bound captures would 128 be advantageous to simplifying this determination. 130 To add to the complication the framework draft is vague in making 131 recommendations as to what the consumer should do at the reception of 132 scene / capture scene entry / capture information. It suggests that 133 the consumer could pick an element from each of the option presented. 134 It's not clear how this would work under the assumption that a 135 provider provides this information with the understanding to it must 136 be able to simultaneously provide this media. Chosing different 137 captures to what the provider has sent may mean that the media 138 streams related to captures may not be able to sent together. 139 Limiting this flexibility may increase interoperability. 141 2. Proposal 143 This section provides a strawman proposal of principles that should 144 be documented in the framework document 146 Whilst there appears to be different interpretations, to the 147 Contributors there appears to be one fundamental assumption that 148 everyone agrees on, that is that all captures within a scene must be 149 spatially related. 151 It is also assumed that there would be a desire to increase the 152 chances of interoperability and to minimise the complexity needed for 153 encoding and parsing scene information. 155 Based on this assumption and the above discussion it is proposed that 156 : 158 a) A scene represents an area where the capture devices are 159 spatially related, i.e. a presentation that shares no spatial 160 relation with a video is a separate scene. 162 b) A capture scene entry thus represents alternate 163 representations of a complete scene. The provider is the one 164 that determines what a complete scene is. A consumer choses 165 a capture scene entry from the scene in the knowledge that it 166 represents the entire scene. 168 c) A new concept of "Capture group" be incorporated into a 169 capture scene entry which indicates which captures are 170 closely bound. Closely bound captures are those that have a 171 closer relationship than just being spatially related and 172 MUST be able to be encoded and sent simultaneously. E.g. 173 multiple captures for the purposes of capturing a continuous 174 image or sound stage are closely bound. 176 d) A consumer shall chose a captre scene entry rather than 177 choosing individual captures from multiple entries. This 178 does not mean that an consuming endpoint must render all the 179 captures. What is locally rendered and how is a local 180 decision. 182 3. Acknowledgements 184 This template was derived from an initial version written by Pekka 185 Savola and contributed by him to the xml2rfc project. 187 4. IANA Considerations 189 This memo includes no request to IANA. 191 5. Security Considerations 193 TBD 195 6. References 197 6.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 6.2. Informative References 204 [I-D.ietf-clue-framework] 205 Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, 206 "Framework for Telepresence Multi-Streams", 207 draft-ietf-clue-framework-06 (work in progress). 209 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 210 June 1999. 212 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 213 Text on Security Considerations", BCP 72, RFC 3552, 214 July 2003. 216 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 217 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 218 May 2008. 220 Authors' Addresses 222 Christian Groves (editor) 223 Huawei 224 Melbourne, 225 Australia 227 Email: Christian.Groves@nteczone.com 229 Weiwei Yang 230 Huawei 231 P.R.China 233 Email: tommy@huawei.com 235 Roni Even 236 Huawei 237 Tel Aviv, 238 Isreal 240 Email: roni.even@mail01.huawei.com 242 Paul Kyzivat 243 Huawei 244 Greater Boston, Massachusetts 245 USA 247 Email: pkyzivat@alum.mit.edu