The application/opensearchdescription+xml media type
draft-ellermann-opensearch-03

Abstract

This draft suggests to register the
application/opensearchdescription+xml media type for OpenSearch descriptions. Atom and XHTML <link rel="search" .../> elements are examples where this media type is used.

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 May 17, 2012.

Copyright Notice

Copyright (c) 2011 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.

1. Introduction

This draft suggests to register the
application/opensearchdescription+xml media type for OpenSearch descriptions. Atom and XHTML <link rel="search" .../> elements are examples where this media type is used.

It can be discussed in http://groups.google.com/group/opensearch or on the mailto:ietf-types@iana.org mailing list. Because this draft is not (more) intended to be published as RFC the normative and informative references are actually only "further readings".

2. Security Considerations

The security considerations are a part of the IANA [iana] media subtype registration template.

3. IANA Considerations

Below you find the [RFC4288] registration template for the subtype "opensearchdescription+xml" of the "application" media type under http://www.iana.org/assignments/media-types/application/:

Type name:

application

Subtype name:

opensearchdescription+xml

Required parameters:

There are no required parameters.

Optional parameters:

charset (defaults to "UTF-8")

Encoding considerations:

Identical to those of "application/xml" as described in [RFC3023]; especially "UTF-8" [RFC3629] and its proper subset "US-ASCII" are supposed to work.

For non-ASCII documents served as "text/xml" the "charset" parameter is required; this might be relevant when authors are unable to configure the server hosting their OSD (OpenSearch Description document).

Security considerations:

All general security and privacy considerations for sending queries to servers specified in an URL are applicable.

Where clients support the optional update feature in OSDs it affects the privacy of users.

The EcmaScript API AddSearchProvider() typically enforces a "same origin" policy for the OSD; the URL element within the OSD can designate a third party as search provider.

An OSD can claim to be a search description for X, but actually do something else.

Interoperability considerations:

OpenSearch descriptions use the http://a9.com/-/spec/opensearch/1.1/ XML name space, optionally in conjunction with other XML name spaces for extensions or for application specific purposes.

Published specification:

http://www.opensearch.org/Specifications/1.1/

Applications that use this media type:

Various Web browsers, search engines, and software libraries support OSDs. The "search" link relation is used on many Web pages with this media type.

The EcmaScript API AddSearchProvider() documented for WhatWG HTML uses this media type.

Additional information:

OSDs have no "magic numbers" as defined in RFC 4288. There are no special "common file name extensions" for OSDs, OSDs are XML documents. If specific extensions are desired the conventional ".osdx" or ".a9.xml" might do the trick.

Person & email address to contact for further information:

http://groups.google.com/group/opensearch http://www.opensearch.org/Community/Guidelines

Intended usage:

COMMON

Restrictions on usage:

None

Author:

DeWitt Clinton

Change controller:

http://www.opensearch.org/

4. Acknowledgments

As always John Klensin is an inspiration for all kinds of "process experiments" not limited to [RFC3933] and [RFC4897]. Thanks to Mark Nottingham for registering the "search" link relation, to Ian Hickson for documenting window.external.AddSearchProvider() in [WhatWG] HTML, to Sam Ruby for validating OSDs at http://feedvalidator.org/, and to DeWitt Clinton for specifying [OpenSearch] with the OpenSearch community.

Paul Libbrecht suggested to add a clipboard name and MAC OS9 file type code if applicable. Neither [RFC4288] nor [OpenSearch] offer any applicable info.

Thanks also to Henrik Levkowetz, Julian Reschke, and the "happy IANA" folks.

5. References

5.1. Normative References

5.2. Informative References

Appendix A. Document History

Changes in version 03:

• Fixed the bogus "no RFC" boilerplate used in version -02: Only this draft is not more intended to be published as RFC. Everybody is free to create derivative IETF drafts.
• Updated the credits based on a discussion on the mailto:ietf-types@iana.org mailing list.
• Updated the [WhatWG] reference; xml2rfc is notoriously hostile to any "as of today" concepts. Removed explanation that xml2rfc strict="yes" insists on the presence of Section 2.
• Checked [I-D.freed-media-type-regs] for suggested new tricks wrt clipboard names, MAC OS9 file type codes, or grandfathered media subtype name squatting in the standards tree.

Changes in version 02 (2011):

• Plan B: Nobody is going to write an RFC for this media type; especially nobody is going to create a formal XML DTD or similar definition above what is already documented in the OpenSearch 1.1 specification.
• [I-D.nottingham-http-link-header] replaced by [RFC5988]. Removed the registration of link relation "search", because that already happened based on [RFC5988].
• Removed everything related to RFCXXXX, this draft is not more intended to be published as RFC.
• Updated the credits. Populated the "TBD" placeholders in the template Section 3.

Changes in version 01 (2008):

• Move registry cleanup from Section 5 to the (hopefully) next [I-D.nottingham-http-link-header].
• Adopt registration template in [I-D.nottingham-http-link-header] replacing the similar [RFC4287] template.
• Some background info with examples parked in the introduction.

Initial version:

• This is a kind of template that could be extended to register rel="search" and application/opensearchdescription+xml if the OpenSearch community likes this approach.
• The change controller for a media type in the standards tree has to be a SDO (Standards Development Organization) recognized by the IESG or IAB on behalf of the IETF community, not necessarily the IETF itself.
• For atom:link relations IESG review is good enough. Informational IETF RFCs are approved by the IESG in a "document action", this would trigger the IANA considerations in Section 3.

Author's Address

Table of Contents

• 1. Introduction
• 2. Security Considerations
• 3. IANA Considerations
• 4. Acknowledgments
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Appendix A. Document History
• Author's Address