The Profile Media Type Parameter
draft-inkster-profile-parameter-00.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 15, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document defines a media type parameter 'profile' for the existing media types 'application/xml', 'text/xml' and 'application/json'. The 'profile' parameter provides an additional hint as to how the XML or JSON content is formatted, and may be used.

This document updates RFC 3236 (The 'application/xhtml+xml' Media Type), and RFC 4627 (The application/json Media Type for JavaScript Object Notation (JSON)).

Table of Contents

1.  Introduction
2.  The Profile Parameter
3.  Examples
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

1.  Introduction

Internet media types were originally defined in [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) but have since come to be used in a variety of protocols (HTTP, SIP) and formats (HTML, Atom, MathML). They provide a simple two-tier system for identifying content formats. With the exception of certain vanity, vendor-specific and experimental media types, new types need to be registered with the IETF through the publication of an RFC [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.).

XML [W3C.REC‑xml‑20081126] (Sperberg-McQueen, C., Yergeau, F., Bray, T., Paoli, J., and E. Maler, “Extensible Markup Language (XML) 1.0 (Fifth Edition),” November 2008.) and JSON [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) are two meta-formats - extensible frameworks for carrying a wide variety of types of data. XML may carry vector images [W3C.REC‑SVG11‑20030114] (Ferraiolo, J., 淳, and D. Jackson, “Scalable Vector Graphics (SVG) 1.1 Specification,” January 2003.), privacy policies [W3C.REC‑P3P‑20020416] (Marchiori, M., “The Platform for Privacy Preferences 1.0 (P3P1.0) Specification,” April 2002.), syndicated content [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.), recipes [RecipeBookXML] (Horton, D., “RecipeBook XML,” 2005.), or even desktop configuration settings [GConf] (The GNOME Project, “GConf configuration system,” .). JSON may carry "life streams" (@@xref activitystrea.ms), semantic data [RDFJSON] (Alexander, K. and I. Davis, “RDF/JSON Specification,” .), or personal contact details [jCard] (Oheim, G. and T. Inkster, “jCard 0.1,” 2008.). In some of these cases, specialised media types have been registered for the specific variety or "profile" in use - examples include 'application/smil+xml' [RFC4536] (Hoschka, P., “The application/smil and application/smil+xml Media Types,” July 2006.) and 'application/atom+xml' [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.).

However, often the developers of a particular media type do not wish to devote the time necessary for publishing an RFC, or do not understand the benefits. This means that much XML and JSON is published using the generic content types 'application/xml' and 'application/json' respectively. While this practice is good enough for a variety of purposes, it hinders HTTP content negotiation. If a user-agent requests content using an HTTP 'Accept' header of 'application/xml', the server is unable to determine which variety of XML the user-agent expects, and serve the correct type when more than one type is offered.

This document registers a media type parameter 'profile' to be used as an indicator of the variety of XML or JSON being referred to by generic 'application/xml' and 'application/json' media types.

2.  The Profile Parameter

The 'profile' parameter takes a single absolute URI [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) as its value, which may be quoted with single or double quotes. Two profiles are considered identical if the URIs match in a character-by-character case-sensitive string comparison.

The parameter applies to the 'application/xml', 'text/xml' and 'application/json' formats, and is compatible with the existing profile attribute defined for 'application/xhtml+xml' [RFC3236] (Baker, M. and P. Stark, “The 'application/xhtml+xml' Media Type,” January 2002.). This parameter is optional.

The 'profile' parameter provides a hint for consuming and publishing agents as to the variety of XML or JSON provided or expected. This hint is not considered authoritative, and may be over-ridden by inspection of the content body.

The URI provided in the 'profile' parameter acts as an identifier only. Software is not expected to dereference the URI, though it is not forbidden from doing so.

Specification documents for XML- and JSON-based formats may define a canonical URI for that format's profile.

In the absence of a specification-defined profile URI, the correct profile URI to use for XML media types is the primary namespace used by the specification; or if namespaces aren't used, the canonical URI of the specification itself.

In the absence of a specification-defined profile URI, the correct profile URI to use for JSON media types is the canonical URI of the specification itself.

In some cases, such as mixed-namespace XML, multiple profiles may be applicable to a single item of content. In these cases, servers should publish the content using a media type mentioning whichever profile the author thinks is most useful to advertise, but should pay attention to any of the profiles if found in the 'Accept' header during content negotiation.

When a registered media type, or widespread unregistered type is available for the specific profile of XML or JSON in use, these should be used instead, and the use of a generic media type with 'profile' parameter should be eschewed.

3.  Examples

The profile parameter can be useful for disambiguating between different flavours of XML in content negotiation.

GET /data HTTP/1.1
Host: example.com
Accept: application/rdf+xml,
    application/xml; profile="http://ilrt.org/discovery/2004/03/rxr/",
    text/turtle,
    application/xml; profile="http://www.w3.org/2003/g/data-view#"; q=0.5,
    application/json; profile="http://n2.talis.com/wiki/RDF_JSON_Specification"
User-Agent: DataMuncher/3.142

HTTP/1.1 200 OK
Content-Type: application/xml; charset="utf-8"
Content-Length: 226

<graph xmlns="http://ilrt.org/discovery/2004/03/rxr/">
  <triple>
    <subject uri="http://example.net"/>
    <predicate uri="http://purl.org/dc/elements/1.1/title"/>
    <object>Test Title</object>
  </triple>
</rxr:graph>

The RXR specification does not define a profile URI, so the primary namespace associated with the format is used instead.

The profile parameter is suitable for use in HTML and XHTML <link> elements.

<link rel='alternate'
      href='something.xml'
      type='text/xml;profile="http://www.oembed.com/"' />

The oEmbed specification does not define a profile URI, nor use namespaces, so the canonical URI for the specification is used instead.

The profile parameter is suitable for use in [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) message headers.

From: Alice <[email protected]>
To: Bob <[email protected]>
Subject: ACME Inc complaints procedure flowchart
MIME-Version: 1.0
Content-Type: application/json; profile="http://purl.example/acme/json/flow"

{
	title : "Complaints Procedure" ;
	steps: [
	 ...

4.  IANA Considerations

None.

5.  Security Considerations

None.

6.  Acknowledgements

7.  References

7.1. Normative References

7.2. Informative References

Author's Address