diff options
Diffstat (limited to 'doc/rfc/rfc6906.txt')
| -rw-r--r-- | doc/rfc/rfc6906.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6906.txt b/doc/rfc/rfc6906.txt new file mode 100644 index 0000000..7712259 --- /dev/null +++ b/doc/rfc/rfc6906.txt @@ -0,0 +1,451 @@ + + + + + + +Independent Submission E. Wilde +Request for Comments: 6906 EMC Corporation +Category: Informational March 2013 +ISSN: 2070-1721 + + + The 'profile' Link Relation Type + +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 Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://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 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. + + + + + +Wilde Informational [Page 1] + +RFC 6906 "profile" Link Type March 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Profiles ........................................................3 + 3.1. Profiles and Media Types ...................................4 + 3.2. Profile Context ............................................5 + 4. IANA Considerations .............................................5 + 5. Examples ........................................................6 + 5.1. hCard ......................................................6 + 5.2. Dublin Core ................................................6 + 5.3. Podcasts ...................................................7 + 6. Security Considerations .........................................7 + 7. Acknowledgements ................................................7 + 8. References ......................................................7 + 8.1. Normative References .......................................7 + 8.2. Informative References .....................................7 + +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. 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 of RFC 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 this + + + +Wilde 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. (Section + 5.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 in RFC 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 (see + Section 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 (see Section 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 in Section 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 per Section + 6.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 uses http://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 profile + http://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 2013 + + +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. + +6. Security Considerations + + The 'profile' relation type is not known to introduce any new + security issues not already discussed in RFC 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. References + +8.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 2013 + + +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 Informational [Page 8] + |