CLUE Data Model Namespace Namespace for CLUE Data Model urn:ietf:params:xml:ns:clue-info
See RFC 8846.
26.2. XML Schema Registration This section registers an XML schema per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:clue-info Registrant Contact: CLUE Working Group (clue@ietf.org), Roberta Presta (roberta.presta@unina.it). Schema: The XML for this schema can be found in its entirety in Section 4 of this document. 26.3. Media Type Registration for "application/clue_info+xml" This section registers the "application/clue_info+xml" media type. To: ietf-types@iana.org Subject: Registration of media type application/clue_info+xml Type name: application Subtype name: clue_info+xml Required parameters: (none) Optional parameters: charset Same as the charset parameter of "application/xml" as specified in [RFC7303], Section 3.2. Encoding considerations: Same as the encoding considerations of "application/xml" as specified in [RFC7303], Section 3.2. Security considerations: This content type is designed to carry data related to telepresence information. Some of the data could be considered private. This media type does not provide any protection and thus other mechanisms such as those described in Section 25 are required to protect the data. This media type does not contain executable content. Interoperability considerations: None. Published specification: RFC 8846 Applications that use this media type: CLUE-capable telepresence systems. Additional Information: Magic Number(s): none File extension(s): .clue Macintosh File Type Code(s): TEXT Person & email address to contact for further information: Roberta Presta (roberta.presta@unina.it). Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of "application/xml" [RFC7303], and many of the considerations described there also apply to "application/clue_info+xml". 26.4. Registry for Acceptable Values IANA has created a registry of acceptable values for the tag as defined in Section 11.18. The initial values for this registry are "room", "table", "lectern", "individual", and "audience". New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. 26.5. Registry for Acceptable Values IANA has created a registry of acceptable values for the tag as defined in Section 11.19. The initial values for this registry are "slides" and "images". New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. 26.6. Registry for Acceptable Values IANA has created a registry of acceptable values for the tag as defined in Section 12.1. The initial values for this registry are "uni", "shotgun", "omni", "figure8", "cardioid", and "hyper-cardioid". New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. 26.7. Registry for Acceptable Values IANA has created a registry of acceptable values for the tag as defined in Section 21.1.3. The initial values for this registry are "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman", and "observer". New values are assigned by Expert Review per [RFC8126]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. 27. Sample XML File The following XML document represents a schema-compliant example of a CLUE telepresence scenario. Taking inspiration from the examples described in the framework specification [RFC8845], the XML representation of an endpoint-style Media Provider's ADVERTISEMENT is provided. There are three cameras, where the central one is also capable of capturing a zoomed-out view of the overall telepresence room. Besides the three video captures coming from the cameras, the Media Provider makes available a further multicontent capture of the loudest segment of the room, obtained by switching the video source across the three cameras. For the sake of simplicity, only one audio capture is advertised for the audio of the whole room. The three cameras are placed in front of three participants (Alice, Bob, and Ciccio), whose vCard and conference role details are also provided. Media captures are arranged into four capture scene views: 1. (VC0, VC1, VC2) - left, center, and right camera video captures 2. (VC3) - video capture associated with loudest room segment 3. (VC4) - video capture zoomed-out view of all people in the room 4. (AC0) - main audio There are two encoding groups: (i) EG0, for video encodings, and (ii) EG1, for audio encodings. As to the simultaneous sets, VC1 and VC4 cannot be transmitted simultaneously since they are captured by the same device, i.e., the central camera (VC4 is a zoomed-out view while VC1 is a focused view of the front participant). On the other hand, VC3 and VC4 cannot be simultaneous either, since VC3, the loudest segment of the room, might be at a certain point in time focusing on the central part of the room, i.e., the same as VC1. The simultaneous sets would then be the following: SS1: made by VC3 and all the captures in the first capture scene view (VC0,VC1,and VC2) SS2: made by VC0, VC2, and VC4 CS1 0.0 0.0 10.0 0.0 1.0 10.0 true EG1 main audio from the room 1 it static room alice bob ciccio CS1 -2.0 0.0 10.0 -3.0 20.0 9.0 -1.0 20.0 9.0 -3.0 20.0 11.0 -1.0 20.0 11.0 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed-out view of all people in the room 2 it static room alice bob ciccio 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 VC0 VC1 VC2 VC3 VC4 AC0 VC3 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Ciccio chairman timekeeper 28. MCC Example Enhancing the scenario presented in the previous example, the Media Provider is able to advertise a composed capture VC7 made by a big picture representing the current speaker (VC3) and two picture-in- picture boxes representing the previous speakers (the previous one, VC5, and the oldest one, VC6). The provider does not want to instantiate and send VC5 and VC6, so it does not associate any encoding group with them. Their XML representations are provided for enabling the description of VC7. A possible description for that scenario could be the following: CS1 0.0 0.0 10.0 0.0 1.0 10.0 true EG1 main audio from the room 1 it static room alice bob ciccio CS1 0.5 1.0 0.5 0.5 0.0 0.5 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed-out view of all people in the room 2 it static room alice bob ciccio CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:1 previous loudest room segment per the most recent iteration of the sound level detection algorithm it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:2 previous loudest room segment per the second most recent iteration of the sound level detection algorithm it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 VC3 VC5 VC6 3 EG0 big picture of the current speaker + pips about previous speakers 3 it static individual 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 participants' individual videos VC0 VC1 VC2 loudest segment of the room VC3 loudest segment of the room + pips VC7 room audio AC0 room video VC4 VC3 VC7 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Ciccio chairman timekeeper 29. References 29.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, . [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, . [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8845] Duckworth, M., Ed., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", RFC 8845, DOI 10.17487/RFC8845, January 2021, . [RFC8847] Presta, R. and S P. Romano, "Protocol for Controlling Multiple Streams for Telepresence (CLUE)", RFC 8847, DOI 10.17487/RFC8847, January 2021, . [RFC8850] Holmberg, C., "Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel", RFC 8850, DOI 10.17487/RFC8850, January 2021, . 29.2. Informative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Acknowledgements The authors thank all the CLUE contributors for their valuable feedback and support. Thanks also to Alissa Cooper, whose AD review helped us improve the quality of the document. Authors' Addresses Roberta Presta University of Napoli Via Claudio 21 80125 Napoli Italy Email: roberta.presta@unina.it Simon Pietro Romano University of Napoli Via Claudio 21 80125 Napoli Italy Email: spromano@unina.it
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4