idnits 2.17.1 draft-wilde-profile-link-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2012) is 4202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft EMC Corporation 4 Intended status: Informational October 17, 2012 5 Expires: April 20, 2013 7 The 'profile' Link Relation Type 8 draft-wilde-profile-link-04 10 Abstract 12 This specification defines the 'profile' link relation type that 13 allows resource representations to indicate that they are following 14 one or more profiles. A profile is defined to not alter the 15 semantics of the resource representation itself, but to allow clients 16 to learn about additional semantics (constraints, conventions, 17 extensions) that are associated with the resource representation, in 18 addition to those defined by the media type and possibly other 19 mechanisms. 21 Editorial Note (to be removed by RFC Editor) 23 Please discuss this draft on the apps-discuss@ietf.org mailing list. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 20, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Profiles and Media Types . . . . . . . . . . . . . . . . . 5 63 3.2. Profile Context . . . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. hCard . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Podcasts . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.1. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . . 8 72 7.2. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . . 8 73 7.3. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 8 74 7.4. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 One of the foundations of the Internet and Web Architecture is the 84 fact that resource representations communicated through protocols 85 such as SMTP or HTTP are labeled with a 'media type', which allows a 86 client to understand at run time what 'type' of resource 87 representation it is handling. Sometimes, it would be useful for 88 servers and clients to include additional information about the 89 nature of the resource, so that a client understanding this 90 additional information could react in a way specific to that 91 specialization of the resource, where the specialization can be about 92 constraints, conventions, extensions, or any other aspects that do 93 not alter the basic media type semantics. HTML 4 [HTML401] has such 94 a mechanism built into the language, which is the 'profile' attribute 95 of the 'head' element. This mechanism, however, is specific to HTML 96 alone, and at the time of writing it seems as if HTML 5 will drop 97 support for this mechanism entirely. 99 RFC 5988 [RFC5988] "defines a framework for typed links that is not 100 specific to a particular serialization or application. It does so by 101 redefining the link relation registry established by Atom to have a 102 broader domain, and adding to it the relations that are defined by 103 HTML." 105 This specification registers a 'profile' link relation type according 106 to the rules of RFC 5988 [RFC5988]. This link relation type is 107 independent of the context in which it is used (however, the 108 representation must support typed links for this mechanism to work) 109 and does not constrain in any way the target of the linked URI. In 110 fact, for the purpose of this specification, the target URI does not 111 necessarily have to identify a dereferencable resource (or even use a 112 dereferencable URI scheme), and clients can treat the occurrence of a 113 specific URI in the same way as an XML namespace URI and invoke 114 specific behavior based on the assumption that a specific profile 115 target URI signals that a resource representation follows a specific 116 profile. Note that at the same time, it is possible for profile 117 target URIs to use dereferencable URIs and use a representation 118 (which is outside the scope of this specification) which represents 119 the information about the profile in a human- or machine-readable 120 way. 122 As one example, consider the case of podcasts, a specific kind of 123 feed using additional fields for media-related metadata. Using a 124 'profile' link, it would be easily possible for clients to understand 125 that a specific feed is supposed to be a podcast feed, and that it 126 may contain entries using podcast-specific fields. This may allow a 127 client to behave differently when handling such a feed (such as 128 rendering a podcast-specific UI), even when the current set of 129 entries in the feed may not contain any podcast entries. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 3. Profiles 139 The concept of a profile has no strict definition on the Internet or 140 on the Web. For the purpose of this specification, a profile can be 141 described as additional semantics that can be used to process a 142 resource representation, such as constraints, conventions, 143 extensions, or any other aspects that do not alter the basic media 144 type semantics. A profile MUST NOT change the semantics of the 145 resource representation when processed without profile knowledge, so 146 that clients both with and without knowledge of a profiled resource 147 can safely use the same representation. While this specification 148 associates profiles with resource representations, creators and users 149 of profiles MAY define and manage them in a way that they can be used 150 across media types and thus could be associated with a resource, 151 independent of its representations (i.e., using the same profile URI 152 for different media types). However, such a design is outside of the 153 scope of this specification, and clients SHOULD treat profiles as 154 being associated with a resource representation. 156 Profiles can be combined, meaning that a single resource 157 representation can conform to zero or any number of profiles. 158 Depending on the profile support of clients, it is possible that the 159 same resource representation, when linked to a number of profiles, 160 can be processed with different sets of processing rules, based on 161 the profile support of the clients. 163 Profiles are identified by URI, but as with for example XML namespace 164 URIs, the URI in this case only serves as an identifier, meaning that 165 the presence of a specific URI has to be sufficient for a client to 166 assert that a resource representation conforms to a profile. Clients 167 thus SHOULD treat profile URIs as identifiers and not as links, but 168 profiles MAY be defined in a way that the URIs do identify 169 retrievable profile description and thus can be accessed by clients 170 by dereferencing the profile URI. For profiles intended for use in 171 environments where clients may encounter unknown profile URIs, 172 profile maintainers SHOULD consider to make the profile URI 173 dereferencable and provide useful documentation at that URI. The 174 design and representation of such profile descriptions, however, is 175 outside the scope of this specification. 177 3.1. Profiles and Media Types 179 A media type defines both the semantics and the serialization of a 180 specific type of content. In many cases, media types have some 181 extensibility or openness built-in, so that specific instances of the 182 media type can layer additional semantics on top of the media type's 183 foundations. In this case, a profile is the appropriate mechanism to 184 signal that the original semantics and processing model of the media 185 type still applies, but that an additional processing model can be 186 used to extract additional semantics. This is in contrast to a new 187 media type, which instead of just adding processing rules and 188 semantics, in most cases defines a complete set of processing rules 189 and semantics. As an example, XHTML is not a profile of XML but a 190 new media type because it introduces a complete new perspective of 191 the underlying XML structures, and from the XHTML point of view, 192 exposing the raw XML is not all that useful for clients. However, 193 hCard (see Section 5.1) is a profile of (X)HTML because it adds 194 processing rules that allow a client to extract additional semantics 195 from a representation, without changing any of the processing rules 196 and semantics of (X)HTML itself. While the line between a media type 197 and a profile might not always be easy to draw, the intention of 198 profiles is not to replace media types, but to add a more lightweight 199 and runtime-capable mechanism that allows servers and clients to be 200 more explicit in how a specific instance of a media type represents 201 concepts that are not defined by the media type itself, but by 202 additional conventions (the profile processing rules and semantics). 204 The idea of profiles is that they allow instances to clearly identify 205 what kind of mechanism they are using for expressing additional 206 semantics, should they follow a well-defined framework for doing so 207 (see Section 5 for examples). While this allows servers and clients 208 to represent the use of profiles, it does not make the profile 209 information visible outside of the representation itself, if the 210 representation is using embedded typed links. For newly defined 211 media types that may be used with profiles, it is therefore 212 recommended that they SHOULD define a media type parameter called 213 "profile", and specify that this media type parameter follows the 214 semantics of a profile as laid out in this document. This way, 215 clients can use this media type parameter to request a certain 216 profile when interacting, for example, with an HTTP server and 217 setting the Accept header. Representations using a "profile" media 218 type parameter still SHOULD include that value in the representation 219 using the "profile" link relation, since the media type label of a 220 representation can easily get lost when it is taken out of its 221 conversational context. 223 Since a representation can link to more than one profile, the same 224 has to be possible for the corresponding media type parameter (if a 225 media type defines such a parameter). Media types defining a 226 "profile" parameter SHOULD define it as a whitespace-separated list 227 of profile URIs. 229 3.2. Profile Context 231 Profile links convey information about the use of profiles for a 232 media type. If they are used within a media type, they apply to the 233 context specified by that media type, which means that for example 234 profile links in the head element of an HTML document apply to the 235 document as a whole. The context of a profile extends to the scope 236 of where it is being used, which means that profiles used in profile 237 media type parameters (as described in Section 3.1) or used in HTTP 238 Link headers extend to the scope of the protocol in which they are 239 being used. 241 4. IANA Considerations 243 The link relation type below will be registered by IANA per Section 244 6.2.1 of RFC 5988 [RFC5988]: 246 Relation Name: profile 248 Description: Identifying that a resource representation conforms 249 to a certain profile, without affecting the non-profile semantics 250 of the resource representation. 252 Reference: [[ This document ]] 254 Notes: Profile URIs are primarily intended to be used as 255 identifiers, and thus clients SHOULD NOT indiscriminately access 256 profile URIs. 258 5. Examples 260 This section lists some examples of profiles that already are defined 261 today (and thus could be readily used with a 'profile' link), and of 262 some potential additional examples. Since so far, profiles have been 263 mostly limited to HTML (because of the support of profiles in HTML), 264 the two examples of existing profiles are HTML profiles, and the two 265 hypothetical examples are non-HTML examples. 267 5.1. hCard 269 The hCard profile uses http://microformats.org/profile/hcard as its 270 defining URI and is essentially a mechanism how vCard [RFC6350] 271 information can be embedded in an HTML page using the mechanisms 272 provided by microformats. It is thus a good example for how profiles 273 might on the one hand define a model-based extension of the original 274 media type (in this case adding vCard fields), and how they also have 275 to define specific ways of how that model extension then is 276 represented in the media type (in this case, using microformats). 277 Alternatively, it would be possible to represent vCard information 278 through the mechanisms of RDFa or microdata, but since these would be 279 different conventions that a client would need to follow to extract 280 the vCard data, they would be identified by different profiles. 282 5.2. Dublin Core 284 Dublin Core metadata identified by the profile 285 http://dublincore.org/documents/2008/08/04/dc-html/ can be used to 286 embed Dublin Core metadata in an HRML page. In contrast to hCard, 287 which is using microformats as its foundation, the Dublin Core 288 profile defines its own way of embedding metadata into HTML, and does 289 so by using HTML elements. The interesting difference to 290 hCard is that Dublin Core not only defines metadata to be embedded in 291 HTML, it also allows links to be added as metadata, in which case the 292 profile not just describes additional data to be found within the 293 representation, but also allows the representation to be linked to 294 additional resources. 296 5.3. Podcasts 298 Podcasts are an extension of feed formats, and define a substantial 299 set of additional attributes to reflect the fact that the resources 300 in podcast feeds are time-based media formats such as audio and 301 video. While there is no profile URI for podcasts, the current 302 definition (maintained by Apple) at 303 http://www.apple.com/itunes/podcasts/specs.html could serve as such a 304 URI, or it could by updated to include such a URI. Podcasts are 305 feeds with special behavior, and while it is possible to follow a 306 podcast feed using a generic feed reader, a podcast-aware feed reader 307 will be able to extract additional information from the feed, and 308 thus can implement more sophisticated services or present a more 309 sophisticated UI for podcast feeds. The Apple page referenced above 310 describes the implementation of one such specialized podcast feed 311 reader, Apple iTunes. 313 6. Security Considerations 315 The 'profile' relation type is not known to introduce any new 316 security issues not already discussed in RFC 5988 [RFC5988] for 317 generic use of Web linking mechanisms. 319 7. Change Log 321 Note to RFC Editor: Please remove this section before publication. 323 7.1. From -03 to -04 325 o Changed category from "Standard" to "Informational". 327 o Minor textual changes. 329 7.2. From -02 to -03 331 o Removed the AtomPub example, which seemed to cause more confusion 332 than clarification. 334 o Minor textual changes. 336 7.3. From -01 to -02 338 o Feedback directed to apps-discuss@ietf.org 340 o Improved explanation of difference between media types and 341 profiles in "Profiles and Media Types" (Section 3.1). 343 o Added section on "Profiles and Media Types" (Section 3.1). 345 o Added section on "Profile Context" (Section 3.2). 347 7.4. From -00 to -01 349 o Updated security considerations. 351 o Made it clear that profiles are about resource representations, 352 and not about resources. 354 o Added examples section (Section 3.1) with four examples (Dublin 355 Core, HCard, AtomPub, and Podcasts). 357 o Minor textual changes. 359 8. References 361 8.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", RFC 2119, March 1997. 366 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 368 8.2. Informative References 370 [HTML401] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 371 Specification", World Wide Web Consortium 372 Recommendation REC-html401-19991224, December 1999, 373 . 375 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 376 August 2011. 378 Appendix A. Acknowledgements 380 Thanks for comments and suggestions provided by Erlend Hamnaberg, 381 Markus Lanthaler, Simon Mayer, Mark Nottingham, Julian Reschke, James 382 Snell, and Tim Williams. 384 Author's Address 386 Erik Wilde 387 EMC Corporation 388 6801 Koll Center Parkway 389 Pleasanton, CA 94566 390 U.S.A. 392 Phone: +1-925-6006244 393 Email: erik.wilde@emc.com 394 URI: http://dret.net/netdret/