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