Movatterモバイル変換

Independent Submission                                          E. WildeRequest for Comments: 6906                               EMC CorporationCategory: Informational                                       March 2013ISSN: 2070-1721The 'profile' Link Relation TypeAbstract   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; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6906.Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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.Wilde                         Informational                     [Page 1]

RFC 6906                   "profile" Link Type                March 2013Table of Contents1. Introduction ....................................................22. Terminology .....................................................33. Profiles ........................................................33.1. Profiles and Media Types ...................................43.2. Profile Context ............................................54. IANA Considerations .............................................55. Examples ........................................................65.1. hCard ......................................................65.2. Dublin Core ................................................65.3. Podcasts ...................................................76. Security Considerations .........................................77. Acknowledgements ................................................78. References ......................................................78.1. Normative References .......................................78.2. Informative References .....................................71.  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.  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 [HTML401] 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.RFC 5988 [RFC5988] "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 ofRFC 5988 [RFC5988].  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 thisWilde                         Informational                     [Page 2]

RFC 6906                   "profile" Link Type                March 2013   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.  (Section5.3 gives more details for this example.)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 inRFC 2119 [RFC2119].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 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.Wilde                         Informational                     [Page 3]

RFC 6906                   "profile" Link Type                March 2013   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.3.1.  Profiles and Media Types   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 (seeSection 5.1) 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).Wilde                         Informational                     [Page 4]

RFC 6906                   "profile" Link Type                March 2013   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 (seeSection 5 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.3.2.  Profile Context   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 inSection 3.1) or used in HTTP   Link headers extend to the scope of the protocol in which they are   being used.4.  IANA Considerations   The link relation type below has been registered by IANA perSection6.2.1 of RFC 5988 [RFC5988]:      Relation Name: profile      Description: Identifying that a resource representation conforms      to a certain profile, without affecting the non-profile semantics      of the resource representation.Wilde                         Informational                     [Page 5]

RFC 6906                   "profile" Link Type                March 2013      Reference: [RFC6906]      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 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.5.1.  hCard   The hCard profile useshttp://microformats.org/profile/hcard as its   defining URI and is essentially a mechanism on how vCard [RFC6350]   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.5.2.  Dublin Core   Dublin Core metadata identified by the profilehttp://dublincore.org/documents/2008/08/04/dc-html/ 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.Wilde                         Informational                     [Page 6]

RFC 6906                   "profile" Link Type                March 20135.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) athttp://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.6.  Security Considerations   The 'profile' relation type is not known to introduce any new   security issues not already discussed inRFC 5988 [RFC5988] for   generic use of Web linking mechanisms.7.  Acknowledgements   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.8.  References8.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC5988]  Nottingham, M., "Web Linking",RFC 5988, October 2010.8.2.  Informative References   [HTML401]  Le Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01              Specification", World Wide Web Consortium Recommendation              REC-html401-19991224, December 1999,              <http://www.w3.org/TR/1999/REC-html401-19991224>.   [RFC6350]  Perreault, S., "vCard Format Specification",RFC 6350,              August 2011.Wilde                         Informational                     [Page 7]

RFC 6906                   "profile" Link Type                March 2013Author'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                         Informational                     [Page 8]