One document matched: draft-groves-clue-partial-update-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">
-->
<?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-clue-partial-update-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="CLUE Partial Updates">CLUE Partial Updates</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="2014" />
<!-- 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>Real-time Applications and Infrastructure Area</area>
<workgroup>CLUE</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 proposes a method for using partial updates in CLUE Advertisements to update the CLUE data model. It uses the XML patch operations defined in <xref target="RFC5261" /></t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As commonly recognised, a large conference using CLUE with many participants and captures will result in large CLUE Advertisement messages. Participants may come and go in conferences which require updates to the CLUE information. Sending large CLUE messages to remove a single capture or scene results in unnecessary bandwidth and processing to compare the existing CLUE description with the updated description. It has been recognised that a method that allows partial updates to the CLUE description is desirable.</t>
<t>This document describes procedures for Partial CLUE Advertisements. It does not consider CLUE Configure messages as these are significantly smaller than Advertisement messages.</t>
<t>This document defines a "full Advertisement" as one that does not use the partial advertisement
syntax and represents a complete description of a Media Provider's media sending capabilities at that point in time. A "partial Advertisement" is one that uses the syntax defined in this document to represent a sub-set of the complete description.</t>
<t>As noted in clause 4.3/ <xref target="I-D.ietf-clue-protocol" />, an approach using a "delta" mechanism for advertising changes is suggested. It proposed to leverage the mechanism defined in <xref target="RFC5261" />. It effectively defines an API for manipulating XML nodes (see clause 6/[http://www.w3.org/TR/xpath-datamodel/#Node]) in an XML document. It utilises XPATH to identify the XML nodes. A basic tutorial on XPATH can be found at:
http://www.w3schools.com/XPath/default.asp</t>
<t>The procedures are based around the use of XPATH path expressions (see: clause 3.2/[ http://www.w3.org/TR/xpath20/]) to identify a node/s in a CLUE XML document. Several operations are defined that can be used on those nodes. The "add" operation allows the insertion of new XML elements and attributes to the existing XML nodes. The "replace" operation allows the modification of existing XML nodes. The "remove" operation allows the removal of existing XML nodes.</t>
<t>This document is based on updates to version 5 of the CLUE Data Model Schema <xref target="I-D.ietf-clue-data-model-schema" />.</t>
<t>The following functions are defined:
<list hangIndent="4" style="symbols">
<t>Addition: An add operation issued with new elements has the effect of adding the new elements to the CLUEinfo description.</t>
<t>Replacement: A replacement operation modifies existing element/s with the value/s provided. This may be used to replace child elements without requiring separate add and remove operations.</t>
<t>Removal: A removal operation issued on an element has the effect of deleting that element and any child elements from the CLUEinfo description.</t>
</list></t>
<t>Partial updates are implemented using the existing CLUE Advertisement (ADV) message. The difference being that the ADV message for partial updates will not contain a full clue-info description containing all the relevant media provider information but will instead contain a partial update syntax. A Re-Advertisement request (READV/ACK) will result in the media provider's full clue-info being sent. Thus no changes to the protocol message state model are envisaged.</t>
<t>This document does not perform a numerical analysis on how many bytes will be saved using an Advertisement with a partial update versus a full Advertisement. The amount of bytes saved will be dependent on the desired operation. The examples in this document show potential partial updates against the examples in <xref target="I-D.ietf-clue-data-model-schema" />. The basic example in the data model draft is ~6300 characters. It can be seen that the size of the partial updates is considerably less than a full CLUE info description.</t>
<t>This document also does not perform an analysis nor give guidelines on how a media provider would determine when to send a partial update versus a full update. It is assumed that the media provider provides an initial full clue-info description and that any subsequent Advertisements contain partial updates. A media provider MAY provide a full Advertisement at any time.</t>
<t>Furthermore this document does not describe how the media provider determines the "diff" between an old Advertisement and a new one. This functionality is internal to the media provider.</t>
</section>
<section title="Partial Notification Format">
<t>The format of the partial updates in based on the XML scheme "patch-ops" defined in <xref target="RFC5261" />. The partial update XML is defined in a new element "clue-info-diff".</t>
<t>The content of the <clue-info-diff> element is an unordered sequence of <add>, <replace>, and <remove> elements followed by elements from other namespaces for the purposes of extensibility. Any such unknown elements MUST be ignored by the client. The <add>, <replace>, and <remove> elements can contain other extension attributes than what are defined in the corresponding base types of <xref target="RFC6502" />.</t>
<t>Author's Note: The introduction of the possibility for extension is consistent with <xref target="RFC6502" />. This aspect may be removed to simplify the implementation.</t>
<t>The elements may appear any number of times and in any order in <clue-info-diff>. However the partial update MUST contain at least one <add>, <replace> or <remove> element. Any changes are with respect to the base CLUEinfo description. The "base" CLUEinfo description is the result of a previously sent Advertisement with a full CLUEinfo description and any subsequently sent partial updates. Then sending of a full CLUEinfo description will have the effect of resetting the "base" CLUEinfo description.</t>
<t>It is not possible for one operation (add/replace/remove) to affect another element in the same clue-info-diff. E.g. an operation may not use an XPATH to reference a previous operation in a clue-info-diff. However attribute values may be referenced across operations. E.g. a Capture Scene ID may be used to add a capture scene and also used in a media capture to reference the scene.</t>
<t>If the XPATH cannot be resolved to a single node by the receiver an error response should be generated.</t>
<t>Author's Note: XPATH allows quite advanced methods of identifying XML nodes. To simplify implementations it may be advantageous to limit the selector values for specifying nodes. E.g. nodes must be fully specified by name rather than using wildcarding.</t>
</section>
<section title="XML Schema for Partial Negotiations">
<t>This is the XML proposed for inclusion into the CLUE protocol. It includes the schema for XML patching from [RFC5261] (using [RFC6205] as the basis for the syntax) and defines the add, remove and replacement operations. It is used in CLUE Advertisement messages.</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
<!-- include patch-ops type definitions -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- partial updates -->
<xs:element name="clue-info-diff">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<!-- add some content -->
<xs:element name="add">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="add">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- remove some content -->
<xs:element name="remove">
<xs:complexType>
<xs:complexContent>
<xs:extension base="remove">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- replace some content -->
<xs:element name="replace">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="replace">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- allow extension elements from other namespaces -->
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
</xs:element>
</xs:schema>
]]></artwork>
</figure>
<t>The XML below is also proposed for inclusion into the CLUE protocol. It includes the schema for XML patch operation errors from [RFC5261]. It is used in CLUE Advertisement ACK messages.</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
<!-- include patch-ops-error type definitions -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops-error"/>
<!-- partial updates errors -->
<xs:element name="clue-info-diff-error">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<!-- add some content -->
<xs:element name="patch-ops-error">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="patch-ops-error">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
</xs:element>
</xs:schema>
]]></artwork>
</figure>
</section>
<section title="Operations">
<section title="<add> Element">
<t>The use of the <add> element is as per section 4.3/<xref target="RFC5261" /> with the exception that the addition of attributes and namespaces is not supported. Thus the 'type' attribute is not supported.</t>
<t>Author's Note: Given the nature of the CLUE XML there doesn't seem to be a use case to update namespaces or attributes.</t>
<t>When inserting elements, the new nodes are described as they should appear in the CLUEinfo document with respect to the "sel" and any "pos" attribute.</t>
</section>
<section title="<replace> Element">
<t>The use of the <replace> element is as per section 4.4/<xref target="RFC5261" />.</t>
<t>When modifying elements the modified nodes must be specified as they should appear info the CLUE info document. The content-to-modify must include the element referenced by the xpath and any child elements. It will have the effect of completely replacing the previous setting of the element. Any child element present in the base document will be removed if not present in the content-to-modify. Any child element, not present in the base document but present in the content-to-modify will be added. XML attributes follow the same behaviour.</t>
</section>
<section title="<remove> Element">
<t>The use of the <remove> element is as per section 4.5/<xref target="RFC5261" />.</t>
</section>
</section>
<section title="Error Handling">
<t>When parsing an Advertisement containing a partial update, the Media Consumer may detect an error in the partial update or may not be able to unambiguously apply the update. This may result in an error. In order to support error handling the <patch-ops-error> element should be included in the Advertisement Acknowledgement message.</t>
</section>
<section title="Procedures">
<t>This section describes the rules associated with partial updates to a CLUE Advertisement. Due to the structure of the CLUE data model there are dependencies between the different elements in the CLUE info document. These procedures are from a syntactic perspective and cover interactions between CLUEinfo elements. Various combinations of operations may or may not make sense from an application perspective, however the application perspective is out of scope of these procedures.</t>
<t>Firstly general rules are described that apply to all elements in the CLUEInfo. Procedures specific to the following top level elements are then described:
<list hangIndent="4" style="symbols">
<t>mediaCaptures</t>
<t>encodingGroups</t>
<t>captureScenes</t>
<t>simultaneousSets</t>
<t>globalSceneEntries</t>
<t>people</t>
</list>
</t>
<section title="General">
<section title="Addition">
<t>When adding a new element, any mandatory child elements must be included. For example: when adding a new media capture the <capturedMedia>, <captureSceneIDREF> and <encGroupIDREF> elements must be included in the partial update.</t>
</section>
<section title="Replacement">
<t>See the specific procedures for replacement in the clauses below.</t>
</section>
<section title="Removal">
<t>The deletion of an element will have the effect of deleting all child elements.</t>
</section>
</section>
<section title="Capture Scene <captureScenes>">
<section title="Addition">
<t>A partial update may add additional <captureScene> elements to the <captureScenes> element. Additional <sceneEntry> elements may be added to the <sceneEntries> element. Additional media captures (<captureIDREF>) may be added to the <sceneEntry> element.
</t>
</section>
<section title="Replacement">
<t>A partial update may modify the child elements of the <captureSceneType>. If the <sceneID> element is changed then any elements that reference the sceneID (e.g. by captureSceneIDREF in <mediaCaptureType> element) must also be changed in the partial update.</t>
</section>
<section title="Removal">
<t>A partial update may remove a capture scene from an existing CLUEInfo description. If the sceneID of the deleted capture scene is used in other elements (e.g. by captureSceneIDREF in <mediaCaptureType>) then these elements must either be removed or the captureSceneIDRef must be changed to another existing capture scene identity in the partial update.</t>
<t>A partial update may delete a <sceneEntry> element. If the sceneEntryID is used in other elements (e.g. by sceneEntryIDREF in <globalCaptureEntryType> and <simultaneousSetType> then these elements must either be requested to be removed or the sceneEntryIDREF must be changed to another existing capture scene entry identity in the partial update.</t>
</section>
</section>
<section title="Media Captures <mediaCaptures>">
<section title="Addition">
<t>A partial update may add additional captures may by specifying additional <mediaCaptureType> structures. The partial update must include the mandatory elements of the structure. Therefore the <captureSceneIDREF> elements must reference existing Capture Scenes or reference Capture Scenes being added in the partial update.</t>
<t>The addition of a new media capture may also require that the captureID is added to elements that reference media captures. For example: captureIDREF in the <contentType> (for multiple content captures), mediaCaptureIDs in the <sceneEntryType> element, captureIDREF in the <simultaneousSetType> element and IDREF in the <relatedTo> element. The addition of a mediaCapture may also result in a new <sceneEntry> element (see clause 3.2.1) and possibily an update of the <globalCaptureEntries> element being needed in the partial update.</t>
<t>If the new media capture contains a <capturedPeople> element containing <personIDREF> elements, the referenced <personID> must also be added to the <people> element if it has previously not been included.</t>
<t>Additional capture attributes may be added to existing media captures.</t>
</section>
<section title="Replacement">
<t>A partial update may modify the child elements of the <mediaCaptureType>. If the <captureID> element is changed then any elements that reference the captureID (e.g. by captureIDREF) must also be changed in the partial update.</t>
<t>If the partial update modifies the <capturedPeople> element then the <people> element may need to be updated. See clauses 6.3.1 and 6.3.3.</t>
</section>
<section title="Removal">
<t>A partial update may remove a <mediaCapture> element. The captureID of the removed mediaCapture must also be removed from any elements that reference the captureID in the partial update. For example: captureIDREF in the <contentType> (for multiple content captures), mediaCaptureIDs in the <sceneEntryType> element, captureIDREF in the <simultaneousSetType> element and IDREF in the <relatedTo> element.</t>
<t>If the removed media capture contains a <capturedPeople> element containing <personIDREF> elements and the referenced <personID>s are not referenced by any other media capture, the referenced persons may removed from the <people> element.</t>
</section>
</section>
<section title="Encoding Groups <encodingGroups>">
<section title="Addition">
<t>An <encodingGroup> element may be added to without requiring modification to other top level elements. However if the encoding group is to be used by media captures, the encGroupIDREF of the added encoding group must be added to at least one media capture. Child elements of <encodingGroup> may be added without impact to other top level elements.</t>
<t>Note: The change of an encID may result an SDP Offer/Answer exchange modifying an encoding.</t>
</section>
<section title="Replacement">
<t>If the <encodingGroupID> attribute is modified then any media captures that reference the encodingGroupID (through the encGroupIDREF) must also be modified.</t>
<t>Note: The change of an encID may result an SDP Offer/Answer exchange modifying an encoding.</t>
</section>
<section title="Removal">
<t>If an encodingGroup element is removed any media captures that reference the removed encodingGroup (through the encGroupIDREF element) must be modified to reference a new encoding group ID or the encoding group must be removed in the partial update.</t>
<t>Note: The removal of an encID may result an SDP Offer/Answer exchange removing an encoding.</t>
</section>
</section>
<section title="Simultaneous Sets <simultaneousSets>">
<t>Operations (Add, Replace, Remove) may be applied the <simultaneousSets> element without any impacts on other top level elements. Any referenced media captures or capture scene entries must exist.</t>
</section>
<section title="Global Scene Entries <globalSceneEntries>">
<t>Operations (Add, Replace, Remove) may be applied the <globalSceneEntries> element without any impacts on other top level elements. Any referenced capture scene entries must exist.</t>
</section>
<section title="People <people>">
<section title="Addition">
<t>A new <people> element may be added without affecting other top level elements. However for the new element to be used by the receiver of the CLUE description the <personID> of the people defined in that element must be referenced by one or more media captures or capture scenes.</t>
</section>
<section title="Replacement">
<t>If the <personID> element is modified then any media captures that reference the participant (through the <capturedPeople> element) must also be modified.</t>
</section>
<section title="Removal">
<t>If a <person> element or any instances of the <personType> element are removed then any media captures that reference the removed people (through the <capturedPeople> element) must be modified to remove the personID in question.</t>
</section>
</section>
</section>
<section title="Examples">
<t>The following examples are based on partial updates to the sample XML file in clause 22/<xref target="I-D.ietf-clue-data-model-schema" />. The changes are against the sample XML file. The changes are not cumulative across the examples.</t>
<section title="Additional Presentation Capture ">
<t>A presentation video capture (VC5) is added to the conference for a document camera. As this doesn't share a co-ordinate space a new Capture scene (CS2) is added. The clue-info-diff indicates to add the new capture after media capture VC4. An existing encoding group is used. The new capture is also added to the simultaneous sets SS1 and SS2 as it may be used in conjunction with the other captures. The following shows the additions:</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
<clue-info-diff xmlns="urn:ietf:params:xml:ns:clue-info">
<add sel="clueInfo/captureScenes/captureScene[1]" pos="after">
<captureScene scale="unknown" sceneID="CS2">
<sceneEntries>
<sceneEntry mediaType="video" sceneEntryID="SE5">
<mediaCaptureIDs>
<captureIDREF>VC5</captureIDREF>
</mediaCaptureIDs>
</sceneEntry>
</sceneEntries>
</captureScene>
</add>
<add sel="clueInfo/simultaneousSets/simultaneousSet[1]/captureIDREF[1]"
pos="after">
<captureIDREF>VC5</captureIDREF>
</add>
<add sel="clueInfo/simultaneousSets/simultaneousSet[2]/captureIDREF[4]"
pos="after">
<captureIDREF>VC5</captureIDREF>
</add>
<add sel="clueInfo/mediaCaptures/mediaCapture[6]" pos="after">
<mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="videoCaptureType" captureID="VC5">
<capturedMedia>video</capturedMedia>
<captureSceneIDREF>CS2</captureSceneIDREF>
<encGroupIDREF>EG0</encGroupIDREF>
<individual>true</individual>
<description lang="en">document camera</description>
<presentation>image</presentation>
</mediaCapture>
</add>
</clue-info-diff>
]]></artwork>
</figure>
</section>
<section title="Capture Removal">
<t>The video captures VC3 and VC4 are no longer available. As a result the following must be removed from the CLUE information:
<list hangIndent="4" style="symbols">
<t>mediaCaptures for VC3 and VC4</t>
<t>sceneEntries for SE2 and SE3 as they only contain VC3 and VC4</t>
<t>capture identities for VC3 and VC4 from the simultaneousSets</t>
</list></t>
<t>The following shows the partial update with the removal:</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
<clue-info-diff xmlns="urn:ietf:params:xml:ns:clue-info">
<remove sel="clueInfo/mediaCaptures/mediaCapture[5]">
<remove sel="clueInfo/mediaCaptures/mediaCapture[6]">
<remove sel="clueInfo/captureScene/sceneEntries/sceneEntry[2]">
<remove sel="clueInfo/captureScene/sceneEntries/sceneEntry[3]">
<remove
sel="clueInfo/simultaneousSets/simultaneousSet[1]/captureIDREF[1]">
<remove
sel= "clueInfo/simultaneousSets/simultaneousSet[2]/captureIDREF[3]">
<remove
sel="clueInfo/simultaneousSets/simultaneousSet[2]/captureIDREF[4]">
</clue-info-diff>
]]></artwork>
</figure>
</section>
<section title="Attribute Modification">
<t>The video capture VC4 zooms in on a particular participant and no longer represents a zoomed out view. As a result the description of VC4 and the participants are changed.</t>
<t>The following shows the partial update with the change:</t>
<figure align="left" title="">
<artwork align="left"><![CDATA[
<clue-info-diff xmlns="urn:ietf:params:xml:ns:clue-info">
<replace sel="clueInfo/mediaCaptures/mediaCapture[6]/description">
<description lang="en">zoomed in view on ciccio</description>
</replace>
<replace sel= "clueInfo/mediaCaptures/mediaCapture[6]/capturedPeople">
<capturedPeople>
<personIDREF>ciccio</participantIDREF>
</capturedPeople>
</replace>
</clue-info-diff>
]]></artwork>
</figure>
</section>
</section>
<section title="Summary">
<t>The authors believe that the use of partial updates is an efficient way of updating CLUE information minimising the amount of data that needs to be sent in an Advertisement. It is proposed to introduce partial Advertisements into the CLUE protocol.</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>It is not expected that the proposed changes present the need for any IANA registrations.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>It is not expected that the proposed changes present any addition security issues to the current framework.</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"?>
<?rfc include="reference.RFC.5261.xml"?>
<?rfc include="reference.RFC.6502.xml"?>
<?rfc include="reference.I-D.ietf-clue-data-model-schema.xml"?>
<?rfc include="reference.I-D.ietf-clue-protocol.xml"?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include="reference.RFC.2629.xml"?>
<!-- <reference anchor="I-D.ietf-clue-framework">
<front>
<title>Framework for Telepresence Multi-Streams</title>
<author initials="A" surname="Romanow">
<organization></organization>
</author>
<author initials="M" surname="Duckworth">
<organization></organization>
</author>
<author initials="A" surname="Pepperell">
<organization></organization>
</author>
<author initials="B" surname="Baldino">
<organization></organization>
</author>
<date year="draft-ietf-clue-framework-09 (work in progress)" />
</front>
</reference> -->
</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:45:01 |