[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 >>
- [dispatch] Re: IETF WG state changed for draft-ie… Jim Fenton
- [dispatch] Re: IETF WG state changed for draft-ie… John C Klensin
- [dispatch] Re: IETF WG state changed for draft-ie… Jim Fenton
- [dispatch] Re: IETF WG state changed for draft-ie… John C Klensin
- [dispatch] Re: IETF WG state changed for draft-ie… Rob Sayre
- [dispatch] Re: IETF WG state changed for draft-ie… Tim Bray
- [dispatch] Re: IETF WG state changed for draft-ie… Murray S. Kucherawy
- [dispatch] Re: IETF WG state changed for draft-ie… Rob Sloan
- [dispatch] Re: IETF WG state changed for draft-ie… Tim Bray
- [dispatch] Re: IETF WG state changed for draft-ie… Rob Sloan
- [dispatch] Re: IETF WG state changed for draft-ie… Murray S. Kucherawy
- [dispatch] Re: IETF WG state changed for draft-ie… Tim Bray
- [dispatch] Re: IETF WG state changed for draft-ie… Rob Sloan
- [dispatch] Re: IETF WG state changed for draft-ie… Tim Bray
- [dispatch] Re: IETF WG state changed for draft-ie… John C Klensin
- [dispatch] Re: IETF WG state changed for draft-ie… Rob Sloan
- [dispatch] Re: IETF WG state changed for draft-ie… Rob Sayre