Re: [Cellar] Conversation about a NON-IANA request in Matroska

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 19 August 2021 21:14 UTC

Return-Path: <superuser@gmail.com>
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 1F1863A095F for <cellar@ietfa.amsl.com>; Thu, 19 Aug 2021 14:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 hgoAtsk4TMov for <cellar@ietfa.amsl.com>; Thu, 19 Aug 2021 14:14:30 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 7F1E73A0953 for <cellar@ietf.org>; Thu, 19 Aug 2021 14:14:30 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id i1so4893003vsk.8 for <cellar@ietf.org>; Thu, 19 Aug 2021 14:14:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aYy/3kFGIypQ6khHaEhVr7vyyC7UzcSVmKvmQQ6ZBnw=; b=Ld8yY9+M08uKmUyT400zuvgxFEY9VhM+TgHv24pPnQIWIuvoM4uyl4oEFcWBpp1HiC 9ID1aNMEuMDOBgIg3kj/q82LECp4CuuiqXbMzRe59Y3eFSbLwQXpImVwXdWMGSj6urpH N/n/X/T7DzUW95te3Xhk74wmzQi6/ycTDARD0qwtV9z4JdRSM4XqNvSOUN54eK1CttoE 2tEz7vuHP3T4a3UHbQukVnXXZyhrM4Re3UxZzRSHZD6HkOPQqoXXahPkyZh+0YyH72nw klW3jb8/WuCGRkYgn9CVQCwho14Io8XnpjOhjy6jNQiu46+Oc9zue5DMT/WJqJaiyTmn FQbw==
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=aYy/3kFGIypQ6khHaEhVr7vyyC7UzcSVmKvmQQ6ZBnw=; b=Pnf6pbEJoke8KmE8qhZLqTwxWeG8mDLKiC+GRY/fOQoWQPpmAFXpd3N80TwCb8qKH0 hfJSeL/B18Zkmy3bZ9o41gA2RziH8IFPfIqSy/DQSm20E3CLJe4e3NR9NQ1CcQCLokUc co8+pHknohVemN3eioKJ4Vqtbj+Ul27PiMRHGbpuElDR+zyXGoZW7ogBrZxme+63c+mi osEG/NwYAXmdtzv1H9hts5p9xTFcGyHbZ0BYtpHUb39Yk84zuD54vdYmHgCOfV+Rzi4B v1NY1qeELrAbJR3brHhgqpVC1HYgKPkZoxQ7qp4L4T1Jj8hdDV5YJeCwEA6qcZKqgexc cmYw==
X-Gm-Message-State: AOAM530LrLm60Hd708mtNy2Ud52pR6hARVS1SEwCcz55PbulW/fD47sg NUNbxfwnllHrxMz4fFFGS8zlIzHn4eU7TlNR6SY=
X-Google-Smtp-Source: ABdhPJxrTrW6Ge3Xi2em0uMNyFCjCbj6/m3sl3o1pkwcDy41NOA/KaOxgjyKO6j4X7F6RvLwrg+8ml8QDrF+R2vBHCM=
X-Received: by 2002:a67:df0c:: with SMTP id s12mr14563381vsk.0.1629407667844; Thu, 19 Aug 2021 14:14:27 -0700 (PDT)
MIME-Version: 1.0
References: <CAKKJt-ceukRCPUK=DTvDxDBPw-ddROX-snfZQ-BatSkgVZ0-qw@mail.gmail.com> <CAL0qLwY6V8eVG56ckhy3GFDwW61-6OD9_h=X-vDWFySM0e3B9A@mail.gmail.com> <4945.1629386506@localhost> <CAL0qLwZeE1qZ+5wLnCMFoCcvP2cf5=9Y+g5Lx3k5iqxF7gAw5g@mail.gmail.com> <22109.1629403274@localhost>
In-Reply-To: <22109.1629403274@localhost>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 19 Aug 2021 14:14:16 -0700
Message-ID: <CAL0qLwbUk7QLiCEESqbEknUELSgure+MrdvLXBK+hkRV_GxVxQ@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>, Francesca Palombini <francesca.palombini@ericsson.com>
Content-Type: multipart/alternative; boundary="0000000000003c7c3305c9f009c2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/GqVyzx0kOKq8RBhGYf_KyZYWwts>
Subject: Re: [Cellar] Conversation about a NON-IANA request in Matroska
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: Thu, 19 Aug 2021 21:14:36 -0000

What I'm worried about is that picking a date effectively sets a flag day.
Have we ever successfully asserted a flag day in a standards action before?

But then the IETF has no control over whether anyone adheres to it, making
it effectively arbitrary anyway.

-MSK

On Thu, Aug 19, 2021 at 1:01 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Murray S. Kucherawy <superuser@gmail.com> wrote:
>     >> Implementations MUST accept both in perpetuity.  (that's easy to
>     >> implement, and it's an archive format, so disk files and resource
>     >> forks...)
>     >>
>     >> Until 2025, implementations SHOULD use video/x-matroska when
> creating
>     >> files.  After 2025, implementations SHOULD use video/matroska when
>     >> creating files.
>     >>
>     >> (or another year sufficiently far in the future)
>     >>
>
>     > If you're going to register "x-dash" on the basis of indeterminate
>     > inertia, I would argue the "dash" one isn't worth registering.
>
> okay.
>
>     > I would encourage something like:
>
>     > - register "dash", indicating it is the current and the only
> officially
>     > supported one
>
>     > - register "x-dash", indicating that it's officially
>     > deprecated and new implementations MUST NOT generate it
>
>     > - indicate that
>     > for supporting legacy implementations, all implementations SHOULD
>     > accept both
>
>     > At some point in the future if/when you are convinced nothing
> generates
>     > "x-dash" anymore, you could do an update that turns "x-dash" into an
>     > error.
>
> That's why I suggested a transition date, so that this process could be
> essentially automatic.  Readers would have some time to catch up.
>
> If readers will never catch up, then I agree, just go with "x-dash",
> although
> it sets a weird precedent to me.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>