idnits 2.17.1
draft-wilde-atom-profile-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([7], [8]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 88: '...tics. A profile MUST NOT change the s...'
-- The draft header indicates that this document updates RFC4287, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC4287, updated by this document, for
RFC5378 checks: 2004-07-09)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 26, 2013) is 4016 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Informational RFC: RFC 6906 (ref. '2')
** Obsolete normative reference: RFC 3023 (ref. '4') (Obsoleted by RFC 7303)
-- Obsolete informational reference (is this intentional?): RFC 2616 (ref.
'5') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC
7235)
Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. Wilde
3 Internet-Draft EMC
4 Updates: 4287 (if approved) April 26, 2013
5 Intended status: Standards Track
6 Expires: October 28, 2013
8 Profile Support for the Atom Syndication Format
9 draft-wilde-atom-profile-01
11 Abstract
13 The Atom syndication format is a generic XML format for representing
14 collections. Profiles are one way how Atom feeds can indicate that
15 they support specific extensions. To make this support visible on
16 the media type level, this specification re-registers the Atom media
17 type, and adds a "profile" media type parameter. This allows
18 profiles to become visible at the media type level, so that servers
19 as well as clients can indicate support for specific Atom profiles in
20 conversations, for example when communicating via HTTP.
22 Note to Readers
24 This draft should be discussed on the atom-syntax mailing list [7].
26 Online access to all versions and files is available on github [8].
28 Status of this Memo
30 This Internet-Draft is submitted in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF). Note that other groups may also distribute
35 working documents as Internet-Drafts. The list of current Internet-
36 Drafts is at http://datatracker.ietf.org/drafts/current/.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 This Internet-Draft will expire on October 28, 2013.
45 Copyright Notice
47 Copyright (c) 2013 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (http://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 2.1. Profiles for Alternatives . . . . . . . . . . . . . . . . . 4
65 2.2. Profiles for Specializations . . . . . . . . . . . . . . . 4
66 3. Profile Parameter Definition . . . . . . . . . . . . . . . . . 5
67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
68 4.1. Atom Media Type application/atom+xml . . . . . . . . . . . 5
69 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
70 5.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 7
71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
73 6.2. Non-Normative References . . . . . . . . . . . . . . . . . 8
74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 1. Introduction
79 The Atom Syndication Format "is an XML-based document format that
80 describes lists of related information known as 'feeds'. Feeds are
81 composed of a number of items, known as 'entries', each with an
82 extensible set of attached metadata. For example, each entry has a
83 title." [1]
85 Profiles "can be described as additional semantics that can be used
86 to process a resource representation, such as constraints,
87 conventions, extensions, or any other aspects that do not alter the
88 basic media type semantics. A profile MUST NOT change the semantics
89 of the resource representation when processed without profile
90 knowledge, so that clients both with and without knowledge of a
91 profiled resource can safely use the same representation." [2]
93 Profiles are identified by URI, and their use can be indicated for a
94 representation by adding a link with the registered "profile" link
95 relation type, linking to the profile URI. While this is sufficient
96 to represent the fact that a certain representation is using a
97 profile, it does not make that fact visible outside of this
98 representation. Ideally, peers communicating their media type, for
99 example when communicating via Hypertext Transfer Protocol (HTTP)
100 [5], should be able to indicate the support of certain profiles
101 through the media type identifier itself, without changing the base
102 media type.
104 Because Atom supports generic links through its element,
105 "profile" links can be easily added to a feed, indicating that this
106 feed does adhere to a certain profile. However, on the media type
107 level, this feed would still be labeled as application/atom+xml,
108 making the profile invisible on that level and thus not allowing it
109 to be used in interactions such as content negotiation in HTTP.
111 This specification adds a "profile" media type parameter to the
112 application/atom+xml media type, thereby making it possible for
113 profiles to be exposed at the media type level. Apart from adding
114 that one media type parameter, this specification does not change
115 anything about the Atom format itself, or its media type
116 registration.
118 2. Examples
120 Adding a "profile" parameter to the Atom media type adds visibility
121 of profiles at the media type level, for example when alternative
122 profiles are supported by a service. It might also help to further
123 "specialize" a media type in environments where such a
124 "specialization" is useful. Two examples are intended to illustrate
125 these two scenarios.
127 2.1. Profiles for Alternatives
129 For example, when linking to feeds of media-oriented services, it
130 would be possible to expose two feeds, one using MediaRSS, and the
131 other one using Podcasts. Both formats roughly cover the same
132 functionality as media-oriented feed-based extensions, but by having
133 the ability to expose their capabilities at the media type level,
134 HTTP mechanisms and conversations can be used to distinguish between
135 these formats.
137 In some cases it may be possible to support more than one profile,
138 and then it is up for the service to decide whether these should be
139 exposed in one representation (which can be exposed by linking to
140 multiple profiles from the resource representation and/or in the
141 media type parameter), or whether there should be two
142 representations, one for each profile. This decision will probably
143 depend on implementation complexity, the trade-off between navigation
144 complexity (two representations with one profile each) and processing
145 complexity, and also the size of the profile data, because in
146 particular in the case of overlapping profiles, there might be many
147 redundancies.
149 Thus, which way to go for multiple profiles is not a question that
150 has one correct answer; it depends on the profiles, and on the
151 services that are built around them.
153 2.2. Profiles for Specializations
155 Feed-based services may provide additional features in feeds that are
156 represented using Atom's extension mechanisms. These additional
157 features might be useful only for those clients that support them,
158 and otherwise might add volume to a feed that is of no value to
159 general consumers. In such a scenario, specialized clients might
160 also request their specialized features via profile media type
161 parameters, and will then get the feed being "enriched" with the
162 additional features. If clients do not request such a profile or
163 request one that is not known to the server, the server responds with
164 a generic feed, still allowing them to treat the feed as a generic
165 feed (with no additional features being represented).
167 Whether services respond with profiles by default or only for
168 specific requests about a profile is a matter of policy, and will be
169 influenced by factors such as the added volume when adding profile
170 data, and the question whether profiles should only be exposed to
171 those that specifically ask for them. Since profiles are not allowed
172 to change the semantics of the media type itself, such a decision can
173 depend on the trade-off being a matter of expressivity, and not
174 whether it will break clients under some circumstances.
176 3. Profile Parameter Definition
178 The profile parameter for the application/atom+xml media type allows
179 one or more profile URIs to be specified. These profile URIs have
180 the identifier semantics defined in [2], and when appearing as media
181 type parameter, they have the same semantics as if they had been
182 associated with the resource URI through other means, such as using
183 one or more elements as children of the
184 element.
186 As a general rule, media type parameters must be quoted unless they
187 are tokens. For the "profile" media type parameter defined here,
188 this means that is must be quoted. It contains a non-empty list of
189 space-separated URIs (the profile URIs).
190 profile-param = "profile=" profile-value
191 profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <">
192 profile-URI = URI
194 The "URI" in the above grammar refers to the "URI" as defined in
195 Section 3 of [3]
197 4. IANA Considerations
199 The media type registration for the media type application/atom+xml
200 should be updated according to the following registration.
202 4.1. Atom Media Type application/atom+xml
204 The Internet media type [6] for an Atom document is application/
205 atom+xml.
207 4.1.1. Media Type Name
209 application
211 4.1.2. Subtype Name
213 atom+xml
215 4.1.3. Required Parameters
217 none
219 4.1.4. Optional Parameters
221 charset: This parameter has semantics identical to the charset
222 parameter of the "application/xml" media type as specified in [4].
224 profile: This parameter indicates that one or more profiles are used
225 in the feed, according to the definition of profiles in [2]. The
226 parameter syntax is specified in Section 3 of RFC XXXX
228 4.1.5. Encoding Considerations
230 Identical to those of "application/xml" as described in [4], Section
231 3.2.
233 4.1.6. Security Considerations
235 As defined in [1]. In addition, as this media type uses the "+xml"
236 convention, it shares the same security considerations as described
237 in [4], Section 10.
239 4.1.7. Interoperability Considerations
241 There are no known interoperability issues.
243 4.1.8. Published Specification
245 [1], RFC XXXX
247 4.1.9. Applications which use this media type
249 Many. Atom has become a common foundation for many syndication-
250 oriented scenarios, and also has become a commonly used
251 representation for collection contents.
253 4.1.10. Magic number(s)
255 As specified for "application/xml" in [4], Section 3.2.
257 4.1.11. File extension(s)
259 .atom
261 4.1.12. Fragment Identifiers
263 As specified for "application/xml" in [4], Section 5.
265 4.1.13. Base URI
267 As specified in [4], Section 6.
269 4.1.14. Macintosh File Type Code(s)
271 TEXT
273 4.1.15. Person & email address to contact for further information
275 Mark Nottingham and Erik Wilde
277 4.1.16. Intended Usage
279 Common
281 4.1.17. Author/Change Controller
283 IESG
285 5. Change Log
287 Note to RFC Editor: Please remove this section before publication.
289 5.1. From -00 to -01
291 o Fixed typos.
293 o Removed the requirement to percent-encode URIs in the profile
294 parameter.
296 o Added example for media type specialization.
298 6. References
300 6.1. Normative References
302 [1] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
303 Format", RFC 4287, December 2005.
305 [2] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
306 March 2013.
308 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
309 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
310 January 2005.
312 [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
313 RFC 3023, January 2001.
315 6.2. Non-Normative References
317 [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
318 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
319 HTTP/1.1", RFC 2616, June 1999.
321 [6] Freed, N., Klensin, J., and T. Hansen, "Media Type
322 Specifications and Registration Procedures", BCP 13, RFC 6838,
323 January 2013.
325 URIs
327 [7]
329 [8]
331 Appendix A. Acknowledgements
333 Thanks for comments and suggestions provided by Markus Lanthaler.
335 Author's Address
337 Erik Wilde
338 EMC
339 6801 Koll Center Parkway
340 Pleasanton, CA 94566
341 U.S.A.
343 Phone: +1-925-6006244
344 Email: erik.wilde@emc.com
345 URI: http://dret.net/netdret/