idnits 2.17.1 draft-ietf-clue-data-model-schema-17.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 date (August 13, 2016) is 2812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9' is mentioned on line 1171, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-clue-datachannel-14 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel') == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE Working Group R. Presta 3 Internet-Draft S P. Romano 4 Intended status: Standards Track University of Napoli 5 Expires: February 14, 2017 August 13, 2016 7 An XML Schema for the CLUE data model 8 draft-ietf-clue-data-model-schema-17 10 Abstract 12 This document provides an XML schema file for the definition of CLUE 13 data model types. The term "CLUE" stands for "ControLling mUltiple 14 streams for tElepresence" and is the name of the IETF working group 15 in which this document, as well as other companion documents, has 16 been developed. The document defines a coherent structure for 17 information associated with the description of a telepresence 18 scenario. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 14, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. . . . . . . . . . . . . . . . . . . . . . . . 19 59 6. . . . . . . . . . . . . . . . . . . . . . . . 19 60 7. . . . . . . . . . . . . . . . . . . . . . . . 19 61 8. . . . . . . . . . . . . . . . . . . . . . . 19 62 9. . . . . . . . . . . . . . . . . . . . . . . . . 19 63 10. . . . . . . . . . . . . . . . . . . . . . . 19 64 11. . . . . . . . . . . . . . . . . . . . . . . . . 19 65 11.1. captureID attribute . . . . . . . . . . . . . . . . . . . 22 66 11.2. mediaType attribute . . . . . . . . . . . . . . . . . . . 22 67 11.3. . . . . . . . . . . . . . . . . . . . 22 68 11.4. . . . . . . . . . . . . . . . . . . . . . 22 69 11.5. . . . . . . . . . . . . . . . . . . 23 70 11.5.1. . . . . . . . . . . . . . . . . . . . 24 71 11.5.2. . . . . . . . . . . . . . . . . . . . . 25 72 11.6. . . . . . . . . . . . . . . . . . 26 73 11.7. . . . . . . . . . . . . . . . . . . . . . . . . 26 74 11.8. . . . . . . . . . . . . . . . . . . . 26 75 11.9. . . . . . . . . . . . . . . . . . . . 27 76 11.10. . . . . . . . . . . . . . . . . . . . . . . . . 27 77 11.11. . . . . . . . . . . . . . . . . . . . . . . 28 78 11.12. . . . . . . . . . . . . . . . . . . . . . . 29 79 11.13. . . . . . . . . . . . . . . . . . . . . . . 29 80 11.14. . . . . . . . . . . . . . . . . . . . . . . . 29 81 11.15. . . . . . . . . . . . . . . . . . . . . . . . . . 30 82 11.16. . . . . . . . . . . . . . . . . . . . . . . . 30 83 11.17. . . . . . . . . . . . . . . . . . . . . . . . 30 84 11.18. . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 11.19. . . . . . . . . . . . . . . . . . . . . . 31 86 11.20. . . . . . . . . . . . . . . . . . . . . . 31 87 11.21. . . . . . . . . . . . . . . . . . . . . 32 88 11.21.1. . . . . . . . . . . . . . . . . . . . . 32 89 12. Audio captures . . . . . . . . . . . . . . . . . . . . . . . . 32 90 12.1. . . . . . . . . . . . . . . . . . . 33 91 13. Video captures . . . . . . . . . . . . . . . . . . . . . . . . 33 92 14. Text captures . . . . . . . . . . . . . . . . . . . . . . . . 34 93 15. Other capture types . . . . . . . . . . . . . . . . . . . . . 34 94 16. . . . . . . . . . . . . . . . . . . . . . . . . 35 95 16.1. . . . . . . . . . . . . . . . . . . . 36 96 16.2. . . . . . . . . . . . . . . . . . . . . . . 36 97 16.3. sceneID attribute . . . . . . . . . . . . . . . . . . . . 36 98 16.4. scale attribute . . . . . . . . . . . . . . . . . . . . . 36 99 17. . . . . . . . . . . . . . . . . . . . . . . . . . 37 100 17.1. . . . . . . . . . . . . . . . . . . . . 38 101 17.2. sceneViewID attribute . . . . . . . . . . . . . . . . . . 38 102 18. . . . . . . . . . . . . . . . . . . . . . . . 38 103 18.1. . . . . . . . . . . . . . . . . . . . 39 104 18.2. . . . . . . . . . . . . . . . . . . . . 39 105 18.3. encodingGroupID attribute . . . . . . . . . . . . . . . . 39 106 19. . . . . . . . . . . . . . . . . . . . . . . 39 107 19.1. setID attribute . . . . . . . . . . . . . . . . . . . . . 40 108 19.2. mediaType attribute . . . . . . . . . . . . . . . . . . . 40 109 19.3. . . . . . . . . . . . . . . . . . . . 41 110 19.4. . . . . . . . . . . . . . . . . . . . . 41 111 19.5. . . . . . . . . . . . . . . . . . . . 41 112 20. . . . . . . . . . . . . . . . . . . . . . . . . . 41 113 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 114 21.1. . . . . . . . . . . . . . . . . . . . . . . . . 42 115 21.1.1. personID attribute . . . . . . . . . . . . . . . . . 42 116 21.1.2. . . . . . . . . . . . . . . . . . . . . 42 117 21.1.3. . . . . . . . . . . . . . . . . . . . . 43 118 22. . . . . . . . . . . . . . . . . . . . . . . 43 119 22.1. . . . . . . . . . . . . . . . . . . . . . . . 44 120 22.2. . . . . . . . . . . . . . . . . . . . . . . 44 121 22.3. . . . . . . . . . . . . . . . . . . . 44 122 23. . . . . . . . . . . . . . . . . . . . . . . . . . . 44 123 24. XML Schema extensibility . . . . . . . . . . . . . . . . . . . 45 124 24.1. Example of extension . . . . . . . . . . . . . . . . . . 46 125 25. Security considerations . . . . . . . . . . . . . . . . . . . 48 126 26. IANA considerations . . . . . . . . . . . . . . . . . . . . . 49 127 26.1. XML namespace registration . . . . . . . . . . . . . . . 49 128 26.2. XML Schema registration . . . . . . . . . . . . . . . . . 50 129 26.3. MIME Media Type Registration for 130 "application/clue_info+xml" . . . . . . . . . . . . . . . 50 131 26.4. Registry for acceptable values . . . . . . . . . . 51 132 26.5. Registry for acceptable values . . . . . . 51 133 26.6. Registry for acceptable values . . 51 134 26.7. Registry for acceptable values . . . . . . . 52 135 27. Sample XML file . . . . . . . . . . . . . . . . . . . . . . . 52 136 28. MCC example . . . . . . . . . . . . . . . . . . . . . . . . . 60 137 29. Diff with draft-ietf-clue-data-model-schema-16 version . . . . 71 138 30. Diff with draft-ietf-clue-data-model-schema-15 version . . . . 71 139 31. Diff with draft-ietf-clue-data-model-schema-14 version . . . . 71 140 32. Diff with draft-ietf-clue-data-model-schema-13 version . . . . 71 141 33. Diff with draft-ietf-clue-data-model-schema-12 version . . . . 71 142 34. Diff with draft-ietf-clue-data-model-schema-11 version . . . . 71 143 35. Diff with draft-ietf-clue-data-model-schema-10 version . . . . 71 144 36. Diff with draft-ietf-clue-data-model-schema-09 version . . . . 72 145 37. Diff with draft-ietf-clue-data-model-schema-08 version . . . . 72 146 38. Diff with draft-ietf-clue-data-model-schema-07 version . . . . 72 147 39. Diff with draft-ietf-clue-data-model-schema-06 version . . . . 72 148 40. Diff with draft-ietf-clue-data-model-schema-04 version . . . . 73 149 41. Diff with draft-ietf-clue-data-model-schema-03 version . . . . 74 150 42. Diff with draft-ietf-clue-data-model-schema-02 version . . . . 74 151 43. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74 152 44. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 153 44.1. Normative References . . . . . . . . . . . . . . . . . . 74 154 44.2. Informative References . . . . . . . . . . . . . . . . . 76 156 1. Introduction 158 This document provides an XML schema file for the definition of CLUE 159 data model types. For the benefit of the reader, the term 'CLUE' 160 stands for "ControLling mUltiple streams for tElepresence" and is the 161 name of the IETF working group in which this document, as well as 162 other companion documents, has been developed. A thorough definition 163 of the CLUE framework can be found in [I-D.ietf-clue-framework]. 165 The schema is based on information contained in 166 [I-D.ietf-clue-framework]. It encodes information and constraints 167 defined in the aforementioned document in order to provide a formal 168 representation of the concepts therein presented. 170 The document aims at the definition of a coherent structure for 171 information associated with the description of a telepresence 172 scenario. Such information is used within the CLUE protocol messages 173 ([I-D.ietf-clue-protocol]) enabling the dialogue between a Media 174 Provider and a Media Consumer. CLUE protocol messages, indeed, are 175 XML messages allowing (i) a Media Provider to advertise its 176 telepresence capabilities in terms of media captures, capture scenes, 177 and other features envisioned in the CLUE framework, according to the 178 format herein defined and (ii) a Media Consumer to request the 179 desired telepresence options in the form of capture encodings, 180 represented as described in this document. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. Definitions 190 This document refers to the same definitions used in 191 [I-D.ietf-clue-framework], except for the "CLUE Participant" 192 definition. We briefly recall herein some of the main terms used in 193 the document. 195 Audio Capture: Media Capture for audio. Denoted as ACn in the 196 examples in this document. 198 Capture: Same as Media Capture. 200 Capture Device: A device that converts physical input, such as 201 audio, video or text, into an electrical signal, in most cases to 202 be fed into a media encoder. 204 Capture Encoding: A specific encoding of a Media Capture, to be sent 205 by a Media Provider to a Media Consumer via RTP. 207 Capture Scene: A structure representing a spatial region captured by 208 one or more Capture Devices, each capturing media representing a 209 portion of the region. The spatial region represented by a 210 Capture Scene MAY correspond to a real region in physical space, 211 such as a room. A Capture Scene includes attributes and one or 212 more Capture Scene Views, with each view including one or more 213 Media Captures. 215 Capture Scene View: A list of Media Captures of the same media type 216 that together form one way to represent the entire Capture Scene. 218 CLUE Participant: This term is imported from the CLUE protocol 219 ([I-D.ietf-clue-protocol]) document. 221 Consumer: Short for Media Consumer. 223 Encoding or Individual Encoding: A set of parameters representing a 224 way to encode a Media Capture to become a Capture Encoding. 226 Encoding Group: A set of encoding parameters representing a total 227 media encoding capability to be sub-divided across potentially 228 multiple Individual Encodings. 230 Endpoint A CLUE-capable device which is the logical point of final 231 termination through receiving, decoding and rendering, and/or 232 initiation through capturing, encoding, and sending of media 233 streams. An endpoint consists of one or more physical devices 234 which source and sink media streams, and exactly one [RFC4353] 235 Participant (which, in turn, includes exactly one SIP User Agent). 236 Endpoints can be anything from multiscreen/multicamera rooms to 237 handheld devices. 239 Media: Any data that, after suitable encoding, can be conveyed over 240 RTP, including audio, video or timed text. 242 Media Capture: A source of Media, such as from one or more Capture 243 Devices or constructed from other Media streams. 245 Media Consumer: A CLUE-capable device that intends to receive 246 Capture Encodings. 248 Media Provider: A CLUE-capable device that intends to send Capture 249 Encodings. 251 Multiple Content Capture: A Capture that mixes and/or switches other 252 Captures of a single type (e.g., all audio or all video.) 253 Particular Media Captures may or may not be present in the 254 resultant Capture Encoding depending on time or space. Denoted as 255 MCCn in the example cases in this document. 257 Multipoint Control Unit (MCU): A CLUE-capable device that connects 258 two or more endpoints together into one single multimedia 259 conference [RFC7667]. An MCU includes an [RFC4353] like Mixer, 260 without the [RFC4353] requirement to send media to each 261 participant. 263 Plane of Interest: The spatial plane containing the most relevant 264 subject matter. 266 Provider: Same as Media Provider. 268 Render: The process of reproducing the received Streams like, for 269 instance, displaying of the remote video on the Media Consumer's 270 screens, or playing of the remote audio through loudspeakers. 272 Scene: Same as Capture Scene. 274 Simultaneous Transmission Set: A set of Media Captures that can be 275 transmitted simultaneously from a Media Provider. 277 Single Media Capture: A capture which contains media from a single 278 source capture device, e.g., an audio capture from a single 279 microphone, a video capture from a single camera. 281 Spatial Relation: The arrangement in space of two objects, in 282 contrast to relation in time or other relationships. 284 Stream: A Capture Encoding sent from a Media Provider to a Media 285 Consumer via RTP [RFC3550]. 287 Stream Characteristics: The union of the features used to describe a 288 Stream in the CLUE environment and in the SIP-SDP environment. 290 Video Capture: A Media Capture for video. 292 4. XML Schema 294 This section contains the CLUE data model schema definition. 296 The element and attribute definitions are formal representations of 297 the concepts needed to describe the capabilities of a Media Provider 298 and the streams that are requested by a Media Consumer given the 299 Media Provider's ADVERTISEMENT ([I-D.ietf-clue-protocol]). 301 The main groups of information are: 303 : the list of media captures available (Section 5) 305 : the list of encoding groups (Section 6) 307 : the list of capture scenes (Section 7) 309 : the list of simultaneous transmission sets 310 (Section 8) 312 : the list of global views sets (Section 9) 314 : meta data about the participants represented in the 315 telepresence session (Section 21) 317 : the list of instantiated capture encodings 318 (Section 10) 320 All of the above refers to concepts that have been introduced in 321 [I-D.ietf-clue-framework] and further detailed in this document. 323 324 334 335 339 340 341 342 343 344 345 347 349 350 351 352 353 355 356 358 359 360 361 362 363 364 365 366 367 369 370 371 372 373 374 375 376 378 379 381 382 383 384 385 387 388 389 392 394 395 396 397 398 399 400 401 403 404 405 406 407 409 410 411 412 414 416 417 418 419 420 421 423 424 425 426 428 430 432 433 434 436 437 438 439 440 441 442 444 445 446 447 449 450 451 453 454 455 456 457 458 460 461 462 463 464 465 467 468 469 470 472 473 475 476 477 478 480 481 482 483 484 Acceptable values (enumerations) for this type are managed 485 by IANA in the "CLUE Schema <personType> registry", 486 accessible at TBD-IANA. 487 489 490 492 493 494 495 496 Acceptable values (enumerations) for this type are managed 497 by IANA in the "CLUE Schema <view> registry", 498 accessible at TBD-IANA. 499 500 501 503 504 505 506 507 Acceptable values (enumerations) for this type are managed 508 by IANA in the "CLUE Schema <presentation> registry", 509 accessible at TBD-IANA. 510 511 512 514 515 516 517 519 520 522 523 524 526 527 528 529 530 531 532 533 535 536 537 538 539 541 542 543 544 546 547 548 549 550 551 552 553 554 556 557 558 559 560 561 562 563 565 566 567 568 569 570 572 573 574 575 576 578 579 580 581 582 583 585 586 587 588 589 591 592 593 594 595 596 597 599 600 601 602 603 605 606 607 608 609 Acceptable values (enumerations) for this type are managed by IANA 610 in the "CLUE Schema <sensitivityPattern> registry", accessible 611 at TBD-IANA. 612 613 614 616 617 618 619 620 621 623 624 625 626 628 630 631 632 633 634 635 636 637 638 639 641 642 643 644 645 647 648 650 651 652 653 654 656 657 659 660 661 662 663 665 666 667 668 669 670 671 672 674 675 676 677 678 680 681 683 684 685 686 687 688 689 690 692 693 694 695 697 698 700 701 702 703 705 706 708 709 710 711 712 713 715 716 717 718 720 721 722 723 724 725 727 728 729 730 732 733 735 736 737 738 740 742 744 746 747 748 749 750 752 753 754 755 757 758 760 761 762 763 765 767 768 769 770 771 772 773 774 776 777 779 780 781 782 783 784 786 788 789 790 791 793 794 796 797 798 799 800 801 802 803 804 805 807 808 809 810 811 813 Following sections describe the XML schema in more detail. As a 814 general remark, please notice that optional elements that don't 815 define what their absence means are intended to be associated with 816 undefined properties. 818 5. 820 represents the list of one or more media captures 821 available at the Media Provider's side. Each media capture is 822 represented by a element (Section 11). 824 6. 826 represents the list of the encoding groups organized 827 on the Media Provider's side. Each encoding group is represented by 828 an element (Section 18). 830 7. 832 represents the list of the capture scenes organized 833 on the Media Provider's side. Each capture scene is represented by a 834 element. (Section 16). 836 8. 838 contains the simultaneous sets indicated by the 839 Media Provider. Each simultaneous set is represented by a 840 element. (Section 19). 842 9. 844 contains a set of alternative representations of all 845 the scenes that are offered by a Media Provider to a Media Consumer. 846 Each alternative is named "global view" and it is represented by a 847 element. (Section 20). 849 10. 851 is a list of capture encodings. It can represent 852 the list of the desired capture encodings indicated by the Media 853 Consumer or the list of instantiated captures on the provider's side. 854 Each capture encoding is represented by a element. 855 (Section 22). 857 11. 859 A Media Capture is the fundamental representation of a media flow 860 that is available on the provider's side. Media captures are 861 characterized (i) by a set of features that are independent from the 862 specific type of medium, and (ii) by a set of features that are 863 media-specific. The features that are common to all media types 864 appear within the media capture type, that has been designed as an 865 abstract complex type. Media-specific captures, such as video 866 captures, audio captures and others, are specializations of that 867 abstract media capture type, as in a typical generalization- 868 specialization hierarchy. 870 The following is the XML Schema definition of the media capture type: 872 873 874 875 876 877 878 879 881 882 884 885 886 887 888 890 891 892 894 896 897 898 899 900 901 902 903 905 906 907 908 909 911 912 913 914 915 917 11.1. captureID attribute 919 The "captureID" attribute is a mandatory field containing the 920 identifier of the media capture. Such an identifier serves as the 921 way the capture is referenced from other data model elements (e.g., 922 simultaneous sets, capture encodings, and others via 923 ). 925 11.2. mediaType attribute 927 The "mediaType" attribute is a mandatory attribute specifying the 928 media type of the capture. Common standard values are "audio", 929 "video", "text", as defined in [RFC6838]. Other values can be 930 provided. It is assumed that implementations agree on the 931 interpretation of those other values. The "mediaType" attribute is 932 as generic as possible. Here is why: (i) the basic media capture 933 type is an abstract one; (ii) "concrete" definitions for the standard 934 ([RFC6838]) audio, video and text capture types have been specified; 935 (iii) a generic "otherCaptureType" type has been defined; (iv) the 936 "mediaType" attribute has been generically defined as a string, with 937 no particular template. From the considerations above, it is clear 938 that if one chooses to rely on a brand new media type and wants to 939 interoperate with others, an application-level agreement is needed on 940 how to interpret such information. 942 11.3. 944 is a mandatory field containing the value of the 945 identifier of the capture scene the media capture is defined in, 946 i.e., the value of the sceneID (Section 16.3) attribute of that 947 capture scene. Indeed, each media capture MUST be defined within one 948 and only one capture scene. When a media capture is spatially 949 definable, some spatial information is provided along with it in the 950 form of point coordinates (see Section 11.5). Such coordinates refer 951 to the space of coordinates defined for the capture scene containing 952 the capture. 954 11.4. 956 is an optional field containing the identifier of the 957 encoding group the media capture is associated with, i.e., the value 958 of the encodingGroupID (Section 18.3) attribute of that encoding 959 group. Media captures that are not associated with any encoding 960 group can not be instantiated as media streams. 962 11.5. 964 Media captures are divided into two categories: (i) non spatially 965 definable captures and (ii) spatially definable captures. 967 Captures are spatially definable when at least (i) it is possible to 968 provide the coordinates of the device position within the 969 telepresence room of origin (capture point) together with its 970 capturing direction specified by a second point (point on line of 971 capture), or (ii) it is possible to provide the represented area 972 within the telepresence room, by listing the coordinates of the four 973 co-planar points identifying the plane of interest (area of capture). 974 The coordinates of the above mentioned points MUST be expressed 975 according to the coordinate space of the capture scene the media 976 captures belongs to. 978 Non spatially definable captures cannot be characterized within the 979 physical space of the telepresence room of origin. Captures of this 980 kind are for example those related to recordings, text captures, 981 DVDs, registered presentations, or external streams that are played 982 in the telepresence room and transmitted to remote sites. 984 Spatially definable captures represent a part of the telepresence 985 room. The captured part of the telepresence room is described by 986 means of the element. By comparing the 987 element of different media captures within the 988 same capture scene, a consumer can better determine the spatial 989 relationships between them and render them correctly. Non spatially 990 definable captures do not embed such element in their XML 991 description: they are instead characterized by having the 992 tag set to "true" (see Section 11.6). 994 The definition of the spatial information type is the following: 996 997 998 999 1001 1002 1004 1005 1006 1007 The contains the coordinates of the capture device 1008 that is taking the capture (i.e., the capture point), as well as, 1009 optionally, the pointing direction (i.e., the point on line of 1010 capture) (see Section 11.5.1). 1012 The is an optional field containing four points 1013 defining the captured area covered by the capture (see 1014 Section 11.5.2). 1016 The scale of the points coordinates is specified in the scale 1017 (Section 16.4) attribute of the capture scene the media capture 1018 belongs to. Indeed, all the spatially definable media captures 1019 referring to the same capture scene share the same coordinate system 1020 and express their spatial information according to the same scale. 1022 11.5.1. 1024 The element is used to represent the position and 1025 optionally the line of capture of a capture device. 1026 MUST be included in spatially definable audio captures, while it is 1027 optional for spatially definable video captures. 1029 The XML Schema definition of the element type is the 1030 following: 1032 1033 1034 1035 1036 1038 1039 1040 1042 1043 1044 1045 1046 1047 1048 1049 1050 The point type contains three spatial coordinates (x,y,z) 1051 representing a point in the space associated with a certain capture 1052 scene. 1054 The element includes a mandatory 1055 element and an optional element, both of the 1056 type "pointType". specifies the three coordinates 1057 identifying the position of the capture device. 1058 is another pointType element representing the "point on line of 1059 capture", that gives the pointing direction of the capture device. 1061 The coordinates of the point on line of capture MUST NOT be identical 1062 to the capture point coordinates. For a spatially definable video 1063 capture, if the point on line of capture is provided, it MUST belong 1064 to the region between the point of capture and the capture area. For 1065 a spatially definable audio capture, if the point on line of capture 1066 is not provided, the sensitivity pattern should be considered 1067 omnidirectional. 1069 11.5.2. 1071 is an optional element that can be contained within the 1072 spatial information associated with a media capture. It represents 1073 the spatial area captured by the media capture. MUST be 1074 included in the spatial information of spatially definable video 1075 captures, while it MUST NOT be associated with audio captures. 1077 The XML representation of that area is provided through a set of four 1078 point-type elements, , , , and 1079 that MUST be co-planar. The four coplanar points are 1080 identified from the perspective of the capture device. The XML 1081 schema definition is the following: 1083 1084 1085 1086 1087 1088 1089 1090 1091 1093 11.6. 1095 When media captures are non spatially definable, they MUST be marked 1096 with the boolean element set to "true" and no 1097 MUST be provided. Indeed, 1098 and are mutually 1099 exclusive tags, according to the section within the XML 1100 Schema definition of the media capture type. 1102 11.7. 1104 A media capture can be (i) an individual media capture or (ii) a 1105 multiple content capture (MCC). A multiple content capture is made 1106 by different captures that can be arranged spatially (by a 1107 composition operation), or temporally (by a switching operation), or 1108 that can result from the orchestration of both the techniques. If a 1109 media capture is an MCC, then it MAY show in its XML data model 1110 representation the element. It is composed by a list of 1111 media capture identifiers ("mediaCaptureIDREF") and capture scene 1112 view identifiers ("sceneViewIDREF"), where the latter ones are used 1113 as shortcuts to refer to multiple capture identifiers. The 1114 referenced captures are used to create the MCC according to a certain 1115 strategy. If the element does not appear in a MCC, or it 1116 has no child elements, then the MCC is assumed to be made of multiple 1117 sources but no information regarding those sources is provided. 1119 1120 1121 1122 1124 1126 1128 1129 1130 1132 11.8. 1134 is an optional element for multiple content 1135 captures that contains a numeric identifier. Multiple content 1136 captures marked with the same identifier in the 1137 contain at all times captures coming from the same sources. It is 1138 the Media Provider that determines what the source for the captures 1139 is. In this way, the Media Provider can choose how to group together 1140 single captures for the purpose of keeping them synchronized 1141 according to the element. 1143 11.9. 1145 is an optional boolean element for multiple 1146 content captures. It indicates whether or not the Provider allows 1147 the Consumer to choose a specific subset of the captures referenced 1148 by the MCC. If this attribute is true, and the MCC references other 1149 captures, then the Consumer MAY specify in a CONFIGURE message a 1150 specific subset of those captures to be included in the MCC, and the 1151 Provider MUST then include only that subset. If this attribute is 1152 false, or the MCC does not reference other captures, then the 1153 Consumer MUST NOT select a subset. If is not 1154 shown in the XML description of the MCC, its value is to be 1155 considered "false". 1157 11.10. 1159 is an optional element that can be used only for multiple 1160 content captures. It indicates the criteria applied to build the 1161 multiple content capture using the media captures referenced in the 1162 list. The value is in the form of a 1163 token that indicates the policy and an index representing an instance 1164 of the policy, separated by a ":" (e.g., SoundLevel:2, RoundRobin:0, 1165 etc.). The XML schema defining the type of the element is 1166 the following: 1168 1169 1170 1171 1172 1173 1175 At the time of writing, only two switching policies are defined in 1176 [I-D.ietf-clue-framework]: 1178 SoundLevel: the content of the MCC is determined by a sound level 1179 detection algorithm. The loudest (active) speaker (or a previous 1180 speaker, depending on the index value) is contained in the MCC. 1181 Index 0 represents the most current instance of the policy, i.e., 1182 the currently active speaker, 1 represents the previous instance, 1183 i.e., the previous active speaker, and so on. 1185 RoundRobin: the content of the MCC is determined by a time based 1186 algorithm. 1188 Other values for the element can be used. In this case, it 1189 is assumed that implementations agree on the meaning of those other 1190 values and/or those new switching policies are defined in later 1191 documents. 1193 11.11. 1195 is an optional element that can be used only for 1196 multiple content captures (MCC). It provides information about the 1197 number of media captures that can be represented in the multiple 1198 content capture at a time. If is not provided, all the 1199 media captures listed in the element can appear at a time 1200 in the capture encoding. The type definition is provided below. 1202 1203 1204 1205 1206 1207 1208 1210 1211 1212 1213 1215 1216 1217 1219 When the "exactNumber" attribute is set to "true", it means the 1220 element carries the exact number of the media captures 1221 appearing at a time. Otherwise, the number of the represented media 1222 captures MUST be considered "<=" the value. 1224 For instance, an audio MCC having the value set to 1 1225 means that a media stream from the MCC will only contain audio from a 1226 single one of its constituent captures at a time. On the other hand, 1227 if the value is set to 4 and the exactNumber attribute 1228 is set to "true", it would mean that the media stream received from 1229 the MCC will always contain a mix of audio from exactly four of its 1230 constituent captures. 1232 11.12. 1234 is a boolean element that MUST be used for single- 1235 content captures. Its value is fixed and set to "true". Such 1236 element indicates the capture that is being described is not a 1237 multiple content capture. Indeed, and the 1238 aforementioned tags related to MCC attributes (from Section 11.7 to 1239 Section 11.11) are mutually exclusive, according to the 1240 section within the XML Schema definition of the media capture type. 1242 11.13. 1244 is used to provide human-readable textual information. 1245 This element is included in the XML definition of media captures, 1246 capture scenes and capture scene views to the aim of providing human- 1247 readable description of, respectively, media captures, capture scenes 1248 and capture scene views. According to the data model definition of a 1249 media capture (Section 11)), zero or more elements can 1250 be used, each providing information in a different language. The 1251 element definition is the following: 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1264 As can be seen, is a string element with an attribute 1265 ("lang") indicating the language used in the textual description. 1266 Such an attribute is compliant with the Language-Tag ABNF production 1267 from [RFC5646]. 1269 11.14. 1271 is an optional unsigned integer field indicating the 1272 importance of a media capture according to the Media Provider's 1273 perspective. It can be used on the receiver's side to automatically 1274 identify the most relevant contribution from the Media Provider. The 1275 higher the importance, the lower the contained value. If no priority 1276 is assigned, no assumptions regarding relative importance of the 1277 media capture can be assumed. 1279 11.15. 1281 is an optional element containing the language used in the 1282 capture. Zero or more elements can appear in the XML 1283 description of a media capture. Each such element has to be 1284 compliant with the Language-Tag ABNF production from [RFC5646]. 1286 11.16. 1288 is an optional element indicating whether or not the 1289 capture device originating the capture may move during the 1290 telepresence session. That optional element can assume one of the 1291 three following values: 1293 static SHOULD NOT change for the duration of the CLUE session, 1294 across multiple ADVERTISEMENT messages. 1296 dynamic MAY change in each new ADVERTISEMENT message. Can be 1297 assumed to remain unchanged until there is a new ADVERTISEMENT 1298 message. 1300 highly-dynamic MAY change dynamically, even between consecutive 1301 ADVERTISEMENT messages. The spatial information provided in an 1302 ADVERTISEMENT message is simply a snapshot of the current values 1303 at the time when the message is sent. 1305 11.17. 1307 The optional element contains the value of the captureID 1308 attribute (Section 11.1) of the media capture to which the considered 1309 media capture refers. The media capture marked with a 1310 element can be for example the translation of the referred media 1311 capture in a different language. 1313 11.18. 1315 The element is an optional tag describing what is represented 1316 in the spatial area covered by a media capture. It has been 1317 specified as a simple string with an annotation pointing to an ad hoc 1318 defined IANA registry: 1320 1321 1322 1323 1324 Acceptable values (enumerations) for this type are managed 1325 by IANA in the "CLUE Schema registry", 1326 accessible at TBD-IANA. 1327 1328 1329 1331 The current possible values, as per the CLUE framework document 1332 [I-D.ietf-clue-framework], are: "room", "table", "lectern", 1333 "individual", and "audience". 1335 11.19. 1337 The element is an optional tag used for media captures 1338 conveying information about presentations within the telepresence 1339 session. It has been specified as a simple string with an annotation 1340 pointing to an ad hoc defined IANA registry: 1342 1343 1344 1345 1346 Acceptable values (enumerations) for this type are managed 1347 by IANA in the "CLUE Schema registry", 1348 accessible at TBD-IANA. 1349 1350 1351 1353 The current possible values, as per the CLUE framework document 1354 [I-D.ietf-clue-framework], are "slides" and "images". 1356 11.20. 1358 The element is a boolean element indicating that there 1359 is text embedded in the media capture (e.g., in a video capture). 1360 The language used in such embedded textual description is reported in 1361 "lang" attribute. 1363 The XML Schema definition of the element is: 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1376 11.21. 1378 This optional element is used to indicate which telepresence session 1379 participants are represented within the media captures. For each 1380 participant, a element is provided. 1382 11.21.1. 1384 contains the identifier of the represented person, 1385 i.e., the value of the related personID attribute (Section 21.1.1). 1386 Metadata about the represented participant can be retrieved by 1387 accessing the list (Section 21). 1389 12. Audio captures 1391 Audio captures inherit all the features of a generic media capture 1392 and present further audio-specific characteristics. The XML Schema 1393 definition of the audio capture type is reported below: 1395 1396 1397 1398 1399 1400 1401 1403 1404 1405 1406 1407 1408 An example of audio-specific information that can be included is 1409 represented by the element. (Section 12.1). 1411 12.1. 1413 The element is an optional field describing the 1414 characteristics of the nominal sensitivity pattern of the microphone 1415 capturing the audio signal. It has been specified as a simple string 1416 with an annotation pointing to an ad hoc defined IANA registry: 1418 1419 1420 1421 1422 Acceptable values (enumerations) for this type are managed by IANA 1423 in the "CLUE Schema registry", accessible 1424 at TBD-IANA. 1425 1426 1427 1429 The current possible values, as per the CLUE framework document 1430 [I-D.ietf-clue-framework], are "uni", "shotgun", "omni", "figure8", 1431 "cardioid" and "hyper-cardioid". 1433 13. Video captures 1435 Video captures, similarly to audio captures, extend the information 1436 of a generic media capture with video-specific features. 1438 The XML Schema representation of the video capture type is provided 1439 in the following: 1441 1442 1443 1444 1445 1446 1448 1449 1450 1452 1453 1455 14. Text captures 1457 Also text captures can be described by extending the generic media 1458 capture information, similarly to audio captures and video captures. 1460 There are no known properties of a text-based media which aren't 1461 already covered by the generic mediaCaptureType. Text captures are 1462 hence defined as follows: 1464 1465 1466 1467 1468 1469 1471 1472 1473 1474 1475 1477 Text captures MUST be marked as non spatially definable (i.e., they 1478 MUST present in their XML description the 1479 (Section 11.6) element set to "true"). 1481 15. Other capture types 1483 Other media capture types can be described by using the CLUE data 1484 model. They can be represented by exploiting the "otherCaptureType" 1485 type. This media capture type is conceived to be filled in with 1486 elements defined within extensions of the current schema, i.e., with 1487 elements defined in other XML schemas (see Section 24 for an 1488 example). The otherCaptureType inherits all the features envisioned 1489 for the abstract mediaCaptureType. 1491 The XML Schema representation of the otherCaptureType is the 1492 following: 1494 1495 1496 1497 1498 1499 1501 1502 1503 1504 1505 1507 When defining new media capture types that are going to be described 1508 by means of the element, spatial properties of 1509 such new media capture types SHOULD be defined (e.g., whether or not 1510 they are spatially definable, whether or not they should be 1511 associated with an area of capture, or other properties that may be 1512 defined). 1514 16. 1516 A Media Provider organizes the available captures in capture scenes 1517 in order to help the receiver both in the rendering and in the 1518 selection of the group of captures. Capture scenes are made of media 1519 captures and capture scene views, that are sets of media captures of 1520 the same media type. Each capture scene view is an alternative to 1521 represent completely a capture scene for a fixed media type. 1523 The XML Schema representation of a element is the 1524 following: 1526 1527 1528 1529 1530 1532 1533 1535 1536 1537 1538 1539 1541 Each capture scene is identified by a "sceneID" attribute. The 1542 element can contain zero or more textual 1543 elements, defined as in Section 11.13. Besides , there 1544 is the optional element (Section 16.1), which 1545 contains structured information about the scene in the vcard format, 1546 and the optional element (Section 16.2), which is the 1547 list of the capture scene views. When no is provided, 1548 the capture scene is assumed to be made of all the media captures 1549 which contain the value of its sceneID attribute in their mandatory 1550 captureSceneIDREF attribute. 1552 16.1. 1554 The element contains optional information about 1555 the capture scene according to the vcard format, as specified in the 1556 Xcard RFC [RFC6351]. 1558 16.2. 1560 The element is a mandatory field of a capture scene 1561 containing the list of scene views. Each scene view is represented 1562 by a element (Section 17). 1564 1565 1566 1567 1568 1570 1571 1573 16.3. sceneID attribute 1575 The sceneID attribute is a mandatory attribute containing the 1576 identifier of the capture scene. 1578 16.4. scale attribute 1580 The scale attribute is a mandatory attribute that specifies the scale 1581 of the coordinates provided in the spatial information of the media 1582 capture belonging to the considered capture scene. The scale 1583 attribute can assume three different values: 1585 "mm" - the scale is in millimeters. Systems which know their 1586 physical dimensions (for example professionally installed 1587 telepresence room systems) should always provide such real-world 1588 measurements. 1590 "unknown" - the scale is the same for every media capture in the 1591 capture scene but the unity of measure is undefined. Systems 1592 which are not aware of specific physical dimensions yet still know 1593 relative distances should select "unknown" in the scale attribute 1594 of the capture scene to be described. 1596 "noscale" - there is no common physical scale among the media 1597 captures of the capture scene. That means the scale could be 1598 different for each media capture. 1600 1601 1602 1603 1604 1605 1606 1607 1609 17. 1611 A element represents a capture scene view, which contains 1612 a set of media captures of the same media type describing a capture 1613 scene. 1615 A element is characterized as follows. 1617 1618 1619 1620 1621 1622 1623 1624 1625 One or more optional elements provide human-readable 1626 information about what the scene view contains. is 1627 defined as already seen in Section 11.13. 1629 The remaining child elements are described in the following 1630 subsections. 1632 17.1. 1634 The is the list of the identifiers of the media 1635 captures included in the scene view. It is an element of the 1636 captureIDListType type, which is defined as a sequence of 1637 , each containing the identifier of a media 1638 capture listed within the element: 1640 1641 1642 1643 1645 1646 1648 17.2. sceneViewID attribute 1650 The sceneViewID attribute is a mandatory attribute containing the 1651 identifier of the capture scene view represented by the 1652 element. 1654 18. 1656 The element represents an encoding group, which is 1657 made by a set of one or more individual encodings and some parameters 1658 that apply to the group as a whole. Encoding groups contain 1659 references to individual encodings that can be applied to media 1660 captures. The definition of the element is the 1661 following: 1663 1664 1665 1666 1667 1668 1670 1671 1672 1673 1675 In the following, the contained elements are further described. 1677 18.1. 1679 is an optional field containing the maximum 1680 bitrate expressed in bits per second that can be shared by the 1681 individual encodings included in the encoding group. 1683 18.2. 1685 is the list of the individual encodings grouped 1686 together in the encoding group. Each individual encoding is 1687 represented through its identifier contained within an 1688 element. 1690 1691 1692 1693 1694 1695 1697 18.3. encodingGroupID attribute 1699 The encodingGroupID attribute contains the identifier of the encoding 1700 group. 1702 19. 1704 represents a simultaneous transmission set, i.e., a 1705 list of captures of the same media type that can be transmitted at 1706 the same time by a Media Provider. There are different simultaneous 1707 transmission sets for each media type. 1709 1710 1711 1712 1714 1716 1718 1720 1721 1722 1723 1724 1726 Besides the identifiers of the captures ( 1727 elements), also the identifiers of capture scene views and of capture 1728 scene can be exploited as shortcuts ( and 1729 elements). As an example, let's consider the 1730 situation where there are two capture scene views (S1 and S7). S1 1731 contains captures AC11, AC12, AC13. S7 contains captures AC71, AC72. 1732 Provided that AC11, AC12, AC13, AC71, AC72 can be simultaneously sent 1733 to the media consumer, instead of having 5 1734 elements listed in the simultaneous set (i.e., one 1735 for AC11, one for AC12, and so on), there can be 1736 just two elements (one for S1 and one for S7). 1738 19.1. setID attribute 1740 The "setID" attribute is a mandatory field containing the identifier 1741 of the simultaneous set. 1743 19.2. mediaType attribute 1745 The "mediaType" attribute is an optional attribute containing the 1746 media type of the captures referenced by the simultaneous set. 1748 When only capture scene identifiers are listed within a simultaneous 1749 set, the media type attribute MUST appear in the XML description in 1750 order to determine which media captures can be simultaneously sent 1751 together. 1753 19.3. 1755 contains the identifier of the media capture that 1756 belongs to the simultaneous set. 1758 19.4. 1760 contains the identifier of the scene view containing 1761 a group of captures that are able to be sent simultaneously with the 1762 other captures of the simultaneous set. 1764 19.5. 1766 contains the identifier of the capture scene 1767 where all the included captures of a certain media type are able to 1768 be sent together with the other captures of the simultaneous set. 1770 20. 1772 is a set of captures of the same media type representing 1773 a summary of the complete Media Provider's offer. The content of a 1774 global view is expressed by leveraging only scene view identifiers, 1775 put within elements. Each global view is identified 1776 by a unique identifier within the "globalViewID" attribute. 1778 1779 1780 1781 1783 1785 1786 1787 1788 1790 21. 1792 Information about the participants that are represented in the media 1793 captures is conveyed via the element. As it can be seen 1794 from the XML Schema depicted below, for each participant, a 1795 element is provided. 1797 1798 1799 1800 1801 1802 1804 21.1. 1806 includes all the metadata related to a person represented 1807 within one or more media captures. Such element provides the vcard 1808 of the subject (via the element, see Section 21.1.2) and 1809 his conference role(s) (via one or more elements, see 1810 Section 21.1.3). Furthermore, it has a mandatory "personID" 1811 attribute (Section 21.1.1). 1813 1814 1815 1816 1818 1819 1821 1822 1823 1824 1826 21.1.1. personID attribute 1828 The "personID" attribute carries the identifier of a represented 1829 person. Such an identifier can be used to refer to the participant, 1830 as in the element in the media captures 1831 representation (Section 11.21). 1833 21.1.2. 1835 The element is the XML representation of all the fields 1836 composing a vcard as specified in the Xcard RFC [RFC6351]. The 1837 vcardType is imported by the Xcard XML Schema provided in Appendix A 1838 of [I-D.ietf-ecrit-additional-data]. As such schema specifies, the 1839 element within is mandatory. 1841 21.1.3. 1843 The value of the element determines the role of the 1844 represented participant within the telepresence session organization. 1845 It has been specified as a simple string with an annotation pointing 1846 to an ad hoc defined IANA registry: 1848 1849 1850 1851 1852 Acceptable values (enumerations) for this type are managed 1853 by IANA in the "CLUE Schema registry", 1854 accessible at TBD-IANA. 1855 1856 1857 1859 The current possible values, as per the CLUE framework document 1860 [I-D.ietf-clue-framework], are: "presenter", "timekeeper", 1861 "attendee", "minute taker", "translator", "chairman", "vice- 1862 chairman", "observer". 1864 A participant can play more than one conference role. In that case, 1865 more than one element will appear in his description. 1867 22. 1869 A capture encoding is given from the association of a media capture 1870 with an individual encoding, to form a capture stream as defined in 1871 [I-D.ietf-clue-framework]. Capture encodings are used within 1872 CONFIGURE messages from a Media Consumer to a Media Provider for 1873 representing the streams desired by the Media Consumer. For each 1874 desired stream, the Media Consumer needs to be allowed to specify: 1875 (i) the capture identifier of the desired capture that has been 1876 advertised by the Media Provider; (ii) the encoding identifier of the 1877 encoding to use, among those advertised by the Media Provider; (iii) 1878 optionally, in case of multi-content captures, the list of the 1879 capture identifiers of the desired captures. All the mentioned 1880 identifiers are intended to be included in the ADVERTISEMENT message 1881 that the CONFIGURE message refers to. The XML model of 1882 is provided in the following. 1884 1885 1886 1887 1888 1889 1891 1893 1894 1895 1896 1898 22.1. 1900 is the mandatory element containing the identifier of the 1901 media capture that has been encoded to form the capture encoding. 1903 22.2. 1905 is the mandatory element containing the identifier of 1906 the applied individual encoding. 1908 22.3. 1910 is an optional element to be used in case of 1911 configuration of MCC. It contains the list of capture identifiers 1912 and capture scene view identifiers the Media Consumer wants within 1913 the MCC. That element is structured as the element used to 1914 describe the content of an MCC. The total number of media captures 1915 listed in the MUST be lower than or equal to the 1916 value carried within the attribute of the MCC. 1918 23. 1920 The element includes all the information needed to 1921 represent the Media Provider's description of its telepresence 1922 capabilities according to the CLUE framework. Indeed, it is made by: 1924 the list of the available media captures ( 1925 (Section 5)) 1927 the list of encoding groups ( (Section 6)) 1928 the list of capture scenes ( (Section 7)) 1930 the list of simultaneous transmission sets ( 1931 (Section 8)) 1933 the list of global views sets ( (Section 9)) 1935 meta data about the participants represented in the telepresence 1936 session ( (Section 21)) 1938 It has been conceived only for data model testing purposes and, 1939 though it resembles the body of an ADVERTISEMENT message, it is not 1940 actually used in the CLUE protocol message definitions. The 1941 telepresence capabilities descriptions compliant to this data model 1942 specification that can be found in Section 27 and Section 28 are 1943 provided by using the element. 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1956 1957 1958 1959 1961 24. XML Schema extensibility 1963 The telepresence data model defined in this document is meant to be 1964 extensible. Extensions are accomplished by defining elements or 1965 attributes qualified by namespaces other than 1966 "urn:ietf:params:xml:ns:clue-info" and 1967 "urn:ietf:params:xml:ns:vcard-4.0" for use wherever the schema allows 1968 such extensions (i.e., where the XML Schema definition specifies 1969 "anyAttribute" or "anyElement"). Elements or attributes from unknown 1970 namespaces MUST be ignored. Extensibility was purposefully favored 1971 as much as possible based on expectations about custom 1972 implementations. Hence, the schema offers people enough flexibility 1973 as to define custom extensions, without losing compliance with the 1974 standard. This is achieved by leveraging elements and attributes, which is a common approach with schemas, 1976 still matching the UPA (Unique Particle Attribution) constraint. 1978 24.1. Example of extension 1980 When extending the CLUE data model, a new schema with a new namespace 1981 associated with it needs to be specified. 1983 In the following, an example of extension is provided. The extension 1984 defines a new audio capture attribute ("newAudioFeature") and an 1985 attribute for characterizing the captures belonging to an 1986 "otherCaptureType" defined by the user. An XML document compliant 1987 with the extension is also included. The XML file results validated 1988 against the current CLUE data model schema. 1990 1991 2002 2003 2007 2008 2011 2012 2013 2015 2016 2017 2021 2022 2027 CS1 2028 true 2029 true 2030 EG1 2031 newAudioFeatureValue 2032 2033 2034 2039 CS1 2040 true 2041 EG1 2042 OtherValue 2043 2044 2045 2046 2047 2048 300000 2049 2050 ENC4 2051 ENC5 2052 2053 2054 2055 2056 2057 2058 2060 25. Security considerations 2062 This document defines an XML Schema data model for telepresence 2063 scenarios. The modeled information is identified in the CLUE 2064 framework as necessary in order to enable a full-fledged media stream 2065 negotiation and rendering. Indeed, the XML elements herein defined 2066 are used within CLUE protocol messages to describe both the media 2067 streams representing the Media Provider's telepresence offer and the 2068 desired selection requested by the Media Consumer. Security concerns 2069 described in [I-D.ietf-clue-framework], Section 15, apply to this 2070 document. 2072 Data model information carried within CLUE messages SHOULD be 2073 accessed only by authenticated endpoints. Indeed, authenticated 2074 access is strongly advisable, especially if you convey information 2075 about individuals () and/or scenes 2076 (). There might be more exceptions, depending on 2077 the level of criticality that is associated with the setup and 2078 configuration of a specific session. In principle, one might even 2079 decide that no protection at all is needed for a particular session; 2080 here is why authentication has not been identified as a mandatory 2081 requirement. 2083 Going deeper into details, some information published by the Media 2084 Provider might reveal sensitive data about who and what is 2085 represented in the transmitted streams. The vCard included in the 2086 elements (Section 21.1) mandatorily contains the 2087 identity of the represented person. Optionally vCards can also carry 2088 the person's contact addresses, together with his/her photo and other 2089 personal data. Similar privacy-critical information can be conveyed 2090 by means of elements (Section 16.1) describing the 2091 capture scenes. The elements (Section 11.13) also can 2092 specify details about the content of media captures, capture scenes 2093 and scene views that should be protected. 2095 Integrity attacks to the data model information encapsulated in CLUE 2096 messages can invalidate the success of the telepresence session's 2097 setup by misleading the Media Consumer's and Media Provider's 2098 interpretation of the offered and desired media streams. 2100 The assurance of the authenticated access and of the integrity of the 2101 data model information is up to the involved transport mechanisms, 2102 namely the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data 2103 channel [I-D.ietf-clue-datachannel]. 2105 XML parsers need to be robust with respect to malformed documents. 2106 Reading malformed documents from unknown or untrusted sources could 2107 result in an attacker gaining privileges of the user running the XML 2108 parser. In an extreme situation, the entire machine could be 2109 compromised. 2111 26. IANA considerations 2113 This document registers a new XML namespace, a new XML schema, the 2114 MIME type for the schema and four new registries associated, 2115 respectively, with acceptable , , 2116 and values. 2118 26.1. XML namespace registration 2120 URI: urn:ietf:params:xml:ns:clue-info 2122 Registrant Contact: IETF CLUE Working Group , Roberta 2123 Presta 2125 XML: 2127 BEGIN 2129 2130 2132 2133 2134 2136 CLUE Data Model Namespace 2137 2138 2139

Namespace for CLUE Data Model

2140

urn:ietf:params:xml:ns:clue-info

2141

See 2142 RFC XXXX. 2143 2145

2146 2147 2149 END 2151 26.2. XML Schema registration 2153 This section registers an XML schema per the guidelines in [RFC3688]. 2155 URI: urn:ietf:params:xml:schema:clue-info 2157 Registrant Contact: CLUE working group (clue@ietf.org), Roberta 2158 Presta (roberta.presta@unina.it). 2160 Schema: The XML for this schema can be found as the entirety of 2161 Section 4 of this document. 2163 26.3. MIME Media Type Registration for "application/clue_info+xml" 2165 This section registers the "application/clue_info+xml" MIME type. 2167 To: ietf-types@iana.org 2169 Subject: Registration of MIME media type application/clue_info+xml 2171 MIME media type name: application 2173 MIME subtype name: clue_info+xml 2175 Required parameters: (none) 2177 Optional parameters: charset 2178 Same as the charset parameter of "application/xml" as specified in 2179 [RFC7303], Section 3.2. 2181 Encoding considerations: Same as the encoding considerations of 2182 "application/xml" as specified in [RFC7303], Section 3.2. 2184 Security considerations: This content type is designed to carry data 2185 related to telepresence information. Some of the data could be 2186 considered private. This media type does not provide any protection 2187 and thus other mechanisms such as those described in Section 25 are 2188 required to protect the data. This media type does not contain 2189 executable content. 2191 Interoperability considerations: None. 2193 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 2194 replace XXXX with the RFC number for this specification.]] 2196 Applications that use this media type: CLUE-capable telepresence 2197 systems. 2199 Additional Information: Magic Number(s): (none), 2200 File extension(s): .clue, 2201 Macintosh File Type Code(s): TEXT. 2203 Person & email address to contact for further information: Roberta 2204 Presta (roberta.presta@unina.it). 2206 Intended usage: LIMITED USE 2208 Author/Change controller: The IETF 2210 Other information: This media type is a specialization of 2211 application/xml [RFC7303], and many of the considerations described 2212 there also apply to application/clue_info+xml. 2214 26.4. Registry for acceptable values 2216 IANA is requested to create a registry of acceptable values for the 2217 the tag as defined in Section 11.18. The initial values for 2218 this registry are "room", "table", "lectern", "individual", and 2219 "audience". 2221 New values are assigned by Expert Review per [RFC5226]. This 2222 reviewer will ensure that the requested registry entry conforms to 2223 the prescribed formatting. 2225 IANA is further requested to update this draft with the URL to the 2226 new registry in Section 11.18, marked as "TBD-IANA". 2228 26.5. Registry for acceptable values 2230 IANA is requested to create a registry of acceptable values for the 2231 the tag as defined in Section 11.19. The initial 2232 values for this registry are "slides" and "images". 2234 New values are assigned by Expert Review per [RFC5226]. This 2235 reviewer will ensure that the requested registry entry conforms to 2236 the prescribed formatting. 2238 IANA is further requested to update this draft with the URL to the 2239 new registry in Section 11.19, marked as "TBD-IANA". 2241 26.6. Registry for acceptable values 2243 IANA is requested to create a registry of acceptable values for the 2244 the tag as defined in Section 12.1. The initial 2245 values for this registry are "uni", "shotgun", "omni", "figure8", 2246 "cardioid" and "hyper-cardioid". 2248 New values are assigned by Expert Review per [RFC5226]. This 2249 reviewer will ensure that the requested registry entry conforms to 2250 the prescribed formatting. 2252 IANA is further requested to update this draft with the URL to the 2253 new registry in Section 12.1, marked as "TBD-IANA". 2255 26.7. Registry for acceptable values 2257 IANA is requested to create a registry of acceptable values for the 2258 the tag as defined in Section 21.1.3. The initial 2259 values for this registry are "presenter", "timekeeper", "attendee", 2260 "minute taker", "translator", "chairman", "vice-chairman", 2261 "observer". 2263 New values are assigned by Expert Review per [RFC5226]. This 2264 reviewer will ensure that the requested registry entry conforms to 2265 the prescribed formatting. 2267 IANA is further requested to update this draft with the URL to the 2268 new registry in Section 21.1.3, marked as "TBD-IANA". 2270 27. Sample XML file 2272 The following XML document represents a schema compliant example of a 2273 CLUE telepresence scenario. Taking inspiration from the examples 2274 described in the framework draft ([I-D.ietf-clue-framework]), it is 2275 provided the XML representation of an endpoint-style Media Provider's 2276 ADVERTISEMENT. 2278 There are three cameras, where the central one is also capable of 2279 capturing a zoomed-out view of the overall telepresence room. 2280 Besides the three video captures coming from the cameras, the Media 2281 Provider makes available a further multi-content capture of the 2282 loudest segment of the room, obtained by switching the video source 2283 across the three cameras. For the sake of simplicity, only one audio 2284 capture is advertised for the audio of the whole room. 2286 The three cameras are placed in front of three participants (Alice, 2287 Bob and Ciccio), whose vcard and conference role details are also 2288 provided. 2290 Media captures are arranged into four capture scene views: 2292 1. (VC0, VC1, VC2) - left, center and right camera video captures 2294 2. (VC3) - video capture associated with loudest room segment 2295 3. (VC4) - video capture zoomed out view of all people in the room 2297 4. (AC0) - main audio 2299 There are two encoding groups: (i) EG0, for video encodings, and (ii) 2300 EG1, for audio encodings. 2302 As to the simultaneous sets, VC1 and VC4 cannot be transmitted 2303 simultaneously since they are captured by the same device, i.e., the 2304 central camera (VC4 is a zoomed-out view while VC1 is a focused view 2305 of the front participant). On the other hand, VC3 and VC4 cannot be 2306 simultaneous either, since VC3, the loudest segment of the room, 2307 might be at a certain point in time focusing on the central part of 2308 the room, i.e., the same as VC1. The simultaneous sets would then be 2309 the following: 2311 SS1 made by VC3 and all the captures in the first capture scene view 2312 (VC0,VC1,VC2); 2314 SS2 made by VC0, VC2, VC4 2316 2317 2320 2321 2324 CS1 2325 2326 2327 2328 0.0 2329 0.0 2330 10.0 2331 2332 2333 0.0 2334 1.0 2335 10.0 2336 2337 2338 2339 true 2340 EG1 2341 main audio from the room 2342 2343 1 2344 it 2345 static 2346 room 2347 2348 alice 2349 bob 2350 ciccio 2351 2352 2353 2356 CS1 2357 2358 2359 2360 -2.0 2361 0.0 2362 10.0 2363 2364 2365 2366 2367 -3.0 2368 20.0 2369 9.0 2370 2371 2372 -1.0 2373 20.0 2374 9.0 2375 2376 2377 -3.0 2378 20.0 2379 11.0 2380 2381 2382 -1.0 2383 20.0 2384 11.0 2385 2386 2387 2388 true 2389 EG0 2390 left camera video capture 2391 2392 1 2393 it 2394 static 2395 individual 2396 2397 ciccio 2398 2399 2400 2403 CS1 2404 2405 2406 2407 0.0 2408 0.0 2409 10.0 2410 2411 2412 2413 2414 -1.0 2415 20.0 2416 9.0 2417 2418 2419 1.0 2420 20.0 2421 9.0 2422 2423 2424 -1.0 2425 20.0 2426 11.0 2427 2428 2429 1.0 2430 20.0 2431 11.0 2432 2433 2434 2435 true 2436 EG0 2437 central camera video capture 2438 2439 1 2440 it 2441 static 2442 individual 2443 2444 alice 2445 2446 2447 2450 CS1 2451 2452 2453 2454 2.0 2455 0.0 2456 10.0 2457 2458 2459 2460 2461 1.0 2462 20.0 2463 9.0 2464 2465 2466 3.0 2467 20.0 2468 9.0 2469 2470 2471 1.0 2472 20.0 2473 11.0 2474 2475 2476 3.0 2477 20.0 2478 11.0 2479 2480 2481 2482 true 2483 EG0 2484 right camera video capture 2485 2486 1 2487 it 2488 static 2489 individual 2490 2491 bob 2492 2493 2494 2497 CS1 2498 2499 2500 2501 -3.0 2502 20.0 2503 9.0 2504 2505 2506 3.0 2507 20.0 2508 9.0 2509 2510 2511 -3.0 2512 20.0 2513 11.0 2514 2515 2516 3.0 2517 20.0 2518 11.0 2519 2520 2521 2522 2523 SE1 2524 2525 SoundLevel:0 2526 EG0 2527 loudest room segment 2528 2 2529 it 2530 static 2531 individual 2533 2534 2537 CS1 2538 2539 2540 2541 0.0 2542 0.0 2543 10.0 2544 2545 2546 2547 2548 -3.0 2549 20.0 2550 7.0 2551 2552 2553 3.0 2554 20.0 2555 7.0 2556 2557 2558 -3.0 2559 20.0 2560 13.0 2561 2562 2563 3.0 2564 20.0 2565 13.0 2566 2567 2568 2569 true 2570 EG0 2571 zoomed out view of all people in the 2572 room 2573 2 2574 it 2575 static 2576 room 2577 2578 alice 2579 bob 2580 ciccio 2582 2583 2584 2585 2586 2587 600000 2588 2589 ENC1 2590 ENC2 2591 ENC3 2592 2593 2594 2595 300000 2596 2597 ENC4 2598 ENC5 2599 2600 2601 2602 2603 2604 2605 2606 2607 VC0 2608 VC1 2609 VC2 2610 2611 2612 2613 2614 VC3 2615 2616 2617 2618 2619 VC4 2620 2621 2622 2623 2624 AC0 2625 2626 2627 2628 2629 2630 2631 2632 VC3 2633 SE1 2634 2635 2636 VC0 2637 VC2 2638 VC4 2639 2640 2641 2642 2643 2644 2645 Bob 2646 2647 2648 minute taker 2649 2650 2651 2652 2653 Alice 2654 2655 2656 presenter 2657 2658 2659 2660 2661 Ciccio 2662 2663 2664 chairman 2665 timekeeper 2666 2667 2668 2670 28. MCC example 2672 Enhancing the scenario presented in the previous example, the Media 2673 Provider is able to advertise a composed capture VC7 made by a big 2674 picture representing the current speaker (VC3) and two picture-in- 2675 picture boxes representing the previous speakers (the previous one 2676 -VC5- and the oldest one -VC6). The provider does not want to 2677 instantiate and send VC5 and VC6, so it does not associate any 2678 encoding group with them. Their XML representations are provided for 2679 enabling the description of VC7. 2681 A possible description for that scenario could be the following: 2683 2684 2686 2687 2690 CS1 2691 2692 2693 2694 0.0 2695 0.0 2696 10.0 2697 2698 2699 0.0 2700 1.0 2701 10.0 2702 2703 2704 2705 true 2706 EG1 2707 main audio from the room 2708 2709 1 2710 it 2711 static 2712 room 2713 2714 alice 2715 bob 2716 ciccio 2717 2718 2719 2722 CS1 2723 2724 2725 2726 0.5 2727 1.0 2728 0.5 2729 2730 2731 0.5 2732 0.0 2733 0.5 2734 2735 2736 2737 true 2738 EG0 2739 left camera video capture 2740 2741 1 2742 it 2743 static 2744 individual 2745 2746 ciccio 2747 2748 2749 2752 CS1 2753 2754 2755 2756 0.0 2757 0.0 2758 10.0 2759 2760 2761 2762 2763 -1.0 2764 20.0 2765 9.0 2766 2767 2768 1.0 2769 20.0 2770 9.0 2771 2772 2773 -1.0 2774 20.0 2775 11.0 2776 2777 2778 1.0 2779 20.0 2780 11.0 2781 2782 2783 2784 true 2785 EG0 2786 central camera video capture 2787 2788 1 2789 it 2790 static 2791 individual 2792 2793 alice 2794 2795 2796 2799 CS1 2800 2801 2802 2803 2.0 2804 0.0 2805 10.0 2806 2807 2808 2809 2810 1.0 2811 20.0 2812 9.0 2813 2814 2815 3.0 2816 20.0 2817 9.0 2818 2819 2820 1.0 2821 20.0 2822 11.0 2823 2824 2825 3.0 2826 20.0 2827 11.0 2828 2829 2830 2831 true 2832 EG0 2833 right camera video capture 2834 2835 1 2836 it 2837 static 2838 individual 2839 2840 bob 2841 2842 2843 2846 CS1 2847 2848 2849 2850 -3.0 2851 20.0 2852 9.0 2853 2854 2855 3.0 2856 20.0 2857 9.0 2858 2859 2860 -3.0 2861 20.0 2862 11.0 2863 2864 2865 3.0 2867 20.0 2868 11.0 2869 2870 2871 2872 2873 SE1 2874 2875 SoundLevel:0 2876 EG0 2877 loudest room segment 2878 2 2879 it 2880 static 2881 individual 2882 2883 2886 CS1 2887 2888 2889 2890 0.0 2891 0.0 2892 10.0 2893 2894 2895 2896 2897 -3.0 2898 20.0 2899 7.0 2900 2901 2902 3.0 2903 20.0 2904 7.0 2905 2906 2907 -3.0 2908 20.0 2909 13.0 2910 2911 2912 3.0 2913 20.0 2914 13.0 2915 2916 2917 2918 true 2919 EG0 2920 2921 zoomed out view of all people in the room 2922 2923 2 2924 it 2925 static 2926 room 2927 2928 alice 2929 bob 2930 ciccio 2931 2932 2933 2936 CS1 2937 2938 2939 2940 -3.0 2941 20.0 2942 9.0 2943 2944 2945 3.0 2946 20.0 2947 9.0 2948 2949 2950 -3.0 2951 20.0 2952 11.0 2953 2954 2955 3.0 2956 20.0 2957 11.0 2958 2959 2960 2961 2962 SE1 2964 2965 SoundLevel:1 2966 penultimate loudest room segment 2967 2968 it 2969 static 2970 individual 2971 2972 2975 CS1 2976 2977 2978 2979 -3.0 2980 20.0 2981 9.0 2982 2983 2984 3.0 2985 20.0 2986 9.0 2987 2988 2989 -3.0 2990 20.0 2991 11.0 2992 2993 2994 3.0 2995 20.0 2996 11.0 2997 2998 2999 3000 3001 SE1 3002 3003 SoundLevel:2 3004 last but two loudest room segment 3005 3006 it 3007 static 3008 individual 3009 3010 3013 CS1 3014 3015 3016 3017 -3.0 3018 20.0 3019 9.0 3020 3021 3022 3.0 3023 20.0 3024 9.0 3025 3026 3027 -3.0 3028 20.0 3029 11.0 3030 3031 3032 3.0 3033 20.0 3034 11.0 3035 3036 3037 3038 3039 VC3 3040 VC5 3041 VC6 3042 3043 3 3044 EG0 3045 big picture of the current speaker + 3046 pips about previous speakers 3047 3 3048 it 3049 static 3050 individual 3051 3052 3053 3054 3055 600000 3056 3057 ENC1 3058 ENC2 3059 ENC3 3061 3062 3063 3064 300000 3065 3066 ENC4 3067 ENC5 3068 3069 3070 3071 3072 3073 3074 3075 participants' individual 3076 videos 3077 3078 VC0 3079 VC1 3080 VC2 3081 3082 3083 3084 loudest segment of the 3085 room 3086 3087 VC3 3088 3089 3090 3091 loudest segment of the 3092 room + pips 3093 3094 VC7 3095 3096 3097 3098 room audio 3099 3100 AC0 3101 3102 3103 3104 room video 3105 3106 VC4 3107 3108 3110 3111 3112 3113 3114 3115 VC3 3116 VC7 3117 SE1 3118 3119 3120 VC0 3121 VC2 3122 VC4 3123 3124 3125 3126 3127 3128 3129 Bob 3130 3131 3132 minute taker 3133 3134 3135 3136 3137 Alice 3138 3139 3140 presenter 3141 3142 3143 3144 3145 Ciccio 3146 3147 3148 chairman 3149 timekeeper 3150 3151 3152 3154 29. Diff with draft-ietf-clue-data-model-schema-16 version 3156 As per Alexey Melnikov's and Stefan Winter's comments: replaced wrong 3157 references to RFC2119 in section 11.3 and section 11.5. The updated 3158 reference is to RFC5646. 3160 30. Diff with draft-ietf-clue-data-model-schema-15 version 3162 Applied modifications as per the following reviews: (i) Alexey 3163 Melnikov's discuss and comments (abstract amendments, typo 3164 corrections, insertion of references, etc.); (ii) Kathleen Moriarty's 3165 discuss and comments (amendments to the Security Considerations 3166 section); (iii) Stefan Winter's OPS-DIR review (use of enumerated 3167 types in the schema). 3169 31. Diff with draft-ietf-clue-data-model-schema-14 version 3171 Applied modifications as per the following reviews: (i) Henry S. 3172 Thompson's APPS-DIR review; (ii) Stefan Winter's OPS-DIR review; 3173 (iii) Francis Dupont's GEN-ART review; (iv) Rich Salz's review (as 3174 part of the security directorate's ongoing effort to review all IETF 3175 documents being processed by the IESG.) 3177 32. Diff with draft-ietf-clue-data-model-schema-13 version 3179 Applied modifications as per the latest Area Director (Alissa 3180 Cooper's) review comments. 3182 33. Diff with draft-ietf-clue-data-model-schema-12 version 3184 Removed some typos and inconsistencies. Applied modifications as per 3185 Alissa Cooper's review comments. 3187 34. Diff with draft-ietf-clue-data-model-schema-11 version 3189 Applied modifications as per Mark Duckworth's review (example 3190 corrections and maxCapturesType modification) 3192 maxCapturesType has been changed from positiveInteger to 3193 unsignedShort excluding value 0. 3195 35. Diff with draft-ietf-clue-data-model-schema-10 version 3197 Minor modifications have been applied to address nits at page https:/ 3198 /www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/ 3199 draft-ietf-clue-data-model-schema-10.txt. 3201 36. Diff with draft-ietf-clue-data-model-schema-09 version 3203 o We have introduced a element containing a 3204 mandatory and an optional in 3205 the definition of as per Paul's review 3207 o A new type definition for switching policies (resembled by 3208 element) has been provided in order to have acceptable 3209 values in the form of "token:index". 3211 o Minor modifications suggested in WGLC reviews have been applied. 3213 37. Diff with draft-ietf-clue-data-model-schema-08 version 3215 o Typos correction 3217 38. Diff with draft-ietf-clue-data-model-schema-07 version 3219 o IANA Considerations: text added 3221 o maxCaptureEncodings removed 3223 o personTypeType values aligned with CLUE framework 3225 o allowSubsetChoice added for multiple content captures 3227 o embeddedText moved from videoCaptureType definition to 3228 mediaCaptureType definition 3230 o typos removed from section Terminology 3232 39. Diff with draft-ietf-clue-data-model-schema-06 version 3234 o Capture Scene Entry/Entries renamed as Capture Scene View/Views in 3235 the text, / renamed as / 3236 in the XML schema. 3238 o Global Scene Entry/Entries renamed as Global View/Views in the 3239 text, / renamed as 3240 / 3242 o Security section added. 3244 o Extensibility: a new type is introduced to describe other types of 3245 media capture (otherCaptureType), text and example added. 3247 o Spatial information section updated: capture point optional, text 3248 now is coherent with the framework one. 3250 o Audio capture description: added, 3251 removed, disallowed. 3253 o Simultaneous set definition: added to refer to 3254 capture scene identifiers as shortcuts and an optional mediaType 3255 attribute which is mandatory to use when only capture scene 3256 identifiers are listed. 3258 o Encoding groups: removed the constraint of the same media type. 3260 o Updated text about media captures without 3261 (optional in the XML schema). 3263 o "mediaType" attribute removed from homogeneous groups of capture 3264 (scene views and globlal views) 3266 o "mediaType" attribute removed from the global view textual 3267 description. 3269 o "millimeters" scale value changed in "mm" 3271 40. Diff with draft-ietf-clue-data-model-schema-04 version 3273 globalCaptureEntries/Entry renamed as globalSceneEntries/Entry; 3275 sceneInformation added; 3277 Only capture scene entry identifiers listed within global scene 3278 entries (media capture identifiers removed); 3280 renamed as in the >clueInfo< template 3282 renamed as to synch with the framework 3283 terminology 3285 renamed as to synch with the 3286 framework terminology 3288 renamed as in the media capture 3289 type definition to remove ambiguity 3291 Examples have been updated with the new definitions of 3292 and of . 3294 41. Diff with draft-ietf-clue-data-model-schema-03 version 3296 encodings section has been removed 3298 global capture entries have been introduced 3300 capture scene entry identifiers are used as shortcuts in listing 3301 the content of MCC (similarly to simultaneous set and global 3302 capture entries) 3304 Examples have been updated. A new example with global capture 3305 entries has been added. 3307 has been made optional. 3309 has been renamed into 3311 Obsolete comments have been removed. 3313 participants information has been added. 3315 42. Diff with draft-ietf-clue-data-model-schema-02 version 3317 captureParameters and encodingParameters have been removed from 3318 the captureEncodingType 3320 data model example has been updated and validated according to the 3321 new schema. Further description of the represented scenario has 3322 been provided. 3324 A multiple content capture example has been added. 3326 Obsolete comments and references have been removed. 3328 43. Acknowledgments 3330 The authors thank all the CLUErs for their precious feedbacks and 3331 support. Thanks also to Alissa Cooper, whose AD reviews helped us 3332 improve the quality of the document. 3334 44. References 3336 44.1. Normative References 3338 [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data 3339 channel", 3340 draft-ietf-clue-datachannel-14 3341 (work in progress), August 2016. 3343 [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and 3344 S. Wenger, "Framework for 3345 Telepresence Multi-Streams", 3346 draft-ietf-clue-framework-25 (work 3347 in progress), January 2016. 3349 [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE 3350 protocol", 3351 draft-ietf-clue-protocol-08 (work 3352 in progress), May 2016. 3354 [I-D.ietf-ecrit-additional-data] Gellens, R., Rosen, B., Tschofenig, 3355 H., Marshall, R., and J. 3356 Winterbottom, "Additional Data 3357 Related to an Emergency Call", 3358 draft-ietf-ecrit-additional-data-38 3359 (work in progress), April 2016. 3361 [RFC2119] Bradner, S., "Key words for use in 3362 RFCs to Indicate Requirement 3363 Levels", BCP 14, RFC 2119, 3364 DOI 10.17487/RFC2119, March 1997, < 3365 http://www.rfc-editor.org/info/ 3366 rfc2119>. 3368 [RFC5226] Narten, T. and H. Alvestrand, 3369 "Guidelines for Writing an IANA 3370 Considerations Section in RFCs", 3371 BCP 26, RFC 5226, DOI 10.17487/ 3372 RFC5226, May 2008, . 3375 [RFC5646] Phillips, A., Ed. and M. Davis, 3376 Ed., "Tags for Identifying 3377 Languages", BCP 47, RFC 5646, 3378 DOI 10.17487/RFC5646, 3379 September 2009, . 3382 [RFC6351] Perreault, S., "xCard: vCard XML 3383 Representation", RFC 6351, 3384 DOI 10.17487/RFC6351, August 2011, 3385 . 3388 [RFC7303] Thompson, H. and C. Lilley, "XML 3389 Media Types", RFC 7303, 3390 DOI 10.17487/RFC7303, July 2014, . 3394 44.2. Informative References 3396 [RFC3550] Schulzrinne, H., Casner, S., 3397 Frederick, R., and V. Jacobson, 3398 "RTP: A Transport Protocol for 3399 Real-Time Applications", STD 64, 3400 RFC 3550, DOI 10.17487/RFC3550, 3401 July 2003, . 3404 [RFC3688] Mealling, M., "The IETF XML 3405 Registry", BCP 81, RFC 3688, 3406 DOI 10.17487/RFC3688, January 2004, 3407 . 3410 [RFC4353] Rosenberg, J., "A Framework for 3411 Conferencing with the Session 3412 Initiation Protocol (SIP)", 3413 RFC 4353, DOI 10.17487/RFC4353, 3414 February 2006, . 3417 [RFC6838] Freed, N., Klensin, J., and T. 3418 Hansen, "Media Type Specifications 3419 and Registration Procedures", 3420 BCP 13, RFC 6838, DOI 10.17487/ 3421 RFC6838, January 2013, . 3424 [RFC7667] Westerlund, M. and S. Wenger, "RTP 3425 Topologies", RFC 7667, 3426 DOI 10.17487/RFC7667, 3427 November 2015, . 3430 Authors' Addresses 3432 Roberta Presta 3433 University of Napoli 3434 Via Claudio 21 3435 Napoli 80125 3436 Italy 3438 EMail: roberta.presta@unina.it 3440 Simon Pietro Romano 3441 University of Napoli 3442 Via Claudio 21 3443 Napoli 80125 3444 Italy 3446 EMail: spromano@unina.it