idnits 2.17.00 (12 Aug 2021) /tmp/idnits40264/draft-ietf-simple-xcap-diff-07.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 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 671. 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 (November 16, 2007) is 5299 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: May 19, 2008 Nokia 6 November 16, 2007 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-07 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 May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines a document format that can be used to 44 indicate that a change has occurred in a document managed by the 45 Extensible Markup Language (XML) Configuration Access Protocol 46 (XCAP). This format indicates the document that has changed and its 47 former and new entity tags. It also can indicate the specific change 48 that was made in the document, using an XML patch format. This 49 format allows also indications of element and attribute content of an 50 XML document. XCAP diff documents can be delivered to clients using 51 a number of means, including a Session Initiation Protocol (SIP) 52 event package. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4 59 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 11 64 7.2. URN Sub-Namespace Registration for 65 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12 66 7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 12 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property and Copyright Statements . . . . . . . . . . 16 74 1. Introduction 76 The Extensible Markup Language (XML) Configuration Access Protocol 77 (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML 78 documents stored on a server. These XML documents serve as 79 configuration information for application protocols. As an example, 80 resource list [RFC4662] subscriptions (also known as presence lists) 81 allow a client to have a single SIP subscription to a list of users, 82 where the list is maintained on a server. The server will obtain 83 presence for those users and report it back to the client. This 84 application requires the server, called a Resource List Server (RLS), 85 to have access to the list of presentities. This list needs to be 86 manipulated by clients so they can add and remove their friends as 87 they desire. 89 Complexities arise when multiple clients attempt to simultaneously 90 manipulate a document, such as a presence list. Frequently, a client 91 will keep a copy of the current list in memory, so it can render it 92 to users. However, if another client modifies the document, the 93 cached version becomes stale. This modification event must be made 94 known to all clients which have cached copies of the document, so 95 that they can fetch the most recent one. 97 To deal with this problem, clients can use a Session Initiation 98 Protocol (SIP) [RFC3261] event package [RFC3265] to subscribe to 99 change events in XCAP documents. This notification needs to indicate 100 the specific resource that changed, and how it changed. One solution 101 for the format of such a change notification would be a content 102 indirection object [RFC4483]. Though content indirection can tell a 103 client that a document has changed, it provides it with MIME 104 Content-ID indicating the new version of the document. The MIME 105 Content-ID is not the same as the entity tag, which is used by XCAP 106 for document versioning. As such, a client cannot easily ascertain 107 whether an indication of a change in a document is due to a change it 108 just made, or due to a change another client made at around the same 109 time. Furthermore, content indirections don't indicate how a 110 document changed; they would only be able to indicate that it did 111 change. 113 To resolve these problems, this document defines a data format which 114 can convey the fact that an XML document managed by XCAP has changed. 115 This data format is an XML document format, called an XCAP diff 116 document. This format can indicate that a document has changed, and 117 provide its previous and new entity tags. It can also optionally 118 include a set of patch operations [I-D.ietf-simple-xml-patch-ops], 119 which indicate how to transform the document from the version prior 120 to the change, to the version after it. XML element and attribute 121 content of XCAP documents can also be delivered with this format. 123 XML documents that are equivalent for the purposes of many 124 applications may differ in their physical representation. Similar to 125 XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of 126 an XML document determines the logical equivalence when this format 127 is used to patch XML documents. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119] and 134 indicate requirement levels for compliant implementations. 136 This specification also defines the following additional terms: 138 Document: When the term document is used without the "XCAP diff" in 139 front of it, it refers to the XCAP document resource about whom 140 the XCAP diff document is reporting a change. 142 XCAP diff document: The XML document defined by this specification 143 that reports on a set of changes in an XCAP document resource. 145 Server: Typically an XCAP server, this is a protocol entity that 146 generates XCAP diff documents based on its knowledge of a set of 147 XCAP documents. 149 Client: Typically an XCAP client and SIP User Agent (UA), the client 150 consumes XCAP diff documents in order to reconstruct the document 151 stored on the server. 153 3. Structure of an XCAP Diff Document 155 An XCAP diff document is an XML [W3C.REC-xml-20060816] document that 156 MUST be well-formed and SHOULD be valid. XCAP diff documents MUST be 157 based on XML 1.0 and MUST be encoded using UTF-8. This specification 158 makes use of XML namespaces for identifying XCAP diff documents and 159 document fragments. The namespace URI for elements defined by this 160 specification is a URN [RFC2141], using the namespace identifier 161 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is: 163 urn:ietf:params:xml:ns:xcap-diff 165 An XCAP diff document begins with the root element tag . 166 This element has a single mandatory attribute, "xcap-root". The 167 value of this attribute is the XCAP root URI for the documents in 168 which the changes have taken place. A single XCAP diff document can 169 only represent changes in documents within the same XCAP root. The 170 content of the element is an unordered sequence of 171 , and elements followed by any number 172 of elements from other namespaces for the purposes of extensibility. 173 Any such unknown elements MUST be ignored by the client. Each 174 element specifies changes in a specific document within 175 the XCAP root. It has one mandatory attribute, "sel", and a two 176 optional attributes, "new-etag" and "previous-etag". The "sel" 177 attribute of the element identifies the specific document 178 within the XCAP root for which changes are indicated. Its content 179 MUST be a relative path reference, with the base URI being equal to 180 the XCAP root URI. The "new-etag" attribute provides the entity tag 181 (ETag) for the document after the application of the changes, 182 assuming the document exists after those changes. The "previous- 183 etag" attribute provides an identifier for the document instance 184 prior to the change. If the change being reported is the removal of 185 a document, the "previous-etag" MUST only be included and the "new- 186 etag" attribute will not be present. The "new-etag" attribute MUST 187 only exist alone when the document either exists or it was just 188 created (no patch included). Both attributes are present when a 189 patch (or series of XCAP operations) has been applied to the 190 resource. Also both attributes MAY be used to indicate an ETag 191 change without any document modifications (patches). 193 The "previous-etag" and "new-etag" need not have been sequentially 194 assigned ETags at the server. An XCAP diff document can indicate 195 changes that have occurred over a series of XCAP operations. The 196 only requirement then is that, the sequence of events, when executed 197 serially, will result in the transformation of the document with the 198 ETag "previous-etag" to the one whose ETag is "new-etag". Also the 199 series of operations do not have to be the same exact series of 200 operations that occurred at the server. If several 201 elements with the same "sel" selector value exist in the XCAP diff 202 document, i.e. for example, the full ETag change history is 203 indicated, the corresponding patches MUST be appliable in the given 204 document order. 206 Each element contains either a sequence of patching 207 instructions or an indication that the body hasn't semantically 208 changed. The latter means that the document has been assigned a new 209 ETag but its content is unchanged and it is indicated by the element. Patching instructions are described by the 211 , and elements. These elements use the 212 corresponding add, replace and remove types defined in 213 [I-D.ietf-simple-xml-patch-ops], and define a set of patch operations 214 that can be applied to transform the document. See 215 [I-D.ietf-simple-xml-patch-ops] for instructions on how this 216 transformation is effected. The element can also contain 217 elements from other namespaces for the purposes of extensibility. 218 The , and elements allow extension attributes 219 from any namespace. Any unknown elements element or 220 attributes of patch operation elements MUST be ignored. 222 Figure 1 shows element content and how corresponding 223 resource or metadata changes. An external document retrieval means 224 in practice an HTTP GET requests for a relevant resource. 226 +-----------+----------+-----------+----------+-------------------+ 227 | previous- | new- | | | not- | metadata change | 229 | | | | changed> | | 230 +-----------+----------+-----------+----------+-------------------+ 231 | xxx | yyy | * | - | resource patched, | 232 | | | | | patch included | 233 +-----------+----------+-----------+----------+-------------------+ 234 | xxx | yyy | - | - | resource patched, | 235 | | | | | external document | 236 | | | | | retrieval | 237 +-----------+----------+-----------+----------+-------------------+ 238 | xxx | yyy | - | * | only ETag changed | 239 +-----------+----------+-----------+----------+-------------------+ 240 | - | yyy | - | - | resource created | 241 | | | | | or exists, | 242 | | | | | external document | 243 | | | | | retrieval | 244 +-----------+----------+-----------+----------+-------------------+ 245 | xxx | - | - | - | resource removed | 246 +-----------+----------+-----------+----------+-------------------+ 248 Figure 1: element content / corresponding resource changes 250 Each element indicates the existing element content of an 251 XCAP document. It has one mandatory attribute, "sel", and one 252 optional attribute, "exists". The "sel" attribute of the 253 element identifies an XML element of an XCAP document. It is a 254 percent endoced relative URI following XCAP conventions when 255 selecting elements. The XCAP Node Selector MUST always locate a 256 unique node, the "exists" attribute thus shows whether an element 257 exists or not in the XCAP document. When the "exists" attribute is 258 absent from the element, the indicated element still exists 259 in the XCAP document. The located result element exists as a child 260 element of the element. It should be noted, that only the 261 full content of an element is shown if it exists, there are no 262 conventions for patching these elements. In a corner case where the 263 content of this element cannot be presented for some reason, although 264 it exists in the XCAP document, the element MUST NOT have 265 any child nodes. 267 As the result XML element is typically namespace qualified, all 268 needed namespace declarations MUST exist within the 269 document. The possible local namespace declarations within the 270 result element exist unmodified as in the source document, similar to 271 XCAP conventions. Other namespace references MUST be resolved from 272 the context of the or its parent elements. The prefixes of 273 qualified names (QName) [W3C.REC-xml-names-20060816] of XML nodes 274 also remain as they exist originally in the source XCAP document. 276 Each element indicates the existing attribute content of 277 an XCAP document. It has one mandatory attribute, "sel", and one 278 optional attribute, "exists". The "sel" attribute of the 279 element identifies an XML attribute of an XCAP document. It is a 280 percent endoced relative URI following XCAP conventions when 281 selecting attributes. The "exists" attribute indicates whether an 282 attribute exists or not in the XCAP document. When the "exists" 283 attribute is absent from the element, the indicated 284 attribute still exists in the XCAP document. The child text node of 285 the element indicates the value of the located attribute. 286 Note that if the attribute is namespace qualified, the query 287 parameter of the XCAP URI indicates the attached namespace URI and 288 the prefix in the XCAP source document. 290 4. XML Schema 292 The XML Schema for the XCAP diff format. 294 295 301 302 305 306 307 308 309 310 311 312 313 314 315 316 318 319 320 321 322 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 354 355 356 357 359 360 361 362 363 364 365 366 368 369 370 371 372 373 375 376 378 379 380 381 383 384 385 386 387 389 390 391 392 394 395 397 399 5. Example Document 401 The following is an example of a document compliant to the schema. 403 404 407 411 417 418 419 420 421 422 presence 423 424 426 sip:marketing@example.com 430 432 This indicates that the document with URI "http://xcap.example.com/ 433 root/resource-lists/users/sip:joe@example.com/coworkers" has changed. 434 Its previous entity tag is "8a77f8d" and its new one is "7ahggs" but 435 actual changes are not shown. The element exists in the 436 rls-services "index" document and its full content is shown. Note 437 that the element is attached with a default namespace 438 declaration within the original document. Similarly, a "uri" 439 attribute content is shown from the same "index" document as an 440 illustrative example. 442 6. Security Considerations 444 XCAP diff documents can include changes from one document to another. 445 As a consequence, if the document itself is sensitive and requires 446 confidentiality, integrity or authentication, then the same applies 447 to the XCAP diff format. Therefore, protocols which transport XCAP 448 diff documents must provide sufficient security capabilities for 449 transporting the document itself. 451 7. IANA Considerations 453 There are several IANA considerations associated with this 454 specification. 456 7.1. application/xcap-diff+xml MIME Type 458 MIME media type name: application 460 MIME subtype name: xcap-diff+xml 462 Mandatory parameters: none 464 Optional parameters: Same as charset parameter application/xml as 465 specified in RFC 3023 [RFC3023]. 467 Encoding considerations: Same as encoding considerations of 468 application/xml as specified in RFC 3023 [RFC3023]. 470 Security considerations: See Section 10 of RFC 3023 [RFC3023] and 471 Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 472 XXXX with the RFC number of this specification.]]. 474 Interoperability considerations: none. 476 Published specification: This document. 478 Applications which use this media type: This document type has 479 been used to support manipulation of resource lists [RFC4826] 480 using XCAP. 482 Additional Information: 484 Magic Number: None 486 File Extension: .xdf 488 Macintosh file type code: "TEXT" 490 Personal and email address for further information: Jonathan 491 Rosenberg, jdrosen@jdrosen.net 492 Intended usage: COMMON 494 Author/Change controller: The IETF. 496 7.2. URN Sub-Namespace Registration for 497 urn:ietf:params:xml:ns:xcap-diff 499 This section registers a new XML namespace, as per the guidelines in 500 [RFC3688] 502 URI: The URI for this namespace is 503 urn:ietf:params:xml:ns:xcap-diff. 505 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 506 Jonathan Rosenberg (jdrosen@jdrosen.net). 508 XML: 510 BEGIN 511 512 514 515 516 518 XCAP Diff Namespace 519 520 521

Namespace for XCAP Diff

522

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

523

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

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