Is OpenSearch on life support?
BrandonLive
of Draft 4 went unanswered, and it has been ages since Draft 3 was
posted.
E-mails to Dewitt about OpenSearch have gone unanswered as well.
Dewitt, if you read this - I understand if you're too busy with other
work to focus on OpenSearch any longer. But have you considered
looking for others to take over ownership of the standard? Or sharing
ownership of it with others?
Andrew Turner
that it is relatively stable and actually quite commonly used though
transparent to many, that there isn't much traffic/discussion on the
list.
DeWitt has been very open to contributions by anyone. So the spec is
already available for everyone to modify or help out with. In fact,
there is a lot of discussion about OpenSearch going on in other
standards bodies (OASIS and OGC to name two I am familiar with).
Andrew
BrandonLive
this forum :)
OpenSearch is quite commonly used in the most basic, limited ways.
Implementations of it vary wildly. Just look at the other post I made
today. The number of varied interpretations and behaviors is
staggering.
It's been ages since Draft 3 was posted, and many many months since
Dewitt posted that Draft 4 would be available "soon." Well over a
year ago a colleague and I made suggestions for Draft 4, which Dewitt
seemed to like and said would be included in it. But here it is more
than a year later and Draft 4 and those contributions are nowhere to
be seen.
Brandon
DeWitt Clinton
My hope for the OpenSearch specs is to get the IPR cleaned up using the Open Web Foundation incubation process in the near future. Not a whole lot to do there, but it's a necessary next step to ensure the patent non-asserts/licenses are in place from contributors and that we can demonstrate a diverse community of contributors. The first part (ipr) is going to be the harder of the two as there are already a good number of contributors to demonstrate diversity and openness.
After that, I wouldn't mind seeing this go through the IETF, and would personally prefer that over OASIS.
But, and I don't think anyone will disagree here, I'm not personally giving the spec enough time or attention to be the sole editor. I hope people didn't think I was discouraging other people from taking a whack at it.
One thing that would greatly facilitate progress on the next draft would be a volunteer to convert Draft 3 from Mediawiki syntax into RFC XML source form. We could then check it into a source code repository and manage and edit drafts there. We could have one canonical master draft copy, and any number of propose drafts to merge from. (I hate Mediawiki as a spec management tool passionately at this point. That alone has kept me from touching the spec in a year.)
-DeWitt
Ed Summers
and would be interested in working with others to make that happen.
//Ed
DeWitt Clinton
The best way to get this moving, in my opinion, would be for someone to take that first pass at converting the spec to RFC format. It will be best if we don't make normative changes during this first stage -- so a 1 for 1 mechanical transformation is in order. We can call this parity preserving version "Draft 4", then start down the path of the adding new (backward compatible) additions in "Draft 5". Once we're happy, let's lock that down, call it 1.1 Final. Backward compatibility breaking changes (including xml namespace changes) should at least be a 1.2.
I've gone ahead and registered the 'opensearch' project on Google Code:
http://code.google.com/p/opensearch/
We can use this project to edit draft copies of the spec prior to publication and maintain reference implementations and libraries. This gives us a SVN repository, an issue tracker, and a lightweight wiki as we need them. We can publish the final versions on www.opensearch.org.
I'll add people to the project as requested. As a first pass and a way of seeding contributors, if your name is on the existing spec, then please send me an email -- you're automatically getting write access to the project.
Ed, if you want to take a stab at the initial conversion then let me know and we'll hook you up with write access as well.
Open to any and all suggestions as to how to do this better. Thanks, everyone!
-DeWitt
Frank Ellermann
> there is a lot of discussion about OpenSearch going on in other
> standards bodies (OASIS and OGC to name two I am familiar with).
Just in case, the project to register rel="search" and the MIME
type application/opensearchdescription+xml in the relevant IANA
registries also isn't dead, but admittedly at the point where I'd
need some missing info in the draft:
See <http://tools.ietf.org/html/draft-ellermann-opensearch> for
version 01, now based on another draft reorganizing the IANA
"link relation registry" (was atom only, will be atom + http).
An existing schema recognized here would also help. There are
two existing schemas, but I can't judge if they are good enough.
Frank
BrandonLive
I'm on vacation right now, oddly enough, but when I'm home later this
week I'll take a look and see if I can lend a hand.
Frank Ellermann
> My hope for the OpenSearch specs is to get the IPR cleaned up
> using the Open Web Foundation incubation process in the near
> future.
Dunno what that is, but it is likely important. If you intend
to get one or more RFCs within the IETF framework, they have a
"note well" procedure. You can put this list under "note well"
by requesting its addition to the "list of other IETF lists"
below <http://www.ietf.org/maillist-new4.html>.
Actually at the bottom of the next page. The "note well" is
right below the IETF main page if you click on mailing lists:
<http://www.ietf.org/maillist.html>
In the request form you need a topic, e.g., write rel="search"
and application/opensearchdescription+xml standardization.
You'd also pick an area, that's "applications", and the IETF
area director (Lisa or Chris) for the request. My impression
is that this topic might be better suited for Lisa. After
the area director (hopefully) acknowledged the request this
list will be added to the "list of other IETF lists", that is
actually all that happens. The interpretation of "note well"
is left as an exercise for the list owner and requestor, for
all normal cases. Unless somebody starts to sue, then this
might be interpreted by a court.
All "contributors" are supposed to submit any IPR (including
patents) affecting the work on IETF lists and in IETF drafts
that they are aware of on an IETF Web form for this purpose.
"Contributor" is anybody posting here, and talking about any
IETF work not limited to the drafts developed here. Or in
other words, it boils down to "if you know a relevant patent
you have to say so", but IANAL (= reading the IETF IPR list
doesn't count).
Frank
DeWitt Clinton
As background to my earlier comments, the Open Web Foundation discussion is going on over at:
http://openwebfoundation.org/
And on the public mailing list at:
http://groups.google.com/group/open-web-discuss
The (forthcoming) OWF IPR policy will be a little more stringent and will offer more assurances to implementers than the IETF technically requires, in that it will seek patent non-asserts/licenses from contributors, and an up-front CLA. But we anticipate this process will be completely compatible with the IETF requirements, which in turn include some things that the OWF does not, like disclosure.
Note that I personally have no ability to influence Amazon at this point. They currently hold (though to the best of my knowledge, have not enforced) the OpenSearch trademark and have made no claims one way or the other about patents. That said, Amazon offered the existing specification under a Creative Commons 2.5 BY-SA copyright license, which is a very good start, and could be taken as a signal of their good faith intentions to continue to promote OpenSearch as an open web standard. We will be relying on Amazon's continued good will to do the right thing going forward. (If someone from Amazon is reading this, please feel free to ping me off-list.)
As a community we've learned over the past several years from similar specifications, like OpenID and OAuth, and now I'd simply like to apply those best practices to this specification.
-DeWitt
DeWitt Clinton
If not, no worries, I'll try and start on that myself soon. I just don't want to duplicate the effort if someone else has it in progress.
Cheers,
-DeWitt
Frank Ellermann
> Just wanted to tickle this thread to see if anyone is working
> on porting the spec over to the RFC XML format.
> If not, no worries, I'll try and start on that myself soon.
> I just don't want to duplicate the effort if someone else has
> it in progress.
One assumption in the "registration draft" was that the real
specification is "elsewhere", e.g., where it is today, not in
an RFC.
If you intend to put the "real specification" in a RFC this
memo can also tackle the business of two IANA registrations:
1 - The link-relation "search" either for Atom (as in the
00 registration draft), or for HTTP and Atom (as in the
01 registration draft based on Mark's draft).
2 - The MIME type registration (in both registration drafts)
IMO it makes no sense to have two different drafts, just copy
what you need (roughly everything ;-) into the new draft for
the "real spec." plus minor registration issues.
As mentioned off list, just grab the existing XML source at
http://hmdmhdfmhdjmzdtjmzdtzktdkztdjz.googlepages.com/draft-ellermann-opensearch-01.xml
You'd have to rewrite the abstract, rename the file and the
draft, restart from 00, fill in your name, and replace all
vague references to an "expernal" specification by the magic
word for "this RFC" &rfc.number; shown as "RFCXXXX" in the
xml2rfc text output.
What's most needed is a schema, or if all else fails a DTD.
I'm willing to tackle the latter, but only as last resort,
DTDs are in direct conflict with the idea of extensions by
namespace.
Frank
--
See <http://tools.ietf.org/html/draft-ellermann-opensearch>