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

John C Klensin <john-ietf@jck.com> Wed, 16 July 2025 18:02 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 D097D44E1C2B; Wed, 16 Jul 2025 11:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 0iIfpcnHYX31; Wed, 16 Jul 2025 11:02:12 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id 6524544E1C23; Wed, 16 Jul 2025 11:02:12 -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 1uc6SG-000Pk9-9R; Wed, 16 Jul 2025 14:02:08 -0400
Date: Wed, 16 Jul 2025 14:02:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: Rob Sloan <rmsj=40google.com@dmarc.ietf.org>, Tim Bray <tbray@textuality.com>
Message-ID: <6A677D8E48FCDFCE39C2E91B@PSB>
In-Reply-To: <CAM6SWqwCj6B=5jzqSiqpgrbM-7NnsaAGmUE4u0JmLw2WDpVHbQ@mail.gmail.com>
References: <F9C3585F-AF98-42E1-A7DA-24B9AC1DA0B1@bluepopcorn.net> <CAHBU6ivs7ucNLqqe5dkNM2J5R11YAV20jYc45fFhFsv4rT6sLw@mail.gmail.com> <2FBD5774EDA06F83FE75AC02@PSB> <CAL0qLwan85quE8nh9ZdG=e=RSZWe-vAeNFYJF-EcAdsE9G4ovw@mail.gmail.com> <CAM6SWqxiCG0dYuzt+5Vvck=4=sEuvXX5vKXjh78NX57tQKbAEw@mail.gmail.com> <CAHBU6it6dDhi4ZJqF3jFPpxQgwaPT6fAwJjpguh++Y1a55jpLQ@mail.gmail.com> <CAM6SWqxo1Tr-PjCCeRuJuDNkCN_7FTKb7zFz0Agmt0iaged8Pw@mail.gmail.com> <CAL0qLwZG4vZ25N=YRjbsMSxORQSpTKJ3SVrNnD_COCRZ77MYHQ@mail.gmail.com> <CAHBU6itPwgNPz_+nwFxvcT3XPjnxm=+xPTUn+vdkO5qh=kcsFQ@mail.gmail.com> <CAM6SWqwCj6B=5jzqSiqpgrbM-7NnsaAGmUE4u0JmLw2WDpVHbQ@mail.gmail.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
Message-ID-Hash: 5YZN3D5TIRPP56N3GQ7C4JCRZ5B4DESC
X-Message-ID-Hash: 5YZN3D5TIRPP56N3GQ7C4JCRZ5B4DESC
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/RAGqvTmH0hOrbJLZW74ERvD_BDw>
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>


--On Wednesday, July 16, 2025 10:29 -0400 Rob Sloan
<rmsj=40google.com@dmarc.ietf.org> wrote:

> I have applied these adjustments in this change
> <https://github.com/wkumari/draft-murray-dispatch-mime-protobuf/com
> mit/b0ea8374ea3e0a76f5105b95197cfce2e81bfef2>
> 
>> at least one of the two examples in that paragraph that mention
>> "UTF-8"
> is probably wrong
> 
> Sorry, which example are you referring to?
> 
> I have rewritten `UTF-8 encodings` as `Unicode text` as it sounds
> like that is one correction to make here

That should do most of it and sorry for not being more explicit.
There are actually two issues.

The first problem, which we seem to be encountering in several
contexts, is that UTF-8 is a specific encoding of Unicode.  While it
is generally the preferred one in data interchanged these days, it is
not the only one and it is therefore generally important to talk
about "Unicode text" or equivalent, as you have now done unless
whatever is being said is very specific to the UTF-8 encoding.

The distinction is extra-important in this case because Section 3 of
draft-ietf-dispatch-mime-protobuf-01 uses "encoding" to refer, not to
Unicode encodings like UTF-8 but the choice between "binary" and
"json". 

The second issue, independent of the above, is with Murray's note
from yesterday [1] which, in turn, refers to Rob's "alternate
proposal" [2].   The new text at 201-202 there includes:

	"Further, handling UTF-8 encodings generally can be quite
	complex with problems discussed, for example, in
	{{UniChars}};..."

The problem there is that draft-bray-unichars involves a relatively
non-complex mechanism and discussion.  If you want to address the
complexity issues, it would be good to reference something that
actually does discuss them in addition to draft-bray-unichars.  While
there are other places when that discussion occurs, the most obvious,
and probably appropriate, one in the IETF context is the PRECIS work
so what I suggested was referencing it as well.  Tim's July 7 note
[3] (and apparently an earlier one) says almost the same thing, i.e.,

	"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,..."

but could, I suppose, be considered ambiguous about to what "this
work" refers. Because the explanations in the PRECIS work and in
draft-bray-unichars are different (as described above), address
different levels of complexity, and are more or less complementary,
both should be referenced, not one or the other.

Does that clarify the concerns and proposed solutions?

    john



[1]
https://mailarchive.ietf.org/arch/msg/dispatch/xmDC0X1_mnBcYCc3Tk8iTcqkFhk
[2]
https://github.com/wkumari/draft-murray-dispatch-mime-protobuf/commit/c666f8e1c6810cbc54b0e93658e1ae6ec3dc5886
[3]
https://mailarchive.ietf.org/arch/msg/dispatch/ghl9YaYfK6wAik7-qQUy22sgbxc