idnits 2.17.1 draft-groves-clue-partial-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 15, 2014) is 3504 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6205' is mentioned on line 222, but not defined == Unused Reference: 'RFC2119' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 687, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-clue-data-model-schema-06 == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE C. Groves, Ed. 3 Internet-Draft W. Yang 4 Intended status: Informational R. Even 5 Expires: March 19, 2015 Huawei 6 September 15, 2014 8 CLUE Partial Updates 9 draft-groves-clue-partial-update-00 11 Abstract 13 This document proposes a method for using partial updates in CLUE 14 Advertisements to update the CLUE data model. It uses the XML patch 15 operations defined in [RFC5261] 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 19, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Partial Notification Format . . . . . . . . . . . . . . . . . 4 53 3. XML Schema for Partial Negotiations . . . . . . . . . . . . . 5 54 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4.1. Element . . . . . . . . . . . . . . . . . . . . . . 7 56 4.2. Element . . . . . . . . . . . . . . . . . . . . 7 57 4.3. Element . . . . . . . . . . . . . . . . . . . . 8 58 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 8 59 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6.1.1. Addition . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1.2. Replacement . . . . . . . . . . . . . . . . . . . . . 9 63 6.1.3. Removal . . . . . . . . . . . . . . . . . . . . . . . 9 64 6.2. Capture Scene . . . . . . . . . . . . . . 9 65 6.2.1. Addition . . . . . . . . . . . . . . . . . . . . . . 9 66 6.2.2. Replacement . . . . . . . . . . . . . . . . . . . . . 9 67 6.2.3. Removal . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.3. Media Captures . . . . . . . . . . . . . 10 69 6.3.1. Addition . . . . . . . . . . . . . . . . . . . . . . 10 70 6.3.2. Replacement . . . . . . . . . . . . . . . . . . . . . 10 71 6.3.3. Removal . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.4. Encoding Groups . . . . . . . . . . . . 11 73 6.4.1. Addition . . . . . . . . . . . . . . . . . . . . . . 11 74 6.4.2. Replacement . . . . . . . . . . . . . . . . . . . . . 11 75 6.4.3. Removal . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.5. Simultaneous Sets . . . . . . . . . . 11 77 6.6. Global Scene Entries . . . . . . . . 12 78 6.7. People . . . . . . . . . . . . . . . . . . . . . 12 79 6.7.1. Addition . . . . . . . . . . . . . . . . . . . . . . 12 80 6.7.2. Replacement . . . . . . . . . . . . . . . . . . . . . 12 81 6.7.3. Removal . . . . . . . . . . . . . . . . . . . . . . . 12 82 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.1. Additional Presentation Capture . . . . . . . . . . . . . 12 84 7.2. Capture Removal . . . . . . . . . . . . . . . . . . . . . 13 85 7.3. Attribute Modification . . . . . . . . . . . . . . . . . 14 86 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 12.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 As commonly recognised, a large conference using CLUE with many 98 participants and captures will result in large CLUE Advertisement 99 messages. Participants may come and go in conferences which require 100 updates to the CLUE information. Sending large CLUE messages to 101 remove a single capture or scene results in unnecessary bandwidth and 102 processing to compare the existing CLUE description with the updated 103 description. It has been recognised that a method that allows 104 partial updates to the CLUE description is desirable. 106 This document describes procedures for Partial CLUE Advertisements. 107 It does not consider CLUE Configure messages as these are 108 significantly smaller than Advertisement messages. 110 This document defines a "full Advertisement" as one that does not use 111 the partial advertisement syntax and represents a complete 112 description of a Media Provider's media sending capabilities at that 113 point in time. A "partial Advertisement" is one that uses the syntax 114 defined in this document to represent a sub-set of the complete 115 description. 117 As noted in clause 4.3/ [I-D.ietf-clue-protocol], an approach using a 118 "delta" mechanism for advertising changes is suggested. It proposed 119 to leverage the mechanism defined in [RFC5261]. It effectively 120 defines an API for manipulating XML nodes (see clause 121 6/[http://www.w3.org/TR/xpath-datamodel/#Node]) in an XML document. 122 It utilises XPATH to identify the XML nodes. A basic tutorial on 123 XPATH can be found at: http://www.w3schools.com/XPath/default.asp 125 The procedures are based around the use of XPATH path expressions 126 (see: clause 3.2/[ http://www.w3.org/TR/xpath20/]) to identify a 127 node/s in a CLUE XML document. Several operations are defined that 128 can be used on those nodes. The "add" operation allows the insertion 129 of new XML elements and attributes to the existing XML nodes. The 130 "replace" operation allows the modification of existing XML nodes. 131 The "remove" operation allows the removal of existing XML nodes. 133 This document is based on updates to version 5 of the CLUE Data Model 134 Schema [I-D.ietf-clue-data-model-schema]. 136 The following functions are defined: 138 o Addition: An add operation issued with new elements has the effect 139 of adding the new elements to the CLUEinfo description. 141 o Replacement: A replacement operation modifies existing element/s 142 with the value/s provided. This may be used to replace child 143 elements without requiring separate add and remove operations. 145 o Removal: A removal operation issued on an element has the effect 146 of deleting that element and any child elements from the CLUEinfo 147 description. 149 Partial updates are implemented using the existing CLUE Advertisement 150 (ADV) message. The difference being that the ADV message for partial 151 updates will not contain a full clue-info description containing all 152 the relevant media provider information but will instead contain a 153 partial update syntax. A Re-Advertisement request (READV/ACK) will 154 result in the media provider's full clue-info being sent. Thus no 155 changes to the protocol message state model are envisaged. 157 This document does not perform a numerical analysis on how many bytes 158 will be saved using an Advertisement with a partial update versus a 159 full Advertisement. The amount of bytes saved will be dependent on 160 the desired operation. The examples in this document show potential 161 partial updates against the examples in 162 [I-D.ietf-clue-data-model-schema]. The basic example in the data 163 model draft is ~6300 characters. It can be seen that the size of the 164 partial updates is considerably less than a full CLUE info 165 description. 167 This document also does not perform an analysis nor give guidelines 168 on how a media provider would determine when to send a partial update 169 versus a full update. It is assumed that the media provider provides 170 an initial full clue-info description and that any subsequent 171 Advertisements contain partial updates. A media provider MAY provide 172 a full Advertisement at any time. 174 Furthermore this document does not describe how the media provider 175 determines the "diff" between an old Advertisement and a new one. 176 This functionality is internal to the media provider. 178 2. Partial Notification Format 180 The format of the partial updates in based on the XML scheme "patch- 181 ops" defined in [RFC5261]. The partial update XML is defined in a 182 new element "clue-info-diff". 184 The content of the element is an unordered sequence 185 of , , and elements followed by elements from 186 other namespaces for the purposes of extensibility. Any such unknown 187 elements MUST be ignored by the client. The , , and 188 elements can contain other extension attributes than what 189 are defined in the corresponding base types of [RFC6502]. 191 Author's Note: The introduction of the possibility for extension is 192 consistent with [RFC6502]. This aspect may be removed to simplify 193 the implementation. 195 The elements may appear any number of times and in any order in 196 . However the partial update MUST contain at least 197 one , or element. Any changes are with 198 respect to the base CLUEinfo description. The "base" CLUEinfo 199 description is the result of a previously sent Advertisement with a 200 full CLUEinfo description and any subsequently sent partial updates. 201 Then sending of a full CLUEinfo description will have the effect of 202 resetting the "base" CLUEinfo description. 204 It is not possible for one operation (add/replace/remove) to affect 205 another element in the same clue-info-diff. E.g. an operation may 206 not use an XPATH to reference a previous operation in a clue-info- 207 diff. However attribute values may be referenced across operations. 208 E.g. a Capture Scene ID may be used to add a capture scene and also 209 used in a media capture to reference the scene. 211 If the XPATH cannot be resolved to a single node by the receiver an 212 error response should be generated. 214 Author's Note: XPATH allows quite advanced methods of identifying XML 215 nodes. To simplify implementations it may be advantageous to limit 216 the selector values for specifying nodes. E.g. nodes must be fully 217 specified by name rather than using wildcarding. 219 3. XML Schema for Partial Negotiations 221 This is the XML proposed for inclusion into the CLUE protocol. It 222 includes the schema for XML patching from [RFC5261] (using [RFC6205] 223 as the basis for the syntax) and defines the add, remove and 224 replacement operations. It is used in CLUE Advertisement messages. 226 227 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 274 The XML below is also proposed for inclusion into the CLUE protocol. 275 It includes the schema for XML patch operation errors from [RFC5261]. 276 It is used in CLUE Advertisement ACK messages. 278 279 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 302 4. Operations 304 4.1. Element 306 The use of the element is as per section 4.3/[RFC5261] with the 307 exception that the addition of attributes and namespaces is not 308 supported. Thus the 'type' attribute is not supported. 310 Author's Note: Given the nature of the CLUE XML there doesn't seem to 311 be a use case to update namespaces or attributes. 313 When inserting elements, the new nodes are described as they should 314 appear in the CLUEinfo document with respect to the "sel" and any 315 "pos" attribute. 317 4.2. Element 319 The use of the element is as per section 4.4/[RFC5261]. 321 When modifying elements the modified nodes must be specified as they 322 should appear info the CLUE info document. The content-to-modify 323 must include the element referenced by the xpath and any child 324 elements. It will have the effect of completely replacing the 325 previous setting of the element. Any child element present in the 326 base document will be removed if not present in the content-to- 327 modify. Any child element, not present in the base document but 328 present in the content-to-modify will be added. XML attributes 329 follow the same behaviour. 331 4.3. Element 333 The use of the element is as per section 4.5/[RFC5261]. 335 5. Error Handling 337 When parsing an Advertisement containing a partial update, the Media 338 Consumer may detect an error in the partial update or may not be able 339 to unambiguously apply the update. This may result in an error. In 340 order to support error handling the element should 341 be included in the Advertisement Acknowledgement message. 343 6. Procedures 345 This section describes the rules associated with partial updates to a 346 CLUE Advertisement. Due to the structure of the CLUE data model 347 there are dependencies between the different elements in the CLUE 348 info document. These procedures are from a syntactic perspective and 349 cover interactions between CLUEinfo elements. Various combinations 350 of operations may or may not make sense from an application 351 perspective, however the application perspective is out of scope of 352 these procedures. 354 Firstly general rules are described that apply to all elements in the 355 CLUEInfo. Procedures specific to the following top level elements 356 are then described: 358 o mediaCaptures 360 o encodingGroups 362 o captureScenes 364 o simultaneousSets 366 o globalSceneEntries 368 o people 370 6.1. General 372 6.1.1. Addition 374 When adding a new element, any mandatory child elements must be 375 included. For example: when adding a new media capture the 376 , and elements 377 must be included in the partial update. 379 6.1.2. Replacement 381 See the specific procedures for replacement in the clauses below. 383 6.1.3. Removal 385 The deletion of an element will have the effect of deleting all child 386 elements. 388 6.2. Capture Scene 390 6.2.1. Addition 392 A partial update may add additional elements to the 393 element. Additional elements may be 394 added to the element. Additional media captures 395 () may be added to the element. 397 6.2.2. Replacement 399 A partial update may modify the child elements of the 400 . If the element is changed then any 401 elements that reference the sceneID (e.g. by captureSceneIDREF in 402 element) must also be changed in the partial 403 update. 405 6.2.3. Removal 407 A partial update may remove a capture scene from an existing CLUEInfo 408 description. If the sceneID of the deleted capture scene is used in 409 other elements (e.g. by captureSceneIDREF in ) 410 then these elements must either be removed or the captureSceneIDRef 411 must be changed to another existing capture scene identity in the 412 partial update. 414 A partial update may delete a element. If the 415 sceneEntryID is used in other elements (e.g. by sceneEntryIDREF in 416 and then these 417 elements must either be requested to be removed or the 418 sceneEntryIDREF must be changed to another existing capture scene 419 entry identity in the partial update. 421 6.3. Media Captures 423 6.3.1. Addition 425 A partial update may add additional captures may by specifying 426 additional structures. The partial update must 427 include the mandatory elements of the structure. Therefore the 428 elements must reference existing Capture Scenes 429 or reference Capture Scenes being added in the partial update. 431 The addition of a new media capture may also require that the 432 captureID is added to elements that reference media captures. For 433 example: captureIDREF in the (for multiple content 434 captures), mediaCaptureIDs in the element, 435 captureIDREF in the element and IDREF in the 436 element. The addition of a mediaCapture may also result 437 in a new element (see clause 3.2.1) and possibily an 438 update of the element being needed in the 439 partial update. 441 If the new media capture contains a element 442 containing elements, the referenced must 443 also be added to the element if it has previously not been 444 included. 446 Additional capture attributes may be added to existing media 447 captures. 449 6.3.2. Replacement 451 A partial update may modify the child elements of the 452 . If the element is changed then any 453 elements that reference the captureID (e.g. by captureIDREF) must 454 also be changed in the partial update. 456 If the partial update modifies the element then the 457 element may need to be updated. See clauses 6.3.1 and 458 6.3.3. 460 6.3.3. Removal 462 A partial update may remove a element. The captureID 463 of the removed mediaCapture must also be removed from any elements 464 that reference the captureID in the partial update. For example: 465 captureIDREF in the (for multiple content captures), 466 mediaCaptureIDs in the element, captureIDREF in the 467 element and IDREF in the element. 469 If the removed media capture contains a element 470 containing elements and the referenced s are 471 not referenced by any other media capture, the referenced persons may 472 removed from the element. 474 6.4. Encoding Groups 476 6.4.1. Addition 478 An element may be added to without requiring 479 modification to other top level elements. However if the encoding 480 group is to be used by media captures, the encGroupIDREF of the added 481 encoding group must be added to at least one media capture. Child 482 elements of may be added without impact to other top 483 level elements. 485 Note: The change of an encID may result an SDP Offer/Answer exchange 486 modifying an encoding. 488 6.4.2. Replacement 490 If the attribute is modified then any media 491 captures that reference the encodingGroupID (through the 492 encGroupIDREF) must also be modified. 494 Note: The change of an encID may result an SDP Offer/Answer exchange 495 modifying an encoding. 497 6.4.3. Removal 499 If an encodingGroup element is removed any media captures that 500 reference the removed encodingGroup (through the encGroupIDREF 501 element) must be modified to reference a new encoding group ID or the 502 encoding group must be removed in the partial update. 504 Note: The removal of an encID may result an SDP Offer/Answer exchange 505 removing an encoding. 507 6.5. Simultaneous Sets 509 Operations (Add, Replace, Remove) may be applied the 510 element without any impacts on other top level 511 elements. Any referenced media captures or capture scene entries 512 must exist. 514 6.6. Global Scene Entries 516 Operations (Add, Replace, Remove) may be applied the 517 element without any impacts on other top level 518 elements. Any referenced capture scene entries must exist. 520 6.7. People 522 6.7.1. Addition 524 A new element may be added without affecting other top level 525 elements. However for the new element to be used by the receiver of 526 the CLUE description the of the people defined in that 527 element must be referenced by one or more media captures or capture 528 scenes. 530 6.7.2. Replacement 532 If the element is modified then any media captures that 533 reference the participant (through the element) must 534 also be modified. 536 6.7.3. Removal 538 If a element or any instances of the element 539 are removed then any media captures that reference the removed people 540 (through the element) must be modified to remove the 541 personID in question. 543 7. Examples 545 The following examples are based on partial updates to the sample XML 546 file in clause 22/[I-D.ietf-clue-data-model-schema]. The changes are 547 against the sample XML file. The changes are not cumulative across 548 the examples. 550 7.1. Additional Presentation Capture 552 A presentation video capture (VC5) is added to the conference for a 553 document camera. As this doesn't share a co-ordinate space a new 554 Capture scene (CS2) is added. The clue-info-diff indicates to add 555 the new capture after media capture VC4. An existing encoding group 556 is used. The new capture is also added to the simultaneous sets SS1 557 and SS2 as it may be used in conjunction with the other captures. 558 The following shows the additions: 560 561 562 563 564 565 566 VC5 567 568 569 570 571 572 574 VC5 575 576 578 VC5 579 580 581 583 video 584 CS2 585 EG0 586 true 587 document camera 588 image 589 590 591 593 7.2. Capture Removal 595 The video captures VC3 and VC4 are no longer available. As a result 596 the following must be removed from the CLUE information: 598 o mediaCaptures for VC3 and VC4 600 o sceneEntries for SE2 and SE3 as they only contain VC3 and VC4 602 o capture identities for VC3 and VC4 from the simultaneousSets 604 The following shows the partial update with the removal: 606 607 608 609 610 611 613 615 617 619 7.3. Attribute Modification 621 The video capture VC4 zooms in on a particular participant and no 622 longer represents a zoomed out view. As a result the description of 623 VC4 and the participants are changed. 625 The following shows the partial update with the change: 627 628 629 zoomed in view on ciccio 630 631 632 633 ciccio 634 635 636 638 8. Summary 640 The authors believe that the use of partial updates is an efficient 641 way of updating CLUE information minimising the amount of data that 642 needs to be sent in an Advertisement. It is proposed to introduce 643 partial Advertisements into the CLUE protocol. 645 9. Acknowledgements 647 This template was derived from an initial version written by Pekka 648 Savola and contributed by him to the xml2rfc project. 650 10. IANA Considerations 652 It is not expected that the proposed changes present the need for any 653 IANA registrations. 655 11. Security Considerations 657 It is not expected that the proposed changes present any addition 658 security issues to the current framework. 660 12. References 662 12.1. Normative References 664 [I-D.ietf-clue-data-model-schema] 665 Presta, R. and S. Romano, "An XML Schema for the CLUE data 666 model", draft-ietf-clue-data-model-schema-06 (work in 667 progress), June 2014. 669 [I-D.ietf-clue-protocol] 670 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 671 clue-protocol-01 (work in progress), June 2014. 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch 677 Operations Framework Utilizing XML Path Language (XPath) 678 Selectors", RFC 5261, September 2008. 680 [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. 681 Urpalainen, "Conference Event Package Data Format 682 Extension for Centralized Conferencing (XCON)", RFC 6502, 683 March 2012. 685 12.2. Informative References 687 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 688 June 1999. 690 Authors' Addresses 692 Christian Groves (editor) 693 Huawei 694 Melbourne 695 Australia 697 Email: Christian.Groves@nteczone.com 698 Weiwei Yang 699 Huawei 700 P.R.China 702 Email: tommy@huawei.com 704 Roni Even 705 Huawei 706 Tel Aviv 707 Isreal 709 Email: roni.even@mail01.huawei.com