idnits 2.17.1 draft-snell-atompub-feature-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 285. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 27, 2006) is 6420 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) == Unused Reference: 'RFC4287' is defined on line 233, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 3 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 September 27, 2006 4 Expires: March 31, 2007 6 Atom Publishing Protocol Features Extension 7 draft-snell-atompub-feature-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 31, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document introduces extensions to the Atom Publishing Protocol 41 introspection format for expressing metadata about the features 42 supported by an Atom Publishing Protocol server implementation. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 48 3. Feature Introspection and the 'f:feature' element . . . . . . . 3 49 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 4. Publishing Controls and the 'f:control' element . . . . . . . . 4 51 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 54 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 Intellectual Property and Copyright Statements . . . . . . . . . . 9 59 1. Introduction 61 This document introduces extensions for the Atom Publishing Protocol 62 introspection format for expressing metadata about the features 63 supported by an Atom Publishing Protocol server implementation. 65 2. Notational Conventions 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in BCP 14, [RFC2119]. 71 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 72 to uniquely identify XML element names. It uses the following 73 namespace prefix for the indicated namespace URI; 75 "f": "http://purl.org/atompub/features/1.0" 77 This specification uses terms from the XML Infoset [W3C.REC-xml- 78 infoset-20040204]. However, this specification uses a shorthand; the 79 phrase "Information Item" is omitted when naming Element Information 80 Items. Therefore, when this specification uses the terms "element" 81 and "attribute" it is referring, respectively, to the Element and 82 Attribute Information Items in Infoset terms. 84 3. Feature Introspection and the 'f:feature' element 86 A feature is an abstract behavior, function and capability supported 87 by an Atom Publishing Protocol server. Examples of features that 88 might be supported by an APP server include support for a particular 89 set of Atom format extensions, a particular authentication scheme, or 90 a specific set of behaviors. The presence of a f:feature element in 91 an app:collection element is an indication that the collection 92 supports the feature and may require that a client wishing to use the 93 endpoint use that feature. Features are identified using permanent, 94 universally unique IRI's. 96 feature = element f:feature { 97 atomCommonAttributes, 98 attribute ref { atomUri }, 99 attribute required { 'yes' | 'no' }?, 100 attribute href { atomURI }?, 101 (extensionElement*) 102 } 104 The "ref" attribute specifies an IRI that uniquely identifies a 105 feature supported by a collection. The value of the ref attribute 106 MUST be compared on a case-sensitive, character-by-character basis. 107 Relative references MUST NOT be used. 109 A 'required' attribute value of "yes" indicates that clients MUST 110 utilize the identified feature when interacting with the collection. 111 If not specified, the value is assumed to be "no". 113 An optional 'href' attribute MAY be used to specify the URI of a 114 human-readable description of the feature. 116 The f:feature element MAY contain child elements and attributes other 117 than those defined in this specification. Such "foreign markup" are 118 considered to be metadata applicable to the feature identified by the 119 f:feature element. Software agents MUST NOT stop processing or 120 signal an error or change their behavior as a result of encountering 121 such foreign markup. 123 An app:collection element MAY contain zero or more f:feature elements 124 but MUST NOT contain more than one with the same ref attribute value. 126 3.1. Example 128 The following is an example of a collection supporting one required 129 and one optional feature. 131 132 133 134 ... 135 137 139 140 ... 141 142 143 144 145 147 4. Publishing Controls and the 'f:control' element 149 Publishing Controls are a mechanism provided by the Atom Publishing 150 Protocol to embed metadata within atom:entry elements designed to 151 influence the way a server processes the entry. The pub:control 152 element is provided as a convenient container for this metadata 153 within an atom:entry. The Atom Publishing Protocol does not, 154 however, define a mechanism by which clients can discover which 155 publishing controls a server supports. 157 The presence of a f:control element in an app:collection element is 158 an indication that the collection supports the control and may 159 require that a client wishing to use the endpoint use that control. 160 Controls are identified using permanent, universally unique IRI's. 162 control = element f:control { 163 atomCommonAttributes, 164 attribute ref { atomUri }, 165 attribute required { 'yes' | 'no' }?, 166 attribute href { atomURI }?, 167 (extensionElement*) 168 } 170 The "ref" attribute specifies an IRI that uniquely identifies a 171 control supported by a collection. The value of the ref attribute 172 MUST be compared on a case-sensitive, character-by-character basis. 173 Relative references MUST NOT be used. 175 A 'required' attribute value of "yes" indicates that clients MUST 176 utilize the identified control when interacting with the collection. 177 If not specified, the value is assumed to be "no". 179 An optional 'href' attribute MAY be used to specify the URI of a 180 human-readable description of the control. 182 The f:control element MAY contain child elements and attributes other 183 than those defined in this specification. Such "foreign markup" are 184 considered to be metadata applicable to the control identified by the 185 f:control element. Software agents MUST NOT stop processing or 186 signal an error or change their behavior as a result of encountering 187 such foreign markup. 189 An app:collection element MAY contain zero or more f:control elements 190 but MUST NOT contain more than one with the same ref attribute value. 192 4.1. Example 194 The following is an example of a collection supporting one required 195 and one optional control. 197 198 199 200 ... 201 203 205 206 initial 207 accepted 208 rejected 209 210 211 212 213 215 5. Security Considerations 217 Specific features and controls supported by a collection may 218 introduce security considerations and concerns beyond those discussed 219 by the Atom Publishing Protocol and Atom Syndication Format 220 specifications. Implementors must refer to the specifications and 221 description of each feature and control to determine the security 222 considerations relevant to each. 224 6. IANA Considerations 226 This specification does not specify any considerations for IANA. 228 7. References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 233 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 234 Syndication Format", RFC 4287, December 2005. 236 [W3C.REC-xml-infoset-20040204] 237 Cowan, J. and R. Tobin, "XML Information Set (Second 238 Edition)", World Wide Web Consortium Recommendation REC- 239 xml-infoset-20040204, February 2004, 240 . 242 [W3C.REC-xml-names-19990114] 243 Bray, T., Layman, A., and D. Hollander, "Namespaces in 244 XML", World Wide Web Consortium Recommendation REC-xml- 245 names-19990114, January 1999, 246 . 248 Appendix A. Acknowledgements 250 The author acknowledges the feedback from Elias Torres, Robert Yates, 251 David Johnson, Byrne Reese, Joe Gregorio and the other members of the 252 IETF Atom Publishing working group during the development of this 253 specification. 255 Author's Address 257 James M Snell 259 Phone: 260 Email: jasnell@gmail.com 261 URI: http://snellspace.com 263 Intellectual Property Statement 265 The IETF takes no position regarding the validity or scope of any 266 Intellectual Property Rights or other rights that might be claimed to 267 pertain to the implementation or use of the technology described in 268 this document or the extent to which any license under such rights 269 might or might not be available; nor does it represent that it has 270 made any independent effort to identify any such rights. Information 271 on the procedures with respect to rights in RFC documents can be 272 found in BCP 78 and BCP 79. 274 Copies of IPR disclosures made to the IETF Secretariat and any 275 assurances of licenses to be made available, or the result of an 276 attempt made to obtain a general license or permission for the use of 277 such proprietary rights by implementers or users of this 278 specification can be obtained from the IETF on-line IPR repository at 279 http://www.ietf.org/ipr. 281 The IETF invites any interested party to bring to its attention any 282 copyrights, patents or patent applications, or other proprietary 283 rights that may cover technology that may be required to implement 284 this standard. Please address the information to the IETF at 285 ietf-ipr@ietf.org. 287 Disclaimer of Validity 289 This document and the information contained herein are provided on an 290 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 291 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 292 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 293 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 294 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 295 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 297 Copyright Statement 299 Copyright (C) The Internet Society (2006). This document is subject 300 to the rights, licenses and restrictions contained in BCP 78, and 301 except as set forth therein, the authors retain all their rights. 303 Acknowledgment 305 Funding for the RFC Editor function is currently provided by the 306 Internet Society.