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