[media-types] [MEDIAMAN] 117 minutes

Harald Alvestrand <harald@alvestrand.no> Fri, 04 August 2023 12:46 UTC

Return-Path: <harald@alvestrand.no>
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 43A53C151091 for <media-types@ietfa.amsl.com>; Fri, 4 Aug 2023 05:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.114
X-Spam-Level:
X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLmKLxNw-2dR for <media-types@ietfa.amsl.com>; Fri, 4 Aug 2023 05:46:01 -0700 (PDT)
Received: from smtp.alvestrand.no (unknown [IPv6:2a01:4f9:c010:a44b::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68F5C151081 for <media-types@ietf.org>; Fri, 4 Aug 2023 05:46:00 -0700 (PDT)
Received: from [192.168.3.110] (unknown [185.71.208.122]) by smtp.alvestrand.no (Postfix) with ESMTPSA id 5350D4F128 for <media-types@ietf.org>; Fri, 4 Aug 2023 14:45:57 +0200 (CEST)
Message-ID: <585fd40e-226c-7839-8cf8-7ce2c4d73dd5@alvestrand.no>
Date: Fri, 04 Aug 2023 14:45:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0
Content-Language: en-US
To: "media-types@ietf.org" <media-types@ietf.org>
From: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/vOURf2P-GrWyp1mMyeFi332mZxo>
Subject: [media-types] [MEDIAMAN] 117 minutes
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 04 Aug 2023 12:46:06 -0000

The current minutes in HedgeDoc are at 
https://notes.ietf.org/notes-ietf-117-mediaman

and reproduced below.

If this looks good to all, I'll upload them.

Harald

Mediaman IETF 117

draft-ietf-mediaman-toplevel - one review, ready
No objections, meeting attendees agree with the document moving forward.

draft-ietf-mediaman-haptics
Harald believes it is ready.
Alexey agrees. Suggests a minor update is required and will propose 
correction on mailing list.

draft-ietf-mediaman-suffixes
Manu: removed processing pipeline content from draft and produced new 
draft 05

Alexey: We should ask IANA to signal when a registration is being 
requested that uses the same base subtype as an existing type.

Specification required: yes.

Revision needed to the suffix registration process. Clarify if 
registration template is needed in an RFC when IETF is the change 
controller.

Guidance is needed for expert reviewers if they are required to make 
judgement calls on the overlap of semantics of media types with 
different suffixes.

draft-ietf-mediaman-standards-tree
Alexey: Concern about having expert reviewers verify adoption.

Consensus amongst participants to adopt.

6838bis or patch docs?
Harald: Allow toplevel to go forward and then roll into 6838bis

Harald: Finished docs can go to RFC, and inflight documents with 
consensus can become part of 6838bis.

Alexey: Update charter to ensure future ADs are aware of decisions made 
here.

Current wording suggests only the last +suffix describes the structure 
of the document.