idnits 2.17.1
draft-wilde-atom-profile-04.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 ([2], [1]), 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 97: '...tics. A profile MUST NOT change the s...'
RFC 2119 keyword, line 213: '... profile URI MAY be used to indicate...'
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 (July 23, 2014) is 3564 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC3023' is defined on line 357, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 6982
(Obsoleted by RFC 7942)
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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 UC Berkeley
4 Updates: 4287 (if approved) July 23, 2014
5 Intended status: Informational
6 Expires: January 24, 2015
8 Profile Support for the Atom Syndication Format
9 draft-wilde-atom-profile-04
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 adds an optional "profile"
17 media type parameter to the Atom media type. This allows profiles to
18 become visible at the media type level, so that servers as well as
19 clients can indicate support for specific Atom profiles in
20 conversations, for example when communicating via HTTP. This
21 specification updates RFC 4287 by adding the "profile" media type
22 parameter to the application/atom+xml media type registration.
24 Note to Readers
26 This draft should be discussed on the atom-syntax mailing list [1].
28 Online access to all versions and files is available on github [2].
30 Status of this Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at http://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on January 24, 2015.
47 Copyright Notice
48 Copyright (c) 2014 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
65 2.1. Profiles for Alternatives . . . . . . . . . . . . . . . . . 4
66 2.2. Profiles for Specializations . . . . . . . . . . . . . . . 4
67 2.3. Profile URI for AtomPub . . . . . . . . . . . . . . . . . . 5
68 3. Profile Parameter Definition . . . . . . . . . . . . . . . . . 5
69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
70 4.1. Atom Media Type application/atom+xml . . . . . . . . . . . 6
71 4.2. AtomPub Profile URI . . . . . . . . . . . . . . . . . . . . 6
72 5. Implementation Status . . . . . . . . . . . . . . . . . . . . . 7
73 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
74 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
75 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
76 8.1. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . . 8
77 8.2. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . . 8
78 8.3. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 8
79 8.4. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 8
80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
82 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 9
84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
86 1. Introduction
88 The Atom Syndication Format "is an XML-based document format that
89 describes lists of related information known as 'feeds'. Feeds are
90 composed of a number of items, known as 'entries', each with an
91 extensible set of attached metadata. For example, each entry has a
92 title." [RFC4287]
94 Profiles "can be described as additional semantics that can be used
95 to process a resource representation, such as constraints,
96 conventions, extensions, or any other aspects that do not alter the
97 basic media type semantics. A profile MUST NOT change the semantics
98 of the resource representation when processed without profile
99 knowledge, so that clients both with and without knowledge of a
100 profiled resource can safely use the same representation." [RFC6906]
102 Profiles are identified by URI, and their use can be indicated for a
103 representation by adding a link with the registered "profile" link
104 relation type, linking to the profile URI. While this is sufficient
105 to represent the fact that a certain representation is using a
106 profile, it does not make that fact visible outside of this
107 representation. Ideally, peers communicating their media type, for
108 example when communicating via Hypertext Transfer Protocol (HTTP)
109 [RFC2616], should be able to indicate the support of certain profiles
110 through the media type identifier itself, without changing the base
111 media type.
113 Because Atom supports generic links through its element,
114 "profile" links can be easily added to a feed, indicating that this
115 feed does adhere to a certain profile. However, on the media type
116 level, this feed would still be labeled as application/atom+xml,
117 making the profile invisible on that level and thus not allowing it
118 to be used in interactions such as content negotiation in HTTP.
120 This specification adds a "profile" media type parameter to the
121 application/atom+xml media type, thereby making it possible for
122 profiles to be exposed at the media type level. Apart from adding
123 that one media type parameter, this specification does not change
124 anything about the Atom format itself, or its media type
125 registration.
127 2. Examples
129 Adding a "profile" parameter to the Atom media type adds visibility
130 of profiles at the media type level, for example when alternative
131 profiles are supported by a service. It might also help to further
132 "specialize" a media type in environments where such a
133 "specialization" is useful. Two examples are intended to illustrate
134 these two scenarios.
136 2.1. Profiles for Alternatives
138 For example, when linking to feeds of media-oriented services, it
139 would be possible to expose two feeds, one using MediaRSS, and the
140 other one using Podcasts. Both formats roughly cover the same
141 functionality as media-oriented feed-based extensions, but by having
142 the ability to expose their capabilities at the media type level,
143 HTTP mechanisms and conversations can be used to distinguish between
144 these formats.
146 In some cases it may be possible to support more than one profile,
147 and then it is up for the service to decide whether these should be
148 exposed in one representation (which can be exposed by linking to
149 multiple profiles from the resource representation and/or in the
150 media type parameter), or whether there should be two
151 representations, one for each profile. This decision will probably
152 depend on implementation complexity, the trade-off between navigation
153 complexity (two representations with one profile each) and processing
154 complexity, and also the size of the profile data, because in
155 particular in the case of overlapping profiles, there might be many
156 redundancies.
158 Thus, which way to go for multiple profiles is not a question that
159 has one correct answer; it depends on the profiles, and on the
160 services that are built around them.
162 2.2. Profiles for Specializations
164 Feed-based services may provide additional features in feeds that are
165 represented using Atom's extension mechanisms. These additional
166 features might be useful only for those clients that support them,
167 and otherwise might add volume to a feed that is of no value to
168 general consumers. In such a scenario, specialized clients might
169 also request their specialized features via profile media type
170 parameters, and will then get the feed being "enriched" with the
171 additional features. If clients do not request such a profile or
172 request one that is not known to the server, the server responds with
173 a generic feed, still allowing them to treat the feed as a generic
174 feed (with no additional features being represented).
176 Whether services respond with profiles by default or only for
177 specific requests about a profile is a matter of policy, and will be
178 influenced by factors such as the added volume when adding profile
179 data, and the question whether profiles should only be exposed to
180 those that specifically ask for them. Since profiles are not allowed
181 to change the semantics of the media type itself, such a decision can
182 depend on the trade-off being a matter of expressivity, and not
183 whether it will break clients under some circumstances.
185 2.3. Profile URI for AtomPub
187 The Atom Publishing Protocol (AtomPub) [RFC5023] builds on Atom and
188 defines additional interactions with feeds, such as the ability to
189 POST an entry to a collection URI as a request to create a new entry
190 in that collection. AtomPub uses Atom's media type for representing
191 feeds and entries (and introduces its own media type for representing
192 category and service documents, but these are not relevant for this
193 discussion).
195 When requesting a collection URI from an AtomPub server, clients will
196 GET a feed document with no indication that the server supports
197 AtomPub. Clients are supposed to have knowledge about AtomPub
198 support, so that they know whether POST requests to the collection
199 URI might succeed. It is possible that clients send an OPTIONS
200 request to the collection URI to find out about the allowed methods,
201 but this requires an additional roundtrip, and since the AtomPub spec
202 does not explicitly mention OPTIONS, it may be the case that
203 implementations do not generally support this discovery mechanism.
205 To make AtomPub support of a collection explicit in a feed document,
206 the profile URI urn:ietf:rfc:5023 is defined. When including this
207 profile URI in a feed, a server indicates AtomPub support:
208
209
210
212 When used with the profile parameter of the Atom media type, this
213 profile URI MAY be used to indicate that the resource is advertising
214 AtomPub support. It should be noted that AtomPub servers are not
215 required to use the AtomPub profile URI in any way (because it is not
216 a part of the AtomPub specification), but that supporting it may make
217 it easier for clients to discover the AtomPub capabilities of
218 available resources.
220 3. Profile Parameter Definition
222 The profile parameter for the application/atom+xml media type allows
223 one or more profile URIs to be specified. These profile URIs have
224 the identifier semantics defined in [RFC6906], and when appearing as
225 media type parameter, they have the same semantics as if they had
226 been associated with the resource URI through other means, such as
227 using one or more elements as children of
228 the element.
230 As a general rule, media type parameters must be quoted unless they
231 are tokens. For the "profile" media type parameter defined here,
232 this means that is must be quoted. It contains a non-empty list of
233 space-separated URIs (the profile URIs).
234 profile-param = "profile=" profile-value
235 profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <">
236 profile-URI = URI
238 The "URI" in the above grammar refers to the "URI" as defined in
239 Section 3 of [RFC3986]
241 4. IANA Considerations
243 This specification updates an existing media type according to the
244 registry mechanism described in [RFC6838].
246 4.1. Atom Media Type application/atom+xml
248 The Internet media type for Atom (application/atom+xml) should be
249 updated by adding the following optional media type parameter:
251 4.1.1. Optional Parameters
253 profile: This parameter indicates that one or more profiles are used
254 in the feed, according to the definition of profiles in [RFC6906].
255 The parameter syntax is specified in Section 3 of RFC XXXX
257 4.2. AtomPub Profile URI
259 The AtomPub Profile URI urn:ietf:rfc:5023 should be added to the
260 registry of Profile URIs established by [RFC7284]. The registration
261 should use the following information:
263 Profile URI: urn:ietf:rfc:5023
265 Common Name: Atom Publishing Protocol (AtomPub) Profile
267 Description: When using this profile URI for a resource using the
268 application/atom+xml media type, a server indicates AtomPub
269 support.
271 Reference: [RFC5023] and RFC XXXX
273 5. Implementation Status
275 Note to RFC Editor: Please remove this section before publication.
277 This section records the status of known implementations of the
278 protocol defined by this specification at the time of posting of this
279 Internet-Draft, and is based on a proposal described in RFC 6982
280 [RFC6982]. The description of implementations in this section is
281 intended to assist the IETF in its decision processes in progressing
282 drafts to RFCs. Please note that the listing of any individual
283 implementation here does not imply endorsement by the IETF.
284 Furthermore, no effort has been spent to verify the information
285 presented here that was supplied by IETF contributors. This is not
286 intended as, and must not be construed to be, a catalog of available
287 implementations or their features. Readers are advised to note that
288 other implementations may exist.
290 According to RFC 6982, "this will allow reviewers and working groups
291 to assign due consideration to documents that have the benefit of
292 running code, which may serve as evidence of valuable experimentation
293 and feedback that have made the implemented protocols more mature.
294 It is up to the individual working groups to use this information as
295 they see fit".
297 ...
299 6. Security Considerations
301 There are no known security considerations for adding this optional
302 media type parameter to the application/atom+xml media type.
304 7. Open Issues
306 Note to RFC Editor: Please remove this section before publication.
308 o Are there other Atom profile URIs that could be registered as a
309 part of this draft?
311 8. Change Log
313 Note to RFC Editor: Please remove this section before publication.
315 8.1. From -03 to -04
317 o Moved "The Profile URI Registry" from I-D to RFC.
319 o Adding AtomPub Profile registration according to [RFC7284].
321 8.2. From -02 to -03
323 o Updated author address.
325 8.3. From -01 to -02
327 o Added "Implementation Status" section (Section 5)."
329 o Added example and suggested URI for an AtomPub Profile
330 (Section 2.3)
332 o Changed IANA section to only request adding a "profile" media type
333 parameter (instead of providing a complete media type registration
334 template).
336 o Added "Open Issues" section (Section 7) and reminder to check the
337 progress of the "Profile URI Registry" draft.
339 o Updating "Implementation Status" section to refer to RFC 6982
340 [RFC6982].
342 o Adding "Security Considerations" section (Section 6)
344 8.4. From -00 to -01
346 o Fixed typos.
348 o Removed the requirement to percent-encode URIs in the profile
349 parameter.
351 o Added example for media type specialization.
353 9. References
355 9.1. Normative References
357 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
358 Types", RFC 3023, January 2001.
360 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
361 Resource Identifier (URI): Generic Syntax", STD 66,
362 RFC 3986, January 2005.
364 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
365 Syndication Format", RFC 4287, December 2005.
367 [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
368 March 2013.
370 [RFC7284] Lanthaler, M., "The Profile URI Registry", RFC 7284,
371 June 2014.
373 9.2. Informative References
375 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
376 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
377 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
379 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
380 Protocol", RFC 5023, October 2007.
382 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
383 Specifications and Registration Procedures", BCP 13,
384 RFC 6838, January 2013.
386 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
387 Code: The Implementation Status Section", RFC 6982,
388 July 2013.
390 URIs
392 [1]
394 [2]
396 Appendix A. Acknowledgements
398 Thanks for comments and suggestions provided by Markus Lanthaler and
399 Peter Rushforth.
401 Author's Address
403 Erik Wilde
404 UC Berkeley
406 Email: dret@berkeley.edu
407 URI: http://dret.net/netdret/