Re: [rohc] IPR... again...

On Tue, Sep 02, 2003 at 06:23:41PM +0100, West, Mark wrote:
> 
> The thing that pains me about this is that it does affect the bits on the
> wire, as you have to re-order all the bytes in the header to be able to
> compute the CRC in two stages.  Hence my slightly facetious remark that we
> should just 'promise not to do it...'  By the standard you are obliged to
> re-order the fields as if you were going to do this but if, as in your
> implementation, you don't actually *do* the caching, I assume that this
> avoids the IPR..?
> 

Mark,

There are two separate issues here:

1.	Choice of header field ordering for CRC calculation.

2.	Caching the CRC when the static fields don't change.

Clearly (2) is the motivation for the ordering in (1).  However, anyone who
specifies the scope and algorithm for a CRC can arbitrarily decide ordering and
various other factors, such as interleaving, convolution, "salt", bit order,
byte order, etc.  So I don't see that any possible patent on the concept of a
CRC cache for partial CRC calculations (which have been around for over a
decade anyway) can somehow imply a patent on a particular field order.  

In other words, I don't see that an IPR issue on (2) implies an IPR issue on
(1).  If someone "owns" the method of incremental CRC calculation, that doesn't
imply that they "own" a particular order of header fields in a CRC calculation.

Once again, it's very difficult to see how anyone can patent everyday,
bog-standard engineering practices. 

> (See patent WO0207323 or 
> http://l2.espacenet.com/espacenet/viewer?PN=WO0207323&CY=gb&LG=en&DB=EPD 
> if you want to know more..!)

I must say that I am shocked by this. This is clearly in the intersection
of the categories "prior art", "obvious to those skilled in the art", and
"not very useful". I pity the poor company that has to prove these things
in court. The patent office shouldn't accept these shallow concepts.

> Well, I'd have thought so.  Again, for the curious, see patent WO0079763, or
> http://l2.espacenet.com/espacenet/viewer?PN=CA2375830&CY=gb&LG=en&DB=EPD
> for the gory details.

Once again, I am shocked. What does the Patent Office do apart from
clicking the "OK" button? By the way, did you know that about 12 months
ago, some guy in Australia patented the lever? Then a couple of weeks later,
someone patented the wheel! 

One effect of this sort of attempt to patent ROHC will be to prevent any open
source, free implementations from being published. Even a frivolous patent can
bankrupt a poor programmer. The IETF is not supposed to be a publishing house
for proprietary standards. IETF standards are supposedly open and free for
anyone to implement. If ROHC is the private property of a few big companies,
then this should be clarified so that other people can avoid it - and maybe
create a free and open robust header compression standard. If it becomes known
that ROHC is private intellectual property, then I think the general, wider
interest in it will decrease. When GIF file users were sued by Unisys, the open
source community created the PNG format. There are many cases where proprietary
protocols and formats have been substituted by the open source world. 

> My contention (hence my previous e-mail) is that a CRC over the compressed
> data, that is only used to verify that decompression of same succeeded, is
> (in fact) exactly what 'deflate', 'zlib', 'pkzip', ... do.

These CRC-equipped compression formats were published after a long history of
routine use of CRCs to check received files, I believe.  There have been many
programs like cksum, crc32, md5 etc. which have been used routinely in the unix
world for verifying correct receipt of uncompressed files. 

Software like "ssh" has always used compression, and has used very strong
checksums on the decompressed result. The same is true, I believe, of
bog-standard telephone modems, which do compression and checksumming to
verify correct reception. This is at least a decade old.

CRCs have been in the signal processing texts for many decades, as have also
compression algorithms. It's seems strange to me that anyone would
think of trying to patent such an obvious combination: compression + CRC.

> In order to move forward, though, we really need to determine what we can
> and what we cannot use for TCP compression.  (Which is my main motivation
> for pushing this thread -- although it will clearly tell us some things
> about RFC 3095, which is probably no bad thing...)

If the IPR issues are not satisfactorily clarified, only companies with
big legal departments will publish ROHC implementations.
In my opinion, there needs to be a process whereby the "little fish" can
get a solid assurance from the "big fish" that they will not be sued
for implementing and releasing RoHC implementations. Patents really
poison the whole market place so that little fish cannot breathe.
An invalid patent is as harmful as a valid patent to the little fish.

Cheers,
Alan.

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc