Network Working Group N. Mehta Internet-Draft Oracle Corp. Intended status: Experimental June 9, 2009 Expires: December 11, 2009 In-lining Extensions for Atom draft-mehta-atom-inline-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 11, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This specification defines mechanisms for in-lining representations of linked resources in Atom documents. Mehta Expires December 11, 2009 [Page 1] Internet-Draft Atom In-line Extensions June 2009 Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. In-line Representation of Resources . . . . . . . . . . . . . . 3 2.1. The "ae:inline" Extension Element . . . . . . . . . . . . . 4 2.1.1. Empty "ae:inline" Element . . . . . . . . . . . . . . . 5 2.1.2. The "type" Attribute . . . . . . . . . . . . . . . . . 6 2.1.3. Processing Model . . . . . . . . . . . . . . . . . . . 6 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Feed with in-line replies link . . . . . . . . . . . . . . 7 3.2. Entry with in-line up link . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 Appendix B. Revision History . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Mehta Expires December 11, 2009 [Page 2] Internet-Draft Atom In-line Extensions June 2009 1. Introduction This document defines an extension for in-line representations of linked resources within the Atom Syndication Format [RFC4287]. Such in-line representations can be either text, binary, or well-formed XML. 1.1. Namespace The XML Namespaces URI for the XML data format described in this specification is: http://purl.org/atom/ext/ This specification uses the prefix "ae:" for the namespace name. The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the namespace name of the Atom Syndication Format [RFC4287]. These namespace prefixes are not semantically significant. 1.2. Notational Conventions Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAXNG]. In those sections, this specification uses the xhtmlDiv, atomCommonAttributes, atomMediaType and anyElement, defined in [RFC4287]. However, the text of this specification provides the definition of conformance. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Terminology This specification uses Atom link relations to identify different types of links; see the Atom specification [RFC4287] for information about their syntax, and the IANA link relation registry for more information about specific values. 2. In-line Representation of Resources Some applications require the ability to pre-fetch resources linked from an Atom document using the atom:link element [RFC4287]. Such in-line representations are similar to the in-line content model of Atom. Mehta Expires December 11, 2009 [Page 3] Internet-Draft Atom In-line Extensions June 2009 An Atom document MAY include the in-line representation of a linked resource by using the ae:inline element inside the corresponding atom:link element. The in-lined representation is only a hint and MAY differ from the representation obtained from the URI referenced in the link. Atom Processors SHOULD use the link URI to obtain the complete representation of the linked resource. 2.1. The "ae:inline" Extension Element The "ae:inline" element contains an approximate representation of the linked resource. Mehta Expires December 11, 2009 [Page 4] Internet-Draft Atom In-line Extensions June 2009 extensionInlineTextRepresentation = element ae:inline { atomCommonAttributes, attribute type {"text" | "html"}?, (text)* } extensionInlineXHTMLRepresentation = element ae:inline { atomCommonAttributes, attribute type {"xhtml"}, xhtmlDiv } extensionInlineAtomRepresentation = element ae:inline { atomCommonAttributes, attribute type {"feed" | "entry"}, atomFeed | atomEntry } extensionInlineOtherRepresentation = element ae:inline { atomCommonAttributes, attribute type { atomMediaType }?, (text|anyElement)* } extensionInlineEmpty = element ae:inline { atomCommonAttributes, empty } extensionInline = extensionInlineTextRepresentation | extensionInlineXHTMLRepresentation | extensionInlineAtomRepresentation | extensionInlineOtherRepresentation | extensionInlineEmpty 2.1.1. Empty "ae:inline" Element The ae:inline element may be empty if the producer of the Atom document a linked resource cannot be in-lined, e.g., due to inadequate authorization or if the resource does not yet exist. Mehta Expires December 11, 2009 [Page 5] Internet-Draft Atom In-line Extensions June 2009 2.1.2. The "type" Attribute On the ae:inline element, the value of the "type" attribute MAY be one of "text", "html", "xhtml", "entry", or "feed". Failing that, it MUST conform to the syntax of a MIME media type, but MUST NOT be a composite type (see Section 4.2.6 of [RFC4288]). If the type attribute is not provided, Atom Processors MUST behave as though the type attribute were present with a value of "text". The type attributes on an atom:link element and its nested ae:inline element may not match. 2.1.3. Processing Model Use of the in-line extensions MUST conform to the following rules. Conforming Atom Processors MUST interpret ae:inline according to the first applicable rule: 1. If the value of "type" is "text", the content of ae:inline MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, Atom Processors MAY collapse white space (including line breaks), and display the text using typographic techniques such as justification and proportional fonts. 2. If the value of "type" is "html", the content of ae:inline MUST NOT contain child elements and SHOULD be suitable for handling as HTML [HTML]. The HTML markup MUST be escaped; for example, "
" as "<br>". The HTML markup SHOULD be such that it could validly appear directly within an HTML
element. Atom Processors that display the content MAY use the markup to aid in displaying it. 3. If the value of "type" is "xhtml", the content of ae:inline MUST be a single XHTML div element [W3C.REC-XHTML] and SHOULD be suitable for handling as XHTML. The XHTML div element itself MUST NOT be considered part of the content. Atom Processors that display the content MAY use the markup to aid in displaying it. The escaped versions of characters such as "&" and ">" represent those characters, not markup. 4. If the value of "type" is "entry", the content of atom:content MUST be a single ATOM entry element [RFC4287]. 5. If the value of "type" is "feed", the content of atom:content MUST be a single ATOM feed element [RFC4287]. 6. If the value of "type" is an XML media type [RFC3023] or ends with "+xml" or "/xml" (case insensitive), the content of ae: inline MAY include child elements and SHOULD be suitable for handling as the indicated media type. This would normally mean that the "ae:inline" element would contain a single child element that would serve as the root element of the XML document of the indicated type. Mehta Expires December 11, 2009 [Page 6] Internet-Draft Atom In-line Extensions June 2009 7. If the value of "type" begins with "text/" (case insensitive), the content of ae:inline MUST NOT contain child elements. 8. For all other values of "type", the content of atom:content MUST be a valid Base64 encoding, as described in [RFC3548], section 3. When decoded, it SHOULD be suitable for handling as the indicated media type. In this case, the characters in the Base64 encoding MAY be preceded and followed in the atom:content element by white space, and lines are separated by a single newline (U+000A) character. 3. Examples 3.1. Feed with in-line replies link http://www.example.org/entries My posts 2006-03-01T12:12:12Z ... ... Mehta Expires December 11, 2009 [Page 7] Internet-Draft Atom In-line Extensions June 2009 3.2. Entry with in-line up link ... ... 4. Security Considerations In-line Extensions for Atom are subject to the security considerations found in Section 8 of [RFC4287]. In-line representations can overwhelm Atom processors. For this reason, consumers of Atom representations should take adequate precautions to limit resource consumption when processing ae:inline elements. 5. References 5.1. Normative References [HTML] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Specification, W3C REC REC-html401-19991224", December 1999, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, Mehta Expires December 11, 2009 [Page 8] Internet-Draft Atom In-line Extensions June 2009 RFC 3986, January 2005. [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [W3C.REC-XHTML] Pemberton, S., "XHTML 1.0: The Extensible HyperText Markup Language", W3C REC-XHTML, January 2000, . 5.2. Informative References [RELAXNG] Clark, J., "RELAX NG Compact Syntax", December 2001, . URIs [1] Appendix A. Acknowledgements On the atom-syntax mailing list, Hadrien Gardeur, Al Brown, Julian Reschke, Mark Nottingham, Pablo Castro, Kyle Marvin, and James Snell provided very valuable feedback to solidify this draft. Appendix B. Revision History 00 - Initial Revision, split from draft-divilly-atom-hierarchy-01. Author's Address Nikunj R. Mehta Oracle Corp. Email: nikunj.mehta@oracle.com URI: http://o-micron.blogspot.com/ Mehta Expires December 11, 2009 [Page 9]