Independent Submission E. Wilde
Request for Comments: 6906 EMC Corporation
Category: Informational March 2013
ISSN: 2070-1721
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.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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 ....................................................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
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.
Internet和web体系结构的基础之一是，通过协议（如SMTP或HTTP）进行通信的资源表示被标记为“媒体类型”，这允许客户端在运行时了解它正在处理的资源表示的“类型”。有时，服务器和客户端包含有关资源性质的附加信息会很有用。这将允许理解此附加信息的客户机以特定于资源专门化的方式作出反应，其中专门化可以是关于约束、约定、扩展或不改变基本媒体类型语义的任何其他方面。HTML4[HTML401]在语言中内置了这样一种机制，即“head”元素的“profile”属性。然而，这种机制仅限于HTML；在撰写本文时，HTML5似乎将完全放弃对该机制的支持。
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."
RFC 5988[RFC5988]“定义了一个非特定于特定序列化或应用程序的类型化链接框架。它通过重新定义Atom建立的链接关系注册表，使其具有更广的域，并向其中添加由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
本规范根据RFC 5988[RFC5988]的规则注册“配置文件”链接关系类型。具有此关系类型的链接可以在支持类型化链接的表示以及HTTP链接头中使用。概要文件链接关系类型独立于使用它的上下文，并且不以任何方式约束链接URI的目标。事实上，为了这个目的
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.
在规范中，目标URI不一定必须标识可取消引用的资源（甚至不必使用可取消引用的URI方案）。客户端可以用与XML名称空间URI相同的方式处理特定URI的出现，并基于特定概要文件目标URI表示资源表示遵循特定概要文件的假设来调用特定行为。注意，同时，概要文件目标uri可以使用可取消引用的uri，也可以使用表示（不在本规范的范围内）以人或机器可读的方式表示关于概要文件的信息。
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.)
作为一个例子，考虑播客的情况，其中特定类型的订阅使用媒体相关元数据的附加字段。使用“profile”链接，客户很容易理解特定提要应该是播客提要，并且它可能包含使用播客特定字段的条目。这可能允许客户端在处理此类提要（例如呈现特定于播客的UI）时表现不同，即使提要中的当前条目集可能不包含任何播客条目。（第5.3节给出了该示例的更多细节。）
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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.
个人资料的概念在互联网或网络上没有严格的定义。出于本规范的目的，概要文件可以描述为可用于处理资源表示的附加语义，例如约束、约定、扩展或不改变基本媒体类型语义的任何其他方面。当在没有概要文件知识的情况下处理概要文件时，概要文件不得更改资源表示的语义，以便具有和不具有概要文件资源知识的客户端都可以安全地使用相同的表示。虽然本规范将配置文件与资源表示相关联，但配置文件的创建者和用户可以以允许跨媒体类型使用的方式对其进行定义和管理；因此，它们可以与资源相关联，独立于它们的表示（即，对不同的媒体类型使用相同的配置文件URI）。但是，这样的设计超出了本规范的范围，客户机应该将概要文件视为与资源表示关联。
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.
配置文件由URI标识。但是，与例如XML命名空间URI一样，本例中的URI仅用作标识符，这意味着特定URI的存在必须足以让客户端断言资源表示符合概要文件。因此，客户端应该将概要文件URI视为标识符而不是链接，但是概要文件可以这样定义：URI确实标识可检索的概要文件描述，因此客户端可以通过取消引用概要文件URI来访问概要文件。对于打算在客户端可能遇到未知配置URI的环境中使用的配置文件，配置维护人员应考虑使配置URI不可撤销，并在该URI提供有用的文档。然而，此类外形描述的设计和表示不在本规范的范围内。
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).
媒体类型定义特定类型内容的语义和序列化。在许多情况下，媒体类型具有一些内置的可扩展性或开放性，因此媒体类型的特定实例可以在媒体类型的基础之上添加附加语义。在这种情况下，配置文件是一种适当的机制，用于表示媒体类型的原始语义和处理模型仍然适用，但可以使用附加处理模型来提取附加语义。这与一种新的媒体类型形成对比，这种媒体类型不只是添加处理规则和语义，而是在大多数情况下定义一套完整的处理规则和语义。例如，XHTML不是XML的概要文件，而是一种新的媒体类型，因为它引入了底层XML结构的全新透视图，并且从XHTML的角度来看，公开原始XML对客户端并不是那么有用。然而，hCard（参见第5.1节）是（X）HTML的一个概要文件，因为它添加了处理规则，允许客户端从表示中提取额外的语义，而不改变（X）HTML本身的任何处理规则和语义。虽然媒体类型和配置文件之间的界限可能并不总是容易划清，但配置文件的目的并不是取代媒体类型，但要添加一种更轻量级、支持运行时的机制，使服务器和客户端能够更明确地了解媒体类型的特定实例如何表示不由媒体类型本身定义，而是由其他约定（配置文件处理规则和语义）定义的概念。
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.
概要文件的目标是，如果实例遵循定义良好的框架来表达额外的语义，那么它们允许实例清楚地识别它们正在使用何种机制来表达额外的语义（示例见第5节）。虽然这允许服务器和客户机表示配置文件的使用，但如果表示使用的是嵌入式类型链接，则不会使配置文件信息在表示本身之外可见。因此，对于可能与配置文件一起使用的新定义的媒体类型，建议它们定义一个名为“profile”的媒体类型参数，并指定此媒体类型参数遵循本文档中列出的配置文件语义。这样，客户机可以在与HTTP服务器交互并设置Accept标头时使用此媒体类型参数来请求特定的配置文件。使用“配置文件”媒体类型参数的表示仍应在使用“配置文件”链接关系的表示中包含该值，因为当表示的媒体类型标签从对话上下文中取出时，很容易丢失。
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.
由于表示可以链接到多个配置文件，因此相应的媒体类型参数（如果媒体类型定义了这样的参数）也可以链接到多个配置文件。定义“配置文件”参数的媒体类型应将其定义为以空格分隔的配置文件URI列表。
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.
配置文件链接传达有关使用媒体类型配置文件的信息。如果它们在媒体类型中使用，则应用于该媒体类型指定的上下文。这意味着，例如，HTML文档的head元素中的profile链接应用于整个文档。配置文件的上下文扩展到其使用的范围，这意味着配置文件媒体类型参数（如第3.1节所述）中使用的配置文件或HTTP链接头中使用的配置文件扩展到其使用的协议的范围。
The link relation type below has been registered by IANA per Section 6.2.1 of RFC 5988 [RFC5988]:
IANA已根据RFC 5988[RFC5988]第6.2.1节的规定注册了以下链接关系类型：
Relation Name: profile
关系名称：profile
Description: Identifying that a resource representation conforms to a certain profile, without affecting the non-profile semantics of the resource representation.
描述：标识资源表示符合特定概要文件，而不影响资源表示的非概要文件语义。
Reference: [RFC6906]
参考文献：[RFC6906]
Notes: Profile URIs are primarily intended to be used as identifiers, and thus clients SHOULD NOT indiscriminately access profile URIs.
注意：配置文件URI主要用作标识符，因此客户端不应不加区别地访问配置文件URI。
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.
本节列出了一些已经定义的概要文件（因此可以与“概要文件”链接一起使用）和一些潜在的附加概要文件的示例。到目前为止，配置文件主要局限于HTML（因为HTML中支持配置文件）。现有配置文件的两个示例是HTML配置文件，一个假设示例是基于提要的非HTML示例。
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.
hCard配置文件使用http://microformats.org/profile/hcard 作为其定义URI，它本质上是一种机制，用于说明如何使用微格式提供的机制将vCard[RFC6350]信息嵌入到HTML页面中。因此，这是一个很好的示例，一方面，配置文件可以定义原始媒体类型的基于模型的扩展（在本例中，添加vCard字段），另一方面，配置文件还必须定义如何在媒体类型中表示模型扩展的具体方式（在本例中，使用微格式）。或者，可以通过属性中的RDF（RDFa）机制或微数据来表示vCard信息，但由于客户提取vCard数据需要遵循不同的约定，因此它们将由不同的配置文件来标识。
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.
配置文件标识的都柏林核心元数据http://dublincore.org/documents/2008/08/04/dc-html/ 可用于在HTML页面中嵌入都柏林核心元数据。与使用微格式为基础的HCARD相比，都柏林核心配置文件定义了自己的元数据嵌入HTML的方式，它使用HTML <Link >元素。与hCard有趣的区别在于，dublincore不仅定义了要嵌入HTML的元数据，还允许将链接作为元数据添加。在这种情况下，概要文件不仅描述要在表示中找到的其他数据，而且还允许将表示链接到其他资源。
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.
播客是提要格式的扩展，定义了大量附加属性，以反映播客提要中的资源是基于时间的媒体格式，如音频和视频。虽然播客没有配置文件URI，但当前的定义（由Apple维护）是http://www.apple.com/itunes/podcasts/specs.html 可以用作这样的URI，也可以通过更新来包含这样的URI。播客是具有特殊行为的提要；虽然可以使用通用提要阅读器来跟踪播客提要，但支持播客的提要阅读器将能够从提要中提取更多信息，从而可以实现更复杂的服务或为播客提要提供更复杂的UI。上面提到的Apple页面描述了一个专门的播客提要阅读器Apple iTunes的实现。
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.
“profile”关系类型不会引入RFC 5988[RFC5988]中未讨论的任何新安全问题，以用于Web链接机制的一般使用。
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.
感谢Erlend Hamnaberg、Markus Lanthaler、Simon Mayer、Mark Nottingham、Julian Reschke、James Snell、Herbert Van de Sompel和Tim Williams提供的意见和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
[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>.
[HTML401]Le Hors，A.，Raggett，D.，和I.Jacobs，“HTML 4.01规范”，万维网联盟建议REC-HTML401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[RFC6350]Perreault，S.，“vCard格式规范”，RFC 63502011年8月。
Author's Address
作者地址
Erik Wilde EMC Corporation 6801 Koll Center Parkway Pleasanton, CA 94566 U.S.A.
Erik Wilde EMC Corporation 6801美国加利福尼亚州普莱森顿科尔中心公园路94566号。
Phone: +1-925-6006244
EMail: erik.wilde@emc.com
URI: http://dret.net/netdret/
Phone: +1-925-6006244
EMail: erik.wilde@emc.com
URI: http://dret.net/netdret/