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]