Re: [Cellar] compression libraries in IETF specifications (was Re: [cellar-wg/matroska-specification] deprecate LZO compression (#376))

Steve Lhomme <slhomme@matroska.org> Fri, 22 May 2020 13:23 UTC

Return-Path: <slhomme@matroska.org>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6399A3A02BE for <cellar@ietfa.amsl.com>; Fri, 22 May 2020 06:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCQo6o-o0fvV for <cellar@ietfa.amsl.com>; Fri, 22 May 2020 06:23:17 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C953A00D2 for <cellar@ietf.org>; Fri, 22 May 2020 06:23:17 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id f6so5008533pgm.1 for <cellar@ietf.org>; Fri, 22 May 2020 06:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lPOn+/QLJVQ1SrTIZFfHltFmvN8BNEPk8pCY3QsvN7o=; b=y41URdXXSd/WtJn7r+gKEkWytv2NctZE2Wu43bDIKMZ+c2uXJTit+clvdPkJ1mCVNN cAhc6yVMjLjRM5d1gufCMBXeJpRIy0n9oNbQs3lofI2Vo9bUwpM6wBtjf1CNACsTKLfI A/ma8iRCWUdcGmptgaRjYlR18kwTu4UtXgJpD4iHZL/levPKQ0WmFmG3nReAbDoHEL7h Pt8iTyunqr+KaHMl9OeLfYBS8lO4ULu6IOA/cija1jbhyYdoICQ01y+5pKeCgnkhI0E0 H3zQu5t3oZSKwE7+ktMMzHOiun2Ljjp25KT6j6EqyBWQKixpnfywbwpyp+7K4yzj2g07 mVaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lPOn+/QLJVQ1SrTIZFfHltFmvN8BNEPk8pCY3QsvN7o=; b=C2DEfG5jEDPP5AaiXaOW6fdl8MxG065jiX1m0f19n+DRJkPyibqR9y2U5pGCqFLEoe Y95DEcib80Lurg5b0boZ3QvSiVfBj6Wyvgd4ipYoAqPZjTQDVIk1A2byc/PE9SkOyilb CLN+hgMEcP0Qzx9PyODH9a4vjJhB1XNFd/3Kzk2SKSXMufZzlhnXPQCitAOIRV4ePnkd 5gOCdYTIOBvLNy6Pa1Rb4iY+83GvcPn0Ym2WkEpKU9bD7r9oHZTIl7sq2hiYmSx9bGDF bkrO7IYpVJHWuZeTV4nESSKqXKNgpLRXqlqtWHUtJJBJPomDFBC8UCRtg4APPcNgCAwS nRyQ==
X-Gm-Message-State: AOAM533M0Xk7Xnp6LpK61g+B/RYCzhqRsXUe/uzKVJ2LMKHssnJz69Ng WT8d1MpDnzFVLG+HV2llcthYpkDyoH0gqQlbQPk81w==
X-Google-Smtp-Source: ABdhPJzi9wproK+WRrYu0faCm/BK/gKrAnASN9ymb1P3DNdjZvhfdP+H4puINsr2xg0ccUfmSFaUMlzjyafC0Tu93Zk=
X-Received: by 2002:a63:ca45:: with SMTP id o5mr1199515pgi.103.1590153795883; Fri, 22 May 2020 06:23:15 -0700 (PDT)
MIME-Version: 1.0
References: <cellar-wg/matroska-specification/issues/376@github.com> <24830.1588522227@localhost> <CAKKJt-dxwwWpOHweAFDOEnAvpOi5dnT1c8rtd-NwZYp-AU+Obg@mail.gmail.com> <c32608ad-85c3-b487-3359-0edd77850f12@nostrum.com>
In-Reply-To: <c32608ad-85c3-b487-3359-0edd77850f12@nostrum.com>
From: Steve Lhomme <slhomme@matroska.org>
Date: Fri, 22 May 2020 15:23:04 +0200
Message-ID: <CAOXsMF+4VghQ_AtKQsDaRx3xkTB5h3N7S54WsbYZBXnnt3B4cA@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Michael Richardson <mcr@sandelman.ca>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/ccu9TJXrbPIM694RqdHe8ExfNeM>
Subject: Re: [Cellar] compression libraries in IETF specifications (was Re: [cellar-wg/matroska-specification] deprecate LZO compression (#376))
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2020 13:23:21 -0000

I hope we don't have to get to this point.

In Matroska we (currently) have 4 compressions:
- header compression: stripping the same bytes at the beginning of
each frame, not sure if there's a patent/license issue on that. It was
clearly designed in "clean room" (no knowledge of existing other
formats doing that).
- zlib: designed to have patent issues (and used widely for
everything, even PNG ?) https://www.zlib.net/zlib_faq.html#faq31
- LZO which at least has some documentation in the Linux Kernel. I
wouldn't imagine they would use that it there was any issue.
- bzlib, which is fact bz2 an evolution of bzlib to avoid patents
(https://en.wikipedia.org/wiki/Bzip2), also used very widely.

My main concern was that LZO did not have a freely usable
implementation (official being GPL or commercial) but then I found
some more libs capable of that. So at least for implementation they
all have free (as in everything) implementations.

As for patents do we have to put some text that we believe their not
covered by patents ?

Le mar. 5 mai 2020 à 23:18, Adam Roach <adam@nostrum.com> a écrit :
>
> On 5/5/2020 3:43 PM, Spencer Dawkins at IETF wrote:
>
> Hi, Michael,
>
> On Sun, May 3, 2020 at 11:10 AM Michael Richardson <mcr@sandelman.ca> wrote:
>>
>>
>> Hi, I wanted to bring this item to the list's attention.
>>
>> Spencer: I seem to remember that the IETF has had compression IPR issues in
>> specifications in the past.  IPCOMP comes to mind, but I am guessing that
>> other RTP/SIP groups have gone through this..
>
>
> I had forgotten IPCOMP, but was remembering RoHC and RoHCv2. I think you're remembering SIGCOMP.
>
>
> Probably not: SIGCOMP sidestepped this specific issue altogether by normatively specifying precisely zero compression algorithms. It instead defined a virtual machine that message recipients would implement, and to which message senders would send bytecodes sufficient to decode subsequent messages.
>
> /a
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



-- 
Steve Lhomme
Matroska association Chairman