Re: Last Call: The PPP Compression Control Protocol (CCP) to Proposed

[Vernon Schryver <[e-mail]>]

> ...
> Associated with the CPP protocol are the following ten internet-drafts
> which will be considered for publication as Informational RFCs:
> 
>  1. PPP Stac LZS Compression Protocol
>         <draft-ietf-pppext-stacker-05.txt>
>  2. PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol
>         <draft-ietf-pppext-hpppc-00.txt>
>  3. PPP Gandalf FZA Compression Protocol
>         <draft-ietf-pppext-gandalf-00.txt>
>  4. PPP Predictor Compression Protocol'
>         <draft-ietf-pppext-predictor-00.txt>
>  5. PPP BSD Compression Protocol
>         <draft-ietf-pppext-bsd-compress-00.txt

Why version #0?  That was years ago.
Version #5 of BSD Compress is already almost 5 months old.

>  6. PPP Deflate Protocol
>         <draft-ietf-pppext-deflate-00.txt>
>  7. PPP LZS-DCP Compression Protocol (LZS-DCP)
>         <draft-ietf-pppext-lzs-dcp-01.txt>
>  8. PPP Magnalink Variable Resource Compression
>         <draft-ietf-pppext-magnalink-01.txt>
>  9. PPP for Data Compression in Data Curcuit-Terminating Equipment (DCE)
>         <draft-ietf-pppext-dce-compress-00.txt>
> 10. PPP Serial Data Transport Protocol (SDTP)
>         <draft-ietf-pppext-sdtp-00.txt>
> 
> The reason that the various algorithm documents are not on a standards
> track is because patents apply to these and some represent businesses
> of their author's companies. There can, therefore, never be multiple
> interoperable implementations of same. The documents are structured in
> this way specifically to enable businesses to persue their courses with
> minimum impact of their patents and claims on the standard or the
> process that generates it.

Some minor points of fact:
    - I understand that some of those compression schemes are not
	covered by patents that have not expired (e.g. Deflate).
    - there are multiple completely independent implementations of some
	of the schemes that are covered by patents (e.g. Predictor has
	at least 3, probably 4, and perhaps more, although some of
	those Predictor implementations may no longer be in commercial
	production).
    - others of the compression schemes do involve businesses, 
	money, licenses, and so forth.

I am not objecting to publishing any of (the correct version of) those
drafts.  It's just that it is important to keep the facts straight.
IETF should not repeat the bogus nonsense of the trade press and some
salescritters that there is no such thing as interoperable,
non-proprietary PPP compression.

If you want to minimize the consumption of RFC numbers, you might want
to ask the authors of those drafts if there is any prospect there will
be even a single implementation.  There are one or two that I suspect
are orphans, now lacking interested parties and even a single
implementation.  Still, as Information RFCs, they might be interesting
historical reading, and I think they all should be published.


Vernon Schryver,  [e-mail]