Re: [media-types] [dispatch] [art] Status of Haptics I-D in DISPATCH?

John C Klensin <john-ietf@jck.com> Tue, 04 May 2021 02:09 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7A53A1E94; Mon, 3 May 2021 19:09:34 -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 TfbQ8byq1-oW; Mon, 3 May 2021 19:09:30 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 F25C33A1E93; Mon, 3 May 2021 19:09:29 -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 1ldkV6-000OXt-LR; Mon, 03 May 2021 22:09:28 -0400
Date: Mon, 03 May 2021 22:09:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, media-types@ietf.org
cc: art@ietf.org, ART ADs <art-ads@ietf.org>, dispatch@ietf.org
Message-ID: <0383D07402EB596076C1BD22@PSB>
In-Reply-To: <A4981D8A-B155-4FCA-889B-9737B496D1BA@ericsson.com>
References: <C1D837ED-4EB1-4C69-BA7F-7269B111A002@ericsson.com> <FB16C435B6EFF84534985905@JcK-HP5> <alpine.OSX.2.20.2105031645070.824@mac-allocchio3.garrtest.units.it> <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <A4981D8A-B155-4FCA-889B-9737B496D1BA@ericsson.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/media-types/bJ2qWxSQl7B0BPx0auxDZgo7_fA>
Subject: Re: [media-types] [dispatch] [art] Status of Haptics I-D in DISPATCH?
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2021 02:09:35 -0000


--On Monday, May 3, 2021 16:13 +0000 Francesca Palombini
<francesca.palombini=40ericsson.com@dmarc.ietf.org> wrote:

>...

>> (0) This haptics top-level type.
>> 
>> (1) The proposal to allow multiple media type suffixes.
>> 
>> (2) Media types for programming languages
>> 
>> (3) Improved guidelines for constructing media type security
>> considerations.
>> 
>> (4) Review the format of the media type registry. One
>> suggestion, which I think came from John Klensin, was that
>>         given media type names can be grandfathered, the name
>>         itself isn't a reliable indicator of the of the tree,
>>         so a column listing the tree the type is in would be
>>         helpful.

>...
> I am interested to hear your opinion, if you think creating
> such a wg would be a good idea and you'd participate in it, if
> you have proposals that would fit in such a wg, and especially
> if you'd be willing to actively help the wg creation (help out
> with chartering, chairing etc). On my side, and speaking only
> for myself, I have been warned of long running working groups,
> but I am not against it if there is enough interest and people
> are willing to put in the time and effort to make this work.

Francesca,

I don't know what Ned had in mind but, to me, the list above is
not open-ended and the sort of thing that would require a WG
with an open-ended charter and schedule.  Each of the issues Ned
raised is a (more or less) new strategic question [1] and they
are probably best thought of that way rather than as individual
open-ended tasks.

Taking the Haptics proposal as an example, Ned should check and
confirm this but my recollection from when what is now the media
type model was first designed was that we expected very few new
top-level types and wanted it to be hard, probably even at the
"only if there is no possible other choice" level.   Based on
reading the draft and the discussion during the DISPATCH
meeting, I suspect haptics might qualify.  But a WG discussion,
both of that proposal and about what light it sheds on the
situation and what we have learned in 30 years about what the
criteria for top-level types should be.   Can we design criteria
good enough that expert review is appropriate?  Should we
convene a WG for each proposed top-level type and, if so, where
will the energy come from?  Are there better models.  For
example for this particular proposal, if the real expertise and
interest is in an MPEG group [2], would it be sensible to define
criteria for top level types so that some sort of "specification
from recognized standards body" model would work, perhaps with
the IETF setting up an advisory team (the media-types mailing
list might or might not be appropriate).  I don't have answers,
but these are the types of questions a WG ought to be able to
address and answer within some plausible time.

Media type suffixes are another example.   What is needed is an
effort to think through the example proposals we have seen and
others people might come up with and either decide they are a
bad idea or establish evaluation criteria.  I hope we would not
need a WG for each possible suffix, but we almost certainly need
one to establish and reach consensus on some principles.

And so on for the rest of the list.  Won't be easy, but I don't
think it is open-ended.

best,
   john



[1] "More or less" because a few have been around, not dealt
with, for a while so the "new" part is deciding to deal with
them.

[2] I'm going to try to write a response to Ted's comments about
the need to do something soon, but will keep it separate from
this note.