idnits 2.17.1 draft-snell-atompub-feature-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 587. 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 (June 17, 2007) is 6151 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-atompub-protocol-15 ** Downref: Normative reference to an Experimental draft: draft-snell-atompub-feed-license (ref. 'I-D.snell-atompub-feed-license') ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft June 17, 2007 4 Intended status: Standards Track 5 Expires: December 19, 2007 7 Atom Publishing Protocol Features Extension 8 draft-snell-atompub-feature-05.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 19, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document introduces extensions to the Atom Publishing Protocol 42 introspection format for expressing metadata about the behaviors, 43 functions and capabilities supported by an Atom Publishing Protocol 44 collection. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 50 3. The 'f:feature' element . . . . . . . . . . . . . . . . . . . 4 51 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 54 5.1. Registry of Atom Publishing Features . . . . . . . . . . . 6 55 5.1.1. Initial Assignments . . . . . . . . . . . . . . . . . 7 56 6. Normative References . . . . . . . . . . . . . . . . . . . . . 12 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 Intellectual Property and Copyright Statements . . . . . . . . . . 14 61 1. Introduction 63 This document introduces extensions for the Atom Publishing Protocol 64 service document format for expressing metadata about the behaviors, 65 functions and capabilities supported by an Atom Publishing Protocol 66 collection. 68 2. Notational Conventions 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in BCP 14, [RFC2119]. 74 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 75 to uniquely identify XML element names. It uses the following 76 namespace prefix for the indicated namespace URI; 78 "f": "http://purl.org/atompub/features/1.0" 80 This specification uses terms from the XML Infoset 81 [W3C.REC-xml-infoset-20040204]. However, this specification uses a 82 shorthand; the phrase "Information Item" is omitted when naming 83 Element Information Items. Therefore, when this specification uses 84 the terms "element" and "attribute" it is referring, respectively, to 85 the Element and Attribute Information Items in Infoset terms. 87 This specification uses the terms "atomUri" and 88 "atomCommonAttributes" from the non-normative RELAX NG Compact schema 89 included in [RFC4287]. Where used, these serve the same purpose and 90 have the same meaning as their use in [RFC4287]. 92 Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also 93 an IRI, so a URI may be used wherever below an IRI is named. There 94 are two special considerations: (1) when an IRI that is not also a 95 URI is given for dereferencing, it MUST be mapped to a URI using the 96 steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as 97 an identifier, it MUST NOT be so mapped. 99 Any element defined by this specification MAY have an xml:base 100 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an, 101 it serves the function described in section 5.1.1 of [RFC3986], 102 establishing the base URI (or IRI) for resolving any relative 103 references found within the effective scope of the xml:base 104 attribute. 106 Any element defined by this specification MAY have an xml:lang 107 attribute, whose content indicates the natural language for the 108 element and its descendents. The language context is only 109 significant for elements and attributes declared to be "Language- 110 Sensitive". Requirements regarding the content and interpretation of 111 xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204], Section 112 2.12. 114 3. The 'f:feature' element 116 A feature is an abstract behavior, function and capability supported 117 by an Atom Publishing Protocol collection. Examples of features that 118 might be supported by an APP server include support for draft 119 entries, scheduled publication of entries, use of a particular set of 120 Atom format extensions, use of a particular authentication scheme, 121 and so on. The presence of a f:feature element in an app:collection 122 element is an indication that the collection supports the feature 123 specified and may require that a client wishing to use the endpoint 124 use that feature. Features are identified using permanent, 125 universally unique IRI's. 127 feature = element f:feature { 128 atomCommonAttributes, 129 attribute ref { atomUri }, 130 attribute required { 'yes' | 'no' }?, 131 attribute href { atomUri }?, 132 attribute label { text }?, 133 (anyElement)* 134 } 136 anyElement = element * - f:* { 137 (attribute * { text } 138 | text 139 | anyElement)* 140 } 142 The "ref" attribute specifies a globally unique IRI identifying a 143 feature supported by a collection. The value of the ref attribute 144 MUST be compared on a case-sensitive, character-by-character basis. 145 Relative references MUST NOT be used. 147 A 'required' attribute value of "yes" indicates that clients MUST 148 utilize the identified feature when interacting with the collection. 149 A server MAY reject requests from clients that do not support or use 150 the feature. If not specified, the value is assumed to be "no". 152 An optional 'href' attribute MAY be used to specify the URI of a 153 human-readable description of the feature. Relative references MAY 154 be used. 156 The optional 'label' attribute MAY be used to specify a human- 157 readable label for the feature. The value of the 'label' attribute 158 is Language-Sensitive as defined by Section 2 of [RFC4287]. 160 The f:feature element MAY contain child elements and attributes other 161 than those defined in this specification. Such "foreign markup" are 162 considered to be metadata applicable to the feature identified by the 163 f:feature element. Software agents MUST NOT stop processing or 164 signal an error or change their behavior as a result of encountering 165 such foreign markup. 167 An app:collection element MAY contain zero or more f:feature elements 168 but MUST NOT contain more than one with the same ref attribute value. 169 The order in which f:feature elements appear within the app: 170 collection element is insignificant. 172 The f:feature element MAY contain attributes included as part of the 173 atomCommonAttributes production defined by Section 2 of [RFC4287] or 174 any update thereof. When used on an f:feature element, such 175 attributes serve the same purpose described in [RFC4287] or their 176 corresponding specifications. 178 3.1. Example 180 The following is an example of a collection supporting one 181 hypothetical required feature and a number of optional features. 183 187 188 My Workspace 189 190 My Atom Collection 191 application/atom+xml;type=entry 192 194 196 198 199 202 203 204 206 4. Security Considerations 208 Specific features supported by a collection may introduce security 209 considerations and concerns beyond those discussed by the Atom 210 Publishing Protocol and Atom Syndication Format specifications. 211 Implementors must refer to the specifications and description of each 212 feature to determine the security considerations relevant to each. 214 5. IANA Considerations 216 5.1. Registry of Atom Publishing Features 218 The Registry of Atom Publishing Features is maintained by IANA and 219 contains information about known features that can be supported by 220 Atom Publishing Protocol implementations. New assignments are 221 subject to IESG approval, as outlined in [RFC2434]. Requests should 222 be made by email to IANA, which will then forward the request to the 223 IESG, requesting approval. The request should use the following 224 template: 226 o Ref: (A globally unique IRI identifying the feature) 227 o Label: (A human-readable label for the feature) 228 o Description: (A human-readable description of the feature) 229 o Href: (A URI referencing a document containing a detailed 230 definition of the feature) 231 o Security Considerations: 233 5.1.1. Initial Assignments 235 The Registry of Features initially contains the following 236 assignments: 238 5.1.1.1. Drafts - http://www.w3.org/2007/app/drafts 240 o Ref: http://www.w3.org/2007/app/drafts 241 o Label: Drafts 242 o Description: The "Drafts" feature indicates that a collection 243 supports the use of the app:draft control element as defined in 244 section 13.1.1 of [I-D.ietf-atompub-protocol]. 246 5.1.1.2. XHTML Content - http://www.w3.org/2007/app/xhtml-content 248 o Ref: http://www.w3.org/2007/app/xhtml-content 249 o Label: XHTML Content 250 o Description: The "XHTML Content" feature indicates that a server 251 will accept the use of an XHTML value within the atom:content 252 element. 254 5.1.1.3. HTML Content - http://www.w3.org/2007/app/html-content 256 o Ref: http://www.w3.org/2007/app/html-content 257 o Label: HTML Content 258 o Description: The "HTML Content" feature indicates that a server 259 will accept the use of an escaped HTML value within the atom: 260 content element. 262 5.1.1.4. Text Content - http://www.w3.org/2007/app/text-content 264 o Ref: http://www.w3.org/2007/app/text-content 265 o Label: Text Content 266 o Description: The "Text Content" feature indicates that a server 267 will accept the use of a plain text value within the atom:content 268 element. 270 5.1.1.5. XML Content - http://www.w3.org/2007/app/xml-content 272 o Ref: http://www.w3.org/2007/app/xml-content 273 o Label: XML Content 274 o Description: The "XML Content" feature indicates that a server 275 will accept the use of well-formed XML content within the atom: 276 content element. 278 5.1.1.6. Binary Content - http://www.w3.org/2007/app/binary-content 280 o Ref: http://www.w3.org/2007/app/xhtml-content 281 o Label: Binary Content 282 o Description: The "Binary Content" feature indicates that a server 283 will accept Base-64 encoded binary data within the atom:content 284 element. 286 5.1.1.7. Referenced Content - http://www.w3.org/2007/app/src-content 288 o Ref: http://www.w3.org/2007/app/ref-content 289 o Label: XHTML Content 290 o Description: The "Referenced Content" feature indicates that a 291 server will accept atom:content elements that use the src 292 attribute to reference external content resources. 294 5.1.1.8. XHTML Title - http://www.w3.org/2007/app/xhtml-title 296 o Ref: http://www.w3.org/2007/app/xhtml-title 297 o Label: XHTML Title 298 o Description: The "XHTML Title" feature indicates that a server 299 will accept the use of an XHTML value within the atom:title 300 element. 302 5.1.1.9. HTML Title - http://www.w3.org/2007/app/html-title 304 o Ref: http://www.w3.org/2007/app/html-title 305 o Label: HTML Title 306 o Description: The "HTML Content" feature indicates that a server 307 will accept the use of an escaped HTML value within the atom:title 308 element. 310 5.1.1.10. Text Title - http://www.w3.org/2007/app/text-title 312 o Ref: http://www.w3.org/2007/app/text-title 313 o Label: Text Title 314 o Description: The "Text Content" feature indicates that a server 315 will accept the use of a plain text value within the atom:title 316 element. 318 5.1.1.11. XHTML Summary - http://www.w3.org/2007/app/xhtml-summary 320 o Ref: http://www.w3.org/2007/app/xhtml-summary 321 o Label: XHTML Summary 322 o Description: The "XHTML Summary" feature indicates that a server 323 will accept the use of an XHTML value within the atom:summary 324 element. 326 5.1.1.12. HTML Summary - http://www.w3.org/2007/app/html-summary 328 o Ref: http://www.w3.org/2007/app/html-summary 329 o Label: HTML Summary 330 o Description: The "HTML Summary" feature indicates that a server 331 will accept the use of an escaped HTML value within the atom: 332 summary element. 334 5.1.1.13. Text Summary - http://www.w3.org/2007/app/text-summary 336 o Ref: http://www.w3.org/2007/app/text-summary 337 o Label: Text Summary 338 o Description: The "Text Summary" feature indicates that a server 339 will accept the use of a plain text value within the atom:summary 340 element. 342 5.1.1.14. Auto Summary - http://www.w3.org/2007/app/auto-summary 344 o Ref: http://www.w3.org/2007/app/auto-summary 345 o Label: Auto Summary 346 o Description: The "Auto Summary" feature indicates that a server 347 will autogenerate the value of the atom:summary element and will 348 either reject or ignore attempts by the client to modify the value 349 of atom:summary. 351 5.1.1.15. XHTML Rights - http://www.w3.org/2007/app/xhtml-rights 353 o Ref: http://www.w3.org/2007/app/xhtml-rights 354 o Label: XHTML Rights 355 o Description: The "XHTML Rights" feature indicates that a server 356 will accept the use of an XHTML value within the atom:rights 357 element. 359 5.1.1.16. HTML Rights - http://www.w3.org/2007/app/html-rights 361 o Ref: http://www.w3.org/2007/app/html-rights 362 o Label: HTML Rights 363 o Description: The "HTML Rights" feature indicates that a server 364 will accept the use of an escaped HTML value within the atom: 365 rights element. 367 5.1.1.17. Text Rights - http://www.w3.org/2007/app/text-rights 369 o Ref: http://www.w3.org/2007/app/text-rights 370 o Label: Text Rights 371 o Description: The "Text Rights" feature indicates that a server 372 will accept the use of a plain text value within the atom:rights 373 element. 375 5.1.1.18. Authenticated Author - http://www.w3.org/2007/app/auth-author 377 o Ref: http://www.w3.org/2007/app/auth-author 378 o Label: Authenticated Author 379 o Description: The "Authenticated Author" feature indicates that a 380 server will use the authenticated identity of the client to 381 determine the values to use within the atom:author element. 382 Attempts by a client to manually set or modify the author 383 information will either be rejected or ignored by the server. 385 5.1.1.19. Slug - http://www.w3.org/2007/app/slug 387 o Ref: http://www.w3.org/2007/app/slug 388 o Label: Slug 389 o Description: The "Slug" feature indicates that a server will use 390 the Slug request header defined in section 9.7 of 391 [I-D.ietf-atompub-protocol] to set the URI of newly created 392 resources. 394 5.1.1.20. Multiple Categories - 395 http://www.w3.org/2007/app/multiple-categories 397 o Ref: http://www.w3.org/2007/app/multiple-categories 398 o Label: Multiple Categories 399 o Description: The "Multiple Categories" feature indicates that a 400 server will accept entries that contain multiple atom:category 401 elements. 403 5.1.1.21. Multiple Authors - 404 http://www.w3.org/2007/app/multiple-authors 406 o Ref: http://www.w3.org/2007/app/multiple-authors 407 o Label: Multiple Authors 408 o Description: The "Multiple Authors" feature indicates that a 409 server will accept and preserve multiple atom:author elements 410 contained by an entry. 412 5.1.1.22. Multiple Contributors - 413 http://www.w3.org/2007/app/multiple-contributors 415 o Ref: http://www.w3.org/2007/app/contributors 416 o Label: Multiple Contributors 417 o Description: The "Multiple Contributors" feature indicates that a 418 server will accept and preserve atom:contributor elements 419 contained by an entry. 421 5.1.1.23. Preserve Infoset - 422 http://www.w3.org/2007/app/preserve-infoset 424 Label: Preserve Infoset 426 Description: The "Preserve Infoset" feature indicates that a server 427 will preserve the complete XML XML Infoset 428 [W3C.REC-xml-infoset-20040204] of entries POST or PUT to a 429 collection. 431 5.1.1.24. Preserve IDs - http://www.w3.org/2007/app/preserve-id 433 o Ref: http://www.w3.org/2007/app/preserve-id 434 o Label: Preserve IDs 435 o Description: The "Preserve IDs" feature indicates that a server 436 will preserve the value of atom:id elements as provided by a 437 client. 439 5.1.1.25. Preserve Dates - http://www.w3.org/2007/app/preserve-dates 441 o Ref: http://www.w3.org/2007/app/preserve-updated 442 o Label: Preserve Dates 443 o Description: The "Preserve Dates" feature indicates that a server 444 will preserve the value of the atom:updated and atom:published 445 elements as provided by a client. 447 5.1.1.26. Preserve Extensions - 448 http://www.w3.org/2007/app/preserve-extensions 450 o Ref: http://www.w3.org/2007/app/preserve-extensions 451 o Label: Preserve Extensions 452 o Description: The "Preserve Extensions" feature indicates that a 453 server will preserve unknown foreign markup contained within an 454 entry. 456 5.1.1.27. Preserve Links - http://www.w3.org/2007/app/preserve-links 457 o Ref: http://www.w3.org/2007/app/preserve-links 458 o Label: Preserve Links 459 o Description: The "Preserve Links" feature indicates that a server 460 will preserve all atom:link elements contained within an entry. 462 5.1.1.28. Preserve Rights - http://www.w3.org/2007/app/preserve-rights 464 o Ref: http://www.w3.org/2007/app/preserve-rights 465 o Label: Preserve Rights 466 o Description: The "Preserve Rights" feature indicates that a server 467 will preserve all atom:rights elements and License Links 468 [I-D.snell-atompub-feed-license] contained within an entry. 470 5.1.1.29. Threading - http://purl.org/syndication/thread/1.0 472 o Ref: http://purl.org/syndication/thread/1.0 473 o Label: Threading 474 o Description: The Feed Thread feature indicates that the APP server 475 accepts entries that contain the in-reply-to element as defined by 476 [RFC4685]. 478 6. Normative References 480 [I-D.ietf-atompub-protocol] 481 Hora, B. and J. Gregorio, "The Atom Publishing Protocol", 482 draft-ietf-atompub-protocol-15 (work in progress), 483 May 2007. 485 [I-D.snell-atompub-feed-license] 486 Snell, J., "Atom License Extension", 487 draft-snell-atompub-feed-license-11 (work in progress), 488 March 2007. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 494 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 495 October 1998. 497 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 498 Resource Identifier (URI): Generic Syntax", STD 66, 499 RFC 3986, January 2005. 501 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 502 Identifiers (IRIs)", RFC 3987, January 2005. 504 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 505 Syndication Format", RFC 4287, December 2005. 507 [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, 508 September 2006. 510 [W3C.REC-xml-20040204] 511 Yergeau, F., Maler, E., Bray, T., Paoli, J., and C. 512 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 513 (Third Edition)", World Wide Web Consortium 514 FirstEdition REC-xml-20040204, February 2004, 515 . 517 [W3C.REC-xml-infoset-20040204] 518 Tobin, R. and J. Cowan, "XML Information Set (Second 519 Edition)", World Wide Web Consortium Recommendation REC- 520 xml-infoset-20040204, February 2004, 521 . 523 [W3C.REC-xml-names-19990114] 524 Hollander, D., Bray, T., and A. Layman, "Namespaces in 525 XML", World Wide Web Consortium FirstEdition REC-xml- 526 names-19990114, January 1999, 527 . 529 [W3C.REC-xmlbase-20010627] 530 Marsh, J., "XML Base", World Wide Web Consortium 531 Recommendation REC-xmlbase-20010627, June 2001, 532 . 534 Appendix A. Acknowledgements 536 The author acknowledges the feedback from Elias Torres, Robert Yates, 537 David Johnson, Byrne Reese, Joe Gregorio, Bill de hO`ra and the other 538 members of the IETF Atom Publishing working group during the 539 development of this specification. 541 Author's Address 543 James M Snell 545 Phone: 546 Email: jasnell@gmail.com 547 URI: http://snellspace.com 549 Full Copyright Statement 551 Copyright (C) The IETF Trust (2007). 553 This document is subject to the rights, licenses and restrictions 554 contained in BCP 78, and except as set forth therein, the authors 555 retain all their rights. 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 560 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 561 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 562 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Intellectual Property 567 The IETF takes no position regarding the validity or scope of any 568 Intellectual Property Rights or other rights that might be claimed to 569 pertain to the implementation or use of the technology described in 570 this document or the extent to which any license under such rights 571 might or might not be available; nor does it represent that it has 572 made any independent effort to identify any such rights. Information 573 on the procedures with respect to rights in RFC documents can be 574 found in BCP 78 and BCP 79. 576 Copies of IPR disclosures made to the IETF Secretariat and any 577 assurances of licenses to be made available, or the result of an 578 attempt made to obtain a general license or permission for the use of 579 such proprietary rights by implementers or users of this 580 specification can be obtained from the IETF on-line IPR repository at 581 http://www.ietf.org/ipr. 583 The IETF invites any interested party to bring to its attention any 584 copyrights, patents or patent applications, or other proprietary 585 rights that may cover technology that may be required to implement 586 this standard. Please address the information to the IETF at 587 ietf-ipr@ietf.org. 589 Acknowledgment 591 Funding for the RFC Editor function is provided by the IETF 592 Administrative Support Activity (IASA).