[dispatch] Re: IETF WG state changed for draft-ietf-dispatch-mime-protobuf

John C Klensin <john-ietf@jck.com> Mon, 07 July 2025 22:51 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: dispatch@mail2.ietf.org
Delivered-To: dispatch@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id ABA1B40C291F for <dispatch@mail2.ietf.org>; Mon, 7 Jul 2025 15:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.232, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A6FjiqDgna4 for <dispatch@mail2.ietf.org>; Mon, 7 Jul 2025 15:51:11 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id 57C0B40C25AE for <dispatch@ietf.org>; Mon, 7 Jul 2025 15:50:38 -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 1uYufN-0002xI-Pv; Mon, 07 Jul 2025 18:50:29 -0400
Date: Mon, 07 Jul 2025 18:50:23 -0400
From: John C Klensin <john-ietf@jck.com>
To: Tim Bray <tbray@textuality.com>, Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <2FBD5774EDA06F83FE75AC02@PSB>
In-Reply-To: <CAHBU6ivs7ucNLqqe5dkNM2J5R11YAV20jYc45fFhFsv4rT6sLw@mail.gmail.com>
References: <175192121062.1954633.17042383977116310632@dt-datatracker- 6fcb845cd4-p6tkq> <F9C3585F-AF98-42E1-A7DA-24B9AC1DA0B1@bluepopcorn.net> <CAHBU6ivs7ucNLqqe5dkNM2J5R11YAV20jYc45fFhFsv4rT6sLw@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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
Message-ID-Hash: 2T7FEY7Y5FD37FTPTDQRJPJBAXPENQTM
X-Message-ID-Hash: 2T7FEY7Y5FD37FTPTDQRJPJBAXPENQTM
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dispatch.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dispatch@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dispatch] Re: IETF WG state changed for draft-ietf-dispatch-mime-protobuf
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/ECxthK8IHZj3nbP8yGIJ4iIkBr4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Owner: <mailto:dispatch-owner@ietf.org>
List-Post: <mailto:dispatch@ietf.org>
List-Subscribe: <mailto:dispatch-join@ietf.org>
List-Unsubscribe: <mailto:dispatch-leave@ietf.org>

Agree with Tim.

While I have still have some concerns about the content of
draft-bray-unichars and about whether PRECIS is sufficiently up to
date, I think the message from  those documents, the many discussions
surrounding them, and work in both Unicode Consortium and W3C is that
statements equivalent to "UTF-8 with no other restrictions" (aka
"just send UTF-8") are a mistake, one that is likely to cause
interoperability and other problems down the line.  

While I can imagine that there might be some cases that would be
reasonable exceptions (although it takes some effort), if the
specification is not to require (or at least strongly recommend) some
restrictions along the lines of the existing specs Tim mentions,
there should at least be a clear explanation in the document as to
why the "no restrictions" model is appropriate.


Finally and a bit off-topic with the content of the document, two
procedural issues:

(1) I can see nothing in the DISPATCH charter, much less its history,
that allows it to assign a document to itself for processing into an
RFC.  In this particular case, the Abstract says that the document
registers media types.   We already have a WG, mediaman, which can
consider new registration procedures and media types (although the
latter for specific cases would be marginal given its charter).
Processing registrations in this fashion by DISPATCH would, in any
event, be inconsistent with both RFC 6838 and the proposed
draft-ietf-mediaman-6838bis.  This objection should probably have
been raised in April on the grounds that Media Type registrations are
not "simple administrative documents" -- if they were, we would not
need RFC 6838, much less a WG chartered for the purpose of updating
it.  Even at this late date, I hope the DISPATCH Chairs will consider
that issue carefully rather than requiring an appeal.

(2) Someone should explain, to the DISPATCH WG and the datatracker,
the relationship between this document
(draft-ietf-dispatch-mime-protobuf) and the apparently (at least
substantially) identical draft-intarea-dispatch-mime-protobuf-00.
My guess is that draft-intarea-dispatch-mime-protobuf-00 replaced
draft-murray-dispatch-mime-protobuf and was, in turn, replaced by
this draft, but that is not what the datatracker pages say.

   john-the-grump


--On Monday, July 7, 2025 21:56 +0100 Tim Bray <tbray@textuality.com>
wrote:

> On Jul 7, 2025 at 2:50:19 PM, Jim Fenton <fenton@bluepopcorn.net>
> wrote:
> 
>> This starts a 2 week last working group last call for
>> draft-ietf-dispatch-mime-protobuf. Please review this short draft
>> and submit any comments to the mailing list.
>> 
> 
> In a previous iteration, I offered the following input about the
> draft but didn't hear back, so here goes again:
> 
> I note that the specification for Protobufs in
> https://protobuf.dev/programming-guides/proto3/ defines its string
> type as "A string must always contain UTF-8 encoded or 7-bit ASCII
> text, and cannot be longer than 2^32" and applies no restrictions
> to the contents of strings.  The IETF has both PRECIS and the
> recently-IESG-approved
> https://datatracker.ietf.org/doc/draft-bray-unichars/ both of which
> recommend restricting the set of Unicode characters allowed in
> protocols and data structures.  I think it would be useful if the
> media-type registration mentioned this work, perhaps in Security
> Considerations.
> 
> -T
> 
> 
>> -Jim
>> 
>> On 7 Jul 2025, at 13:46, IETF Secretariat wrote:
>> 
>> The IETF WG state of draft-ietf-dispatch-mime-protobuf has been
>> changed to
>> 
>> "In WG Last Call" from "WG Document" by Jim Fenton:
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-dispatch-mime-protobuf/
>> 
>> 
>> _______________________________________________
>> dispatch mailing list -- dispatch@ietf.org
>> To unsubscribe send an email to dispatch-leave@ietf.org
>>