IBM IPR Disclosure

2007-02-15 Thread James M Snell

All,

As a general FYI, IBM just filed a blanket IPR disclosure [1] relating
to the activity of the Atompub WG.  Before any misinformation starts
going around about this I thought it would be a good idea to give y'all
a heads up.

As of right now IBM has NO KNOWN patents or applications for patents
that read on the Atom specs.  However, as is well known, IBM has a
massive IPR portfolio and it would take a very long time and cost a lot
of money for us to dig through 'em all to know for certain.  Rather than
spend the time and energy doing that, IBM has agreed to a blanket
commitment to Royalty Free terms for any IPR that reads on the Standards
Track specifications produced by the atompub Working Group.

Again, I want to reiterate that there are no patents we are currently
aware of nor are there any applications in progress that we are
currently aware of.

There are basically two reasons we are doing this:

1. We think the Atom Syndication Format and the Atom Publishing Protocol
are really important.

2. We want anyone to be able to implement Atom without any fear of
patent hell (and we're really hoping that others agree).

I must add that I am not a IPR expert by any stretch of the imagination.
 If you have questions, please direct them to me and I will answer what
I can or I will forward them on to our IP Law experts.

- James


[1] https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=804



Re: I-D ACTION:draft-ietf-atompub-protocol-13.txt

2007-02-15 Thread Hugh Winkler


Re the type parameter (sec. 12): I earlier suggested to define file
extensions for feed and entry documents, and that suggestion got some
+1s and no objections.

Let me reiterate points:

1. If the "different processing models" models require we be able to
distinguish feeds from entries by mime types, then i we'll want to be
able to distinguish them using file extensions.  RFC 4288 has a place
for you to fill it in.

2. When you do that exercise you'll see that no existing software will
be able to map the mime type to the correct file extension. Existing
software can choose a file extension based on the major type/subtype
pair -- it will not parse out parameters looking for one named "type".
The transformation is not reversible -- we can go from file extensions
to mime types but not the other way.

3.  There will be no such problem if you simply choose a new subtype
to describe entry documents.

Hugh


--
Hugh Winkler
Wellstorm Development

http://www.wellstorm.com/
+1 512 694 4795 mobile (preferred)
+1 512 264 3998 office