< draft-wilde-atom-profile-01.txt   draft-wilde-atom-profile-02.txt >
Network Working Group E. Wilde Network Working Group E. Wilde
Internet-Draft EMC Internet-Draft EMC
Updates: 4287 (if approved) April 26, 2013 Updates: 4287 (if approved) July 29, 2013
Intended status: Standards Track Intended status: Informational
Expires: October 28, 2013 Expires: January 30, 2014
Profile Support for the Atom Syndication Format Profile Support for the Atom Syndication Format
draft-wilde-atom-profile-01 draft-wilde-atom-profile-02
Abstract Abstract
The Atom syndication format is a generic XML format for representing The Atom syndication format is a generic XML format for representing
collections. Profiles are one way how Atom feeds can indicate that collections. Profiles are one way how Atom feeds can indicate that
they support specific extensions. To make this support visible on they support specific extensions. To make this support visible on
the media type level, this specification re-registers the Atom media the media type level, this specification adds an optional "profile"
type, and adds a "profile" media type parameter. This allows media type parameter to the Atom media type. This allows profiles to
profiles to become visible at the media type level, so that servers become visible at the media type level, so that servers as well as
as well as clients can indicate support for specific Atom profiles in clients can indicate support for specific Atom profiles in
conversations, for example when communicating via HTTP. conversations, for example when communicating via HTTP. This
specification updates RFC 4287 by adding the "profile" media type
parameter to the application/atom+xml media type registration.
Note to Readers Note to Readers
This draft should be discussed on the atom-syntax mailing list [7]. This draft should be discussed on the atom-syntax mailing list [10].
Online access to all versions and files is available on github [8]. Online access to all versions and files is available on github [11].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2013. This Internet-Draft will expire on January 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 21 skipping to change at page 2, line 23
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Profiles for Alternatives . . . . . . . . . . . . . . . . . 4 2.1. Profiles for Alternatives . . . . . . . . . . . . . . . . . 4
2.2. Profiles for Specializations . . . . . . . . . . . . . . . 4 2.2. Profiles for Specializations . . . . . . . . . . . . . . . 4
2.3. Profile URI for AtomPub . . . . . . . . . . . . . . . . . . 5
3. Profile Parameter Definition . . . . . . . . . . . . . . . . . 5 3. Profile Parameter Definition . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Atom Media Type application/atom+xml . . . . . . . . . . . 5 4.1. Atom Media Type application/atom+xml . . . . . . . . . . . 6
5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Status . . . . . . . . . . . . . . . . . . . . . 6
5.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Non-Normative References . . . . . . . . . . . . . . . . . 8 8.1. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 8.2. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Non-Normative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Atom Syndication Format "is an XML-based document format that The Atom Syndication Format "is an XML-based document format that
describes lists of related information known as 'feeds'. Feeds are describes lists of related information known as 'feeds'. Feeds are
composed of a number of items, known as 'entries', each with an composed of a number of items, known as 'entries', each with an
extensible set of attached metadata. For example, each entry has a extensible set of attached metadata. For example, each entry has a
title." [1] title." [1]
Profiles "can be described as additional semantics that can be used Profiles "can be described as additional semantics that can be used
skipping to change at page 5, line 8 skipping to change at page 5, line 8
Whether services respond with profiles by default or only for Whether services respond with profiles by default or only for
specific requests about a profile is a matter of policy, and will be specific requests about a profile is a matter of policy, and will be
influenced by factors such as the added volume when adding profile influenced by factors such as the added volume when adding profile
data, and the question whether profiles should only be exposed to data, and the question whether profiles should only be exposed to
those that specifically ask for them. Since profiles are not allowed those that specifically ask for them. Since profiles are not allowed
to change the semantics of the media type itself, such a decision can to change the semantics of the media type itself, such a decision can
depend on the trade-off being a matter of expressivity, and not depend on the trade-off being a matter of expressivity, and not
whether it will break clients under some circumstances. whether it will break clients under some circumstances.
2.3. Profile URI for AtomPub
The Atom Publishing Protocol (AtomPub) [6] builds on Atom and defines
additional interactions with feeds, such as the ability to POST an
entry to a collection URI as a request to create a new entry in that
collection. AtomPub uses Atom's media type for representing feeds
and entries (and introduces its own media type for representing
category and service documents, but these are not relevant for this
discussion).
When requesting a collection URI from an AtomPub server, clients will
GET a feed document with no indication that the server supports
AtomPub. Clients are supposed to have knowledge about AtomPub
support, so that they know whether POST requests to the collection
URI might succeed. It is possible that clients send an OPTIONS
request to the collection URI to find out about the allowed methods,
but this requires an additional roundtrip, and since the AtomPub spec
does not explicitly mention OPTIONS, it may be the case that
implementations do not generally support this discovery mechanism.
To make AtomPub support of a collection explicit in a feed document,
the profile URI urn:ietf:rfc:5023 is suggested. When including this
profile URI in a feed, a server indicates AtomPub support:
<?xml version="1.0" ?>
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="profile" href="urn:ietf:rfc:5023">
When used with the profile parameter of the Atom media type, this
profile URI MAY be used to indicate that the resource is advertising
AtomPub support. It should be noted that AtomPub servers are not
required to use the AtomPub profile URI in any way (because it is not
a part of the AtomPub specification), but that supporting it may make
it easier for clients to discover the AtomPub capabilities of
available resources.
3. Profile Parameter Definition 3. Profile Parameter Definition
The profile parameter for the application/atom+xml media type allows The profile parameter for the application/atom+xml media type allows
one or more profile URIs to be specified. These profile URIs have one or more profile URIs to be specified. These profile URIs have
the identifier semantics defined in [2], and when appearing as media the identifier semantics defined in [2], and when appearing as media
type parameter, they have the same semantics as if they had been type parameter, they have the same semantics as if they had been
associated with the resource URI through other means, such as using associated with the resource URI through other means, such as using
one or more <link profile="" href=""/> elements as children of the one or more <link profile="" href=""/> elements as children of the
<feed> element. <feed> element.
skipping to change at page 5, line 31 skipping to change at page 6, line 19
space-separated URIs (the profile URIs). space-separated URIs (the profile URIs).
profile-param = "profile=" profile-value profile-param = "profile=" profile-value
profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <"> profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <">
profile-URI = URI profile-URI = URI
The "URI" in the above grammar refers to the "URI" as defined in The "URI" in the above grammar refers to the "URI" as defined in
Section 3 of [3] Section 3 of [3]
4. IANA Considerations 4. IANA Considerations
The media type registration for the media type application/atom+xml This specification updates an existing media type according to the
should be updated according to the following registration. registry mechanism described in [7].
4.1. Atom Media Type application/atom+xml 4.1. Atom Media Type application/atom+xml
The Internet media type [6] for an Atom document is application/ The Internet media type for Atom (application/atom+xml) should be
atom+xml. updated by adding the following optional media type parameter:
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 4.1.1. Optional Parameters
parameter of the "application/xml" media type as specified in [4].
profile: This parameter indicates that one or more profiles are used profile: This parameter indicates that one or more profiles are used
in the feed, according to the definition of profiles in [2]. The in the feed, according to the definition of profiles in [2]. The
parameter syntax is specified in Section 3 of RFC XXXX parameter syntax is specified in Section 3 of RFC XXXX
4.1.5. Encoding Considerations 5. Implementation Status
Identical to those of "application/xml" as described in [4], 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 [4], Section 10.
4.1.7. Interoperability Considerations
There are no known interoperability issues.
4.1.8. Published Specification
[1], RFC XXXX
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) Note to RFC Editor: Please remove this section before publication.
As specified for "application/xml" in [4], Section 3.2. This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 6982 [8].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
4.1.11. File extension(s) According to RFC 6982, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
.atom ...
4.1.12. Fragment Identifiers 6. Security Considerations
As specified for "application/xml" in [4], Section 5. There are no known security considerations for adding this optional
media type parameter to the application/atom+xml media type.
4.1.13. Base URI 7. Open Issues
As specified in [4], Section 6. Note to RFC Editor: Please remove this section before publication.
4.1.14. Macintosh File Type Code(s) o Monitor how the proposal for a "Profile URI Registry" [9] is
coming along. If it is successful, then the proposed AtomPub
Profile URI Section 2.3 should be included in the IANA
Considerations Section 4.
TEXT 8. Change Log
4.1.15. Person & email address to contact for further information Note to RFC Editor: Please remove this section before publication.
Mark Nottingham <mnot@mnot.net> and Erik Wilde <erik.wilde@emc.com> 8.1. From -01 to -02
4.1.16. Intended Usage o Added "Implementation Status" section (Section 5)."
Common o Added example and suggested URI for an AtomPub Profile
(Section 2.3)
4.1.17. Author/Change Controller o Changed IANA section to only request adding a "profile" media type
parameter (instead of providing a complete media type registration
template).
IESG o Added "Open Issues" section (Section 7) and reminder to check the
progress of the "Profile URI Registry" draft.
5. Change Log o Updating "Implementation Status" section to refer to RFC 6982 [8].
Note to RFC Editor: Please remove this section before publication. o Adding "Security Considerations" section (Section 6)
5.1. From -00 to -01 8.2. From -00 to -01
o Fixed typos. o Fixed typos.
o Removed the requirement to percent-encode URIs in the profile o Removed the requirement to percent-encode URIs in the profile
parameter. parameter.
o Added example for media type specialization. o Added example for media type specialization.
6. References 9. References
6.1. Normative References 9.1. Normative References
[1] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication [1] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
Format", RFC 4287, December 2005. Format", RFC 4287, December 2005.
[2] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, [2] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
March 2013. March 2013.
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005. January 2005.
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
6.2. Non-Normative References 9.2. Non-Normative References
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[6] Freed, N., Klensin, J., and T. Hansen, "Media Type [6] Gregorio, J. and B. de hOra, "The Atom Publishing Protocol",
RFC 5023, October 2007.
[7] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC 6838, Specifications and Registration Procedures", BCP 13, RFC 6838,
January 2013. January 2013.
[8] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code:
The Implementation Status Section", RFC 6982, July 2013.
[9] Lanthaler, M., "The IETF Profile URI Registry",
draft-lanthaler-profile-registry-02 (work in progress),
June 2013.
URIs URIs
[7] <http://www.imc.org/atom-syntax/> [10] <http://www.imc.org/atom-syntax/>
[8] <https://github.com/dret/I-D/tree/master/atom-profile> [11] <https://github.com/dret/I-D/tree/master/atom-profile>
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks for comments and suggestions provided by Markus Lanthaler. Thanks for comments and suggestions provided by Markus Lanthaler and
Peter Rushforth.
Author's Address Author's Address
Erik Wilde Erik Wilde
EMC EMC
6801 Koll Center Parkway 6801 Koll Center Parkway
Pleasanton, CA 94566 Pleasanton, CA 94566
U.S.A. U.S.A.
Phone: +1-925-6006244 Phone: +1-925-6006244
 End of changes. 41 change blocks. 
92 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/