idnits 2.17.1 draft-sayre-atompub-protocol-seek-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 239. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 224. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 22, 2005) is 6761 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) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sayre 3 Internet-Draft October 22, 2005 4 Expires: April 25, 2006 6 Feed Seek for the Atom Publishing Protocol 7 draft-sayre-atompub-protocol-seek-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 April 25, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This memo presents a set of URI parameters used identify segments of 41 an Atom Publishing Protocol feed. It also presents a syntax for 42 declaring the placement of those parameters in a URI. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. The 'app:seek' Attribute . . . . . . . . . . . . . . . . . . . 4 49 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 50 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 51 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 53 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 B. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Intellectual Property and Copyright Statements . . . . . . . . 7 57 1. Introduction 59 When Atom Publishing Protocol [APP-Basic] clients encounter an APP 60 collection, they may require smaller or larger frames of entries than 61 the server provides by default. Most servers provide between 5 and 62 25 entries per Atom Feed Document [AtomFormat]. This frame can be 63 far too large for a bandwidth and resource-constrained device, which 64 might only have room to display two or three titles at a time. This 65 frame can be far too small for a client attempting to sync up with a 66 collection that contains many thousands of members. 68 2. Parameters 70 HTTP URIs [RFC3986] provide a useful mechanism for composing 71 parameterized requests--the query string [RFC2616]. This document 72 outlines four parameters that are generally useful to APP clients, 73 but may not be useful for every APP collection. 75 count: The maximum number of Atom Entries to be included in the 76 response. The field is an integer. 77 offset: The offset at which to begin the sequence of entries that 78 match a given request. The field is an integer. 79 begin: Atom entries in the returned feed have an atom:updated date 80 later in time than the 'begin' date. The field matches the syntax 81 of an Atom Date Construct [AtomFormat]. 82 end: Atom entries in the returned feed have an atom:updated date 83 equal or earlier in time than the 'end' date. The field matches 84 the syntax of an Atom Date Construct [AtomFormat]. 86 None of the parameters are required, and servers could add additional 87 parameters. 89 Example Selection URI (disregard line break) 91 http://example.com/foo?begin=2003-12-13T18:30:02Z\ 92 &end=2003-12-25T18:30:02Z&offset=2&count=4 94 Seek URIs are templated by surrounding the field names in brackets. 95 For example, the 'count' field would appear as '{count}' in a 96 template. 98 An example seek template: 100 http://example.com/app?b={begin}&e={end}&i={offset}&c={count} 102 All parameters are optional, so servers interpret requests with 103 missing parameters using the list below: 105 If no 'end' field is present: The 'end' date is considered to be the 106 updated date of the collection's most recently updated member 107 resource. 108 If no 'begin' field is present: The 'begin' date is considered to be 109 the update date of the collection's least recently updated member 110 resource. 111 If no 'offset' field is present: The 'offset' integer is considered 112 to be 0. 113 If no 'count' field is present: The 'count' integer is determined by 114 the server. 116 3. The 'app:seek' Attribute 118 The "app:seek" attribute can be added to an anchor element contained 119 in a server's XOXO Service Outline [XOXO]. When present, this 120 namespace-qualified attribute provides a template for the 121 parameterized GET requests described by this document. After 122 substitution of the appropriate parameters, the resulting URI 123 reference is interpreted relative to the in-scope base URI. The APP 124 namespace is "http://purl.org/atom/app#". This document refers to it 125 by using the prefix "app", but that prefix is arbitrary. 127 An example Service Outline with an app:seek attribute: 129 155 4. Security Considerations 157 Malicious or buggy clients could mount a Denial-of-Service attack by 158 sending large date ranges or integers as parameter values. 160 5. IANA Considerations 162 None 164 6. Informative References 166 [APP-Basic] 167 Sayre, R., "The Atom Publishing Protocol (Basic)", work- 168 in-progress, October 2005. 170 [AtomFormat] 171 Nottingham, M. and R. Sayre, "The Atom Syndication 172 Format", work-in-progress, August 2005. 174 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 175 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 176 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 178 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 179 Resource Identifier (URI): Generic Syntax", STD 66, 180 RFC 3986, January 2005. 182 [XOXO] Marks, K., Celik, T., Pilgrim, M., and M. Peterson, "XOXO 183 1.0: Extensible Open XHTML Outlines", October 2004. 185 Author's Address 187 Robert Sayre 189 Email: rfsayre@boswijck.com 190 URI: http://boswijck.com 192 Appendix A. Contributors 194 This draft is a variant of the in-progress Atom Publishing Protocol 195 specification from the IETF Atompub WG, and owes a debt to the WG's 196 members. 198 Appendix B. Change History 200 -00: Split from draft-sayre-atompub-protocol-basic-00 / -02 202 Intellectual Property Statement 204 The IETF takes no position regarding the validity or scope of any 205 Intellectual Property Rights or other rights that might be claimed to 206 pertain to the implementation or use of the technology described in 207 this document or the extent to which any license under such rights 208 might or might not be available; nor does it represent that it has 209 made any independent effort to identify any such rights. Information 210 on the procedures with respect to rights in RFC documents can be 211 found in BCP 78 and BCP 79. 213 Copies of IPR disclosures made to the IETF Secretariat and any 214 assurances of licenses to be made available, or the result of an 215 attempt made to obtain a general license or permission for the use of 216 such proprietary rights by implementers or users of this 217 specification can be obtained from the IETF on-line IPR repository at 218 http://www.ietf.org/ipr. 220 The IETF invites any interested party to bring to its attention any 221 copyrights, patents or patent applications, or other proprietary 222 rights that may cover technology that may be required to implement 223 this standard. Please address the information to the IETF at 224 ietf-ipr@ietf.org. 226 The IETF has been notified of intellectual property rights claimed in 227 regard to some or all of the specification contained in this 228 document. For more information consult the online list of claimed 229 rights. 231 Disclaimer of Validity 233 This document and the information contained herein are provided on an 234 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 235 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 236 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 237 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 238 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 239 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 241 Copyright Statement 243 Copyright (C) The Internet Society (2005). This document is subject 244 to the rights, licenses and restrictions contained in BCP 78, and 245 except as set forth therein, the authors retain all their rights. 247 Acknowledgment 249 Funding for the RFC Editor function is currently provided by the 250 Internet Society.