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/