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 >
- [Cellar] Conversation about a NON-IANA request in… Spencer Dawkins at IETF
- Re: [Cellar] Conversation about a NON-IANA reques… Spencer Dawkins at IETF
- Re: [Cellar] Conversation about a NON-IANA reques… Murray S. Kucherawy
- Re: [Cellar] Conversation about a NON-IANA reques… Michael Richardson
- Re: [Cellar] Conversation about a NON-IANA reques… Murray S. Kucherawy
- Re: [Cellar] Conversation about a NON-IANA reques… Michael Richardson
- Re: [Cellar] Conversation about a NON-IANA reques… Murray S. Kucherawy
- Re: [Cellar] Conversation about a NON-IANA reques… Michael Richardson
- Re: [Cellar] Conversation about a NON-IANA reques… Steve Lhomme
- Re: [Cellar] Conversation about a NON-IANA reques… Michael Richardson
- Re: [Cellar] Conversation about a NON-IANA reques… Steve Lhomme