Re: [Last-Call] Intdir last call review of draft-ietf-mediaman-toplevel-03
Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Mon, 04 March 2024 10:18 UTC
Return-Path: <antoine.fressancourt@huawei.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9FC14F6B3; Mon, 4 Mar 2024 02:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.407
X-Spam-Level:
X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 DpvFoR__IXkb; Mon, 4 Mar 2024 02:18:34 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC5CC14F602; Mon, 4 Mar 2024 02:18:33 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TpF012Khpz6JBFD; Mon, 4 Mar 2024 18:13:37 +0800 (CST)
Received: from lhrpeml100003.china.huawei.com (unknown [7.191.160.210]) by mail.maildlp.com (Postfix) with ESMTPS id BF9F51409F9; Mon, 4 Mar 2024 18:18:30 +0800 (CST)
Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by lhrpeml100003.china.huawei.com (7.191.160.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 4 Mar 2024 10:18:30 +0000
Received: from lhrpeml500003.china.huawei.com ([7.191.162.67]) by lhrpeml500003.china.huawei.com ([7.191.162.67]) with mapi id 15.01.2507.035; Mon, 4 Mar 2024 10:18:30 +0000
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Antoine Fressancourt <antoine@aft.network>, "int-dir@ietf.org" <int-dir@ietf.org>
CC: "draft-ietf-mediaman-toplevel.all@ietf.org" <draft-ietf-mediaman-toplevel.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "media-types@ietf.org" <media-types@ietf.org>
Thread-Topic: Intdir last call review of draft-ietf-mediaman-toplevel-03
Thread-Index: AQHabgX6HiIg29BC/EGISPG8ddn0erEnWzvQ
Date: Mon, 04 Mar 2024 10:18:30 +0000
Message-ID: <943e6dcefdce4402ae156f6ed4e0af67@huawei.com>
References: <169391582579.49616.10945134643187350045@ietfa.amsl.com> <c5d959c0-ae6f-45c7-835c-11acb9e6bd06@it.aoyama.ac.jp>
In-Reply-To: <c5d959c0-ae6f-45c7-835c-11acb9e6bd06@it.aoyama.ac.jp>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.215.65]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/y4dkQPJPSZkVdblmudz-X69Fq0g>
Subject: Re: [Last-Call] Intdir last call review of draft-ietf-mediaman-toplevel-03
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 10:18:35 -0000
Hello Martin, Thanks for your answer. Please see some more detailed comments about your answers (beginning with [AFT]), but, as with the original comments I made, they are absolutely not major or blocking in any way in my perspective. [...] > > I found the following minor issues, which I think SHOULD be clarified > before > publication: - Section 1.1 is not clear about what are the issues with > the media type registration process described in RFC 6838. An hint > about an explanation is only given at the end of section 3 when the > author gives some details about the history. I think the background > section should better highlight what are the main issues with RFC 6838 > before defining an updated registration procedure. Actually, I think this is addressed just before Section 1.1, where the documents says: >>>> RFC 6838 (Media Type Specifications and Registration Procedures), Section 4.2.7 only summarily gave criteria for defining additional top-level media types. This document provides more detailed criteria for defining additional top-level media types. >>>> [AFT] My intention here was to get an intuition whether the lack of clarity of the criteria given in RFC 6838 has been an issue for a registration. Besides, the draft's text does not include the specific reference to Section 4.2.7. I think it is a good idea to add it as you did in this answer. > - In section 2.1, the draft mentions that new top-level type MUST be > defined in a Standard Track RFC. This is a difference from section > 3.1 in RFC 6838, which mentions that a media type can be registered > with a Standards Track, a BCP, an Informational or an Experimental > track document as soon as there is an IETF consensus, and I think it > should be highlighted more clearly. BCP is still possible. Informational or Experimental don't need IETF consensus, and so they are not considered good enough for such a major thing as top-level types. There hasn't actually been any registration with the later two (not counting RFC 1437, which is an April Fool RFC), so I don't think there will be a big uproar like "I've always wanted to register this top-level type in an Informational RFC, and suddenly I can't.". [AFT] Agreed, my point was just to stress that the current draft clarifies this point compared to RFC 6838. > - This may be a layperson misunderstanding, but the draft does not > mention the concept of Registration trees introduced in section 3 of > RFC 6838, while I think some examples that justify the writing of the > current draft could have been addressed using a method described there. standards/vendor/personal tree are now described at the start of 1. Introduction. [AFT] Great, thanks. > For instance, in section 3 > of the draft, the example of the undocumented use of the 'font' top > level type could have been adressed by having the actors using this > type use 'vnd.font' or 'x.font' instead to prove the point that this > top tier media type is useful while 'font' was documented in a draft > following the Standards track. I wonder why the author does not > encourage the use of a transitory faceted media type to accompany the registration of a new top-tier media type. I don't think we want to tell people how to do things unofficially to then tell them how to do things officially. [AFT] I am not encouraging people to do things unofficially, but, in some cases, people may want to test whether there is traction for a given top level type by experimenting using it under an experimental or vendor-specific top level type that implementations are not forced to understand before standardizing. My point was to express this possibility, and I think giving an explicit playground for experimental types would help. > The following are minor issues (typos, misspelling, minor text improvements) > with the document: - In section 3, on page 7, 'recommended' should be used > rather than 'recommened' at the end of the penultimate paragraph of the section. Thanks, good catch, fixed. Many thanks again, Martin.
- [Last-Call] Intdir last call review of draft-ietf… Antoine Fressancourt via Datatracker
- Re: [Last-Call] Intdir last call review of draft-… Martin J. Dürst
- Re: [Last-Call] Intdir last call review of draft-… Antoine FRESSANCOURT
- Re: [Last-Call] Intdir last call review of draft-… Harald Alvestrand