Network Working Group E. Wilde
Internet-Draft EMC
Updates: 4287 (if approved) March 30, 2013
Intended status: Standards Track
Expires: October 1, 2013
Profile Support for the Atom Syndication Format
draft-wilde-atom-profile-00
Abstract
The Atom syndication format is a generic XML format for representing
collections. Profiles are one way how Atom feeds can indicate that
they support specific extensions. To make this support visible on
the media type level, this specification re-registers the Atom media
type, and adds a "profile" media type parameter. This allows
profiles to become visible at the media type level, so that servers
as well as clients can indicate support for specific Atom profiles in
conversations, for example when communicating via HTTP.
Note to Readers
This draft should be discussed on the atom-syntax mailing list [6].
Online access to all versions and files is available on github [7].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 1, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wilde Expires October 1, 2013 [Page 1]
Internet-Draft Atom Profiles March 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Profile Parameter Definition . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Atom Media Type application/atom+xml . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . . 7
5.2. Non-Normative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Wilde Expires October 1, 2013 [Page 2]
Internet-Draft Atom Profiles March 2013
1. Introduction
The Atom Syndication Format "is an XML-based document format that
describes lists of related information known as 'feeds'. Feeds are
composed of a number of items, known as 'entries', each with an
extensible set of attached metadata. For example, each entry has a
title." [1]
Profiles "can be described as additional semantics that can be used
to process a resource representation, such as constraints,
conventions, extensions, or any other aspects that do not alter the
basic media type semantics. A profile MUST NOT change the semantics
of the resource representation when processed without profile
knowledge, so that clients both with and without knowledge of a
profiled resource can safely use the same representation." [2]
Profiles are identified by URI, and can be added to a representation
by adding a link with the registered "profile" link relation type,
linking to the profile URI. While this is sufficient to represent
the fact that a certain representation is using a profile, it does
not make that fact visible outside of this representation. Ideally,
peers communicating their media type should be able to indicate the
support of certain profiles through the media type itself, without
changing the base media type.
Because Atom supports generic links through its element,
"profile" links can be easily added to a feed, indicating that this
feed does adhere to a certain profile. However, on the media type
level, this feed would still be labeled as application/atom+xml,
making the profile invisible on that level and thus not allowing it
to be used in interactions such as content negotiation in the
Hypertext Transfer Protocol (HTTP). [4].
This specification adds a "profile" parameter to the application/
atom+xml media type, thereby making it possible for profiles to be
exposed at the media type level. Apart from adding that one media
type parameter, this specification does not change anything about the
Atom format itself.
2. Examples
Adding a "profile" parameter to the Atom media type adds visibility
of profiles at the media type level. For example, when linking to
feeds of media-oriented services, it would be possible to expose two
feeds, one using MediaRSS, and the other using Podcasts. Both
formats roughly cover the same functionality as media-oriented feed-
based extensions, but by having the ability to expose their
Wilde Expires October 1, 2013 [Page 3]
Internet-Draft Atom Profiles March 2013
capabilities at the media type level, HTTP mechanisms and
conversations can be used to distinguish between these formats.
In some cases it may be possible to support more than one profile,
and then it is up for the service to decide whether these should be
exposed in one representation (which can be exposed by linking to
multiple profiles from the resource representation and/or in the
media type parameter), or whether there should be two
representations, one for each profile. This decision will probably
depend on implementation complexity, the trade-off between navigation
complexity (two representations with one profile each) and processing
complexity, and also the size of the profile data, because in
particular in the case of overlapping profiles, there might be many
redundacies.
Thus, which way to go for multiple profiles is not a question that as
one correct answer; it depends on the profiles, and on the services
that are built around them.
3. Profile Parameter Definition
The profile parameter for the application/atom+xml media type allows
one or more profile URIs to be specified. These profile URIs have
the identifier semantics defined in [2], and when appearing as media
type parameter, they have the same semantics as if they had been
associated with the resource URI through other means, such as using
one or more element as a child of the
element.
Media type parameters must be quoted unless they are tokens. For the
"profile" media type parameter defined here, this means that is must
be quoted, and contains a non-empty list of space-separated URI-
encoded URIs.
profile-param = "profile=" profile-value
profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <">
profile-URI = percent-encoded-URI
When processing "mprofile" media type parameters, it is therefore
important to apply URI-decoding before processing the URI (such as
comparing it to known profiles). This is particularly important
since profile URIs in Atom content (in
links) will not be URI-encoded, and thus properly encoding and
decoding URIs in these two location is essential to implement correct
processing.
Wilde Expires October 1, 2013 [Page 4]
Internet-Draft Atom Profiles March 2013
4. IANA Considerations
The Internet media type [5] for an Atom document is application/
atom+xml.
4.1. Atom Media Type application/atom+xml
This specification requests the registration of an XML-based media
type for the eXtensible Access Control Markup Language (XACML).
4.1.1. Media Type Name
application
4.1.2. Subtype Name
atom+xml
4.1.3. Required Parameters
none
4.1.4. Optional Parameters
charset: This parameter has semantics identical to the charset
parameter of the "application/xml" media type as specified in [3].
profile: This parameter indicates that one or more profiles are used
in the feed, according to the definition of profiles in [2]. The
parameter syntax is specified in of RFC XXXX (Section 3)
4.1.5. Encoding Considerations
Identical to those of "application/xml" as described in [3], Section
3.2.
4.1.6. Security Considerations
As defined in [1]. In addition, as this media type uses the "+xml"
convention, it shares the same security considerations as described
in [3], Section 10.
4.1.7. Interoperability Considerations
There are no known interoperability issues.
Wilde Expires October 1, 2013 [Page 5]
Internet-Draft Atom Profiles March 2013
4.1.8. Published Specification
[1]
4.1.9. Applications which use this media type
Many. Atom has become a common foundation for many syndication-
oriented scenarios, and also has become a commonly used
representation for collection contents.
4.1.10. Magic number(s)
As specified for "application/xml" in [3], Section 3.2.
4.1.11. File extension(s)
.atom
4.1.12. Fragment Identifiers
As specified for "application/xml" in [3], Section 5.
4.1.13. Base URI
As specified in [3], Section 6.
4.1.14. Macintosh File Type Code(s)
TEXT
4.1.15. Person & email address to contact for further information
Mark Nottingham and Erik Wilde
4.1.16. Intended Usage
Common
4.1.17. Author/Change Controller
IESG
5. References
Wilde Expires October 1, 2013 [Page 6]
Internet-Draft Atom Profiles March 2013
5.1. Normative References
[1] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
Format", RFC 4287, December 2005.
[2] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
March 2013.
[3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
5.2. Non-Normative References
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC 6838,
January 2013.
URIs
[6]
[7]
Author's Address
Erik Wilde
EMC
6801 Koll Center Parkway
Pleasanton, CA 94566
U.S.A.
Phone: +1-925-6006244
Email: erik.wilde@emc.com
URI: http://dret.net/netdret/
Wilde Expires October 1, 2013 [Page 7]