idnits 2.17.1 draft-ietf-atompub-typeparam-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, updated by RFC 4748 on line 190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 180. 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (December 27, 2006) is 6329 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: 'RFC2046' is defined on line 123, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell, Ed. 3 Internet-Draft IBM 4 Expires: June 30, 2007 December 27, 2006 6 The application/atom+xml Type Parameter 7 draft-ietf-atompub-typeparam-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 June 30, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2006). 38 Abstract 40 The Atom Syndication Format (RFC 4287) defines the 'application/ 41 atom+xml' media type to identify both Atom Feed and Atom Entry 42 Documents. This document defines an optional 'type' parameter used 43 to differentiate the two types of Atom documents. 45 Editorial Note 47 To provide feedback on this Internet-Draft, join the atom-protocol 48 mailing list (http://www.imc.org/atom-protocol/index.html) [1]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 54 3. The 'type' parameter . . . . . . . . . . . . . . . . . . . . . 3 55 4. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 59 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 4 60 Appendix B. Revision History . . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 Intellectual Property and Copyright Statements . . . . . . . . . . 6 64 1. Introduction 66 The Atom Syndication Format [RFC4287] defines two types of documents 67 that can be identified using the 'application/atom+xml' media type. 68 Implementation experience has demonstrated, however, that Atom Feed 69 and Entry Documents can have different processing models and there 70 are situations where they need to be differentiated. 72 2. Notational Conventions 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 3. The 'type' parameter 80 This document defines a new "type" parameter for use with the 81 'application/atom+xml' media type. 82 type = "entry" / "feed" 84 Neither the parameter name nor its value are case sensitive. 86 The value 'entry' indicates that the media type identifies an Atom 87 Entry Document. The root element of the document MUST be atom:entry. 89 The value 'feed' indicates that the media type identifies an Atom 90 Feed Document. The root element of the document MUST be atom:feed. 92 If not specified, the type is assumed to be unspecified, requiring 93 Atom processors to examine the root element to determine the type of 94 Atom document. 96 4. Conformance 98 New specifications MAY require that the type parameter be used to 99 identify the Atom Document type. Producers of Atom Entry Documents 100 SHOULD use the type parameter regardless of whether or not it is 101 required. Producers of Atom Feed Documents MAY use the parameter. 103 Atom processors that do not recognize the 'type' parameter MUST 104 ignore its value and examine the root element to determine the 105 document type. 107 Atom processors that do recognize the parameter SHOULD detect and 108 report inconsistencies between the parameter's value and the actual 109 type of the document's root element. 111 5. IANA Considerations 113 IANA is requested to add a reference to this specification in the 114 'application/atom+xml' media type registration. 116 6. Security Considerations 118 The security considerations discussed in Section 8 of [RFC4287] 119 apply. 121 7. Normative References 123 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 124 Extensions (MIME) Part Two: Media Types", RFC 2046, 125 November 1996. 127 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 128 Requirement Levels", BCP 14, RFC 2119, March 1997. 130 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 131 Syndication Format", RFC 4287, December 2005. 133 [1] 135 Appendix A. Contributors 137 The content and concepts within are a product of the Atom community 138 and the Atompub Working Group. 140 [[anchor9: chairs to compile a contribution list for 1.0 --snell]] 142 Appendix B. Revision History 144 draft-ietf-atompub-typeparam-00: Initial Draft 146 Author's Address 148 James M Snell (editor) 149 IBM 150 285 W Bullard Ave. 151 Fresno, CA 93704 152 US 154 Phone: +1 919 227 3750 155 Email: jasnell@gmail.com 156 URI: http://ibm.com/ 158 Intellectual Property Statement 160 The IETF takes no position regarding the validity or scope of any 161 Intellectual Property Rights or other rights that might be claimed to 162 pertain to the implementation or use of the technology described in 163 this document or the extent to which any license under such rights 164 might or might not be available; nor does it represent that it has 165 made any independent effort to identify any such rights. Information 166 on the procedures with respect to rights in RFC documents can be 167 found in BCP 78 and BCP 79. 169 Copies of IPR disclosures made to the IETF Secretariat and any 170 assurances of licenses to be made available, or the result of an 171 attempt made to obtain a general license or permission for the use of 172 such proprietary rights by implementers or users of this 173 specification can be obtained from the IETF on-line IPR repository at 174 http://www.ietf.org/ipr. 176 The IETF invites any interested party to bring to its attention any 177 copyrights, patents or patent applications, or other proprietary 178 rights that may cover technology that may be required to implement 179 this standard. Please address the information to the IETF at 180 ietf-ipr@ietf.org. 182 Disclaimer of Validity 184 This document and the information contained herein are provided on an 185 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 186 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 187 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 188 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 189 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 190 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 192 Copyright Statement 194 Copyright (C) The IETF Trust (2006). This document is subject to the 195 rights, licenses and restrictions contained in BCP 78, and except as 196 set forth therein, the authors retain all their rights. 198 Acknowledgment 200 Funding for the RFC Editor function is currently provided by the 201 Internet Society.