F. Ellermann
Internet-Draft xyzzy
Intended status: Informational October 21, 2011
Expires: April 23, 2012
The application/opensearchdescription+xml media type
draft-ellermann-opensearch-02
Abstract
This draft suggests to register the
application/opensearchdescription+xml media type for OpenSearch
descriptions. Atom and XHTML 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. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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 April 23, 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.
Ellermann Expires April 23, 2012 [Page 1]
Internet-Draft OpenSearch Description October 2011
1. Introduction
This draft suggests to register the
application/opensearchdescription+xml media type for OpenSearch
descriptions. Atom and XHTML elements are
examples where this media type is used.
It can be discussed in or
on the 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
See below (Section 3). There used to be a way to create "not for
RFC" Internet drafts with xml2rfc, this section is required for
strict="yes" processing.
3. IANA Considerations
Below you find the [RFC4288] registraton template for the subtype
"opensearchdescription+xml" of the "application" media type under
:
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).
Ellermann Expires April 23, 2012 [Page 2]
Internet-Draft OpenSearch Description October 2011
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
XML name
space, optionally in conjunction with other XML
name spaces for extensions or for application
specific purposes.
Published specification:
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:
Ellermann Expires April 23, 2012 [Page 3]
Internet-Draft OpenSearch Description October 2011
Intended usage: COMMON
Restrictions on usage:
None
Author: DeWitt Clinton
Change controller:
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 , and
to DeWitt Clinton for specifying [OpenSearch] with the OpenSearch
community.
Thanks also to Henrik Levkowetz, Julian Reschke, and the "happy IANA"
folks.
5. References
5.1. Normative References
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", BCP 13, RFC 4288,
December 2005.
[OpenSearch] Clinton, D., "OpenSearch 1.1", 2011, .
5.2. Informative References
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", BCP 93, RFC 3933, November 2004.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005.
Ellermann Expires April 23, 2012 [Page 4]
Internet-Draft OpenSearch Description October 2011
[RFC4897] Klensin, J. and S. Hartman, "Handling Normative
References to Standards-Track Documents", BCP 97,
RFC 4897, June 2007.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[EcmaScript] "ECMAScript Language Specification Edition 5.1", ecma
international Standard ECMA-262, June 2011, .
[WhatWG] Hickson, I., "HTML Living Standard -- Last Updated 20
October 2011", 2011, .
[XML] Paoli, J., Bray, T., Maler, E., and C. Sperberg-
McQueen, "Extensible Markup Language (XML) 1.0 (Second
Edition)", World Wide Web Consortium
Recommendation REC-xml-20001006, October 2000,
.
[XML-names] Thompson, H., Layman, A., Bray, T., Hollander, D., and
R. Tobin, "Namespaces in XML 1.0 (Third Edition)",
World Wide Web Consortium Recommendation REC-xml-names-
20091208, December 2009,
.
Appendix A. Document History
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):
Ellermann Expires April 23, 2012 [Page 5]
Internet-Draft OpenSearch Description October 2011
* 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
Frank Ellermann
xyzzy
Hamburg, Germany
EMail: hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com
URI: http://purl.net/xyzzy/
Ellermann Expires April 23, 2012 [Page 6]