Re: Google, etc, and their proprietary protocols

Warren Kumari <warren@kumari.net> Fri, 27 November 2020 15:56 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57463A074B for <ietf@ietfa.amsl.com>; Fri, 27 Nov 2020 07:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=kumari-net.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 FOgiVwc2HqlC for <ietf@ietfa.amsl.com>; Fri, 27 Nov 2020 07:56:52 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 5F6033A064A for <ietf@ietf.org>; Fri, 27 Nov 2020 07:56:52 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id d20so7628005lfe.11 for <ietf@ietf.org>; Fri, 27 Nov 2020 07:56:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ah4nm4oHvHSV6FazKNLU5kboT9Tmqzby8uLd5jlblDY=; b=KG1opncrn8w0HYqzhTo9QGTQ7nQ+HMUvkvy/Uq2hey8Lgpj6cfn/kf7Z7gynkFyAjX eNwLojGjUf8QdEXP7RqGqlkKieWYE0IF02/cP0yrXlFnkQGC0KQ0yx4AnUtIyD9uuyFE gCsBa27brToiby84oiPFuwV3Wo+Wo7Prw0Fw1tmTmIpJhiaA44/uKZLMCiQwcBNWwbAp hwg5Q7SIaIrF8jL8M2KzZLR39snAMZ5xMreOWA1DQsBNpeUpHhswDEZy/f4bp1UwQBpI Qig2RVoC/NCzsHcdN7JPWXAa7c4S9vVsBr31dDYEKF0HNpTXuaWe4L1aKdzEWAaD/jm5 dbUw==
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; bh=Ah4nm4oHvHSV6FazKNLU5kboT9Tmqzby8uLd5jlblDY=; b=e9zZNbwEQH0RMjhlGeQphnCA2t6PE/WqBs0DEOR0EE9/NdFHQY7uYwhpWdjUWDPy9N BKM2COVeoMN72aML+Jjb1fInMxnEULCaq9mKtMUibOb3TQ9kmvdihKW6OSbVzMz6k616 Ox+KxBZu7GXrYbqgKxjcvPmUZghF15sVVjzb6uEPY4MjgYUfB6z+E0N/9a+H322ItiCL GI77wDOnfa52M5BneHeHumR5VcLoXw4D7YM4Rz66YVBpIf+swDle+b73GnOCUDpHXsWC xo6V7ZFVjyAh0CIrQs8vmlOn9y+E/Jev6C15DK45NBpr6VHfEo4i1SznxFpiOLocpwJG Cpsg==
X-Gm-Message-State: AOAM532EY19/Uqc/QjmijMGGDpO1VWfObG9iiPqBG5xs6utYbJm99Rbg 7PpXW/VGAAA+x/FR651dihVVangG7ZI9o7tZA3PIgs/Uksxa4Oyy
X-Google-Smtp-Source: ABdhPJwZG8f6TQHs9VUyWT7Gz8noTnJNAX/Lunq3METwZ2B8lKQTbn1g4wB1QrXk1/PNbzk0SeDO0xTAPmzDSq2GJhg=
X-Received: by 2002:ac2:568b:: with SMTP id 11mr3856527lfr.397.1606492610393; Fri, 27 Nov 2020 07:56:50 -0800 (PST)
MIME-Version: 1.0
References: <d00258b3-ef73-ee93-a47d-2831738d32d1@mtcc.com>
In-Reply-To: <d00258b3-ef73-ee93-a47d-2831738d32d1@mtcc.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 27 Nov 2020 10:56:14 -0500
Message-ID: <CAHw9_iLcYFkOuRgiyKLH-OnBs1i+Y-8L4ds3areJiT9EbxFs+w@mail.gmail.com>
Subject: Re: Google, etc, and their proprietary protocols
To: Michael Thomas <mike@mtcc.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/W9rrqZwsQBfVOQwcxJ0jxyKehgk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Nov 2020 15:56:54 -0000

On Thu, Nov 26, 2020 at 3:34 PM Michael Thomas <mike@mtcc.com> wrote:
>
>
> I know there are a whole lot of things that Google is doing for
> configuration, casting of urls (cf chromecast), etc which use
> proprietary protocols. Lots of other vendors are inventing the same or
> similar wheels. Can anybody tell me why these haven't been standardized?
> Is it politics? It sure is a PITA to not be able to send a URL to Apple
> Device or cast from Firefox onto my chromecast. I assume that this
> tangle applies for every other ecosystem like Apple and Amazon.
>
> Does anybody know the history and/or why we suffer this mess? I mean,
> the base level mechanisms seem pretty well understood.
>

Hi there,

So, there are a number of things at play here.

Firstly is that there many of the things which you are probably
viewing as "protocols" are more APIs/formats. In many cases these APIs
are very narrowly focused, quite specific (and so there isn't really
interoperability), and change frequently as new features are added,
etc. Keeping an IETF standard updated every time the API changes would
limit how quickly features can be added.

Publishing documentation on how to use an API on the
Google (internal) site is easy; standardizing through the IETF process
takes many months/years, often requiring travel, extensive time on
mailing lists, etc. One exception to this is QUIC. QUIC was started in
Google, but, because of the broad impact and interoperability to the
core plumbing of the Internet, it was clear that bringing it to the
IETF would result in a more widely deployed and used protocol.

Basically all drafts written by Googlers are because that individual
used some of their discretionary time to participate; often this
doesn't happen because none of the people working on $whatever felt
like there was utility in standardizing it, or because it seemed like
the benefit of having $whatever become an RFC was not worth the
time/effort/work.

I personally believe in the IETF and would like more Googlers to
participate and standardize things **if they are actually useful to
standardize**.


> Mike, cheers and happy T-day for those who celebrate it :)

Enjoy the leftover turkey / less email weekend :-)
W

>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf