idnits 2.17.1
draft-wilde-profile-link-01.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 (April 15, 2012) is 4394 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 5988 (ref. '1') (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: Standards Track April 15, 2012
5 Expires: October 17, 2012
7 The 'profile' Link Relation Type
8 draft-wilde-profile-link-01
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 Status of this Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on October 17, 2012.
38 Copyright Notice
40 Copyright (c) 2012 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
57 3. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
59 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
60 5.1. hCard . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
61 5.2. Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . 5
62 5.3. Podcasts . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 5.4. Atom Publishing Protocol (AtomPub) . . . . . . . . . . . . 6
64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
65 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
66 7.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 7
67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
69 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
73 1. Introduction
75 One of the foundations of the Internet and Web Architecture is the
76 fact that resource representations communicated through protocols
77 such as SMTP or HTTP are labeled with a 'media type', which allows a
78 client to understand at run time what 'type' of resource
79 representation it is handling. Sometimes, it would be useful for
80 servers and clients to include additional information about the
81 nature of the resource, so that a client understanding this
82 additional information could react in a way specific to that
83 specialization of the resource, where the specialization can be about
84 constraints, conventions, extensions, or any other aspects that do
85 not alter the basic media type semantics. HTML 4 [3] has such a
86 mechanism built into the language, which is the 'profile' attribute
87 of the 'head' element. This mechanism, however, is specific to HTML
88 alone, and at the time of writing it seems as if HTML 5 will drop
89 support for this mechanism entirely.
91 RFC 5988 [1] "defines a framework for typed links that is not
92 specific to a particular serialization or application. It does so by
93 redefining the link relation registry established by Atom to have a
94 broader domain, and adding to it the relations that are defined by
95 HTML."
97 This specification registers a 'profile' link relation type according
98 to the rules of RFC 5988 [1]. This link relation type is independent
99 of the context in which it is used (however, the representation must
100 support typed links for this mechanism to work) and does not
101 constrain in any way the target of the linked URI. In fact, for the
102 purpose of this specification, the target URI does not necessarily
103 have to identify a dereferencable resource (or even use a
104 dereferencable URI scheme), and clients can treat the occurrence of a
105 specific URI in the same way as an XML namespace URI and invoke
106 specific behavior based on the assumption that a specific profile
107 target URI signals that a resource representation follows a specific
108 profile. Note that at the same time, it is possible for profile
109 target URIs to use referencable URIs and use a media type (which is
110 outside the scope of this specification) which represents the
111 information about the profile in a human- or machine-readable way.
113 As one example, consider the case of podcasts, a specific kind of
114 feed using additional fields for media-related metadata. Using a
115 'profile' link, it would be easily possible for clients to understand
116 that a specific feed is supposed to be a podcast feed, and that it
117 may contain entries using podcast-specific fields. This may allow a
118 client to behave differently when handling such a feed (such as
119 rendering a podcast-specific UI), even when the current set of
120 entries in the feed may not contain any podcast entries.
122 2. Terminology
124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
126 document are to be interpreted as described in RFC 2119 [2].
128 3. Profiles
130 The concept of a profile has no strict definition on the Internet or
131 on the Web. For the purpose of this specification, a profile can be
132 described as additional semantics that can be used to process a
133 resource representation, such as constraints, conventions,
134 extensions, or any other aspects that do not alter the basic media
135 type semantics. A profile MUST NOT change the semantics of the
136 resource representation when processed without profile knowledge, so
137 that clients both with and without knowledge of a profiled resource
138 can safely use the same representation. While this specification
139 associates profiles with resource representations, creators of
140 profiles MAY define and manage them in a way that they can be used
141 across media types and thus could be associated with a resource,
142 independent of its representations. However, such a design is
143 outside of the scope of this specification, and clients profiles
144 SHOULD treat them as being associated with a representation.
146 Profiles can be combined, meaning that a single resource
147 representation can conform to zero or any number of profiles.
148 Depending on the profile support of clients, it is possible that the
149 same resource representation, when linked to a number of profiles,
150 can be processed with different sets of processing rules, based on
151 the profile support of the clients.
153 Profiles are identified by URI, but as with for example XML namespace
154 URIs, the URI in this case only serves as an identifier, meaning that
155 the presence of a specific URI has to be sufficient for a client to
156 assert that a resource representation conforms to a profile. Clients
157 thus SHOULD treat profile URIs as identifiers and not as links, but
158 profiles MAY be defined in a way that the URIs do identify
159 retrievable profile description and thus can be accessed by clients
160 by dereferencing the profile URI. For profiles intended for use in
161 environments where clients may encounter unknown profile URIs,
162 profile maintainers SHOULD consider to make the profile URI
163 dereferencable and provide useful documentation at that URI. The
164 design of such profile descriptions, however, is outside the scope of
165 this specification.
167 4. IANA Considerations
169 The link relation type below has been registered by IANA per Section
170 6.2.1 of RFC 5988 [1]:
172 Relation Name: profile
174 Description: Identifying that a resource representation conforms
175 to a certain profile, without affecting the non-profile semantics
176 of the resource representation.
178 Reference: [[ This document ]]
180 Notes: Profile URIs are primarily intended to be used as
181 identifiers, and thus clients SHOULD NOT indiscriminately access
182 profile URIs.
184 5. Examples
186 This section lists some examples of profiles that already are defined
187 today (and thus could be readily used with a 'profile' link), and of
188 some potential additional examples. Since so far, profiles have been
189 mostly limited to HTML (because of the support of profiles in HTML),
190 the two examples of existing profiles are HTML profiles, and the two
191 hypothetical examples are non-HTML examples.
193 5.1. hCard
195 The hCard profile uses http://microformats.org/profile/hcard as its
196 defining URI and is essentially a mechanism how vCard [4] information
197 can be embedded in an HTML page using the mechanisms provided by
198 microformats. It is thus a good example for how profiles might on
199 the one hand define a model-based extension of the original media
200 type (in this case adding vCard fields), and how they also have to
201 define specific ways of how that model extension then is represented
202 in the media type (in this case, using microformats). Alternatively,
203 it would be possible to represent vCard information through the
204 mechanisms of RDFa or microdata, but since these would be different
205 conventions that a client would need to follow to extract the vCard
206 data, they would be identified by different profiles.
208 5.2. Dublin Core
210 Dublin Core metadata identified by the profile
211 http://dublincore.org/documents/2008/08/04/dc-html/ can be used to
212 embed Dublin Core metadata in an HRML page. In contrast to hCard,
213 which is using microformats as its foundation, the Dublin Core
214 profile defines its own way of embedding metadata into HTML, and does
215 so by using HTML elements. The interesting difference to
216 hCard is that Dublin Core not only defines metadata to be embedded in
217 HTML, it also allows links to be added as metadata, in which case the
218 profile not just describes additional data to be found within the
219 representation, but also allows the representation to be linked to
220 additional resources.
222 5.3. Podcasts
224 Podcasts are an extension of feed formats, and define a substantial
225 set of additional attributes to reflect the fact that the resources
226 in podcast feeds are time-based media formats such as audio and
227 video. While there is no profile URI for podcasts, the current
228 definition (maintained by Apple) at
229 http://www.apple.com/itunes/podcasts/specs.html could serve as such a
230 URI, or it could by updated to include such a URI. Podcasts are
231 feeds with special behavior, and while it is possible to follow a
232 podcast feed using a generic feed reader, a podcast-aware feed reader
233 will be able to extract additional information from the feed, and
234 thus can implement more sophisticated services or present a more
235 sophisticated UI for podcast feeds. The Apple page referenced above
236 describes the implementation of one such specialized podcast feed
237 reader, Apple iTunes.
239 5.4. Atom Publishing Protocol (AtomPub)
241 The Atom Publishing Protocol (AtomPub) [5] has no mechanism for
242 signalling to clients that a feed supports AtomPub, this is only
243 discoverable for clients if they know that a feed's URI appears in a
244 service document (because they have found that service document
245 through some means outside of the AtomPub specification). By adding
246 a profile link to a feed supporting AtomPub (using Atom's generic
247 link element), an AtomPub feed could be self-describing in the sense
248 that clients could discover a feed's support for AtomPub just by
249 looking at the feed itself. While this approach would require an
250 update of the AtomPub specification, future specifications could
251 easily include such a profile URI as part of the specification
252 itself, and profile links then could serve as the generic discovery
253 mechanism for these extensions of a feed's capabilities.
255 6. Security Considerations
257 The 'profile' relation type is not known to introduce any new
258 security issues not already discussed in RFC 5988 [1] for generic use
259 of Web linking mechanisms.
261 7. Change Log
263 Note to RFC Editor: Please remove this section before publication.
265 7.1. From -00 to -01
267 o Updated security considerations.
269 o Minor typographical changes.
271 o Added section with examples.
273 o Made it clear that profiles are about resource representations,
274 and not about resources.
276 o Added structured examples section with fours examples (Dublin
277 Core, HCard, AtomPub, and Podcasts)
279 8. References
281 8.1. Normative References
283 [1] Nottingham, M., "Web Linking", RFC 5988, October 2010.
285 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
286 Levels", RFC 2119, March 1997.
288 8.2. Informative References
290 [3] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Specification",
291 World Wide Web Consortium Recommendation REC-html401-19991224,
292 December 1999, .
294 [4] Perreault, S., "vCard Format Specification", RFC 6350,
295 August 2011.
297 [5] Gregorio, J. and B. Hora, "The Atom Publishing Protocol",
298 RFC 5023, October 2010.
300 Appendix A. Acknowledgements
302 Thanks for comments and suggestions provided by Erlend Hamnaberg,
303 Markus Lanthaler, Simon Mayer, Mark Nottingham, and Tim Williams.
305 Author's Address
307 Erik Wilde
308 EMC Corporation
309 6801 Koll Center Parkway
310 Pleasanton, CA 94566
311 U.S.A.
313 Phone: +1-925-6006244
314 Email: erik.wilde@emc.com
315 URI: http://dret.net/netdret/