idnits 2.17.00 (12 Aug 2021) /tmp/idnits43104/draft-ietf-simple-xcap-diff-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 676. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 5, 2008) is 5128 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 2648 == Outdated reference: draft-ietf-simple-xml-patch-ops has been published as RFC 5261 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Urpalainen 5 Expires: November 6, 2008 Nokia 6 May 5, 2008 8 An Extensible Markup Language (XML) Document Format for Indicating A 9 Change in XML Configuration Access Protocol (XCAP) Resources 10 draft-ietf-simple-xcap-diff-09 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 6, 2008. 37 Abstract 39 This specification defines a document format that can be used to 40 indicate that a change has occurred in a document managed by the 41 Extensible Markup Language (XML) Configuration Access Protocol 42 (XCAP). This format indicates the document that has changed and its 43 former and new entity tags. It also can indicate the specific change 44 that was made in the document, using an XML patch format. This 45 format allows also indications of element and attribute content of an 46 XML document. XCAP diff documents can be delivered to clients using 47 a number of means, including a Session Initiation Protocol (SIP) 48 event package. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4 55 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 9 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 11 60 7.2. URN Sub-Namespace Registration for 61 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12 62 7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 13 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 68 Intellectual Property and Copyright Statements . . . . . . . . . . 16 70 1. Introduction 72 The Extensible Markup Language (XML) Configuration Access Protocol 73 (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML 74 documents stored on a server. These XML documents serve as 75 configuration information for application protocols. As an example, 76 resource list [RFC4662] subscriptions (also known as presence lists) 77 allow a client to have a single SIP subscription to a list of users, 78 where the list is maintained on a server. The server will obtain 79 presence for those users and report it back to the client. This 80 application requires the server, called a Resource List Server (RLS), 81 to have access to the list of presentities. This list needs to be 82 manipulated by clients so they can add and remove their friends as 83 they desire. 85 Complexities arise when multiple clients attempt to simultaneously 86 manipulate a document, such as a presence list. Frequently, a client 87 will keep a copy of the current list in memory, so it can render it 88 to users. However, if another client modifies the document, the 89 cached version becomes stale. This modification event must be made 90 known to all clients which have cached copies of the document, so 91 that they can fetch the most recent one. 93 To deal with this problem, clients can use a Session Initiation 94 Protocol (SIP) [RFC3261] event package [RFC3265] to subscribe to 95 change events in XCAP documents. This notification needs to indicate 96 the specific resource that changed, and how it changed. One solution 97 for the format of such a change notification would be a content 98 indirection object [RFC4483]. Though content indirection can tell a 99 client that a document has changed, it provides it with MIME 100 Content-ID indicating the new version of the document. The MIME 101 Content-ID is not the same as the entity tag, which is used by XCAP 102 for document versioning. As such, a client cannot easily ascertain 103 whether an indication of a change in a document is due to a change it 104 just made, or due to a change another client made at around the same 105 time. Furthermore, content indirections don't indicate how a 106 document changed; they would only be able to indicate that it did 107 change. 109 To resolve these problems, this document defines a data format which 110 can convey the fact that an XML document managed by XCAP has changed. 111 This data format is an XML document format, called an XCAP diff 112 document. This format can indicate that a document has changed, and 113 provide its previous and new entity tags. It can also optionally 114 include a set of patch operations [I-D.ietf-simple-xml-patch-ops], 115 which indicate how to transform the document from the version prior 116 to the change, to the version after it. XML element and attribute 117 content of XCAP documents can also be delivered with this format. 119 XML documents that are equivalent for the purposes of many 120 applications may differ in their physical representation. Similar to 121 XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of 122 an XML document determines the logical equivalence when this format 123 is used to patch XML documents. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119] and 130 indicate requirement levels for compliant implementations. 132 This specification also defines the following additional terms: 134 Document: When the term document is used without the "XCAP diff" in 135 front of it, it refers to the XCAP document resource about whom 136 the XCAP diff document is reporting a change. 138 XCAP diff document: The XML document defined by this specification 139 that reports on a set of changes in an XCAP document resource. 141 Server: Typically an XCAP server, this is a protocol entity that 142 generates XCAP diff documents based on its knowledge of a set of 143 XCAP documents. 145 Client: Typically an XCAP client and SIP User Agent (UA), the client 146 consumes XCAP diff documents in order to reconstruct the document 147 stored on the server. 149 3. Structure of an XCAP Diff Document 151 An XCAP diff document is an XML [W3C.REC-xml-20060816] document that 152 MUST be well-formed and SHOULD be valid. XCAP diff documents MUST be 153 based on XML 1.0 and MUST be encoded using UTF-8. This specification 154 makes use of XML namespaces for identifying XCAP diff documents and 155 document fragments. The namespace URI for elements defined by this 156 specification is a URN [RFC2141], using the namespace identifier 157 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is: 159 urn:ietf:params:xml:ns:xcap-diff 161 An XCAP diff document begins with the root element tag . 162 This element has a single mandatory attribute, "xcap-root". The 163 value of this attribute is the XCAP root URI for the documents in 164 which the changes have taken place. A single XCAP diff document can 165 only represent changes in documents within the same XCAP root. The 166 content of the element is an unordered sequence of 167 , and elements followed by any number 168 of elements from other namespaces for the purposes of extensibility. 169 Any such unknown elements MUST be ignored by the client. Each 170 element specifies changes in a specific document within 171 the XCAP root. It has one mandatory attribute, "sel", and a two 172 optional attributes, "new-etag" and "previous-etag". The "sel" 173 attribute of the element identifies the specific document 174 within the XCAP root for which changes are indicated. Its content 175 MUST be a relative path reference, with the base URI being equal to 176 the XCAP root URI. The "new-etag" attribute provides the entity tag 177 (ETag) for the document after the application of the changes, 178 assuming the document exists after those changes. The "previous- 179 etag" attribute provides an identifier for the document instance 180 prior to the change. If the change being reported is the removal of 181 a document, the "previous-etag" MUST only be included and the "new- 182 etag" attribute will not be present. The "new-etag" attribute MUST 183 only exist alone when the document either exists or it was just 184 created (no patch included). Both attributes are present when a 185 patch (or series of XCAP operations) has been applied to the 186 resource. Also both attributes MAY be used to indicate an ETag 187 change without any document modifications (patches). 189 The "previous-etag" and "new-etag" need not have been sequentially 190 assigned ETags at the server. An XCAP diff document can indicate 191 changes that have occurred over a series of XCAP operations. The 192 only requirement then is that, the sequence of events, when executed 193 serially, will result in the transformation of the document with the 194 ETag "previous-etag" to the one whose ETag is "new-etag". Also the 195 series of operations do not have to be the same exact series of 196 operations that occurred at the server. If several 197 elements with the same "sel" selector value exist in the XCAP diff 198 document, i.e. for example, the full ETag change history is 199 indicated, the corresponding patches MUST be appliable in the given 200 document order. 202 Each element contains either a sequence of patching 203 instructions or an indication that the body hasn't semantically 204 changed. The latter means that the document has been assigned a new 205 ETag but its content is unchanged and it is indicated by the element. Patching instructions are described by the 207 , and elements. These elements use the 208 corresponding add, replace and remove types defined in 209 [I-D.ietf-simple-xml-patch-ops], and define a set of patch operations 210 that can be applied to transform the document. See 211 [I-D.ietf-simple-xml-patch-ops] for instructions on how this 212 transformation is effected. The element can also contain 213 elements from other namespaces for the purposes of extensibility. 214 The , and elements allow extension attributes 215 from any namespace. Any unknown elements element or 216 attributes of patch operation elements MUST be ignored. 218 Figure 1 shows element content and how corresponding 219 resource or metadata changes. An external document retrieval means 220 in practice HTTP GET requests for target resources. 222 +-----------+----------+-----------+----------+-------------------+ 223 | previous- | new- | | | not- | metadata change | 225 | | | | changed> | | 226 +-----------+----------+-----------+----------+-------------------+ 227 | xxx | yyy | * | - | resource patched, | 228 | | | | | patch included | 229 +-----------+----------+-----------+----------+-------------------+ 230 | xxx | yyy | - | - | resource patched, | 231 | | | | | external document | 232 | | | | | retrieval | 233 +-----------+----------+-----------+----------+-------------------+ 234 | xxx | yyy | - | * | only ETag changed | 235 +-----------+----------+-----------+----------+-------------------+ 236 | - | yyy | - | - | resource created | 237 | | | | | or exists, | 238 | | | | | external document | 239 | | | | | retrieval | 240 +-----------+----------+-----------+----------+-------------------+ 241 | xxx | - | - | - | resource removed | 242 +-----------+----------+-----------+----------+-------------------+ 244 Figure 1: element content / corresponding resource changes 246 Each element indicates the existing element content of an 247 XCAP document. It has one mandatory attribute, "sel", and one 248 optional attribute, "exists". The "sel" attribute of the 249 element identifies an XML element of an XCAP document. It is a 250 percent endoced relative URI following XCAP conventions when 251 selecting elements. The XCAP Node Selector MUST always locate a 252 unique node, the "exists" attribute thus shows whether an element 253 exists or not in the XCAP document. When the "exists" attribute is 254 absent from the element, it means that the indicated 255 element still exists in the XCAP document. The located result 256 element exists as a child element of the element. It 257 should be noted, that only the full content of an element is shown if 258 it exists, there are no conventions for patching these elements. In 259 a corner case where the content of this element cannot be presented 260 for some reason, although it exists in the XCAP document, the 261 element MUST NOT have any child nodes. 263 As the result XML element is typically namespace qualified, all 264 needed namespace declarations MUST exist within the 265 document. The possible local namespace declarations within the 266 result element exist unmodified as in the source document, similar to 267 XCAP conventions. Other namespace references MUST be resolved from 268 the context of the or its parent elements. The prefixes of 269 qualified names (QName) [W3C.REC-xml-names-20060816] of XML nodes 270 also remain as they exist originally in the source XCAP document. 272 Each element indicates the existing attribute content of 273 an XCAP document. It has one mandatory attribute, "sel", and one 274 optional attribute, "exists". The "sel" attribute of the 275 element identifies an XML attribute of an XCAP document. It is a 276 percent endoced relative URI following XCAP conventions when 277 selecting attributes. The "exists" attribute indicates whether an 278 attribute exists or not in the XCAP document. When the "exists" 279 attribute is absent from the element, it means that the 280 indicated attribute still exists in the XCAP document. The child 281 text node of the element indicates the value of the 282 located attribute. Note that if the attribute is namespace 283 qualified, the query parameter of the XCAP URI indicates the attached 284 namespace URI and the prefix in the XCAP source document. 286 4. XML Schema 288 The XML Schema for the XCAP diff format. 290 291 297 298 301 302 303 304 305 306 307 308 309 310 311 312 314 315 316 317 318 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 355 356 357 358 359 360 361 362 364 365 366 367 368 369 371 372 374 375 376 377 379 380 381 382 383 385 386 387 388 390 391 393 395 5. Example Document 397 The following is an example of a document compliant to the schema. 399 400 403 407 413 414 415 416 417 418 presence 419 420 422 sip:marketing@example.com 426 428 This indicates that the document with URI "http://xcap.example.com/ 429 root/resource-lists/users/sip:joe@example.com/coworkers" has changed. 430 Its previous entity tag is "8a77f8d" and its new one is "7ahggs" but 431 actual changes are not shown. The element exists in the 432 rls-services "index" document and its full content is shown. Note 433 that the element is attached with a default namespace 434 declaration within the original document. Similarly, a "uri" 435 attribute content is shown from the same "index" document as an 436 illustrative example. 438 6. Security Considerations 440 XCAP diff documents can include changes from one document to another. 441 As a consequence, if the document itself is sensitive and requires 442 confidentiality, integrity or authentication, then the same applies 443 to the XCAP diff format. Therefore, protocols which transport XCAP 444 diff documents must provide sufficient security capabilities for 445 transporting the document itself. 447 The SIP event package framework specified in RFC 3265 [RFC3265] is 448 the most typical use-case for this format. Then in general its 449 security considerations apply, but event packages MAY also have other 450 specific threats which MUST be considered on an application-by- 451 application basis. 453 7. IANA Considerations 455 There are several IANA considerations associated with this 456 specification. 458 7.1. application/xcap-diff+xml MIME Type 460 MIME media type name: application 462 MIME subtype name: xcap-diff+xml 464 Mandatory parameters: none 466 Optional parameters: Same as charset parameter application/xml as 467 specified in RFC 3023 [RFC3023]. 469 Encoding considerations: Same as encoding considerations of 470 application/xml as specified in RFC 3023 [RFC3023]. 472 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 473 Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 474 XXXX with the RFC number of this specification.]]. 476 Interoperability considerations: none. 478 Published specification: This document. 480 Applications which use this media type: This document type has 481 been used to support manipulation of resource lists [RFC4826] 482 using XCAP. 484 Additional Information: 486 Magic Number: None 488 File Extension: .xdf 489 Macintosh file type code: "TEXT" 491 Personal and email address for further information: Jonathan 492 Rosenberg, jdrosen@jdrosen.net 494 Intended usage: COMMON 496 Author/Change controller: The IETF. 498 7.2. URN Sub-Namespace Registration for 499 urn:ietf:params:xml:ns:xcap-diff 501 This section registers a new XML namespace, as per the guidelines in 502 [RFC3688] 504 URI: The URI for this namespace is 505 urn:ietf:params:xml:ns:xcap-diff. 507 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 508 Jonathan Rosenberg (jdrosen@jdrosen.net). 510 XML: 512 BEGIN 513 514 516 517 518 520 XCAP Diff Namespace 521 522 523

Namespace for XCAP Diff

524

urn:ietf:params:xml:ns:xcap-diff

525

See RFCXXXX[[NOTE 526 TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this 527 specification.]].

528 529 530 END 532 7.3. Schema Registration 534 This section registers a new XML schema per the procedures in 535 [RFC3688]. 537 URI: urn:ietf:params:xml:schema:xcap-diff 539 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 540 Jonathan Rosenberg (jdrosen@jdrosen.net). 542 The XML for this schema can be found as the sole content of 543 Section 4. 545 8. Acknowledgments 547 The authors would like to thank Pavel Dostal, Jeroen van Bemmel, 548 Martin Hynar, Anders Lindgren and Mary Barnes for their valuable 549 comments. 551 9. References 553 9.1. Normative References 555 [W3C.REC-xml-20060816] 556 Maler, E., Paoli, J., Bray, T., Yergeau, F., and C. 557 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 558 (Fourth Edition)", World Wide Web Consortium 559 Recommendation REC-xml-20060816, August 2006, 560 . 562 [W3C.REC-xml-c14n-20010315] 563 Boyer, J., "Canonical XML Version 1.0", World Wide Web 564 Consortium Recommendation REC-xml-c14n-20010315, 565 March 2001, 566 . 568 [W3C.REC-xml-names-20060816] 569 Hollander, D., Bray, T., Layman, A., and R. Tobin, 570 "Namespaces in XML 1.0 (Second Edition)", World Wide Web 571 Consortium Recommendation REC-xml-names-20060816, 572 August 2006, 573 . 575 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 577 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 578 Types", RFC 3023, January 2001. 580 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 581 August 1999. 583 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 584 January 2004. 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 590 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 592 [I-D.ietf-simple-xml-patch-ops] 593 Urpalainen, J., "An Extensible Markup Language (XML) Patch 594 Operations Framework Utilizing XML Path Language (XPath) 595 Selectors", draft-ietf-simple-xml-patch-ops-04 (work in 596 progress), November 2007. 598 9.2. Informative References 600 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 601 A., Peterson, J., Sparks, R., Handley, M., and E. 602 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 603 June 2002. 605 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 606 Event Notification", RFC 3265, June 2002. 608 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 609 Initiation Protocol (SIP) Event Notification Extension for 610 Resource Lists", RFC 4662, August 2006. 612 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 613 for Representing Resource Lists", RFC 4826, May 2007. 615 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 616 Session Initiation Protocol (SIP) Messages", RFC 4483, 617 May 2006. 619 Authors' Addresses 621 Jonathan Rosenberg 622 Cisco 623 Edison, NJ 624 US 626 Email: jdrosen@cisco.com 627 URI: http://www.jdrosen.net 629 Jari Urpalainen 630 Nokia 631 Itamerenkatu 11-13 632 Helsinki 00180 633 Finland 635 Phone: +358 7180 37686 636 Email: jari.urpalainen@nokia.com 638 Full Copyright Statement 640 Copyright (C) The IETF Trust (2008). 642 This document is subject to the rights, licenses and restrictions 643 contained in BCP 78, and except as set forth therein, the authors 644 retain all their rights. 646 This document and the information contained herein are provided on an 647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 649 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 650 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 651 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Intellectual Property 656 The IETF takes no position regarding the validity or scope of any 657 Intellectual Property Rights or other rights that might be claimed to 658 pertain to the implementation or use of the technology described in 659 this document or the extent to which any license under such rights 660 might or might not be available; nor does it represent that it has 661 made any independent effort to identify any such rights. Information 662 on the procedures with respect to rights in RFC documents can be 663 found in BCP 78 and BCP 79. 665 Copies of IPR disclosures made to the IETF Secretariat and any 666 assurances of licenses to be made available, or the result of an 667 attempt made to obtain a general license or permission for the use of 668 such proprietary rights by implementers or users of this 669 specification can be obtained from the IETF on-line IPR repository at 670 http://www.ietf.org/ipr. 672 The IETF invites any interested party to bring to its attention any 673 copyrights, patents or patent applications, or other proprietary 674 rights that may cover technology that may be required to implement 675 this standard. Please address the information to the IETF at 676 ietf-ipr@ietf.org.