idnits 2.17.1 draft-snell-atompub-feature-11.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 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. 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 (October 22, 2007) is 6030 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 October 22, 2007 4 Intended status: Experimental 5 Expires: April 24, 2008 7 Atom Publishing Protocol Feature Discovery 8 draft-snell-atompub-feature-11.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 April 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document introduces extensions to the Atom Publishing Protocol 42 Service Document 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. The "supportsDraft" Feature . . . . . . . . . . . . . . . . . . 6 53 5. The "ignoresDraft" Feature . . . . . . . . . . . . . . . . . . 6 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . . . 8 61 1. Introduction 63 This document introduces an extension to the Atom Publishing Protocol 64 (Atompub) service document [RFC5023] format that allows for the 65 documentation and discovery of behaviors, functions or capabilities 66 supported by an Atompub collection. Examples of such capabilities 67 can include the preservation of certain kinds of content, support for 68 draft entries, support for the scheduled publication of entries, use 69 of a particular set of Atom format extensions, and so on. 71 Describing features using the mechanisms defined in this 72 specification is currently considered to be largely experimental. 73 While there are examples of such mechanisms being put to practical 74 use in deployed applications, there is currently not enough 75 collective implementation experience to determine whether the 76 mechanism defined here is sufficient to fully address the general 77 needs of Atom Publishing Protocol client and server implementations. 78 Implementations and feedback are encouraged. 80 2. Notational Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in BCP 14, [RFC2119]. 86 This specification uses XML Namespaces [W3C.REC-xml-names-20060816] 87 to uniquely identify XML element names. It uses the following 88 namespace prefix for the indicated namespace URI; 90 "f": "http://purl.org/atompub/features/1.0" 92 This specification uses terms from the XML Infoset 93 [W3C.REC-xml-infoset-20040204]. However, this specification uses a 94 shorthand; the phrase "Information Item" is omitted when naming 95 Element Information Items. Therefore, when this specification uses 96 the terms "element" and "attribute" it is referring, respectively, to 97 the Element and Attribute Information Items in Infoset terms. 99 This specification uses the terms "atomUri" and 100 "atomCommonAttributes" from the non-normative RELAX NG Compact schema 101 included in [RFC4287]. Where used, these serve the same purpose and 102 have the same meaning as their use in [RFC4287]. 104 Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also 105 an IRI, so a URI may be used wherever below an IRI is named. There 106 are two special considerations: (1) when an IRI that is not also a 107 URI is given for dereferencing, it MUST be mapped to a URI using the 108 steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as 109 an identifier, it MUST NOT be so mapped. 111 Any element defined by this specification MAY have an xml:base 112 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it 113 serves the function described in section 5.1.1 of [RFC3986], 114 establishing the base URI (or IRI) for resolving any relative 115 references found within the effective scope of the xml:base 116 attribute. 118 Any element defined by this specification MAY have an xml:lang 119 attribute, whose content indicates the natural language for the 120 element and its descendents. The language context is only 121 significant for elements and attributes declared to be "Language- 122 Sensitive". Requirements regarding the content and interpretation of 123 xml:lang are specified in XML 1.0 [W3C.REC-xml-20060816], Section 124 2.12. 126 3. The f:feature element 128 The f:feature element is used in an app:collection element to declare 129 the collection's support for a feature. 131 namespace f = "http://purl.org/atompub/features/1.0" 133 feature = element f:feature { 134 atomCommonAttributes, 135 attribute ref { atomUri }, 136 attribute href { atomUri }?, 137 attribute label { text }?, 138 (anyElement)* 139 } 141 anyElement = element * - f:feature { 142 (attribute * { text } 143 | text 144 | anyElement)* 145 } 147 The ref attribute specifies a globally unique IRI identifying a 148 feature. The value of the ref attribute MUST be compared on a case- 149 sensitive, character-by-character basis. Relative references MUST 150 NOT be used. The IRI is used strictly for identification and cannot 151 be assumed to be dereferenceable. 153 An optional href attribute MAY be used to specify a dereferenceable 154 IRI of a human-readable description of the feature. Relative 155 references MAY be used. 157 The optional label attribute MAY be used to specify a human-readable 158 label for the feature. The value of the label attribute is Language- 159 Sensitive as defined by Section 2 of [RFC4287]. 161 The f:feature element MAY contain a mix of text and any number of 162 child elements and attributes from any XML namespace, with the 163 exception of the f:feature element itself. Such markup is considered 164 to be metadata applicable to the feature identified. Software agents 165 MUST NOT stop processing or signal an error or change their behavior 166 as a result of encountering such markup. 168 An app:collection element MAY contain any number of f:feature 169 elements but MUST NOT contain more than one with the same ref 170 attribute value. The order in which f:feature elements appear within 171 the app:collection element is insignificant. 173 The presence of a f:feature element is an indication that the 174 collection supports the feature identified. The lack of a f:feature 175 element identifying a particular feature indicates that support for 176 that feature is unspecified. This does not mean that the feature is 177 not supported, only that the server has not explicitly declared 178 support. There are no means by which a server can indicate that a 179 given feature is unsupported. 181 3.1. Example 183 The following is an example of a collection using the f:feature 184 element to indicate its support for the app:draft element as defined 185 by [RFC5023]. 187 191 192 My Workspace 193 194 My Atom Collection 195 application/atom+xml;type=entry 196 198 199 200 202 4. The "supportsDraft" Feature 204 The "supportsDraft" feature is used to indicate that a collection 205 supports the use of the app:draft control element as defined by 206 Section 13.1.1 of [RFC5023]. The IRI of the "supportsDraft" feature 207 is: 208 http://purl.org/atompub/features/1.0/supportsDraft 210 5. The "ignoresDraft" Feature 212 The "ignoresDraft" feature is used to indicate that a collection will 213 ignore the use of the app:draft control element as defined by Section 214 13.1.1 of [RFC5023]. The IRI of the "ignoresDraft" feature is: 215 http://purl.org/atompub/features/1.0/ignoresDraft 217 A server MUST NOT declare support for both the "supportsDraft" and 218 "ignoresDraft" features within the a single app:collection element. 220 6. Security Considerations 222 Specific features supported by a collection may introduce security 223 considerations and concerns beyond those discussed by the Atom 224 Publishing Protocol and Atom Syndication Format specifications. 225 Implementors must refer to the specifications and description of each 226 feature to determine the security considerations relevant to each. 228 7. IANA Considerations 230 This specification does not define any actions for IANA. 232 8. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 238 Resource Identifier (URI): Generic Syntax", STD 66, 239 RFC 3986, January 2005. 241 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 242 Identifiers (IRIs)", RFC 3987, January 2005. 244 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 245 Syndication Format", RFC 4287, December 2005. 247 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 248 Protocol", RFC 5023, October 2007. 250 [W3C.REC-xml-20060816] 251 Bray, T., Paoli, J., Yergeau, F., Sperberg-McQueen, C., 252 and E. Maler, "Extensible Markup Language (XML) 1.0 253 (Fourth Edition)", World Wide Web Consortium 254 Recommendation REC-xml-20060816, August 2006, 255 . 257 [W3C.REC-xml-infoset-20040204] 258 Tobin, R. and J. Cowan, "XML Information Set (Second 259 Edition)", World Wide Web Consortium Recommendation REC- 260 xml-infoset-20040204, February 2004, 261 . 263 [W3C.REC-xml-names-20060816] 264 Hollander, D., Tobin, R., Bray, T., and A. Layman, 265 "Namespaces in XML 1.0 (Second Edition)", World Wide Web 266 Consortium Recommendation REC-xml-names-20060816, 267 August 2006, 268 . 270 [W3C.REC-xmlbase-20010627] 271 Marsh, J., "XML Base", World Wide Web Consortium 272 Recommendation REC-xmlbase-20010627, June 2001, 273 . 275 Appendix A. Acknowledgements 277 The author acknowledges the feedback from the other members of the 278 IETF Atom Publishing working group during the development of this 279 specification. 281 Author's Address 283 James M Snell 285 Phone: 286 Email: jasnell@gmail.com 287 URI: http://snellspace.com 289 Full Copyright Statement 291 Copyright (C) The IETF Trust (2007). 293 This document is subject to the rights, licenses and restrictions 294 contained in BCP 78, and except as set forth therein, the authors 295 retain all their rights. 297 This document and the information contained herein are provided on an 298 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 299 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 300 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 301 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 302 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 305 Intellectual Property 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org. 329 Acknowledgment 331 Funding for the RFC Editor function is provided by the IETF 332 Administrative Support Activity (IASA).