Subject: [ietf-types] Registration of media type application/opensearchdescription+xml

From: Frank Ellermann <[email-masked]>
Date: Thu, 20 Oct 2011 13:03:38 +0200

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 RFC 3023; especially "UTF-8" (RFC 3629) 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 OSDD (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
                   OSDDs it affects the privacy of users.

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

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

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

   Published specification:
                   <http://www.opensearch.org/Specifications/OpenSearch/1.1>

   Applications that use this media type:
                   Various Web browsers, search engines, and software
                   libraries support OSDDs.  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:
                   OSDDs have no "magic numbers" as defined in RFC 4288.
                   There are no special "common file name extensions" for
                   OSDDs, OSDDs are XML documents.  If specific extensions
                   are desired ".a9.xml" (or similar) 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/>

---

From: Paul Libbrecht <[email-masked]>
Date: Tue, 25 Oct 2011 08:54:44 +0200

Frank,

My comments are that of a dilletante in the field. 
I hope someone will review the formal aspects of the procedure.

This is an interesting registration and it seems to be in good shape.

My usual suggestion is: what about clipboards? 
OpenSearch Description Documents sound to be a natural candidate to be exchanged in clipboards (be copied-and-pasted, be drag-and-dropped, ...). Do I mistake?
Hence I would like to suggest you add two lines in the additional information section such as the following:
- Windows Clipboard Flavor Name: "OpenSearch Description Document"
- Macintosh Uniform Type Identifier: org.opensearch.description conforms to public.xml

My guts feelings about the "responsibility" part of the registration is that it lacks a tiny bit of formality:
- isn't the WhatWG HTML a "place" for drafting a format that will hopefully end up be a W3C standard? I would prefer a W3C document to be referred to.
- a google-group as the contact is really volatile. Is there no way to put a legally registered entity instead? I think even a9.com would be better. 
- Similarly http://www.opensearch.org/ is rather a volatile change controller. Provided a domain is more or less what its whois entry is, it means A9.com is the controller (the registered company in the US). Rather say that.

paul

Le 20 oct. 2011 à 13:03, Frank Ellermann a écrit :

> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 25 Oct 2011 17:10:16 +0200

> I hope someone will review the formal aspects of the

RFC 4288 guarantees an IETF Last Call for this beast if
it ever gets this far.  I've tried to submit an updated
"not for RFC" Internet Draft, but that's still stuck in
a manual submission queue.

RFC 4288 also guarantees (or rather demands) a complete
copy of the registration template in whatever passes as
specification, RFC or otherwise:

<URL:http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_5#MIME_type_application.2Fopensearchdescription.2Bxml>

Content and/or URL might change during the review here.

The OpenSearch folks suggested to replace OSDD by OSD,
and to add ".osdx" as the conventional file extension:
Microsoft uses ".osdx".

I'm not interested to "invent" wild + wonderful features,
I'm only interested to get this beast registered "as is".

> My usual suggestion is: what about clipboards?

Dunno, is there any problem with XML and clipboards?

> OpenSearch Description Documents sound to be a natural
> candidate to be exchanged in clipboards (be copied-and
> -pasted, be drag-and-dropped, ...). Do I mistake?

All I ever wish to do with OSDs is (1) edit some details,
or wrt the security considerations inspect their source,
(2) adopt an OSD when the auto-detect link rel="search"
worked as it should, (3) click on an AddSearchProvider()
EcmaScript link for cases where link rel="search" is no
option.  Where do clipboards enter this picture for you,
and is it relevant for the IANA media type registration?

> - Macintosh Uniform Type Identifier:
> org.opensearch.description conforms to public.xml

Sadly I've no idea how Mac Uniform type identifiers work,
and the info published in RFC 4288 convinced me that it's
not something to worry about.  If you have any "official"
public source that this is a well-known Mac id. I add it,
otherwise I prefer to stick to what I could defend in an
IETF Last Call.

> My guts feelings about the "responsibility" part of the > registration is that it lacks a tiny bit of formality:
> - isn't the WhatWG HTML a "place" for drafting a format > that will hopefully end up be a W3C standard?

AddSearchProvider() is documented in WhatWG HTML.  Both
the HTML5 draft and WhatWG HTML have a reference to the
OpenSearch 1.1 spec.  The rel="search" link relation is
registered for about a year.  Oh yes, there is this tiny
bit of "happiana" and RFC 4288 standards tree, but "let's
see what happens" (before giving up on this registration).

> - a google-group as the contact is really volatile.

Well, it's how the OpenSearch community works, they have a
MediaWiki installation with talk pages, and a mailing list
hosted by Google groups.  For at least five years, I can't
tell how it was when this work was still hosted by A9.com.
AFAIK Amazon still donates the domain, and they certainly
donated the OpenSearch XML name space URI some years ago.

> Is there no way to put a legally registered entity
> instead? I think even a9.com would be better.

I'm trying to register a well-known media type used in all major
browsers and on many web pages, but I cannot claim
that I try this on behalf of A9.

The OpenSearch.org folks know that I want this media type
to be registered since I-D.ellermann-opensearch-00 (2008),
and so far nobody had objections.  Sadly there were no
volunteers to create an RFC, and the proposal to create a
DTD for a future RFC died in a resounding silence.

> - Similarly http://www.opensearch.org/ is rather a
> volatile change controller.

This actually is the "change controller" for some years,
but IANAL and certainly not speaking for A9.

-Frank

<URL:http://www.opensearch.org/User:Xyzzy>
<URL:http://www.opensearch.org/Specifications/License>