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