idnits 2.17.1 draft-wilde-atom-profile-03.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 95: '...tics. A profile MUST NOT change the s...' RFC 2119 keyword, line 211: '... 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 (January 22, 2014) is 3746 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3023' is defined on line 335, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-05) exists of draft-lanthaler-profile-registry-02 -- 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 (~~), 3 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) January 22, 2014 5 Intended status: Informational 6 Expires: July 26, 2014 8 Profile Support for the Atom Syndication Format 9 draft-wilde-atom-profile-03 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 July 26, 2014. 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 5. Implementation Status . . . . . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . . 7 76 8.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 7 77 8.3. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 8 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 The Atom Syndication Format "is an XML-based document format that 87 describes lists of related information known as 'feeds'. Feeds are 88 composed of a number of items, known as 'entries', each with an 89 extensible set of attached metadata. For example, each entry has a 90 title." [RFC4287] 92 Profiles "can be described as additional semantics that can be used 93 to process a resource representation, such as constraints, 94 conventions, extensions, or any other aspects that do not alter the 95 basic media type semantics. A profile MUST NOT change the semantics 96 of the resource representation when processed without profile 97 knowledge, so that clients both with and without knowledge of a 98 profiled resource can safely use the same representation." [RFC6906] 100 Profiles are identified by URI, and their use can be indicated for a 101 representation by adding a link with the registered "profile" link 102 relation type, linking to the profile URI. While this is sufficient 103 to represent the fact that a certain representation is using a 104 profile, it does not make that fact visible outside of this 105 representation. Ideally, peers communicating their media type, for 106 example when communicating via Hypertext Transfer Protocol (HTTP) 107 [RFC2616], should be able to indicate the support of certain profiles 108 through the media type identifier itself, without changing the base 109 media type. 111 Because Atom supports generic links through its element, 112 "profile" links can be easily added to a feed, indicating that this 113 feed does adhere to a certain profile. However, on the media type 114 level, this feed would still be labeled as application/atom+xml, 115 making the profile invisible on that level and thus not allowing it 116 to be used in interactions such as content negotiation in HTTP. 118 This specification adds a "profile" media type parameter to the 119 application/atom+xml media type, thereby making it possible for 120 profiles to be exposed at the media type level. Apart from adding 121 that one media type parameter, this specification does not change 122 anything about the Atom format itself, or its media type 123 registration. 125 2. Examples 127 Adding a "profile" parameter to the Atom media type adds visibility 128 of profiles at the media type level, for example when alternative 129 profiles are supported by a service. It might also help to further 130 "specialize" a media type in environments where such a 131 "specialization" is useful. Two examples are intended to illustrate 132 these two scenarios. 134 2.1. Profiles for Alternatives 136 For example, when linking to feeds of media-oriented services, it 137 would be possible to expose two feeds, one using MediaRSS, and the 138 other one using Podcasts. Both formats roughly cover the same 139 functionality as media-oriented feed-based extensions, but by having 140 the ability to expose their capabilities at the media type level, 141 HTTP mechanisms and conversations can be used to distinguish between 142 these formats. 144 In some cases it may be possible to support more than one profile, 145 and then it is up for the service to decide whether these should be 146 exposed in one representation (which can be exposed by linking to 147 multiple profiles from the resource representation and/or in the 148 media type parameter), or whether there should be two 149 representations, one for each profile. This decision will probably 150 depend on implementation complexity, the trade-off between navigation 151 complexity (two representations with one profile each) and processing 152 complexity, and also the size of the profile data, because in 153 particular in the case of overlapping profiles, there might be many 154 redundancies. 156 Thus, which way to go for multiple profiles is not a question that 157 has one correct answer; it depends on the profiles, and on the 158 services that are built around them. 160 2.2. Profiles for Specializations 162 Feed-based services may provide additional features in feeds that are 163 represented using Atom's extension mechanisms. These additional 164 features might be useful only for those clients that support them, 165 and otherwise might add volume to a feed that is of no value to 166 general consumers. In such a scenario, specialized clients might 167 also request their specialized features via profile media type 168 parameters, and will then get the feed being "enriched" with the 169 additional features. If clients do not request such a profile or 170 request one that is not known to the server, the server responds with 171 a generic feed, still allowing them to treat the feed as a generic 172 feed (with no additional features being represented). 174 Whether services respond with profiles by default or only for 175 specific requests about a profile is a matter of policy, and will be 176 influenced by factors such as the added volume when adding profile 177 data, and the question whether profiles should only be exposed to 178 those that specifically ask for them. Since profiles are not allowed 179 to change the semantics of the media type itself, such a decision can 180 depend on the trade-off being a matter of expressivity, and not 181 whether it will break clients under some circumstances. 183 2.3. Profile URI for AtomPub 185 The Atom Publishing Protocol (AtomPub) [RFC5023] builds on Atom and 186 defines additional interactions with feeds, such as the ability to 187 POST an entry to a collection URI as a request to create a new entry 188 in that collection. AtomPub uses Atom's media type for representing 189 feeds and entries (and introduces its own media type for representing 190 category and service documents, but these are not relevant for this 191 discussion). 193 When requesting a collection URI from an AtomPub server, clients will 194 GET a feed document with no indication that the server supports 195 AtomPub. Clients are supposed to have knowledge about AtomPub 196 support, so that they know whether POST requests to the collection 197 URI might succeed. It is possible that clients send an OPTIONS 198 request to the collection URI to find out about the allowed methods, 199 but this requires an additional roundtrip, and since the AtomPub spec 200 does not explicitly mention OPTIONS, it may be the case that 201 implementations do not generally support this discovery mechanism. 203 To make AtomPub support of a collection explicit in a feed document, 204 the profile URI urn:ietf:rfc:5023 is suggested. When including this 205 profile URI in a feed, a server indicates AtomPub support: 206 207 208 210 When used with the profile parameter of the Atom media type, this 211 profile URI MAY be used to indicate that the resource is advertising 212 AtomPub support. It should be noted that AtomPub servers are not 213 required to use the AtomPub profile URI in any way (because it is not 214 a part of the AtomPub specification), but that supporting it may make 215 it easier for clients to discover the AtomPub capabilities of 216 available resources. 218 3. Profile Parameter Definition 220 The profile parameter for the application/atom+xml media type allows 221 one or more profile URIs to be specified. These profile URIs have 222 the identifier semantics defined in [RFC6906], and when appearing as 223 media type parameter, they have the same semantics as if they had 224 been associated with the resource URI through other means, such as 225 using one or more elements as children of 226 the element. 228 As a general rule, media type parameters must be quoted unless they 229 are tokens. For the "profile" media type parameter defined here, 230 this means that is must be quoted. It contains a non-empty list of 231 space-separated URIs (the profile URIs). 232 profile-param = "profile=" profile-value 233 profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <"> 234 profile-URI = URI 236 The "URI" in the above grammar refers to the "URI" as defined in 237 Section 3 of [RFC3986] 239 4. IANA Considerations 241 This specification updates an existing media type according to the 242 registry mechanism described in [RFC6838]. 244 4.1. Atom Media Type application/atom+xml 246 The Internet media type for Atom (application/atom+xml) should be 247 updated by adding the following optional media type parameter: 249 4.1.1. Optional Parameters 251 profile: This parameter indicates that one or more profiles are used 252 in the feed, according to the definition of profiles in [RFC6906]. 253 The parameter syntax is specified in Section 3 of RFC XXXX 255 5. Implementation Status 257 Note to RFC Editor: Please remove this section before publication. 259 This section records the status of known implementations of the 260 protocol defined by this specification at the time of posting of this 261 Internet-Draft, and is based on a proposal described in RFC 6982 262 [RFC6982]. The description of implementations in this section is 263 intended to assist the IETF in its decision processes in progressing 264 drafts to RFCs. Please note that the listing of any individual 265 implementation here does not imply endorsement by the IETF. 266 Furthermore, no effort has been spent to verify the information 267 presented here that was supplied by IETF contributors. This is not 268 intended as, and must not be construed to be, a catalog of available 269 implementations or their features. Readers are advised to note that 270 other implementations may exist. 272 According to RFC 6982, "this will allow reviewers and working groups 273 to assign due consideration to documents that have the benefit of 274 running code, which may serve as evidence of valuable experimentation 275 and feedback that have made the implemented protocols more mature. 276 It is up to the individual working groups to use this information as 277 they see fit". 279 ... 281 6. Security Considerations 283 There are no known security considerations for adding this optional 284 media type parameter to the application/atom+xml media type. 286 7. Open Issues 288 Note to RFC Editor: Please remove this section before publication. 290 o Monitor how the proposal for a "Profile URI Registry" 291 [I-D.lanthaler-profile-registry] is coming along. If it is 292 successful, then the proposed AtomPub Profile URI Section 2.3 293 should be included in the IANA Considerations Section 4. 295 8. Change Log 297 Note to RFC Editor: Please remove this section before publication. 299 8.1. From -02 to -03 301 o Updated author address. 303 8.2. From -01 to -02 305 o Added "Implementation Status" section (Section 5)." 307 o Added example and suggested URI for an AtomPub Profile 308 (Section 2.3) 310 o Changed IANA section to only request adding a "profile" media type 311 parameter (instead of providing a complete media type registration 312 template). 314 o Added "Open Issues" section (Section 7) and reminder to check the 315 progress of the "Profile URI Registry" draft. 317 o Updating "Implementation Status" section to refer to RFC 6982 318 [RFC6982]. 320 o Adding "Security Considerations" section (Section 6) 322 8.3. From -00 to -01 324 o Fixed typos. 326 o Removed the requirement to percent-encode URIs in the profile 327 parameter. 329 o Added example for media type specialization. 331 9. References 333 9.1. Normative References 335 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 336 Types", RFC 3023, January 2001. 338 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 339 Resource Identifier (URI): Generic Syntax", STD 66, 340 RFC 3986, January 2005. 342 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 343 Syndication Format", RFC 4287, December 2005. 345 [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, 346 March 2013. 348 9.2. Informative References 350 [I-D.lanthaler-profile-registry] 351 Lanthaler, M., "The IETF Profile URI Registry", 352 draft-lanthaler-profile-registry-02 (work in progress), 353 June 2013. 355 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 356 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 357 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 359 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 360 Protocol", RFC 5023, October 2007. 362 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 363 Specifications and Registration Procedures", BCP 13, 364 RFC 6838, January 2013. 366 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 367 Code: The Implementation Status Section", RFC 6982, 368 July 2013. 370 URIs 372 [1] 374 [2] 376 Appendix A. Acknowledgements 378 Thanks for comments and suggestions provided by Markus Lanthaler and 379 Peter Rushforth. 381 Author's Address 383 Erik Wilde 384 UC Berkeley 386 Email: dret@berkeley.edu 387 URI: http://dret.net/netdret/