doc: Add RFC documents

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]
+