The 'profile' Link Relation Type
draft-wilde-profile-link-00

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 that are associated with the resource 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 September 6, 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 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
2.  Terminology
3.  Resource Profiles
4.  IANA Considerations
5.  Security Considerations
6.  Change Log
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Acknowledgements
§  Author's Address

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. HTML 4 [3] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.) 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 it seems as if HTML 5 will drop support for this mechanism entirely.

This specification registers a 'profile' link relation type according to the rules of RFC 5988 [1] (Nottingham, M., “Web Linking,” October 2010.). This link relation type is independent of the resource representation it is used in (but the representation must support types links for this mechanism to work) and independent of the target of the linked URI. In fact, for the purpose of this specification, the URI does not necessarily have to link to a dereferencable resource, and clients can treat the occurrence of a specific URI in the same sense as a namespace URI and invoke specific behavior based on the assumption that a specific profile URI signals that a resource follows a specific profile. Note that at the same time, it is possible for profile 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 possible for a client 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 UI), even when the current set of entries in the feed may not contain any podcast entries.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Resource Profiles

The concept of a resource profile has no strict definition on the Internet or within the Web. For the purpose of this specification, a resource profile are additional semantics that can be used to process a resource. These semantics SHOULD be independent of specific representations of both the resources using them, and a of a specific profile representation (if it exists), so that a profile URI can be reused across media types. Furthermore, a profile MUST NOT change the semantics of the resource when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation.

Profiles can be combined, meaning that a single resource can conform to zero or any number of profiles. Depending on the profile support of clients it is this possible that the same resource, when linked to a number of profiles, can be processed with very different sets of processing rules, based on the profile knowledge of the clients.

Profiles are identified by URI, but as with for example XML namespace URIs, the URI in this case first and foremost serves as an identifier, meaning that the presence of a certain URI can be sufficient for a client to assert that a resource conforms to a profile. However, in some settings it may be desirable to allow profiles to change at runtime, in which case it is necessary for clients to dereference links to profiles and interpret the profile representation they retrieve. In such a scenario, a media type for profile representation is required, but both the scenario and the required media type are outside of the scope of this specification.

4.  IANA Considerations

The link relation type below has been registered by IANA per Section 6.2.1 of RFC 5988 [1] (Nottingham, M., “Web Linking,” October 2010.):

Relation Name: profile

Description: Identifying that a resource conforms to a certain profile, without affecting the non-profile semantics of the resource.

Reference: RFC xxxx (this draft's eventual RFC number)

Notes: Profile URIs are primarily intended to be used as identifiers, and thus clients SHOULD NOT indiscriminately access profile URIs.

5.  Security Considerations

The 'profile' relation type is truly believed not to raise any new security issues which are not discussed in RFC 5988 [1] (Nottingham, M., “Web Linking,” October 2010.) for generic use of Web linking mechanism.

6.  Change Log

Note to RFC Editor: Please remove this section before publication.

7.  References

7.1. Normative References

7.2. Informative References

Appendix A.  Acknowledgements

Thanks for comments and suggestions provided by ...

Author's Address