TOC 
Network Working GroupN. Mehta
Internet-DraftOracle Corp.
Intended status: ExperimentalJune 29, 2009
Expires: December 31, 2009 


In-lining Extensions for Atom
draft-mehta-atom-inline-01

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 31, 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 Atom resources.

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 Atom Resources
    2.1.  The "ae:inline" Extension Element
        2.1.1.  The "type" Attribute
        2.1.2.  Empty "ae:inline" Element
3.  Examples
    3.1.  Feed with empty in-line replies feed link
    3.2.  Entry with in-line via feed link
    3.3.  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




 TOC 

1.  Introduction

This document defines an extension for in-line representations of linked Atom resources within the Atom Syndication Format [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.).



 TOC 

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.



 TOC 

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 atomEntry, atomFeed, and atomCommonAttributes, 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.).



 TOC 

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.



 TOC 

2.  In-line Representation of Atom 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 Atom 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.



 TOC 

2.1.  The "ae:inline" Extension Element

The "ae:inline" element contains an approximate representation of the linked resource.


extensionInline =
   element ae:inline {
      atomCommonAttributes,
      atomFeed | atomEntry | empty
   }


 TOC 

2.1.1.  The "type" Attribute

The type attribute on a link element is a hint about the type of representation that is expected to be returned when the value of the href attribute is dereferenced. A processor must be prepared to deal with either Atom document type regardless of the value of the type attribute in the link element.



 TOC 

2.1.2.  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.



 TOC 

3.  Examples



 TOC 

3.1.  Feed with empty in-line replies feed link

The following example demonstrates use of an empty in-lined feed within an atom:link element. The type attribute of link is interpreted as an Atom feed document due to the requirements of the replies link relation.

<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"
      href="http://www.example.org/replies">
      <ae:inline xmlns:ae="http://purl.org/atom/ext/"/>
    </link>
    <link rel="self"
      href="http://www.example.org/entries" />
    ...
</feed>


 TOC 

3.2.  Entry with in-line via feed link

The following example demonstrates use of an in-lined feed within an atom:link element. The type attribute of link is general enough to allow either Atom feed or entry document to be in-lined.

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


 TOC 

3.3.  Entry with in-line up link

The following example demonstrates use of an in-lined entry within an atom:link element. The type attribute of link is specifically limiting the in-lined content to use an Atom entry document.

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


 TOC 

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.



 TOC 

5.  References



 TOC 

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 (TXT, HTML, XML).
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” RFC 3023, January 2001 (TXT).
[RFC3548] Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 3548, July 2003 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
[RFC4288] Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” BCP 13, RFC 4288, December 2005 (TXT).
[W3C.REC-XHTML] Pemberton, S., “XHTML 1.0: The Extensible HyperText Markup Language,” W3C REC-XHTML, January 2000.


 TOC 

5.2. Informative References

[RELAXNG] Clark, J., “RELAX NG Compact Syntax,” December 2001.


 TOC 

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.



 TOC 

Appendix B.  Revision History

00 - Initial Revision, split from draft-divilly-atom-hierarchy-01.

01 - Limited scope of in-lining to Atom.

Removed type attribute from ae:inline as well as support for non-Atom in-lining.

Specified the interpretation of type attribute and the value of ae:inline

Added example for empty inline element



 TOC 

Author's Address

  Nikunj R. Mehta
  Oracle Corp.
Email:  nikunj.mehta@oracle.com
URI:  http://o-micron.blogspot.com/