idnits 2.17.1 draft-mehta-atom-inline-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 and authors Copyright Line does not match the current year -- The document date (June 29, 2009) is 5386 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'HTML' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC3023' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC3548' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'RFC4288' is defined on line 257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mehta 3 Internet-Draft Oracle Corp. 4 Intended status: Experimental June 29, 2009 5 Expires: December 31, 2009 7 In-lining Extensions for Atom 8 draft-mehta-atom-inline-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 31, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This specification defines mechanisms for in-lining representations 47 of linked Atom resources. 49 Editorial Note 51 To provide feedback on this Internet-Draft, join the atom-syntax 52 mailing list (http://www.imc.org/atom-syntax/) [1]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3 59 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. In-line Representation of Atom Resources . . . . . . . . . . . 3 61 2.1. The "ae:inline" Extension Element . . . . . . . . . . . . . 4 62 2.1.1. The "type" Attribute . . . . . . . . . . . . . . . . . 4 63 2.1.2. Empty "ae:inline" Element . . . . . . . . . . . . . . . 4 64 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Feed with empty in-line replies feed link . . . . . . . . . 4 66 3.2. Entry with in-line via feed link . . . . . . . . . . . . . 5 67 3.3. Entry with in-line up link . . . . . . . . . . . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 73 Appendix B. Revision History . . . . . . . . . . . . . . . . . . . 7 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 This document defines an extension for in-line representations of 79 linked Atom resources within the Atom Syndication Format [RFC4287]. 81 1.1. Namespace 83 The XML Namespaces URI for the XML data format described in this 84 specification is: 86 http://purl.org/atom/ext/ 88 This specification uses the prefix "ae:" for the namespace name. The 89 prefix "atom:" is used for "http://www.w3.org/2005/Atom", the 90 namespace name of the Atom Syndication Format [RFC4287]. These 91 namespace prefixes are not semantically significant. 93 1.2. Notational Conventions 95 Some sections of this specification are illustrated with fragments of 96 a non-normative RELAX NG Compact schema [RELAXNG]. In those 97 sections, this specification uses the atomEntry, atomFeed, and 98 atomCommonAttributes, defined in [RFC4287]. 100 However, the text of this specification provides the definition of 101 conformance. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 1.3. Terminology 109 This specification uses Atom link relations to identify different 110 types of links; see the Atom specification [RFC4287] for information 111 about their syntax, and the IANA link relation registry for more 112 information about specific values. 114 2. In-line Representation of Atom Resources 116 Some applications require the ability to pre-fetch resources linked 117 from an Atom document using the atom:link element [RFC4287]. Such 118 in-line representations are similar to the in-line content model of 119 Atom. 121 An Atom document MAY include the in-line representation of a linked 122 Atom resource by using the ae:inline element inside the corresponding 123 atom:link element. The in-lined representation is only a hint and 124 MAY differ from the representation obtained from the URI referenced 125 in the link. Atom Processors SHOULD use the link URI to obtain the 126 complete representation of the linked resource. 128 2.1. The "ae:inline" Extension Element 130 The "ae:inline" element contains an approximate representation of the 131 linked resource. 133 extensionInline = 134 element ae:inline { 135 atomCommonAttributes, 136 atomFeed | atomEntry | empty 137 } 139 2.1.1. The "type" Attribute 141 The type attribute on a link element is a hint about the type of 142 representation that is expected to be returned when the value of the 143 href attribute is dereferenced. A processor must be prepared to deal 144 with either Atom document type regardless of the value of the type 145 attribute in the link element. 147 2.1.2. Empty "ae:inline" Element 149 The ae:inline element may be empty if the producer of the Atom 150 document a linked resource cannot be in-lined, e.g., due to 151 inadequate authorization or if the resource does not yet exist. 153 3. Examples 155 3.1. Feed with empty in-line replies feed link 157 The following example demonstrates use of an empty in-lined feed 158 within an atom:link element. The type attribute of link is 159 interpreted as an Atom feed document due to the requirements of the 160 replies link relation. 162 164 http://www.example.org/entries 165 My posts 166 2006-03-01T12:12:12Z 167 169 170 171 173 ... 174 176 3.2. Entry with in-line via feed link 178 The following example demonstrates use of an in-lined feed within an 179 atom:link element. The type attribute of link is general enough to 180 allow either Atom feed or entry document to be in-lined. 182 184 http://www.example.org/entry/1 185 My posts 186 2006-03-01T12:12:12Z 187 189 192 193 ... 194 195 196 197 199 ... 200 202 3.3. Entry with in-line up link 204 The following example demonstrates use of an in-lined entry within an 205 atom:link element. The type attribute of link is specifically 206 limiting the in-lined content to use an Atom entry document. 208 209 211 212 213 ... 214 215 216 217 219 ... 220 222 4. Security Considerations 224 In-line Extensions for Atom are subject to the security 225 considerations found in Section 8 of [RFC4287]. 227 In-line representations can overwhelm Atom processors. For this 228 reason, consumers of Atom representations should take adequate 229 precautions to limit resource consumption when processing ae:inline 230 elements. 232 5. References 234 5.1. Normative References 236 [HTML] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 237 Specification, W3C REC REC-html401-19991224", 238 December 1999, 239 . 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, March 1997. 244 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 245 Types", RFC 3023, January 2001. 247 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 248 Encodings", RFC 3548, July 2003. 250 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 251 Resource Identifier (URI): Generic Syntax", STD 66, 252 RFC 3986, January 2005. 254 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 255 Syndication Format", RFC 4287, December 2005. 257 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 258 Registration Procedures", BCP 13, RFC 4288, December 2005. 260 [W3C.REC-XHTML] 261 Pemberton, S., "XHTML 1.0: The Extensible HyperText Markup 262 Language", W3C REC-XHTML, January 2000, 263 . 265 5.2. Informative References 267 [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, . 271 URIs 273 [1] 275 Appendix A. Acknowledgements 277 On the atom-syntax mailing list, Hadrien Gardeur, Al Brown, Julian 278 Reschke, Mark Nottingham, Pablo Castro, Kyle Marvin, and James Snell 279 provided very valuable feedback to solidify this draft. 281 Appendix B. Revision History 283 00 - Initial Revision, split from draft-divilly-atom-hierarchy-01. 285 01 - Limited scope of in-lining to Atom. 286 Removed type attribute from ae:inline as well as support for non- 287 Atom in-lining. 288 Specified the interpretation of type attribute and the value of 289 ae:inline 290 Added example for empty inline element 292 Author's Address 294 Nikunj R. Mehta 295 Oracle Corp. 297 Email: nikunj.mehta@oracle.com 298 URI: http://o-micron.blogspot.com/