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/