Network Working Group E. Wilde
Internet-Draft EMC Corporation
Intended status: Standards Track April 15, 2012
Expires: October 17, 2012
The 'profile' Link Relation Type
draft-wilde-profile-link-01
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 to not 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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. Code Components extracted from this document must
Wilde Expires October 17, 2012 [Page 1]
Internet-Draft "profile" Link Type April 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. hCard . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Podcasts . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Atom Publishing Protocol (AtomPub) . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Wilde Expires October 17, 2012 [Page 2]
Internet-Draft "profile" Link Type April 2012
1. Introduction
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, so that a client understanding this
additional information could 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 [3] has such a
mechanism built into the language, which is the 'profile' attribute
of the 'head' element. This mechanism, however, is specific to HTML
alone, and at the time of writing it seems as if HTML 5 will drop
support for this mechanism entirely.
RFC 5988 [1] "defines a framework for typed links that is not
specific to a particular serialization 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 RFC 5988 [1]. This link relation type is independent
of the context in which it is used (however, the representation must
support typed links for this mechanism to work) and does not
constrain in any way the target of the linked URI. In fact, for the
purpose of this specification, the target URI does not necessarily
have to identify a dereferencable resource (or even use a
dereferencable URI scheme), and 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 referencable URIs and use a media type (which is
outside the scope of this specification) which represents the
information about the profile in a human- or machine-readable way.
As one example, consider the case of podcasts, a specific kind of
feed using 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.
Wilde Expires October 17, 2012 [Page 3]
Internet-Draft "profile" Link Type April 2012
2. Terminology
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 RFC 2119 [2].
3. Profiles
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 of
profiles MAY define and manage them in a way that they can be used
across media types and thus could be associated with a resource,
independent of its representations. However, such a design is
outside of the scope of this specification, and clients profiles
SHOULD treat them as being associated with a representation.
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, but as 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. Clients
thus 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 of such profile descriptions, however, is outside the scope of
this specification.
Wilde Expires October 17, 2012 [Page 4]
Internet-Draft "profile" Link Type April 2012
4. IANA Considerations
The link relation type below has been registered by IANA per Section
6.2.1 of RFC 5988 [1]:
Relation Name: profile
Description: Identifying that a resource representation conforms
to a certain profile, without affecting the non-profile semantics
of the resource representation.
Reference: [[ This document ]]
Notes: Profile URIs are primarily intended to be used as
identifiers, and thus clients SHOULD NOT indiscriminately access
profile URIs.
5. Examples
This section lists some examples of profiles that already are defined
today (and thus could be readily used with a 'profile' link), and of
some potential additional examples. Since 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 two
hypothetical examples are non-HTML examples.
5.1. hCard
The hCard profile uses http://microformats.org/profile/hcard as its
defining URI and is essentially a mechanism how vCard [4] 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 then is represented
in the media type (in this case, using microformats). Alternatively,
it would be possible to represent vCard information through the
mechanisms of 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.
5.2. Dublin Core
Dublin Core metadata identified by the profile
http://dublincore.org/documents/2008/08/04/dc-html/ can be used to
embed Dublin Core metadata in an HRML page. In contrast to hCard,
which is using microformats as its foundation, the Dublin Core
Wilde Expires October 17, 2012 [Page 5]
Internet-Draft "profile" Link Type April 2012
profile defines its own way of embedding metadata into HTML, and does
so by using HTML 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 just describes additional data to be found within the
representation, but also allows the representation to be linked to
additional resources.
5.3. Podcasts
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
http://www.apple.com/itunes/podcasts/specs.html 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.
5.4. Atom Publishing Protocol (AtomPub)
The Atom Publishing Protocol (AtomPub) [5] has no mechanism for
signalling to clients that a feed supports AtomPub, this is only
discoverable for clients if they know that a feed's URI appears in a
service document (because they have found that service document
through some means outside of the AtomPub specification). By adding
a profile link to a feed supporting AtomPub (using Atom's generic
link element), an AtomPub feed could be self-describing in the sense
that clients could discover a feed's support for AtomPub just by
looking at the feed itself. While this approach would require an
update of the AtomPub specification, future specifications could
easily include such a profile URI as part of the specification
itself, and profile links then could serve as the generic discovery
mechanism for these extensions of a feed's capabilities.
6. Security Considerations
The 'profile' relation type is not known to introduce any new
security issues not already discussed in RFC 5988 [1] for generic use
of Web linking mechanisms.
Wilde Expires October 17, 2012 [Page 6]
Internet-Draft "profile" Link Type April 2012
7. Change Log
Note to RFC Editor: Please remove this section before publication.
7.1. From -00 to -01
o Updated security considerations.
o Minor typographical changes.
o Added section with examples.
o Made it clear that profiles are about resource representations,
and not about resources.
o Added structured examples section with fours examples (Dublin
Core, HCard, AtomPub, and Podcasts)
8. References
8.1. Normative References
[1] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
8.2. Informative References
[3] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Specification",
World Wide Web Consortium Recommendation REC-html401-19991224,
December 1999, .
[4] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011.
[5] Gregorio, J. and B. Hora, "The Atom Publishing Protocol",
RFC 5023, October 2010.
Appendix A. Acknowledgements
Thanks for comments and suggestions provided by Erlend Hamnaberg,
Markus Lanthaler, Simon Mayer, Mark Nottingham, and Tim Williams.
Wilde Expires October 17, 2012 [Page 7]
Internet-Draft "profile" Link Type April 2012
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: http://dret.net/netdret/
Wilde Expires October 17, 2012 [Page 8]