1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Independent Submission E. Wilde
Request for Comments: 6906 EMC Corporation
Category: Informational March 2013
ISSN: 2070-1721
<span class="h1">The 'profile' Link Relation Type</span>
Abstract
This specification defines the 'profile' link relation type that
allows resource representations to indicate that they are following
one or more profiles. A profile is defined not to alter the
semantics of the resource representation itself, but to allow clients
to learn about additional semantics (constraints, conventions,
extensions) that are associated with the resource representation, in
addition to those defined by the media type and possibly other
mechanisms.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6906">http://www.rfc-editor.org/info/rfc6906</a>.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
<span class="grey">Wilde Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6906">RFC 6906</a> "profile" Link Type March 2013</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Profiles ........................................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Profiles and Media Types ...................................<a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Profile Context ............................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. IANA Considerations .............................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Examples ........................................................<a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. hCard ......................................................<a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Dublin Core ................................................<a href="#page-6">6</a>
<a href="#section-5.3">5.3</a>. Podcasts ...................................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-7">7</a>. Acknowledgements ................................................<a href="#page-7">7</a>
<a href="#section-8">8</a>. References ......................................................<a href="#page-7">7</a>
<a href="#section-8.1">8.1</a>. Normative References .......................................<a href="#page-7">7</a>
<a href="#section-8.2">8.2</a>. Informative References .....................................<a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
One of the foundations of the Internet and web architecture is the
fact that resource representations communicated through protocols,
such as SMTP or HTTP, are labeled with a 'media type', which allows a
client to understand at run time what 'type' of resource
representation it is handling. Sometimes, it would be useful for
servers and clients to include additional information about the
nature of the resource. This would allow a client understanding this
additional information to react in a way specific to that
specialization of the resource, where the specialization can be about
constraints, conventions, extensions, or any other aspects that do
not alter the basic media type semantics. HTML 4 [<a href="#ref-HTML401" title=""HTML 4.01 Specification"">HTML401</a>] has such
a mechanism built into the language, which is the 'profile' attribute
of the 'head' element. However, this mechanism is specific to HTML
alone; at the time of writing, it seems as if HTML 5 will drop
support for this mechanism entirely.
<a href="./rfc5988">RFC 5988</a> [<a href="./rfc5988" title=""Web Linking"">RFC5988</a>] "defines a framework for typed links that isn't
specific to a particular serialisation or application. It does so by
redefining the link relation registry established by Atom to have a
broader domain, and adding to it the relations that are defined by
HTML."
This specification registers a 'profile' link relation type according
to the rules of <a href="./rfc5988">RFC 5988</a> [<a href="./rfc5988" title=""Web Linking"">RFC5988</a>]. Links with this relation type
can be used in representations that support typed links as well as in
HTTP Link headers. The profile link relation type is independent of
the context in which it is used and does not constrain, in any way,
the target of the linked URI. In fact, for the purpose of this
<span class="grey">Wilde Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6906">RFC 6906</a> "profile" Link Type March 2013</span>
specification, the target URI does not necessarily have to identify a
dereferencable resource (or even use a dereferencable URI scheme).
Clients can treat the occurrence of a specific URI in the same way as
an XML namespace URI and invoke specific behavior based on the
assumption that a specific profile target URI signals that a resource
representation follows a specific profile. Note that, at the same
time, it is possible for profile target URIs to use dereferencable
URIs and to use a representation (which is outside the scope of this
specification) that represents the information about the profile in a
human- or machine-readable way.
As one example, consider the case of podcasts, where a specific kind
of feed uses additional fields for media-related metadata. Using a
'profile' link, it would be easily possible for clients to understand
that a specific feed is supposed to be a podcast feed, and that it
may contain entries using podcast-specific fields. This may allow a
client to behave differently when handling such a feed (such as
rendering a podcast-specific UI), even when the current set of
entries in the feed may not contain any podcast entries. (<a href="#section-5.3">Section</a>
<a href="#section-5.3">5.3</a> gives more details for this example.)
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Profiles</span>
The concept of a profile has no strict definition on the Internet or
on the web. For the purpose of this specification, a profile can be
described as additional semantics that can be used to process a
resource representation, such as constraints, conventions,
extensions, or any other aspects that do not alter the basic media
type semantics. A profile MUST NOT change the semantics of the
resource representation when processed without profile knowledge, so
that clients both with and without knowledge of a profiled resource
can safely use the same representation. While this specification
associates profiles with resource representations, creators and users
of profiles MAY define and manage them in a way that allows them to
be used across media types; thus, they could be associated with a
resource, independent of their representations (i.e., using the same
profile URI for different media types). However, such a design is
outside of the scope of this specification, and clients SHOULD treat
profiles as being associated with a resource representation.
<span class="grey">Wilde Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6906">RFC 6906</a> "profile" Link Type March 2013</span>
Profiles can be combined, meaning that a single resource
representation can conform to zero or any number of profiles.
Depending on the profile support of clients, it is possible that the
same resource representation, when linked to a number of profiles,
can be processed with different sets of processing rules, based on
the profile support of the clients.
Profiles are identified by URI. However, as is the case with, for
example, XML namespace URIs, the URI in this case only serves as an
identifier, meaning that the presence of a specific URI has to be
sufficient for a client to assert that a resource representation
conforms to a profile. Thus, clients SHOULD treat profile URIs as
identifiers and not as links, but profiles MAY be defined in a way
that the URIs do identify retrievable profile description and thus
can be accessed by clients by dereferencing the profile URI. For
profiles intended for use in environments where clients may encounter
unknown profile URIs, profile maintainers SHOULD consider to make the
profile URI dereferencable and provide useful documentation at that
URI. The design and representation of such profile descriptions,
however, is outside the scope of this specification.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Profiles and Media Types</span>
A media type defines both the semantics and the serialization of a
specific type of content. In many cases, media types have some
built-in extensibility or openness, so that specific instances of the
media type can layer additional semantics on top of the media type's
foundation. In this case, a profile is the appropriate mechanism to
signal that the original semantics and processing model of the media
type still apply, but that an additional processing model can be used
to extract additional semantics. This is in contrast to a new media
type that, instead of just adding processing rules and semantics
defines a complete set of processing rules and semantics in most
cases. As an example, XHTML is not a profile of XML but a new media
type because it introduces a complete new perspective of the
underlying XML structures, and from the XHTML point of view, exposing
the raw XML is not all that useful for clients. However, hCard (see
<a href="#section-5.1">Section 5.1</a>) is a profile of (X)HTML because it adds processing rules
that allow a client to extract additional semantics from a
representation, without changing any of the processing rules and
semantics of (X)HTML itself. While the line between a media type and
a profile might not always be easy to draw, the intention of profiles
is not to replace media types, but to add a more lightweight and
runtime-capable mechanism that allows servers and clients to be more
explicit in how a specific instance of a media type represents
concepts that are not defined by the media type itself, but by
additional conventions (the profile processing rules and semantics).
<span class="grey">Wilde Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6906">RFC 6906</a> "profile" Link Type March 2013</span>
The objective of profiles is that they allow instances to clearly
identify what kind of mechanism they are using for expressing
additional semantics, should they follow a well-defined framework for
doing so (see <a href="#section-5">Section 5</a> for examples). While this allows servers and
clients to represent the use of profiles, it does not make the
profile information visible outside of the representation itself, if
the representation is using embedded typed links. For newly defined
media types that may be used with profiles, it is therefore
recommended that they SHOULD define a media type parameter called
'profile' and specify that this media type parameter follows the
semantics of a profile as laid out in this document. This way,
clients can use this media type parameter to request a certain
profile when interacting, for example, with an HTTP server and
setting the Accept header. Representations using a 'profile' media
type parameter still SHOULD include that value in the representation
using the 'profile' link relation, since the media type label of a
representation can easily get lost when it is taken out of its
conversational context.
Since a representation can link to more than one profile, the same
has to be possible for the corresponding media type parameter (if a
media type defines such a parameter). Media types defining a
'profile' parameter SHOULD define it as a whitespace-separated list
of profile URIs.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Profile Context</span>
Profile links convey information about the use of profiles for a
media type. If they are used within a media type, they apply to the
context specified by that media type. This means, for example, that
profile links in the head element of an HTML document apply to the
document as a whole. The context of a profile extends to the scope
of where it is being used, which means that profiles used in profile
media type parameters (as described in <a href="#section-3.1">Section 3.1</a>) or used in HTTP
Link headers extend to the scope of the protocol in which they are
being used.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
The link relation type below has been registered by IANA per <a href="./rfc5988#section-6.2.1">Section</a>
<a href="./rfc5988#section-6.2.1">6.2.1 of RFC 5988</a> [<a href="./rfc5988" title=""Web Linking"">RFC5988</a>]:
Relation Name: profile
Description: Identifying that a resource representation conforms
to a certain profile, without affecting the non-profile semantics
of the resource representation.
<span class="grey">Wilde Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6906">RFC 6906</a> "profile" Link Type March 2013</span>
Reference: [<a href="./rfc6906">RFC6906</a>]
Notes: Profile URIs are primarily intended to be used as
identifiers, and thus clients SHOULD NOT indiscriminately access
profile URIs.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Examples</span>
This section lists some examples of profiles that are already defined
(and thus could be readily used with a 'profile' link) and of some
potential additional profiles. So far, profiles have been mostly
limited to HTML (because of the support of profiles in HTML). The
two examples of existing profiles are HTML profiles, and the one
hypothetical example is a non-HTML example that is based on feeds.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. hCard</span>
The hCard profile uses <a href="http://microformats.org/profile/hcard">http://microformats.org/profile/hcard</a> as its
defining URI and is essentially a mechanism on how vCard [<a href="./rfc6350" title=""vCard Format Specification"">RFC6350</a>]
information can be embedded in an HTML page using the mechanisms
provided by microformats. It is thus a good example for how profiles
might, on the one hand, define a model-based extension of the
original media type (in this case, adding vCard fields), and how they
also have to define specific ways of how that model extension is then
represented in the media type (in this case, using microformats).
Alternatively, it would be possible to represent vCard information
through the mechanisms of RDF in Attributes (RDFa) or microdata, but
since these would be different conventions that a client would need
to follow to extract the vCard data, they would be identified by
different profiles.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Dublin Core</span>
Dublin Core metadata identified by the profile
<a href="http://dublincore.org/documents/2008/08/04/dc-html/">http://dublincore.org/documents/2008/08/04/dc-html/</a> can be used to
embed Dublin Core metadata in an HTML page. In contrast to hCard,
which uses microformats as its foundation, the Dublin Core profile
defines its own way of embedding metadata into HTML, and it does so
using HTML <link> elements. The interesting difference to hCard is
that Dublin Core not only defines metadata to be embedded in HTML, it
also allows links to be added as metadata. In which case, the
profile not only describes additional data to be found within the
representation, but also allows the representation to be linked to
additional resources.
<span class="grey">Wilde Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6906">RFC 6906</a> "profile" Link Type March 2013</span>
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Podcasts</span>
Podcasts are an extension of feed formats and define a substantial
set of additional attributes to reflect the fact that the resources
in podcast feeds are time-based media formats, such as audio and
video. While there is no profile URI for podcasts, the current
definition (maintained by Apple) at
<a href="http://www.apple.com/itunes/podcasts/specs.html">http://www.apple.com/itunes/podcasts/specs.html</a> could serve as such a
URI, or it could by updated to include such a URI. Podcasts are
feeds with special behavior; and while it is possible to follow a
podcast feed using a generic feed reader, a podcast-aware feed reader
will be able to extract additional information from the feed, and
thus can implement more sophisticated services or present a more
sophisticated UI for podcast feeds. The Apple page referenced above
describes the implementation of one such specialized podcast feed
reader, Apple iTunes.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The 'profile' relation type is not known to introduce any new
security issues not already discussed in <a href="./rfc5988">RFC 5988</a> [<a href="./rfc5988" title=""Web Linking"">RFC5988</a>] for
generic use of Web linking mechanisms.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
Thanks for comments and suggestions provided by Erlend Hamnaberg,
Markus Lanthaler, Simon Mayer, Mark Nottingham, Julian Reschke, James
Snell, Herbert Van de Sompel, and Tim Williams.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC5988">RFC5988</a>] Nottingham, M., "Web Linking", <a href="./rfc5988">RFC 5988</a>, October 2010.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-HTML401">HTML401</a>] Le Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999,
<<a href="http://www.w3.org/TR/1999/REC-html401-19991224">http://www.w3.org/TR/1999/REC-html401-19991224</a>>.
[<a id="ref-RFC6350">RFC6350</a>] Perreault, S., "vCard Format Specification", <a href="./rfc6350">RFC 6350</a>,
August 2011.
<span class="grey">Wilde Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6906">RFC 6906</a> "profile" Link Type March 2013</span>
Author's Address
Erik Wilde
EMC Corporation
6801 Koll Center Parkway
Pleasanton, CA 94566
U.S.A.
Phone: +1-925-6006244
EMail: erik.wilde@emc.com
URI: <a href="http://dret.net/netdret/">http://dret.net/netdret/</a>
Wilde Informational [Page 8]
</pre>
|
