On Wed, Oct 5, 2011 at 6:16 PM, Stephan Wenger <stewe@xxxxxxxxx> wrote: > Phillip, > Please see inline. > > On 10.5.2011 13:25 , "Phillip Hallam-Baker" <hallam@xxxxxxxxx> wrote: > >>I have some issues with the way that the section on IPR is written. >>While I agree with most of the statements there. I don't see my two >>biggest IPR concerns listed. >> >>1) Specific to this document, we already have unencumbered CODECs that >>permit encoding of audio and video with acceptable fidelity and >>adequate compression for 95% of all purposes. Thus it is essential >>that the IPR regime for any future CODEC strictly limits the cost of >>using that technique to some portion of the cost savings from >>reduction in bandwidth use. > > I disagree for technical reasons that have already been pointed out by > others. I would also suggest that something like AAC, according to your > theory, should have never happened (as it covers essentially the same > application space as MP3, with moderate gains in the quality/bitrate > tradeoff), but it a) was standardized--in the same body as MP3, and b) was > and is a commercial success, despite being quite expensive. I said that adopting a new encumbered algorithm would be stupid. At no time did I say that stupid did not happen. For evidence to the contrary see Planet:Earth Frequently IPR holders will attempt to prolong the validity of their patents by making minor tweaks of dubious technical value. What I said was that if any new CODEC is going to be accepted, the cost of using that CODEC must be strictly limited to the value that is provided in terms of limiting the number of bits required. In other words, I do not want to be paying for the patent that enables me to do Internet telephony since that can be achieved quite acceptably with no compression whatsoever. I may be willing to pay $X for a patent that allows savings significantly greater than $X. Unfortunately the current draft seems to me to be saying 'free is good but we might have to pay'. I think the presumption should be that there will be no payment for this particular application for reasons that go beyond the general preference for free. >>2) The principal concern I have with IPR licensing in general is not >>the cost of licensing but the difficulty of licensing. I have on >>several occasions been in negotiations with an IPR holder who is >>completely unable to decide how much money they want or on what terms >>they are willing to offer their IPR. > > The IETF is certainly not in the business of regulating how licensing > discussions are to be arranged :-) (Never mind that they can be quite > frustrating, as, apparently, both of us know). Again, mu law is seriously out of patent. No conversations with wolves or lawyers required. > All what you write above is true. > >>Taken in combination, I cannot imagine any reason to use any audio >>codec other than MP3 or AC2 (or some other similar legacy scheme) once >>we can be assured that the corresponding patents have expired. > > Well, many folks actually do license, under sometimes expensive terms, > protected technology, and use them to their benefit. MP3 became the standard for audio because it was the only widely supported option. Dolby Digital offered somewhat better fidelity and multi-tracks. But those technologies are close to twenty years old and the patents should be nearing expiry or have already expired. > Your email ends here. Now I'm at loss. > > Is your position that > A) the section on IPR be modified with an explanation of the commercial > constraints you have described, > B) the section be modified to gate the issue of an RFC defining an IETF > codec on terms compatible with YOUR commercial constraints you have > described, or > C) something else? I was arguing for A. If we are talking about IPR we are inevitably talking about commercial terms. I would like IPR holders in this space to understand that this is not going to be the normal patent beauty contest that has been the norm in this space for the past 20 odd years. I am quite aware of the licensing schemes employed in the MPEG world and really don't have much good to say about it. -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf