Network Working Group C. Divilly
Internet-Draft N. Mehta
Intended status: BCP Oracle Corp.
Expires: November 21, 2009 May 20, 2009
AtomPub Guidelines for Collection Discovery
draft-divilly-atompub-discovery-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 November 21, 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 document recommends best practices for discovering AtomPub
Collection resources as applicable to various content representation
formats.
Divilly & Mehta Expires November 21, 2009 [Page 1]
Internet-Draft AtomPub Collection Discovery May 2009
Editorial Note
To provide feedback on this Internet-Draft, join the atom-protocol
mailing list (http://www.imc.org/atom-protocol/).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.2. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discovering Collections from a Feed Document . . . . . . . . . 3
3. Discovering Service from an HTML Document . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Revision History . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Divilly & Mehta Expires November 21, 2009 [Page 2]
Internet-Draft AtomPub Collection Discovery May 2009
1. Introduction
Atom Publishing Protocol [RFC5023] is used for several applications
that consume and produce an unbounded number of Collection resources.
This document introduces guidelines over existing syntactic
techniques for identifying Collection resources in use from various
Internet content representation formats, including feeds and HTML
type resources.
Previously, AtomPub [RFC5023] has introduced two mechanisms for
collection discovery. However, in the absence of suitable
guidelines, there is no clarity about which mechanism is suited for a
particular purpose. In general, where other Atom or AtomPub syntax
is in use, this document recommends the use of the app:collection
element. Where only a link element may be used, this document
recommends the use of the service link relation.
1.1. Notational Conventions
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.2. Namespace
This specification uses the prefix "atom:" for
"http://www.w3.org/2005/Atom", the namespace name of the Atom
Syndication Format [RFC4287]. The prefix "app:" is used for
"http://www.w3.org/2007/app", the namespace name of the Atom
Publishing Protocol [RFC5023]. These namespace prefixes are not
semantically significant.
2. Discovering Collections from a Feed Document
When an Atom Processor encounters an Atom Feed Document, and the
processor is capable of performing AtomPub operations, then it is
valuable to determine whether that feed is modifiable. Some
processors incorrectly assume that a feed may be modified at the
exact same URI from which it is obtained.
AtomPub Processors need a way to determine whether and where new
entries can be added to a Feed. If a syndicated feed document is
modifiable using AtomPub, then the processor can indeed manipulate
the feed. For this purpose, processors can benefit from Collection
metadata that is present in the feed document.
The alternative is obtaining the feed's service document by following
Divilly & Mehta Expires November 21, 2009 [Page 3]
Internet-Draft AtomPub Collection Discovery May 2009
a link with the relation "service", followed by identifying the
Collection resources in the AtomPub Service Document, followed by
correlating these Collection resources to the feed at hand.
Naturally, this alternative is more complex, resource consuming, and
less likely to succeed in finding the exact Collection resource to be
manipulated.
Moreover, not every feed can be modified, and servers can indicate
this by omitting Collection metadata in such feeds.
Section 8.3.5 of [RFC5023] specifies the Collection metadata that may
occur in syndicated Atom feeds. The presence of an app:collection
element as a child of an atom:feed element signals server's
preparedness to modify a feed. This document therefore recommnds
that if a Feed is backed by a Collection, then the server SHOULD
identify the backing Collection using the app:collection element as a
child of the atom:feed element.
If the href attribute of this app:collection element is identical to
that of the parent atom:feed element's self link relation, then the
processor SHOULD treat the feed to be the Collection feed as defined
in Section 4.2 of [RFC5023].
Example: Writable Collection backing a Feed
Writable Feed
application/atom+xml;type=entry
...
Example: Read-only Collection backing a Feed
Read-only Feed
...
Divilly & Mehta Expires November 21, 2009 [Page 4]
Internet-Draft AtomPub Collection Discovery May 2009
Example: Writable Collection Feed
Collection Feed
...
3. Discovering Service from an HTML Document
When an Atom processor encounters an HTML or XHTML document, and the
processor is capable of performing AtomPub operations, then it is
useful to determine the available AtomPub resources with which it can
interact.
The host format, though, limits the ability to specify metadata
embedded in the content being processed. Therefore, the best
approach for a server is to specify a link with relation "service" to
provide a URI to the AtomPub Service Document that includes all the
metadata corresponding to one or more Collections. The server can
also specify a link with relation "feed" to provide a URI to an Atom
feed with relevant content, which can in turn provide additional
metadata for manipulating AtomPub resources present on that server as
explained in the previous section.
4. Security Considerations
None
5. IANA Considerations
None
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Divilly & Mehta Expires November 21, 2009 [Page 5]
Internet-Draft AtomPub Collection Discovery May 2009
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005.
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
Protocol", RFC 5023, October 2007.
Appendix A. Revision History
00 - Initial Revision, created from
draft-divilly-atompub-hierarchy-00.
Authors' Addresses
Colm Divilly
Oracle Corp.
Email: colm.divilly@oracle.com
URI: http://cdivilly.wordpress.com
Nikunj Mehta
Oracle Corp.
Email: nikunj.mehta@oracle.com
URI: http://o-micron.blogspot.com/
Divilly & Mehta Expires November 21, 2009 [Page 6]