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 12, 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.

Editorial Note

To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/).

Table of Contents

1.  Introduction
    1.1.  Namespace
    1.2.  Notational Conventions
    1.3.  Terminology
2.  In-line Representation of Resources
    2.1.  The "ae:inline" Extension Element
        2.1.1.  Empty "ae:inline" Element
        2.1.2.  The "type" Attribute
        2.1.3.  Processing Model
3.  Examples
    3.1.  Feed with in-line replies link
    3.2.  Entry with in-line up link
4.  Security Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Revision History
§  Author's Address

1.  Introduction

This document defines an extension for in-line representations of linked resources within the Atom Syndication Format [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.). 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] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.). 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] (Clark, J., “RELAX NG Compact Syntax,” December 2001.). In those sections, this specification uses the xhtmlDiv, atomCommonAttributes, atomMediaType and anyElement, defined in [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

1.3.  Terminology

This specification uses Atom link relations to identify different types of links; see the Atom specification [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) 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] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.). Such in-line representations are similar to the in-line content model of Atom.

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.

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.

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] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.)). 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] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification, W3C REC REC-html401-19991224,” December 1999.). The HTML markup MUST be escaped; for example, "<br>" as "&lt;br>". The HTML markup SHOULD be such that it could validly appear directly within an HTML <DIV> 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] (Pemberton, S., “XHTML 1.0: The Extensible HyperText Markup Language,” January 2000.) 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] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.).
5. If the value of "type" is "feed", the content of atom:content MUST be a single ATOM feed element [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.).
6. If the value of "type" is an XML media type [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) 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.
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] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.), 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

<feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
    <id>http://www.example.org/entries</id>
    <title>My posts</title>
    <updated>2006-03-01T12:12:12Z</updated>
    <link rel="replies" thr:count="10"
      href="http://www.example.org/replies">
      <ae:inline xmlns:ae="http://purl.org/atom/ext/"
        type="feed">
        <feed>
        ...
        </feed>
      </ae:inline>
    </link>
    <link rel="self"
      href="http://www.example.org/entries" />
    ...
</feed>

3.2.  Entry with in-line up link

<entry xmlns="http://www.w3.org/2005/Atom">
  <link rel="up" type="application/atom+xml"
    href="/finance/feeds/default/portfolios/1">
    <ae:inline type="entry">
      <atom:entry>
         ...
      </atom:entry>
    </ae:inline>
  </atom:link>
  <atom:link rel="edit"
     href="/finance/feeds/default/portfolios/1/positions/NASDAQ:ORCL"/>
  ...
</atom:entry>

4.  Security Considerations

In-line Extensions for Atom are subject to the security considerations found in Section 8 of [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.).

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

5.2. Informative References

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