Re: [dispatch] Proposed/draft charter for "mediaman"
John C Klensin <john-ietf@jck.com> Thu, 03 June 2021 17:46 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFB3A113B for <dispatch@ietfa.amsl.com>; Thu, 3 Jun 2021 10:46:15 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kzFXe-W00Yal for <dispatch@ietfa.amsl.com>; Thu, 3 Jun 2021 10:46:10 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCFE3A1137 for <dispatch@ietf.org>; Thu, 3 Jun 2021 10:46:10 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lorPx-000MxY-7P; Thu, 03 Jun 2021 13:46:05 -0400
Date: Thu, 03 Jun 2021 13:45:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>, Ned Freed <ned.freed@mrochek.com>
cc: DISPATCH list <dispatch@ietf.org>
Message-ID: <186D8E4B026BA2F7C3D54B2F@PSB>
In-Reply-To: <CAL0qLwZJ2nPaiFOWZf9SOPP3pAK5kmm8t1Xu7A36xiwJDd8_Jw@mail.gmail.com>
References: <CAL0qLwavrxxa=fdn48-F8Dt2qBDFEJyPoNjSkYOiHi-46k1Wtw@mail.gmail.com> <01RYY5BDVHVK0085YQ@mauve.mrochek.com> <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> <CAL0qLwZOvFqYtcXGV_bdHJ_PkUjJdGZJ+itoUxjF-4xYzgbDGQ@mail.gmail.com> <01RZSLCQGG9Y00IM2V@mauve.mrochek.com> <CAL0qLwZJ2nPaiFOWZf9SOPP3pAK5kmm8t1Xu7A36xiwJDd8_Jw@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/P4_zSmOzC3ePKaMjCeTYlJgVYNg>
Subject: Re: [dispatch] Proposed/draft charter for "mediaman"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 17:46:16 -0000
--On Thursday, June 3, 2021 08:21 -0700 "Murray S. Kucherawy" <superuser@gmail.com> wrote: > On Thu, Jun 3, 2021 at 7:57 AM Ned Freed > <ned.freed@mrochek.com> wrote: > >> > Revised based on feedback. If we're good to go here, I can >> > put it on the next review cycle. >> >> Better, but still some issues. My significant concerns are: >> >> (1) This doesn't prioritize the haptics work. (But if it's >> the consensus is not >> to do that so be it.) > It's the first thing on the list. I can't move it up any > higher. > > Would you suggest doing not only that, but explicitly saying > nothing else can be done until this ships? >... I was about to make exactly the opposite argument. Stepping back a few paces... (1) I believe that, at the time 6838 and it predecessors were written, there was a shared assumption that proliferation of top-level media types was not a good idea. The several rounds of discussion around haptics lead me to believe that assumption is now less generally shared and * that people who want top-level types, even if only because it makes them feel their work is important, should be able to have them and/or * that the argument that, if we don't allow people to register whatever they want, they will just squat on the names, causing potential uniqueness problems should prevail over more subtle considerations and tradeoffs. While haptics might well be appropriate as a top-level type under any criteria we might come up with, it seems that a key part of the work of the proposed WG is necessarily a review of those criteria (both explicit and oral tradition) and determining whether revisions or more explicit specifications are needed. Approving haptics as a top-level type and only then doing that review seems wholly inappropriate if only because haptics would presumably then be a precedent to be considered. (2) The main argument for putting haptics first in spite of the above is that doing so is a matter of urgency because of the interactions with pending ISO action. That argument might have been reasonable a couple of years ago, but is now OBE: the ISO actions and decisions are essentially set in stone and the window for IETF action having any effect on them has closed. If there are any substantive interactions left, we are playing catch-up. The squatting we would normally like to avoid has already occurred. While it would be better to catch up sooner rather than later, it is hard to believe that several months one way or the other will make any difference. Because a media type name structure has apparently already appeared in the ISO documents, we may have no choice other than to approve the registration. However, it still makes a difference whether we approve it as consistent with the policies we are developing or as an exception based on use and standardization elsewhere. So, to me. it needs to be "criteria review first, then specific cases, haptics included" not "haptics first and above all". Additional observation, which I have said before: if getting haptics registered is really of very high priority and the ISO work that would, in a better world, reference it, is, as we have been told, past the point where it can be changed, then my understanding of Section 3.1, option 2 of RFC 6838 allows a procedure that could be _very_ fast: (Step 1): If it has not already done so, IESG identifies the relevant ISO TC as a "recognized standards body". It is has already so identified all of ISO that way, this step is a no-op. (Step 2): The ISO TC or ISO/CS point to a specification (which need not be an RFC or I-D leading to on) and asks up to register the thing. (Step 3): The expert review process and/or IANA get to dicker with the ISO body about the adequacy of the specification if they conclude that is necessary. No WG required to address that particular registration (nor the time needed to set one up and have it reach decisions). So, to me, there are only two cases. Either this is urgent and ISO wants it or it doesn't. In the latter case, I don't see the case for urgency rather than due process and consideration by a WG. best, john john
- [dispatch] Proposed/draft charter for "mediaman" Murray S. Kucherawy
- Re: [dispatch] Proposed/draft charter for "mediam… Ned Freed
- Re: [dispatch] Proposed/draft charter for "mediam… Murray S. Kucherawy
- Re: [dispatch] Proposed/draft charter for "mediam… Martin J. Dürst
- Re: [dispatch] Proposed/draft charter for "mediam… Mark Nottingham
- Re: [dispatch] Proposed/draft charter for "mediam… Murray S. Kucherawy
- Re: [dispatch] Proposed/draft charter for "mediam… ned+dispatch
- Re: [dispatch] Proposed/draft charter for "mediam… Murray S. Kucherawy
- Re: [dispatch] Proposed/draft charter for "mediam… John C Klensin
- Re: [dispatch] Proposed/draft charter for "mediam… Mark Nottingham
- Re: [dispatch] Proposed/draft charter for "mediam… Murray S. Kucherawy
- Re: [dispatch] Proposed/draft charter for "mediam… Murray S. Kucherawy
- Re: [dispatch] [media-types] Proposed/draft chart… Martin J. Dürst
- Re: [dispatch] [media-types] Proposed/draft chart… Paul Libbrecht
- Re: [dispatch] [media-types] Proposed/draft chart… Murray S. Kucherawy
- Re: [dispatch] [media-types] Proposed/draft chart… Paul Libbrecht
- Re: [dispatch] [media-types] Proposed/draft chart… Alexey Melnikov
- Re: [dispatch] [media-types] Proposed/draft chart… Paul Libbrecht
- Re: [dispatch] [media-types] Proposed/draft chart… Murray S. Kucherawy
- Re: [dispatch] [media-types] Proposed/draft chart… ned+dispatch