idnits 2.17.1 draft-snell-atompub-feature-01.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 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 314. ** 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 (October 10, 2006) is 6405 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) No issues found here. Summary: 4 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 October 10, 2006 4 Expires: April 13, 2007 6 Atom Publishing Protocol Features Extension 7 draft-snell-atompub-feature-01.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 April 13, 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 . . . . . . . . 5 51 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 54 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 attribute label { text }?, 102 (extensionElement*) 103 } 105 The "ref" attribute specifies an IRI that uniquely identifies a 106 feature supported by a collection. The value of the ref attribute 107 MUST be compared on a case-sensitive, character-by-character basis. 108 Relative references MUST NOT be used. 110 A 'required' attribute value of "yes" indicates that clients MUST 111 utilize the identified feature when interacting with the collection. 112 A server MAY reject requests from clients that do not support or use 113 the feature. If not specified, the value is assumed to be "no". 115 An optional 'href' attribute MAY be used to specify the URI of a 116 human-readable description of the feature. 118 The optional 'label' attribute MAY be used to specify a human- 119 readable label for the feature. The value of the 'label' attribute 120 is Language-Sensitive as defined by Section 2 of [RFC4287]. 122 The f:feature element MAY contain child elements and attributes other 123 than those defined in this specification. Such "foreign markup" are 124 considered to be metadata applicable to the feature identified by the 125 f:feature element. Software agents MUST NOT stop processing or 126 signal an error or change their behavior as a result of encountering 127 such foreign markup. 129 An app:collection element MAY contain zero or more f:feature elements 130 but MUST NOT contain more than one with the same ref attribute value. 131 The order in which f:feature elements appears is insignificant. 133 3.1. Example 135 The following is an example of a collection supporting one required 136 and one optional feature. 138 139 140 141 ... 142 145 146 147 151 152 154 156 4. Publishing Controls and the 'f:control' element 158 Publishing Controls are a mechanism provided by the Atom Publishing 159 Protocol to embed metadata within atom:entry elements designed to 160 influence the way a server processes the entry. The pub:control 161 element is provided as a convenient container for this metadata 162 within an atom:entry. The Atom Publishing Protocol does not define a 163 mechanism by which clients can discover which publishing controls a 164 server supports. 166 The presence of a f:control element in an app:collection element is 167 an indication that the collection supports the control and may 168 require that a client wishing to use the endpoint use that control. 169 Controls are identified using permanent, universally unique IRI's. 171 control = element f:control { 172 atomCommonAttributes, 173 attribute ref { atomUri }, 174 attribute required { 'yes' | 'no' }?, 175 attribute href { atomURI }?, 176 attribute label { text }?, 177 (extensionElement*) 178 } 180 The "ref" attribute specifies an IRI that uniquely identifies a 181 control supported by a collection. The value of the ref attribute 182 MUST be compared on a case-sensitive, character-by-character basis. 183 Relative references MUST NOT be used. 185 A 'required' attribute value of "yes" indicates that clients MUST 186 utilize the identified control when interacting with the collection. 187 A server MAY reject requests from clients that do not support or use 188 the control. If not specified, the value is assumed to be "no". 190 An optional 'href' attribute MAY be used to specify the URI of a 191 human-readable description of the control. 193 The optional 'label' attribute MAY be used to specify a human- 194 readable label for the control. The value of the 'label' attribute 195 is Language-Sensitive as defined by Section 2 of [RFC4287]. 197 The f:control element MAY contain child elements and attributes other 198 than those defined in this specification. Such "foreign markup" are 199 considered to be metadata applicable to the control identified by the 200 f:control element. Software agents MUST NOT stop processing or 201 signal an error or change their behavior as a result of encountering 202 such foreign markup. 204 An app:collection element MAY contain zero or more f:control elements 205 but MUST NOT contain more than one with the same ref attribute value. 206 The order in which f:control elements appear is insignificant. 208 4.1. Example 210 The following is an example of a collection supporting one required 211 and one optional control. 213 214 215 216 ... 217 219 221 222 markdown 223 wiki 224 line-breaks 225 226 227 228 229 230 232 An example atom:entry using the listed controls could appear as: 234 235 ... 236 237 yes 238 markdown 239 line-breaks 240 241 ... 242 244 5. Security Considerations 246 Specific features and controls supported by a collection may 247 introduce security considerations and concerns beyond those discussed 248 by the Atom Publishing Protocol and Atom Syndication Format 249 specifications. Implementors must refer to the specifications and 250 description of each feature and control to determine the security 251 considerations relevant to each. 253 6. IANA Considerations 255 This specification does not specify any considerations for IANA. 257 7. References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 263 Syndication Format", RFC 4287, December 2005. 265 [W3C.REC-xml-infoset-20040204] 266 Cowan, J. and R. Tobin, "XML Information Set (Second 267 Edition)", World Wide Web Consortium Recommendation REC- 268 xml-infoset-20040204, February 2004, 269 . 271 [W3C.REC-xml-names-19990114] 272 Layman, A., Bray, T., and D. Hollander, "Namespaces in 273 XML", World Wide Web Consortium Recommendation REC-xml- 274 names-19990114, January 1999, 275 . 277 Appendix A. Acknowledgements 279 The author acknowledges the feedback from Elias Torres, Robert Yates, 280 David Johnson, Byrne Reese, Joe Gregorio and the other members of the 281 IETF Atom Publishing working group during the development of this 282 specification. 284 Author's Address 286 James M Snell 288 Phone: 289 Email: jasnell@gmail.com 290 URI: http://snellspace.com 292 Intellectual Property Statement 294 The IETF takes no position regarding the validity or scope of any 295 Intellectual Property Rights or other rights that might be claimed to 296 pertain to the implementation or use of the technology described in 297 this document or the extent to which any license under such rights 298 might or might not be available; nor does it represent that it has 299 made any independent effort to identify any such rights. Information 300 on the procedures with respect to rights in RFC documents can be 301 found in BCP 78 and BCP 79. 303 Copies of IPR disclosures made to the IETF Secretariat and any 304 assurances of licenses to be made available, or the result of an 305 attempt made to obtain a general license or permission for the use of 306 such proprietary rights by implementers or users of this 307 specification can be obtained from the IETF on-line IPR repository at 308 http://www.ietf.org/ipr. 310 The IETF invites any interested party to bring to its attention any 311 copyrights, patents or patent applications, or other proprietary 312 rights that may cover technology that may be required to implement 313 this standard. Please address the information to the IETF at 314 ietf-ipr@ietf.org. 316 Disclaimer of Validity 318 This document and the information contained herein are provided on an 319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 321 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 322 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 323 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 326 Copyright Statement 328 Copyright (C) The Internet Society (2006). This document is subject 329 to the rights, licenses and restrictions contained in BCP 78, and 330 except as set forth therein, the authors retain all their rights. 332 Acknowledgment 334 Funding for the RFC Editor function is currently provided by the 335 Internet Society.