One document matched: draft-groves-perc-clue-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!--
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC6350 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6350.xml">
<!ENTITY RFC6501 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6501.xml">
-->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-groves-perc-clue-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Usage of CLUE with PERC">Usage of CLUE with PERC</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Christian Groves" initials="C" role="editor"
surname="Groves">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Melbourne</city>
<region></region>
<code></code>
<country>Australia</country>
</postal>
<email>Christian.Groves@nteczone.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Weiwei Yang" initials="W"
surname="Yang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>P.R.China</country>
</postal>
<email>tommy@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Roni Even" initials="R"
surname="Even">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Tel Aviv</city>
<region></region>
<code></code>
<country>Isreal</country>
</postal>
<email>roni.even@mail01.huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Applications and Real-Time Area</area>
<workgroup>PERC</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document provides an initial discussion of the relationship between PERC and CLUE. It seeks to identify any potential impacts or/and enhancement to the way that CLUE is used in the PERC architecture.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>OThe PERC working charter specifically mentions that the solution for PERC should:<list hangIndent="4" style="hanging">
<t>"be implementable by both SIP (RFC3261) and WebRTC endpoints [I-D.ietf-rtcweb-overview]. How telepresence endpoints using the protocols defined in the CLUE working group could utilize the defined security solution needs to be considered. However, it is acknowledged that limitations may exist, resulting in restricted functionality or need for additional adaptations of the CLUE protocols."</t>
</list></t>
<t>It also indicates that work for documenting the model for integrating PERC with based with the establishment of CLUE conferences needs to be performed.</t>
<t>This draft provides some initial information to address both these areas.</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/> when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings.</t>
</section>
<section title="CLUE Background">
<t>The CLUE protocol framework <xref target="I-D.ietf-clue-framework"/> effectively is a means of sending metadata about media captures and encodings between a Providing Endpoint and a Consuming Endpoint. The CLUE protocol is transmitted using a WebRTC Datachannel <xref target="I-D.ietf-clue-datachannel"/> meaning that any SRTP based mechanisms for encrypting this metadata cannot be used.</t>
<t>The information that can be sent regarding media captures is summarized below:<list hangIndent="4" style="hanging">
<t>- Spatial information, including point of capture, point on line of capture, area of capture, mobility of capture and audio capture sensitivity pattern;</t>
<t>- Descriptive information, including a human readable description, indication of presentation, field of view type and language;</t>
<t>- Person information, including the role of the person and xCard description;</t>
<t>- Miscellaneous information, including whether text is embedded or a relation to other captures.</t>
</list>
</t>
<t>It is possible for providers through the Multi-Content Capture (MCC) mechanism to provide the information about the individual contributing sources. It can provide the switching policy as well as synchronization information.</t>
<t>Information about the overall "Scene" may also be provided including views, human readable descriptions, xCard and scale information.</t>
<t>Using the CLUE protocol information the Consuming endpoint can then choose what media captures and encodings that it would like to receive through the use of CLUE and SIP/SDP signalling. Media is typically provided through SRTP. Figure 2 / <xref target="I-D.ietf-clue-framework"/> highlights the basic call flow. Figure 1 below provides a copy of this flow.</t>
<figure align="left" anchor="figure1" title="CLUE Basic Information Flow">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------+ +-----------+
| Endpoint1 | | Endpoint2 |
+----+------+ +-----+-----+
| INVITE (BASIC SDP+CLUECHANNEL) |
|--------------------------------->|
| 200 0K (BASIC SDP+CLUECHANNEL)|
|<---------------------------------|
| ACK |
|--------------------------------->|
| |
|<################################>|
| BASIC SDP MEDIA SESSION |
|<################################>|
| |
| CONNECT (CLUE CTRL CHANNEL) |
|=================================>|
| ... |
|<================================>|
| CLUE CTRL CHANNEL ESTABLISHED |
|<================================>|
| |
| ADVERTISEMENT 1 |
|*********************************>|
| ADVERTISEMENT 2 |
|<*********************************|
| |
| CONFIGURE 1 |
|<*********************************|
| CONFIGURE 2 |
|*********************************>|
| |
| REINVITE (UPDATED SDP) |
|--------------------------------->|
| 200 0K (UPDATED SDP)|
|<---------------------------------|
| ACK |
|--------------------------------->|
| |
|<################################>|
| UPDATED SDP MEDIA SESSION |
|<################################>|
| |
v v
]]></artwork>
</figure>
<t>Whilst CLUE is a point to point protocol it may be used in conferences containing multipoint control units (MCU)s. In this scenario the MCU acts as an aggregation point for CLUE information. That is the MCU receives ADVERTISEMENT messages received from multiple endpoints before deciding on the contents of the ADVERTISEMENT that it wishes to send. Likewise the MCU will use received CONFIGURE messages to decide what the contents of its CONFIGURE messages will be. In doing so the MCU may apply any local policy / provisioning information to its decisions. Figure 2 illustrates this CLUE signalling. The SIP/SDP signalling is omitted for brevity.</t>
<figure align="left" anchor="figure2" title="CLUE MCU Flow">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------+ +-----------+ +-----------+ +-----------+
| Endpoint1 | | Endpoint2 | | MCU | | Endpoint3 |
+----+------+ +----+------+ +-----+-----+ +-----+-----+
| ADVERTISEMENT 1 | | |
|***********************************>| |
| | ADVERTISEMENT 2 | |
| |*****************>| |
| | | ADVERTISEMENT 3|
| | |***************>|
| | | CONFIGURE 1 |
| | |<***************|
| CONFIGURE 2 | | |
|<***********************************| |
| | CONFIGURE 3 | |
| |<*****************| |
| MEDIA FLOW | | |
|***********************************>| |
| | MEDIA FLOW | |
| |*****************>| |
| | | MEDIA FLOW |
| | |***************>|
]]></artwork>
</figure>
<t>Figure 2 shows a unidirectional media flow to Endpoint3. A bi-directional media flow would be enabled by Endpoint3 providing an ADVERTISEMENT to the MCU and the MCU providing ADVERTISEMENTS to Endpoint1 and Endpoint2. Endpoint1 and Endpoint2 would then also send CONFIGURE messages to the MCU and the MCU would send a CONFIGURE message to Endpoint3.</t>
<t>Thus the selection of a particular Media Capture and Encoding (Capture Encoding) by the endpoints drives what topology occurs at the MCU. However there is a caveat. The MCU could apply filtering of the CLUE metadata to provide a sub-set of the data or append its own data. For example it may decide that rather than offer the source audio from Endpoint1 and Endpoint2 as individual streams, it will offer a mix of these two sources, as individual streams.</t>
</section>
<section title="CLUE Relation to PERC">
<t>As detailed in the charter, the goal of the PERC WG is to:<list hangIndent="4" style="hanging">
<t>"...work on a solution that enables centralized SRTP-based conferencing, where the central device distributing the media is not required to be trusted with the keys to decrypt the participants' media. The media must be kept confidential and authenticated between an originating endpoint and the explicitly allowed receiving endpoints or other devices. The meta information provided to the central device is to be limited to the minimal required for it to perform its function to preserve the conference participant's privacy."</t>
</list>
</t>
<t>As described above CLUE largely provides metadata (or meta information) so the task is to identify the minimal set of CLUE data required for CLUE to still work. It also needs to be considered the limited functionality of a media distribution device (MDD) as compared to an MCU.</t>
<t>In broad terms the initial PERC drafts propose a solution where there are two sets of encryption keys, one for the end-to-end (e2e) session and another for the transport connection (i.e. between the endpoint and MDD). SRTP extensions are required to carry the e2e encrypted data. The concept of a key management function (KMF) is also introduced which receives information about the call and the endpoints (as per 8.1/<xref target="I-D.jones-perc-private-media-framework"/> ). The KMF is the element that the endpoints trust it provides cryptographic keys and authenticates media content. See 6.1 / <xref target="I-D.jones-perc-private-media-reqts"/>.</t>
<t>So far only SRTP media has been considered by PERC. As the MDD does not have access to the un-encrypted media stream it can only provide switching topologies (e.g. Media Switch, Selective Forwarding Unit, Transport Translator/ Transport Relay?, <xref target="I-D.ietf-avtcore-rtp-topologies-update"/>).</t>
<t>These aspects have some implications on the use of CLUE.</t>
<section title="Topology">
<t>As noted in the background section the selection of particular captures and encodings by endpoints effectively dictates what topology occurs at the MCU/MDD. Therefore where a CLUE enabled MDD receives an indication that an encoding requires the use of PERC, the MDD must ensure that in any subsequent ADVERTISEMENTs and SIP/SDP offers it sends, that the capture encoding is an unmixed local source (i.e. doesn't use a MCC indicating a MDD local composition of remote sources). This would be a mismatch in capabilities as the MDD is unable to mix SRTP streams.</t>
<t>Whilst the MDD may utilise the MCC mechanism to indicate that a particular capture encoding may represent multiple sources, the MaxCaptures attribute (section 7.2.1.1/<xref target="I-D.ietf-clue-framework"/>) should be set to <=1 or 1 to indicate that only switching is used. Other MaxCapture values indicate the potential use of composed (thus mixed) capture encodings.</t>
<t>A MCC Policy attribute (section 7.2.1.2/<xref target="I-D.ietf-clue-framework"/>) may also be included. It allows the indication of a "SoundLevel" policy that indicates that the content of the capture encoding is determined by a sound level detection algorithm. As a PERC enabled MDD cannot access the SRTP media the "SoundLevel" policy should not be used unless the endpoint indicates the use of an unencrypted or hop by hop mechanism (e.g. utilising <xref target="RFC6464"/>) for sound level detection.</t>
</section>
<section title="Media manipulation">
<t>Given that the PERC enabled MDD cannot access the encrypted media, it cannot filter possible media content. For example an endpoint may indicate that the media capture contains embedded text (clause 7.1.1.13/<xref target="I-D.ietf-clue-framework"/>) information. It has no mechanism to filter out (e.g. by removing part of the image, or text signaled associated with audio) or to confirm text is being sent. Therefore the MDD can either only remove the capture from being ADVERTISED or pass the embedded text attribute without modification.</t>
<t>A CLUE enabled MDD has the ability of adding its own captures and encodings to ADVERTISEMENTS. PERC enabled consumers should determine if the encoding associated with the advertised captures contains the correct key/fingerprint information as distributed by the KMF before requesting the capture encoding via a CONFIGURE. This is a similar consideration as for non-CLUE endpoint responding with an SDP Answer.</t>
</section>
<section title="Privacy">
<t>The CLUE framework allows the sending of potentially private information to the MCU. Participant and endpoint information via the xCard <xref target="RFC6351"/> format may be provided. xCard can contain address, contact, company, images and audio information. Whilst this information does not compromise the encrypted media it does provide information about the persons generating it. </t>
<t>CLUE also allows the definition of extensions so there may be proprietory extensions that may also contain potentially senstive information.</t>
<t>As indicated in the PERC WG charter meta information provided to the central device is to be limited to the minimal required for the MDD to perform its function. This may potentially result in an CLUE endpoint significantly reducing the amount of metadata it sends in ADVERTISEMENTS. This would result in decreased information for CONSUMERs to decide which captures to consumer. This may lead to a decreased telepresence user experience.</t>
</section>
<section title="Encodings">
<t>CLUE itself carries little encoding information other than encoding groups with indicate which encodings are linked (and the maxmimum bit rate) and encodingIDs of the individual encodings. The encodingIDs provide a link to the actual encoding information provided through SIP/SDP. The SDP utilizes the "a=group" and "a=mid" mechanism to reference the CLUE encodingIDs thus providing a linkage between CLUE and SDP.</t>
<t>It is expected that any indication of the use of PERC for SRTP streams will be signaled through SDP. Therefore a CLUE enabled endpoint is not required to change any CLUE based encoding information to use PERC.</t>
</section>
<section title="Mapping RTP streams to CLUE media captures">
<t>In order to associate RTP media with a particular CLUE capture encoding <xref target="I-D.ietf-clue-rtp-mapping"/> defines a RTP header extension and a RTCP SDES item both containing a CaptureID. The draft indicates for mapping an RTP stream to a specific MC in the MCC the CLUE the media sender MUST send for MCC the captureID in the RTP header and as a RTCP SDES message.</t>
<t>If an MDD produces or modifies MCCs (in particular the individual source CaptureIDs) as per section 4.1 above, then it may need to potentially modify the received source RTP/RTCP captureIDs to match the CLUE MCC before sending RTP/RTCP. In the case of voice activated switching, the MDD should also send the relevant RTP/RTCP captureID.</t>
<t>Therefore any PERC solution should ensure that the MDD may have access to and the ability to send RTP/RTCP captureID.</t>
</section>
<section title="Others?">
<t>TBD</t>
</section>
</section>
<section title="Potential CLUE enhancements">
<t>CLUE has a defined extension mechanism (see section 8/[ID.ietf-clue-protocol]). The use of any enhancements related to PERC could be negotiated through this mechanism.</t>
<section title="Encrypted CLUE information">
<t>In order to limit the amount of metadata available to the MDD but still allowing the full use of CLUE, CLUE could be enhanced to carry encrypted data that is associated with a capture/scene but is not available to an MDD. This would be similar to the proposed solution for SRTP. The KMF could be enhanced to provide keys to the endpoints to access this CLUE encrypted data to make decisions on which capture encodings to CONFIGURE.</t>
<t>In a PERC environment the endpoints are responsible for stream selection and any composition and thus they should have access to the full capture and scene metadata provided by the other endpoints in a conference. A MDD that switches streams doesn't need access to this metadata as it should not make decisions regarding the forwarding of streams based on the content/characteristics of the stream. Accordingly the MDD only strictly needs a CaptureID and the encoding information in order to switch streams. CLUE capture attributes, capture scene, simultaneous set and people information may be encrypted and passed through the MDD. This is due to the fact that a CONFIGURE only contains a CaptureID and an associated EncodingID. It's the CONFIGURE message that determine which capture encoding an endpoint sends.</t>
<t>The syntax below in figure 3 provides a conceptual illustration of the clear and encrypted parts of a CLUE ADVERTISEMENT utilising the example from section 10.1 / [ID.ietf-clue-protocol]:</t>
<figure align="left" anchor="figure3" title="Encrypted CLUE Advertisement">
<preamble></preamble>
<artwork align="left"><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<advertisement xmlns="urn:ietf:params:xml:ns:clue-protocol"
xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
protocol="CLUE" v="0.4">
<clueId>Napoli</clueId>
<sequenceNr>45</sequenceNr>
<mediaCaptures>
<ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:videoCaptureType" captureID="AC0" mediaType="video">
<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
<ns2:encGroupIDREF>EG1</ns2:encGroupIDREF>
/**************** Encrypted contents **************/
<ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC0">
<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
<ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
/**************** Encrypted contents **************/
</ns2:mediaCapture>
<ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC1">
<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
<ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
/**************** Encrypted contents **************/
</ns2:mediaCapture>
<ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC3">
<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
<ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
/**************** Encrypted contents **************/
</ns2:mediaCapture>
<ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC4">
<ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
<ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
/**************** Encrypted contents **************/
</mediaCaptures>
<encodingGroups>
<ns2:encodingGroup encodingGroupID="EG0">
<ns2:maxGroupBandwidth>600000</ns2:maxGroupBandwidth>
<ns2:encodingIDList>
<ns2:encID>ENC1</ns2:encID>
<ns2:encID>ENC2</ns2:encID>
<ns2:encID>ENC3</ns2:encID>
</ns2:encodingIDList>
</ns2:encodingGroup>
<ns2:encodingGroup encodingGroupID="EG1">
<ns2:maxGroupBandwidth>300000</ns2:maxGroupBandwidth>
<ns2:encodingIDList>
<ns2:encID>ENC4</ns2:encID>
<ns2:encID>ENC5</ns2:encID>
</ns2:encodingIDList>
</ns2:encodingGroup>
</encodingGroups>
<captureScenes>
/**************** Encrypted contents **************/
</captureScenes>
<simultaneousSets>
/**************** Encrypted contents **************/
</simultaneousSets>
<people>
/**************** Encrypted contents **************/
</people>
</advertisement>
]]></artwork>
</figure>
<t>The downside of this approach is that the MDD effectively becomes unable to offer its own switched streams as multiple content captures. Whilst in theory it could offer its own MCCs utilising the unencrypted CaptureIDs, it has little metadata to decide which streams are related in order to provide synchronised switching. Therefore it could be recommended that information such as the capture area (which is unlikely to be sensitive) should be passed in the clear (unencrypted) to allow the MDD to distinguish that the captures cover different parts of the same scene. In this case the MDD could provide a MCC.</t>
</section>
<section title="Others?">
<t>TBD</t>
</section>
</section>
<section title="Summary">
<t>This draft provides a discussion of the relationship between CLUE and PERC and the potential impacts to CLUE when used with PERC streams.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>None.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This draft is about the privacy and security implications of using CLUE in a PERC environment.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include="reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include="reference.RFC.6351.xml"?>
<?rfc include="reference.RFC.6464.xml"?>
<?rfc include="reference.I-D.ietf-clue-framework.xml"?>
<?rfc include="reference.I-D.ietf-clue-datachannel.xml"?>
<?rfc include="reference.I-D.jones-perc-private-media-framework.xml"?>
<?rfc include="reference.I-D.jones-perc-private-media-reqts.xml"?>
<?rfc include="reference.I-D.ietf-avtcore-rtp-topologies-update.xml"?>
<?rfc include="reference.I-D.ietf-clue-rtp-mapping.xml"?>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems).
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date to
year only, to be consistent with the comments. Updated the
IANA guidelines reference from the I-D to the finished RFC. -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:47:58 |