]> xyzzy

Hamburg Germany hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com http://purl.net/xyzzy/

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

This draft suggests to register theapplication/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 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".

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

Below you find the registration template for the subtype "opensearchdescription+xml" of the "application" media type under : application opensearchdescription+xml There are no required parameters. charset (defaults to "UTF-8") Identical to those of "application/xml" as described in ; especially "UTF-8" 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). 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. OpenSearch descriptions use the XML name space, optionally in conjunction with other XML name spaces for extensions or for application specific purposes. 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. 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. COMMON None DeWitt Clinton

As always John Klensin is an inspiration for all kinds of "process experiments" not limited to and . Thanks to Mark Nottingham for registering the "search" link relation, to Ian Hickson for documenting window.external.AddSearchProvider() in HTML, to Sam Ruby for validating OSDs at , and to DeWitt Clinton for specifying with the OpenSearch community. Paul Libbrecht suggested to add a clipboard name and MAC OS9 file type code if applicable. Neither nor offer any applicable info. Thanks also to Henrik Levkowetz, Julian Reschke, and the "happy IANA" folks.

&rfc3023; &rfc3629; &rfc4288; Google &rfc3933; &rfc4287; &rfc4897; &rfc5988; Google &bis4288;

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 mailing list. Updated the reference; xml2rfc is notoriously hostile to any "as of today" concepts. Removed explanation that xml2rfc strict="yes" insists on the presence of . Checked 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 . Removed the registration of link relation "search", because that already happened based on . Removed everything related to RFC&rfc.number;, this draft is not more intended to be published as RFC. Updated the credits. Populated the "TBD" placeholders in the template . 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 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 .