From nobody Sat May 1 14:24:42 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02183A10E3 for ; Sat, 1 May 2021 14:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQZXlZ2mVcX0 for ; Sat, 1 May 2021 14:24:36 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49C23A10DB for ; Sat, 1 May 2021 14:24:35 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id z25-20020a9d65d90000b02902a560806ca7so1691018oth.11 for ; Sat, 01 May 2021 14:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/A8fC/y06IUQCpxXUtnwqNKNMEXAPLVQIgkwFkVzgKc=; b=11G7EeuMT2OVhfIffPfFwkJzJlhvMGddlmi9rM9TWu2Qn+YgfmJp/Se8B8lqGuRVcK 5tdrmKGsHUBfJIYzPQnbntfIdvbdSXDDyPHB0OoQpGgKLt2KcOmfOC9c7QxZhMT9PH8Y F6fqkrk5FL5/ipF9nM0HEUJM/D7kzn/9OPKJcBoAuyrzjdszVaMD5DlCX1QaCxx319dI rFUzwgCKENwNUGxtTVjCVGSDwFt7UWqXr8IkqCmZehME6ni2YtLQ/Or29IbcbSlGhepO pHPjRcX2BvHg2yDnrZhx8pmL7kXqkGPWoDrwV0JztgcXbu4U8+X8GmEU9K/uSe6y0HQV hWjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/A8fC/y06IUQCpxXUtnwqNKNMEXAPLVQIgkwFkVzgKc=; b=surogh4pw3k6GT4IsEKxeE6y5gaTJ8E2bTnfKNTEq/J3wcWkzGXTglbObb3uRAl2mo ThvwdghSiKw0d0gyN2AJAKbdCCyYl2bdiSeLfVhpMSsTw6UCVS3SoQY5VHTkddGrVpIH 8H+nY+du/3OOba8br/Hq0uli9N7bLe6FMvuzNCeIkSxr6kotkZZoGP9r8eDKNPNVKnkw pWlRNtn2jmm9GM1YecbKUeEsk4seiHyZkKIKWwvwCMl1LGnvvHhmimiH6Jse/+Ba2E2V aystJQC0R1cH0mX01Qacfmb3qyv7FpZPFVakAVuRkGCT+NiLSnFI4MQe6pAiBp/71ASM bliQ== X-Gm-Message-State: AOAM532kD+ImfkmFLjTG1ckw9b+uBETDKTClw/IwIrB/7huYKoPvJHGR nN2wQpDPodYr4U7d4nkHN6FJ2G9cb7s20UW3Q6N8RGfmqvHqcA== X-Google-Smtp-Source: ABdhPJw/XGFSI7GGw9rZNxUUOAdVfwa8GivwmhyCLXi8eL6riv//NGsByNKYt9FhJPHTLuajOltpyTYum73w1Z3OuOc= X-Received: by 2002:a05:6830:4ca:: with SMTP id s10mr9304681otd.79.1619904273973; Sat, 01 May 2021 14:24:33 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> From: Samuel Erdtman Date: Sat, 1 May 2021 23:24:23 +0200 Message-ID: To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="000000000000d212eb05c14b5aeb" Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 21:24:41 -0000 --000000000000d212eb05c14b5aeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Carsten, Your clarifications were great! See some comments inline. On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: > Hi Samuel, > > > 1. What do you mean with data at rest, data store in database or file? > > The point is that you are not signing the data being transferred, but a > local copy of some (e.g., freshly decoded) data (i.e., at the data model > level) which is then processed a little (potentially taking out all > signatures) and then is run through a rather complicated engine to produc= e > a signing input that is a deterministic function of the decoded and > processed data. > > There are easier ways to get a signing input from JSON-like data at rest. > For a (quite workable) strawman: How about doing a CBOR encoding using > deterministic encoding rules? > This is a good point. Still not convinced other solutions would be orders of magnitude better and the proposed one is easy to implement and easy to understand (maybe too easy since I had not thought about your alternative solution). > > > Or is it data that does not change? Sorry I do not get it. > > > > 2. What is weird with saying "Represented in JSON=E2=80=9D? > > Your scheme does NOT require (or benefit in any way from) representing th= e > data in JSON. > The data could be transferred in YAML (or CBOR for that matter): as long > as your local copy of the decoded data (after the little processing) stic= ks > inside the confines of the I-JSON data model, you can use your scheme for > signing. > But since JSON according to https://tools.ietf.org/html/rfc7159 is fairly flexible, would not fitting it into CBOR require similar limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON limitations= ) > > > is it that the RFC7493 I-JSON subset is not all that JSON could be? (to > me this is a reasonable limitation that I in practice never have had to g= o > outside) > > Well, that has been debated to death, and it is clear that nobody likes > I-JSON (*), but it is the de-facto boundary within which the actually mor= e > capable JSON format needs to be used these days. > (If you need more flexibility, you know where to find CBOR.) > So are you saying that CBOR would not impose the same limitations on the original JSON as RFC8785? > > > 3. So I totally get that one does not like XMLDigSig, in my opinion not > because of the signing procedures but because of the canonicalization > process. When I looked at it I gave up and created a hardcoded template. > The difference in canonicalization of JSON (RFC7493 I-JSON subset) > according to RFC8785 is like night and day compared to XML > canonicalization. In your comment it seems like you are of the opinion th= at > this effort will be as tricky as XMLDigSig. do you think so? > > Indeed, the RFC 8785 encoding is (ignoring potential problems on the > numeric side) simpler than canonicalized XML, even with its weird > regression to UTF16-land. > > Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicaliz= ation, > but in the confusion of how the data at rest was to be processed for > signing, e.g., what part of the data at rest was contributing to the > signing input and what the signature on that part then actually meant. J= WS > is probably flexible enough that a carefully constructed application can > get all this right, but we are talking about non-trivial specifications > needed beyond the boring part of generating the byte-string signing input= . > > > 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain= text" being bad > descriptions. Yes what is signed is the RFC8785 transformation of the inp= ut > data, but the signature are then put into your data keeping the data in i= ts > original =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain text" as opposed = to base64-url encoded. I > guess enveloped JWS is a more accurate name but =E2=80=9Cclear text=E2=80= =9D or =E2=80=9Cplain > text" is easy to understand. > > Well, I understand that the naming you chose is a good strategy for > selling the scheme. > It is, however, not describing what is actually going on, and I try to > minimize the use of misleading terminology. > Fair point > > Gr=C3=BC=C3=9Fe, Carsten > > (*) Over at the JSON mailing list, there has been some fresh discussion > just this week about how to get around some of the implementation > limitations, or JSON=E2=80=99s (deliberate!) lack of extensibility, or bo= th. > Archived-At: < > https://mailarchive.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> > and the thread behind that. > > --000000000000d212eb05c14b5aeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Carsten,

=
Your clarifications were great!

See some comm= ents inline.

On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <cabo@tzi.org> wrote:
Hi Samuel,

> 1. What do you mean with data at rest, data store in database or file?=

The point is that you are not signing the data being transferred, but a loc= al copy of some (e.g., freshly decoded) data (i.e., at the data model level= ) which is then processed a little (potentially taking out all signatures) = and then is run through a rather complicated engine to produce a signing in= put that is a deterministic function of the decoded and processed data.

There are easier ways to get a signing input from JSON-like data at rest. For a (quite workable) strawman: How about doing a CBOR encoding using dete= rministic encoding rules?

This is a goo= d point. Still not convinced other solutions would be orders of magnitude b= etter and the proposed one is easy to implement and easy to understand (may= be too easy since I had not thought about your alternative solution).
<= /div>
=C2=A0

> Or is it data that does not change? Sorry I do not get it.
>
> 2. What is weird with saying "Represented in JSON=E2=80=9D?

Your scheme does NOT require (or benefit in any way from) representing the = data in JSON.
The data could be transferred in YAML (or CBOR for that matter): as long as= your local copy of the decoded data (after the little processing) sticks i= nside the confines of the I-JSON data model, you can use your scheme for si= gning.

But since JSON according to https://tools.ietf.org/html/rfc= 7159 is fairly flexible, would not fitting it into CBOR require similar= limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-= JSON limitations)
=C2=A0

> is it that the RFC7493 I-JSON subset is not all that JSON could be? (t= o me this is a reasonable limitation that I in practice never have had to g= o outside)

Well, that has been debated to death, and it is clear that nobody likes I-J= SON (*), but it is the de-facto boundary within which the actually more cap= able JSON format needs to be used these days.
(If you need more flexibility, you know where to find CBOR.)

So are you saying that CBOR would not impose the same= limitations on the original JSON as RFC8785?
=C2=A0

> 3. So I totally get that one does not like XMLDigSig, in my opinion no= t because of the signing procedures but because of the canonicalization pro= cess. When I looked at it I gave up and created a hardcoded template. The d= ifference in canonicalization of JSON (RFC7493 I-JSON subset) according to = RFC8785 is like night and day compared to XML canonicalization. In your com= ment it seems like you are of the opinion that this effort will be as trick= y as XMLDigSig. do you think so?

Indeed, the RFC 8785 encoding is (ignoring potential problems on the numeri= c side) simpler than canonicalized XML, even with its weird regression to U= TF16-land.

Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicalizat= ion, but in the confusion of how the data at rest was to be processed for s= igning, e.g., what part of the data at rest was contributing to the signing= input and what the signature on that part then actually meant.=C2=A0 JWS i= s probably flexible enough that a carefully constructed application can get= all this right, but we are talking about non-trivial specifications needed= beyond the boring part of generating the byte-string signing input.

> 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplai= n text" being bad descriptions. Yes what is signed is the RFC8785 tran= sformation of the input data, but the signature are then put into your data= keeping the data in its original =E2=80=9Cclear text=E2=80=9D or =E2=80=9C= plain text" as opposed to base64-url encoded. I guess enveloped JWS is= a more accurate name but =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain te= xt" is easy to understand.

Well, I understand that the naming you chose is a good strategy for selling= the scheme.
It is, however, not describing what is actually going on, and I try to mini= mize the use of misleading terminology.

Fair point
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten

(*) Over at the JSON mailing list, there has been some fresh discussion jus= t this week about how to get around some of the implementation limitations,= or JSON=E2=80=99s (deliberate!) lack of extensibility, or both.=C2=A0 Arch= ived-At: <https://mailarchi= ve.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> and the threa= d behind that.

--000000000000d212eb05c14b5aeb-- From nobody Sat May 1 14:28:55 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1B33A1132 for ; Sat, 1 May 2021 14:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ5aQfbNJhBZ for ; Sat, 1 May 2021 14:28:44 -0700 (PDT) Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9883A1115 for ; Sat, 1 May 2021 14:28:44 -0700 (PDT) Received: by mail-oo1-xc2d.google.com with SMTP id u48-20020a4a97330000b02901fa060b8066so414687ooi.8 for ; Sat, 01 May 2021 14:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y4K4ms5W8oP/nQiUlcLgssDNUjb+LAcb6PIJKQKny+k=; b=Eb32Jz6yq6vjlMaTlINLMTCO6FugVBqu5wlm6mrd75++tPyl+vNaCtU+30QGBJPnYZ fauGDJfqRgM6VInysuRcHf/3NlvycRggApYeUf3bbdImKMsQ441k81UGpdAM+T8wvEz2 TFREOGi19qSDUR7FaWECTWA8ieZ111NBemIXMddAJkI80CKxHHZwasugIyKpwIik7k0M nFwrRr+pbzF4VR1fP1yWVBfrQ+idShzPB3ycbYGCnExx0e9iwD0TC+/RbpKxcguw8lfc ohUvfK589ZmZ4m10koO7tDveVGGkYa3IeQ0HVxZueFJX5gO9M4DjeQD7Y0SmtfygInnr d+9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y4K4ms5W8oP/nQiUlcLgssDNUjb+LAcb6PIJKQKny+k=; b=AgvwFiVjjADWMiTer1zvO1OHz/Pv+bSfPUVaqk2MZtCAu4ls+Q9sGh4rpP4CLsyesw /xWi317Map8v86Q/ksdRHgLANs4Q22zSGz0Yau8o85vnDhR5rkZ11uyTwqJ69EUOuYfQ khZiFIffqshmUhCij+SAn2SuvaxH5ogSvlA5SEElBUggnBdmr6rTYVaoQRWM/oa+Rl9e kDcuiU3MOeEjIYAQmt0uljlmPP97JhuVAmHPwfGK4zhNaR2wJf8yuzhPmTeIfzdEO3Ca 8tCaBBCoPypqNJf0cwMN1x8t3puWugLBW2HLDzqZvFLcDp7qcbNw+GRo9Y+uVZNzCxYo kTsA== X-Gm-Message-State: AOAM533xNpOWQWjK7fVgcc6p+ZTDzYYx6xPVvgKOe5/wIvgh5scrjbNv 8pDVf6e3UgUutR3b9mnqqsO75KhJl93E05Dtl5vVKg== X-Google-Smtp-Source: ABdhPJxmJocMe3Ac8LH7n3q9RzZpe1UNPN64HisJO5XfBtgT9anrX8GTpZ4ePTU8l7a4TFeqZ4aYxAeopZv4Q74MT08= X-Received: by 2002:a4a:b4cb:: with SMTP id g11mr9851682ooo.41.1619904518286; Sat, 01 May 2021 14:28:38 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: From: Samuel Erdtman Date: Sat, 1 May 2021 23:28:27 +0200 Message-ID: To: Carsten Bormann Cc: art@ietf.org, IETF SecDispatch , DISPATCH , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="00000000000062079105c14b6910" Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 21:28:53 -0000 --00000000000062079105c14b6910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, One more thing, you wrote "Signing data at rest certainly is a use case that is worth addressing.". With my new fond insights (thanks) does this mean that you are in favor of specifying how to do enveloped signatures for JSON (or at least not against it)? Cheers //Samuel On Sat, May 1, 2021 at 11:24 PM Samuel Erdtman wrote: > Thanks Carsten, > > Your clarifications were great! > > See some comments inline. > > On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: > >> Hi Samuel, >> >> > 1. What do you mean with data at rest, data store in database or file? >> >> The point is that you are not signing the data being transferred, but a >> local copy of some (e.g., freshly decoded) data (i.e., at the data model >> level) which is then processed a little (potentially taking out all >> signatures) and then is run through a rather complicated engine to produ= ce >> a signing input that is a deterministic function of the decoded and >> processed data. >> >> There are easier ways to get a signing input from JSON-like data at rest= . >> For a (quite workable) strawman: How about doing a CBOR encoding using >> deterministic encoding rules? >> > > This is a good point. Still not convinced other solutions would be orders > of magnitude better and the proposed one is easy to implement and easy to > understand (maybe too easy since I had not thought about your alternative > solution). > > >> >> > Or is it data that does not change? Sorry I do not get it. >> > >> > 2. What is weird with saying "Represented in JSON=E2=80=9D? >> >> Your scheme does NOT require (or benefit in any way from) representing >> the data in JSON. >> The data could be transferred in YAML (or CBOR for that matter): as long >> as your local copy of the decoded data (after the little processing) sti= cks >> inside the confines of the I-JSON data model, you can use your scheme fo= r >> signing. >> > > But since JSON according to https://tools.ietf.org/html/rfc7159 is fairly > flexible, would not fitting it into CBOR require similar limitations as > RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON limitatio= ns) > > >> >> > is it that the RFC7493 I-JSON subset is not all that JSON could be? (t= o >> me this is a reasonable limitation that I in practice never have had to = go >> outside) >> >> Well, that has been debated to death, and it is clear that nobody likes >> I-JSON (*), but it is the de-facto boundary within which the actually mo= re >> capable JSON format needs to be used these days. >> (If you need more flexibility, you know where to find CBOR.) >> > > So are you saying that CBOR would not impose the same limitations on the > original JSON as RFC8785? > > >> >> > 3. So I totally get that one does not like XMLDigSig, in my opinion no= t >> because of the signing procedures but because of the canonicalization >> process. When I looked at it I gave up and created a hardcoded template. >> The difference in canonicalization of JSON (RFC7493 I-JSON subset) >> according to RFC8785 is like night and day compared to XML >> canonicalization. In your comment it seems like you are of the opinion t= hat >> this effort will be as tricky as XMLDigSig. do you think so? >> >> Indeed, the RFC 8785 encoding is (ignoring potential problems on the >> numeric side) simpler than canonicalized XML, even with its weird >> regression to UTF16-land. >> >> Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicali= zation, >> but in the confusion of how the data at rest was to be processed for >> signing, e.g., what part of the data at rest was contributing to the >> signing input and what the signature on that part then actually meant. = JWS >> is probably flexible enough that a carefully constructed application can >> get all this right, but we are talking about non-trivial specifications >> needed beyond the boring part of generating the byte-string signing inpu= t. >> >> > 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplai= n text" being bad >> descriptions. Yes what is signed is the RFC8785 transformation of the in= put >> data, but the signature are then put into your data keeping the data in = its >> original =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain text" as opposed= to base64-url encoded. I >> guess enveloped JWS is a more accurate name but =E2=80=9Cclear text=E2= =80=9D or =E2=80=9Cplain >> text" is easy to understand. >> >> Well, I understand that the naming you chose is a good strategy for >> selling the scheme. >> It is, however, not describing what is actually going on, and I try to >> minimize the use of misleading terminology. >> > > Fair point > > >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> (*) Over at the JSON mailing list, there has been some fresh discussion >> just this week about how to get around some of the implementation >> limitations, or JSON=E2=80=99s (deliberate!) lack of extensibility, or b= oth. >> Archived-At: < >> https://mailarchive.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> >> and the thread behind that. >> >> --00000000000062079105c14b6910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten,

One more thing, = you wrote "Signing data at rest certainly is a use case that is worth = addressing.". With my new fond insights (thanks) does this mean that y= ou are in favor of specifying how to do enveloped signatures for JSON (or a= t least not against it)?

Cheers
//S= amuel


On Sat, May 1, 2021 at 11:24 PM Samuel Erdtman &l= t;samuel@erdtman.se> wrote:
=
Thanks Carsten,

Your clarifica= tions were great!

See some comments inline.

On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <cabo@tzi.org> wrote:
Hi Samuel,

> 1. What do you mean with data at rest, data store in database or file?=

The point is that you are not signing the data being transferred, but a loc= al copy of some (e.g., freshly decoded) data (i.e., at the data model level= ) which is then processed a little (potentially taking out all signatures) = and then is run through a rather complicated engine to produce a signing in= put that is a deterministic function of the decoded and processed data.

There are easier ways to get a signing input from JSON-like data at rest. For a (quite workable) strawman: How about doing a CBOR encoding using dete= rministic encoding rules?

This is a goo= d point. Still not convinced other solutions would be orders of magnitude b= etter and the proposed one is easy to implement and easy to understand (may= be too easy since I had not thought about your alternative solution).
<= /div>
=C2=A0

> Or is it data that does not change? Sorry I do not get it.
>
> 2. What is weird with saying "Represented in JSON=E2=80=9D?

Your scheme does NOT require (or benefit in any way from) representing the = data in JSON.
The data could be transferred in YAML (or CBOR for that matter): as long as= your local copy of the decoded data (after the little processing) sticks i= nside the confines of the I-JSON data model, you can use your scheme for si= gning.

But since JSON according to https://tools= .ietf.org/html/rfc7159 is fairly flexible, would not fitting it into CB= OR require similar limitations as RFC8785 puts on what you can do with the = JSON? (i.e. the I-JSON limitations)
=C2=A0

> is it that the RFC7493 I-JSON subset is not all that JSON could be? (t= o me this is a reasonable limitation that I in practice never have had to g= o outside)

Well, that has been debated to death, and it is clear that nobody likes I-J= SON (*), but it is the de-facto boundary within which the actually more cap= able JSON format needs to be used these days.
(If you need more flexibility, you know where to find CBOR.)

So are you saying that CBOR would not impose the same= limitations on the original JSON as RFC8785?
=C2=A0

> 3. So I totally get that one does not like XMLDigSig, in my opinion no= t because of the signing procedures but because of the canonicalization pro= cess. When I looked at it I gave up and created a hardcoded template. The d= ifference in canonicalization of JSON (RFC7493 I-JSON subset) according to = RFC8785 is like night and day compared to XML canonicalization. In your com= ment it seems like you are of the opinion that this effort will be as trick= y as XMLDigSig. do you think so?

Indeed, the RFC 8785 encoding is (ignoring potential problems on the numeri= c side) simpler than canonicalized XML, even with its weird regression to U= TF16-land.

Much of the actual problems of XMLDSig weren=E2=80=99t in the canonicalizat= ion, but in the confusion of how the data at rest was to be processed for s= igning, e.g., what part of the data at rest was contributing to the signing= input and what the signature on that part then actually meant.=C2=A0 JWS i= s probably flexible enough that a carefully constructed application can get= all this right, but we are talking about non-trivial specifications needed= beyond the boring part of generating the byte-string signing input.

> 4. Not sure I agree with =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplai= n text" being bad descriptions. Yes what is signed is the RFC8785 tran= sformation of the input data, but the signature are then put into your data= keeping the data in its original =E2=80=9Cclear text=E2=80=9D or =E2=80=9C= plain text" as opposed to base64-url encoded. I guess enveloped JWS is= a more accurate name but =E2=80=9Cclear text=E2=80=9D or =E2=80=9Cplain te= xt" is easy to understand.

Well, I understand that the naming you chose is a good strategy for selling= the scheme.
It is, however, not describing what is actually going on, and I try to mini= mize the use of misleading terminology.

Fair point
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten

(*) Over at the JSON mailing list, there has been some fresh discussion jus= t this week about how to get around some of the implementation limitations,= or JSON=E2=80=99s (deliberate!) lack of extensibility, or both.=C2=A0 Arch= ived-At: <https://mailarchi= ve.ietf.org/arch/msg/json/BWkSc8JYybzmgLT0Bsmfhiwf7cY> and the threa= d behind that.

--00000000000062079105c14b6910-- From nobody Mon May 3 03:39:48 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB6C3A189C; Mon, 3 May 2021 03:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqolJWRmI3Kw; Mon, 3 May 2021 03:39:37 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70042.outbound.protection.outlook.com [40.107.7.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62533A189A; Mon, 3 May 2021 03:39:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J2SHYGlE+zmYbcQp+iERFZyFabMJFVKeX3wTPJrEphHky9N4mAhGRZ06GZVDg1ZfdxjyXUH8hjyafYXW7+HGwLFtzFk0/XYwn3omMBnVcaMm06L2Wj933HCtLfDKbMuCzj2/f/rabgJEzuaTqfpuylTuJFVrsjzsrEXSfcJViwQOK3d6+ELYd5CPMgfWgaW1TOOvT4ZW12xbiI4dG22FB8t83CgyfsPvXUB9853rycV764XBq3EZg+XRb5ZUKW0gx8n7K2HEow+ywWi49ITIxi4Iq/50ZsjmUJdLN6O+G10x2QUZngw7HrTbvHohnWPwwDQIf65xzkVhpLbE03nu+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4qFCAJivtl2+j1g5T1HJoxbnDy9iBgJHVQPADq9oBbY=; b=gXf+Hq3rA0EmHcqrPedDlrNbLzVAhoCJumoClo/jJlq0Ukf4iNT2XZymlsHZur0dc4isUP/lSXqku1KpglwbiBMkDsM7Ggf9g79o4LAb7eLY0f9NovJhj8EGS12ZQRWu1GGA+e/jsOHheaI8aWeR7Gy+Sls/qRGzbcQz52d+lFEp5HZaMQn8folr5UV9dCQnsvl38/w4QAMGuY5/6IRSJBgESeCcx0mcY3KWAOxxYzoAIugcRARHlyi7ypY+IZUMsFKzqm55rbn8FUzSuFuC1zJsIR8dRZQQ2sNsM8pYWqGfpf4h9Qew4MDzfl7NwTBNl4wZxP5nJXrC0st45PE4zw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4qFCAJivtl2+j1g5T1HJoxbnDy9iBgJHVQPADq9oBbY=; b=BkoJvpFFzont/hjdcHKHUnEt04fkQWmTd8swN5AbHtyH3iTb83eVXMutVIgx4l10T5LU/STAC8+5OtDYYBRsxqMnsw6Q+nNeg/YTROGG+v3am69Y8DxZe/VdIwO1mj5bdpM1xybbHXW8husfFj5VX+fMcvaUIkM1ui2rV7LJxc0= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR07MB4220.eurprd07.prod.outlook.com (2603:10a6:7:a2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.17; Mon, 3 May 2021 10:39:28 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b%5]) with mapi id 15.20.4108.023; Mon, 3 May 2021 10:39:28 +0000 From: Francesca Palombini To: "dispatch@ietf.org" , "art@ietf.org" CC: ART ADs , "draft-muthusamy-dispatch-haptics@ietf.org" , "dispatch-chairs@ietf.org" Thread-Topic: Status of Haptics I-D in DISPATCH? Thread-Index: AQHXQAiXhkWIzY99rEKfQgzWZ5WHhA== Date: Mon, 3 May 2021 10:39:28 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:d19f:93a7:d3b5:5464] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d203eb0d-1112-46c4-d6af-08d90e1fba90 x-ms-traffictypediagnostic: HE1PR07MB4220: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wRobrti7ibTXfreWQe2KJtZDAht8wgdTZbiMfmr01lKiyuAQaCqA9sg5urZTslCEn3kfd6Bl4ylf0vVeIc/fPiKerRIUEnz2WYHjAQfk+q/YqDKiRd3AhrT4PLiMvly9RrjP5AoiDATq/llWTL8+pb/NrIvjokqdisbTf704iXFpGCrdUqicbuX66GDS2kI2Cr1Hy1EFFcXu6s31VmSUAq4z537YiD2cNsP7q8OFKDaZw1AE05ipT4v4Z/mL1RDiLWKtDTbH0KilpB8IGioVlpkfp1k00QbQBpxzly/tO3/cbLh61XBtrrjmkhSQr7tpFsbHnFrPBEhg0QfXXgw+TdJ5EZkdmjdXvtyShgBMhO45jPrq0+OaE6grku+rtK6LF78c0JW6ASsWIBBZ/Gnp4JMI8s5yRSqiayr4OjJEAp9mg5qEvS/7o2sUhZ4CVBU/6SOKKr3LogeG1K21STodjP81mdAIiTailNQjP0bfmlxIz5K2J1NM2dNchu7/0D1XXD66VMFXtVKFVNjOqHmTVbn5CkFY1TFh7UIGd3XbIXa252gbFxkMwI6cYMi6q4y/bsE3HdhMWHX61r5ZZ2W7QQnAvDiEfKu5qBsv4dIvlUnLbDRbUT87CKXpaLztVDrrDrBTsyfaDz5fTUTbwYwb44KzGR8jaeOJFP5tMS5l+LxdmWHNgZ5udrgbf1y+G0XJ4ekD2K4phf+3WrkJjb0fqdOcT/faQXEFqvpxWL1kLxo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(376002)(366004)(346002)(6512007)(66556008)(64756008)(66446008)(66476007)(6486002)(6506007)(66946007)(76116006)(8936002)(966005)(86362001)(33656002)(122000001)(478600001)(38100700002)(8676002)(71200400001)(316002)(36756003)(54906003)(110136005)(2616005)(44832011)(186003)(4326008)(450100002)(2906002)(5660300002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VTVhb0ZhWUVhNUx0YW9lUFYvL290UU5nOCs0dC9OMVh0eWUwM1hGcThPNVBh?= =?utf-8?B?VmNiakM4UHptUVFHMktlUEk0aE15TDNtTlVDQk1aVVEzM3pNYTdOaW5JSWNW?= =?utf-8?B?c0Z6aEFoQWlQRlhMa2dFcEpsYjhtbGhVTUducENXaWEyRUlrQ0xvbVVNVG5k?= =?utf-8?B?aFFDeC9CUXFNeE5mK0R3ajk4emY4ZG1hNkFrZk1ZZnlBS3pZYVZoRnNUME1Y?= =?utf-8?B?S0hieS80aWhBY2VOVGhDMFRXVGo4WUhGQ0NuUW1taUJlV2ZsdkgrWXZHb3h4?= =?utf-8?B?Vi8xNzJUSWVhcW1kYVZPSkR5NFVrVi9ySHBnTUc4L2JkN2l6dnZ2MlRoeGhY?= =?utf-8?B?V1I5OGJ2TzBid1liMFEyYjJzbU5XTUtoUUZyTUlwczk5N0dQZ0Y5UGdlYStC?= =?utf-8?B?bURmd1l3SFp1KzdFZUZtMVkzTGI4WGVtaVVsWlFSTVdzZWJEQzYxa293bzlt?= =?utf-8?B?bUZPdTZBNDd1aXk5QklzcTZrR0pxdlJhSVdoU1NvRmdMT0F1SjFtTWhwbENx?= =?utf-8?B?NFVETUlwUFJkK3hlZktqM0VVQVBZYjVIN2wwQkVFb0g0b2dBZ1pESjl5Uzcw?= =?utf-8?B?TUNHMkVWRUhiTVJ2OWRRZVNFVWZwaXRXVjB4UE9HVjhxRnJZb1ZJYTh5WjRC?= =?utf-8?B?L0ZTZVRjcW5mZXhJdDh5bmZPQ1N3clRSMVkwcnl3ZzlqOFkxNWtxVkNIZzU1?= =?utf-8?B?UFJoSkJBSDlHZDhKbUhhWjVSMU1uOWhXSmRkcnMvc1FTRDhmZ08xMkRVdllY?= =?utf-8?B?cFptNk1TOGt1eVV3OGhHaFZ3Q1Z3SXRldzZBaDZqaS9Td1o2VkZ0MS9mNkU4?= =?utf-8?B?dEpsdHJGdnJCZzZDOTMya2htaFk3dnZqZXRMU0dTbzhrZTVMY1V4TnAyaURv?= =?utf-8?B?TkppVW4zcnVabzJoQ09HZkI0NmRkanRpanZ0SkNIbUltdmsrV2JBMlQ1VEhi?= =?utf-8?B?b3VXdndkQTRLR2tueWUrcnZaaG9ZdllaVXVub3FGZGEzYnFwa1V1YjBWY0Iz?= =?utf-8?B?MlprSktsTlIxV2J4d0pUUkNtM3hTVWc1VFJ1OHg0d3hodkhKNmdYcWFscnlR?= =?utf-8?B?ZUJ5UTFaZzNqbzJyZmR0a0w1WUl1ZWt5aUpkcVBNQTlXbjI2cWdnTmQ5SW5Y?= =?utf-8?B?b0FVdTZlQlMwcmwzYk9pRERYTHFmT2FTMy9IWU9CdDlZd2krcGVZdGFrdzFU?= =?utf-8?B?RloyWmJZUmJFVkVQanZkS3ZnNW1zY05aOEUwbERuTTByWDFnTFgrc0VZK1k4?= =?utf-8?B?VTArWThNQVZtWWRieks4UGh0V0xhS0R3VGZOOGtxb3NScitKTVRaczNsT0NL?= =?utf-8?B?TmdlMkJpZURMbjl4dUdSSWNmYmRQcTFDLzBwZHRKV0szd1JiQVZsc0VBR1Vr?= =?utf-8?B?U0huejIxT0ZSQkZXY3ZaV2hNUUdDaHdNaURpcjdHTVB5TTNYZmN6SjR6d0tQ?= =?utf-8?B?NFpmZHVHV1ZjNVdMR1hBZDRURzFvMXhJNFp4TE5PaUFSc09PRkhKbWw1TFlN?= =?utf-8?B?bWFqeFNHQWdDTUs0TFRsSXF1R1BGL1F5M1hkeGFhaStSTnRUeVFzMjkra1l4?= =?utf-8?B?NHZlT0dOU0svckIyWEpkMUc3ZkZpMU9ZMWVaWjVkQmY0QVRzSm9yWUJ1Y1BE?= =?utf-8?B?cUNxbXJ2UHVYak1UZmVqQ1JSaGFyMDJxcHJXQ1VhVUc2MTFlTTBwZlhZbXgz?= =?utf-8?B?MWtMT2p4YUo2Wi9IRUhWcWRuenpqbWdnZXNnVDEvQmtPN0hNWmVlbThkWU43?= =?utf-8?B?KzQrTTZQQ2RuREIxZmlrZ1Q2RThPNUVwVGVLMHFleCtiSE1nUUNLeTAvK0lY?= =?utf-8?B?VDFLV2VuWEFIWHF6TXJnRDB6SWc1aDNnU3NGOVNNc1F3TXVUTHZJM1BQQU5I?= =?utf-8?B?T0ZzVEJLVk13S3JETVBXd1VBdUlIaXVNbU5YWTY1REE1UUE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d203eb0d-1112-46c4-d6af-08d90e1fba90 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 10:39:28.4726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: t6ltH83p7uTODpgyd8irxm5BuRNFNcQWY24chZ2FKHD628wXy+ht3iwAlTCW+JgCJqrjUSwrWZR2WVZnEJs8LkxbwMN4/xRz8E08pyCymHkE4vTrKwgPcDpe8oDkkGs/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4220 Archived-At: Subject: Re: [dispatch] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 10:39:42 -0000 SGkgYWxsLA0KDQpNdXJyYXkgYW5kIEkgYXJlIHN0aWxsIGxvb2tpbmcgZm9yIGd1aWRhbmNlIGZy b20gdGhlIGNvbW11bml0eSBvbiBob3cgdG8gcHJvY2VzcyB0aGUgSGFwdGljcyBwcm9wb3NhbCBk aXNjdXNzZWQgaW4gRGlzcGF0Y2ggYXQgSUVURjEwOToNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tdXRodXNhbXktZGlzcGF0Y2gtaGFwdGljcy0wMSANCg0K RHVyaW5nIHRoZSBJRVRGMTA5IG1lZXRpbmcgKG1pbnV0ZXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTA5LWRpc3BhdGNoLyApIGFuZCBwcmV2aW91cyBtYWlsaW5n IGxpc3QgZGlzY3Vzc2lvbiBbMV0sIHRoZXJlIHdhcyBnZW5lcmFsIHN1cHBvcnQgb24gcHJvZ3Jl c3NpbmcgdGhpcyB3b3JrLiBNdXJyYXkgaGFzIHByZXZpb3VzbHkgYXNrZWQgdGhlIG1haWxpbmcg bGlzdCBpZiB0aGUgY29tbXVuaXR5IHRoaW5rcyB0aGlzIGlzIGJldHRlciBkb25lIGFzIGVpdGhl ciBhIHNob3J0LWxpdmVkIHdvcmtpbmcgZ3JvdXAgb3IgYXMgQUQgc3BvbnNvcmVkIFsyXSwgYnV0 IGdvdCBubyBhbnN3ZXIuIFRoaXMgaXMgY29uY2VybmluZyBmb3IgdXMsIGFzIGlmIHRoZXJlIGlz IG5vIGVuZXJneSB0byB3b3JrIG9uIHRoaXMgcHJvcG9zYWwsIHNwaW5uaW5nIGEgd2cgb3V0IG9m IGl0IHdpdGggZW5vdWdoIGFjdGl2ZSBwYXJ0aWNpcGFudHMgb3IgZXZlbiBnZXR0aW5nIGVub3Vn aCByZXZpZXdzIHRvIGVuc3VyZSBJRVRGIGNvbnNlbnN1cyBtaWdodCBub3QgYmUgZG9hYmxlLiBT byB0aGlzIGlzIHVzIHJlYWNoaW5nIG91dCBvbmUgbW9yZSB0aW1lIHRvIGhlYXIgaWYgdGhlcmUg aXMgaW50ZXJlc3RlZCBwZW9wbGUgd2hvIHdvdWxkIGJlIHdpbGxpbmcgdG8gZ2V0IGludm9sdmVk LCBhbmQgaWYgc28gaGVhcmluZyB5b3VyIG9waW5pb24gaWYgeW91IHRoaW5rIHRoaXMgc2hvdWxk IGdvIHRocm91Z2ggYXMgQUQgc3BvbnNvcmVkIG9yIHdpbGwgbmVlZCBpdHMgb3duIHdnIChteSBw cmVmZXJlbmNlKS4NCg0KRnJhbmNlc2NhDQoNCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvZGlzcGF0Y2gvVHYtNF9aVXdBU0Jqcy1EcmdPUjVJMG9TRGNRLyANClsy XSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Rpc3BhdGNoL0dJWUUydjhV a3hrQlZIbEYzRkhqVDhUbWkzay8gDQoNCg== From nobody Mon May 3 04:18:28 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE983A07B3; Mon, 3 May 2021 04:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6y_ch6pBIaw; Mon, 3 May 2021 04:18:23 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C893A07B2; Mon, 3 May 2021 04:18:22 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id v24so5048757oiv.9; Mon, 03 May 2021 04:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+RyqjGy9BsHn9uC9MlqlYhD9ko9lA92Q7Jpqbeucxdw=; b=lvkbr0avff1uzetcmojGWVj2JHxLUcK9zNgt5iVTdptXYKqiiWeufjoDmWNvlfI/fN IuH4glE/2u8dAAcDN7MWtlPCIgrKdHMltoV5rjVtItb2H1iumjWOMYotDxQwDSOLPhtO aLRFvyGrYauGaQU2pQaxJSKL6I/6adv7rCYqi4mrUOkDuOOSoDnC37NlrmeoTkrk2bvq TGESakoQdy7Y3Hdb+sHTmzlKUwUOSCDa7OfwUF+eXugjpcgTJk0FhxUsyX5ncJ5jt3ls gGgQIwNcK2PNhbkrNZ4BQ3UJThXi7u3Xj1JMa8KFnJ5je4+xZuWt8uK6iNtT2dORVDud hAZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+RyqjGy9BsHn9uC9MlqlYhD9ko9lA92Q7Jpqbeucxdw=; b=lSqdox059VECTzcJ6JXhe7WSDKzIMs+QkSFFhiKftygpBTN/iBMh+jbzSx39hK1nL5 s3zM90+xGqlHU3UHcgUVYC9oyoNWWbVYLe0vB4KlBdut9xiCulob5Nynss0b0lQjI4zg zRUZZ6XbDRJ55aCtQLHTM1y35apLSXA3FjcM3XjdL5ykPrOgzjNMaPr9hgC8Udwdbz/F lmmg9j8ksOct7xFr77pQF0YBaQy4ayFkxwB21zNSDoSThHWb+n1CfDIwIYxfRMUiHRmF HSy1FFIP2EX5+X2+mSOJ9n5GVUaSoNPIRdp9rZEc0XBuGItYrP7YP00LkzxRoHeQSJ2b ZGDQ== X-Gm-Message-State: AOAM531c6A9XCHZ40kKCcEyTcEt8bJtAda1ASTyOON52aVx8RXUGiX+V 9aDk7lm3DeU0R76g+u4jy3ch0axJnK31EoiKZQi7jupd42A= X-Google-Smtp-Source: ABdhPJxz2+nDxysFyWuwknOFj5NN7ujavnmafJABS8X9f3H0M9pbGhvS2ye18Qr2x4uwynh05DSwXxIHgzHws4qOAzY= X-Received: by 2002:aca:ad87:: with SMTP id w129mr13259680oie.35.1620040701638; Mon, 03 May 2021 04:18:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Mon, 3 May 2021 12:17:55 +0100 Message-ID: To: Francesca Palombini Cc: "dispatch@ietf.org" , "art@ietf.org" , ART ADs , "draft-muthusamy-dispatch-haptics@ietf.org" , "dispatch-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008afbcc05c16b1eb2" Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 11:18:27 -0000 --0000000000008afbcc05c16b1eb2 Content-Type: text/plain; charset="UTF-8" Hi Francesca, I think this would be fine as AD-sponsored with discussion on the art@ietf.org list. I am willing to review the document when last-called. regards, Ted Hardie On Mon, May 3, 2021 at 11:40 AM Francesca Palombini wrote: > Hi all, > > Murray and I are still looking for guidance from the community on how to > process the Haptics proposal discussed in Dispatch at IETF109: > > https://datatracker.ietf.org/doc/html/draft-muthusamy-dispatch-haptics-01 > > During the IETF109 meeting (minutes: > https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and previous > mailing list discussion [1], there was general support on progressing this > work. Murray has previously asked the mailing list if the community thinks > this is better done as either a short-lived working group or as AD > sponsored [2], but got no answer. This is concerning for us, as if there is > no energy to work on this proposal, spinning a wg out of it with enough > active participants or even getting enough reviews to ensure IETF consensus > might not be doable. So this is us reaching out one more time to hear if > there is interested people who would be willing to get involved, and if so > hearing your opinion if you think this should go through as AD sponsored or > will need its own wg (my preference). > > Francesca > > > [1] > https://mailarchive.ietf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-DrgOR5I0oSDcQ/ > [2] > https://mailarchive.ietf.org/arch/msg/dispatch/GIYE2v8UkxkBVHlF3FHjT8Tmi3k/ > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --0000000000008afbcc05c16b1eb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francesca,

I think this w= ould be fine as AD-sponsored with discussion on the art@ietf.org list.=C2=A0 I am willing to review the document w= hen last-called.

regards,

Ted Hardie

On Mon, May 3, 2021 at 11:40 AM Francesca Palombini &l= t;francesca.palombini=3D40= ericsson.com@dmarc.ietf.org> wrote:
Hi all,

Murray and I are still looking for guidance from the community on how to pr= ocess the Haptics proposal discussed in Dispatch at IETF109:

https://datatracker.ietf.or= g/doc/html/draft-muthusamy-dispatch-haptics-01

During the IETF109 meeting (minutes: https://d= atatracker.ietf.org/doc/minutes-109-dispatch/ ) and previous mailing li= st discussion [1], there was general support on progressing this work. Murr= ay has previously asked the mailing list if the community thinks this is be= tter done as either a short-lived working group or as AD sponsored [2], but= got no answer. This is concerning for us, as if there is no energy to work= on this proposal, spinning a wg out of it with enough active participants = or even getting enough reviews to ensure IETF consensus might not be doable= . So this is us reaching out one more time to hear if there is interested p= eople who would be willing to get involved, and if so hearing your opinion = if you think this should go through as AD sponsored or will need its own wg= (my preference).

Francesca


[1] https://mailarchive.i= etf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-DrgOR5I0oSDcQ/
[2] https://mailarchive.i= etf.org/arch/msg/dispatch/GIYE2v8UkxkBVHlF3FHjT8Tmi3k/

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--0000000000008afbcc05c16b1eb2-- From nobody Mon May 3 06:33:44 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E263A11C1; Mon, 3 May 2021 06:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YelDsnLG-EM8; Mon, 3 May 2021 06:33:38 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8033A11BA; Mon, 3 May 2021 06:33:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYL7H9T7TS00HBBD@mauve.mrochek.com>; Mon, 3 May 2021 06:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620048512; bh=OdLlkSZKS81a6Nr0l/j3UZMeW1lalCsfcfsXmA5j/r4=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=mek2Ne7QmayhBqb8tF7Dr72f/pkpH9sn/HHO7914Ep4nNPLW+z2/MRs3704NZV7EZ pN4O0a8jKd44PlPJPN/5fbQDe1qT9gMGkt1nZ1BGidU1uW2ij5cjcozZJAgO3TvQPN HxHAzu1goIKDFSUPFDFM5yXIANeUibfBDcARp9qk= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Mon, 3 May 2021 06:28:27 -0700 (PDT) Cc: "dispatch@ietf.org" , "art@ietf.org" , ART ADs , "draft-muthusamy-dispatch-haptics@ietf.org" , "dispatch-chairs@ietf.org" Message-id: <01RYL7H6I3N20085YQ@mauve.mrochek.com> Date: Mon, 03 May 2021 06:09:59 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 03 May 2021 10:39:28 +0000" References: To: Francesca Palombini Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 13:33:43 -0000 > Murray and I are still looking for guidance from the community on how to > process the Haptics proposal discussed in Dispatch at IETF109: > https://datatracker.ietf.org/doc/html/draft-muthusamy-dispatch-haptics-01 > During the IETF109 meeting (minutes: > https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and previous mailing > list discussion [1], there was general support on progressing this work. Murray > has previously asked the mailing list if the community thinks this is better > done as either a short-lived working group or as AD sponsored [2], but got no > answer. We need a media types working group, because there are several media type related matters that warrant attention. The ones I know about are: (0) This haptics top-level type. (1) The proposal to allow multiple media type suffixes. (2) Media types for programming languages (3) Improved guidelines for constructing media type security considerations. This is not intended to be a comprehensive list: There may be other things that I have forgotten or don't know about. Also note that my listing these things does not mean I think the work is a great idea - I'm fairly skeptical of the multiple suffix idea. The only one where I have real skin in the game is (3), and I'm working on an I-D for it. I'm also willing to act as an editor for the programming language document, and review the other work. > This is concerning for us, as if there is no energy to work on this > proposal, spinning a wg out of it with enough active participants or even > getting enough reviews to ensure IETF consensus might not be doable. So this is > us reaching out one more time to hear if there is interested people who would be > willing to get involved, and if so hearing your opinion if you think this should > go through as AD sponsored or will need its own wg (my preference). I can't speak to the energy level of others, but I would suggest asking about it on the media types list. My guess is a significant number of people involved in media types don't subscribe to this list. Ned From nobody Mon May 3 07:01:54 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39023A1313; Mon, 3 May 2021 07:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1_4CyWLhX6u; Mon, 3 May 2021 07:01:46 -0700 (PDT) Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B900D3A130F; Mon, 3 May 2021 07:01:45 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ldZ7N-000FMv-TB; Mon, 03 May 2021 10:00:13 -0400 Date: Mon, 03 May 2021 09:59:53 -0400 From: John C Klensin To: Francesca Palombini , dispatch@ietf.org, art@ietf.org cc: ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, dispatch-chairs@ietf.org Message-ID: In-Reply-To: References: 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 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:01:51 -0000 Francesca, Like others, I think this work is worth progressing. However, precisely because of that, and because new top-level media types are a big deal with a potential interoperability mess if we get them wrong, I'm a little nervous about pushing a specification written by two people from the same company through on AD sponsorship. I think what we know from patterns of Last Calls in the last few years is that, for a topic on which most IETF participants have little in-depth knowledge and/or interest, the Last Call will either produce silence or comments similar to those during the DISPATCH meeting: "seems like a good idea but I can't evaluate the technical details. So I'd like to see a WG. And, if the WG cannot get interest and energy from a significant number of people from multiple organizations, then there is an issue we should not overlook or accidentally suppress: silence,whether on a Last Call or otherwise, from everyone but a document's authors/proponents does not IETF consensus make. I just noticed Ned's note and agree with everything he says. The comments above get to the same conclusion he reaches although from a different direction. And I favor a media types WG over one specifically for the Haptics proposal alone for the reasons he gives and one he implies: it would be significantly more likely to draw significant participation. best, john --On Monday, 03 May, 2021 10:39 +0000 Francesca Palombini wrote: > Hi all, > > Murray and I are still looking for guidance from the community > on how to process the Haptics proposal discussed in Dispatch > at IETF109: > > https://datatracker.ietf.org/doc/html/draft-muthusamy-dispatch > -haptics-01 > > During the IETF109 meeting (minutes: > https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and > previous mailing list discussion [1], there was general > support on progressing this work. Murray has previously asked > the mailing list if the community thinks this is better done > as either a short-lived working group or as AD sponsored [2], > but got no answer. This is concerning for us, as if there is > no energy to work on this proposal, spinning a wg out of it > with enough active participants or even getting enough reviews > to ensure IETF consensus might not be doable. So this is us > reaching out one more time to hear if there is interested > people who would be willing to get involved, and if so hearing > your opinion if you think this should go through as AD > sponsored or will need its own wg (my preference). > > Francesca > > > [1] > https://mailarchive.ietf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-D > rgOR5I0oSDcQ/ [2] > https://mailarchive.ietf.org/arch/msg/dispatch/GIYE2v8UkxkBVHl > F3FHjT8Tmi3k/ > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Mon May 3 07:34:47 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4603D3A1655; Mon, 3 May 2021 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOVuzgvTyWrx; Mon, 3 May 2021 07:34:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA3C3A1650; Mon, 3 May 2021 07:34:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYL9LXLR7K00GQTV@mauve.mrochek.com>; Mon, 3 May 2021 07:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620052174; bh=9SKHpw2M5QZ1ccZ9oxlD3NCDXga4GCo0jkUFBvI9Gn8=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=AQdx93HYxF/3rqz5iDDhmZSxbV0Ofkjd0Q6ZINJvfxdoJcdFDvxj0sX+syt+wdUIS QMACZyqQaD2CPqprOidxpU3x3i1rv2LNTjsBmCMvNieIVs/pjxKSt7Qgwea4CsV5Kv foxlBK5DanCqFD4TU9liX5PATDANKYYjfkEWhdHQ= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Mon, 3 May 2021 07:29:30 -0700 (PDT) Cc: Francesca Palombini , dispatch@ietf.org, art@ietf.org, ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, dispatch-chairs@ietf.org Message-id: <01RYL9LVJOVA0085YQ@mauve.mrochek.com> Date: Mon, 03 May 2021 07:27:52 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 03 May 2021 09:59:53 -0400" References: To: John C Klensin Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:34:46 -0000 +1 to everything John said here. There are a number of restrictions on different top-level types in some protocols, and we need unusually broad participation to get at all of them. Ned > Francesca, > Like others, I think this work is worth progressing. However, > precisely because of that, and because new top-level media types > are a big deal with a potential interoperability mess if we get > them wrong, I'm a little nervous about pushing a specification > written by two people from the same company through on AD > sponsorship. I think what we know from patterns of Last Calls > in the last few years is that, for a topic on which most IETF > participants have little in-depth knowledge and/or interest, the > Last Call will either produce silence or comments similar to > those during the DISPATCH meeting: "seems like a good idea but I > can't evaluate the technical details. > So I'd like to see a WG. And, if the WG cannot get interest and > energy from a significant number of people from multiple > organizations, then there is an issue we should not overlook or > accidentally suppress: silence,whether on a Last Call or > otherwise, from everyone but a document's authors/proponents > does not IETF consensus make. > I just noticed Ned's note and agree with everything he says. > The comments above get to the same conclusion he reaches > although from a different direction. And I favor a media types > WG over one specifically for the Haptics proposal alone for the > reasons he gives and one he implies: it would be significantly > more likely to draw significant participation. > best, > john > --On Monday, 03 May, 2021 10:39 +0000 Francesca Palombini > wrote: > > Hi all, > > > > Murray and I are still looking for guidance from the community > > on how to process the Haptics proposal discussed in Dispatch > > at IETF109: > > > > https://datatracker.ietf.org/doc/html/draft-muthusamy-dispatch > > -haptics-01 > > > > During the IETF109 meeting (minutes: > > https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and > > previous mailing list discussion [1], there was general > > support on progressing this work. Murray has previously asked > > the mailing list if the community thinks this is better done > > as either a short-lived working group or as AD sponsored [2], > > but got no answer. This is concerning for us, as if there is > > no energy to work on this proposal, spinning a wg out of it > > with enough active participants or even getting enough reviews > > to ensure IETF consensus might not be doable. So this is us > > reaching out one more time to hear if there is interested > > people who would be willing to get involved, and if so hearing > > your opinion if you think this should go through as AD > > sponsored or will need its own wg (my preference). > > > > Francesca > > > > > > [1] > > https://mailarchive.ietf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-D > > rgOR5I0oSDcQ/ [2] > > https://mailarchive.ietf.org/arch/msg/dispatch/GIYE2v8UkxkBVHl > > F3FHjT8Tmi3k/ > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon May 3 07:49:57 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6733A16CE; Mon, 3 May 2021 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=garr.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLKGKvYEGstb; Mon, 3 May 2021 07:49:47 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB903A16E0; Mon, 3 May 2021 07:49:46 -0700 (PDT) Received: from mac-allocchio3.homenet.telecomitalia.it (unknown [10.2.2.13]) by smtp-1.dir.garr.it (Postfix) with ESMTPSA id 2233C9FB6F; Mon, 3 May 2021 16:49:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=202004; t=1620053384; bh=w43+LwwZmtB4gz3CaZy+c6omRaVLKDy24ksAiYKCtMY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=MhPS5jqM8plxEflxGfA8p5FQYDNPX0VZAHwoLq81dTMvuJ2/8o3VZVoIZBw9Cr5pB ojmy/rz/+8/S4pIUHu+OX/NozyiDz+RWw7BkMXtEYH8oGcDHnMuEdshvl5uxiha5xF QegH7XkjjytMFYSBaucMhwXYUlvUffGw8bGHSD0VOluNZ3S+sOwKmYvNU/mZAcEPOJ /Cvbclz7mda3fkUn7WNboaP+yIe+gt2i6eDqutmwdvQ6jbNFHJW1Eech33ZH9cuEiM uI3XIJNDQxGyS05WfDkM8u/1YfCbzGv/JCfljEQ0hPhQjtfvHi0qDpfPDOjoIrENfr KvWZ0vs1KYrTA== Date: Mon, 3 May 2021 16:49:38 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: John C Klensin cc: Francesca Palombini , dispatch@ietf.org, art@ietf.org, ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, dispatch-chairs@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:49:52 -0000 yes John and Ned, it IS a good idea to have sug a registry, otherwise, as the I-D itselfs point out, we will end in complete divergent proprietary implementations. But to ensure the solution, although simple and in line with other registries, needs to be agreed at least by people who are working implemnting these solutions... so John's objection "two aut=rhots from the same company" worries me a bit. I'd like to have a revision (or even co-authoring) at leaset from Apple, Google and others. Just to be sure we creare a usable specification, no other reason... but it's important to check we agree and there is consensus. A "convened" short life WG ? just my 2 cents. all the best Claudio On Mon, 3 May 2021, John C Klensin wrote: > Francesca, > > Like others, I think this work is worth progressing. However, > precisely because of that, and because new top-level media types > are a big deal with a potential interoperability mess if we get > them wrong, I'm a little nervous about pushing a specification > written by two people from the same company through on AD > sponsorship. I think what we know from patterns of Last Calls > in the last few years is that, for a topic on which most IETF > participants have little in-depth knowledge and/or interest, the > Last Call will either produce silence or comments similar to > those during the DISPATCH meeting: "seems like a good idea but I > can't evaluate the technical details. > > So I'd like to see a WG. And, if the WG cannot get interest and > energy from a significant number of people from multiple > organizations, then there is an issue we should not overlook or > accidentally suppress: silence,whether on a Last Call or > otherwise, from everyone but a document's authors/proponents > does not IETF consensus make. > > I just noticed Ned's note and agree with everything he says. > The comments above get to the same conclusion he reaches > although from a different direction. And I favor a media types > WG over one specifically for the Haptics proposal alone for the > reasons he gives and one he implies: it would be significantly > more likely to draw significant participation. > > best, > john > > --On Monday, 03 May, 2021 10:39 +0000 Francesca Palombini > wrote: > >> Hi all, >> >> Murray and I are still looking for guidance from the community >> on how to process the Haptics proposal discussed in Dispatch >> at IETF109: >> >> https://datatracker.ietf.org/doc/html/draft-muthusamy-dispatch >> -haptics-01 >> >> During the IETF109 meeting (minutes: >> https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and >> previous mailing list discussion [1], there was general >> support on progressing this work. Murray has previously asked >> the mailing list if the community thinks this is better done >> as either a short-lived working group or as AD sponsored [2], >> but got no answer. This is concerning for us, as if there is >> no energy to work on this proposal, spinning a wg out of it >> with enough active participants or even getting enough reviews >> to ensure IETF consensus might not be doable. So this is us >> reaching out one more time to hear if there is interested >> people who would be willing to get involved, and if so hearing >> your opinion if you think this should go through as AD >> sponsored or will need its own wg (my preference). >> >> Francesca >> >> >> [1] >> https://mailarchive.ietf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-D >> rgOR5I0oSDcQ/ [2] >> https://mailarchive.ietf.org/arch/msg/dispatch/GIYE2v8UkxkBVHl >> F3FHjT8Tmi3k/ >> >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art > > > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys From nobody Mon May 3 08:24:11 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6C53A1839; Mon, 3 May 2021 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk3EfnfIKP79; Mon, 3 May 2021 08:24:01 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F40D3A1835; Mon, 3 May 2021 08:24:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYLBC2QSY800GAWZ@mauve.mrochek.com>; Mon, 3 May 2021 08:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620055133; bh=1BOrDGZLo5nem2cV7Pxqn2eK++ww+gAZ93Te2HKn5JI=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=lQBH/O0w7ej4SVEOa8CHUaDHZLNWWXs+c3MMBX1M/iMA+MQJpsOvP7H0WfjxuKFio aJ2EYuEpjsrB+ugJfYPlZHxBKCtzGCM9jbrDgwlyKwB+AfTfMgrEdiFbLXiQoUcfM2 kXZDqCBM3MdYEDLDUuIVuC+5HAjlZDHDSYnqg/WU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYLB732E4W00AUHD@mauve.mrochek.com>; Mon, 3 May 2021 08:18:50 -0700 (PDT) Cc: John C Klensin , dispatch@ietf.org, dispatch-chairs@ietf.org, art@ietf.org, ART ADs , Francesca Palombini , draft-muthusamy-dispatch-haptics@ietf.org Message-id: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> Date: Mon, 03 May 2021 08:15:22 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 03 May 2021 16:49:38 +0200 (CEST)" References: To: Claudio Allocchio Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:24:11 -0000 Accidently omitted one item from the list that I *did* know about: (4) Review the format of the media type registry. One suggestion, which I think came from John Klensin, was that given media type names can be grandfathered, the name itself isn't a reliable indicator of the of the tree, so a column listing the tree the type is in would be helpful. Ned From nobody Mon May 3 08:37:55 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1446D3A18A5; Mon, 3 May 2021 08:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quKJ_zcHgsmb; Mon, 3 May 2021 08:37:41 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366BF3A18A3; Mon, 3 May 2021 08:37:41 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FYnD23HSWzyVM; Mon, 3 May 2021 17:37:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 3 May 2021 17:37:38 +0200 Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" X-Mao-Original-Outgoing-Id: 641749057.865182-4f28f307c53c71d76f6553ebffc36dbc Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> To: Samuel Erdtman X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:37:46 -0000 On 2021-05-01, at 23:28, Samuel Erdtman wrote: >=20 > Hi Carsten, >=20 > One more thing, you wrote "Signing data at rest certainly is a use = case that is worth addressing.". With my new fond insights (thanks) does = this mean that you are in favor of specifying how to do enveloped = signatures for JSON (or at least not against it)?=20 Signing data at rest doesn=E2=80=99t mean that the signature then needs = to be put into the signed object. This is essentially adulterating that = object, and is part of the XMLDSig =E2=80=9Cwhat was just signed?=E2=80=9D= practicability issue. (Such as, does my countersignature include the previous signature or = not? What does it mean to sign a signed object? Nothing about the existing = signature, or does it mean I endorse the existing signature, or does it = mean my signature actually is conditional on the validity of that = existing signature?) I=E2=80=99m not sure though I know what an =E2=80=9Cenveloped = signature=E2=80=9D is, and whether what I just said above even replies = to what I asked. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 3 09:06:47 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823023A1AC3; Mon, 3 May 2021 09:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZYqBD1MzaAi; Mon, 3 May 2021 09:06:38 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506EE3A1ACB; Mon, 3 May 2021 09:06:33 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FYnsM44y6zyY6; Mon, 3 May 2021 18:06:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 3 May 2021 18:06:31 +0200 Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" X-Mao-Original-Outgoing-Id: 641750791.121515-81ca36c7b085c8c48b5f85ba11209a5e Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> To: Samuel Erdtman X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 16:06:45 -0000 Hi Samuel, I haven=E2=80=99t responded to your message yet as it triggers some = MacOS mail misbehavior. Let me try anyway, I hope you can parse the result. > On 2021-05-01, at 23:24, Samuel Erdtman wrote: >=20 >> Thanks Carsten, >>=20 >> Your clarifications were great! >>=20 >> See some comments inline. >>=20 >> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: >> Hi Samuel, >>=20 >> > 1. What do you mean with data at rest, data store in database or = file? >>=20 >> The point is that you are not signing the data being transferred, but = a local copy of some (e.g., freshly decoded) data (i.e., at the data = model level) which is then processed a little (potentially taking out = all signatures) and then is run through a rather complicated engine to = produce a signing input that is a deterministic function of the decoded = and processed data. >>=20 >> There are easier ways to get a signing input from JSON-like data at = rest. >> For a (quite workable) strawman: How about doing a CBOR encoding = using deterministic encoding rules? >=20 > This is a good point. Still not convinced other solutions would be = orders of magnitude better and the proposed one is easy to implement and = easy to understand (maybe too easy since I had not thought about your = alternative solution).=20 It is hard to measure interoperability in orders of magnitude=E2=80=A6 Doing a CBOR signing input is easy to implement and easy to understand, = though. No UTF-16 needed :-) >> > Or is it data that does not change? Sorry I do not get it. >> >=20 >> > 2. What is weird with saying "Represented in JSON=E2=80=9D? >>=20 >> Your scheme does NOT require (or benefit in any way from) = representing the data in JSON. >> The data could be transferred in YAML (or CBOR for that matter): as = long as your local copy of the decoded data (after the little = processing) sticks inside the confines of the I-JSON data model, you can = use your scheme for signing. >>=20 > But since JSON according to https://tools.ietf.org/html/rfc7159 is = fairly flexible, would not fitting it into CBOR require similar = limitations as RFC8785 puts on what you can do with the JSON? (i.e. the = I-JSON limitations) It does require some thinking. https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 documents what = we arrived at when discussing that in the CBOR WG. (I=E2=80=99m very well aware that many applications would be content = with just I-JSON, because they already have made their peace with it to = enable JavaScript classic processing. So I=E2=80=99m just answering the = question here.) >> > is it that the RFC7493 I-JSON subset is not all that JSON could be? = (to me this is a reasonable limitation that I in practice never have had = to go outside) >>=20 >> Well, that has been debated to death, and it is clear that nobody = likes I-JSON (*), but it is the de-facto boundary within which the = actually more capable JSON format needs to be used these days. >> (If you need more flexibility, you know where to find CBOR.) >>=20 > So are you saying that CBOR would not impose the same limitations on = the original JSON as RFC8785?=20 Yes. Again, please see = https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 Please note that I=E2=80=99m not making these points to push CBOR, even = though I=E2=80=99m really convinced CBOR and its =E2=80=9CJSON mode=E2=80=9D= can play a helpful role in addressing the underlying requirements. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 3 09:13:23 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5536F3A1A91; Mon, 3 May 2021 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxyYMAL_5JN9; Mon, 3 May 2021 09:13:17 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20080.outbound.protection.outlook.com [40.107.2.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9633A1A95; Mon, 3 May 2021 09:13:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IJGyzGYg39UgVAkW4yjntWv6R1C3vNf5yrzlVTeXSDw6sUgI4SkVIztQFj6HjrZaXyfPISPAoI5FFq99DUdPoAnuN3Bb5X3QC57z7mAoBWj43pfWLu+XvPxagemGVpfyQD97jtGhQ6oeKpewhlJ5ECGJYUZjjYE1ncJLOMZRBKzhaU2P1zzn8JnadADzw3yX2LKdjIFCR7Mx7/CxWI4SJpOQ5mhPeTMKn+PnJhyBv/d8ObtvyOtw+W7oMutVnAssaTAFMO1s2PmO0p6FaxUzZf+aq8JXcKoKVHtd7LJ1mz+5lJpRqorgJO+fYnzxZQpQ3fPBwqVawMvoIalON8Rk9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VtuJnnbwIk1T/c08b03W+Dr+YMfkh7PWQhbm5uehkBQ=; b=QndC3kb0ih8Z2fZzu8MZ+Dch1Up4l/iOrAeOv4oWzJKsNi8FXmjHQaM1Vx475y6Y63SyW/OAOTntXa3jFJiwOZLgKON/PH6Phylu9bzm8hXkulOCKZbJ24DjxNsi6K3nzY9tckxXvCelhdLlo/TFx+AEh6FoAt6VfTw/SeXKMzc9+L5aRxh/dKevWkq7sfHbY/nP/elRvN1/w6TF7myi+oQ/1s1SU5+9/lN0aaAY0B5NZPWAoaS/tM2c4ysfx0+eN2/+66VsNjFaDw+ZpLjtw2DBPyTuXqh7iB6vcgPqfbHSSpMJLV/VuYs5nws1ejxiMZTU7YmynZFsIMDb1Yd6pA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VtuJnnbwIk1T/c08b03W+Dr+YMfkh7PWQhbm5uehkBQ=; b=r57xtKjnVCiAgJ97zzg5S/xvM7cIWhWp6+aZX1Ux4x5dNZgE0Lp6tQZjsSCsiHAOOyl5p7zM976BzIMNie+GJMP/Q8CDIy4JCWx6as6Z2yRXVsm6rwl/0FxqI025vUYU98GwrOGlwW5ZiR5d/tZikNieS1Crk2ZmL04E8uiPfPY= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0702MB3625.eurprd07.prod.outlook.com (2603:10a6:7:8b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.20; Mon, 3 May 2021 16:13:14 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::593:f4fd:94e3:d90b%5]) with mapi id 15.20.4108.023; Mon, 3 May 2021 16:13:14 +0000 From: Francesca Palombini To: "media-types@ietf.org" CC: "dispatch@ietf.org" , "art@ietf.org" , ART ADs Thread-Topic: [dispatch] [art] Status of Haptics I-D in DISPATCH? Thread-Index: AQHXQAiXhkWIzY99rEKfQgzWZ5WHhKrRyR2AgAAN5gCAAAm1HIAALyyA Date: Mon, 3 May 2021 16:13:14 +0000 Message-ID: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> In-Reply-To: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:d19f:93a7:d3b5:5464] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 92899a90-2ab1-419f-68e1-08d90e4e5ac7 x-ms-traffictypediagnostic: HE1PR0702MB3625: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rSyg9CUeOWIV/PwJ4lV2X+K6Pb1R+kj1nn6Tugu9qlz7KZfeCb7wYJ/ZCgJFIAkG0mwFyHrNCpRWWpV0f8QnbOd+asmXB8EZ08mQOB5bplYAJIGpn5snu46H59pteuvYZyaXlbwI0SmBtl5aOapJ5Gsg7+9IkNhQ6ROPmoLSQbqmn2pj2ADtTmbXzF5DdvgHokX29slQCPw5RqUbg8s2LsYVfuueUTDfySURhxhERZnGcs9Ew82PH4saP2JbBNDgqoiMIXiogpf5dXoFMGbEuMxWGutCMN4lDs5bTgKHo/7UuCWVl9Gp7uhz7Jkot2MviyTHVsfPkbVQNzeaVWK5oXX97JOppouy51dh55Nm4NyXCWnr49pMfMEjtSK4lDQDziFGkjp5uW7bc3NkzI0SODQNxqjfnp3+bZd9QIGw/9Xj1BLSYfGdXUOKybq4nXYCCzRZiaaRYrooRPpkjdi4U5E5Od3XQTCpr0w+nV9Hd37h0KxK1wS2c/3LgA1Euo77V7qCDdGyMq6uXal6S7l05VAMX/KFpHoxV9Z/kAqqvzjt+85N6C0+7mZA7jVZcqG1TZ8De8gehUXxUNvU15GKfxav0iyJiLiagOUijO2Y3L2IrhAgDHCFLuznIw3A9dxDJZMftBEk6etj1u7h3rAFy76t9+Ox9rKpVy8FTTnftn/pcGEyBfkmklaBbD/BCIySMytqbMEnV3vfF1NGPniAMpYdqTz6ImyCUdIqySAqdwI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(346002)(39860400002)(366004)(6512007)(6486002)(5660300002)(122000001)(186003)(38100700002)(6506007)(66446008)(71200400001)(44832011)(316002)(66556008)(64756008)(2616005)(8676002)(76116006)(6916009)(86362001)(66946007)(8936002)(83380400001)(450100002)(33656002)(478600001)(966005)(36756003)(2906002)(66476007)(54906003)(4326008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?MFdBYmNwRE50bUR1bEFBRTdjTDJ6ZS9LZTEyWVBNNGZzSCtyTm1lZ3NBek1E?= =?utf-8?B?aUZaaEZnbC91ZFNseVFZcS9oa01COXBabE9nZjJlNm50YWZEL0NuY1pld292?= =?utf-8?B?T3dhaG9rektjZjJINUZEdVdaVTA1N3M1U1dwOEJPTUVRR29NakQ5L0RsVG42?= =?utf-8?B?UThjR2c1SGM2WVlGQy9CRW9JSHBZcVk5RHBBQ05MOEVhcEt5VThMdDRxS0Z5?= =?utf-8?B?S0F2TU9sMG5lbE42RndBdy9PbDQxTTd5dXZtNnZudUtyVE5ZS2N5Uy9XZks5?= =?utf-8?B?WHhra1lUbStxRm95cVpnMEdSM2JHQVBDZjhJOGVjVzYwM3pyQU5WUGxIdENZ?= =?utf-8?B?VWJWSzBYZVF4SHZKc3c5TjQ1YWNtQndLRWliT2dQdlhFWWdEYlVvWXAwZXBt?= =?utf-8?B?VmJVNFlGZVZscGM3OW9hRElDMnZEQnZMSlhZY0JudDA4MzByeHpHdFRLTFFH?= =?utf-8?B?ejhkMnVVdUlNemtaVWhtTzh2SHJRQnRJeG9yR291WllDZGg3OExSUUp1TGJw?= =?utf-8?B?YVV2T3NRbHFPdnB1SS83d0ZTOU5GNFJ2a0labWZmUjFWWFpid1RWVlJlYTl5?= =?utf-8?B?azZuS0tYK1FINURJTUN1bVlXSThWNCsybExrVGpNN1dpYStIaHJZUGY1SFpB?= =?utf-8?B?eXZob1NYYzdnRS9XTDM2bTF5b0JvRXFWR2NSeE9vbEJocWNtRFAzME9BRHdn?= =?utf-8?B?RUFZNW5paUZPMUxxbllWTCsvdHM5SXl1M1V3SDhiUWtCeEpVcGhKbHEzOWNr?= =?utf-8?B?ZnpZUmVYQ25WdUlyTHNuaHMyTGRCeFlsWm9VMnVBMFpBQWhxdSt5cCtNanJJ?= =?utf-8?B?M0hBZzRlWUNjZjRaRmVnOFdmNWtZcEczMzJDMnQ1enJkcmxuTVBZdjBpYjVJ?= =?utf-8?B?Y2tRVXF6R0JTellibWxXVWxaL3hjWElxY3FROWFkTWVuS0F6RldOWURvRG1x?= =?utf-8?B?Tm8yRXE1a1VZTitPUkZDWGNJRm9mTWtzemlLVGtGMXAzaFNRUE5BVXN4ZXR4?= =?utf-8?B?Q3hhOHd1Um5ONk05YmR3Z2QxTERCQjdLY0xOaG1wTzJ0cGdheTZpdmZjN1gw?= =?utf-8?B?enFtcDNoYWJNK1pVN1FRQm9lS0RGd2VqbysrUFdFdGxkMTFyNXpkdHUvc1JI?= =?utf-8?B?bnc1VUJIa0Jqc2h5czlNcWsxYUdoL1NYZytEb2dnK2t5bkZPSm1mZ09KbjNh?= =?utf-8?B?V2l3WU0vL1R2MzJXVEt3aGhMRjVoTHBYWDA1ekpweUxXVThtZEdYUmVYaXFZ?= =?utf-8?B?cHN6ZnBCdjBhblI0UEY2R1p6Qy9pcmU3V3BQQkNQVmdFYy9BQXVEaTh4Smkz?= =?utf-8?B?WDR4cjhOdlAyeW1qeTBsb2x4TmVMS2drSGFwTkJ3UTdmYmxGY25XUzlCTG1w?= =?utf-8?B?MzY4MGV3SDNtWEJMbjZ4YnA2a3h1dWJ5NWZFYmF3eEZKU1NUWlU2a21ta2Fj?= =?utf-8?B?d09TQlFMT1RnbXJlRUNpdkg5aXNFN0ZsREhXaVRGcVdoUXlXNFZuTTJJaFhP?= =?utf-8?B?L24xeUF5UHhHN1JXbE9IaW9OVTMyQnNKZ2xCZTRZSlI1VXJRNlZNMFRpaFpJ?= =?utf-8?B?VXdRQWFlTEtXNE5od1RWL3ZlcUgvL3Nva0ZYTzRHZU1PdTRYclB2S3p1cEhD?= =?utf-8?B?d0NNVlVSbmU3N1UwTUhyN1RlNURYWFl2WFQ0NDZPSXlSYzlOSE4zN1FrdlRJ?= =?utf-8?B?N0RtOWN6dnNLcnVhY2pINmlMUG5iTi92RU9oLzE4Qkd4dzYrZ3FpN2w5YWF3?= =?utf-8?B?NEVadFZQMWl3U05tb3VoeTNaWkVkT2R5TmZhcWlrNTdhTFB1emZ3eVlEbDlP?= =?utf-8?B?RzNoYlhWZWFUTFQ3WmdDRXJBcGxmWEs3c010TEloWGN1NnBlOCtwMFYxUjY4?= =?utf-8?B?OTdFcWQ0NWdsUjJDdGFJcU9pd3VEOFhMVVRaS3dKeWsrSHc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 92899a90-2ab1-419f-68e1-08d90e4e5ac7 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 16:13:14.2062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +idzdO9h0cTKbHd4t41aOgEjemQSYU0QtlC9YWVBAb/QZsyIYzU4fVAkOR+dD/r3t3APpH8by7SBsJX55aZ+sbPYtgxlRGZgR8HBMeFyKNfoC5rD864QuAzxOHwNAXLc X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3625 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 16:13:22 -0000 SGkgYWxsLA0KDQpXaGlsZSBsb29raW5nIHRvIHByb2dyZXNzIHRoZSBoYXB0aWNzIHJlZ2lzdHJh dGlvbiByZXF1ZXN0IChhbmQgZm9sbG93aW5nIGRyYWZ0KSBbMV0sIE5lZCBoYXMgc3VnZ2VzdGVk IHdlIG1pZ2h0IG5lZWQgdG8gY3JlYXRlIGEgbWVkaWEgdHlwZSB3b3JraW5nIGdyb3VwIHRvIHdv cmsgb24gbWVkaWEgdHlwZSBpdGVtcyB0aGF0IHJlcXVpcmUgcGFydGljdWxhciBhdHRlbnRpb25z LiBUaGF0IGNvdWxkIGluY2x1ZGUgdG9wIGxldmVsIG1lZGlhIHR5cGVzIHJlZ2lzdHJhdGlvbnMs IGFuZCBhbHNvIG90aGVyIG1lZGlhIHR5cGUgcmVsYXRlZCBpdGVtcy4gVGhpcyB3b3VsZCBub3Qg Y2hhbmdlIHRoZSB3YXkgbWVkaWEgdHlwZSByZWdpc3RyYXRpb25zIGFyZSBkb25lLCBidXQgcmF0 aGVyIGNyZWF0ZSBhIGZvcnVtIGZvciBkaXNjdXNzaW9uLiBOZWQgc3BlY2lmaWNhbGx5IG1lbnRp b25zIHRoZSBmb2xsb3dpbmc6IA0KDQo+ICgwKSBUaGlzIGhhcHRpY3MgdG9wLWxldmVsIHR5cGUu DQo+IA0KPiAoMSkgVGhlIHByb3Bvc2FsIHRvIGFsbG93IG11bHRpcGxlIG1lZGlhIHR5cGUgc3Vm Zml4ZXMuDQo+DQo+ICgyKSBNZWRpYSB0eXBlcyBmb3IgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzDQo+ DQo+ICgzKSBJbXByb3ZlZCBndWlkZWxpbmVzIGZvciBjb25zdHJ1Y3RpbmcgbWVkaWEgdHlwZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCj4NCj4gKDQpIFJldmlldyB0aGUgZm9ybWF0IG9mIHRo ZSBtZWRpYSB0eXBlIHJlZ2lzdHJ5LiBPbmUgc3VnZ2VzdGlvbiwgd2hpY2gNCj4gICAgICAgICBJ IHRoaW5rIGNhbWUgZnJvbSBKb2huIEtsZW5zaW4sIHdhcyB0aGF0IGdpdmVuIG1lZGlhIHR5cGUg bmFtZXMgY2FuIGJlDQo+ICAgICAgICAgZ3JhbmRmYXRoZXJlZCwgdGhlIG5hbWUgaXRzZWxmIGlz bid0IGEgcmVsaWFibGUgaW5kaWNhdG9yIG9mIHRoZQ0KPiAgICAgICAgIG9mIHRoZSB0cmVlLCBz byBhIGNvbHVtbiBsaXN0aW5nIHRoZSB0cmVlIHRoZSB0eXBlIGlzIGluIHdvdWxkIGJlDQo+ICAg ICAgICAgaGVscGZ1bC4NCg0KTmVkIGFsc28gc3VnZ2VzdGVkIHRvIGdldCBpbnB1dCBmcm9tIHRo ZSBtZWRpYS10eXBlIG1haWxpbmcgbGlzdCwgd2hpY2ggaXMgYSB2ZXJ5IGdvb2QgaWRlYSwgaGVu Y2UgdGhpcyBlbWFpbC4NCg0KSSBhbSBpbnRlcmVzdGVkIHRvIGhlYXIgeW91ciBvcGluaW9uLCBp ZiB5b3UgdGhpbmsgY3JlYXRpbmcgc3VjaCBhIHdnIHdvdWxkIGJlIGEgZ29vZCBpZGVhIGFuZCB5 b3UnZCBwYXJ0aWNpcGF0ZSBpbiBpdCwgaWYgeW91IGhhdmUgcHJvcG9zYWxzIHRoYXQgd291bGQg Zml0IGluIHN1Y2ggYSB3ZywgYW5kIGVzcGVjaWFsbHkgaWYgeW91J2QgYmUgd2lsbGluZyB0byBh Y3RpdmVseSBoZWxwIHRoZSB3ZyBjcmVhdGlvbiAoaGVscCBvdXQgd2l0aCBjaGFydGVyaW5nLCBj aGFpcmluZyBldGMpLiBPbiBteSBzaWRlLCBhbmQgc3BlYWtpbmcgb25seSBmb3IgbXlzZWxmLCBJ IGhhdmUgYmVlbiB3YXJuZWQgb2YgbG9uZyBydW5uaW5nIHdvcmtpbmcgZ3JvdXBzLCBidXQgSSBh bSBub3QgYWdhaW5zdCBpdCBpZiB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3QgYW5kIHBlb3BsZSBh cmUgd2lsbGluZyB0byBwdXQgaW4gdGhlIHRpbWUgYW5kIGVmZm9ydCB0byBtYWtlIHRoaXMgd29y ay4NCg0KRnJhbmNlc2NhDQoNClsxXSB0aHJlYWQgc3RhcnRpbmcgaGVyZSBodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Rpc3BhdGNoL3RXQ3hmREdZQ29UY1hsZDFhbkVHZXdZ STA1Yy8gZm9yIGNvbnRleHQNCg0K From nobody Mon May 3 09:30:14 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8BA3A1B33; Mon, 3 May 2021 09:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDYfQvbk6zAY; Mon, 3 May 2021 09:30:02 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8713A1B32; Mon, 3 May 2021 09:30:01 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id n32-20020a9d1ea30000b02902a53d6ad4bdso5608883otn.3; Mon, 03 May 2021 09:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hAxhVa4TKPdhMEJoHlGW0GXuR4Hwai93CJqEv81cD04=; b=XcJN2/BIxpccTA6Gf0OioObEQAnm3VGMIt3Z5mdE4ClDsIMJ/Xs7jfxZqww91CCJqn MscYV7btMswtsu6HCgOT2oY2JI56dpEtNOGwl6Jk+vfK1YPWbg07E6JAQKQoUZDnUlXv pyZ8xTVgUb1bOkYjTIt4GI33qwzNlAB8iAmZBPAdsvtPcmdlGjrO8Yu2RzKfmcNnPi2p 7ON9SGfdLf5ySUOVCYnm+pgJky4s0iobGvUXNIhKMlEvI7pzsseJFSsnuhWUp0nClyxj wz0X6a2bZFJwH/EFHd8YvwNUXg2s3atU8NFuIZKIjybgjkjmJjLEmLe4hizdF6wzULVB QGxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hAxhVa4TKPdhMEJoHlGW0GXuR4Hwai93CJqEv81cD04=; b=l+CGe/t9SYK6UKFYsmBrWZW7CQj6MwppjuI9VErVOB0zleKaKrm8GUh5gtxa40C1ux WJYkZDrbocfe4+QCWlflf+Q9pUJ48lQZ1xzj6xsyQtYQGVEfCuB4Yuy0EtbY2AHDa42w dz1SJqXvq1B++M/dLeROOCsKUucWg8pqBtciuomaLiw/HfW4UG+/RAsxDiYzHCDL8kXr s1pql+nh9044UsOA0x7GLSlKPjKu+t6KbmxF1wdhUqHGqlo8B0+8e5cWK7AE8VQ95JIy B9tH39hnZA6GvSbVMkwao4IR9C3B7UsmQLCrWEC2JbqZW2kOlKm8JUhpDImO8nqY1kLS GyHw== X-Gm-Message-State: AOAM532bKDPECFEFKawo8axk5yCRLkPGGoR5W6VjAyBvYTPk+FoRE0BM H+6KC7OSgAKdePL3sWWYoFp2dLYaU29KMjt+2/8= X-Google-Smtp-Source: ABdhPJx8zcAGC9Hi3mBUbge/422K8jmQViQuUlSP/u4A4TS5s8WgN3SDfjoGNgwE8HuPf1QVmPb2vNFiyIKaREpjKRo= X-Received: by 2002:a9d:be2:: with SMTP id 89mr15362347oth.269.1620059399749; Mon, 03 May 2021 09:29:59 -0700 (PDT) MIME-Version: 1.0 References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> In-Reply-To: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> From: Ted Hardie Date: Mon, 3 May 2021 17:29:33 +0100 Message-ID: To: Ned Freed Cc: Claudio Allocchio , Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , Francesca Palombini , draft-muthusamy-dispatch-haptics@ietf.org Content-Type: multipart/alternative; boundary="0000000000000987e605c16f79e4" Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 16:30:07 -0000 --0000000000000987e605c16f79e4 Content-Type: text/plain; charset="UTF-8" I think the set of work items Ned lays out might well be the basis for a working group. I have concerns, however, with including the registration for a haptics top-level type in that work. As the draft points out, there is a good bit of active work going on related to haptics in other forums (e.g. the MPEG Systems File Format sub-group). If the work on registering a top-level haptics type is interspersed with work on multiple media type suffixes and media types for programming languages, I have concerns about the speed with which it can complete. If we want to see haptic signals be treated appropriately as a media type, I suspect the time we have to do it is not unbounded. My personal advice is thus to progress the haptics work separately. If that means as an ad-sponsored draft, I'm personally okay with that, but I think the best other option is to do it as its own short-lived group. The other work (and the relevant expertise) is pretty distinct. Just my personal opinion, Ted On Mon, May 3, 2021 at 4:24 PM Ned Freed wrote: > Accidently omitted one item from the list that I *did* know about: > > (4) Review the format of the media type registry. One suggestion, which > I think came from John Klensin, was that given media type names can be > grandfathered, the name itself isn't a reliable indicator of the > of the tree, so a column listing the tree the type is in would be > helpful. > > Ned > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000000987e605c16f79e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the set of work items Ned lays out might well= be the basis for a working group.=C2=A0 I have concerns, however, with inc= luding the registration for a haptics top-level type in that work.=C2=A0

As the draft points out, there is a good bit of= active work going on related to haptics in other forums (e.g. the MPEG Sys= tems File Format sub-group).=C2=A0 If the work on registering a top-level h= aptics type is interspersed with work on multiple media type suffixes and m= edia types for programming languages, I have concerns about the speed with = which it can complete.=C2=A0 If we want to see haptic signals be treated ap= propriately as a media type, I suspect the time we have to do it is not unb= ounded.=C2=A0 My personal advice is thus to progress the haptics work separ= ately.=C2=A0 If that means as an ad-sponsored draft, I'm personally oka= y with that, but I think the best other option is to do it as its own short= -lived group.=C2=A0 The other work (and the relevant expertise) is pretty d= istinct.=C2=A0

Just my personal opinion,

Ted

On Mon, May 3, 2021 at 4:24 PM Ned Freed = <ned.freed@mrochek.com> = wrote:
Accidentl= y omitted one item from the list that I *did* know about:

(4) Review the format of the media type registry. One suggestion, which
=C2=A0 =C2=A0 I think came from John Klensin, was that given media type nam= es can be
=C2=A0 =C2=A0 grandfathered, the name itself isn't a reliable indicator= of the
=C2=A0 =C2=A0 of the tree, so a column listing the tree the type is in woul= d be
=C2=A0 =C2=A0 helpful.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000000987e605c16f79e4-- From nobody Mon May 3 10:27:42 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE43A1D6B; Mon, 3 May 2021 10:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wqu1270ZtOD; Mon, 3 May 2021 10:27:35 -0700 (PDT) Received: from outbound-ip12b.ess.barracuda.com (outbound-ip12b.ess.barracuda.com [209.222.82.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57F43A1D5D; Mon, 3 May 2021 10:27:23 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2177.outbound.protection.outlook.com [104.47.59.177]) by mx-outbound22-57.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 03 May 2021 17:27:10 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ns7WItnRbvfBLuzOgSDWh7KrYmOjj0QQe3UlljZpI0H4V5A/Ns5sfw0O/ZiZyoNiOJaGFydq3bdFdwPqC5nC+D+mzCVapEM6I+zjjXGDMsZYI2OU74gXXd1qqTGhRQC4N1bBZbnh0UC8kGha2oNpYCKVwIB7UaOAdJn4pKELJnyaZpAOC0TPakpK47PR+mxWJfjJsr1YtNTcyGQl86CYM9ZKP2FaZYpzpBwZxGOrbzTzPCz559u2hmj4R1zik4l1i4NHVpvBMOPSzsv+olMzaYWPV8eVdDlYCYQGCsA7Yurori96456tHNBPBJi69HpS1yU9lI1lrHtjwrcw4t8MLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1wH3LBzHWobw5lh8LIudSPyaA77u5f7suWsr3NnKfNg=; b=lPq+KZabNwhZ5A7NqPuCbW8kfhlGYM1mY+aPHp3oGbUkWVVDHijPJXQJohcWE9jTA8tliHV39TdU+cXQsW09PyP1Nbb9CL93/BVJT0rbW5u/3TnxlPlnNxgDRFa58bNwtPlAsQ7weera5CGqBFaVgSF08g37RzavkycWpLbmVUcj87wReBd7zlh0qWg8jF9lbOmQqPdiZDZ3+M5ebIeRvWwpJKyhk1Nxy9gog/cxm5tZH9l5d5pj1heRf4VdRRwJqGY0ov28YEM6rAABu4GVEkooc3slXOk/DmrWGMRTd70tDxAcnFZhRg3WeP/ZSDvPVvyTKp5PV8QHkXdVPsglNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1wH3LBzHWobw5lh8LIudSPyaA77u5f7suWsr3NnKfNg=; b=GQXTeXTgtof2/iZAxOMjbOqfL8sDZfhbbjD9q8or5PQwXH4uDcNs6dVlR/nofNY8U1JTWblaOaKWTJGOy6Ia3k0c5td8aqug2uN5myIk7DfSGpaGozIJVnShCkqP4jJVSUxcJohROgpIIuNSxdEyrgv05OglomU19n55jD9mGnQ= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM6PR16MB3561.namprd16.prod.outlook.com (2603:10b6:5:1ce::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.41; Mon, 3 May 2021 17:27:08 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681%6]) with mapi id 15.20.4087.043; Mon, 3 May 2021 17:27:08 +0000 From: Yeshwant Muthusamy To: Ted Hardie , Ned Freed CC: Claudio Allocchio , Dispatch WG , "dispatch-chairs@ietf.org" , Applications and Real-Time Area Discussion , ART ADs , Francesca Palombini , "draft-muthusamy-dispatch-haptics@ietf.org" Thread-Topic: [dispatch] [art] Status of Haptics I-D in DISPATCH? Thread-Index: AQHXQAiXhkWIzY99rEKfQgzWZ5WHhKrRyR2AgAAN5gCAAAmtFIAAEj6AgAADbRA= Date: Mon, 3 May 2021 17:27:08 +0000 Message-ID: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.43.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44fadb4a-d6d4-401a-0b11-08d90e58ae09 x-ms-traffictypediagnostic: DM6PR16MB3561: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5WbLGykMLUnZDYeuSpEyHgLNgPCiF9d4FdggEddoe5ZSy5s5hRplujoXsLkUAFBDsEjj6vLWoZRMJRs7XmFMCNkpW3wFjZsLRwzkF4LIS9cdIGWGBdRzNtqvgjuy5Iv46/5pJwA3mTCdfL70jhpnWrRyPMslwbKbN77mvWZ6I57SLmYphNZ/MbZozp+ZsoL3RYCku7v+jHGUcVP5I0Gl8pB6S/XWpqsVlw9TsJnSmFfqLJIyq9juB4yF8VbxVZJkYrRQpqbcQ5rANxYsBPn/O0Dn089NvyYCEbzDnnUf6jPk2l+58SILT60vhAKr8WmHR0RW4qc1mvjXBn0TYzABAUiIjAYbStwHIwjSAPB4Kn/8UmtHpxoF2LNO6EIGlQqRlO0GIZv8MbdWWZYcX309rzZHiqSL/j4tTYhxoXCVGagZy4ZqmUAZA44yRJDEcW1JrvDUFzmtsq2yPGJDda1e25+5DwmR3fpUsq/pKyoi9AjQiA0+61y/zLdZbpccQOlYKc9cqJ+vORcgB1JGF1Xk1rQSh9gFjLVHL3NvCuQjh/ib7OCwkdXoN9pWTttPP/QDBK/0kZAD89ja5OZZvgGOMPRcz6LBMtdEEAa3PFZ1lU2NwH2A7txrhTHKz+KQCqihUqOsvVuiteGrjgFqRYH20QH4SHv5i4HiWx9aVzRuMdPsF12F52xUKlFVnu0KHVT5 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(366004)(136003)(376002)(39830400003)(122000001)(54906003)(478600001)(38100700002)(53546011)(86362001)(83380400001)(66556008)(8676002)(186003)(66616009)(66476007)(2906002)(99936003)(110136005)(66946007)(7696005)(64756008)(33656002)(66446008)(26005)(4326008)(21615005)(8936002)(71200400001)(316002)(55016002)(9686003)(76116006)(52536014)(166002)(966005)(6506007)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?VERnQmZOVzlLQ1FmY1hheHZyM3ZvZlowRVFtdEJqVDVtMkhoSEdUeHRQVXNQ?= =?utf-8?B?dUljN0RVb0E5V0Jhc3d3RlNEc0dFN1Q2bUlkVlpDcjhuQ3prYVpzMTFwSHFH?= =?utf-8?B?NTJCck1LZVBDVzg5VlpIMGNQVS9lNmo0ZW4zRWJXaVdIT3l5QWZKdWdhYldY?= =?utf-8?B?U2oxTVBFb0ZBdjMzaHR1S3RDSFA1dWZMK1FneG05L3B4UkFRSmNTVm84eDY0?= =?utf-8?B?NGpPa1hDQWVZWk1jbjBEbGRYWUptREFXWFVERzgrOFlwN3VhSkMzeUpoa050?= =?utf-8?B?eitsclgrUmovZ1RiTWg1dUZwU0VsOU9ZLzRGenVuakFQaUFtZWZWMDU1VFlq?= =?utf-8?B?SStQaFBFNWVLZm9TQk9iTVN4UjJoUVVaM2lYbHVZODdiSmJRaUxoenJGcGVJ?= =?utf-8?B?Nmh6a00yaGdTTlgyVXdoK0FqaDVBc3ArZWRLd2ZLNlJ1TXg5N2liYW1UNmw4?= =?utf-8?B?N3pQRnlBa215V2R4WHd3cTU5YkljUXlWMlZlWGRBRGMrMDh0YTNwcDQ0K1Bp?= =?utf-8?B?VmxYK1Q0T1NndndWWmxvMHo3VmlYMXMrMEt1eHhsVEdxbWluRWYxd3BYa2pL?= =?utf-8?B?bVhkTjNtZlJ4UXVEc0tDaU9Tcm1oR1VCU2Y3SFpIVExzQWNnWFlEdm5RNDhw?= =?utf-8?B?U2UzdkVwME1OUmlTelEwTEFncGEzM2V2U0NFUjFvZ1Q5YW8vcTJiS29JZGto?= =?utf-8?B?SjhaWlZ4YlBhR3JGWjRGVlpHcFNYNmxGN2RPcUxIVCs1NWQ4YUhBYnN0VitI?= =?utf-8?B?M0N4K0p3OHJqQnB3Y1NnUUdOejZBNGw1TDVMS1p0ZGVsWGtXWmxwZGFRRFlo?= =?utf-8?B?bkM1Y3ZoL2VlSHVGNWZFOVJtVU96b2pLRDlzd0gwT0I4Z0grVyt3Y2lkUTRL?= =?utf-8?B?YXVHQS9pR0Q0dStDSVgzN2dtZnFtbmI5cmQ3NmNzeG9XY2xnQXhIYlFWOFVx?= =?utf-8?B?NU0zS1ErYS8rTzZLYWQwM0h5dERHRGE4VG9yUGJGbTZmeUs0VkgwdjlwUS96?= =?utf-8?B?dUtxQW96VkplZnpJWFJVcWcwMDhkVjNpTlVod2NnVjd3YWNnZWJRanF5dXhq?= =?utf-8?B?T0NvVTlXY0dUcFY3Sjd5U0ErTlNqVzdRQ3FqaW1YYmZ0amtaaVFUM1R2ZkN6?= =?utf-8?B?alpTVHhuUGUrOEI2ZzA4alhNQzRNNk9PRTBRZUhUdWlGL0dsNlo5S0RzZEs3?= =?utf-8?B?NjNRdFZMMzA3ZVdjckpBTWhyRzlMMXRTakt2d25saWdUeWhVZTEraERuc0Vm?= =?utf-8?B?Z3hESWxKd3VHK2hFR3BlUHN6aENSUlAzYVI0bVc4c0J6TURMWlR0NVNjV1hT?= =?utf-8?B?eUtWOGRad3F3cHVZMFVNL0Fwa3BLYWpSdzRTSjhKMjBzeWQydTVaWGg0cnBI?= =?utf-8?B?d3FheGtJZllzaXRQZXorc2NydXNmTWpFNUFWYWdMSm03RDZab0lIOWg1bys0?= =?utf-8?B?ZVlEYklpT3dESGtmK0VoM21ibTRLRkwzaXJHcFdPcTlqbzcwRkZGd1FXNXlI?= =?utf-8?B?RjZEeVF1bkJGUUVqUjY0S3ErOXdNTUZsa0FiSVYrVU5OdkJMdkpCY0c5U3Jq?= =?utf-8?B?WnJLU2c4bkpDQ0Rabi85OEs3ajh1NUpublQwdFNhaXVScmJSVjZZZU1uaUxl?= =?utf-8?B?NFJOdGkrQVc3UmEva2RPYStCeHUveVFTMWM4Y1VQZlBDeEYvQUx6YU1KZkRR?= =?utf-8?B?VnJUM0VuMkVpNVYrK1FoK1JQdHlCS2g5VDRTeTRwUTdHK0k1bE0xcnF0MlFk?= =?utf-8?Q?vphmeDnvGgNvw0FIn0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44fadb4a-d6d4-401a-0b11-08d90e58ae09 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 17:27:08.8787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UpdCZD6N34IW891hy11Vcg3rjZKwAokFTtBrWdYOUPf70RGQHYtiSeu1ofln5J9j9TsIqMTsmAniJ5rGkieWSDAqPcnlK2bCPYwrm4UKedQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB3561 X-BESS-ID: 1620062830-105689-5370-38013-1 X-BESS-VER: 2019.1_20210429.1817 X-BESS-Apparent-Source-IP: 104.47.59.177 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.231982 [from cloudscan11-117.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.00 HTML_MESSAGE BODY: HTML included in message X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND, HTML_MESSAGE X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 17:27:41 -0000 --_004_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_" --_000_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCkZpcnN0IG9mZiwgZ2xhZCB0byBzZWUgc29tZSB0cmFmZmljIG9uIHRoZSBoYXB0 aWNzIEktRC4gVGhhbmtzIHRvIEZyYW5jZXNjYSBmb3IganVtcC1zdGFydGluZyB0aGUgbGF0ZXN0 IHJvdW5kIG9mIGRpc2N1c3Npb24uDQoNCkF0IHRoZSByaXNrIG9mIHNvdW5kaW5nIGJpYXNlZCAo YXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBJLUQpLCBJIHdvdWxkIHNlY29uZCBUZWTigJlz IGxhdGVzdCBwcm9wb3NhbCB0aGF0IHdlIG5vdCBvdmVybG9hZCB0aGUgV0cgd2l0aCBvdGhlciBt ZWRpYSB0eXBlLXJlbGF0ZWQgd29yaywgbGVzdCBpdCBlbmQgdXAgZGUtcHJpb3JpdGl6aW5nIG9y IGRlbGF5aW5nIGNvbnNpZGVyYXRpb24gb2YgdGhlIGhhcHRpY3MgcHJvcG9zYWwuIEkgYXBwcmVj aWF0ZSB0aGUgaW1wb3J0YW5jZSBvZiBOZWTigJlzIGxpc3QsIGJ1dCBUZWQgaXMgY29ycmVjdCBp biB0aGF0IHRoZSB0aW1lIHRvIGdldCB0aGUgaGFwdGljcyBwcm9wb3NhbCByZXZpZXdlZCAoYW5k IGhvcGVmdWxseSwgYXBwcm92ZWQpIGlzIG5vdCB1bmJvdW5kZWQuIE1vcmUgb24gdGhhdCBiZWxv dy4NCg0KU2V0dGluZyBhc2lkZSB0aGUgaW1wbGljYXRpb25zIChpbmFkdmVydGVudCBvciBvdGhl cndpc2UpIG9mIENsYXVkaW/igJlzIGNvbW1lbnQgdGhhdCBBcHBsZSBvciBHb29nbGUgbmVlZCB0 byBiZSBvbiB0aGUgYXV0aG9ycyBsaXN0IGZvciBJRVRGIHRvIGV2ZW4gY29uc2lkZXIgYW4gSUQg IChvciB3b3JrIG9uIGl0IGV4cGVkaXRpb3VzbHkpLCAgSSB3b3VsZCBwb2ludCB0byB0aGUgZm9s bG93aW5nIERyYWZ0IEFtZW5kbWVudCBvZiB0aGUgSVNPL0lFQyAxNDQ5Ni0xMiAoSVNPIEJhc2Ug TWVkaWEgRmlsZSBGb3JtYXQpIHN0YW5kYXJkLiBJdCBpcyB0aGUgb25lIHRoYXQgaGFzIG91ciBw cm9wb3NhbCB0byB0cmVhdCBoYXB0aWNzIGFzIGEgdG9wLWxldmVsIG1lZGlhIHR5cGUsIGFraW4g dG8gYXVkaW8gYW5kIHZpZGVvLCBpbiBJU09CTUZGIGZpbGVzIChsaWtlIC5tcDQsIC4zZ3BwLCBl dGMuKS4NCg0KaHR0cHM6Ly93d3cuaXNvLm9yZy9zdGFuZGFyZC84MTYwNC5odG1sDQoNCkZvciB0 aG9zZSBmYW1pbGlhciB3aXRoIGhvdyBNUEVHIHdvcmtzLCBhIERBTUQgbWVhbnMgdGhhdCB0aGUg cHJvcG9zYWwgaGFzIGdvbmUgdGhyb3VnaCB0d28gcm91bmRzIG9mIGJhbGxvdGluZyBmcm9tIHZh cmlvdXMgSVNPIE5hdGlvbmFsIEJvZGllcyAoaW5jbHVkaW5nIHRoZSBVUyBOYXRpb25hbCBCb2R5 KS4gQW5kIHllcywgQXBwbGUgYW5kIEdvb2dsZSBhcmUgaW5kZWVkIHBhcnQgb2YgdGhlIFVTIE5h dGlvbmFsIEJvZHkg8J+Yii4gV2UgYXJlIGhhcHB5IHRvIHJlcG9ydCB0aGF0IG5vIG9iamVjdGlv bnMgd2VyZSByZWNlaXZlZCB0byB0aGUgaGFwdGljcyBwcm9wb3NhbCBpbiBlaXRoZXIgdGhlIENE IG9yIERBTUQgYmFsbG90IHJvdW5kcyBmcm9tIGFueSBvZiB0aGUgMjArIE5hdGlvbmFsIEJvZGll cyB0aGF0IHZvdGVkIG9uIGl0LiBJdCBoYXMgbm93IG1vdmVkIHRvIEZESVMgYmFsbG90ICh0aGUg aGFwdGljcyBwcm9wb3NhbCBoYXZpbmcgYmVlbiBtZXJnZWQgd2l0aCBvdGhlciB1cGRhdGVzIHRv IDE0NDk2LTEyIGZvciBhIG5ldyA3dGggZWRpdGlvbikgdGhhdCBpcyBleHBlY3RlZCB0byBjb21w bGV0ZSBieSBKdWx5Lg0KDQpNUEVHIGhhcyBhbHNvIGlzc3VlZCBhIENhbGwgZm9yIFByb3Bvc2Fs cyBvbiB0aGUgQ29kZWQgUmVwcmVzZW50YXRpb24gb2YgSGFwdGljcyDigJMgUGhhc2UgMSBhdCB0 aGUganVzdCBjb25jbHVkZWQgTVBFRzEzNCBtZWV0aW5nIGxhc3Qgd2Vlay4gVGhlIENmUCBzZWVr cyB0ZWNobm9sb2dpZXMgdGhhdCB3b3VsZCBoZWxwIHN0YW5kYXJkaXplIGEgaGFwdGljIGNvZGlu ZyBmb3JtYXQgYW5kIGEgaGFwdGljIGRlY29kZXIgaW4gTVBFRy4gVGhlIHByZXNzIHJlbGVhc2Ug YW5kIGZpbmFsIENmUCBkb2NzIHRoZW1zZWx2ZXMgc2hvdWxkIGJlIGF2YWlsYWJsZSBpbiBhIGZl dyBkYXlzLiBEcmFmdCB2ZXJzaW9ucyBvZiB0aGUgSGFwdGljcyBDZlAgZG9jdW1lbnRzIGZyb20g TVBFRzEzMyBpbiBKYW51YXJ5IDIwMjEgY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHBzOi8vd3d3Lm1w ZWdzdGFuZGFyZHMub3JnL3N0YW5kYXJkcy9FeHBsb3JhdGlvbnMvNDAvLg0KDQpJIHByZXNlbnQg dGhlIGFib3ZlIGluZm9ybWF0aW9uIG5vdCBhcyBjb25jbHVzaXZlIGV2aWRlbmNlLCBidXQgYXMg dmFsaWQgZGF0YSBwb2ludHMgdG8gYmUgY29uc2lkZXJlZCBpbiBvdXIgZGlzY3Vzc2lvbnMgb24g dGhpcyBJLUQuDQoNCkkgbG9vayBmb3J3YXJkIHRvIHRoZSBuZXh0IHN0ZXBzIGFuZCB0byBhbnN3 ZXJpbmcgYW55IHF1ZXN0aW9ucyBvbiB0aGUgY29udGVudCBvZiB0aGUgSS1EIGl0c2VsZi4NCg0K VGhhbmtzLA0KWWVzaHdhbnQNCg0KWWVzaHdhbnQgTXV0aHVzYW15LCBQaC5ELiB8IFNlbmlvciBE aXJlY3RvciwgU3RhbmRhcmRzDQpbY2lkOmltYWdlMDAxLmpwZ0AwMUQ3NDAxMi4yRDI5OUQ5MF0N CnltdXRodXNhbXlAaW1tZXJzaW9uLmNvbTxtYWlsdG86eW11dGh1c2FteUBpbW1lcnNpb24uY29t PiB8ICsxIDQ2OS01ODMtMjE3MQ0KDQpGcm9tOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5j b20+DQpTZW50OiBNb25kYXksIE1heSAzLCAyMDIxIDExOjMwIEFNDQpUbzogTmVkIEZyZWVkIDxu ZWQuZnJlZWRAbXJvY2hlay5jb20+DQpDYzogQ2xhdWRpbyBBbGxvY2NoaW8gPENsYXVkaW8uQWxs b2NjaGlvQGdhcnIuaXQ+OyBEaXNwYXRjaCBXRyA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBkaXNwYXRj aC1jaGFpcnNAaWV0Zi5vcmc7IEFwcGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlzY3Vz c2lvbiA8YXJ0QGlldGYub3JnPjsgQVJUIEFEcyA8YXJ0LWFkc0BpZXRmLm9yZz47IEZyYW5jZXNj YSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmc+OyBkcmFmdC1tdXRodXNhbXktZGlzcGF0Y2gtaGFwdGljc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtkaXNwYXRjaF0gW2FydF0gU3RhdHVzIG9mIEhhcHRpY3MgSS1EIGluIERJU1BBVENI Pw0KDQpJIHRoaW5rIHRoZSBzZXQgb2Ygd29yayBpdGVtcyBOZWQgbGF5cyBvdXQgbWlnaHQgd2Vs bCBiZSB0aGUgYmFzaXMgZm9yIGEgd29ya2luZyBncm91cC4gIEkgaGF2ZSBjb25jZXJucywgaG93 ZXZlciwgd2l0aCBpbmNsdWRpbmcgdGhlIHJlZ2lzdHJhdGlvbiBmb3IgYSBoYXB0aWNzIHRvcC1s ZXZlbCB0eXBlIGluIHRoYXQgd29yay4NCg0KQXMgdGhlIGRyYWZ0IHBvaW50cyBvdXQsIHRoZXJl IGlzIGEgZ29vZCBiaXQgb2YgYWN0aXZlIHdvcmsgZ29pbmcgb24gcmVsYXRlZCB0byBoYXB0aWNz IGluIG90aGVyIGZvcnVtcyAoZS5nLiB0aGUgTVBFRyBTeXN0ZW1zIEZpbGUgRm9ybWF0IHN1Yi1n cm91cCkuICBJZiB0aGUgd29yayBvbiByZWdpc3RlcmluZyBhIHRvcC1sZXZlbCBoYXB0aWNzIHR5 cGUgaXMgaW50ZXJzcGVyc2VkIHdpdGggd29yayBvbiBtdWx0aXBsZSBtZWRpYSB0eXBlIHN1ZmZp eGVzIGFuZCBtZWRpYSB0eXBlcyBmb3IgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCBJIGhhdmUgY29u Y2VybnMgYWJvdXQgdGhlIHNwZWVkIHdpdGggd2hpY2ggaXQgY2FuIGNvbXBsZXRlLiAgSWYgd2Ug d2FudCB0byBzZWUgaGFwdGljIHNpZ25hbHMgYmUgdHJlYXRlZCBhcHByb3ByaWF0ZWx5IGFzIGEg bWVkaWEgdHlwZSwgSSBzdXNwZWN0IHRoZSB0aW1lIHdlIGhhdmUgdG8gZG8gaXQgaXMgbm90IHVu Ym91bmRlZC4gIE15IHBlcnNvbmFsIGFkdmljZSBpcyB0aHVzIHRvIHByb2dyZXNzIHRoZSBoYXB0 aWNzIHdvcmsgc2VwYXJhdGVseS4gIElmIHRoYXQgbWVhbnMgYXMgYW4gYWQtc3BvbnNvcmVkIGRy YWZ0LCBJJ20gcGVyc29uYWxseSBva2F5IHdpdGggdGhhdCwgYnV0IEkgdGhpbmsgdGhlIGJlc3Qg b3RoZXIgb3B0aW9uIGlzIHRvIGRvIGl0IGFzIGl0cyBvd24gc2hvcnQtbGl2ZWQgZ3JvdXAuICBU aGUgb3RoZXIgd29yayAoYW5kIHRoZSByZWxldmFudCBleHBlcnRpc2UpIGlzIHByZXR0eSBkaXN0 aW5jdC4NCg0KSnVzdCBteSBwZXJzb25hbCBvcGluaW9uLA0KDQpUZWQNCg0KT24gTW9uLCBNYXkg MywgMjAyMSBhdCA0OjI0IFBNIE5lZCBGcmVlZCA8bmVkLmZyZWVkQG1yb2NoZWsuY29tPG1haWx0 bzpuZWQuZnJlZWRAbXJvY2hlay5jb20+PiB3cm90ZToNCkFjY2lkZW50bHkgb21pdHRlZCBvbmUg aXRlbSBmcm9tIHRoZSBsaXN0IHRoYXQgSSAqZGlkKiBrbm93IGFib3V0Og0KDQooNCkgUmV2aWV3 IHRoZSBmb3JtYXQgb2YgdGhlIG1lZGlhIHR5cGUgcmVnaXN0cnkuIE9uZSBzdWdnZXN0aW9uLCB3 aGljaA0KICAgIEkgdGhpbmsgY2FtZSBmcm9tIEpvaG4gS2xlbnNpbiwgd2FzIHRoYXQgZ2l2ZW4g bWVkaWEgdHlwZSBuYW1lcyBjYW4gYmUNCiAgICBncmFuZGZhdGhlcmVkLCB0aGUgbmFtZSBpdHNl bGYgaXNuJ3QgYSByZWxpYWJsZSBpbmRpY2F0b3Igb2YgdGhlDQogICAgb2YgdGhlIHRyZWUsIHNv IGEgY29sdW1uIGxpc3RpbmcgdGhlIHRyZWUgdGhlIHR5cGUgaXMgaW4gd291bGQgYmUNCiAgICBo ZWxwZnVsLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5lZA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWls aW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3JnPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8aHR0cHM6Ly9uYW0x MC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGbGlu a3Byb3RlY3QuY3VkYXN2Yy5jb20lMkZ1cmwlM0ZhJTNEaHR0cHMlMjUzYSUyNTJmJTI1MmZ3d3cu aWV0Zi5vcmclMjUyZm1haWxtYW4lMjUyZmxpc3RpbmZvJTI1MmZkaXNwYXRjaCUyNmMlM0RFJTJD MSUyQ1ZpOWs3ZzFHbFVnVEtCdjI3QUxCc3h1UU9BLXJsd1N3UVJzZGVaM2dUdjZZcG5rS05oNzNW S0ROWVlrRnVBR1l5OUN5djBXWW5YaHE0aW14TTdXdnZLRThMTDlKa2ZURXZvVlhpZU9ZWGVTaiUy NnR5cG8lM0QxJmRhdGE9MDQlN0MwMSU3QyU3QzczZTU4NmNkMWQ3NzRkOWIyZjE5MDhkOTBlNTBi OWRlJTdDNGYwNWU0MWE1OWI4NDEzYWFlMTlkNWRmM2RmZDBmYjUlN0MwJTdDMCU3QzYzNzU1NjU2 MjE1NDA4ODU5MCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxD SlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRh PUZWQWR1T0NoZ3VMM2VreEclMkI0blczeVlRcXp3eWNaa0lMVlM0cklZd0thSSUzRCZyZXNlcnZl ZD0wPg0K --_000_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9sa3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZp cnN0IG9mZiwgZ2xhZCB0byBzZWUgc29tZSB0cmFmZmljIG9uIHRoZSBoYXB0aWNzIEktRC4gVGhh bmtzIHRvIEZyYW5jZXNjYSBmb3IganVtcC1zdGFydGluZyB0aGUgbGF0ZXN0IHJvdW5kIG9mIGRp c2N1c3Npb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSByaXNrIG9mIHNvdW5kaW5n IGJpYXNlZCAoYXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBJLUQpLCBJIHdvdWxkIHNlY29u ZCBUZWTigJlzIGxhdGVzdCBwcm9wb3NhbCB0aGF0IHdlIG5vdCBvdmVybG9hZCB0aGUgV0cgd2l0 aCBvdGhlciBtZWRpYSB0eXBlLXJlbGF0ZWQgd29yaywgbGVzdCBpdCBlbmQgdXAgZGUtcHJpb3Jp dGl6aW5nIG9yIGRlbGF5aW5nIGNvbnNpZGVyYXRpb24gb2YgdGhlIGhhcHRpY3MNCiBwcm9wb3Nh bC4gSSBhcHByZWNpYXRlIHRoZSBpbXBvcnRhbmNlIG9mIE5lZOKAmXMgbGlzdCwgYnV0IFRlZCBp cyBjb3JyZWN0IGluIHRoYXQgdGhlIHRpbWUgdG8gZ2V0IHRoZSBoYXB0aWNzIHByb3Bvc2FsIHJl dmlld2VkIChhbmQgaG9wZWZ1bGx5LCBhcHByb3ZlZCkgaXMgbm90IHVuYm91bmRlZC4gTW9yZSBv biB0aGF0IGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXR0aW5nIGFzaWRlIHRoZSBp bXBsaWNhdGlvbnMgKGluYWR2ZXJ0ZW50IG9yIG90aGVyd2lzZSkgb2YgQ2xhdWRpb+KAmXMgY29t bWVudCB0aGF0IEFwcGxlIG9yIEdvb2dsZSBuZWVkIHRvIGJlIG9uIHRoZSBhdXRob3JzIGxpc3Qg Zm9yIElFVEYgdG8gZXZlbiBjb25zaWRlciBhbiBJRCAmbmJzcDsob3Igd29yayBvbiBpdCBleHBl ZGl0aW91c2x5KSwgJm5ic3A7SSB3b3VsZCBwb2ludCB0byB0aGUgZm9sbG93aW5nIERyYWZ0IEFt ZW5kbWVudA0KIG9mIHRoZSBJU08vSUVDIDE0NDk2LTEyIChJU08gQmFzZSBNZWRpYSBGaWxlIEZv cm1hdCkgc3RhbmRhcmQuIEl0IGlzIHRoZSBvbmUgdGhhdCBoYXMgb3VyIHByb3Bvc2FsIHRvIHRy ZWF0IGhhcHRpY3MgYXMgYSB0b3AtbGV2ZWwgbWVkaWEgdHlwZSwgYWtpbiB0byBhdWRpbyBhbmQg dmlkZW8sIGluIElTT0JNRkYgZmlsZXMgKGxpa2UgLm1wNCwgLjNncHAsIGV0Yy4pLg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmlzby5vcmcvc3RhbmRhcmQv ODE2MDQuaHRtbCI+aHR0cHM6Ly93d3cuaXNvLm9yZy9zdGFuZGFyZC84MTYwNC5odG1sPC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhvc2UgZmFtaWxpYXIgd2l0aCBob3cgTVBFRyB3 b3JrcywgYSBEQU1EIG1lYW5zIHRoYXQgdGhlIHByb3Bvc2FsIGhhcyBnb25lIHRocm91Z2ggdHdv IHJvdW5kcyBvZiBiYWxsb3RpbmcgZnJvbSB2YXJpb3VzIElTTyBOYXRpb25hbCBCb2RpZXMgKGlu Y2x1ZGluZyB0aGUgVVMgTmF0aW9uYWwgQm9keSkuIEFuZCB5ZXMsIEFwcGxlIGFuZCBHb29nbGUg YXJlIGluZGVlZCBwYXJ0IG9mIHRoZSBVUyBOYXRpb25hbA0KIEJvZHkgPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIy Ozwvc3Bhbj4uIFdlIGFyZSBoYXBweSB0byByZXBvcnQgdGhhdCBubyBvYmplY3Rpb25zIHdlcmUg cmVjZWl2ZWQgdG8gdGhlIGhhcHRpY3MgcHJvcG9zYWwgaW4gZWl0aGVyIHRoZSBDRCBvciBEQU1E IGJhbGxvdCByb3VuZHMgZnJvbSBhbnkgb2YgdGhlIDIwKyBOYXRpb25hbCBCb2RpZXMgdGhhdCB2 b3RlZCBvbiBpdC4gSXQgaGFzIG5vdyBtb3ZlZA0KIHRvIEZESVMgYmFsbG90ICh0aGUgaGFwdGlj cyBwcm9wb3NhbCBoYXZpbmcgYmVlbiBtZXJnZWQgd2l0aCBvdGhlciB1cGRhdGVzIHRvIDE0NDk2 LTEyIGZvciBhIG5ldyA3PHN1cD50aDwvc3VwPiBlZGl0aW9uKSB0aGF0IGlzIGV4cGVjdGVkIHRv IGNvbXBsZXRlIGJ5IEp1bHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1QRUcgaGFzIGFsc28g aXNzdWVkIGEgQ2FsbCBmb3IgUHJvcG9zYWxzIG9uIHRoZSBDb2RlZCBSZXByZXNlbnRhdGlvbiBv ZiBIYXB0aWNzIOKAkyBQaGFzZSAxIGF0IHRoZSBqdXN0IGNvbmNsdWRlZCBNUEVHMTM0IG1lZXRp bmcgbGFzdCB3ZWVrLiBUaGUgQ2ZQIHNlZWtzIHRlY2hub2xvZ2llcyB0aGF0IHdvdWxkIGhlbHAg c3RhbmRhcmRpemUgYSBoYXB0aWMgY29kaW5nIGZvcm1hdCBhbmQgYSBoYXB0aWMgZGVjb2Rlcg0K IGluIE1QRUcuIFRoZSBwcmVzcyByZWxlYXNlIGFuZCBmaW5hbCBDZlAgZG9jcyB0aGVtc2VsdmVz IHNob3VsZCBiZSBhdmFpbGFibGUgaW4gYSBmZXcgZGF5cy4gRHJhZnQgdmVyc2lvbnMgb2YgdGhl IEhhcHRpY3MgQ2ZQIGRvY3VtZW50cyBmcm9tIE1QRUcxMzMgaW4gSmFudWFyeSAyMDIxIGNhbiBi ZSBmb3VuZCBoZXJlOg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cubXBlZ3N0YW5kYXJkcy5vcmcvc3Rh bmRhcmRzL0V4cGxvcmF0aW9ucy80MC8iPmh0dHBzOi8vd3d3Lm1wZWdzdGFuZGFyZHMub3JnL3N0 YW5kYXJkcy9FeHBsb3JhdGlvbnMvNDAvPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBw cmVzZW50IHRoZSBhYm92ZSBpbmZvcm1hdGlvbiBub3QgYXMgY29uY2x1c2l2ZSBldmlkZW5jZSwg YnV0IGFzIHZhbGlkIGRhdGEgcG9pbnRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gb3VyIGRpc2N1c3Np b25zIG9uIHRoaXMgSS1ELjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxvb2sgZm9yd2FyZCB0 byB0aGUgbmV4dCBzdGVwcyBhbmQgdG8gYW5zd2VyaW5nIGFueSBxdWVzdGlvbnMgb24gdGhlIGNv bnRlbnQgb2YgdGhlIEktRCBpdHNlbGYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllc2h3YW50PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlllc2h3YW50IE11dGh1c2FteSwgUGguRC4gfCBTZW5pb3IgRGlyZWN0b3Is IFN0YW5kYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxpbWcgYm9yZGVy PSIwIiB3aWR0aD0iMTQ2IiBoZWlnaHQ9IjM5IiBzdHlsZT0id2lkdGg6MS41MjA4aW47aGVpZ2h0 Oi40MDYyaW4iIGlkPSJQaWN0dXJlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQ3 NDAxMi4yRDI5OUQ5MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PjxhIGhyZWY9Im1haWx0bzp5bXV0aHVzYW15QGltbWVyc2lvbi5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDU2M0MxIj55bXV0aHVzYW15QGltbWVyc2lvbi5jb208L3NwYW4+PC9hPiB8ICsxIDQ2 OS01ODMtMjE3MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFRlZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNv bSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDMsIDIwMjEgMTE6MzAgQU08YnI+ DQo8Yj5Ubzo8L2I+IE5lZCBGcmVlZCAmbHQ7bmVkLmZyZWVkQG1yb2NoZWsuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gQ2xhdWRpbyBBbGxvY2NoaW8gJmx0O0NsYXVkaW8uQWxsb2NjaGlvQGdhcnIu aXQmZ3Q7OyBEaXNwYXRjaCBXRyAmbHQ7ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7OyBkaXNwYXRjaC1j aGFpcnNAaWV0Zi5vcmc7IEFwcGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlzY3Vzc2lv biAmbHQ7YXJ0QGlldGYub3JnJmd0OzsgQVJUIEFEcyAmbHQ7YXJ0LWFkc0BpZXRmLm9yZyZndDs7 IEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmcmZ3Q7Ow0KIGRyYWZ0LW11dGh1c2FteS1kaXNwYXRjaC1oYXB0aWNz QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGlzcGF0Y2hdIFthcnRdIFN0YXR1 cyBvZiBIYXB0aWNzIEktRCBpbiBESVNQQVRDSD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIHNldCBvZiB3b3JrIGl0ZW1zIE5lZCBsYXlz IG91dCBtaWdodCB3ZWxsIGJlIHRoZSBiYXNpcyBmb3IgYSB3b3JraW5nIGdyb3VwLiZuYnNwOyBJ IGhhdmUgY29uY2VybnMsIGhvd2V2ZXIsIHdpdGggaW5jbHVkaW5nIHRoZSByZWdpc3RyYXRpb24g Zm9yIGEgaGFwdGljcyB0b3AtbGV2ZWwgdHlwZSBpbiB0aGF0IHdvcmsuJm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgdGhlIGRy YWZ0IHBvaW50cyBvdXQsIHRoZXJlIGlzIGEgZ29vZCBiaXQgb2YgYWN0aXZlIHdvcmsgZ29pbmcg b24gcmVsYXRlZCB0byBoYXB0aWNzIGluIG90aGVyIGZvcnVtcyAoZS5nLiB0aGUgTVBFRyBTeXN0 ZW1zIEZpbGUgRm9ybWF0IHN1Yi1ncm91cCkuJm5ic3A7IElmIHRoZSB3b3JrIG9uIHJlZ2lzdGVy aW5nIGEgdG9wLWxldmVsIGhhcHRpY3MgdHlwZSBpcyBpbnRlcnNwZXJzZWQgd2l0aCB3b3JrIG9u IG11bHRpcGxlDQogbWVkaWEgdHlwZSBzdWZmaXhlcyBhbmQgbWVkaWEgdHlwZXMgZm9yIHByb2dy YW1taW5nIGxhbmd1YWdlcywgSSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoZSBzcGVlZCB3aXRoIHdo aWNoIGl0IGNhbiBjb21wbGV0ZS4mbmJzcDsgSWYgd2Ugd2FudCB0byBzZWUgaGFwdGljIHNpZ25h bHMgYmUgdHJlYXRlZCBhcHByb3ByaWF0ZWx5IGFzIGEgbWVkaWEgdHlwZSwgSSBzdXNwZWN0IHRo ZSB0aW1lIHdlIGhhdmUgdG8gZG8gaXQgaXMgbm90IHVuYm91bmRlZC4mbmJzcDsgTXkNCiBwZXJz b25hbCBhZHZpY2UgaXMgdGh1cyB0byBwcm9ncmVzcyB0aGUgaGFwdGljcyB3b3JrIHNlcGFyYXRl bHkuJm5ic3A7IElmIHRoYXQgbWVhbnMgYXMgYW4gYWQtc3BvbnNvcmVkIGRyYWZ0LCBJJ20gcGVy c29uYWxseSBva2F5IHdpdGggdGhhdCwgYnV0IEkgdGhpbmsgdGhlIGJlc3Qgb3RoZXIgb3B0aW9u IGlzIHRvIGRvIGl0IGFzIGl0cyBvd24gc2hvcnQtbGl2ZWQgZ3JvdXAuJm5ic3A7IFRoZSBvdGhl ciB3b3JrIChhbmQgdGhlIHJlbGV2YW50IGV4cGVydGlzZSkNCiBpcyBwcmV0dHkgZGlzdGluY3Qu Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5KdXN0IG15IHBlcnNvbmFsIG9waW5pb24sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSAzLCAyMDIxIGF0IDQ6MjQg UE0gTmVkIEZyZWVkICZsdDs8YSBocmVmPSJtYWlsdG86bmVkLmZyZWVkQG1yb2NoZWsuY29tIj5u ZWQuZnJlZWRAbXJvY2hlay5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjY2lkZW50bHkgb21pdHRlZCBv bmUgaXRlbSBmcm9tIHRoZSBsaXN0IHRoYXQgSSAqZGlkKiBrbm93IGFib3V0Ojxicj4NCjxicj4N Cig0KSBSZXZpZXcgdGhlIGZvcm1hdCBvZiB0aGUgbWVkaWEgdHlwZSByZWdpc3RyeS4gT25lIHN1 Z2dlc3Rpb24sIHdoaWNoPGJyPg0KJm5ic3A7ICZuYnNwOyBJIHRoaW5rIGNhbWUgZnJvbSBKb2hu IEtsZW5zaW4sIHdhcyB0aGF0IGdpdmVuIG1lZGlhIHR5cGUgbmFtZXMgY2FuIGJlPGJyPg0KJm5i c3A7ICZuYnNwOyBncmFuZGZhdGhlcmVkLCB0aGUgbmFtZSBpdHNlbGYgaXNuJ3QgYSByZWxpYWJs ZSBpbmRpY2F0b3Igb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBvZiB0aGUgdHJlZSwgc28gYSBj b2x1bW4gbGlzdGluZyB0aGUgdHJlZSB0aGUgdHlwZSBpcyBpbiB3b3VsZCBiZTxicj4NCiZuYnNw OyAmbmJzcDsgaGVscGZ1bC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTmVkPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTEw LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZsaW5r cHJvdGVjdC5jdWRhc3ZjLmNvbSUyRnVybCUzRmElM0RodHRwcyUyNTNhJTI1MmYlMjUyZnd3dy5p ZXRmLm9yZyUyNTJmbWFpbG1hbiUyNTJmbGlzdGluZm8lMjUyZmRpc3BhdGNoJTI2YyUzREUlMkMx JTJDVmk5azdnMUdsVWdUS0J2MjdBTEJzeHVRT0Etcmx3U3dRUnNkZVozZ1R2NllwbmtLTmg3M1ZL RE5ZWWtGdUFHWXk5Q3l2MFdZblhocTRpbXhNN1d2dktFOExMOUprZlRFdm9WWGllT1lYZVNqJTI2 dHlwbyUzRDEmYW1wO2RhdGE9MDQlN0MwMSU3QyU3QzczZTU4NmNkMWQ3NzRkOWIyZjE5MDhkOTBl NTBiOWRlJTdDNGYwNWU0MWE1OWI4NDEzYWFlMTlkNWRmM2RmZDBmYjUlN0MwJTdDMCU3QzYzNzU1 NjU2MjE1NDA4ODU5MCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFt cDtzZGF0YT1GVkFkdU9DaGd1TDNla3hHJTJCNG5XM3lZUXF6d3ljWmtJTFZTNHJJWXdLYUklM0Qm YW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_-- --_004_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=5147; creation-date="Mon, 03 May 2021 17:27:08 GMT"; modification-date="Mon, 03 May 2021 17:27:08 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/4QP0aHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MSA2NC4xNDA5NDksIDIwMTAvMTIvMDctMTA6 NTc6MDEgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0idXVpZDo1RDIwODky NDkzQkZEQjExOTE0QTg1OTBEMzE1MDhDOCIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpBMEI4 RUIyQzA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpB MEI4RUIyQjA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQ aG90b3Nob3AgQ1M1LjEgV2luZG93cyI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOjAxODIwNjY3NUYwNkU1MTFCQUZDQjk1NEQ4MTUyNEMyIiBzdFJlZjpkb2N1 bWVudElEPSJ4bXAuZGlkOjdlYjc0ZTdmLWMwMTAtNDUwYi1hODBhLTM4NmQ2ODUxMDQzYyIvPiA8 ZGM6dGl0bGU+IDxyZGY6QWx0PiA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPlByaW50PC9y ZGY6bGk+IDwvcmRmOkFsdD4gPC9kYzp0aXRsZT4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJE Rj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz7/7QBIUGhvdG9zaG9wIDMuMAA4QklN BAQAAAAAAA8cAVoAAxslRxwCAAACAAIAOEJJTQQlAAAAAAAQ/OEfici3yXgvNGI0B1h36//uAA5B ZG9iZQBkwAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAgEBAgICAQICAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIACcAkgMBEQACEQEDEQH/xACVAAAB BAIDAQAAAAAAAAAAAAAABggJCgQHAQMLBQEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAAGAgECAwII CA8AAAAAAAECAwQFBgcICQAREhMUIRUxMjQWFzcYGWEiVDW2ODkKQWIjU2MkZCVVZVZ3t3iIEQEB AQAABQMFAAAAAAAAAAAAAREhMUFxMoECQmGxEtID/9oADAMBAAIRAxEAPwCzfzV7CXrCOtWL61hy 2TdWzjmrZfClExipWpBwym1nsXbWdwfmMm1ds1H8E4VgWsc+bnOKDosmRusUyaxg6CH+u8m+RsdZ +5D9qMbtmtui867o6w6qa/0yYeSkjWLf9GZZyu3ixw8O0kWgtl3+J65G+a5b/jN5G0x51CqdgIe5 dzqLbVKvtKyRDubDQrVB3CDaT9mqzmVr0i3k2CNips/I1e0Q6jhsdRMHsLPxLhqsTv7FEh7dyiAj BlTFyqNdl6tX5+0V6EnbxJPYelwstMx0dK22WjYl7PyMZWo924Sdzj5hBxrh4sk2IqdJsidQwAQo iAKXoDoDoDoDoDoDoDoDoDoE7HW2qy9gsdTirJAydop5IZS2V2PlmDybrBLG1cPoA1gi266j2G99 sWqizT1BExcIkE5PEX29AougOgOgOgqE7aZ2yjstyCR2H80RFbx3m7jjuGd834iqVOVkntdzdjpK gM8t0SwV9zMOkZZDNFKhaXXZoqP8oykmnvFZuiwXY+ikAiS16sDalfd/y7dNhJMMI69bpb4EiFUU XbMcyUezbCMKQtKMVe6a7xeZ1ZpRVjmKJiMCJm9oJgUAuIcKuNnOOONrXNSVdLSFiyVFWXMtjlHD j1K8k/yjbJq0x7pdbxqHO5CtvGCaonMJzKpmMbsYRKAY2+8zglltrxiweUsBo5Svlpz1b08RZIJk OapDzDNgrcXVZ1WYPCRES9RyFGyj9NiqeMeOGjci8ckcTHATkEMDfjk7semOd8Ha90rV+ybGXvYC sTL2ix9WvzeryatvazBYOErasU5pk8kaKkHR/NeSYu0ixzYp1TIKEIYwWTQ26L5ms7R2RJfVO+cd uR2W+nvuBZ0rX2sZXp8zTLjWZ6AlrKreXmZQjD1Wq1utR8emV+4EJBoUVgP6kgJPCNIHu6D79v8A buWzjijKWFpnXPZTW2xQ8BlvEsrZGVwYt21hTkTQNhrdpYsYxvMR780Sv5hU0VEkSHbqJuHCLlFU 1swNCvPLnsHL7TZ/081g0Dns9ZXwVYHCb+WDNleqNTeUeOYNHD+1TDqxVGMa16Vcv5Fu1YRQvnBn oqGMkudQgN1IEdT+bfLmfqpLudTOO7K+Yb/iesubFs7UZ7I0DQo7Cj+Ol7AxXpMZMydaXkslW6UZ 1h0uyZso1tIqJ+wrJVwi4apBLNqLtvjTcPWukbN0cXNdqNpi5ZxNxlmXaNnlKmaw9exVuh5t4ByM /JhJGNWEjvumk4Z+W5ACEUAoBEjK86FkYGY56R0pyO447XmUVMVE24UtzFKScuGs4pAOr2yxcSBX kTVAJUgt0fNdpFXWTOgDkr8h48ly8uokR5C994LQnXuq7EK0E+XazYslUekKR8Nbm9aURg7hGTsw e2RUiaAsjWaMyj4QTIMxK2TeCsX+tIgHiFJbcg0rj7k7srfUDN+7mzWsF41xxFRiwMxiKDl51nPX vMFUtho+MqMijErR8AFef2exTDJugRcvpiIugceeo2IK5mccCw043L3Fz9kpKtZ34+LfrbjmyY7H J1Jyo6ypA3qGVinLiMJDVmysmUBDqxNvlW0oVYGJzpSKBElBWZJpkMoWBGal3LBlk5NOR2vUjX5H HOXKDG4QjMnZgaZHmZtpmBGegHEtHOj42VhYyv0iSjSokTcuW7h6tImTKqoYhxU8wE9sXyiZTrme sqa/aY6eWncax64V6PtOyc/E3yNoleoBJBso+a0qvqvYSZWul7dsElDFZM/G8Fds4btmjxVs7BqD 1tXdx8c7c6sw20WKGzhSHkq9YXcjUJl4i1mK1bqok6JP0ufctEXxGrlo/a9k3JUTlcMlkXaaYprE KNzjghtpvO1sTk3B8ptLj3jRt0zrli924YZ5vpc/VhQ9XeIPUTviUeNdUaJnbsyr1bfsn8g7TjiI NlXJkHHpUUfWqsu51Ep33mmpv+sZL9S/7eP5ta/UZ/MfnL6wv8j+UfxuoKzX7wTDZJ1q5FMIbe02 DZli7RjWvJRsvJMHz6tz1yoL6wQVup9nRTXbFcs5SiTMa3dNkl0DuY50cpRKYDn66fz6pTENcb3g nYd9QMc09MMA5WrmGdt8PVTF1nsU9bcX5bJsZizJULXali66TD0k3R7bAZFvJ3sLXrU4k2ku8UD+ /wD1vpmDnmq4vw02yXtfGtrCSxMXURZKVXbdiqfg5FsqxloKQxNka345Ti5iOXTSdR0mhHVtAyqC xCKpifscAN36DSHJZ+vdw2/9jssfohTetTxoRu2aZFedjitKqmRQoYk2gUAqhSnKCiOJssqpKABg EAOkqQpij8JTAAh7Q6Txo4Mmmf8AeJUzHTIcyPHOKiRjgUxklByaokKiYiAiQ4pKmL3DsPhMIfAI 9Ph6js1Q/bt8qX+0Grf/ABDiPpfGBV8f6KJuUvmlcGSSFwla9M0ElxTKKxEV8YZIOskmqJfGRJY7 ZMTlAexhTKI/FDsvjBjcOUbHx985XCsWLVoCXJ9sdGp+nbpJGJHxs0AR7EDkKBhasQcqeUn38Kfm G8IB4h7y8oGd6MupOr8CG669RQ9K8iIXehGOI0BREYtghBzzZy7ZenVQM3Vh4nzFkTFN2TMiUexg Dwjfn6hEa/aP8ge2HF7iHCEHs5rRAaw5TxJTnEdTHWG59zcIeOb2NjdkmkhaUXpwXsLG3xnmuXKZ AAzgpxIBQEO0ly6HCc2+PXOP+L/VvFNkftrM8pOa9WcfT8n5axmdgc1qhWatyj7yngncGbSyrJRT wqiJxKp2N3Hv0nOdxMDutqjVd0NXco6z2SVXqjC+Q0cSDsccyRdq1OzVmYjbLUJkkcc7cj2Pj56G bg7aEVbmdsBWbkWRFQFSJbLsEevH5t9sXQc6Bxlb5VmObZ8o+OSWTC+bq68Vc1jYbGNcTMxSkTlc N26qloZxkauqd4QqYvAYPE3bdq9aHM8gTmhX7YTmE/8AM36DO+g54TCpyFk5QrTIB59sm+RbNLWd kliFK8dNI10LuMQX7GL4UWjyZfCmmBCFTFUwF9nsLr3eQSvD2gzhcWcp9PgVzjT6pvZtBH1RkCBm bZnFpwMaybi2YGVcCwIuxjW/dHzDgTwAHcR7iNvOeg0tx9ooh+7iZ7EEkwFXXXfdVUQTL3UWTiMs kTWUHsPjVIRAgAYe4gBCgHwB1m873EAvvB/+XPP2PHu/5St8g/Ifj/I/6L4n4Ot/si8lyEak1bdb U/K+DZ+Parzz+Ae2HGUyq2TXeVbKNeZuntMm2CggCzcFZABYvQSMmdzGPHLfxAVY3XNXl1pqKIqE VSOdJVI5VElUzGIomoQwGIchyiBiHIYAEBAe4D16Eem5xS3iSyhx/wCt2TbAyTb2+9053NXiRKmZ Nzbbk0n5avWC+y34pSr2C+PYQZeQXAoeqevFVh7mUMYfOr4+52sOVM37ScdmWKI0hHFQ1rzFfbpk 9aTmUY5+0g7DX67GxykKxUTOeXcmcxqoHTIJRIAAP8PQJ7PGqGXsg8o+i+11cZwKuIcBY+zjXMhv Hc4g1nm0nfcf3+uV4kVBmSMvKIqSVibAqcpigkQTGHv4egPsn5e+95+2V6OB+hP7Hn0Leu99ofOL 58fPf396f3B5XqPdvoPb6jx+Hxfi9urvDAYH1Qy9j7lH3o2usbOBSxDn3H2Dq5jx40nEHU85k6Fj +gVywklYMqRV4tFOSrrkEjmMYFSAUwdvF1AoNT9YcqYg3g5Jc8XNpCoY/wBnbDrfJYrcR8yi/lXb bGVHu0BaRm4xNMqsMZKRnG4IAcxvOIJjB28PQHHtrDlTXG175y+S2cI1ZbB7yZqz3jk0PMoyyjnH 15kknMC5lk0k0zRcqokQfNam8Rkx9gj0Cb429NLrgbS2662bGwsC4Xvd+zk4sMLCTZJmMkqJlF65 Q9IpItCoeWs/hXihFSF7HSE3w9+gZJg7AXMponTHeo+tkLqznDBcLZ7G4wnm/MVinISZx5TrNMvp xaGulQgpOIl5J41k5Rd0mVm3lE27hVUpVF2vkNkb14h7PLTqjmTcbWeg4yw9H11zcoLP2L8jy7Wb sKcPGI1+rsrOlNi1knbRP1a6K0skCRBSTOqXuPYvYQ6S2XYHhbUqbPo4Vsi+nrfFzzOzd9AOq20z CrLpUp5GNJpk5skc49zCk5PIScIis2beNdqkVRbxiukJSmCCNrWfWDd7MO79U3t3sg8R4lkcQ4dm cU4hw1iKfd2dQJC0GfpWa122aUdzMf6ZdrNPgbt0X7g/dVuAgn6Y53Thg3Tqvqfl7EvIVyF7H3Bn BI4z2P8AoW+jJ0wnEH0y6+Y1YcRU974iSIlVifLdqACXjMbzC+0OrtzOgaveNWORDULanZ7L3HxW cLZSxbuc+a3S203KdmGsvcO5tOEgaWyKggovEtbDASMpNvZBdBqss6ei4BBZAPSIrOJ35B7GhWks rpvpw+whL2Rldst3p1kDImW7izOsSLs+WsiMytpN2ycPGrR8uwYR7CPjyOXKRFnJGfnmTS8zyUwb bqbo3nrD/DrlLSy5x9Yb5xtmHdq6XEMI+yNn9bPOZdY5AQpya9hTRI3QbLKWNt6hQSCCACbv38PV t26ImfuWt4f8Cxv+z6+zn9YUf9Zf5L8k/M/9r+J+Dq/l99FqbY5TJKeAcz/Q5FRs1lZXGV1bY8j5 mXjoGIUt7yvv2sEvJy8udOLZsGL9Yi6ouDppGIkJTHIBvGGRQC1x4rqHd7bFK7H8hOgOEcdorpK2 AkBtvg/IORnzUqoioxr0dC2xentXDlJMSi7dyYlaioQ4NnPY6Qb33/U4PQE19ruIahhDFNUwDI16 XwtWqLXYHGcrU59ja6/J1GIj0WEVIR9njXT5nYgeooeYo9IsqLpYx1DHMYwj1gbi6A6A6A6A6A6A 6A6A6A6A6A6A6A6A6A6D/9k= --_004_DM6PR16MB3912056A15FA1D29A8C4E4F8DE5B9DM6PR16MB3912namp_-- From nobody Mon May 3 12:03:29 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC193A07F6 for ; Mon, 3 May 2021 12:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIvpwlxkNFyk for ; Mon, 3 May 2021 12:03:22 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FFB3A08DA for ; Mon, 3 May 2021 12:02:31 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id e15so4888628pfv.10 for ; Mon, 03 May 2021 12:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Q0+XEpgilZHUIn+da8m/N3M6YOr6n6KMaFPV4hgObO8=; b=Y8BNftOd2SsrT3E/bA/bypIM2Tp4AuLjm8m+FwDwXdH2WjSWV3U+nG6a73FclTlc1+ VOZ4Ua9T8JYt6HN8iqEYRzk5krubZ1IWEArHU/LPtvWdYnzDHKv5N2GFvRd5kLEFNPhr BqRrXwogar4FVPOutY//fTSyN4HMgTTp4MKA1oODPoN6kwOEH5D3snkScmhimB4aTg51 OJg8jyCrzK9SwPF4svUjZbMl9zUvVSax0vFu8PIIkv6GR8xLYl74tQ3Y5yUwJnpGvtxE Cod/sxVq5GIxRFqNzB9LgerXLTsILZSr8XigT9Iko5w2n656YJLuZzunsCx+ehUAPxlf Uerg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Q0+XEpgilZHUIn+da8m/N3M6YOr6n6KMaFPV4hgObO8=; b=kDLTBIhpFX4D72Gn9Z6YCGCjUGOBr+a9807Z2CjNRBBYe+TbmgvjydeMDYNATOqq9l C3yhZSBdAQCIBM9O4kZEAug+rXCwOULM2sz4h9Aot6GmTsax4zvC1jjBNf6y8vmEstIe nMzIc1p3VlZJO4JE3xC4CPXfbPLJCcD9baCaQ3fOn1tDennPQW6mknt9WsTk3OOv2kgH clkMI8NXyIicfvNpnBUoC8buWt9qF2+cjWkKb37TvZ/O2/riNoLhALSInZA1MbpNCLbe 5f7+3B3bJJMbIybRO6vCEcWvnUGWThFh2bGYUuXROGl8OClAEcMbsO+vag5xmoPG+9P1 M6nQ== X-Gm-Message-State: AOAM533JAtoJl5cMgr88BiU97Jyobh6BZgKlDK5zNHU+dH/DaSmr3N59 aTcsBvI0P00I/9x3CaMu90hZEKwfvLA= X-Google-Smtp-Source: ABdhPJxglf1fAFC0WpKeZMabL4N1MEtIK5SzUvS/N7o3t+IV5qUgh/UzC8kbDA8TT4+2EMDmlHEHfA== X-Received: by 2002:a62:dd50:0:b029:27a:69c8:55b6 with SMTP id w77-20020a62dd500000b029027a69c855b6mr20030721pff.6.1620068550146; Mon, 03 May 2021 12:02:30 -0700 (PDT) Received: from smtpclient.apple ([2605:a601:a9b4:1200:297c:653c:c535:251]) by smtp.gmail.com with ESMTPSA id a65sm9818471pfb.116.2021.05.03.12.02.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 May 2021 12:02:28 -0700 (PDT) From: Bret Jordan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Mon, 3 May 2021 13:02:27 -0600 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> To: DISPATCH In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: [dispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 19:03:28 -0000 Dear Dispatch, Over the past week we have identified 3 additional individuals that have = expressed public support for this ID. There were two others that either = asked questions or discussed this relative to CBOR. It is important to = note that we have yet to see any examples of why this would or could not = work. We would respectfully ask for a direction from the Chair on how to = move forward: 1) Move forward with ISE for publication 2) Form a short-term WG to work on this 3) Form a longer-term WG to work on this and other JSON related digital = signature issues. 4) Assign this work to another WG to be worked on. Please advise.=20 Thanks Bret =20= From nobody Mon May 3 13:23:07 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3B3A0E1E for ; Mon, 3 May 2021 13:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=garr.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9mgkI84Z5sM for ; Mon, 3 May 2021 13:23:01 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393853A0E1B for ; Mon, 3 May 2021 13:23:00 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (unknown [10.2.2.13]) by smtp-1.dir.garr.it (Postfix) with ESMTPSA id 2BFD6A0A9C for ; Mon, 3 May 2021 22:22:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=202004; t=1620073376; bh=Mex6MbYjTEpu0f9X+1Kwpxs7VFN40Zk/O08AEYMPYUQ=; h=Date:From:To:Subject:From; b=SXXGhLO95dPEgcoUAbxIb/vFBH37NPMN4zlYg0e+NqUswl1wPek+US/DoZxTEz/zQ g4TNUaqyiLxSugq7TuKya1u9v00IEz3qpT8RIeJLqAahgkSHMjjsxy19H2DpDqFzl5 m9uwOqmpRu2T3YRXtb2OQSLJNjmNT421x95sO4+W+ZeCdtIDP6RNxLsN6cCdPSSBdW oRq2y2PQacfkUAAMLTgqgE4zR1l7LYTn2xoMx3ymxHiqNX0CG/zuyFw3HdgA6q7w2a OgbAdHj3NFKbkEdHZON46pUasuWjEcWxEECPkVt15cZy5nreYavZYKDD66D3B1lnO9 sdGBDTNuTtl1w== Date: Mon, 3 May 2021 22:22:50 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Dispatch WG Message-ID: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-365412606-1620070366=:824" Content-ID: Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? (fwd) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 20:23:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-365412606-1620070366=:824 Content-Type: text/plain; CHARSET=utf-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: >> Setting aside the implications (inadvertent or otherwise) of Claudio’s >> comment that Apple or Google need to be on the authors list for IETF to even >> consider an ID (or work on it expeditiously), you totally misread what I stated, sorry. I said that at least those companies who are implementing the "new stuff" should be involved into the discussion of the specificaions, oitherwise the specification will be just ignored or result inaccurate compared to reality. And Apple and Google are just 2 examples. The way you read my sentence it totaly against what IETF is how it works etc. When I (and Ned and John, and many of the people who made suggestions in tis thread) started in the IETF, Apple, Google, and 80% of current companies weer "just not yet stablished", so please do not misread examples. :-) Specifications are done and are successful when all people who need them work to write them, and when people who will implement them work on them, too. apart frm this, +1 to Ned's last email. > > I could even begin to count the number of times I've been told that this or > that > is critical because of the actions of some other standards group, and for > that > reason the IETF needs to engage post haste. IME a common result of such pleas > is > to slow the work down, as people begin to argue about how the IETF should > handle > its interactions with other standards bodies, rather than focusing on the > technical issues at hand. yes! > > Ned > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys --0-365412606-1620070366=:824-- From nobody Mon May 3 17:13:14 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A743A1A4F; Mon, 3 May 2021 17:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYj2oFln7Vhj; Mon, 3 May 2021 17:13:06 -0700 (PDT) Received: from outbound-ip12a.ess.barracuda.com (outbound-ip12a.ess.barracuda.com [209.222.82.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011AB3A1A4A; Mon, 3 May 2021 17:12:53 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2168.outbound.protection.outlook.com [104.47.59.168]) by mx-outbound14-103.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 04 May 2021 00:12:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A3gw+NUQFDSMiQ/90twrQXgje38VdriId7nknSzdruGYZgpNQOrbMuTDn8K+NuMG0ZjSBVT7PRoR5Ee9KHlBNXS33+dFlJNegNylSwa87shjVdH8xveMYz7luZioEpqvlpXnj2tL/xj/MrBD4H+H7W/6P32fNpGgmFzs/1W78J9Kn+04UdwFcCbPNZ/yunBxgIo/EIy+p8pvsdHTVpdCoOZPB7GD9bhEGuyovJK6hqgahIefPMBc101/GnvaEBHhtg0GrUs0hHrXX9RPzcUi5kjjy96uzrindRAtSERzGQGo8G1vsk+9lHYl6HKuyI10RHgoSyJDoA0/zteR5nL+xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QNqCAFENhOud9jgz+muivszgApOvJG78A/uars+Etys=; b=aw0Do1C8emZyB1wvxbxk7xXhtM6aLjEjGCRY5KKTJcWSICSQVHLWeG50R0eV9XouaPm3UyP1XUMZAl2InnLEOsIb1Hs5avc+nVS0mh34OKtCYaE92Kvff/jVQUId/cKI4drHWoUQcjrPqs8ZtxILoMOVa4EGyzZ5C4QEhhYjmglKEB9/syeVJo+PCkduX6GmoOD9iMuqoct7jxmcq2+CPZJnXrmHNwO16qGg+54Cb28vj4nkS55MWAv8HvsdWUrqgyzzFonYs7jh104EoOtDFaLOE83EqP/uBdPKx4KeIor6w9l6pOdCHgCYU4NKF+IN/kgMpGqPXYHCVARnO1jQSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QNqCAFENhOud9jgz+muivszgApOvJG78A/uars+Etys=; b=Zd4i5r+3J1+FdCp4+KwO5Axo83ZMOrHov3KIa4Bbh2IDPDXOMTwFbSg8KCRvMCxOUXgGx8rHooeMYPLWBn36bY52g8PmYIa7z3TuWvGVwlCncbuaZ24TvknzOMa+UMWsFPiNsVq93Ct56If5Rr92XsGQjDT5aWa+xU9qpRYLi/w= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM5PR16MB1642.namprd16.prod.outlook.com (2603:10b6:4:1b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.35; Tue, 4 May 2021 00:12:41 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681%6]) with mapi id 15.20.4087.044; Tue, 4 May 2021 00:12:41 +0000 From: Yeshwant Muthusamy To: Ned Freed CC: Ted Hardie , Dispatch WG , "dispatch-chairs@ietf.org" , Applications and Real-Time Area Discussion , ART ADs , Claudio Allocchio , Francesca Palombini , "draft-muthusamy-dispatch-haptics@ietf.org" Thread-Topic: [dispatch] [art] Status of Haptics I-D in DISPATCH? Thread-Index: AQHXQAiXhkWIzY99rEKfQgzWZ5WHhKrRyR2AgAAN5gCAAAmtFIAAEj6AgAADbRCAACiyU4AAUK0w Date: Tue, 4 May 2021 00:12:41 +0000 Message-ID: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <01RYLJ4MK6040085YQ@mauve.mrochek.com> In-Reply-To: <01RYLJ4MK6040085YQ@mauve.mrochek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mrochek.com; dkim=none (message not signed) header.d=none;mrochek.com; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.43.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b20e434c-b102-45a4-aa5e-08d90e915556 x-ms-traffictypediagnostic: DM5PR16MB1642: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yO6Tg62RLWXPig6z4dneVPlHcC5/zkv5dYW7h4Yi7jw2h1IsHFXYJmby3gAGhWNIT3yDbpLOukQSc8gZzE05JRC2VYdbMMgDEV83WBy+TPUTJJX5loQfmAMCfs5IMH5KgYA3mReigSxJ2oaXT103o33eLG+Vf3PJuvbhGVFjS9sJHJkUgNABakqXMGIOTqhglod4zLZqZNElPkoj2+hGzpvzdNEs8E4Xl6R08zcG0U6tlnoPwbIEBbqBW6Z0dIu9i1w8CFHOIx/tZi2kH9reOqFINgCi8qj/lXqHiu6rEFncriHipOW3Ud2aoYiy3Fjm+dShM8D2CwaqEBLS3YJEUZSXKbcM8grZRiEuUyDv5+Gxyc0e0e7KczVi6ut1duCG2No3gmtYD5Ky+aBZkqPFzGDMEQvm4CcAtw/thNdWMj9fEla/YS+sQeCpJJsLhHKlpMiXixp1bOnOVdjF4arQrIDPX3Zpp/PD0xlMe1YBpWuPIpbQ+j6f+HLP/Q42p1tYjXpgnQASMutZwdtFJ/EQ0zEO5N3HPR5j52nGKlpDhn9xglU+iXlguYoD8Cg0MXsPvbmEkKm2iWxDx/ZfOvZGjgxN8jxGmpaFwPO8sZAgvxXUJymiiOH+CCK2vXXnIgEC6OLZ2ahrX/UJ+HqhaU0FKr3GpUzzd+vlus+UgkqJzMm5OOGCgJuzFcd4OCwb0hgr x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(396003)(376002)(136003)(346002)(366004)(8676002)(478600001)(5660300002)(76116006)(38100700002)(966005)(45080400002)(316002)(7696005)(4326008)(83380400001)(8936002)(52536014)(9686003)(55016002)(71200400001)(26005)(122000001)(86362001)(33656002)(64756008)(66476007)(54906003)(6506007)(186003)(66946007)(66556008)(66446008)(2906002)(53546011)(166002)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?RmV4UVFyRWxvbFk0eXVvOTBOd01hQXFXVkNyM2czYWRic29nWDRXTkZWbjFL?= =?utf-8?B?am15OXJJbDhJYkFuRkJRM1RUTGlsc1ZZWDYrTnQ4bHhSeSt4NEx4eFRtLzZT?= =?utf-8?B?b0FVdno4ZU1PUFByK0RBdGhVQk9yaUs3WFpzYmVHMGJJREtONVZ6TEdxZFB0?= =?utf-8?B?VW11OEpTZC9iVjhOM0F4SUFYMEIzcUZ4eGpvNTY5VEluekVqMHJtZUVYZ0FW?= =?utf-8?B?YVNSSnZvalZ3VDJCNEU5ZktQMXovbVV4b1FsQ0tRVGxzWmo1cFowUE5ITStn?= =?utf-8?B?bW9iZEFTL0taa2Vvbmo0bG1lc3d6LzR6bjRXeDhSQUN5c0tleHJKeExKaWdm?= =?utf-8?B?TDZHWEFPMGlMcXhYSVNhMlgwRHB1bzREREZUaTRFeW94Z1hqQVVUZjg4Ynds?= =?utf-8?B?cWdaV2cvZk9nU1czVHd2MmJhanZkcEE3RzNCcnIvcnhDemdmY2FXdHc2Nlhv?= =?utf-8?B?TFZUbXRhZVZYdGx0OXB2TXV5TnFuSmtEc3lLSHdkYnVhWnBSeUFCUzg2YW9o?= =?utf-8?B?c3dac0xaN1lObVdrSGQ3OVhnUVJ2RXpVcjF5bVN4L1RSS0lKSzQva25CVjZU?= =?utf-8?B?M1U4dThjVUQvd0k3cGE5MlNreDJjRzA3THpoZDRRS3NIVVI3c3VPYm02U0JT?= =?utf-8?B?akhadXRNdjhVOW1ZWTRYSmtsVVVUanNoaG03cGlVcWh2K1dmV2JjdzVSYTVx?= =?utf-8?B?Z0VnaUhVZWxXZEtiSVF2ZzNxTnFsdTg2WEs2bjlrQ0NEaTJTTVZtb205NnJT?= =?utf-8?B?dWZKU3FEbCtTZDFXbFY4QTZOK3EzYmJKTlBPNUp1SEs1TmR2dXV2cVYxa2Zp?= =?utf-8?B?VjcyTFRaemJjaTFnc2lXVDV4U2RnZW9oMWE2alNMZXZKa2VTV1BNVy9WdGRJ?= =?utf-8?B?Rnl2cTI0S3N2MXpvemZnakI0VFMvd3BDdFpjbE1ZQmxOU24wK3ZnbFVoOTJr?= =?utf-8?B?eCtHaEZBamNVYS9hMXBjMWN0cVkzV1VNdE0vNEdQSC93d3hMdS8rMHpmcE5p?= =?utf-8?B?QllBVURFR05kTjNjQzEwcXF3VjdDck5kWXVDL1grZEdRQzluL2NmOFErWmR3?= =?utf-8?B?dHhBYlJVTUVhNkhQeWFabnExNFRFT0RXRmdYbmVjaFFtY2kzbWpKTExXQWQx?= =?utf-8?B?M1lPUFRJNFpERGVSUzNESzVUUG1acWwwQWRNZXRLMStqelVrcElodlRRckNx?= =?utf-8?B?QjU5TXZvVXZqVnRjNVJaRS9DZ3BMekIvOHhIelpRQzNsWXBRY3dXbU5zNUt6?= =?utf-8?B?UFNLVnZaMFhpTmdtbFdXWStmWEZIT2JwbjhENG9ITjJyV0l5UkJlM0V2Njdo?= =?utf-8?B?UEJ6bW8zL0xsL2QvN3dhRWJJY1ZIMXFMVjB4aVRBbldEUkNkUGpMRVFTQVNq?= =?utf-8?B?ejRhZ1Nld3JhZ20wQTVXUkYxbzAwSE9qQ0RLTSsvQ0tsWlY2bFJ0MGhLOVlK?= =?utf-8?B?d1l2REZvSHVWVlRHems0TnM0R2dpTEQzb2h2bTNaQ29rRXhGa2pvOWhNdDJn?= =?utf-8?B?ZnNpNnVDd3plN3RyNGdKUEhEeDI0a3JCbFJKZzhyRUF3WTBjaVBLWEUzR1Q5?= =?utf-8?B?bWhndlJEZEtVeFZOeklpdG5Cb0RKeFQ3SVEzZlRickNzTVhQSktkcnUxZkxu?= =?utf-8?B?eVVXY3lsTW1CMWMxblo2Smp1MzB1VWFIMEV0b0FWRDBPenJQVUt3dFRWWXNv?= =?utf-8?B?M3JNeUNHM3Vsdk1pTFV2UnhYaE5FS2pWclJxZklvenJ4MTFKL2k4RUR2c0Yv?= =?utf-8?Q?K+uIl2UvDWn02paD/4=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR16MB3912BF4649F7CF487C66CC28DE5A9DM6PR16MB3912namp_" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b20e434c-b102-45a4-aa5e-08d90e915556 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2021 00:12:41.2782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K191ORkbrmyHDPXk8h/usZe1Crzf6zxP9TLHgW53dSk+jjbGiwJicdIR0ZOUrhaFZBo6Zz0N4iUkwXNdUKIRd+u2oxnbNMQ5hH2EKdRvieU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1642 X-BESS-ID: 1620087162-103687-23909-7924-1 X-BESS-VER: 2019.1_20210503.2312 X-BESS-Apparent-Source-IP: 104.47.59.168 X-BESS-Outbound-Spam-Score: 0.50 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.231989 [from cloudscan20-189.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.50 BSF_RULE7568M META: Custom Rule 7568M 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.00 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname X-BESS-Outbound-Spam-Status: SCORE=0.50 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_RULE7568M, BSF_BESS_OUTBOUND, HTTP_ESCAPED_HOST X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 00:13:12 -0000 --_000_DM6PR16MB3912BF4649F7CF487C66CC28DE5A9DM6PR16MB3912namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmVkLA0KDQoNCg0KVGhhbmtzIGZvciB0aGUgbm90ZS4gTXkgY29tbWVudHMgaW5saW5lIGJlbG93 LCBwcmVmYWNlZCBieSDigJhbWUtNXeKAmS4NCg0KDQoNClJlZ2FyZHMsDQoNClllc2h3YW50DQoN Cg0KDQpZZXNod2FudCBNdXRodXNhbXksIFBoLkQuIHwgU2VuaW9yIERpcmVjdG9yLCBTdGFuZGFy ZHMNCg0KDQoNCnltdXRodXNhbXlAaW1tZXJzaW9uLmNvbSB8ICsxIDQ2OS01ODMtMjE3MQ0KDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5lZCBGcmVlZCA8bmVkLmZyZWVk QG1yb2NoZWsuY29tPg0KU2VudDogTW9uZGF5LCBNYXkgMywgMjAyMSAxOjMwIFBNDQpUbzogWWVz aHdhbnQgTXV0aHVzYW15IDx5bXV0aHVzYW15QGltbWVyc2lvbi5jb20+DQpDYzogVGVkIEhhcmRp ZSA8dGVkLmlldGZAZ21haWwuY29tPjsgTmVkIEZyZWVkIDxuZWQuZnJlZWRAbXJvY2hlay5jb20+ OyBEaXNwYXRjaCBXRyA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBkaXNwYXRjaC1jaGFpcnNAaWV0Zi5v cmc7IEFwcGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlzY3Vzc2lvbiA8YXJ0QGlldGYu b3JnPjsgQVJUIEFEcyA8YXJ0LWFkc0BpZXRmLm9yZz47IENsYXVkaW8gQWxsb2NjaGlvIDxDbGF1 ZGlvLkFsbG9jY2hpb0BnYXJyLml0PjsgRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBh bG9tYmluaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz47IGRyYWZ0LW11dGh1c2FteS1k aXNwYXRjaC1oYXB0aWNzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBbYXJ0XSBT dGF0dXMgb2YgSGFwdGljcyBJLUQgaW4gRElTUEFUQ0g/DQoNCg0KDQo+IEZvbGtzLA0KDQoNCg0K PiBGaXJzdCBvZmYsIGdsYWQgdG8gc2VlIHNvbWUgdHJhZmZpYyBvbiB0aGUgaGFwdGljcyBJLUQu IFRoYW5rcyB0bw0KDQo+IEZyYW5jZXNjYSBmb3IganVtcC1zdGFydGluZyB0aGUgbGF0ZXN0IHJv dW5kIG9mIGRpc2N1c3Npb24uDQoNCg0KDQo+IEF0IHRoZSByaXNrIG9mIHNvdW5kaW5nIGJpYXNl ZCAoYXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBJLUQpLCBJDQoNCj4gd291bGQgc2Vjb25k IFRlZOKAmXMgbGF0ZXN0IHByb3Bvc2FsIHRoYXQgd2Ugbm90IG92ZXJsb2FkIHRoZSBXRyB3aXRo DQoNCj4gb3RoZXIgbWVkaWEgdHlwZS1yZWxhdGVkIHdvcmssIGxlc3QgaXQgZW5kIHVwIGRlLXBy aW9yaXRpemluZyBvcg0KDQo+IGRlbGF5aW5nIGNvbnNpZGVyYXRpb24gb2YgdGhlIGhhcHRpY3Mg cHJvcG9zYWwuDQoNCg0KDQpUaGlzIHNvcnQgb2YgdGhpbmcgaXMgd2hhdCBXRyBjaGFydGVycyBh cmUgKmZvciouIElmIHRoZSBoYXB0aWNzIHdvcmsgbmVlZHMgdG8gY29tZSBmaXJzdCwgc2F5IHRo YXQgaW4gdGhlIGNoYXJ0ZXIuIElmIGFueXRoaW5nIHRoaXMgaW5jcmVhc2VzIHRoZSBsaWtsaWhv b2Qgb2YgeW91ciBwcm9wb3NhbCBnZXR0aW5nIHNvbWUgYXR0ZW50aW9uLCBiZWNhdXNlIHBlb3Bs ZSBpbnRlcmVzdGVkIGluIHRoZSBvdGhlciB3b3JrIGl0ZW1zIHdpbGwgYmUgaW5jZW50aXZpemVk IHRvIGhlbHAgd2l0aCB0aGUgaGFwdGljcyB3b3JrLCBpbiBvcmRlciB0byBnZXQgdG8gdGhlaXIg aXRlbXMuDQoNCg0KDQpBRHMgaGF2ZSBhIHZhc3QgYXJyYXkgb2YgdGhpbmdzIGNvbXBldGluZyBm b3IgdGhlaXIgYXR0ZW50aW9uLiBXRyBjaGFpcnMsIG5vdCBzbyBtdWNoLiBBcyBzdWNoLCBsZWF2 aW5nIHlvdXIgcHJvcG9zYWwgYXMgYW4gQUQtc3BvbnNvcmVkIGl0ZW0gaXMgZmFyIGxlc3MgbGlr ZWx5IHRvIHByb2R1Y2UgdGltZWx5IHJlc3VsdHMgdGhhbiBkb2luZyBpdCBpbiBhIFdHLg0KDQpb W1lLTV1dIFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uLiBJIHdhcyBub3QgYXdhcmUgb2YgdGhl IGNoYXJ0ZXIgYXNwZWN0LiBJIHdhcyBhZ3JlZWluZyB3aXRoIFRlZOKAmXMgY29tbWVudCB0aGF0 IGEgaGFwdGljcy1zcGVjaWZpYyBXRyB3b3VsZCBiZSBtb3JlIGV4cGVkaWVudC4gSnVzdCBmb3Ig dGhlIHJlY29yZCwgYXQgdGhpcyBwb2ludCwgSSBhbSBjb21wbGV0ZWx5IE9LIHdpdGggKkFOWSog b2YgdGhlIHRocmVlIG1ldGhvZHMgb2YgcHJvZ3Jlc3MgYmVpbmcgcHV0IGZvcndhcmQgYnkgdmFy aW91cyBjb21tZW50ZXJzOg0KDQogIDEuICBhIGhhcHRpY3Mtc3BlY2lmaWMgZm9jdXNlZCBXRywN CiAgMi4gIGEgbWVkaWEtdHlwZXMgV0csIGFsb25nIHRoZSBsaW5lcyB5b3UgaGF2ZSBzdWdnZXN0 ZWQsIHdpdGggYSBjaGFydGVyIHRoYXQgcHJpb3JpdGl6ZXMgdGhlIGhhcHRpY3MgSUQsIG9yDQog IDMuICBBRCBzcG9uc29yc2hpcC4NCg0KSSB3aWxsIGRlZmVyIHRvIHRoZSBwcm9jZXNzIGV4cGVy dHMgb24gdGhpcyBsaXN0IG9uIHRoZSBiZXN0IHdheSBmb3J3YXJkLg0KDQoNCg0KPiBJIGFwcHJl Y2lhdGUgdGhlIGltcG9ydGFuY2Ugb2YgTmVk4oCZcyBsaXN0LCBidXQgVGVkIGlzIGNvcnJlY3Qg aW4gdGhhdA0KDQo+IHRoZSB0aW1lIHRvIGdldCB0aGUgaGFwdGljcyBwcm9wb3NhbCByZXZpZXdl ZCAoYW5kIGhvcGVmdWxseSwgYXBwcm92ZWQpIGlzIG5vdCB1bmJvdW5kZWQuDQoNCj4gTW9yZSBv biB0aGF0IGJlbG93Lg0KDQoNCg0KQXMgSSBzYWlkIGJlZm9yZSwgbm90IG9ubHkgYXJlIHlvdSB0 YWxraW5nIGFib3V0IGEgbmV3IHRvcC1sZXZlbCB0eXBlLCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQg b25lIHRoYXQgaGFzIHRoZSBwb3RlbnRpYWwgdG8gaW50ZXJhY3Qgd2l0aCBzcGVjaWZpYyBwcm90 b2NvbHMsIGUuZy4sIG9uZSB0aGF0IGhhdmUgc3BlY2lmaWMgc2xvdHMgZm9yIGF1ZGlvIGFuZCB2 aWRlbyB0eXBlcyB3aGVyZSB0aGUgdG9wLWxldmVsIHZhbHVlIGlzIGFzc3VtZWQsIGluIGNvbXBs aWNhdGVkIHdheXMuIEFzIHN1Y2gsIHlvdSBhcmUgZ29pbmcgdG8gbmVlZCBpbnZvbHZtZW50IGZy b20gYSBtdWNoIHdpZGVyIHJhbmdlIG9mIHBlb3BsZSB0aGFuIHlvdSB3b3VsZCBmb3IgbW9zdCBv ZiB0aGUgb3RoZXIgaXRlbXMgb24gdGhpcyBsaXN0Lg0KDQpbW1lLTV1dIEFncmVlZC4gQW4gUkZD IHRoYXQgaXMgdGhlIHJlc3VsdCBvZiBhIGRldGFpbGVkIHJldmlldyBhbmQgcm9idXN0IGRpc2N1 c3Npb24gb2YgYWxsIGl0cyBpbXBsaWNhdGlvbnMgaXMgcHJlZmVycmVkLCBmb3Igb2J2aW91cyBy ZWFzb25zLg0KDQoNCg0KPiBTZXR0aW5nIGFzaWRlIHRoZSBpbXBsaWNhdGlvbnMgKGluYWR2ZXJ0 ZW50IG9yIG90aGVyd2lzZSkgb2YgQ2xhdWRpb+KAmXMNCg0KPiBjb21tZW50IHRoYXQgQXBwbGUg b3IgR29vZ2xlIG5lZWQgdG8gYmUgb24gdGhlIGF1dGhvcnMgbGlzdCBmb3IgSUVURg0KDQo+IHRv IGV2ZW4gY29uc2lkZXIgYW4gSUQgIChvciB3b3JrIG9uIGl0IGV4cGVkaXRpb3VzbHkpLCAgSSB3 b3VsZCBwb2ludA0KDQo+IHRvIHRoZSBmb2xsb3dpbmcgRHJhZnQgQW1lbmRtZW50IG9mIHRoZSBJ U08vSUVDIDE0NDk2LTEyIChJU08gQmFzZSBNZWRpYSBGaWxlIEZvcm1hdCkgc3RhbmRhcmQuDQoN Cj4gSXQgaXMgdGhlIG9uZSB0aGF0IGhhcyBvdXIgcHJvcG9zYWwgdG8gdHJlYXQgaGFwdGljcyBh cyBhIHRvcC1sZXZlbA0KDQo+IG1lZGlhIHR5cGUsIGFraW4gdG8gYXVkaW8gYW5kIHZpZGVvLCBp biBJU09CTUZGIGZpbGVzIChsaWtlIC5tcDQsIC4zZ3BwLCBldGMuKS4NCg0KDQoNCj4gaHR0cHM6 Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGbGluaw0KDQo+IHByb3RlY3QuY3VkYXN2Yy5jb20lMkZ1cmwlM0ZhJTNEaHR0cHMlMjUzYSUy NTJmJTI1MmZ3d3cuaXNvLm9yZyUyNTJmc3QNCg0KPiBhbmRhcmQlMjUyZjgxNjA0Lmh0bWwlMjZj JTNERSUyQzElMkMtdms0ckJ0eE1vSzR1cjFvZWt0OE9iaDAweEJnOEpKeXJ0DQoNCj4gcjYxU2F4 aEhVWFJKS05PRkVGdGN2TzlKSzNqeHMwbnRWZGJaaGZxZEtodU1pSEFHVktIVHVTRmVhZXlqV1Z2 T2JRdjlObA0KDQo+IG45aFFoemxtZVJrRzBBJTJDJTJDJTI2dHlwbyUzRDEmYW1wO2RhdGE9MDQl N0MwMSU3QyU3QzQ1YTkzMWRlYzY2NDQ5YWYNCg0KPiAxMWVjMDhkOTBlNjZiMDJjJTdDNGYwNWU0 MWE1OWI4NDEzYWFlMTlkNWRmM2RmZDBmYjUlN0MwJTdDMCU3QzYzNzU1NjY1DQoNCj4gNjQ4MTUz MDI5MCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9p VjJsdU16SQ0KDQo+IGlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtz ZGF0YT1EJTJGVDA4bkp4JTJCd1htJTJGTmMNCg0KPiBtSWFxblRlVmZnN2E4UGJ1S3N1c1Zjb2J4 cFBrJTNEJmFtcDtyZXNlcnZlZD0wDQoNCg0KDQo+IEZvciB0aG9zZSBmYW1pbGlhciB3aXRoIGhv dyBNUEVHIHdvcmtzLCBhIERBTUQgbWVhbnMgdGhhdCB0aGUgcHJvcG9zYWwNCg0KPiBoYXMgZ29u ZSB0aHJvdWdoIHR3byByb3VuZHMgb2YgYmFsbG90aW5nIGZyb20gdmFyaW91cyBJU08gTmF0aW9u YWwNCg0KPiBCb2RpZXMgKGluY2x1ZGluZyB0aGUgVVMgTmF0aW9uYWwgQm9keSkuIEFuZCB5ZXMs IEFwcGxlIGFuZCBHb29nbGUgYXJlDQoNCj4gaW5kZWVkIHBhcnQgb2YgdGhlIFVTIE5hdGlvbmFs IEJvZHkg8J+Yii4gV2UgYXJlIGhhcHB5IHRvIHJlcG9ydCB0aGF0IG5vDQoNCj4gb2JqZWN0aW9u cyB3ZXJlIHJlY2VpdmVkIHRvIHRoZSBoYXB0aWNzIHByb3Bvc2FsIGluIGVpdGhlciB0aGUgQ0Qg b3INCg0KPiBEQU1EIGJhbGxvdCByb3VuZHMgZnJvbSBhbnkgb2YgdGhlIDIwKyBOYXRpb25hbCBC b2RpZXMgdGhhdCB2b3RlZCBvbg0KDQo+IGl0LiBJdCBoYXMgbm93IG1vdmVkIHRvIEZESVMgYmFs bG90ICh0aGUgaGFwdGljcyBwcm9wb3NhbCBoYXZpbmcgYmVlbg0KDQo+IG1lcmdlZCB3aXRoIG90 aGVyIHVwZGF0ZXMgdG8gMTQ0OTYtMTIgZm9yIGEgbmV3IDd0aA0KDQo+IGVkaXRpb24pIHRoYXQg aXMgZXhwZWN0ZWQgdG8gY29tcGxldGUgYnkgSnVseS4NCg0KDQoNCj4gTVBFRyBoYXMgYWxzbyBp c3N1ZWQgYSBDYWxsIGZvciBQcm9wb3NhbHMgb24gdGhlIENvZGVkIFJlcHJlc2VudGF0aW9uDQoN Cj4gb2YgSGFwdGljcyDigJMgUGhhc2UgMSBhdCB0aGUganVzdCBjb25jbHVkZWQgTVBFRzEzNCBt ZWV0aW5nIGxhc3Qgd2Vlay4NCg0KPiBUaGUgQ2ZQIHNlZWtzIHRlY2hub2xvZ2llcyB0aGF0IHdv dWxkIGhlbHAgc3RhbmRhcmRpemUgYSBoYXB0aWMgY29kaW5nDQoNCj4gZm9ybWF0IGFuZCBhIGhh cHRpYyBkZWNvZGVyIGluIE1QRUcuIFRoZSBwcmVzcyByZWxlYXNlIGFuZCBmaW5hbCBDZlANCg0K PiBkb2NzIHRoZW1zZWx2ZXMgc2hvdWxkIGJlIGF2YWlsYWJsZSBpbiBhIGZldyBkYXlzLiBEcmFm dCB2ZXJzaW9ucyBvZg0KDQo+IHRoZSBIYXB0aWNzIENmUCBkb2N1bWVudHMgZnJvbQ0KDQo+IE1Q RUcxMzMgaW4gSmFudWFyeSAyMDIxIGNhbiBiZSBmb3VuZCBoZXJlOg0KDQo+IGh0dHBzOi8vbmFt MTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmxp bmsNCg0KPiBwcm90ZWN0LmN1ZGFzdmMuY29tJTJGdXJsJTNGYSUzRGh0dHBzJTI1M2ElMjUyZiUy NTJmd3d3Lm1wZWdzdGFuZGFyZHMuDQoNCj4gb3JnJTI1MmZzdGFuZGFyZHMlMjUyZkV4cGxvcmF0 aW9ucyUyNTJmNDAlMjUyZi4lMjZjJTNERSUyQzElMkNsMXJzSF9BVQ0KDQo+IGpYQ25LRi1PbFRM c3JKNHVQX2tCZEk3czIxa1lHd09ma2RQM2M5enM2WF9KUFlTLWgxbWdqc0VHc25vUkZwMV9ROTNJ TDgNCg0KPiBRU0hZaTVHNWl3SWRWNlg2Q1E2Z2hENzYzbmF3WnFfZzglMkMlMjZ0eXBvJTNEMSZh bXA7ZGF0YT0wNCU3QzAxJTdDJTdDDQoNCj4gNDVhOTMxZGVjNjY0NDlhZjExZWMwOGQ5MGU2NmIw MmMlN0M0ZjA1ZTQxYTU5Yjg0MTNhYWUxOWQ1ZGYzZGZkMGZiNSU3Qw0KDQo+IDAlN0MwJTdDNjM3 NTU2NjU2NDgxNTMwMjkwJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REENCg0KPiBpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3 QzEwMDAmYW1wO3NkYXRhPUdhdWFoDQoNCj4gb0Foa2U4VkFxVm9sWk5oenI1JTJGM0xUZiUyRmg3 aURTM0x2TjR2enNVJTNEJmFtcDtyZXNlcnZlZD0wDQoNCg0KDQpJIGNvdWxkIGV2ZW4gYmVnaW4g dG8gY291bnQgdGhlIG51bWJlciBvZiB0aW1lcyBJJ3ZlIGJlZW4gdG9sZCB0aGF0IHRoaXMgb3Ig dGhhdCBpcyBjcml0aWNhbCBiZWNhdXNlIG9mIHRoZSBhY3Rpb25zIG9mIHNvbWUgb3RoZXIgc3Rh bmRhcmRzIGdyb3VwLCBhbmQgZm9yIHRoYXQgcmVhc29uIHRoZSBJRVRGIG5lZWRzIHRvIGVuZ2Fn ZSBwb3N0IGhhc3RlLiBJTUUgYSBjb21tb24gcmVzdWx0IG9mIHN1Y2ggcGxlYXMgaXMgdG8gc2xv dyB0aGUgd29yayBkb3duLCBhcyBwZW9wbGUgYmVnaW4gdG8gYXJndWUgYWJvdXQgaG93IHRoZSBJ RVRGIHNob3VsZCBoYW5kbGUgaXRzIGludGVyYWN0aW9ucyB3aXRoIG90aGVyIHN0YW5kYXJkcyBi b2RpZXMsIHJhdGhlciB0aGFuIGZvY3VzaW5nIG9uIHRoZSB0ZWNobmljYWwgaXNzdWVzIGF0IGhh bmQuDQoNCltbWUtNXV0gVGhlIHBvaW50IG9mIHByb3ZpZGluZyB0aG9zZSBNUEVHLXJlbGF0ZWQg ZGF0YSBwb2ludHMgd2FzIG5vdCB0byBhY2NlbnR1YXRlIGFueSBjcml0aWNhbGl0eSBhcyBtdWNo IGFzIGl0IHdhcyB0byB1cGRhdGUgdGhlIElFVEYgYXVkaWVuY2UgYWJvdXQgdGhlIHJlY2VudCBw cm9ncmVzcyBtYWRlIGluIE1QRUcgKHRoZSBwcm9ncmVzcyB0aGF0IGhhcyB0YWtlbiBwbGFjZSBz aW5jZSB0aGUgSS1EIHdhcyBsYXN0IHB1Ymxpc2hlZCBpbiBOb3ZlbWJlciAyMDIwKS4gQXMgSeKA mXZlIHNhaWQgYmVmb3JlLCBJIGxvb2sgZm9yd2FyZCB0byBmaWVsZGluZyBjb21tZW50cyBvbiB0 aGUgdGVjaG5pY2FsIG1lcml0cyBvZiB0aGUgY29udGVudCBvZiB0aGUgSS1ELg0KDQoNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE5lZA0K --_000_DM6PR16MB3912BF4649F7CF487C66CC28DE5A9DM6PR16MB3912namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE3NTc2MjkyODY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xOTQ3MTQyMTAwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzguMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDo3NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgltYXJnaW4tbGVmdDoxMTAuMjVwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNDYuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxODIuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJbWFyZ2luLWxlZnQ6MjE4LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjU0LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjkwLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCW1hcmdpbi1sZWZ0OjMyNi4yNXB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TmVkLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGFua3MgZm9yIHRoZSBub3RlLiBNeSBjb21tZW50cyBpbmxpbmUgYmVsb3csIHByZWZhY2Vk IGJ5IOKAmFtZS01d4oCZLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WWVzaHdhbnQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+WWVzaHdhbnQgTXV0aHVzYW15LCBQaC5ELiB8IFNlbmlvciBE aXJlY3RvciwgU3RhbmRhcmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnltdXRodXNh bXlAaW1tZXJzaW9uLmNvbSB8ICsxIDQ2OS01ODMtMjE3MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE5lZCBGcmVlZCAm bHQ7bmVkLmZyZWVkQG1yb2NoZWsuY29tJmd0OyA8YnI+DQpTZW50OiBNb25kYXksIE1heSAzLCAy MDIxIDE6MzAgUE08YnI+DQpUbzogWWVzaHdhbnQgTXV0aHVzYW15ICZsdDt5bXV0aHVzYW15QGlt bWVyc2lvbi5jb20mZ3Q7PGJyPg0KQ2M6IFRlZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNv bSZndDs7IE5lZCBGcmVlZCAmbHQ7bmVkLmZyZWVkQG1yb2NoZWsuY29tJmd0OzsgRGlzcGF0Y2gg V0cgJmx0O2Rpc3BhdGNoQGlldGYub3JnJmd0OzsgZGlzcGF0Y2gtY2hhaXJzQGlldGYub3JnOyBB cHBsaWNhdGlvbnMgYW5kIFJlYWwtVGltZSBBcmVhIERpc2N1c3Npb24gJmx0O2FydEBpZXRmLm9y ZyZndDs7IEFSVCBBRHMgJmx0O2FydC1hZHNAaWV0Zi5vcmcmZ3Q7OyBDbGF1ZGlvIEFsbG9jY2hp byAmbHQ7Q2xhdWRpby5BbGxvY2NoaW9AZ2Fyci5pdCZndDs7DQogRnJhbmNlc2NhIFBhbG9tYmlu aSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyZn dDs7IGRyYWZ0LW11dGh1c2FteS1kaXNwYXRjaC1oYXB0aWNzQGlldGYub3JnPGJyPg0KU3ViamVj dDogUmU6IFtkaXNwYXRjaF0gW2FydF0gU3RhdHVzIG9mIEhhcHRpY3MgSS1EIGluIERJU1BBVENI PzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBGaXJzdCBvZmYsIGdsYWQgdG8gc2VlIHNvbWUgdHJhZmZpYyBvbiB0aGUgaGFw dGljcyBJLUQuIFRoYW5rcyB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IEZyYW5jZXNjYSBmb3IganVtcC1zdGFydGluZyB0aGUgbGF0ZXN0IHJvdW5kIG9m IGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQXQgdGhlIHJp c2sgb2Ygc291bmRpbmcgYmlhc2VkIChhcyBvbmUgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIEktRCks IEkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3b3VsZCBz ZWNvbmQgVGVk4oCZcyBsYXRlc3QgcHJvcG9zYWwgdGhhdCB3ZSBub3Qgb3ZlcmxvYWQgdGhlIFdH IHdpdGgNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBvdGhl ciBtZWRpYSB0eXBlLXJlbGF0ZWQgd29yaywgbGVzdCBpdCBlbmQgdXAgZGUtcHJpb3JpdGl6aW5n IG9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZGVsYXlp bmcgY29uc2lkZXJhdGlvbiBvZiB0aGUgaGFwdGljcyBwcm9wb3NhbC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhpcyBzb3J0IG9mIHRoaW5nIGlzIHdoYXQgV0cgY2hhcnRlcnMgYXJl ICpmb3IqLiBJZiB0aGUgaGFwdGljcyB3b3JrIG5lZWRzIHRvIGNvbWUgZmlyc3QsIHNheSB0aGF0 IGluIHRoZSBjaGFydGVyLiBJZiBhbnl0aGluZyB0aGlzIGluY3JlYXNlcyB0aGUgbGlrbGlob29k IG9mIHlvdXIgcHJvcG9zYWwgZ2V0dGluZyBzb21lIGF0dGVudGlvbiwgYmVjYXVzZSBwZW9wbGUg aW50ZXJlc3RlZCBpbiB0aGUgb3RoZXINCiB3b3JrIGl0ZW1zIHdpbGwgYmUgaW5jZW50aXZpemVk IHRvIGhlbHAgd2l0aCB0aGUgaGFwdGljcyB3b3JrLCBpbiBvcmRlciB0byBnZXQgdG8gdGhlaXIg aXRlbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFEcyBoYXZlIGEgdmFzdCBhcnJh eSBvZiB0aGluZ3MgY29tcGV0aW5nIGZvciB0aGVpciBhdHRlbnRpb24uIFdHIGNoYWlycywgbm90 IHNvIG11Y2guIEFzIHN1Y2gsIGxlYXZpbmcgeW91ciBwcm9wb3NhbCBhcyBhbiBBRC1zcG9uc29y ZWQgaXRlbSBpcyBmYXIgbGVzcyBsaWtlbHkgdG8gcHJvZHVjZSB0aW1lbHkgcmVzdWx0cyB0aGFu IGRvaW5nIGl0IGluIGEgV0cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPltbWUtNXV0gVGhhbmtzIGZvciB0aGUg ZXhwbGFuYXRpb24uIEkgd2FzIG5vdCBhd2FyZSBvZiB0aGUgY2hhcnRlciBhc3BlY3QuIEkgd2Fz IGFncmVlaW5nIHdpdGggVGVk4oCZcyBjb21tZW50IHRoYXQgYSBoYXB0aWNzLXNwZWNpZmljIFdH IHdvdWxkIGJlIG1vcmUgZXhwZWRpZW50LiBKdXN0IGZvciB0aGUgcmVjb3JkLCBhdCB0aGlzIHBv aW50LCBJIGFtDQogY29tcGxldGVseSBPSyB3aXRoICpBTlkqIG9mIHRoZSB0aHJlZSBtZXRob2Rz IG9mIHByb2dyZXNzIGJlaW5nIHB1dCBmb3J3YXJkIGJ5IHZhcmlvdXMgY29tbWVudGVyczo8bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iY29sb3I6 YmxhY2s7bWFyZ2luLWxlZnQ6Mi4yNXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxiPjxp PmEgaGFwdGljcy1zcGVjaWZpYyBmb2N1c2VkIFdHLDwvaT48L2I+PG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iY29sb3I6YmxhY2s7bWFyZ2luLWxlZnQ6Mi4y NXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxiPjxpPmEgbWVkaWEtdHlwZXMgV0csIGFs b25nIHRoZSBsaW5lcyB5b3UgaGF2ZSBzdWdnZXN0ZWQsIHdpdGggYSBjaGFydGVyIHRoYXQgcHJp b3JpdGl6ZXMgdGhlIGhhcHRpY3MgSUQsIG9yPC9pPjwvYj48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJjb2xvcjpibGFjazttYXJnaW4tbGVmdDoyLjI1cHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPGI+PGk+QUQgc3BvbnNvcnNoaXAuIDwvaT48L2I+ PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkkgd2lsbCBkZWZlciB0byB0aGUgcHJvY2VzcyBleHBlcnRz IG9uIHRoaXMgbGlzdCBvbiB0aGUgYmVzdCB3YXkgZm9yd2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBJIGFwcHJlY2lhdGUgdGhlIGltcG9ydGFuY2Ugb2YgTmVk4oCZcyBsaXN0LCBidXQg VGVkIGlzIGNvcnJlY3QgaW4gdGhhdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IHRoZSB0aW1lIHRvIGdldCB0aGUgaGFwdGljcyBwcm9wb3NhbCByZXZpZXdl ZCAoYW5kIGhvcGVmdWxseSwgYXBwcm92ZWQpIGlzIG5vdCB1bmJvdW5kZWQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE1vcmUgb24gdGhhdCBiZWxvdy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXMgSSBzYWlkIGJlZm9yZSwgbm90IG9ubHkgYXJl IHlvdSB0YWxraW5nIGFib3V0IGEgbmV3IHRvcC1sZXZlbCB0eXBlLCB5b3UgYXJlIHRhbGtpbmcg YWJvdXQgb25lIHRoYXQgaGFzIHRoZSBwb3RlbnRpYWwgdG8gaW50ZXJhY3Qgd2l0aCBzcGVjaWZp YyBwcm90b2NvbHMsIGUuZy4sIG9uZSB0aGF0IGhhdmUgc3BlY2lmaWMgc2xvdHMgZm9yIGF1ZGlv IGFuZCB2aWRlbyB0eXBlcyB3aGVyZSB0aGUgdG9wLWxldmVsDQogdmFsdWUgaXMgYXNzdW1lZCwg aW4gY29tcGxpY2F0ZWQgd2F5cy4gQXMgc3VjaCwgeW91IGFyZSBnb2luZyB0byBuZWVkIGludm9s dm1lbnQgZnJvbSBhIG11Y2ggd2lkZXIgcmFuZ2Ugb2YgcGVvcGxlIHRoYW4geW91IHdvdWxkIGZv ciBtb3N0IG9mIHRoZSBvdGhlciBpdGVtcyBvbiB0aGlzIGxpc3QuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPltb WUtNXV0gQWdyZWVkLiBBbiBSRkMgdGhhdCBpcyB0aGUgcmVzdWx0IG9mIGEgZGV0YWlsZWQgcmV2 aWV3IGFuZCByb2J1c3QgZGlzY3Vzc2lvbiBvZiBhbGwgaXRzIGltcGxpY2F0aW9ucyBpcyBwcmVm ZXJyZWQsIGZvciBvYnZpb3VzIHJlYXNvbnMuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU2V0 dGluZyBhc2lkZSB0aGUgaW1wbGljYXRpb25zIChpbmFkdmVydGVudCBvciBvdGhlcndpc2UpIG9m IENsYXVkaW/igJlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgY29tbWVudCB0aGF0IEFwcGxlIG9yIEdvb2dsZSBuZWVkIHRvIGJlIG9uIHRoZSBhdXRob3Jz IGxpc3QgZm9yIElFVEYNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyB0byBldmVuIGNvbnNpZGVyIGFuIElEJm5ic3A7IChvciB3b3JrIG9uIGl0IGV4cGVkaXRp b3VzbHkpLCZuYnNwOyBJIHdvdWxkIHBvaW50DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdG8gdGhlIGZvbGxvd2luZyBEcmFmdCBBbWVuZG1lbnQgb2YgdGhl IElTTy9JRUMgMTQ0OTYtMTIgKElTTyBCYXNlIE1lZGlhIEZpbGUgRm9ybWF0KSBzdGFuZGFyZC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSXQgaXMgdGhlIG9u ZSB0aGF0IGhhcyBvdXIgcHJvcG9zYWwgdG8gdHJlYXQgaGFwdGljcyBhcyBhIHRvcC1sZXZlbA0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1lZGlhIHR5cGUs IGFraW4gdG8gYXVkaW8gYW5kIHZpZGVvLCBpbiBJU09CTUZGIGZpbGVzIChsaWtlIC5tcDQsIC4z Z3BwLCBldGMuKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJo dHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZsaW5rIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj5odHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZsaW5rPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgcHJvdGVjdC5jdWRhc3ZjLmNvbSUyRnVybCUzRmElM0Ro dHRwcyUyNTNhJTI1MmYlMjUyZnd3dy5pc28ub3JnJTI1MmZzdDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhbmRhcmQlMjUyZjgxNjA0Lmh0bWwlMjZjJTNERSUy QzElMkMtdms0ckJ0eE1vSzR1cjFvZWt0OE9iaDAweEJnOEpKeXJ0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHI2MVNheGhIVVhSSktOT0ZFRnRjdk85Skszanhz MG50VmRiWmhmcWRLaHVNaUhBR1ZLSFR1U0ZlYWV5aldWdk9iUXY5Tmw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbjloUWh6bG1lUmtHMEElMkMlMkMlMjZ0eXBv JTNEMSZhbXA7YW1wO2RhdGE9MDQlN0MwMSU3QyU3QzQ1YTkzMWRlYzY2NDQ5YWY8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgMTFlYzA4ZDkwZTY2YjAyYyU3QzRm MDVlNDFhNTliODQxM2FhZTE5ZDVkZjNkZmQwZmI1JTdDMCU3QzAlN0M2Mzc1NTY2NTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA2NDgxNTMwMjkwJTdDVW5rbm93 biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGlMQ0pCVGlJNklrMWhhV3dp TENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDthbXA7c2RhdGE9RCUyRlQwOG5KeCUyQndYbSUyRk5j PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1JYXFuVGVWZmc3 YThQYnVLc3VzVmNvYnhwUGslM0QmYW1wO2FtcDtyZXNlcnZlZD0wPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgRm9yIHRob3NlIGZhbWlsaWFyIHdpdGggaG93IE1QRUcgd29ya3Ms IGEgREFNRCBtZWFucyB0aGF0IHRoZSBwcm9wb3NhbA0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGhhcyBnb25lIHRocm91Z2ggdHdvIHJvdW5kcyBvZiBiYWxs b3RpbmcgZnJvbSB2YXJpb3VzIElTTyBOYXRpb25hbA0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEJvZGllcyAoaW5jbHVkaW5nIHRoZSBVUyBOYXRpb25hbCBC b2R5KS4gQW5kIHllcywgQXBwbGUgYW5kIEdvb2dsZSBhcmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBpbmRlZWQgcGFydCBvZiB0aGUgVVMgTmF0aW9uYWwg Qm9keSA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDss c2Fucy1zZXJpZiI+DQomIzEyODUyMjs8L3NwYW4+LiBXZSBhcmUgaGFwcHkgdG8gcmVwb3J0IHRo YXQgbm8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG9iamVj dGlvbnMgd2VyZSByZWNlaXZlZCB0byB0aGUgaGFwdGljcyBwcm9wb3NhbCBpbiBlaXRoZXIgdGhl IENEIG9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgREFN RCBiYWxsb3Qgcm91bmRzIGZyb20gYW55IG9mIHRoZSAyMCsgTmF0aW9uYWwgQm9kaWVzIHRoYXQg dm90ZWQgb24NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBp dC4gSXQgaGFzIG5vdyBtb3ZlZCB0byBGRElTIGJhbGxvdCAodGhlIGhhcHRpY3MgcHJvcG9zYWwg aGF2aW5nIGJlZW4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBtZXJnZWQgd2l0aCBvdGhlciB1cGRhdGVzIHRvIDE0NDk2LTEyIGZvciBhIG5ldyA3dGg8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZWRpdGlvbikgdGhhdCBp cyBleHBlY3RlZCB0byBjb21wbGV0ZSBieSBKdWx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IE1QRUcgaGFzIGFsc28gaXNzdWVkIGEgQ2FsbCBmb3IgUHJvcG9zYWxzIG9uIHRo ZSBDb2RlZCBSZXByZXNlbnRhdGlvbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IG9mIEhhcHRpY3Mg4oCTIFBoYXNlIDEgYXQgdGhlIGp1c3QgY29uY2x1ZGVk IE1QRUcxMzQgbWVldGluZyBsYXN0IHdlZWsuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgVGhlIENmUCBzZWVrcyB0ZWNobm9sb2dpZXMgdGhhdCB3b3VsZCBo ZWxwIHN0YW5kYXJkaXplIGEgaGFwdGljIGNvZGluZw0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGZvcm1hdCBhbmQgYSBoYXB0aWMgZGVjb2RlciBpbiBNUEVH LiBUaGUgcHJlc3MgcmVsZWFzZSBhbmQgZmluYWwgQ2ZQDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgZG9jcyB0aGVtc2VsdmVzIHNob3VsZCBiZSBhdmFpbGFi bGUgaW4gYSBmZXcgZGF5cy4gRHJhZnQgdmVyc2lvbnMgb2YNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgSGFwdGljcyBDZlAgZG9jdW1lbnRzIGZyb208 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTVBFRzEzMyBpbiBK YW51YXJ5IDIwMjEgY2FuIGJlIGZvdW5kIGhlcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmxpbmsiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vbmFtMTAuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmxpbms8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBwcm90 ZWN0LmN1ZGFzdmMuY29tJTJGdXJsJTNGYSUzRGh0dHBzJTI1M2ElMjUyZiUyNTJmd3d3Lm1wZWdz dGFuZGFyZHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG9y ZyUyNTJmc3RhbmRhcmRzJTI1MmZFeHBsb3JhdGlvbnMlMjUyZjQwJTI1MmYuJTI2YyUzREUlMkMx JTJDbDFyc0hfQVU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg alhDbktGLU9sVExzcko0dVBfa0JkSTdzMjFrWUd3T2ZrZFAzYzl6czZYX0pQWVMtaDFtZ2pzRUdz bm9SRnAxX1E5M0lMODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBRU0hZaTVHNWl3SWRWNlg2Q1E2Z2hENzYzbmF3WnFfZzglMkMlMjZ0eXBvJTNEMSZhbXA7YW1w O2RhdGE9MDQlN0MwMSU3QyU3QzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA0NWE5MzFkZWM2NjQ0OWFmMTFlYzA4ZDkwZTY2YjAyYyU3QzRmMDVlNDFhNTliODQx M2FhZTE5ZDVkZjNkZmQwZmI1JTdDPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDAlN0MwJTdDNjM3NTU2NjU2NDgxNTMwMjkwJTdDVW5rbm93biU3Q1RXRnBiR1pz YjNkOGV5SldJam9pTUM0d0xqQXdNREE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MxMDAwJmFtcDthbXA7c2RhdGE9R2F1YWg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgb0Foa2U4VkFxVm9sWk5oenI1JTJGM0xUZiUyRmg3aURTM0x2TjR2 enNVJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J IGNvdWxkIGV2ZW4gYmVnaW4gdG8gY291bnQgdGhlIG51bWJlciBvZiB0aW1lcyBJJ3ZlIGJlZW4g dG9sZCB0aGF0IHRoaXMgb3IgdGhhdCBpcyBjcml0aWNhbCBiZWNhdXNlIG9mIHRoZSBhY3Rpb25z IG9mIHNvbWUgb3RoZXIgc3RhbmRhcmRzIGdyb3VwLCBhbmQgZm9yIHRoYXQgcmVhc29uIHRoZSBJ RVRGIG5lZWRzIHRvIGVuZ2FnZSBwb3N0IGhhc3RlLiBJTUUgYSBjb21tb24gcmVzdWx0IG9mIHN1 Y2ggcGxlYXMNCiBpcyB0byBzbG93IHRoZSB3b3JrIGRvd24sIGFzIHBlb3BsZSBiZWdpbiB0byBh cmd1ZSBhYm91dCBob3cgdGhlIElFVEYgc2hvdWxkIGhhbmRsZSBpdHMgaW50ZXJhY3Rpb25zIHdp dGggb3RoZXIgc3RhbmRhcmRzIGJvZGllcywgcmF0aGVyIHRoYW4gZm9jdXNpbmcgb24gdGhlIHRl Y2huaWNhbCBpc3N1ZXMgYXQgaGFuZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W1tZS01dXSBUaGUgcG9pbnQg b2YgcHJvdmlkaW5nIHRob3NlIE1QRUctcmVsYXRlZCBkYXRhIHBvaW50cyB3YXMgbm90IHRvIGFj Y2VudHVhdGUgYW55IGNyaXRpY2FsaXR5IGFzIG11Y2ggYXMgaXQgd2FzIHRvIHVwZGF0ZSB0aGUg SUVURiBhdWRpZW5jZSBhYm91dCB0aGUgcmVjZW50IHByb2dyZXNzIG1hZGUgaW4gTVBFRyAodGhl IHByb2dyZXNzIHRoYXQNCiBoYXMgdGFrZW4gcGxhY2Ugc2luY2UgdGhlIEktRCB3YXMgbGFzdCBw dWJsaXNoZWQgaW4gTm92ZW1iZXIgMjAyMCkuIEFzIEnigJl2ZSBzYWlkIGJlZm9yZSwgSSBsb29r IGZvcndhcmQgdG8gZmllbGRpbmcgY29tbWVudHMgb24gdGhlIHRlY2huaWNhbCBtZXJpdHMgb2Yg dGhlIGNvbnRlbnQgb2YgdGhlIEktRC48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5lZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_DM6PR16MB3912BF4649F7CF487C66CC28DE5A9DM6PR16MB3912namp_-- From nobody Mon May 3 17:18:58 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094003A1A7B; Mon, 3 May 2021 17:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3q_FRX5dpjs; Mon, 3 May 2021 17:18:50 -0700 (PDT) Received: from outbound-ip12a.ess.barracuda.com (outbound-ip12a.ess.barracuda.com [209.222.82.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724603A1A76; Mon, 3 May 2021 17:18:42 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2174.outbound.protection.outlook.com [104.47.59.174]) by mx-outbound14-103.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 04 May 2021 00:18:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kvhXlVDgCU+XazIXT3xj/Jhigo11vvi/yb1sCTH4jA8r9nJzZ0Pg3JGtxs9dKBJnq9B9tKL8xFef1nNQU8zFHRZ6ocJ2MUbhX6a20mUBJ/NitQlobhl5d0htlBzZ822wVe6qBeRSqW7aEXvj/QhsrevXnqz/sz8E8RdVoBbZmpRwGmvNdiQMkEiCsp4BJZN2Z44S3PW3Bl7+KPO0FDA0LT8Tix8XEnVvg2A7BvA5aJyJVlPAZ5TZ28Hb8ZbM2b/B/xbLSawLnqyCSDhgK4w5eiRmDtmZUFPzgrMI3AefmMsexLDFaKaALa/L595JD38tk7LyqVMCkK9mDXspIunGTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/252MhZx4ekasPCxrf6C0gc4I/khMDtXKi87wyCp3C4=; b=i6PbLJEWjD0wB0+8P8gtlJas96m9FVMoVLzfgvkf6U3UW/tVPbSAx8IwG50gkR/wGwF4usxqCFGLfO0/h7TFkVytmcejUo4Rxp5CtlLhfJWMrxW+2jQ9bDH0NTdxfr2+OTGGO2q8AcgE2loYXUDaXMc27e6ZqSpnUx6RpAKbRNiMIR9YwbMtreL3qcpIG0WASoCWdpvfCNUAPMW1WGkMRZvaa0Epd0qp9o7xXNJxZIFQC7u1rIPwmyD635BzC+0HgEt5MsKC3JhgoNFyzzDYaxTDU9oXjuijKQi2Cu3ApL+eFZUIYE81PszPOPr9hXJO30BtIGvuZ1PfViGbFdR9sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/252MhZx4ekasPCxrf6C0gc4I/khMDtXKi87wyCp3C4=; b=O5BIb8A5TgFFArZJlpZOHsSyiCvOUi+okVQJDYv/wypb9EPn9J4kkDSwwuZ/yPpgUJSrxn/DI4gsIcHQi9BfGQLrLvwXamBYHsH0WQr1dHmh1bK1u9O3J0f1UAZWMuZJGFUuM0UzcQ402jrxbKYV8ICSn7ukYz0brv7ftGBgYAk= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM6PR16MB3734.namprd16.prod.outlook.com (2603:10b6:5:2b5::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.35; Tue, 4 May 2021 00:18:29 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681%6]) with mapi id 15.20.4087.044; Tue, 4 May 2021 00:18:29 +0000 From: Yeshwant Muthusamy To: Claudio Allocchio , Ned Freed CC: Ted Hardie , Dispatch WG , "dispatch-chairs@ietf.org" , Applications and Real-Time Area Discussion , ART ADs , Francesca Palombini , "draft-muthusamy-dispatch-haptics@ietf.org" Thread-Topic: [dispatch] [art] Status of Haptics I-D in DISPATCH? Thread-Index: AQHXQAiXhkWIzY99rEKfQgzWZ5WHhKrRyR2AgAAN5gCAAAmtFIAAEj6AgAADbRCAACiyU4AABxCAgABOXpA= Date: Tue, 4 May 2021 00:18:28 +0000 Message-ID: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <01RYLJ4MK6040085YQ@mauve.mrochek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: garr.it; dkim=none (message not signed) header.d=none;garr.it; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.43.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fe06fc6-7695-40e8-b4cf-08d90e922487 x-ms-traffictypediagnostic: DM6PR16MB3734: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PhQgASdJFvPvDiH/XSCoORmfk2TRY4iI7mhIwS7AGQj5Enp09yn+VIRCEfOE+VKv0WoUau2ruI85NKQI3ni/DLOs/l/4mqKpKkVabgcKBF+CkB6AS4/b9kuVVoK6q6EYopHHMqMUIJdidRKfP1XleJcYP4tSZ2rA6XoIA9eSTftNQf9HUDTbt7wdyJ95pjEqc0/TDWCOMToXHRaOO6R/YQdTNl0tBC34JLJmBsoOPyo5synl/4gTyR6SDHgqWszHrDI/GYOmspCaQVwomQb9n8832vy/GJod06plut2Tv6CdMrrcP80DhBU6+oXCMvHI8ckwC16Qt8ibUEQjl9D5fKsazhwsf7O/Jt5Fr9IuqWxZn4MtB4CSfHyq7/4AgG6ApbpOxA4vv+wNAWMvKRG1NCKJqHlKJrUzKRJK8xS9mHKTw7VRESFRfLl6+C7WdOe1WNmuE19dD0b/OTjaOmCbQ7yvWoOw2Lht5t8+N6U0tj/sy+C11JPSxyai6bqJQCXBBPL6KWvGuHQ2WD+EhuPiFjiOhwyPzlN48uy2TuRVWHE7SeHc7j7mwjvakl19A7zNFVQWLEznNUGRXnTnGqSap3ARetOYw96USZJz2YEDf/A9skJVb/AkZR/wNw1EOeHZgRWF/UVcmDK2Hz9FIhyqPi1go2LQ398Zdf+UZpzAgwxzGRYB9Z/78zDL3VaRgI+S x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(396003)(136003)(39830400003)(478600001)(7696005)(55016002)(52536014)(9686003)(71200400001)(8676002)(166002)(33656002)(5660300002)(66556008)(66946007)(45080400002)(4326008)(83380400001)(76116006)(110136005)(64756008)(66476007)(66446008)(54906003)(26005)(38100700002)(186003)(8936002)(53546011)(316002)(122000001)(6506007)(2906002)(966005)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?14ndi5dCGmJWOCWddFL5UqbyA5KT19CwZ+1MXOTNfl/ooWB1xCbbWgTIYDVP?= =?us-ascii?Q?l4/UL/MEuupNzy9jNlGBiyyFayqKLiOCA7L/ezHCV3EJ/WR7vSTFdK61nrON?= =?us-ascii?Q?cPkuiKbpChnAAXJVU8w++F1pLo4y+9C28n5QsY29wmesqTg6prwha2FEMZwG?= =?us-ascii?Q?Yi27CzBs6g1Rl5IweCtgZubGP5zXshkbALAtOSy+2ACyi0nu3ximE2bY+cKl?= =?us-ascii?Q?udEi5PKYaMaCuv8hlMGxlc2knQgtzMFyNkpndu/1igSh0txKAFHO8x/rDkbY?= =?us-ascii?Q?Wf8EXiIr0AW71y+iNjlNrDujG3y9PPun+jbfxvzDnCYGJFSDYJzU+4diq1Fk?= =?us-ascii?Q?pUumhSl5GkHHXtYcePRwpj/Xhq4SfSxQv6TrNICL/OZURy+inC16IDmi+WET?= =?us-ascii?Q?J7LEr8nUAYzG3Ock1Wx+G8FY31NdH3cCiRMMjEbxkkl2hUmBzCR/R4o7ikBG?= =?us-ascii?Q?Kme7SGG9U69oYNBV7bqTMucAwSL9uC8eKD/LwSaT8f5MzXSpmpDK8oXDLTog?= =?us-ascii?Q?b+Rxbg8ppCQYOffgc/nH78e1ufIpTw+oo7VRoWBER048pk2eE46jzvBZsLBC?= =?us-ascii?Q?yLqO7rKstmCTv4CkREMs3ZQ2zws2cOFkKAX8iuwB44NzoX0PHD4aFOe+Pwaa?= =?us-ascii?Q?6IJBqsqQ2StEmU6aVnPg/NteQgLwdrRNjyo4YEQsy0sWMcPPItygJWgPn/HJ?= =?us-ascii?Q?xFkE6jw89+vXK06kJZ1vNOACTNuOUDaiYAWHE4bpg4nNwgK5B1kFKD3gCtH5?= =?us-ascii?Q?8VIsfaWscal5Xjb/L+Ed5jAMWsXmH0Ah+qQ2r6RlhVOZISTtfbHCpi/2V563?= =?us-ascii?Q?i58Pin0jXs3MEd2104/x17wpHK5L3AzsPjbwJ/6CLOeoev9wbzhnLusdsPzH?= =?us-ascii?Q?FBzp7zwyzM1TzAeh3zXFkZRiKuRRwBsLdY9AAZHLYk/TUnPLehBm0DwhtM/G?= =?us-ascii?Q?x+h5GBccpTAfEbAuySMq/vsiLNguLIZ+iogAmpQ2PZJbY0quDZ7p62XbxJJi?= =?us-ascii?Q?vloPgjyGzvdi+sMIiZZNi2TrtNadi/XaGXKuWvPrkUKVuk19ho6fKufJjfl/?= =?us-ascii?Q?yCqCveN2PZoM/4OXWqrz7Jg7Kb7ZmP/FoFsL1WeA/IkGubP7x0l03fH9iW52?= =?us-ascii?Q?xlnc8MtLls8hQKiRFb7aOmrfYhDpvEu1pGqweRinWSdZnO39QxE1BwBCwKuz?= =?us-ascii?Q?6Gsmqp13HsB3gNJhn7sOqt/kIPiRMfuVqKWZ3eSQDhs+YHETB83FO01Kh3qa?= =?us-ascii?Q?ErzCPPWXKiCjq6oKirZfAVswGmb7OG66jKQXTfZY0qVskDVd43lcK676NLL1?= =?us-ascii?Q?ilI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR16MB3912A63036A8929595FCB905DE5A9DM6PR16MB3912namp_" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fe06fc6-7695-40e8-b4cf-08d90e922487 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2021 00:18:28.8920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lyJH3XobvuTZ3/iVBoCkOZsNwR1RJnYP1So2dMsTjUuONCkF8NK0/SB4m5yyIM8jqw9/dPdsSSFZG0tquzMh+iytIO3AF6cEtILLD60Mp34= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB3734 X-BESS-ID: 1620087510-103687-23909-8929-1 X-BESS-VER: 2019.1_20210503.2312 X-BESS-Apparent-Source-IP: 104.47.59.174 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.231989 [from cloudscan21-242.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 00:18:56 -0000 --_000_DM6PR16MB3912A63036A8929595FCB905DE5A9DM6PR16MB3912namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Claudio, I was reacting specifically to the following line in your original email (t= he underlining of the word 'co-authoring' is mine): >>I'd like to have a revision (or even co-authoring) at leaset from Apple, = Google and others. I will leave it at that. Regards, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards ymuthusamy@immersion.com | +1 469-583-2171 -----Original Message----- From: Claudio Allocchio Sent: Monday, May 3, 2021 2:33 PM To: Ned Freed Cc: Yeshwant Muthusamy ; Ted Hardie ; Dispatch WG ; dispatch-chairs@ietf.org; Applica= tions and Real-Time Area Discussion ; ART ADs ; Claudio Allocchio ; Francesca Palombini ; draft-muthusamy-dispatc= h-haptics@ietf.org Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? >> Setting aside the implications (inadvertent or otherwise) of >> Claudio's comment that Apple or Google need to be on the authors list >> for IETF to even consider an ID (or work on it expeditiously), you totally misread what I stated, sorry. I said that at least those compan= ies who are implementing the "new stuff" should be involved into the discus= sion of the specificaions, oitherwise the specification will be just ignore= d or result inaccurate compared to reality. And Apple and Google are just 2= examples. The way you read my sentence it totaly against what IETF is how = it works etc. When I (and Ned and John, and many of the people who made sug= gestions in tis thread) started in the IETF, Apple, Google, and 80% of curr= ent companies weer "just not yet stablished", so please do not misread exam= ples. :-) Specifications are done and are successful when all people who ne= ed them work to write them, and when people who will implement them work on= them, too. apart frm this, +1 to Ned's last email. > > I could even begin to count the number of times I've been told that > this or that is critical because of the actions of some other > standards group, and for that reason the IETF needs to engage post > haste. IME a common result of such pleas is to slow the work down, as > people begin to argue about how the IETF should handle its > interactions with other standards bodies, rather than focusing on the tec= hnical issues at hand. yes! > > Ned > ---------------------------------------------------------------------------= --- Claudio Allocchio G A R R Claudio.Allocchio@garr= .it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=3DClaudio; S=3DAlloc= chio; fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr; C= =3Dit; PGP Key: https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.cert.ga= rr.it%252fservizi%252finformazioni-su-pgp-keys%26c%3DE%2C1%2C-GTUZFGQdXv1p6= 94QMmj1sboEwalq1CLyrRlB-PM9e7iQ5szrRm6OpyckAhxnSk2d8ObumtibdgcLcJfnSN_TW--y= HCwqIEObJRv3_zTuuOk%26typo%3D1&data=3D04%7C01%7C%7C6115199e24f6457dcad1= 08d90e6a4141%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C63755667179426970= 3%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha= WwiLCJXVCI6Mn0%3D%7C1000&sdata=3DOkQt7jhvQQ4g8gjGnRXiz0Px0Idrtj1hZuQsQO= xtcAU%3D&reserved=3D0 --_000_DM6PR16MB3912A63036A8929595FCB905DE5A9DM6PR16MB3912namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Claudio,

 

I was reacting specifically to the following line= in your original email (the underlining of the word ‘co-authoring= 217; is mine):

 

>>I'd like to have a revision (or even <= u>co-authoring) at leaset from Apple, Google and others.=

 

I will leave it at that.

 

Regards,

Yeshwant

 

Yeshwant Muthusamy, Ph.D. | Senior Director, Stan= dards

 

ymuthusamy@immersion.com | +1 469-583-2171

 

-----Original Message-----
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
Sent: Monday, May 3, 2021 2:33 PM
To: Ned Freed <ned.freed@mrochek.com>
Cc: Yeshwant Muthusamy <ymuthusamy@immersion.com>; Ted Hardie <ted= .ietf@gmail.com>; Dispatch WG <dispatch@ietf.org>; dispatch-chairs= @ietf.org; Applications and Real-Time Area Discussion <art@ietf.org>;= ART ADs <art-ads@ietf.org>; Claudio Allocchio <Claudio.Allocchio@= garr.it>; Francesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.or= g>; draft-muthusamy-dispatch-haptics@ietf.org
Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH?

 

 

>> Setting aside the implications (inadvert= ent or otherwise) of

>> Claudio’s comment that Apple or Go= ogle need to be on the authors list

>> for IETF to even consider an ID  (o= r work on it expeditiously),

 

you totally misread what I stated, sorry. I said = that at least those companies who are implementing the "new stuff"= ; should be involved into the discussion of the specificaions, oitherwise t= he specification will be just ignored or result inaccurate compared to reality. And Apple and Google are just 2 examples. = The way you read my sentence it totaly against what IETF is how it works et= c. When I (and Ned and John, and many of the people who made suggestions in= tis thread) started in the IETF, Apple, Google, and 80% of current companies weer "just not yet stabli= shed", so please do not misread examples. :-) Specifications are done = and are successful when all people who need them work to write them, and wh= en people who will implement them work on them, too.

 

apart frm this, +1 to Ned's last email.

> 

> I could even begin to count the number of ti= mes I've been told that

> this or that is critical because of the acti= ons of some other

> standards group, and for that reason the IET= F needs to engage post

> haste. IME a common result of such pleas is = to slow the work down, as

> people begin to argue about how the IETF sho= uld handle its

> interactions with other standards bodies, ra= ther than focusing on the technical issues at hand.

 

yes!

 

> 

>        &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  Ned

> 

 

-------------------------------------------------= -----------------------------

Claudio Allocchio     &n= bsp;       G   A   R = ;  R          Claudio.Allocchio@gar= r.it

        &= nbsp;           &nbs= p;    Senior Technical Officer

tel: +39 040 3758523     = ; Italian Academic and       G=3DClaudio; S= =3DAllocchio;

fax: +39 040 3758565     = ;   Research Network       &nb= sp; P=3Dgarr; A=3Dgarr; C=3Dit;

 

      PGP Key: https://nam10.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flinkprotect.cudasvc.com%2Fur= l%3Fa%3Dhttps%253a%252f%252fwww.cert.garr.it%252fservizi%252finformazioni-s= u-pgp-keys%26c%3DE%2C1%2C-GTUZFGQdXv1p694QMmj1sboEwalq1CLyrRlB-PM9e7iQ5szrR= m6OpyckAhxnSk2d8ObumtibdgcLcJfnSN_TW--yHCwqIEObJRv3_zTuuOk%26typo%3D1&a= mp;data=3D04%7C01%7C%7C6115199e24f6457dcad108d90e6a4141%7C4f05e41a59b8413aa= e19d5df3dfd0fb5%7C0%7C0%7C637556671794269703%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp= ;sdata=3DOkQt7jhvQQ4g8gjGnRXiz0Px0Idrtj1hZuQsQOxtcAU%3D&amp;reserved=3D= 0

--_000_DM6PR16MB3912A63036A8929595FCB905DE5A9DM6PR16MB3912namp_-- From nobody Mon May 3 19:09:40 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7A53A1E94; Mon, 3 May 2021 19:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfbQ8byq1-oW; Mon, 3 May 2021 19:09:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25C33A1E93; Mon, 3 May 2021 19:09:29 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ldkV6-000OXt-LR; Mon, 03 May 2021 22:09:28 -0400 Date: Mon, 03 May 2021 22:09:22 -0400 From: John C Klensin To: Francesca Palombini , media-types@ietf.org cc: art@ietf.org, ART ADs , dispatch@ietf.org Message-ID: <0383D07402EB596076C1BD22@PSB> In-Reply-To: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.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 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 02:09:35 -0000 --On Monday, May 3, 2021 16:13 +0000 Francesca Palombini wrote: >... >> (0) This haptics top-level type. >> >> (1) The proposal to allow multiple media type suffixes. >> >> (2) Media types for programming languages >> >> (3) Improved guidelines for constructing media type security >> considerations. >> >> (4) Review the format of the media type registry. One >> suggestion, which I think came from John Klensin, was that >> given media type names can be grandfathered, the name >> itself isn't a reliable indicator of the of the tree, >> so a column listing the tree the type is in would be >> helpful. >... > I am interested to hear your opinion, if you think creating > such a wg would be a good idea and you'd participate in it, if > you have proposals that would fit in such a wg, and especially > if you'd be willing to actively help the wg creation (help out > with chartering, chairing etc). On my side, and speaking only > for myself, I have been warned of long running working groups, > but I am not against it if there is enough interest and people > are willing to put in the time and effort to make this work. Francesca, I don't know what Ned had in mind but, to me, the list above is not open-ended and the sort of thing that would require a WG with an open-ended charter and schedule. Each of the issues Ned raised is a (more or less) new strategic question [1] and they are probably best thought of that way rather than as individual open-ended tasks. Taking the Haptics proposal as an example, Ned should check and confirm this but my recollection from when what is now the media type model was first designed was that we expected very few new top-level types and wanted it to be hard, probably even at the "only if there is no possible other choice" level. Based on reading the draft and the discussion during the DISPATCH meeting, I suspect haptics might qualify. But a WG discussion, both of that proposal and about what light it sheds on the situation and what we have learned in 30 years about what the criteria for top-level types should be. Can we design criteria good enough that expert review is appropriate? Should we convene a WG for each proposed top-level type and, if so, where will the energy come from? Are there better models. For example for this particular proposal, if the real expertise and interest is in an MPEG group [2], would it be sensible to define criteria for top level types so that some sort of "specification from recognized standards body" model would work, perhaps with the IETF setting up an advisory team (the media-types mailing list might or might not be appropriate). I don't have answers, but these are the types of questions a WG ought to be able to address and answer within some plausible time. Media type suffixes are another example. What is needed is an effort to think through the example proposals we have seen and others people might come up with and either decide they are a bad idea or establish evaluation criteria. I hope we would not need a WG for each possible suffix, but we almost certainly need one to establish and reach consensus on some principles. And so on for the rest of the list. Won't be easy, but I don't think it is open-ended. best, john [1] "More or less" because a few have been around, not dealt with, for a while so the "new" part is deciding to deal with them. [2] I'm going to try to write a response to Ted's comments about the need to do something soon, but will keep it separate from this note. From nobody Mon May 3 19:32:49 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B453A1F49 for ; Mon, 3 May 2021 19:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXu51YaCoWYb for ; Mon, 3 May 2021 19:32:42 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A765B3A1F4E for ; Mon, 3 May 2021 19:32:42 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ldkrY-000Oyi-US; Mon, 03 May 2021 22:32:40 -0400 Date: Mon, 03 May 2021 22:32:35 -0400 From: John C Klensin To: Claudio Allocchio , Dispatch WG Message-ID: <70029BDA7ADEAA02347DC287@PSB> In-Reply-To: References: 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 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? (fwd) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 02:32:47 -0000 --On Monday, May 3, 2021 22:22 +0200 Claudio Allocchio wrote: > >>> Setting aside the implications (inadvertent or otherwise) of >>> Claudio's comment that Apple or Google need to be on the >>> authors list for IETF to even consider an ID (or work on it >>> expeditiously), > > you totally misread what I stated, sorry. I said that at least > those companies who are implementing the "new stuff" should be > involved into the discussion of the specificaions, oitherwise > the specification will be just ignored or result inaccurate > compared to reality. And Apple and Google are just 2 examples. And that is, I think, a different way of looking at the concern I expressed about a proposal that --at least as far as the IETF is concerned-- comes from two people at a single company, a company that isn't a major industry player at Apple or Google (or ...) scale, at least yet. That suggests another important distinction: if the haptics work is an area in which companies like that have no interest, it would be reasonable for the IETF to charge ahead without them -- perhaps someone would spring up who would turn into another dominant industry player. But, if companies like that are already involve and setting their own directions and standards, the IETF ignoring what they are doing and going off in a different direction is, to put it mildly, not likely to be useful. > The way you read my sentence it totaly against what IETF is > how it works etc. When I (and Ned and John, and many of the > people who made suggestions in tis thread) started in the > IETF, Apple, Google, and 80% of current companies weer "just > not yet stablished", so please do not misread examples. :-) > Specifications are done and are successful when all people who > need them work to write them, and when people who will > implement them work on them, too. Right. >... >> I could even begin to count the number of times I've been >> told that this or that is critical because of the actions >> of some other standards group, and for that reason the >> IETF needs to engage post haste. IME a common result of >> such pleas is to slow the work down, as people begin to >> argue about how the IETF should handle its interactions >> with other standards bodies, rather than focusing on the >> technical issues at hand. > > yes! I think this suggests something else although it would be a shame to have the Haptics proposal get blocked by it. However.. Once upon a time, long ago, almost all of the important work on the Internet (at least below the applications layer) was being done by the IETF of its predecessors. "We" believed that other groups just didn't have the expertise and perspective (and were probably not far off). The world has changed, perhaps starting with applications work being done elsewhere and either not brought to the IETF at all or brought in when it is already fairly mature. And some of that work originates with other bodies -- sometimes for good reasons like having the expertise and sometimes for bad ones like people getting annoyed by how the IETF does things and going forum-shopping for SDOs in which to develop work. So, while I agree with the comment above, I also think that we may need to figure out how to get better at working with other SDO when a particular subject requires the expertise and perspective of both or when we have sufficiently little of the required combination of expertise, broad IETF community interest, and energy that we should delegate to someone else and, perhaps, do a sanity check on the results. I hope I'm wrong, but my sense is that we are going in the wrong direction in recent years. best john From nobody Mon May 3 20:48:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A392E3A2262; Mon, 3 May 2021 20:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNp8yRZE_tFz; Mon, 3 May 2021 20:47:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9513A2261; Mon, 3 May 2021 20:47:53 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ldm2K-0000DZ-FK; Mon, 03 May 2021 23:47:52 -0400 Date: Mon, 03 May 2021 23:47:46 -0400 From: John C Klensin To: Ted Hardie cc: Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, media-types@ietf.org Message-ID: <2FD10F8AE6D1B9C7D6545340@PSB> In-Reply-To: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.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 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 03:47:59 -0000 (adding the media-types list and doing a bit of trimming) --On Monday, May 3, 2021 17:29 +0100 Ted Hardie wrote: > I think the set of work items Ned lays out might well be the > basis for a working group. I have concerns, however, with > including the registration for a haptics top-level type in > that work. > > As the draft points out, there is a good bit of active work > going on related to haptics in other forums (e.g. the MPEG > Systems File Format sub-group). If the work on registering a > top-level haptics type is interspersed with work on multiple > media type suffixes and media types for programming languages, > I have concerns about the speed with which it can complete. > If we want to see haptic signals be treated appropriately as a > media type, I suspect the time we have to do it is not > unbounded. My personal advice is thus to progress the haptics > work separately. If that means as an ad-sponsored draft, I'm > personally okay with that, but I think the best other option > is to do it as its own short-lived group. The other work (and > the relevant expertise) is pretty distinct. Ted, As you have probably figured out from my recent notes responding to Francesca and Claudio, I have a slightly different take on this, again somewhat different than Ned's comments. One reason is that I think it would be really unfortunate to establish a precedent that the way to get a top-level media type is to invoke work going on at what I understand to be essentially the WG level in another SDO and then plead urgency. I would feel somewhat differently about an established, recognized, deployed international standard, but, as I understand "active work in ... MPEG Systems File Format sub-group", this is fairly far from that. Analogies to other bodies treating I-Ds as if they are finished, consensus, IETF work product are probably useful here. So, in the hope that the IETF is still an organization in which we can figure out what the right thing is to do and then make the procedures work with it, let me suggest something which may be a bit of a strawman: (1) We get the WG that Ned proposed going, with adjustments as suggested. Getting it going should not take long, e.g., no one as proposed a BOF or two as prerequisites. The first charge for that WG should be to review prior work discuss criteria for new top-level media types. I would hope that can be done fairly quickly. If we cannot reach at least sufficient agreement to conclude that a Haptics top level type would be reasonable (independent of the details of how it is defined and who is defining it, much less candidate subtypes) then I suggest the proposal is dead in the water independent of what other bodies are or are not doing. (2) Probably in parallel with the above, Francesca (or Murray) do a call for volunteers who are familiar with and involved in work on Haptics, in the MPEG group, in their "day job" settings, or elsewhere. Where they are tapped as participants in a short-lived WG or as reviewers of a potential AD-sponsored document is probably unimportant, as long as they represent diverse perspectives. The numbers, expertise, and industry coverage are important. Based on the outcome of that poll, they reach a conclusion as to whether meaningful, informed, IETF consensus on the details of the proposal (presumably a revised I-D) is plausible. (3) If the outcome of (2) is that we have a sufficient number of such people, I don't have a strong preference between AD-sponsored and a short-lived WG. However, the less clear the criteria are that emerge from (1) --or if the early result of that effort is general principles but not anything we would consider criteria-- the more I think a WG is needed. (4) If the outcome of (1) is that a Haptics top-level type is plausible but that of (2) is that we don't have, in the judgment of the ADs, the right combination of expertise, interest, and energy, then I suggest we cut a deal with the MPEG effort (close to one end of the pipeline) and/or the relevant ISO TC (the other end) in which we promise them that we will allocate the top-level media type and delegate responsibility for defining subtypes to them as soon as they tell us that a standard that described the properties and use of that type is finished (not being worked on, but finished). Note that punts the question of how subtypes are evaluated and decided upon to another body. Otherwise, that question is one of the harder issues facing the question of criteria for a new top-level type (and a subject on which I, personally, think the current I-D is fairly weak). I don't know if it would be possible to complete the above before IETF 111, but, if not, we ought to be able to come fairly close. And it is _really_ pragmatic. best, john [1[ https://mailarchive.ietf.org/arch/msg/dispatch/RRIs5MxWbQuF9kJJclJ-KsFQNIg [2] https://mailarchive.ietf.org/arch/msg/dispatch/zE9eMvNXpCXF1LWAMt3y-_2GjJ0 From nobody Tue May 4 02:07:02 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0293A2C3F; Tue, 4 May 2021 02:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIwK7-0XjGqi; Tue, 4 May 2021 02:06:48 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4323A2C3E; Tue, 4 May 2021 02:06:47 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id m13so8094599oiw.13; Tue, 04 May 2021 02:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oj7TPMmI6mioA/a4SMrZ2LxuE8pEegrHy8el9bml9ZQ=; b=oMwni90P+7m23xPlGCp3E3ifBJbBD1Vn1qAld8wG5q9v6yVS/F26WOcGZPQMZa1SIV UOItwwRnKYmC4Y5xRveBhvhqLpbQYV2mDIP1bAezCExZUPmWCJxeBHKK29Ry7Z4DuOZv RJnhI+R1c7tW3XL0BYsmgjvprcGy7mUKiKwMK1SxfzR3eS6z6BqYJRPkrf1tYHFgowBZ X/YRMXqQNenQHnsdahsxE2lOC4ZLAlm6cT/pYYa5n+0vy6nIg9uHPwN5ejXAQ3vQHikr olOzQ3zlObx0/Ydg+JvxOOUQJOYhBvvrTWNpafHF+GESnlEdE5VUZvGmSY7eo6600++j SJRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oj7TPMmI6mioA/a4SMrZ2LxuE8pEegrHy8el9bml9ZQ=; b=aINcJL5Y8InwUFShiuG6q+8NKdzTitcm3t8ffh2NgLnwLPfCjpa3eS9EVcX6x+4/mW yjktOuWMa1DbPENxTAlDU+7O9W6MlVU/JRAJ0EXVM4ZVJ+9Jme12D7adLmb1iDxR4eRN YIKIsbHaNqjaIMqhHudYA+s5uY7p3EkQPDQ/DiTdE31uGT+C0+UoiDL8fUsUc2toR63h n1xXyk1OZszRMBRYfmuVPLuVitL8dYviIHImYMp5OGKNe05xKmevb4w+EMcQWZhglQhr AVc117e8Mo6pkQWCZ/MjSwlizEkn5n3X/Lt9tfbHhv7NN1vBoo9c32hUFWUwMfe3tWCz msgw== X-Gm-Message-State: AOAM531bIenettLOwXqUjtrbM6GjEdBQiyAwW/IFX3YJQDKgFEvBU71u VcpyEwVvEPA4O554qO6alfcJ7v0EAjklPTb804JsCiHl+1g= X-Google-Smtp-Source: ABdhPJyG8vQpwFIUfhdnZXvPxIw23RES9Wc2aaTyW6Ev1hHDUOA+n6ie2OHMvEo1qv3zCVwAqkXe+Hx6blNbQdreqsM= X-Received: by 2002:aca:ad87:: with SMTP id w129mr16842198oie.35.1620119205157; Tue, 04 May 2021 02:06:45 -0700 (PDT) MIME-Version: 1.0 References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> In-Reply-To: <2FD10F8AE6D1B9C7D6545340@PSB> From: Ted Hardie Date: Tue, 4 May 2021 10:06:18 +0100 Message-ID: To: John C Klensin Cc: Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, media-types@ietf.org Content-Type: multipart/alternative; boundary="000000000000b7a09905c17d654f" Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 09:06:53 -0000 --000000000000b7a09905c17d654f Content-Type: text/plain; charset="UTF-8" Hi John, Response in-line. On Tue, May 4, 2021 at 4:47 AM John C Klensin wrote: > (adding the media-types list and doing a bit of trimming) > > --On Monday, May 3, 2021 17:29 +0100 Ted Hardie > wrote: > > > I think the set of work items Ned lays out might well be the > > basis for a working group. I have concerns, however, with > > including the registration for a haptics top-level type in > > that work. > > > > As the draft points out, there is a good bit of active work > > going on related to haptics in other forums (e.g. the MPEG > > Systems File Format sub-group). If the work on registering a > > top-level haptics type is interspersed with work on multiple > > media type suffixes and media types for programming languages, > > I have concerns about the speed with which it can complete. > > If we want to see haptic signals be treated appropriately as a > > media type, I suspect the time we have to do it is not > > unbounded. My personal advice is thus to progress the haptics > > work separately. If that means as an ad-sponsored draft, I'm > > personally okay with that, but I think the best other option > > is to do it as its own short-lived group. The other work (and > > the relevant expertise) is pretty distinct. > > Ted, > > As you have probably figured out from my recent notes responding > to Francesca and Claudio, I have a slightly different take on > this, again somewhat different than Ned's comments. One reason > is that I think it would be really unfortunate to establish a > precedent that the way to get a top-level media type is to > invoke work going on at what I understand to be essentially the > WG level in another SDO and then plead urgency. I would feel > somewhat differently about an established, recognized, deployed > international standard, but, as I understand "active work in ... > MPEG Systems File Format sub-group", this is fairly far from > that. > > Analogies to other bodies treating I-Ds as if they are finished, > consensus, IETF work product are probably useful here. > > I believe the issue here isn't the state of the standards-making in another body but the core proposition of the effort: haptic signals are media. There are a lot of consequences of that core proposition, the most important of which for me are that these signals can be bound with other media into coherent multimedia resources and that we can build interoperable standards that allow both haptic media and these multimedia resources to be handled by any compliant systems that follow that standard. (The other obvious way to model them, as application instructions, leaves us in a very different place). If we agree with that core proposition, than incorporating haptic signals into the media types and other aspects of media processing that are under the aegis of the IETF is the right thing to do, and the time to start that work is now, when it is still possible to have the aspects of the system handled elsewhere adjusted more readily. Waiting until that work is completed strikes me as what I grew up hearing called "the wrong mistake". We could also, of course, ignore the work and that proposition. The likely outcomes of that, in my hazy crystal ball, is either that the relevant work will create a MIME-like system that looks like but isn't quite actually MIME (which means that all of the other media types which are consumed by that system will have to deal with being part of two subtly different systems) or that deployed systems will squat on a string in a way that simply routes around our registry and rules. I am sure you can supply the examples which lead me to that conclusion pretty readily. I have not replied to your proposal below to cede the territory to another body, simply because I think a major point of any effort in this space is how multimedia works rather than how single-medium signals are consumed. That being the case, I don't think we can cede without ceding much more of the multimedia landscape than I think you intended. Just my opinion, of course. regards, Ted Hardie So, in the hope that the IETF is still an organization in which > we can figure out what the right thing is to do and then make > the procedures work with it, let me suggest something which may > be a bit of a strawman: > > (1) We get the WG that Ned proposed going, with adjustments as > suggested. Getting it going should not take long, e.g., no one > as proposed a BOF or two as prerequisites. The first charge > for that WG should be to review prior work discuss criteria for > new top-level media types. I would hope that can be done fairly > quickly. If we cannot reach at least sufficient agreement to > conclude that a Haptics top level type would be reasonable > (independent of the details of how it is defined and who is > defining it, much less candidate subtypes) then I suggest the > proposal is dead in the water independent of what other bodies > are or are not doing. > > (2) Probably in parallel with the above, Francesca (or Murray) > do a call for volunteers who are familiar with and involved in > work on Haptics, in the MPEG group, in their "day job" settings, > or elsewhere. Where they are tapped as participants in a > short-lived WG or as reviewers of a potential AD-sponsored > document is probably unimportant, as long as they represent > diverse perspectives. The numbers, expertise, and industry > coverage are important. Based on the outcome of that poll, they > reach a conclusion as to whether meaningful, informed, IETF > consensus on the details of the proposal (presumably a revised > I-D) is plausible. > > (3) If the outcome of (2) is that we have a sufficient number of > such people, I don't have a strong preference between > AD-sponsored and a short-lived WG. However, the less clear the > criteria are that emerge from (1) --or if the early result of > that effort is general principles but not anything we would > consider criteria-- the more I think a WG is needed. > > (4) If the outcome of (1) is that a Haptics top-level type is > plausible but that of (2) is that we don't have, in the judgment > of the ADs, the right combination of expertise, interest, and > energy, then I suggest we cut a deal with the MPEG effort (close > to one end of the pipeline) and/or the relevant ISO TC (the > other end) in which we promise them that we will allocate the > top-level media type and delegate responsibility for defining > subtypes to them as soon as they tell us that a standard that > described the properties and use of that type is finished (not > being worked on, but finished). Note that punts the question of > how subtypes are evaluated and decided upon to another body. > Otherwise, that question is one of the harder issues facing the > question of criteria for a new top-level type (and a subject on > which I, personally, think the current I-D is fairly weak). > > I don't know if it would be possible to complete the above > before IETF 111, but, if not, we ought to be able to come fairly > close. And it is _really_ pragmatic. > > best, > john > > > > > > > [1[ > https://mailarchive.ietf.org/arch/msg/dispatch/RRIs5MxWbQuF9kJJclJ-KsFQNIg > > [2] > https://mailarchive.ietf.org/arch/msg/dispatch/zE9eMvNXpCXF1LWAMt3y-_2GjJ0 > > --000000000000b7a09905c17d654f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

=
Response in-line.

On Tue, May 4, 2021 at 4:47 AM John C Klen= sin <john-ietf@jck.com> wrot= e:
(adding the m= edia-types list and doing a bit of trimming)

--On Monday, May 3, 2021 17:29 +0100 Ted Hardie
<ted.ietf@gmail.= com> wrote:

> I think the set of work items Ned lays out might well be the
> basis for a working group.=C2=A0 I have concerns, however, with
> including the registration for a haptics top-level type in
> that work.
>
> As the draft points out, there is a good bit of active work
> going on related to haptics in other forums (e.g. the MPEG
> Systems File Format sub-group).=C2=A0 If the work on registering a
> top-level haptics type is interspersed with work on multiple
> media type suffixes and media types for programming languages,
> I have concerns about the speed with which it can complete.
> If we want to see haptic signals be treated appropriately as a
> media type, I suspect the time we have to do it is not
> unbounded.=C2=A0 My personal advice is thus to progress the haptics > work separately.=C2=A0 If that means as an ad-sponsored draft, I'm=
> personally okay with that, but I think the best other option
> is to do it as its own short-lived group.=C2=A0 The other work (and > the relevant expertise) is pretty distinct.

Ted,

As you have probably figured out from my recent notes responding
to Francesca and Claudio, I have a slightly different take on
this, again somewhat different than Ned's comments.=C2=A0 One reason is that I think it would be really unfortunate to establish a
precedent that the way to get a top-level media type is to
invoke work going on at what I understand to be essentially the
WG level in another SDO and then plead urgency.=C2=A0 I would feel
somewhat differently about an established, recognized, deployed
international standard, but, as I understand "active work in ...
MPEG Systems File Format sub-group", this is fairly far from
that.

Analogies to other bodies treating I-Ds as if they are finished,
consensus, IETF work product are probably useful here.


I believe the issue here isn't the= state of the standards-making in another body but the core proposition of = the effort:=C2=A0 haptic signals are media.=C2=A0 There are a lot of conseq= uences of that core proposition, the most important of which for me are tha= t these signals can be bound with other media into coherent multimedia reso= urces and that we can build interoperable standards that allow both haptic = media and these multimedia resources to be handled by any compliant systems= that follow that standard.=C2=A0 (The other obvious way to model them, as = application instructions, leaves us in a very different place).
<= br>
If we agree with that core proposition, than incorporating ha= ptic signals into the media types and other aspects of media processing tha= t are under the aegis of the IETF is the right thing to do, and the time to= start that work is now, when it is still possible to have the aspects of t= he system handled elsewhere adjusted more readily.=C2=A0 Waiting until that= work is completed strikes me as what I grew up hearing called "the wr= ong mistake".

We could also, of course, i= gnore the work and that proposition.=C2=A0 The likely outcomes of that, in = my hazy crystal ball, is either that the relevant work will create a MIME-l= ike system that looks like but isn't quite actually MIME (which means t= hat all of the other media types which are consumed by that system will hav= e to deal with being part of two subtly different systems) or that deployed= systems will squat on a string in a way that simply routes around our regi= stry and rules.=C2=A0 I am sure you can supply the examples which lead me t= o that conclusion pretty readily.

I have not replied to your proposal below to cede the territory to an= other body, simply because I think a major point of any effort in this spac= e is how multimedia works rather than how single-medium signals are consume= d.=C2=A0 That being the case, I don't think we can cede without ceding = much more of the multimedia landscape than I think you intended.

Just my opinion,= of course.

regards,

Ted Hardie


So, in the hope that the IETF is still an organization in which
we can figure out what the right thing is to do and then make
the procedures work with it, let me suggest something which may
be a bit of a strawman:

(1) We get the WG that Ned proposed going, with adjustments as
suggested.=C2=A0 Getting it going should not take long, e.g., no one
as proposed a BOF or two as prerequisites.=C2=A0 =C2=A0The first charge
for that WG should be to review prior work discuss criteria for
new top-level media types.=C2=A0 I would hope that can be done fairly
quickly.=C2=A0 If we cannot reach at least sufficient agreement to
conclude that a Haptics top level type would be reasonable
(independent of the details of how it is defined and who is
defining it, much less candidate subtypes) then I suggest the
proposal is dead in the water independent of what other bodies
are or are not doing.

(2) Probably in parallel with the above, Francesca (or Murray)
do a call for volunteers who are familiar with and involved in
work on Haptics, in the MPEG group, in their "day job" settings,<= br> or elsewhere.=C2=A0 Where they are tapped as participants in a
short-lived WG or as reviewers of a potential AD-sponsored
document is probably unimportant, as long as they represent
diverse perspectives.=C2=A0 The numbers, expertise, and industry
coverage are important.=C2=A0 Based on the outcome of that poll, they
reach a conclusion as to whether meaningful, informed, IETF
consensus on the details of the proposal (presumably a revised
I-D) is plausible.

(3) If the outcome of (2) is that we have a sufficient number of
such people, I don't have a strong preference between
AD-sponsored and a short-lived WG.=C2=A0 However, the less clear the
criteria are that emerge from (1) --or if the early result of
that effort is general principles but not anything we would
consider criteria-- the more I think a WG is needed.

(4) If the outcome of (1) is that a Haptics top-level type is
plausible but that of (2) is that we don't have, in the judgment
of the ADs,=C2=A0 the right combination of expertise, interest, and
energy, then I suggest we cut a deal with the MPEG effort (close
to one end of the pipeline) and/or the relevant ISO TC (the
other end) in which we promise them that we will allocate the
top-level media type and delegate responsibility for defining
subtypes to them as soon as they tell us that a standard that
described the properties and use of that type is finished (not
being worked on, but finished).=C2=A0 Note that punts the question of
how subtypes are evaluated and decided upon to another body.
Otherwise, that question is one of the harder issues facing the
question of criteria for a new top-level type (and a subject on
which I, personally, think the current I-D is fairly weak).

I don't know if it would be possible to complete the above
before IETF 111, but, if not, we ought to be able to come fairly
close.=C2=A0 And it is _really_ pragmatic.

=C2=A0 best,
=C2=A0 =C2=A0john






[1[
https://mailarchive.ietf.o= rg/arch/msg/dispatch/RRIs5MxWbQuF9kJJclJ-KsFQNIg

[2]
https://mailarchive.ietf.o= rg/arch/msg/dispatch/zE9eMvNXpCXF1LWAMt3y-_2GjJ0

--000000000000b7a09905c17d654f-- From nobody Tue May 4 10:37:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B43E3A15B2; Tue, 4 May 2021 10:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQNVCYiAXLIy; Tue, 4 May 2021 10:37:45 -0700 (PDT) Received: from outbound-ip12a.ess.barracuda.com (outbound-ip12a.ess.barracuda.com [209.222.82.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E419A3A15AC; Tue, 4 May 2021 10:37:34 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2171.outbound.protection.outlook.com [104.47.58.171]) by mx-outbound11-68.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 04 May 2021 17:37:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b20Kn4+N1hGBBp+zB2gygDH+s8/pWL4dMYxEtnm4VlyyMdUKAXOcniWkSLyRP6Ch7QjIchgDCmaTXP1csrJ9DebNbXB+v8QGjGoav3twY8BaDPDOviy2tVj6O3ZF15A6e7ynbW84Ebz/Sy1Z200mz7+3swZKB2yXT+XMWhgKV8heTff/3EzKHlSA91gYRF/ZUu3EbvoM5IB2RduO6pGM+GCEcf4aKGuOGHFdUNqy0wgZJjQRdSuD4pjjGPOaKA76tJiV0UK5CuVTdaciy9ZRas2xMgH+ke/iMOgz7+esGvGqj/UtMS9jj5NxWXoGpojL6P+O3Am1WcIIN0iru4O30A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DW6Et+8k5G9T8Mg5xAkmsFJwAgAHvxZ6r2kPvFUg5eI=; b=Mgj7m3cEPtXThMf+hzH9o3Al1L7s3XVdyUkFQ/ZhEo6kehALIxr7kbuqyAMjkODmwizLg6N9A1yU5UTnqwdzEyvdoOS+CyEvEWTmjVKA6I1RYpd6+ZHhDXgNExAtVYvdHim8xmYMm+aYVY0Lz8rngEz2EyaEhqaMsLceGW4y1u19kW6BUG368/K3V5ikomjJWqyAixfp9TOSbITM8ZAaPknI0fsBwgnZM8qSFhUF1rJY60mKvNg00nFO0tsYe52aeOZUxFp7TpqmDqP2H8m+Cdtk4wvuQgY5JG/938PY8dVXt+cJYtD0JaNTZG2VINPJvh99yGaRxzSYqeq9G+x1JA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DW6Et+8k5G9T8Mg5xAkmsFJwAgAHvxZ6r2kPvFUg5eI=; b=aRPaq7hgLuK/BHlVEz1zJObXeX1+is2a4MaHWnaCHGiE7KM3SVXwuHeD+AvMLhn48E5gQ99OIamOKh5j/jK7ZwYsfPkt1sZLByPim8PFP0fZg7sVJogEkFZsBfexNxXltr7M197qy6BINF+YJK36Bc5guhvm/lvkoMyCWQZ65t4= Received: from MW3PR16MB3914.namprd16.prod.outlook.com (2603:10b6:303:4d::19) by MWHPR1601MB1183.namprd16.prod.outlook.com (2603:10b6:300:e3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.25; Tue, 4 May 2021 17:37:12 +0000 Received: from MW3PR16MB3914.namprd16.prod.outlook.com ([fe80::3566:e24:c46d:1e4]) by MW3PR16MB3914.namprd16.prod.outlook.com ([fe80::3566:e24:c46d:1e4%8]) with mapi id 15.20.4108.024; Tue, 4 May 2021 17:37:11 +0000 From: Yeshwant Muthusamy To: John C Klensin , Ted Hardie CC: Dispatch WG , "dispatch-chairs@ietf.org" , Applications and Real-Time Area Discussion , ART ADs , "draft-muthusamy-dispatch-haptics@ietf.org" , "media-types@ietf.org" Thread-Topic: [art] [dispatch] Status of Haptics I-D in DISPATCH? Thread-Index: AQHXQJhM4Zh3T3YG3E61gUYzSXJNSarTkCMQ Date: Tue, 4 May 2021 17:37:11 +0000 Message-ID: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> In-Reply-To: <2FD10F8AE6D1B9C7D6545340@PSB> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jck.com; dkim=none (message not signed) header.d=none;jck.com; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.43.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89cc91f2-cdd6-4459-193b-08d90f233fde x-ms-traffictypediagnostic: MWHPR1601MB1183: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KiveCH8lVbtFsMm7lx3NDlSs5fVPu6ACq3Gr3CIJOnD7IpFn5g3Pi7mNJxJ5Z7kH3MQtSZoUizN5J1qEvxtgACCMF66Of6j8EVO/QHMNb9BGoPsXH5ZDAalqVfZBLMPiSdGCSZWasWO6F4BBF3ygCQY2jQX1vM+A1bxf6VgoLMJvPyG0TcVq4zQglqJLxXyNSMehda8UvtvUQ111O1X5C+KagSxPplvjAPEW2Tv9eye3XZtv5jFXUWnMhwHY8dpfYazdiSVqlcMNOUzLLHOJEu1foD+VUCUrXPWPrugfPBhGD+szRMB7HJxsv4TTNRPOrtPaRMtZa6dGErYs7GRVSd+DO1ZYvYxMTwAvnJpfMjS/uXlpXtIXsejOY7aAU2UGEWj72V+/JyvTU6GzmLelBRXQl5RneOtPiNakrHB9rm3rN0TU8Q2plLg/IOFgHL+1NFJirAemvnTrFLIx+4m/HMuNPqnemAKcPDN+RiHlTbZbC8TszggFTnykLv+urK2FNuTFok0yBvY7FHUOdzfvA3VDD/iLszUfOtFaiUQQ/X/A6QHs8/jlz0MC4STlBXwsHBrCXUz/ivaqfqG3HGQbJFMZ8QupalJelcrxFqLDTXQGJToVVV9hxmadsRgCHKCrcgjoy4LKrQAw7X2XN9FkeZ4BUEf2IZK/VSSyswTvIk+X0bp7OJVyiwuh/mVlScpV x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR16MB3914.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(39830400003)(366004)(136003)(66946007)(64756008)(66556008)(66476007)(66446008)(76116006)(8936002)(33656002)(316002)(8676002)(86362001)(166002)(54906003)(83380400001)(966005)(45080400002)(38100700002)(5660300002)(52536014)(71200400001)(55016002)(478600001)(9686003)(110136005)(4326008)(53546011)(6506007)(2906002)(7696005)(122000001)(186003)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?SgzVGk89Fh50mPow152PPEPlNW05/oj+HY539vCp2XEW5qRhMh95dLkMo6Ng?= =?us-ascii?Q?uoVXd8kCtT0B3yREYiAriVHpXrMcUn68DtUnOMsZ/3T62zRUK6XyNspf8NGE?= =?us-ascii?Q?2zPUELTE7TpSsQtL9OlOL7WZSXNSIGtThe06bZ/9pEK0dDEYjCTp3Zrx01YM?= =?us-ascii?Q?X0Hl0ia/fBthoBsEkShuTVHfr1Jd1zWiIV9snrTahxF2R6E5Ms2xwIgiWs6o?= =?us-ascii?Q?Lrhvg5ndMZHbne37mPoRASxi49Tg1jP/wu3I6PsVFHUu4nw7i2eJniVPyVB4?= =?us-ascii?Q?BjkRc9//E3wc0LKTGcuuRJh7ZS4kHinjYdKxX9A4EjnokYtcF8GyIukAAxXx?= =?us-ascii?Q?g2eEicKS/8u7b60XHUrOWO9gn3EskAKnTLq3MSNBVp4Z1RZG2ICh+N+vpEZy?= =?us-ascii?Q?NGqE+/CKGBaPEPo8qgzlvQJi3oQbeXstMhH9Yqx+YiIy2M33911MBv6ztrSd?= =?us-ascii?Q?VoEcIpD8kHD/zsUQYf/BZqADWrfTNqNXzOa/YquEFMgeDkgENv3GVY0nQOMM?= =?us-ascii?Q?759R7cWTn2P1rFe1U1Jdu7RarX0JRQH8tYiYtxcutsu+eZaPytj+Gpi6hb7f?= =?us-ascii?Q?9HcOUli3vs2omo0F8wMXlm3NPSqXe6lQWCw0d3DFOsMbF/1lFElf+C+tpOCY?= =?us-ascii?Q?jzgNf+tkYbxCRHlvDs8jc8h93gcKuf/QP35gqsORJFG+ROomo7srCQmsImOo?= =?us-ascii?Q?3kyTikvRzKMcyu9Ez+k/qmQ3q3L8pe4LwnRgcWXifaf67omHqw+bZbi5P5qy?= =?us-ascii?Q?kDtmsxHngSYmyZOGLgJmAqk+iHu7qBuW6a3t03GIVGgMqiJjwlDcfiBLCeMa?= =?us-ascii?Q?zq/zBEWEDtyWQvatzz6f5X5pBZhKi/Ja/hDC8ObMuFGwGcSTZQtDoYy8Xazx?= =?us-ascii?Q?IFMiaa6zzcUE1K3KFJiF26TIkvOCyal9vYpZm2rfdJA2r5xB41cP17jhRixe?= =?us-ascii?Q?v7pNAiBNj8xSpzEzIwGW7sQZ00eHB9cFW47jO8Ka/EJIITGi/7pCivlFSeAZ?= =?us-ascii?Q?W+ZaR+XOqnROQnAf3YVriMAc3N5dxwcRog22WkPYurTiI9NVgTZK/0Xc51FC?= =?us-ascii?Q?hvWhau0j6uz7/mQI5KWodz+BaNyN837QCxDEfUlWqkokHYJIbVY/5iMf7aOf?= =?us-ascii?Q?JwkuCoN68sSdfFQbkBQl+tJlK4bWP8M16rpGeoLIE+FVPHAWDO1OTdAiqHBR?= =?us-ascii?Q?FlwV1HFULBHIvlViMsW9AKpvG2Szow8wOOKERJKiRNlt2XcRy8GFRandqiKu?= =?us-ascii?Q?lLA9MPhyt9wIUWGI//ldVWiG4sIWnzXhCUVSLBWQeJH91LTOpnQ10Dlq28Ep?= =?us-ascii?Q?/Kg=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR16MB3914440DE7F74C93CCD7D408DE5A9MW3PR16MB3914namp_" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR16MB3914.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89cc91f2-cdd6-4459-193b-08d90f233fde X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2021 17:37:11.7690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yK8zpX83wpZZWegtx1Zl48d0M9sorkbrrkgRnpkdJdpzHPrRz/e77Tta1ZdOYSGBbWkZcp3rcjM7iGvxGGXozjz1E0ImzruirZ81/WfS97s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1601MB1183 X-BESS-ID: 1620149835-102884-5394-29313-1 X-BESS-VER: 2019.1_20210504.1407 X-BESS-Apparent-Source-IP: 104.47.58.171 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.232003 [from cloudscan8-233.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 17:37:51 -0000 --_000_MW3PR16MB3914440DE7F74C93CCD7D408DE5A9MW3PR16MB3914namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, Regarding your comment: >> One reason is that I think it would be really unfortunate to establish a= precedent that the way to get a top-level media type is to invoke work goi= ng on at >>what I understand to be essentially the WG level in another SDO and then = plead urgency. >>I would feel somewhat differently about an established, recognized, deplo= yed international standard, but, as I understand "active work in .. >>MPEG Systems File Format sub-group", this is fairly far from that. I would just reiterate/summarize what I wrote in my response to Ned's comme= nt that you might have missed: the haptics proposal in MPEG is no longer at= the "WG level" in the MPEG Systems File Format sub-group. It just progress= ed to FDIS ballot at MPEG134, which should complete by July 2021, at which = point progression to IS (International Standard) is just a matter of proced= ure. More to the point, it has passed two rounds (CDAM and DAMD) of interna= tional balloting, with over 20 ISO National Bodies casting their ballots in= each round. No objections to the haptics proposal were received in either = round. The proposal left the "WG level" after MPEG131 in July 2020 (for th= e CDAM/CD ballot) and moved to DAMD/DIS ballot after MPEG132 in October 202= 0 - a fact that was indeed mentioned in v01 of the I-D. The ISO link to the DAMD is here: https://www.iso.org/standard/81604.html. To be clear, I have no issues with the other points you raise. Just want to= make sure that the discussion is based on current reality. Thanks, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards ymuthusamy@immersion.com | +1 469-583-2171 -----Original Message----- From: John C Klensin Sent: Monday, May 3, 2021 10:48 PM To: Ted Hardie Cc: Dispatch WG ; dispatch-chairs@ietf.org; Applications= and Real-Time Area Discussion ; ART ADs ; = draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org Subject: Re: [art] [dispatch] Status of Haptics I-D in DISPATCH? (adding the media-types list and doing a bit of trimming) --On Monday, May 3, 2021 17:29 +0100 Ted Hardie > wrote: > I think the set of work items Ned lays out might well be the basis for > a working group. I have concerns, however, with including the > registration for a haptics top-level type in that work. > > As the draft points out, there is a good bit of active work going on > related to haptics in other forums (e.g. the MPEG Systems File Format > sub-group). If the work on registering a top-level haptics type is > interspersed with work on multiple media type suffixes and media types > for programming languages, I have concerns about the speed with which > it can complete. > If we want to see haptic signals be treated appropriately as a media > type, I suspect the time we have to do it is not unbounded. My > personal advice is thus to progress the haptics work separately. If > that means as an ad-sponsored draft, I'm personally okay with that, > but I think the best other option is to do it as its own short-lived > group. The other work (and the relevant expertise) is pretty > distinct. Ted, As you have probably figured out from my recent notes responding to Frances= ca and Claudio, I have a slightly different take on this, again somewhat di= fferent than Ned's comments. One reason is that I think it would be really= unfortunate to establish a precedent that the way to get a top-level media= type is to invoke work going on at what I understand to be essentially the= WG level in another SDO and then plead urgency. I would feel somewhat dif= ferently about an established, recognized, deployed international standard,= but, as I understand "active work in ... MPEG Systems File Format sub-group", this is fairly far from that. Analogies to other bodies treating I-Ds as if they are finished, consensus,= IETF work product are probably useful here. So, in the hope that the IETF is still an organization in which we can figu= re out what the right thing is to do and then make the procedures work with= it, let me suggest something which may be a bit of a strawman: (1) We get the WG that Ned proposed going, with adjustments as suggested. = Getting it going should not take long, e.g., no one as proposed a BOF or two as prerequisites. The first charge for that WG should be to review prior work discuss criteria for new top-lev= el media types. I would hope that can be done fairly quickly. If we canno= t reach at least sufficient agreement to conclude that a Haptics top level = type would be reasonable (independent of the details of how it is defined a= nd who is defining it, much less candidate subtypes) then I suggest the pro= posal is dead in the water independent of what other bodies are or are not = doing. (2) Probably in parallel with the above, Francesca (or Murray) do a call fo= r volunteers who are familiar with and involved in work on Haptics, in the = MPEG group, in their "day job" settings, or elsewhere. Where they are tapp= ed as participants in a short-lived WG or as reviewers of a potential AD-sp= onsored document is probably unimportant, as long as they represent diverse= perspectives. The numbers, expertise, and industry coverage are important= . Based on the outcome of that poll, they reach a conclusion as to whether= meaningful, informed, IETF consensus on the details of the proposal (presu= mably a revised I-D) is plausible. (3) If the outcome of (2) is that we have a sufficient number of such peopl= e, I don't have a strong preference between AD-sponsored and a short-lived = WG. However, the less clear the criteria are that emerge from (1) --or if = the early result of that effort is general principles but not anything we w= ould consider criteria-- the more I think a WG is needed. (4) If the outcome of (1) is that a Haptics top-level type is plausible but= that of (2) is that we don't have, in the judgment of the ADs, the right = combination of expertise, interest, and energy, then I suggest we cut a dea= l with the MPEG effort (close to one end of the pipeline) and/or the releva= nt ISO TC (the other end) in which we promise them that we will allocate th= e top-level media type and delegate responsibility for defining subtypes to= them as soon as they tell us that a standard that described the properties= and use of that type is finished (not being worked on, but finished). Not= e that punts the question of how subtypes are evaluated and decided upon to= another body. Otherwise, that question is one of the harder issues facing the question of= criteria for a new top-level type (and a subject on which I, personally, t= hink the current I-D is fairly weak). I don't know if it would be possible to complete the above before IETF 111,= but, if not, we ought to be able to come fairly close. And it is _really_= pragmatic. best, john [1[ https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flinkpro= tect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fmailarchive.ietf.org%252fa= rch%252fmsg%252fdispatch%252fRRIs5MxWbQuF9kJJclJ-KsFQNIg%26c%3DE%2C1%2C6G6e= DTk9mcWs8uM122hKaDB0VrG8GnkKRboPw6fB2_Uk0RCPxB0I4AJmz_kiaV6x6hH9YVFkCIjyUrD= rCvar10bLNPZHxnhFl2vdY6YRZpbwR-x73Q%2C%2C%26typo%3D1&data=3D04%7C01%7C%= 7C0c8685de1863484c353008d90eaf6c6a%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7= C1%7C637556968891437551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D2woxbmYzryVC8Lwi= aH3%2FQqX3MpKmy6swcrYTRJABu0A%3D&reserved=3D0 [2] https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flinkpro= tect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fmailarchive.ietf.org%252fa= rch%252fmsg%252fdispatch%252fzE9eMvNXpCXF1LWAMt3y-_2GjJ0%26c%3DE%2C1%2ChatQ= i5r0UG0Mih2C0qTKWqSwanmSjZB1qP6OUtqmoEv54rvdqzNMzyWS0pGKI22pTuojS3pMRy-JXiQ= 9VV5jflqvNUmH3UZysPJ6zpaBLbNBf3Z8L6oychaJolb2%26typo%3D1&data=3D04%7C01= %7C%7C0c8685de1863484c353008d90eaf6c6a%7C4f05e41a59b8413aae19d5df3dfd0fb5%7= C0%7C1%7C637556968891437551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DRdVZ172jKG0Z= 31HPBVVeuZgZ916IbaB36dFom6A9rXA%3D&reserved=3D0 --_000_MW3PR16MB3914440DE7F74C93CCD7D408DE5A9MW3PR16MB3914namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 

Regarding your comment:

 

>> One reason is that I think it = would be really unfortunate to establish a precedent that the way to get a = top-level media type is to invoke work going on at

>>what I understand to be essentially th= e WG level in another SDO and then plead urgency.

>>I would feel somewhat differently abou= t an established, recognized, deployed international standard, but, as I un= derstand "active work in ..

>>MPEG Systems File Format sub-group&quo= t;, this is fairly far from that.

 

I would just reiterate/summarize what I wrote in = my response to Ned’s comment that you might have missed: the haptics = proposal in MPEG is no longer at the “WG level” in the MPEG Sys= tems File Format sub-group. It just progressed to FDIS ballot at MPEG134, which should complete by July 2021, at which point prog= ression to IS (International Standard) is just a matter of procedure. More = to the point, it has passed two rounds (CDAM and DAMD) of international bal= loting, with over 20 ISO National Bodies casting their ballots in each round. No objections to the haptics p= roposal were received in either round.  The proposal left the “W= G level” after MPEG131 in July 2020 (for the CDAM/CD ballot) and move= d to DAMD/DIS ballot after MPEG132 in October 2020 – a fact that was indeed mentioned in v01 of the I-D.

 

The ISO link to the DAMD is here: https://www.iso.org/standard/81604.html.

 

To be clear, I have no issues with the other poin= ts you raise. Just want to make sure that the discussion is based on curren= t reality.

 

Thanks,

Yeshwant

 

Yeshwant Muthusamy, Ph.D. | Senior Director, Stan= dards

 

ymuthusamy@immersion.com | +1 469-583-2171

 

-----Original Message-----
From: John C Klensin <john-ietf@jck.com>
Sent: Monday, May 3, 2021 10:48 PM
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Dispatch WG <dispatch@ietf.org>; dispatch-chairs@ietf.org; Applic= ations and Real-Time Area Discussion <art@ietf.org>; ART ADs <art-= ads@ietf.org>; draft-muthusamy-dispatch-haptics@ietf.org; media-types@ie= tf.org
Subject: Re: [art] [dispatch] Status of Haptics I-D in DISPATCH?

 

(adding the media-types list and doing a bit of t= rimming)

 

--On Monday, May 3, 2021 17:29 +0100 Ted Hardie &= lt;ted.ietf@gmail.com> wrote:

 

> I think the set of work items Ned lays out m= ight well be the basis for

> a working group.  I have concerns, howe= ver, with including the

> registration for a haptics top-level type in= that work.

>

> As the draft points out, there is a good bit= of active work going on

> related to haptics in other forums (e.g. the= MPEG Systems File Format

> sub-group).  If the work on registering= a top-level haptics type is

> interspersed with work on multiple media typ= e suffixes and media types

> for programming languages, I have concerns a= bout the speed with which

> it can complete.

> If we want to see haptic signals be treated = appropriately as a media

> type, I suspect the time we have to do it is= not unbounded.  My

> personal advice is thus to progress the hapt= ics work separately.  If

> that means as an ad-sponsored draft, I'm per= sonally okay with that,

> but I think the best other option is to do i= t as its own short-lived

> group.  The other work (and the relevan= t expertise) is pretty

> distinct.

 

Ted,

 

As you have probably figured out from my recent n= otes responding to Francesca and Claudio, I have a slightly different take = on this, again somewhat different than Ned's comments.  One reason is = that I think it would be really unfortunate to establish a precedent that the way to get a top-level media type is to = invoke work going on at what I understand to be essentially the WG level in= another SDO and then plead urgency.  I would feel somewhat differentl= y about an established, recognized, deployed international standard, but, as I understand "active work in ...=

MPEG Systems File Format sub-group", this is= fairly far from that.

 

Analogies to other bodies treating I-Ds as if the= y are finished, consensus, IETF work product are probably useful here.=

 

So, in the hope that the IETF is still an organiz= ation in which we can figure out what the right thing is to do and then mak= e the procedures work with it, let me suggest something which may be a bit = of a strawman:

 

(1) We get the WG that Ned proposed going, with a= djustments as suggested.  Getting it going should not take long, e.g.,= no one

as proposed a BOF or two as prerequisites. &= nbsp; The first charge

for that WG should be to review prior work discus= s criteria for new top-level media types.  I would hope that can be do= ne fairly quickly.  If we cannot reach at least sufficient agreement t= o conclude that a Haptics top level type would be reasonable (independent of the details of how it is defined and who is = defining it, much less candidate subtypes) then I suggest the proposal is d= ead in the water independent of what other bodies are or are not doing.

 

(2) Probably in parallel with the above, Francesc= a (or Murray) do a call for volunteers who are familiar with and involved i= n work on Haptics, in the MPEG group, in their "day job" settings= , or elsewhere.  Where they are tapped as participants in a short-lived WG or as reviewers of a potential AD-sponsored document i= s probably unimportant, as long as they represent diverse perspectives.&nbs= p; The numbers, expertise, and industry coverage are important.  Based= on the outcome of that poll, they reach a conclusion as to whether meaningful, informed, IETF consensus on the detai= ls of the proposal (presumably a revised

I-D) is plausible.

 

(3) If the outcome of (2) is that we have a suffi= cient number of such people, I don't have a strong preference between AD-sp= onsored and a short-lived WG.  However, the less clear the criteria ar= e that emerge from (1) --or if the early result of that effort is general principles but not anything we would cons= ider criteria-- the more I think a WG is needed.

 

(4) If the outcome of (1) is that a Haptics top-l= evel type is plausible but that of (2) is that we don't have, in the judgme= nt of the ADs,  the right combination of expertise, interest, and ener= gy, then I suggest we cut a deal with the MPEG effort (close to one end of the pipeline) and/or the relevant ISO TC = (the other end) in which we promise them that we will allocate the top-leve= l media type and delegate responsibility for defining subtypes to them as s= oon as they tell us that a standard that described the properties and use of that type is finished (not being = worked on, but finished).  Note that punts the question of how subtype= s are evaluated and decided upon to another body.

Otherwise, that question is one of the harder iss= ues facing the question of criteria for a new top-level type (and a subject= on which I, personally, think the current I-D is fairly weak).<= /p>

 

I don't know if it would be possible to complete = the above before IETF 111, but, if not, we ought to be able to come fairly = close.  And it is _really_ pragmatic.

 

  best,

   john

 

 

 

 

 

 

[1[

https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flin= kprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fmailarchive.ietf.org%2= 52farch%252fmsg%252fdispatch%252fRRIs5MxWbQuF9kJJclJ-KsFQNIg%26c%3DE%2C1%2C= 6G6eDTk9mcWs8uM122hKaDB0VrG8GnkKRboPw6fB2_Uk0RCPxB0I4AJmz_kiaV6x6hH9YVFkCIj= yUrDrCvar10bLNPZHxnhFl2vdY6YRZpbwR-x73Q%2C%2C%26typo%3D1&amp;data=3D04%= 7C01%7C%7C0c8685de1863484c353008d90eaf6c6a%7C4f05e41a59b8413aae19d5df3dfd0f= b5%7C0%7C1%7C637556968891437551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA= iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3D2wox= bmYzryVC8LwiaH3%2FQqX3MpKmy6swcrYTRJABu0A%3D&amp;reserved=3D0

 

[2]

https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fl= inkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fmailarchive.ietf.org= %252farch%252fmsg%252fdispatch%252fzE9eMvNXpCXF1LWAMt3y-_2GjJ0%26c%3DE%2C1%= 2ChatQi5r0UG0Mih2C0qTKWqSwanmSjZB1qP6OUtqmoEv54rvdqzNMzyWS0pGKI22pTuojS3pMR= y-JXiQ9VV5jflqvNUmH3UZysPJ6zpaBLbNBf3Z8L6oychaJolb2%26typo%3D1&amp;data= =3D04%7C01%7C%7C0c8685de1863484c353008d90eaf6c6a%7C4f05e41a59b8413aae19d5df= 3dfd0fb5%7C0%7C1%7C637556968891437551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL= jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata= =3DRdVZ172jKG0Z31HPBVVeuZgZ916IbaB36dFom6A9rXA%3D&amp;reserved=3D0

 

--_000_MW3PR16MB3914440DE7F74C93CCD7D408DE5A9MW3PR16MB3914namp_-- From nobody Tue May 4 10:57:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51883A041D; Tue, 4 May 2021 10:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a5_DlkUP2Qf; Tue, 4 May 2021 10:57:00 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67373A041A; Tue, 4 May 2021 10:56:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ldzI1-00032b-1E; Tue, 04 May 2021 13:56:57 -0400 Date: Tue, 04 May 2021 13:56:50 -0400 From: John C Klensin To: Ted Hardie cc: Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, media-types@ietf.org Message-ID: <7541CBA42BA68413DDC85818@PSB> In-Reply-To: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> 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 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 17:57:03 -0000 Hi, Ted, Also inline, with much trimmed. As a preview, I can, and largely do, agree with your "core proposition". I just question whether this draft represents the level of maturity appropriate for AD sponsorship [0], whether the IETF is ready and has the energy and competence to do the work, and whether a top-level media type is appropriate and/or under what conditions. Based on what I have seen so far, I think the answer to all three questions is "no". The answer to the first and third is normally "WG". And the answer to the second is "try to figure out a different way to get the work done". Details below. --On Tuesday, May 4, 2021 10:06 +0100 Ted Hardie wrote: > Hi John, > > Response in-line. > > On Tue, May 4, 2021 at 4:47 AM John C Klensin > wrote: > ... > Ted, > I believe the issue here isn't the state of the > standards-making in another body but the core proposition of > the effort: haptic signals are media. There are a lot of > consequences of that core proposition, the most important of > which for me are that these signals can be bound with other > media into coherent multimedia resources and that we can build > interoperable standards that allow both haptic media and these > multimedia resources to be handled by any compliant systems > that follow that standard. (The other obvious way to model > them, as application instructions, leaves us in a very > different place). > > If we agree with that core proposition, than incorporating > haptic signals into the media types and other aspects of media > processing that are under the aegis of the IETF is the right > thing to do, and the time to start that work is now, when it > is still possible to have the aspects of the system handled > elsewhere adjusted more readily. Waiting until that work is > completed strikes me as what I grew up hearing called "the > wrong mistake". >From a very high-level view, I agree with the above. However, it does not follow from "incorporating haptic... into the media types" that a top-level type is needed, nor that this I-D is a necessary and sufficient proposal to do that. As a specific example, MPEG was incorporated as a subtype under "video" from the very beginning of MIME multimedia work despite normally including audio elements. Its subsequent variants and offspring have been allocated there too. I observe that the work in other SDOs seems to be done in MPEG-related groups: that does not mean "haptics" should not be a top-level type, but it does not strengthen the case. Could this be done as an "application" subtype with appropriate parameters? Perhaps. And that would certainly be the default for haptics as soon as someone pointed out that no video was needed. Keep in mind that the naming part of the media type registration model is ultimately about the names by which things are called within a set of protocols, rather than the things themselves, or even about what people call them. If the proposal were, e.g., to allocate application/haptics (or even video/haptics), I assume the discussion would be mostly with Ned (and potentially Murray and Alexey) as type reviewers and not on the ART or DISPATCH lists. It would be mostly about whether the definition in the document (including whatever stable or unstable references it pointed to) was adequate and not about a fundamental principle about how media type names and registrations are organized. I think that, in the long term, the IETF lives or dies based of the quality of its work. Getting into so much of a hurry about this that we ignore fundamental considerations would be, IMO, a different "wrong mistake". Perhaps equally important to my reaction to your core principle, I don't see anything in either the I-D or the discussion that follows that asks or expects the IETF to get involved in the actual definitions or protocols associated with haptics. What I get from the draft is that there is a new media thing here and that the IETF is being asked at assign a label -- a media type, but remembering that RFCs 2046 and 4289 define that as a type/subtype combination [1], not necessary a top-level one although that is what the I-D proposes. If someone came to us and said "we'd like the IETF to be involved in designing how haptics work, how the data structure for transmitting haptic information is to be defined and organized, and/or how new protocols for transmitting and presenting haptic information (or delivering vibrations to your fingers or seat) are defined, than we would be having a different conversation (from my point of view, even more about expertise in the IETF). But, as far as I can tell, we have not been offered that opportunity and neither MIME, nor the web, nor any other application that uses media types care very much (except for defaults with some known types and unknown subtypes used with them) what things are called, only how the data are organized and whether that organization is well-defined and implemented. If you, or someone else, want to make a proposal that we be involved that way, possibly in competition with other groups, by all means write it. But, as I stands, I see only a request for a name and so I would suggest that the authors (and the IETF might reasonably choose among the following: (1) Go with application/haptics (or video/haptics but I'm personally convinced by the authors' argument about that) and define it now, in a way that is satisfactory to the media-types list and the reviewers. (2) Make a deal with the reviewers that the subtype should be registered new with an informal and incomplete definition but that a more complete definition will come along when the work in MPEG and ISO get further along. The current rules don't encourage that (for good reason) but don't explicitly prohibit it either... and it might be The Right Thing to do for the reasons you indicate. (3) Insist that a top-level type is needed, but accept the fact that such requests are, and should be, subject to very careful scrutiny, scrutiny that necessarily include a review of what we consider appropriate for a top-level type for which there is not already significant experience and very stable specs (it is not, e.g., a situation akin to the request for "font/"). The first should be relatively quick and focus on adequacy of definition rather than question of whether haptic or haptic-related data are appropriate for some sort of media type registration (which, IMO, has never been in doubt-- again agreeing with your core proposition). The second, even quicker, especially if it comes via a formal request from another recognized standards organization (then the ADs would not even need to be involved except maybe for another round on "recognized"). If the third is really the preference, then a WG to examine the issues, the criteria, and probably even the merits of this proposal is the price one pays. To which the request remains one of a new top-level type, the time that might take and the tradeoffs involved are really the authors' issue and problem, not the IETF's. > We could also, of course, ignore the work and that > proposition. The likely outcomes of that, in my hazy crystal > ball, is either that the relevant work will create a MIME-like > system that looks like but isn't quite actually MIME (which > means that all of the other media types which are consumed by > that system will have to deal with being part of two subtly > different systems) or that deployed systems will squat on a > string in a way that simply routes around our registry and > rules. I am sure you can supply the examples which lead me to > that conclusion pretty readily. I can indeed, but I think you are presuming more involvement by the IETF in the definition of data structures and protocols than I think has been asked for or offered (again as a handy example, note that the IETF had zero involvement in defining MPEG itself -- we just assigned a label to an existing spec -- and there is no evidence that either MIME or the Internet have been worse for the experience). Now, if there were something in this proposal (or some proposal that would likely emerge without IETF involvement) that required a different type naming structure or syntax or that created a subtype of, say, "text/", that would be a problem, not just for MIME but for everything that now depends on MIME structures that someone might want to adapt in the future for haptics. So, yes, we should facilitate their getting a name and should, if asked, advise against stupidity. But, beyond that, the only thing MIME --as a set of structures and principles-- cares about is that a stream of bits are transmitted in some contained way. I suppose that, if the data to be transmitted came in Qbits, Frozzles, or some sort of three or four dimensional data arrangement that could not be reified into a stream, there would be a problem in which it would be very important for the IETF to be involved. But not only is that not being proposed by this I-D but it is certainly nothing we'd want to hurry through. > I have not replied to your proposal below to cede the > territory to another body, simply because I think a major > point of any effort in this space is how multimedia works > rather than how single-medium signals are consumed. That being > the case, I don't think we can cede without ceding much more of > the multimedia landscape than I think you intended. I agree with that as a principle, but I don't see a proposal yet -- from you, the authors (in the I-D or otherwise), or anyone else, to get the IETF involved in the relevant protocol definitions or the haptics part of "how multimedia works". From that point of view, the issue is not ceding the territory to others but having it brought to us, pre-ceded, with what it really just a request for a name (again, not that much different from, e.g., what became video/H263-2000 or video/mp4). I can see a very strong case for the IETF being more actively involved in how multimedia works, or possibly in producing a document like RFC 6416 (which defined MP4V-ES), but the current I-D- isn't any of those things and, AFAICT, we have no proposal, or even the beginning of a proposal, in front of us for that sort of work. > Just my opinion, of course. And mine. best, john [0] I don't know that it has ever been formalized and don't know that trying to do so would be a good idea, but one working definition of "appropriate for AD sponsorship" includes at least one of two elements. One is that it is important to be published in the IETF Stream, but no one other than the authors really care or it is presented as their opinion and the impact on the rest of the Internet is likely to be minimal. The other is that there are no controversial issues, especially those of the variety that sorting out during IETF Last Call does not work well or provide confidence about informed IETF consensus. The authors' arguments in the draft and yours about impact on MIEM argue against the first case. I think the question of whether this, as defined in the I-D should be a top-level type is clearly controversial even if the question of whether some name should be assigned is not. [1] That terminology may have been a mistake and/or confusion-prone, but sorting it out is just another argument for the WG Ned suggested. From nobody Tue May 4 12:03:10 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ECD3A0CF0; Tue, 4 May 2021 12:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pcr2QwEdznoK; Tue, 4 May 2021 12:02:56 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75FD3A0CFC; Tue, 4 May 2021 12:02:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYMX93R51S00FNGM@mauve.mrochek.com>; Tue, 4 May 2021 11:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620154632; bh=KIzCIIoNjNUU2NHmRR03vyfyS5G1GoBzL8zKFYpkPUo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=IFLDxqRoZqBol7PqZ+vjT1aISrgPn08IWZcYn9MfupLCFeMqdKqa+rjrymWyCAM47 mZrabPuox2OIQvF5/rt/Hkdl330PvAJc+yDVps3AggD76Z5r++vCP0ZNvG4NZx+4Hn iF+3azS5HiTqHotvAUwGodO+f0rH8MTuhfqGz6/8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Tue, 4 May 2021 11:57:09 -0700 (PDT) Cc: John C Klensin , media-types@ietf.org, Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org Message-id: <01RYMX921V9K0085YQ@mauve.mrochek.com> Date: Tue, 04 May 2021 11:10:01 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 04 May 2021 10:06:18 +0100" References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> To: Ted Hardie Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 19:03:01 -0000 > I believe the issue here isn't the state of the standards-making in another > body but the core proposition of the effort: haptic signals are media. > There are a lot of consequences of that core proposition, the most > important of which for me are that these signals can be bound with other > media into coherent multimedia resources and that we can build > interoperable standards that allow both haptic media and these multimedia > resources to be handled by any compliant systems that follow that > standard. (The other obvious way to model them, as application > instructions, leaves us in a very different place). This statement appears to be based on a misunderstanding of the semantics of the "application" top level media type. The use of the application top-level type in not limited to content consisting of, or which is modeled as, "application instructions". This is clearly stated in RFC 6838 section 4.2.5: The "application" top-level type is to be used for discrete data that do not fit under any of the other type names, and particularly for data to be processed by some type of application program. Applications process media streams all the time, so even the second part of this in no way prohibits the use of application for media that doesn't fit under "audio" or "video" - as haptics clearly does not - and which is modeled as a media stream. Now, you may not like the fact that "application" was chosen to be the name for the catch-all top-level type. Truth be told, I don't much care for it either. But at the time this stuff was decided, this was the best we could come up with. The bottom line is that while there are legitimate arguments to be made in support of defining a new top-level type rather than just using "application", this isn't one of them. > If we agree with that core proposition, The core proposition isn't now and never has been the issue. > than incorporating haptic signals > into the media types and other aspects of media processing that are under > the aegis of the IETF is the right thing to do, The goal of the media types registry is to allow for the registration of anything that functions as a media type, the (very limited) requirements for which are given in RFC 6838 section 4.1. I interpret that section as not only saying that media types for novel sorts of data not only are allowed, they can't be rejected, and I have implemented that interpretation for 20+ years. I can only recall one recent case where I rejected an application for not meeting the criteria for a media type, and that was when someone was attempting to register a media type name for something that in fact was an entire protocol suite. Speaking as one of the media type reviewers, it's my assesment that a well-defined format for haptic signals currently qualifies for registration under "application". And had an application been made for the various haptics subtypes under the "application" tree, they would almost certainly be registered by now. > and the time to start that > work is now, when it is still possible to have the aspects of the system > handled elsewhere adjusted more readily. Waiting until that work is > completed strikes me as what I grew up hearing called "the wrong mistake". Well, so far your arguments here strike me as what I grew hearing called "not even wrong". > We could also, of course, ignore the work and that proposition. Again, the only issue we are concerned with here is whether or not a new top-level type is warranted. Not whether or not haptics stream can be registered as media types. So let's please stop claiming that this is part of the problem. > The likely > outcomes of that, in my hazy crystal ball, is either that the relevant work > will create a MIME-like system that looks like but isn't quite actually > MIME (which means that all of the other media types which are consumed by > that system will have to deal with being part of two subtly different > systems) or that deployed systems will squat on a string in a way that > simply routes around our registry and rules. I am sure you can supply the > examples which lead me to that conclusion pretty readily. I have no crystal ball of any sort, but this is an argument I've heard many times before: Bad things will happen if we don't bend our process to accommodate whatever. And I have the same problem I always have with such claims: Our process is perfectly adequate to deal with the matter. Right now nothing seems to be preventing this work from going forward other than your insistence on it being done your way. > I have not replied to your proposal below to cede the territory to another > body, simply because I think a major point of any effort in this space is > how multimedia works rather than how single-medium signals are consumed. > That being the case, I don't think we can cede without ceding much more of > the multimedia landscape than I think you intended. The mechansism for handing off registration responsibilites to another organization is actually to define a new registration tree (RFC 6838 section 3.5). The specification is silent as to whether responsibility for a top-level type can be handed off to a different organization, which I guess means it could be via a standards action. But this would be a very big step indeed. If haptics types for some reason required expertise beyond that required for media type reviews currently, I would think the better way to do it would be for IANA to find a different set of reviewers with the necessary expertise. This doesn't mean there aren't issues with defining a new top-level type that have to be dealt with. There most certainly are. But instead of looking at those, I'm responding to arguments which, frankly, are rather more FUD-like than I care for. Ned From nobody Tue May 4 12:12:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8253A0DAD; Tue, 4 May 2021 12:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSVlvujehExa; Tue, 4 May 2021 12:12:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012473A0DAC; Tue, 4 May 2021 12:12:39 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1le0T4-0003Ec-62; Tue, 04 May 2021 15:12:26 -0400 Date: Tue, 04 May 2021 15:12:19 -0400 From: John C Klensin To: Yeshwant Muthusamy , Ted Hardie cc: Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, media-types@ietf.org Message-ID: In-Reply-To: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> 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 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 19:12:47 -0000 Yeshwant, Thanks. I did see your response to Ned, but only after sending my note. In what is perhaps an odd way, from my point of view, this is a good news. If the document is in FDIS ballot, all of the suggestions on the this list about how the IETF needs to be involved, and involved, with some accelerated procedure in order to influence the substantive decisions of other standards bodies are moot: as I am sure you know, just about the one way to make a substantive change in an ISO FDIS document is a "no" vote from a national member body, presumably after either objecting all along (which I presume didn't happen) or discovering some catastrophic substantive problem. No room for a "we think it would be better to do this than that" intervention from the IETF. So the only issues relevant to other SDOs now, AFAICT, is what, if anything, those documents (which, sadly, I don't have time to read and study today or even this week) have to say about media type names. If the answer is that they don't say anything, then the IETF should move with appropriate diligence, but should not put "get it done quickly" ahead of "do it right and get it right". If they say "the media type is 'haptics/', then the IETF is essentially dealing, not with your I-D/ proposal but with an accomplished fact. That would present us with a very different, and unpleasant, situation although, using an extension of Ted's argument, I think some of us would argue for registering it and trying to figure out how to avoid that happening again. If it references the I-D, I suspect we could get a note to the editorial team at ISO /CS and/or to the relevant Committee Manager and secretariat about getting that fixed even after FDIS balloting was completed (and might get our way) but whether that would be of substantive importance given that there is no chance of giving them a stable RFC number as a reference is, well, questionable. So now, with the "need to do this quickly to influence the substantive decisions of other SDOs" and the "the IETF needs to be influential about this in order to remain an actor in the multimedia game" aside because, whatever the IETF decides to do about those issues neither they, nor your I-D, have much, if anything, to do with them, it seems to me there are only two questions for the near term: * Does the ISO FDIS mention "haptics/" as top-level media type? If it does, that is a major IETF (and probably IAB) strategy question, not really a media registration one. And that question includes my concern about precedents of other SDOs squatting on names without including us actively in the development process. * If the answer to that is "no", are there objections to more or less the WG approach Ned suggested that do not rely on the "influence the work of other SDOs" argument? thanks, john --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy wrote: > John, > > > > Regarding your comment: > > > >>> One reason is that I think it would be really unfortunate to >>> establish a precedent that the way to get a top-level media >>> type is to invoke work going on at > >>> what I understand to be essentially the WG level in another >>> SDO and then plead urgency. > >>> I would feel somewhat differently about an established, >>> recognized, deployed international standard, but, as I >>> understand "active work in .. > >>> MPEG Systems File Format sub-group", this is fairly far from >>> that. > > > > I would just reiterate/summarize what I wrote in my response > to Ned's comment that you might have missed: the haptics > proposal in MPEG is no longer at the "WG level" in the MPEG > Systems File Format sub-group. It just progressed to FDIS > ballot at MPEG134, which should complete by July 2021, at > which point progression to IS (International Standard) is just > a matter of procedure. More to the point, it has passed two > rounds (CDAM and DAMD) of international balloting, with over > 20 ISO National Bodies casting their ballots in each round. No > objections to the haptics proposal were received in either > round. The proposal left the "WG level" after MPEG131 in July > 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot > after MPEG132 in October 2020 - a fact that was indeed > mentioned in v01 of the I-D. > > > > The ISO link to the DAMD is here: > https://www.iso.org/standard/81604.html s.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstan > dard%2F81604.html&data=04%7C01%7C%7Cb9be185f21b44df1b2f708d90e > 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966 > 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qwZKX%2B26U > WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=0>. > > > > To be clear, I have no issues with the other points you raise. > Just want to make sure that the discussion is based on current > reality. From nobody Tue May 4 15:45:24 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989953A1877; Tue, 4 May 2021 15:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi4uE8qCFLKk; Tue, 4 May 2021 15:45:10 -0700 (PDT) Received: from outbound-ip12a.ess.barracuda.com (outbound-ip12a.ess.barracuda.com [209.222.82.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E003A1876; Tue, 4 May 2021 15:44:56 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2105.outbound.protection.outlook.com [104.47.55.105]) by mx-outbound10-133.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 04 May 2021 22:44:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cbe9Ztn8zGTpWOq7FEafiDEtq9BL2gbRBp7TeFTocZvAX/+3ehIF8kbxrXU8N0Mtij8t6rhUzJp7mBEt7ECKfOYjKnft8EYvuRDtDe3Skctn8T3i+rf1aaywsdksrOHGwDwNa1ZQ5HcQ3aC/O547dN1eG3D4TtNtO5csXKcw6jUMoNxltKmhEGg90KQxIvaC2g5UGWJX++M9romEUf9MpgDxKBicHFtydmpE1+qPhbATC9Kx1QAhcPh1yx7OvyxWQJXcIyHlebLEBijfFqmhYqb6aEsXLZgl5kjpte2A32mZD+65k/bAaVzxNm+443ql6fhSpQUo2TyWUcewW9yDPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4HCwtpjwApwVXJ2G2PQYF2Hmu+yGLJUFX9DVwmkmQmo=; b=Wx+WJZVL7El0TLI60iP/c2l6ybhebRAN/nvfKU7rt6qfCIpC7mpI0QkIaH//FwTPh/6u/mGcXAiSYcbHqWAaEAwr/yrpRv6f+BO0SQnJ1+TrQxjzmkAfVIbMHcYnu9muBTAhiMkGKsPs8dAMx/pKAP6xM//Vz4xO1qKdCztCzVFRFWjhF0tZKmWey6u8axdMqMSrAUwgRWwPLLMVWVkfHcgf2Sq+e0orwkdiHRZ5KJefe66NLoPvO2FJxVlqMS3DsA5E0MUsghoLIFH8I2LDL4iFos3spcTBpeWhsA8putnJDop8LLeRLl+W1Z22kG7EXOtt7em53qd9NpwT1rGNBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4HCwtpjwApwVXJ2G2PQYF2Hmu+yGLJUFX9DVwmkmQmo=; b=B5oM+K8/QTHrHECYPWZR0tkhGUc1UKK3XfdDu7EyRO77oRbWDiQ8X47Z74K1jHTKPGt+dhedn4PFPAUtzoA4Jmu4EomIFDMH8uRv9HVtrunP/yjW8YKlJ2r/PyoUm+QhtndkdX7KdETRu55iKJj/MuXTNiCimjtKgUfWOcePyP0= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM6PR16MB2729.namprd16.prod.outlook.com (2603:10b6:5:126::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24; Tue, 4 May 2021 22:44:33 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681%6]) with mapi id 15.20.4108.025; Tue, 4 May 2021 22:44:33 +0000 From: Yeshwant Muthusamy To: John C Klensin , Ted Hardie CC: Dispatch WG , "dispatch-chairs@ietf.org" , Applications and Real-Time Area Discussion , ART ADs , "draft-muthusamy-dispatch-haptics@ietf.org" , "media-types@ietf.org" Thread-Topic: [art] [dispatch] Status of Haptics I-D in DISPATCH? Thread-Index: AQHXQJhM4Zh3T3YG3E61gUYzSXJNSarTkCMQgAAheoCAADFIIA== Date: Tue, 4 May 2021 22:44:32 +0000 Message-ID: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jck.com; dkim=none (message not signed) header.d=none;jck.com; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.43.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3007a208-fb40-4d05-76c8-08d90f4e2fa3 x-ms-traffictypediagnostic: DM6PR16MB2729: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1tGEFqkGqUw3L7OSSLRqjG02KRRb6x6BXD/kmQkWa0UIwR5gS9O4uUjvXHRBJTK2XQLlr9biIRc+hAvwuvm++UvEgatP3rkP/PjxiyQ2WPxxgWkMRyVmP7DaPVpDtpgECySKdMZc5F21GuB4lWJGv2D8qiZCWVcGbsXmO1nz9E7iidXYUALzkaNC5SM64nKr5Zmi+CQ7gf6XNsCek4WnAAaClU6ARkQFURfCQWQ21kF9pRLtSrT0d49AsKE69D8lZqd+00aPvhXFgbDbK7dRbdBjItpbhPlLjEvE9wg7pNb8mQXpTfMtq9JFx7mcI30LZcZfxbsRhwaFeAF3/FC9lDinTmVQ8m8M1BQMgK+a5zvvVq57tk8JYtRM6FBOaw41ZZ16lT1gWPywTYUJyzv2fvq5jUUYA37UBkoY6zhWF7xO4yG0ZwioOdN+P0zKnIfbStPG/Hq1HWMdolxbQcz8ni7mC6kwNr+tErSkh3v+rFoU4R3vm+KF5PXeHHwIrGJfmA1GUJXCvV2rCGxVM8YDkDAm7uN+Lk/C6/aBez9mXmsIRQAyEy94U7bUysqUdaobnWp1TIEH+P58CtgboWgjLIVGvjwzUDVYwa5MClfPoEMvxQ8pwGYRxOHiVfohSE2bZFvg5KeIi/j2JNqliwm07mIQgwLWzA7vwyO/JuWEL1M= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(366004)(376002)(39830400003)(45080400002)(71200400001)(52536014)(8676002)(5660300002)(66446008)(26005)(86362001)(66476007)(66556008)(55016002)(9686003)(66946007)(64756008)(76116006)(2906002)(33656002)(110136005)(316002)(478600001)(122000001)(4326008)(38100700002)(966005)(8936002)(53546011)(6506007)(54906003)(166002)(83380400001)(186003)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?tJ0K9Cqt7CIeQqUR8beeE3PaRxaicjHWGRWx7YS7gqeGKlM2JW/0p4G8uMoN?= =?us-ascii?Q?xgZ54rMcGiC+xXYgnQLz6B2xwor1HCETRURLOOW9zk/JgOVZX1PR6EF+hAA9?= =?us-ascii?Q?5lkGktRXtMsI+eApTFvuIodr3JEdIxJDD47WbZU3V7pzY/MRlsWrRNy4IrDC?= =?us-ascii?Q?yMQgLLQ8txx/pXStdeMwIdB3k6NM7I9tb3D7cs15Mws/nVrunWCiyxmCApJ5?= =?us-ascii?Q?40RvbCPg0KTSfRTsXq2PR5c0ZtWdIdKoxIHcMCT6Yj3YnOtGeMd9lKBeTBdz?= =?us-ascii?Q?tUCPqN/nYyVo2L5ENDr3UnkHDyx3GwpObGnYZ9zhPnQJaxI2bcJ/616iSNWh?= =?us-ascii?Q?mnrAnmlZvxTzvKrGl6nGnb+EaB09gP8pYgemGpqr7Tok62BwTz9wMTwLfpIW?= =?us-ascii?Q?j1R2nZQAKomhkSj9fueAf8IIIpxP2QIkXagnzwVPlcwsUqplTnayL+wbdLfN?= =?us-ascii?Q?ExiCsI3chq72Fc4OcIHudinfxyOGAwxAvOuaDKdtcd0vI2nalixWtlKewzee?= =?us-ascii?Q?PYmgQ+md6O62+FN1HAXnkK0IWQoyRqoIYoWT8FkT3siCwY2X3hBlN1mP7KkH?= =?us-ascii?Q?DW2Y3ca23hfas4xNvnx2sQ6/Fo0PrrEq7NAqz5DEuS5mOQmgfm6q9SRFsnYK?= =?us-ascii?Q?PfBA4P/8bic70taFPM3qFLmdJeb2lYarY+2WVgM79vCPcYmZ0+4RDgrI0Jry?= =?us-ascii?Q?8WqSZK6/Wix2MP48ERp08Z6Q3w3XGrGqOA+OLkyoNHl2N09/TeNxpj3xOcb1?= =?us-ascii?Q?sJ32I9LnbhyrMQPIfZI7XcgvutaqvwR6USSYGCKuyVaTKEkbcjx1NRJ6OrBC?= =?us-ascii?Q?+eSxQglsRCYGI9OzY6srqeBlA9lTSh+Y7/1a23ZAeD3CIiG5SvKE17Id2xao?= =?us-ascii?Q?04JPKxfKdDQk4X5R51WXLFQe+t0eb5OkZ4wACZXLgcjWppgUByafwiR+vJvY?= =?us-ascii?Q?kZQwv0Vt84Kjck0z8fAYuc+BWwC+UL1QW1C7KFgRsIwbnjTUN6fM38OUgfIM?= =?us-ascii?Q?YBsKL9Cuj+J3zymb8GP5uLOif6WMJdxCbQqMjkkzZh7DwkUBo8SkDUkscINT?= =?us-ascii?Q?soSmmRwAR51vBTgVjTjL1MNTcF3wm7H8y6R9UgO+zOZfPpXEECX/0yImOMbG?= =?us-ascii?Q?zjsepNwQ46NAxqnEJ/W+VHehYguBxh6J+3buS7QM7W2Zz/Xs63fuwBZ5d7xi?= =?us-ascii?Q?9Bj21d9qwZF0ujnsZPZ7guy5l/yIYyfr3qqg0cj6uLoOsAPeIDcjc0fcjMpK?= =?us-ascii?Q?vga1hMbvzrzVAnZlm4br3xO7c793AuICDFedT6pgFCL8/IJE+PwUYkWj8iup?= =?us-ascii?Q?TtY=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR16MB39126AF1F75D8C33F95E3809DE5A9DM6PR16MB3912namp_" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3007a208-fb40-4d05-76c8-08d90f4e2fa3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2021 22:44:32.9847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: M24cLU+9OgMt7Rhihe5UsFU/QMn38bLIoeUAgkUqTo5yRUG2CcLgBODMfzXUY/OwZ17O9g5XxyIXcHSm/0XQY9+wxuZFcm+agaj9iUFMN+0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB2729 X-BESS-ID: 1620168275-102693-5375-68537-1 X-BESS-VER: 2019.1_20210504.1407 X-BESS-Apparent-Source-IP: 104.47.55.105 X-BESS-Outbound-Spam-Score: 0.50 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.232009 [from cloudscan19-53.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname 0.50 BSF_RULE7568M META: Custom Rule 7568M 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.50 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, HTTP_ESCAPED_HOST, BSF_RULE7568M, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 22:45:20 -0000 --_000_DM6PR16MB39126AF1F75D8C33F95E3809DE5A9DM6PR16MB3912namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, Thanks for the note. Taking each one of your two questions in order: >>* Does the ISO FDIS mention "haptics/" as top-level media type? >>If it does, that is a major IETF (and probably IAB) strategy question, no= t really a media registration one. >> And that question includes my concern about precedents of other SDOs squ= atting on names without including us actively in the development process. No. The ISOBMFF FDIS does not mention 'haptics/' as top-level media type. T= hat said, it treats haptics in exactly the same way that it treats other to= p-level media types in Chapter 12 (audio, video, text, font, etc.) that ha= ve been recognized as top-level media types by IETF. To be more specific, o= ur haptics proposal to ISOBMFF follows the same box hierarchy as the other = top-level types: * Media handler is 'hapt' * Haptic Media Header is the NullMediaHeaderBox * Sample entry is the HapticSampleEntry So, there is no issue of ISO squatting on the 'haptics/' name or shutting I= ETF out from the development process. Our objective was to first introduce = haptics as a top-level media type in ISOBMFF and then approach IETF with th= e proposal that we have in our I-D. For obvious reasons, I am unable to sha= re the DAMD or FDIS documents on this mailing list, but I suspect those who= are also members of MPEG can get access to it easily. >>* If the answer to that is "no", are there objections to more or less the= WG approach Ned suggested that do not rely on the "influence the work of o= ther SDOs" argument? Like I've said before, I am open to whatever mechanism the IETF decides to = use to move the I-D forward. Given the work that has already been done in M= PEG and the fact that we are approaching the FDIS ballot completion stage, = I would assume that the IETF would take that into account *in some form* as= it discusses the technical merits of the I-D. Thanks, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards ymuthusamy@immersion.com | +1 469-583-2171 -----Original Message----- From: John C Klensin Sent: Tuesday, May 4, 2021 2:12 PM To: Yeshwant Muthusamy ; Ted Hardie Cc: Dispatch WG ; dispatch-chairs@ietf.org; Applications= and Real-Time Area Discussion ; ART ADs ; = draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org Subject: RE: [art] [dispatch] Status of Haptics I-D in DISPATCH? Yeshwant, Thanks. I did see your response to Ned, but only after sending my note. In what is perhaps an odd way, from my point of view, this is a good news. = If the document is in FDIS ballot, all of the suggestions on the this list= about how the IETF needs to be involved, and involved, with some accelerat= ed procedure in order to influence the substantive decisions of other stand= ards bodies are moot: as I am sure you know, just about the one way to make= a substantive change in an ISO FDIS document is a "no" vote from a nationa= l member body, presumably after either objecting all along (which I presume= didn't happen) or discovering some catastrophic substantive problem. No r= oom for a "we think it would be better to do this than that" intervention f= rom the IETF. So the only issues relevant to other SDOs now, AFAICT, is what, if anything= , those documents (which, sadly, I don't have time to read and study today = or even this week) have to say about media type names. If the answer is th= at they don't say anything, then the IETF should move with appropriate dili= gence, but should not put "get it done quickly" ahead of "do it right and g= et it right". If they say "the media type is 'haptics/', then the IETF is = essentially dealing, not with your I-D/ proposal but with an accomplished f= act. That would present us with a very different, and unpleasant, situatio= n although, using an extension of Ted's argument, I think some of us would = argue for registering it and trying to figure out how to avoid that happeni= ng again. If it references the I-D, I suspect we could get a note to the e= ditorial team at ISO /CS and/or to the relevant Committee Manager and secre= tariat about getting that fixed even after FDIS balloting was completed (an= d might get our way) but whether that would be of substantive importance given that there i= s no chance of giving them a stable RFC number as a reference is, well, que= stionable. So now, with the "need to do this quickly to influence the substantive deci= sions of other SDOs" and the "the IETF needs to be influential about this i= n order to remain an actor in the multimedia game" aside because, whatever = the IETF decides to do about those issues neither they, nor your I-D, have = much, if anything, to do with them, it seems to me there are only two quest= ions for the near term: * Does the ISO FDIS mention "haptics/" as top-level media type? If it does, that is a major IETF (and probably IAB) strategy question, not = really a media registration one. And that question includes my concern abo= ut precedents of other SDOs squatting on names without including us activel= y in the development process. * If the answer to that is "no", are there objections to more or less the W= G approach Ned suggested that do not rely on the "influence the work of oth= er SDOs" argument? thanks, john --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy > wrote: > John, > > > > Regarding your comment: > > > >>> One reason is that I think it would be really unfortunate to >>> establish a precedent that the way to get a top-level media type is >>> to invoke work going on at > >>> what I understand to be essentially the WG level in another SDO and >>> then plead urgency. > >>> I would feel somewhat differently about an established, recognized, >>> deployed international standard, but, as I understand "active work >>> in .. > >>> MPEG Systems File Format sub-group", this is fairly far from that. > > > > I would just reiterate/summarize what I wrote in my response to Ned's > comment that you might have missed: the haptics proposal in MPEG is no > longer at the "WG level" in the MPEG Systems File Format sub-group. It > just progressed to FDIS ballot at MPEG134, which should complete by > July 2021, at which point progression to IS (International Standard) > is just a matter of procedure. More to the point, it has passed two > rounds (CDAM and DAMD) of international balloting, with over > 20 ISO National Bodies casting their ballots in each round. No > objections to the haptics proposal were received in either round. The > proposal left the "WG level" after MPEG131 in July > 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot after > MPEG132 in October 2020 - a fact that was indeed mentioned in v01 of > the I-D. > > > > The ISO link to the DAMD is here: > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flink > protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.org%252fst > andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfsKcfbpK8nr > TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfpREaQwDMRV > d7M%2C%26typo%3D1&data=3D04%7C01%7C%7C98c8e2a934bf4973859d08d90f309c > 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C637557523733134949%7CU > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C2000&sdata=3D%2BufQx8YrBdXpXyihiMQXkoVkuVKQ6A5E3 > Qz3BQ97HVs%3D&reserved=3D0 k.com/?url=3Dhttps%3A%2F%2Fnam10.safelink%2F&data=3D04%7C01%7C%7C98c8= e > 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1 > %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DyJoFSrPdS6 > 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&reserved=3D0 > s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iso.org%2Fstan > dard%2F81604.html&data=3D04%7C01%7C%7Cb9be185f21b44df1b2f708d90e > 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966 > 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DqwZKX%2B26U > WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=3D0>. > > > > To be clear, I have no issues with the other points you raise. > Just want to make sure that the discussion is based on current > reality. --_000_DM6PR16MB39126AF1F75D8C33F95E3809DE5A9DM6PR16MB3912namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 

Thanks for the note. Taking each one of your two = questions in order:

 

>>* Does the ISO FDIS mention "h= aptics/" as top-level media type?

>>If it does, that is a major IETF (a= nd probably IAB) strategy question, not really a media registration one.

>> And that question includes my conc= ern about precedents of other SDOs squatting on names without including us = actively in the development process.

 

No. The ISOBMFF FDIS does not mention ‘hapt= ics/’ as top-level media type. That said, it treats haptics in exactl= y the same way that it treats other top-level media types in Chapter 12 (au= dio, video, text, font,  etc.) that have been recognized as top-level media types by IETF. To be more specific, our hapt= ics proposal to ISOBMFF follows the same box hierarchy as the other top-lev= el types:

  • Media handler is ‘hapt’
  • Haptic Med= ia Header is the NullMediaHeaderBox
  • Sample entry is t= he HapticSampleEntry

 

So, there is no issue of ISO squatting on the = 216;haptics/’ name or shutting IETF out from the development process.= Our objective was to first introduce haptics as a top-level media type in = ISOBMFF and then approach IETF with the proposal that we have in our I-D. For obvious reasons, I am unable to share the DAM= D or FDIS documents on this mailing list, but I suspect those who are also = members of MPEG can get access to it easily.

 

>>* If the answer to that is "no= ", are there objections to more or less the WG approach Ned suggested = that do not rely on the "influence the work of other SDOs" argume= nt?

 

Like I’ve said before, I am open to whateve= r mechanism the IETF decides to use to move the I-D forward. Given the work= that has already been done in MPEG and the fact that we are approaching th= e FDIS ballot completion stage, I would assume that the IETF would take that into account *in some form* as= it discusses the technical merits of the I-D.

 

Thanks,

Yeshwant

 

Yeshwant Muthusamy, Ph.D. | Senior Director, Stan= dards

 

ymuthusamy@immersion.com | +1 469-583-2171

 

-----Original Message-----
From: John C Klensin <john-ietf@jck.com>
Sent: Tuesday, May 4, 2021 2:12 PM
To: Yeshwant Muthusamy <ymuthusamy@immersion.com>; Ted Hardie <ted= .ietf@gmail.com>
Cc: Dispatch WG <dispatch@ietf.org>; dispatch-chairs@ietf.org; Applic= ations and Real-Time Area Discussion <art@ietf.org>; ART ADs <art-= ads@ietf.org>; draft-muthusamy-dispatch-haptics@ietf.org; media-types@ie= tf.org
Subject: RE: [art] [dispatch] Status of Haptics I-D in DISPATCH?

 

Yeshwant,

 

Thanks.  I did see your response to Ned, but= only after sending my note.

 

In what is perhaps an odd way, from my point of v= iew, this is a good news.  If the document is in FDIS ballot, all of t= he suggestions on the this list about how the IETF needs to be involved, an= d involved, with some accelerated procedure in order to influence the substantive decisions of other standards bodies = are moot: as I am sure you know, just about the one way to make a substanti= ve change in an ISO FDIS document is a "no" vote from a national = member body, presumably after either objecting all along (which I presume didn't happen) or discovering some catastrophic= substantive problem.  No room for a "we think it would be better= to do this than that" intervention from the IETF.

 

So the only issues relevant to other SDOs now, AF= AICT, is what, if anything, those documents (which, sadly, I don't have tim= e to read and study today or even this week) have to say about media type n= ames.  If the answer is that they don't say anything, then the IETF should move with appropriate diligence, = but should not put "get it done quickly" ahead of "do it rig= ht and get it right".  If they say "the media type is 'hapti= cs/', then the IETF is essentially dealing, not with your I-D/ proposal but with an accomplished fact.  That would present us with a= very different, and unpleasant, situation although, using an extension of = Ted's argument, I think some of us would argue for registering it and tryin= g to figure out how to avoid that happening again.  If it references the I-D, I suspect we could get a note to th= e editorial team at ISO /CS and/or to the relevant Committee Manager and se= cretariat about getting that fixed even after FDIS balloting was completed = (and might get our

way) but whether that would be of substantive imp= ortance given that there is no chance of giving them a stable RFC number as= a reference is, well, questionable.

 

So now, with the "need to do this quickly to= influence the substantive decisions of other SDOs" and the "the = IETF needs to be influential about this in order to remain an actor in the = multimedia game" aside because, whatever the IETF decides to do about those issues neither they, nor your I-D, have much, if= anything, to do with them, it seems to me there are only two questions for=   the near term:

 

* Does the ISO FDIS mention "haptics/" = as top-level media type?

If it does, that is a major IETF (and probably IA= B) strategy question, not really a media registration one.  And that q= uestion includes my concern about precedents of other SDOs squatting on nam= es without including us actively in the development process.

 

* If the answer to that is "no", are th= ere objections to more or less the WG approach Ned suggested that do not re= ly on the "influence the work of other SDOs" argument?=

 

thanks,

   john

 

--On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Mu= thusamy <ymuthusamy@immersion.com> = wrote:

 

> John,

>

>

>

> Regarding your comment:

>

>

>

>>> One reason is that I think it would = be really unfortunate to

>>> establish a precedent that the way t= o get a top-level media type is

>>> to invoke work going on at

>

>>> what I understand to be essentially = the WG level in another SDO and

>>> then plead urgency.

>

>>> I would feel somewhat differently ab= out an established, recognized,

>>> deployed international standard, but= , as I understand "active work

>>> in ..

>

>>> MPEG Systems File Format sub-group&q= uot;, this is fairly far from that.

>

>

>

> I would just reiterate/summarize what I wrot= e in my response to Ned's

> comment that you might have missed: the hapt= ics proposal in MPEG is no

> longer at the "WG level" in the MP= EG Systems File Format sub-group. It

> just progressed to FDIS ballot at MPEG134, w= hich should complete by

> July 2021, at which point progression to IS = (International Standard)

> is just a matter of procedure. More to the p= oint, it has passed two

> rounds (CDAM and DAMD) of international ball= oting, with over

> 20 ISO National Bodies casting their ballots= in each round. No

> objections to the haptics proposal were rece= ived in either round.  The

> proposal left the "WG level" after= MPEG131 in July

> 2020 (for the CDAM/CD ballot) and moved to D= AMD/DIS ballot after

> MPEG132 in October 2020 - a fact that was in= deed mentioned in v01 of

> the I-D.

>

>

>

> The ISO link to the DAMD is here:=

> https://nam10.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flink

> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%2= 52f%252fwww.iso.org%252fst

> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu= 6oGkeYZ_zgagOzAfsKcfbpK8nr

> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r= 9nTGAUhqz5d0N-gfpREaQwDMRV

> d7M%2C%26typo%3D1&amp;data=3D04%7C01%7C%= 7C98c8e2a934bf4973859d08d90f309c

> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C= 1%7C637557523733134949%7CU

> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1ha

> WwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D%2B= ufQx8YrBdXpXyihiMQXkoVkuVKQ6A5E3

> Qz3BQ97HVs%3D&amp;reserved=3D0<https:= //nam10.safelinks.protection.outloo

> k.com/?url=3Dhttps%3A%2F%2Fnam10.safelink%2F= &amp;data=3D04%7C01%7C%7C98c8e

> 2a934bf4973859d08d90f309c50%7C4f05e41a59b841= 3aae19d5df3dfd0fb5%7C0%7C1

> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3= d8eyJWIjoiMC4wLjAwMDAiLCJQ

> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C2000&amp;sdata=3DyJoFSrPdS6

> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&a= mp;reserved=3D0

> s.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fwww.iso.org%2Fstan

> dard%2F81604.html&data=3D04%7C01%7C%7Cb9= be185f21b44df1b2f708d90e

> 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C= 0%7C0%7C6375565966

> 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4= wLjAwMDAiLCJQIjoiV

> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000= &sdata=3DqwZKX%2B26U

> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&am= p;reserved=3D0>.

>

>

>

> To be clear, I have no issues with the other= points you raise.

> Just want to make sure that the discussion i= s based on current

> reality.

 

 

--_000_DM6PR16MB39126AF1F75D8C33F95E3809DE5A9DM6PR16MB3912namp_-- From nobody Tue May 4 18:16:43 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6B73A1B3C; Tue, 4 May 2021 18:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw08YYtbo_rL; Tue, 4 May 2021 18:16:31 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A11E3A1D70; Tue, 4 May 2021 18:16:31 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1le69D-0004PC-VT; Tue, 04 May 2021 21:16:19 -0400 Date: Tue, 04 May 2021 21:16:13 -0400 From: John C Klensin To: Yeshwant Muthusamy , Ted Hardie cc: Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, media-types@ietf.org Message-ID: In-Reply-To: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> 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 Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 01:16:37 -0000 Yeshwant, Thanks. And thanks for confirming. I think I've said as much as I can usefully say on the subject. best wishes, john --On Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy wrote: > John, > > > > Thanks for the note. Taking each one of your two questions in > order: > > > >>> * Does the ISO FDIS mention "haptics/" as top-level media >>> type? > >>> If it does, that is a major IETF (and probably IAB) strategy >>> question, not really a media registration one. > >>> And that question includes my concern about precedents of >>> other SDOs squatting on names without including us actively >>> in the development process. > > > > No. The ISOBMFF FDIS does not mention 'haptics/' as top-level > media type. That said, it treats haptics in exactly the same > way that it treats other top-level media types in Chapter 12 > (audio, video, text, font, etc.) that have been recognized as > top-level media types by IETF. To be more specific, our > haptics proposal to ISOBMFF follows the same box hierarchy as > the other top-level types: > > * Media handler is 'hapt' > * Haptic Media Header is the NullMediaHeaderBox > * Sample entry is the HapticSampleEntry > > > > So, there is no issue of ISO squatting on the 'haptics/' name > or shutting IETF out from the development process. Our > objective was to first introduce haptics as a top-level media > type in ISOBMFF and then approach IETF with the proposal that > we have in our I-D. For obvious reasons, I am unable to share > the DAMD or FDIS documents on this mailing list, but I suspect > those who are also members of MPEG can get access to it easily. > > > >>> * If the answer to that is "no", are there objections to >>> more or less the WG approach Ned suggested that do not rely >>> on the "influence the work of other SDOs" argument? > > > > Like I've said before, I am open to whatever mechanism the > IETF decides to use to move the I-D forward. Given the work > that has already been done in MPEG and the fact that we are > approaching the FDIS ballot completion stage, I would assume > that the IETF would take that into account *in some form* as > it discusses the technical merits of the I-D. > > > > Thanks, > > Yeshwant > > > > Yeshwant Muthusamy, Ph.D. | Senior Director, Standards > > > > ymuthusamy@immersion.com | +1 469-583-2171 > > > > -----Original Message----- > From: John C Klensin > Sent: Tuesday, May 4, 2021 2:12 PM > To: Yeshwant Muthusamy ; Ted Hardie > Cc: Dispatch WG ; > dispatch-chairs@ietf.org; Applications and Real-Time Area > Discussion ; ART ADs ; > draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org > Subject: RE: [art] [dispatch] Status of Haptics I-D in > DISPATCH? > > > > Yeshwant, > > > > Thanks. I did see your response to Ned, but only after > sending my note. > > > > In what is perhaps an odd way, from my point of view, this is > a good news. If the document is in FDIS ballot, all of the > suggestions on the this list about how the IETF needs to be > involved, and involved, with some accelerated procedure in > order to influence the substantive decisions of other > standards bodies are moot: as I am sure you know, just about > the one way to make a substantive change in an ISO FDIS > document is a "no" vote from a national member body, > presumably after either objecting all along (which I presume > didn't happen) or discovering some catastrophic substantive > problem. No room for a "we think it would be better to do > this than that" intervention from the IETF. > > > > So the only issues relevant to other SDOs now, AFAICT, is > what, if anything, those documents (which, sadly, I don't have > time to read and study today or even this week) have to say > about media type names. If the answer is that they don't say > anything, then the IETF should move with appropriate > diligence, but should not put "get it done quickly" ahead of > "do it right and get it right". If they say "the media type > is 'haptics/', then the IETF is essentially dealing, not with > your I-D/ proposal but with an accomplished fact. That would > present us with a very different, and unpleasant, situation > although, using an extension of Ted's argument, I think some > of us would argue for registering it and trying to figure out > how to avoid that happening again. If it references the I-D, > I suspect we could get a note to the editorial team at ISO /CS > and/or to the relevant Committee Manager and secretariat about > getting that fixed even after FDIS balloting was completed > (and might get our > > way) but whether that would be of substantive importance given > that there is no chance of giving them a stable RFC number as > a reference is, well, questionable. > > > > So now, with the "need to do this quickly to influence the > substantive decisions of other SDOs" and the "the IETF needs > to be influential about this in order to remain an actor in > the multimedia game" aside because, whatever the IETF decides > to do about those issues neither they, nor your I-D, have > much, if anything, to do with them, it seems to me there are > only two questions for the near term: > > > > * Does the ISO FDIS mention "haptics/" as top-level media type? > > If it does, that is a major IETF (and probably IAB) strategy > question, not really a media registration one. And that > question includes my concern about precedents of other SDOs > squatting on names without including us actively in the > development process. > > > > * If the answer to that is "no", are there objections to more > or less the WG approach Ned suggested that do not rely on the > "influence the work of other SDOs" argument? > > > > thanks, > > john > > > > --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy > > > wrote: > > > >> John, > >> > >> > >> > >> Regarding your comment: > >> > >> > >> > >>>> One reason is that I think it would be really unfortunate to > >>>> establish a precedent that the way to get a top-level media >>>> type is > >>>> to invoke work going on at > >> > >>>> what I understand to be essentially the WG level in another >>>> SDO and > >>>> then plead urgency. > >> > >>>> I would feel somewhat differently about an established, >>>> recognized, > >>>> deployed international standard, but, as I understand >>>> "active work > >>>> in .. > >> > >>>> MPEG Systems File Format sub-group", this is fairly far >>>> from that. > >> > >> > >> > >> I would just reiterate/summarize what I wrote in my response >> to Ned's > >> comment that you might have missed: the haptics proposal in >> MPEG is no > >> longer at the "WG level" in the MPEG Systems File Format >> sub-group. It > >> just progressed to FDIS ballot at MPEG134, which should >> complete by > >> July 2021, at which point progression to IS (International >> Standard) > >> is just a matter of procedure. More to the point, it has >> passed two > >> rounds (CDAM and DAMD) of international balloting, with over > >> 20 ISO National Bodies casting their ballots in each round. No > >> objections to the haptics proposal were received in either >> round. The > >> proposal left the "WG level" after MPEG131 in July > >> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot >> after > >> MPEG132 in October 2020 - a fact that was indeed mentioned in >> v01 of > >> the I-D. > >> > >> > >> > >> The ISO link to the DAMD is here: > >> https://nam10.safelinks.protection.outlook.com/?url=https%3A% >> 2F%2Flink > >> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.o >> rg%252fst > >> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs >> KcfbpK8nr > >> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp >> REaQwDMRV > >> d7M%2C%26typo%3D1&data=04%7C01%7C%7C98c8e2a934bf4973859d0 >> 8d90f309c > >> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331 >> 34949%7CU > >> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB >> TiI6Ik1ha > >> WwiLCJXVCI6Mn0%3D%7C2000&sdata=%2BufQx8YrBdXpXyihiMQXkoVk >> uVKQ6A5E3 > >> Qz3BQ97HVs%3D&reserved=0> on.outloo > >> k.com/?url=https%3A%2F%2Fnam10.safelink%2F&data=04%7C01%7 >> C%7C98c8e > >> 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb >> 5%7C0%7C1 > >> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA >> wMDAiLCJQ > >> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=y >> JoFSrPdS6 > >> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&reserved=0 > >> s.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstan > >> dard%2F81604.html&data=04%7C01%7C%7Cb9be185f21b44df1b2f708d90e > >> 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966 > >> 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qwZKX%2B26U > >> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=0>. > >> > >> > >> > >> To be clear, I have no issues with the other points you raise. > >> Just want to make sure that the discussion is based on current > >> reality. > > > > From nobody Wed May 5 01:50:17 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19DD3A1899; Wed, 5 May 2021 01:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxZzxab3Sqoj; Wed, 5 May 2021 01:50:10 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476213A1896; Wed, 5 May 2021 01:50:09 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id u19-20020a0568302493b02902d61b0d29adso274521ots.10; Wed, 05 May 2021 01:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RUEiqTc3BOeMXVEzyvWF2ED9sNvKzlGtF+1rCwV4J68=; b=O6V1RfAxIjuSNp9+4cahfK9y9CVIftMK+hc1EBtK9yROXP7HWTfmvRrBXtJVuFACPz fthTrNt0PVb1rhTz2/qzIJZ3lIaCNYFLKTi2cWGLJEMEcm+2p8sZS1jfjDyqo5bnrEct IsZeQfunsb922ZCZoU+AaYvU1xx6zv+QLzISB3DQdTx/ecWkbVJfQrsxogSgCMH1eRZF ddmj94vn1hRU9N/J6jk4mXCryqoD4lONWCRb342AT/eV95FRRzmo7qq/LPqp2uwNrrV0 IDsuRGDn0gsHuvB1cEp0VfYVwE5r1mtyQh2Iuqp9d+DpU29WtXXDN/2rxdr5UzF+YVyL kJtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RUEiqTc3BOeMXVEzyvWF2ED9sNvKzlGtF+1rCwV4J68=; b=AJ8NEuwOz2b6uj0rj3x6d3oBO32xlzrufUtNmap4OvxMmZIVl//eB7fgCj64EHMRNz ylmkYFLnYWOJh09G2Kj/ZmATawQQmHUrRdEAvzdl57wob2hgIgbNyI5yozsVnbUGLnUj 41J/TIsWTKiGUbR0/KkhmZZDUn6p/AmHUYCwYRc7ir4B4dGoWH92o4O6d/d3sS2cypVH 0t4o3VaSVfQUBHk9kpeAVRRAedY/B0zNCLn4ojr9AvAckYfOPPPtEUKzPHqkpWxufIuU 0umXA0oLkiSBWtygS2prEa1IOioZ71SznvI7DAOiDQ3IB/+/1Ei1cJQ3CWcOECBAYZTr X22g== X-Gm-Message-State: AOAM532LVhHfSQuXcHfbQBBxBOY/IH1AVvaIZQywP6xLd3KYHDs1Ohcb WD5gKAYci0QqxrswIl0EEEqzm4H11rHk29Zafb0= X-Google-Smtp-Source: ABdhPJy92qSuoPJfCHRUZumXsbcaPSmSJDy6pHL9mwnZ39QOGIFHYHypTEgj9Ms/6decsC1hJk9TFCzSwcEYCoPmH9s= X-Received: by 2002:a9d:be2:: with SMTP id 89mr22903888oth.269.1620204607773; Wed, 05 May 2021 01:50:07 -0700 (PDT) MIME-Version: 1.0 References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> <01RYMX921V9K0085YQ@mauve.mrochek.com> In-Reply-To: <01RYMX921V9K0085YQ@mauve.mrochek.com> From: Ted Hardie Date: Wed, 5 May 2021 09:49:41 +0100 Message-ID: To: Ned Freed Cc: John C Klensin , media-types@ietf.org, Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org Content-Type: multipart/alternative; boundary="0000000000001c212605c19148e6" Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 08:50:15 -0000 --0000000000001c212605c19148e6 Content-Type: text/plain; charset="UTF-8" Responses in-line. On Tue, May 4, 2021 at 8:02 PM Ned Freed wrote: > > I believe the issue here isn't the state of the standards-making in > another > > body but the core proposition of the effort: haptic signals are media. > > There are a lot of consequences of that core proposition, the most > > important of which for me are that these signals can be bound with other > > media into coherent multimedia resources and that we can build > > interoperable standards that allow both haptic media and these multimedia > > resources to be handled by any compliant systems that follow that > > standard. (The other obvious way to model them, as application > > instructions, leaves us in a very different place). > > This statement appears to be based on a misunderstanding of the semantics > of the > "application" top level media type. > > The use of the application top-level type in not limited to content > consisting > of, or which is modeled as, "application instructions". > > This is clearly stated in RFC 6838 section 4.2.5: > > The "application" top-level type is to be used for discrete data that > do not fit under any of the other type names, and particularly for > data to be processed by some type of application program. > > Applications process media streams all the time, so even the second part > of this > in no way prohibits the use of application for media that doesn't fit under > "audio" or "video" - as haptics clearly does not - and which is modeled > as a media stream. > > Now, you may not like the fact that "application" was chosen to be the > name for > the catch-all top-level type. Truth be told, I don't much care for it > either. > But at the time this stuff was decided, this was the best we could come up > with. > > I think it is more this bit that I find telling for the current case: The subtype of "application" will often either be the name or include part of the name of the application for which the data are intended. This does not mean, however, that any application program name may simply be used freely as a subtype of "application"; the subtype needs to be registered. Using this approach to naming would mire the inclusion of haptic signals in pointers to specific applications, where the value is in defining the methods so that they can be consumed by any compliant application. If there were a single haptic signal then application/haptic might well work, but with a collection of them you are either going to have to define a bunch of different media types like application/haptic-vibration, application/haptic-torque, application/haptic-acceleration, or you will need a grouping mechanism for them. Since RFC 6838 still allows for the creation of top-level types, it provides a fairly sensible grouping mechanism and using it reflects just how different these signals are from auditory, visual, or textual resources. The text on this is: In some cases, a new media type may not "fit" under any currently defined top-level type names. Such cases are expected to be quite rare. However, if such a case does arise, a new type name can be defined to accommodate it. Definition of a new top-level type name MUST be done via a Standards Track RFC; no other mechanism can be used to define additional type names. It is my personal opinion that haptic signals do not "fit" under any currently definited top-level type name and that putting them under application as a catch-all will result in either needless pointers to specific applications or a collection of types which would be better organized under a new top-level. In other words, I think that haptics fit the criteria here and that the next step would be to produce the Standards Track RFC suitable for defining a top level type. The bottom line is that while there are legitimate arguments to be made in > support of defining a new top-level type rather than just using > "application", > this isn't one of them. > > > If we agree with that core proposition, > > The core proposition isn't now and never has been the issue. > > > than incorporating haptic signals > > into the media types and other aspects of media processing that are under > > the aegis of the IETF is the right thing to do, > > The goal of the media types registry is to allow for the registration of > anything that functions as a media type, the (very limited) requirements > for > which are given in RFC 6838 section 4.1. I interpret that section as not > only > saying that media types for novel sorts of data not only are allowed, they > can't > be rejected, and I have implemented that interpretation for 20+ years. > > I can only recall one recent case where I rejected an application for not > meeting the criteria for a media type, and that was when someone was > attempting > to register a media type name for something that in fact was an entire > protocol > suite. > > Speaking as one of the media type reviewers, it's my assesment that a > well-defined format for haptic signals currently qualifies for registration > under "application". And had an application been made for the various > haptics > subtypes under the "application" tree, they would almost certainly be > registered > by now. > > > and the time to start that > > work is now, when it is still possible to have the aspects of the system > > handled elsewhere adjusted more readily. Waiting until that work is > > completed strikes me as what I grew up hearing called "the wrong > mistake". > > Well, so far your arguments here strike me as what I grew hearing called > "not > even wrong". > > > We could also, of course, ignore the work and that proposition. > > Again, the only issue we are concerned with here is whether or not a new > top-level type is warranted. Not whether or not haptics stream can be > registered > as media types. So let's please stop claiming that this is part of the > problem. > > > The likely > > outcomes of that, in my hazy crystal ball, is either that the relevant > work > > will create a MIME-like system that looks like but isn't quite actually > > MIME (which means that all of the other media types which are consumed by > > that system will have to deal with being part of two subtly different > > systems) or that deployed systems will squat on a string in a way that > > simply routes around our registry and rules. I am sure you can supply > the > > examples which lead me to that conclusion pretty readily. > > I have no crystal ball of any sort, but this is an argument I've heard many > times before: Bad things will happen if we don't bend our process to > accommodate > whatever. > > And I have the same problem I always have with such claims: Our process is > perfectly adequate to deal with the matter. This is a misrepresentation of my position. I am not asking that we not use our process; I am asking that we *do* use it by assigning or forming a working group for the work (The ADs having ruled out AD-sponsorship, as is their prerogative). Right now nothing seems to be > preventing this work from going forward other than your insistence on it > being > done your way. > This is neither helpful nor accurate. I am not an author of this work; I responded to an AD request for review and commentary, and I have provided both, citing each time that it was my personal opinion. I stand by those opinions, of course, but this matter is up to the community. best, Ted Hardie > > I have not replied to your proposal below to cede the territory to > another > > body, simply because I think a major point of any effort in this space is > > how multimedia works rather than how single-medium signals are consumed. > > That being the case, I don't think we can cede without ceding much more > of > > the multimedia landscape than I think you intended. > > The mechansism for handing off registration responsibilites to another > organization is actually to define a new registration tree (RFC 6838 > section > 3.5). The specification is silent as to whether responsibility for a > top-level > type can be handed off to a different organization, which I guess means it > could > be via a standards action. But this would be a very big step indeed. If > haptics > types for some reason required expertise beyond that required for media > type > reviews currently, I would think the better way to do it would be for IANA > to > find a different set of reviewers with the necessary expertise. > > This doesn't mean there aren't issues with defining a new top-level type > that > have to be dealt with. There most certainly are. But instead of looking at > those, I'm responding to arguments which, frankly, are rather more > FUD-like than > I care for. > > Ned > --0000000000001c212605c19148e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responses in-line.

On Tue, May 4, 2021= at 8:02 PM Ned Freed <ned.free= d@mrochek.com> wrote:
> I believe the issue here isn't the state of the stand= ards-making in another
> body but the core proposition of the effort:=C2=A0 haptic signals are = media.
> There are a lot of consequences of that core proposition, the most
> important of which for me are that these signals can be bound with oth= er
> media into coherent multimedia resources and that we can build
> interoperable standards that allow both haptic media and these multime= dia
> resources to be handled by any compliant systems that follow that
> standard.=C2=A0 (The other obvious way to model them, as application > instructions, leaves us in a very different place).

This statement appears to be based on a misunderstanding of the semantics o= f the
"application" top level media type.

The use of the application top-level type in not limited to content consist= ing
of, or which is modeled as, "application instructions".=C2=A0
This is clearly stated in RFC 6838 section 4.2.5:

=C2=A0 =C2=A0The "application" top-level type is to be used for d= iscrete data that
=C2=A0 =C2=A0do not fit under any of the other type names, and particularly= for
=C2=A0 =C2=A0data to be processed by some type of application program.=C2= =A0

Applications process media streams all the time, so even the second part of= this
in no way prohibits the use of application for media that doesn't fit u= nder
"audio" or "video" - as haptics clearly does not - and = which is modeled
as a media stream.

Now, you may not like the fact that "application" was chosen to b= e the name for
the catch-all top-level type. Truth be told, I don't much care for it e= ither.
But at the time this stuff was decided, this was the best we could come up<= br> with.

I think it is more this bit that I find telling for t= he current case:

   T=
he subtype of "application" will often either be the name or incl=
ude
   part of the name of the application for which the data are intended.
   This does not mean, however, that any application program name may
   simply be used freely as a subtype of "application"; the subty=
pe
   needs to be registered.
Using this approach to naming would mire the inclusion of = haptic signals in pointers to specific applications, where the value is in = defining the methods so that they can be consumed by any compliant applicat= ion.=C2=A0 If there were a single haptic signal then application/haptic mig= ht well work, but with a collection of them you are either going to have to= define a bunch of different media types like application/haptic-vibration,= application/haptic-torque, application/haptic-acceleration, or you will ne= ed a grouping mechanism for them.=C2=A0 Since RFC 6838 still allows for the= creation of top-level types, it provides a fairly sensible grouping mechan= ism and using it reflects just how different these signals are from auditor= y, visual, or textual resources.=C2=A0 The text on this is:

<= /div>
   In some cases, a new media type m=
ay not "fit" under any currently
   defined top-level type names.  Such cases are expected to be quite
   rare.  However, if such a case does arise, a new type name can be
   defined to accommodate it.  Definition of a new top-level type name
   MUST be done via a Standards Track RFC; no other mechanism can be
   used to define additional type names.
It is my personal opinion that haptic signals do not "= ;fit" under any currently definited top-level type name and that putti= ng them under application as a catch-all will result in either needless poi= nters to specific applications or a collection of types which would be bett= er organized under a new top-level. In other words, I think that haptics fi= t the criteria here and that the next step would be to produce the Standard= s Track RFC suitable for defining a top level type.

The bottom line is that while there are legitimate arguments to be made in<= br> support of defining a new top-level type rather than just using "appli= cation",
this isn't one of them.

> If we agree with that core proposition,

The core proposition isn't now and never has been the issue.

> than incorporating haptic signals
> into the media types and other aspects of media processing that are un= der
> the aegis of the IETF is the right thing to do,

The goal of the media types registry is to allow for the registration of anything that functions as a media type, the (very limited) requirements fo= r
which are given in RFC 6838 section 4.1. I interpret that section as not on= ly
saying that media types for novel sorts of data not only are allowed, they = can't
be rejected, and I have implemented that interpretation for 20+ years.

I can only recall one recent case where I rejected an application for not meeting the criteria for a media type, and that was when someone was attemp= ting
to register a media type name for something that in fact was an entire prot= ocol
suite.

Speaking as one of the media type reviewers, it's my assesment that=C2= =A0 a
well-defined format for haptic signals currently qualifies for registration=
under "application". And had an application been made for the var= ious haptics
subtypes under the "application" tree, they would almost certainl= y be registered
by now.

> and the time to start that
> work is now, when it is still possible to have the aspects of the syst= em
> handled elsewhere adjusted more readily.=C2=A0 Waiting until that work= is
> completed strikes me as what I grew up hearing called "the wrong = mistake".

Well, so far your arguments here strike me as what I grew hearing called &q= uot;not
even wrong".

> We could also, of course, ignore the work and that proposition.

Again, the only issue we are concerned with here is whether or not a new top-level type is warranted. Not whether or not haptics stream can be regis= tered
as media types. So let's please stop claiming that this is part of the<= br> problem.

> The likely
> outcomes of that, in my hazy crystal ball, is either that the relevant= work
> will create a MIME-like system that looks like but isn't quite act= ually
> MIME (which means that all of the other media types which are consumed= by
> that system will have to deal with being part of two subtly different<= br> > systems) or that deployed systems will squat on a string in a way that=
> simply routes around our registry and rules.=C2=A0 I am sure you can s= upply the
> examples which lead me to that conclusion pretty readily.

I have no crystal ball of any sort, but this is an argument I've heard = many
times before: Bad things will happen if we don't bend our process to ac= commodate
whatever.

And I have the same problem I always have with such claims: Our process is<= br> perfectly adequate to deal with the matter.

This is a misrepresentation of my position.=C2=A0 I am not asking that we = not use our process; I am asking that we *do* use it by assigning or formin= g a working group for the work (The ADs having ruled out AD-sponsorship, as= is their prerogative).

Right now nothing seems to be
preventing this work from going forward other than your insistence on it be= ing
done your way.

=
This is neither helpful nor accurate. I am not a= n author of this work; I responded to an AD request for review and commenta= ry, and I have provided both, citing each time that it was my personal opin= ion.=C2=A0 I stand by those opinions, of course, but this matter is up to t= he community.=C2=A0

best,

Ted Hardie


> I have not replied to your proposal below to cede the territory to ano= ther
> body, simply because I think a major point of any effort in this space= is
> how multimedia works rather than how single-medium signals are consume= d.
> That being the case, I don't think we can cede without ceding much= more of
> the multimedia landscape than I think you intended.

The mechansism for handing off registration responsibilites to another
organization is actually to define a new registration tree (RFC 6838 sectio= n
3.5). The specification is silent as to whether responsibility for a top-le= vel
type can be handed off to a different organization, which I guess means it = could
be via a standards action. But this would be a very big step indeed. If hap= tics
types for some reason required expertise beyond that required for media typ= e
reviews currently, I would think the better way to do it would be for IANA = to
find a different set of reviewers with the necessary expertise.

This doesn't mean there aren't issues with defining a new top-level= type that
have to be dealt with. There most certainly are. But instead of looking at<= br> those, I'm responding to arguments which, frankly, are rather more FUD-= like than
I care for.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned
--0000000000001c212605c19148e6-- From nobody Wed May 5 08:14:06 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10CB3A116C; Wed, 5 May 2021 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNjTmzUeOxTN; Wed, 5 May 2021 08:13:59 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B6C3A1168; Wed, 5 May 2021 08:13:59 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYO2T8PT3K00HPR9@mauve.mrochek.com>; Wed, 5 May 2021 07:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620226020; bh=kQMM3e22Mk5bG+YmWcE9ap8Ye0RQvozrL7xecmexANE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=CzZq7+TyhNN0nozO9ahWUKyHI3uFzWh6spXRhS+nGqfwDvd3ROHIkZtYsZyry/iz8 qpmfz5Bi9UAMq+mwrF/FiDiDQmYAjJLGhIuGYl2tieCfW5IAcZc4NEF7n5S8sI7r6n hwC0CV2+TMGyZ0FRyuzbeugBOSWYvUAvB+1A9zKI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Wed, 5 May 2021 07:46:58 -0700 (PDT) Cc: media-types@ietf.org, Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs Message-id: <01RYO2T7CWT80085YQ@mauve.mrochek.com> Date: Wed, 05 May 2021 05:42:10 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 05 May 2021 09:49:41 +0100" References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> <01RYMX921V9K0085YQ@mauve.mrochek.com> To: Ted Hardie Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 15:14:05 -0000 We now appear to have completely switched from discussing how to structure the work on a top-level type proposal to arguing about whether or not a new top-level type has merit. While it's always tempting to correct misconceptions about how media types work, this is neither the time nor the place to honor this "call to duty": https://xkcd.com/386/ As such, this will be my final message reponding to specific media type issues until we decide how we're going to do the work. > > I think it is more this bit that I find telling for the current case: > The subtype of "application" will often either be the name or include > part of the name of the application for which the data are intended. > This does not mean, however, that any application program name may > simply be used freely as a subtype of "application"; the subtype > needs to be registered. > Using this approach to naming would mire the inclusion of haptic signals in > pointers to specific applications, where the value is in defining the > methods so that they can be consumed by any compliant application. In which case, don't use the approach! Do you see any requirements language in the text you quoted? I don't. What I see is the word "often", and in practice the majority of media types do *not* use this approach, and more to the point, do not appear to have been tainted by it. This even includes proprietary single-vendor types, because these days vendors often have multiple applications using the same type. Additionally, the types that seem to be the concern here seem to be ones in the standards tree, where the only time this sort of name alignment happens is by happenstance: The name of the type happens to align with the name of someone's application. > If there were a single haptic signal then application/haptic might well work, > but with a collection of them you are either going to have to define a > bunch of different media types like application/haptic-vibration, > application/haptic-torque, application/haptic-acceleration, or you will > need a grouping mechanism for them. The names you have chosen here assume that there's a single haptics format for each type of signal. This is almost certainly a bad idea. Of course nothing prevents us from encoding the grouping in the subtype name, and if this information really needs to be extractable, this is the way to do it. However, if you want to do this you also need some way to tell applications to look for the grouping - saying that the presence of a particular word or phrase in a arbitrary subtype name is also a bad idea. And this brings us - finally - to a reason to make this a top-level type. The current draft mentions this in section 2.2, but doesn't actually define such a convention. Not only does saying such a convention could be defined but not actually defining essentially nullify the point, the convention needs to be in place - and used - from the start. > Since RFC 6838 still allows for the > creation of top-level types, it provides a fairly sensible grouping > mechanism and using it reflects just how different these signals are from > auditory, visual, or textual resources. The text on this is: > In some cases, a new media type may not "fit" under any currently > defined top-level type names. Such cases are expected to be quite > rare. However, if such a case does arise, a new type name can be > defined to accommodate it. Definition of a new top-level type name > MUST be done via a Standards Track RFC; no other mechanism can be > used to define additional type names. > It is my personal opinion that haptic signals do not "fit" under any > currently definited top-level type name and that putting them under > application as a catch-all will result in either needless pointers to > specific applications There is not now, nor has there ever been, a requirement for such pointers. Some registrations find it helpful to provide a list of applications that use the type, but many do not, and almost never in the case of standards tree registrations. > or a collection of types which would be better > organized under a new top-level. In other words, I think that haptics fit > the criteria here and that the next step would be to produce the Standards > Track RFC suitable for defining a top level type. I don't find this argument even close to persuasive, but that's beside the point: I'm not the person you need to convince and neither are the other people reading this message. You also appear to assume I'm against the creation of a top level type. Not that my personal opinion matters a jot, but I'm actually in favor of it. But having been through this process several times, I can tell you that not everyone will be in favor, and you *really* need to have your ducks in a row to succeed, even more so if you expect to do so in any sort of reasonable time frame. > This is a misrepresentation of my position. I am not asking that we not > use our process; I am asking that we *do* use it by assigning or forming a > working group for the work (The ADs having ruled out AD-sponsorship, as is > their prerogative). No, what you asked for is a separate working to do this work indepenent from other media types work. And you appear to be alone in wanting this. > > Right now nothing seems to be > > preventing this work from going forward other than your insistence on it > > being done your way. > This is neither helpful nor accurate. On the contrary, it's both accurate and cuts to the heart of the matter. You have made a number of assertions here, including but not limited to: (1) A working chartered to do general media type work would be unable to prioritize this work, and will instead be distracted by other work items. (2) There are various semantics attached to the application top-level type that either preclude registration of haptics types under it or force them to use a nonsensical semantic model. I have refuted these claims; instead of countering you have in every case pivoted to different arguments. Ned From nobody Wed May 5 08:32:03 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86AA3A1228; Wed, 5 May 2021 08:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QisCPehSHNT; Wed, 5 May 2021 08:31:57 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F133A1269; Wed, 5 May 2021 08:31:56 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id z3so1320554oib.5; Wed, 05 May 2021 08:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SYvM+Y6vCbCiRA4WftGE05JhbRQpXL9AqA85jjnp1iE=; b=eKca0BxdYPyYv1NFfymKtB1s474gUrB2Bc7NrY1O7XfesliGbd0Y1ZbIof18ToPcip A2NUdiTacS23ZTNXkoe/h4MXKag3ihtFtVwGkqJNHJBJKGHDjwAia7I5/NzoeT5k4lOF P11V5MmGY9Rb02DTJTr4o4FWKtGyepAek9TlIiW83h7eGqc+V4boqyj5JxYAaBmW30Ox xv39opQ6OxOooyiMqljj4UegXkEG0LVC6LP6bBGYHj/cNrq32vFnN3PX7SRWbMWT94+W KiXhN2QOkqRSvYERJOeDXzU6eO8Y3Ps65EnkwgPnIBoSWdik1AF4o6C5lWMvDvDNcq3I gpfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SYvM+Y6vCbCiRA4WftGE05JhbRQpXL9AqA85jjnp1iE=; b=m8hA3fINUx+6uC5I2T+H1daHk1IeZZCje+GLzg55XV34TlPNCdeYzZrkGO2WWPShuw jONisorM3OxVWxeQVyTfvftp9LDlkV/6IOgbo9y94uoIDp+1/+t5O8pKZSJXgCtT1RPY GqLmWl0f3JzJ0AdFigSf84bkfInRMvKNmrpZErq3OvVjJsZ0A2uqDdhaU6J9R4ISZbzX ckTb3sY6VaDNZcky/IkxqrrydH3Nruw3H/tawteRO/NgS0ltUOneM2L+AtA/EBITDJcE GrMptnoyozXLVv4E6j7PdRRLimd4LKJDcUOrl8+pnqze6jFIsRviuI6cYEf+ucsiEo7J 3GLg== X-Gm-Message-State: AOAM531tpOOniHVwJqcCEZb+M3NEQVfkR3NGojB5yNE+qc8zspSpxh31 sRT8dZ+t0JJn7ywZ/jQhp/ujA2Ymbu4DEsjTVF0= X-Google-Smtp-Source: ABdhPJxrTSBvELEYEgw4Fi9219AIH7TgeAV4dNmdXaS7cN08IhXY+AVlOY31gv0HqRuJpLQ7avJPyGrZV6zw+h6ecy4= X-Received: by 2002:aca:6701:: with SMTP id z1mr7061773oix.167.1620228714899; Wed, 05 May 2021 08:31:54 -0700 (PDT) MIME-Version: 1.0 References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> <01RYMX921V9K0085YQ@mauve.mrochek.com> <01RYO2T7CWT80085YQ@mauve.mrochek.com> In-Reply-To: <01RYO2T7CWT80085YQ@mauve.mrochek.com> From: Ted Hardie Date: Wed, 5 May 2021 16:31:28 +0100 Message-ID: To: Ned Freed Cc: media-types@ietf.org, Dispatch WG , dispatch-chairs@ietf.org, Applications and Real-Time Area Discussion , ART ADs Content-Type: multipart/alternative; boundary="00000000000001aaea05c196e5d4" Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 15:32:02 -0000 --00000000000001aaea05c196e5d4 Content-Type: text/plain; charset="UTF-8" Ned, In your final response, you cut an important piece of what I had said, so I restore it here: Right now nothing seems to be >> preventing this work from going forward other than your insistence on it >> being >> done your way. >> > > This is neither helpful nor accurate. I am not an author of this work; I > responded to an AD request for review and commentary, and I have provided > both, citing each time that it was my personal opinion. I stand by those > opinions, of course, but this matter is up to the community. > > best, > > Ted Hardie > It is severely discourteous to chop off a statement in which I highlighted that I was giving a personal opinion and would go with the community decision. I understand that you don't agree with my opinion (and, unsurprisingly, I also don't agree with yours), but I am willing to go forward in any way that the community agrees will make progress, even if it is not the way I would personally consider optimal. I am not getting an impression of the same willingness from you, so it might be best if you stated outright whether you are willing to go with the community consensus on this. We can then leave it up to the ADs to judge that consensus. Hopefully they have more input than you, me, and John, despite the volume of the recent exchanges among us; after all, none of us is likely to do the bulk of the work in the eventual group. Ted Hardie > On Wed, May 5, 2021 at 3:52 PM Ned Freed wrote: > We now appear to have completely switched from discussing how to structure > the > work on a top-level type proposal to arguing about whether or not a new > top-level type has merit. While it's always tempting to correct > misconceptions > about how media types work, this is neither the time nor the place to > honor this > "call to duty": > > https://xkcd.com/386/ > > As such, this will be my final message reponding to specific media type > issues > until we decide how we're going to do the work. > > > > I think it is more this bit that I find telling for the current case: > > > The subtype of "application" will often either be the name or include > > part of the name of the application for which the data are intended. > > This does not mean, however, that any application program name may > > simply be used freely as a subtype of "application"; the subtype > > needs to be registered. > > > Using this approach to naming would mire the inclusion of haptic signals > in > > pointers to specific applications, where the value is in defining the > > methods so that they can be consumed by any compliant application. > > In which case, don't use the approach! Do you see any requirements > language in > the text you quoted? I don't. What I see is the word "often", and in > practice > the majority of media types do *not* use this approach, and more to the > point, > do not appear to have been tainted by it. > > This even includes proprietary single-vendor types, because these days > vendors > often have multiple applications using the same type. > > Additionally, the types that seem to be the concern here seem to be ones > in the > standards tree, where the only time this sort of name alignment happens is > by > happenstance: The name of the type happens to align with the name of > someone's > application. > > > If there were a single haptic signal then application/haptic might well > work, > > but with a collection of them you are either going to have to define a > > bunch of different media types like application/haptic-vibration, > > application/haptic-torque, application/haptic-acceleration, or you will > > need a grouping mechanism for them. > > The names you have chosen here assume that there's a single haptics format > for > each type of signal. This is almost certainly a bad idea. > > Of course nothing prevents us from encoding the grouping in the subtype > name, > and if this information really needs to be extractable, this is the way to > do > it. > > However, if you want to do this you also need some way to tell > applications to > look for the grouping - saying that the presence of a particular word or > phrase > in a arbitrary subtype name is also a bad idea. > > And this brings us - finally - to a reason to make this a top-level type. > The > current draft mentions this in section 2.2, but doesn't actually define > such a > convention. Not only does saying such a convention could be defined but not > actually defining essentially nullify the point, the convention needs to be > in place - and used - from the start. > > > Since RFC 6838 still allows for the > > creation of top-level types, it provides a fairly sensible grouping > > mechanism and using it reflects just how different these signals are from > > auditory, visual, or textual resources. The text on this is: > > > In some cases, a new media type may not "fit" under any currently > > defined top-level type names. Such cases are expected to be quite > > rare. However, if such a case does arise, a new type name can be > > defined to accommodate it. Definition of a new top-level type name > > MUST be done via a Standards Track RFC; no other mechanism can be > > used to define additional type names. > > > It is my personal opinion that haptic signals do not "fit" under any > > currently definited top-level type name and that putting them under > > application as a catch-all will result in either needless pointers to > > specific applications > > There is not now, nor has there ever been, a requirement for such > pointers. Some registrations find it helpful to provide a list of > applications that use the type, but many do not, and almost never > in the case of standards tree registrations. > > > or a collection of types which would be better > > organized under a new top-level. In other words, I think that haptics fit > > the criteria here and that the next step would be to produce the > Standards > > Track RFC suitable for defining a top level type. > > I don't find this argument even close to persuasive, but that's beside the > point: I'm not the person you need to convince and neither are the other > people > reading this message. > > You also appear to assume I'm against the creation of a top level type. > Not that > my personal opinion matters a jot, but I'm actually in favor of it. But > having > been through this process several times, I can tell you that not everyone > will > be in favor, and you *really* need to have your ducks in a row to succeed, > even > more so if you expect to do so in any sort of reasonable time frame. > > > This is a misrepresentation of my position. I am not asking that we not > > use our process; I am asking that we *do* use it by assigning or forming > a > > working group for the work (The ADs having ruled out AD-sponsorship, as > is > > their prerogative). > > No, what you asked for is a separate working to do this work indepenent > from > other media types work. And you appear to be alone in wanting this. > > > > Right now nothing seems to be > > > preventing this work from going forward other than your insistence on > it > > > being done your way. > > > This is neither helpful nor accurate. > > On the contrary, it's both accurate and cuts to the heart of the matter. > > You have made a number of assertions here, including but not limited to: > > (1) A working chartered to do general media type work would be unable > to prioritize this work, and will instead be distracted by other > work items. > > (2) There are various semantics attached to the application top-level > type that either preclude registration of haptics types under it or > force them to use a nonsensical semantic model. > > I have refuted these claims; instead of countering you have in every case > pivoted to different arguments. > > Ned > --00000000000001aaea05c196e5d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ned,

In you= r final response, you cut an important piece of what I had said, so I resto= re it here:

Right now nothing seems to be
preventing this work from going forward other than your insistence on it be= ing
done your way.
This is neither helpful nor accurate. I am not an author of this work; I=20 responded to an AD request for review and commentary, and I have=20 provided both, citing each time that it was my personal opinion.=C2=A0 I=20 stand by those opinions, of course, but this matter is up to the=20 community.=C2=A0

best,

Ted Hardie

It is severely discourteous to chop off a statement in which I highligh= ted that I was giving a personal opinion and would go with the community de= cision.=C2=A0

I under= stand that you don't agree with my opinion (and, unsurprisingly, I also= don't agree with yours), but I am willing to go forward in any way tha= t the community agrees will make progress, even if it is not the way I woul= d personally consider optimal.=C2=A0=C2=A0 I am not getting an impression o= f the same willingness from you, so it might be best if you stated outright= whether you are willing to go with the community consensus on this.=C2=A0 = We can then leave it up to the ADs to judge that consensus.=C2=A0

Hopefully they have more input= than you, me, and John, despite the volume of the recent exchanges among u= s; after all, none of us is likely to do the bulk of the work in the eventu= al group.

Ted Hardie

=C2=A0

<= div class=3D"gmail_quote">
On Wed, May= 5, 2021 at 3:52 PM Ned Freed <= ned.freed@mrochek.com> wrote:
We now appear to have completely switched from discuss= ing how to structure the
work on a top-level type proposal to arguing about whether or not a new
top-level type has merit. While it's always tempting to correct misconc= eptions
about how media types work, this is neither the time nor the place to honor= this
"call to duty":

=C2=A0 =C2=A0 https://xkcd.com/386/

As such, this will be my final message reponding to specific media type iss= ues
until we decide how we're going to do the work.

> > I think it is more this bit that I find telling for the current c= ase:

>=C2=A0 =C2=A0 The subtype of "application" will often either = be the name or include
>=C2=A0 =C2=A0 part of the name of the application for which the data ar= e intended.
>=C2=A0 =C2=A0 This does not mean, however, that any application program= name may
>=C2=A0 =C2=A0 simply be used freely as a subtype of "application&q= uot;; the subtype
>=C2=A0 =C2=A0 needs to be registered.

> Using this approach to naming would mire the inclusion of haptic signa= ls in
> pointers to specific applications, where the value is in defining the<= br> > methods so that they can be consumed by any compliant application.

In which case, don't use the approach! Do you see any requirements lang= uage in
the text you quoted? I don't. What I see is the word "often",= and in practice
the majority of media types do *not* use this approach, and more to the poi= nt,
do not appear to have been tainted by it.

This even includes proprietary single-vendor types, because these days vend= ors
often have multiple applications using the same type.

Additionally, the types that seem to be the concern here seem to be ones in= the
standards tree, where the only time this sort of name alignment happens is = by
happenstance: The name of the type happens to align=C2=A0 with the name of = someone's
application.

> If there were a single haptic signal then application/haptic might wel= l work,
> but with a collection of them you are either going to have to define a=
> bunch of different media types like application/haptic-vibration,
> application/haptic-torque, application/haptic-acceleration, or you wil= l
> need a grouping mechanism for them.

The names you have chosen here assume that there's a single haptics for= mat for
each type of signal. This is almost certainly a bad idea.

Of course nothing prevents us from encoding the grouping in the subtype nam= e,
and if this information really needs to be extractable, this is the way to = do
it.

However, if you want to do this you also need some way to tell applications= to
look for the grouping - saying that the presence of a particular word or ph= rase
in a arbitrary subtype name is also a bad idea.

And this brings us - finally - to a reason to make this a top-level type. T= he
current draft mentions this in section 2.2, but doesn't actually define= such a
convention. Not only does saying such a convention could be defined but not=
actually defining essentially nullify the point, the convention needs to be=
in place - and used - from the start.

> Since RFC 6838 still allows for the
> creation of top-level types, it provides a fairly sensible grouping > mechanism and using it reflects just how different these signals are f= rom
> auditory, visual, or textual resources.=C2=A0 The text on this is:

>=C2=A0 =C2=A0 In some cases, a new media type may not "fit" u= nder any currently
>=C2=A0 =C2=A0 defined top-level type names.=C2=A0 Such cases are expect= ed to be quite
>=C2=A0 =C2=A0 rare.=C2=A0 However, if such a case does arise, a new typ= e name can be
>=C2=A0 =C2=A0 defined to accommodate it.=C2=A0 Definition of a new top-= level type name
>=C2=A0 =C2=A0 MUST be done via a Standards Track RFC; no other mechanis= m can be
>=C2=A0 =C2=A0 used to define additional type names.

> It is my personal opinion that haptic signals do not "fit" u= nder any
> currently definited top-level type name and that putting them under > application as a catch-all will result in either needless pointers to<= br> > specific applications

There is not now, nor has there ever been, a requirement for such
pointers. Some registrations find it helpful to provide a list of
applications that use the type, but many do not, and almost never
in the case of standards tree registrations.

> or a collection of types which would be better
> organized under a new top-level. In other words, I think that haptics = fit
> the criteria here and that the next step would be to produce the Stand= ards
> Track RFC suitable for defining a top level type.

I don't find this argument even close to persuasive, but that's bes= ide the
point: I'm not the person you need to convince and neither are the othe= r people
reading this message.

You also appear to assume I'm against the creation of a top level type.= Not that
my personal opinion matters a jot, but I'm actually in favor of it. But= having
been through this process several times, I can tell you that not everyone w= ill
be in favor, and you *really* need to have your ducks in a row to succeed, = even
more so if you expect to do so in any sort of reasonable time frame.

> This is a misrepresentation of my position.=C2=A0 I am not asking that= we not
> use our process; I am asking that we *do* use it by assigning or formi= ng a
> working group for the work (The ADs having ruled out AD-sponsorship, a= s is
> their prerogative).

No, what you asked for is a separate working to do this work indepenent fro= m
other media types work. And you appear to be alone in wanting this.

> > Right now nothing seems to be
> > preventing this work from going forward other than your insistenc= e on it
> > being done your way.

> This is neither helpful nor accurate.

On the contrary, it's both accurate and cuts to the heart of the matter= .

You have made a number of assertions here, including but not limited to:
(1) A working chartered to do general media type work would be unable
=C2=A0 =C2=A0 to prioritize this work, and will instead be distracted by ot= her
=C2=A0 =C2=A0 work items.

(2) There are various semantics attached to the application top-level
=C2=A0 =C2=A0 type that either preclude registration of haptics types under= it or
=C2=A0 =C2=A0 force them to use a nonsensical semantic model.

I have refuted these claims; instead of countering you have in every case pivoted to different arguments.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned
--00000000000001aaea05c196e5d4-- From nobody Wed May 5 12:14:17 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FAF3A1D59; Wed, 5 May 2021 12:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lb6Vv2EAXxu; Wed, 5 May 2021 12:14:02 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54E33A1D53; Wed, 5 May 2021 12:14:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYO9J9Z3OW00D2CX@mauve.mrochek.com>; Wed, 5 May 2021 10:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620237587; bh=y49FyPavjTJSvTfyyCseBXcSqLqSTW3E4ceF0Jimb/I=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=WLwYntKd9kvhcB+aKSh14UGcBA6IPCKB18NKB7GB+jLqD0GPLUxz+mdyt/OCszfrD s//zPFDZYjmT0VbRpjbNtcwhPyIA2lZDCFikKu3vjyLB4gUnpgAKaqrI4TJyTUkIgo 0Shd/sEYmt8QC3+L9QUUZn9bppNvU9TE92BH+vd0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Wed, 5 May 2021 10:59:44 -0700 (PDT) Cc: Ned Freed , media-types@ietf.org, Applications and Real-Time Area Discussion , ART ADs , Dispatch WG , dispatch-chairs@ietf.org Message-id: <01RYO9J7M59Y0085YQ@mauve.mrochek.com> Date: Wed, 05 May 2021 09:01:14 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 05 May 2021 16:31:28 +0100" References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> <01RYMX921V9K0085YQ@mauve.mrochek.com> <01RYO2T7CWT80085YQ@mauve.mrochek.com> To: Ted Hardie Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 19:14:07 -0000 It would a severe understatment to say I'm flabbergasted by this. > In your final response, you cut an important piece of what I had said, so I > restore it here: > Right now nothing seems to be > >> preventing this work from going forward other than your insistence on it > >> being > >> done your way. > >> > > > > This is neither helpful nor accurate. I am not an author of this work; I > > responded to an AD request for review and commentary, and I have provided > > both, citing each time that it was my personal opinion. I stand by those > > opinions, of course, but this matter is up to the community. > > > > best, > > > > Ted Hardie > > > It is severely discourteous to chop off a statement in which I highlighted > that I was giving a personal opinion and would go with the community > decision. Unless you have a special status relevant to this effort that I'm unaware of, everything you say here is a personal opinion. (And so is everything I say, because I have no special status here either: The fact that some of my comments are based on my experience as a media type reviewer may give them a bit of additional weight, but doesn't give them any special status.) Anyone who fails to evaluate your or my comments just as critically as one coming from a first time poster isn't doing it right. As for "going along with the community decision", since I don't know what it means to not go along with it - more on that below - I assign zero weight to the statement. I therefore reject, absolutely and completely, your assertion that it was severely discourteous to remove this text. More generally, as far as trimming material goes, my eyesight happens to be complete crap, and as a result I find it very difficult to pick out the relevant material from a sea of nested replies. (And for some reason I find trailing text to be especially distacting - I'm not sure why.) As a result I tend to be very aggressive in cutting material out of messages - and that's the reason I removed what I believe to have been irrelevant text. That said, in some circumstances this may result in context that would have aided someone else being lost - although I don't see that as being the case here. But I'm afraid I have little choice but to assign higher priority to my own ability to participate effectively than to the possibility of inconveniencing someone else. > I understand that you don't agree with my opinion (and, unsurprisingly, I > also don't agree with yours), but I am willing to go forward in any way > that the community agrees will make progress, even if it is not the way I > would personally consider optimal. I am not getting an impression of the > same willingness from you, so it might be best if you stated outright > whether you are willing to go with the community consensus on this. We can > then leave it up to the ADs to judge that consensus. I'm completely at a loss as to what your concern is here. What, exactly, would it mean for me - or anyone else - to not be "willing to go along with the consensus"? Throw a fit? Pray for divine intevention? File an entirely groundless appeal in hopes of gumming up the works? Go into a funk, pout, pick up my marbles, and refuse to participate? And even if I did choose to behave in such a grossly unprofessional manner, so what? I'm conceited enough to think my personal opinions have sufficient value to be worth posting, but nowhere near conceited enough to believe that they are so special and precious that they are even close to being essential to this effort's success. And perhaps more to the point, I've been actively involved in the IETF since 1989, and during that time I've been on the losing side of far more consequential decisions than this more times than I can even count. This includes quite a few cases where, unlike here, I actually had significant skin in the game. Exactly when did my past behavior give you cause to think I would even consider doing something along these lines? In any case, since you seem to require assurance on this point, the answer is I have no problem if the ADs decide to charter two working groups. I would have a problem with five... but that seems unlikely. > Hopefully they have more input than you, me, and John, despite the volume > of the recent exchanges among us; after all, none of us is likely to do the > bulk of the work in the eventual group. Well, maybe you don't plan on doing significant work in the group or groups, but I most certainly do: I have every intention of providing feedback on all of the drafts associated with my media types to-do list, and as I previously stated, I have every intention of authoring or coauthoring at least one and possibly more of the drafts themselves. And to once more assuage your concerns: It won't matter to me in the slightest if this work happens in one or two groups. Ned From nobody Thu May 6 00:53:30 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8305B3A169B for ; Thu, 6 May 2021 00:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUHRLurcteLX for ; Thu, 6 May 2021 00:53:21 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1D73A169E for ; Thu, 6 May 2021 00:53:21 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id a24so2484155vso.4 for ; Thu, 06 May 2021 00:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/HwBZyG02aXVHYKELjeJMmBt9HTYIoAEOpe8AznSZnc=; b=em1WS5EtNyTnZ0ZsU7GLCpBfkHrMuBhrpnawpUzCi52DLQ2W9WjHhVVxk0HFOznA1J mrjhr/5M0KNRIwWrqgI4XcDKUo/NO+b927ZrI7R1ArOz2d970qiYAKWj/YIwouhCYoT7 m+JpC0U+CSIf0KQQLSfqDgtsZADAWb83TZ45lxbxIgyymHm/pbZg7a8+9w6uyEsIxAKU ZnjKcbgBh4cLh9vT/8gZCtZEOQYG9alImLJFYc+davY572jQ4vPsB1vcYLpTOgS5wTMH dMYL3e238H3WY17Sv+GFsBUKkj/r9wI8v/9IgPscnrRU03rHyAWqCHlF6dVl887QW1ZZ B5Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/HwBZyG02aXVHYKELjeJMmBt9HTYIoAEOpe8AznSZnc=; b=OWqiti1l+ROmPWFdolHYeK6+In1SNZI7s8GyobYmGYUVm8VuweFrgprRkY/bPyv1yv EY7cSZGDmbN0q9/9c8Uh8Vz8Daf7nfiT84lDDyNd6MXrWDT4c5SY3M6mE6Z47jQO6CnH r460iIebj6OI/a5WXj/6Q9Xj5mP2Ea75DE0HPI7Qo4ZdIUVI+M7ETvqNSnIWqQ2waYt1 gWI6wYn+QOzOw+x/8fIlyA5YXgboaxALLa2i70H/gEhTcmmhh43bhytfJmDmCJNvcJZA P9GmUsvE69uHY2EylzFNpD/ECGkwfyxHc1CW69WykX5MfK4lOlb7XiOJ4FlUvee1GrDW u9+Q== X-Gm-Message-State: AOAM531NpkfgBr6SAsM3MpArDm4+dLzixProyYi6Pvt1RDstyfINrQTU FT3J64P7JDM+pIRVyK6HY2I0xYL8YUd4oFgjIVY= X-Google-Smtp-Source: ABdhPJzsrpmj3Ujxvn0rucu0Ced0/rfwePWroFUJ6yIl2iEGy1sxu2DXWRFHMuNsaEIbUv3O62kmZaZo5MbHOuJaq7A= X-Received: by 2002:a67:ed4e:: with SMTP id m14mr2120588vsp.40.1620287600371; Thu, 06 May 2021 00:53:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 6 May 2021 00:53:09 -0700 Message-ID: To: James Zern Cc: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000daaa0305c1a49a6a" Archived-At: Subject: Re: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 07:53:27 -0000 --000000000000daaa0305c1a49a6a Content-Type: text/plain; charset="UTF-8" On Thu, Apr 29, 2021 at 7:58 PM James Zern wrote: > It was suggested I post a message here requesting advice on the processing > path of my submission to register the image/webp mime-type [1]. I'm not > familiar with the process, so if you could have a look and see if this is > appropriate for the DISPATCH working group or suggest another I'd > appreciate it. > Just a reminder that DISPATCH's charter includes: "- By agreement with ART ADs, processing simple administrative documents." If we agree that this work fits that description, then that's a processing option here. I would also suggest this be floated by media-types@ietf.org, if that hasn't been done already. -MSK --000000000000daaa0305c1a49a6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 29, 2021 at 7:58 PM James Zer= n <jzern@google.com> wrote:
It was suggested I post a message here requesting advice on= the processing path of my submission to register the image/webp mime-type = [1]. I'm not familiar with the process, so if you could have a look and= see if this is appropriate for the DISPATCH working group or suggest anoth= er I'd appreciate it.

Just a remi= nder that DISPATCH's charter includes:

"- By agreement with= ART ADs, processing simple administrative documents."

<= /div>
If we agree that this work fits that description, then that's= a processing option here.

I would also suggest th= is be floated by media-types@ietf.o= rg, if that hasn't been done already.

= -MSK
--000000000000daaa0305c1a49a6a-- From nobody Thu May 6 12:34:33 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51F03A2DEF; Thu, 6 May 2021 12:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JldgK-5_Yb4f; Thu, 6 May 2021 12:34:18 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8EB3A2DED; Thu, 6 May 2021 12:34:17 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id t6so1044670vsp.13; Thu, 06 May 2021 12:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ajpmPiDPvxbovwewJp/2yAZ+itLXo0sNab8A+PvMRTg=; b=OU2cWAQaaXVXcMWDNkKtSXxvG++qXgzcgNrRSnxG9wBIF59fQhz+kQfyqTJovAFxPb U4HfiZRwePuIN8hU2vVxFzsVRwD5m2Mc6ek5U4HKPvIA22EqLDJWJ8IhsyYFXpUBhosV EmMSliigubb7l7sX/IigrgIf9zRY1n+Zi5yPrTAQgWwbgVnEeW+CrW3gvrIqS1j5fcCB 0ziwU/yid5be93Dt/yexNun8CBgwx02ZUtBacYZ+fyzSIyWz8JsMyCNgFklMunGZ8NN2 03lwu+LRXDh8bFJ4GlhRDTO8zk3gTsOUpYrHF9KHc+qTVObcyeEvT+mqEFUF0/Jy5STP kGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ajpmPiDPvxbovwewJp/2yAZ+itLXo0sNab8A+PvMRTg=; b=QII4ghjasnwWYcUwrJNOqMzWNES5xjMx+Wcseuk8mMZonZ/LVxy8RvZZWRzhSjSmlW xjvTPKc2zSm03FT+giyO1pT/nci/229CqyN81m8NImgXIMB1DAi+J3poBzJRm0pMWOp+ Rvuc3z9wvEY9qh/Li0dcQoQL+uzZ7N+qsobG8se+oE7vov0AJnfwauYGW8sBk1TFutld 72rKa1D5JhVK+2P2DZf3o3UVE6lJel8c8UDk2pCYH04IY9/GlHwayJp6JD3Qstyd44/z 4iPSLrlTOA5tAZR/Hjf150KMAa72JnQQQt2c24aJZ0cmrPTfBAtNKeA+LA0Tbbj+ihpG IlUw== X-Gm-Message-State: AOAM5318/tNYoUn/9ZSlkYwqMXMSjyQmAHRtCWxvPm69C0xVfTWGvhc8 CjIJcesg5W/8jzeAFotozNj6a3hOzTk3pcshVo0= X-Google-Smtp-Source: ABdhPJw+MMRn0V8GRoJW8WO0AsdgkZ3VlYyhy9SdA/FE4C9UeJuBy0FNteXN1fDYncUOoKkAz6dSjwRv0QMI0m5fBL8= X-Received: by 2002:a67:f754:: with SMTP id w20mr2019528vso.54.1620329654718; Thu, 06 May 2021 12:34:14 -0700 (PDT) MIME-Version: 1.0 References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 6 May 2021 12:34:03 -0700 Message-ID: To: John C Klensin Cc: Yeshwant Muthusamy , Ted Hardie , Dispatch WG , dispatch chairs , Applications and Real-Time Area Discussion , ART ADs , draft-muthusamy-dispatch-haptics@ietf.org, media-types@ietf.org Content-Type: multipart/alternative; boundary="0000000000007d134f05c1ae65f8" Archived-At: Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 19:34:24 -0000 --0000000000007d134f05c1ae65f8 Content-Type: text/plain; charset="UTF-8" Hi all, Thanks for this discussion. At a minimum, it reaffirms my decision not to sponsor this myself. :-) Francesca and I talked about it this morning after the IESG call, and decided that I'll take up the pen to write a draft charter based on this thread and circulate it for comments. Stay tuned. -MSK On Tue, May 4, 2021 at 6:16 PM John C Klensin wrote: > Yeshwant, > > Thanks. And thanks for confirming. I think I've said as much > as I can usefully say on the subject. > > best wishes, > john > > > --On Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy > wrote: > > > John, > > > > > > > > Thanks for the note. Taking each one of your two questions in > > order: > > > > > > > >>> * Does the ISO FDIS mention "haptics/" as top-level media > >>> type? > > > >>> If it does, that is a major IETF (and probably IAB) strategy > >>> question, not really a media registration one. > > > >>> And that question includes my concern about precedents of > >>> other SDOs squatting on names without including us actively > >>> in the development process. > > > > > > > > No. The ISOBMFF FDIS does not mention 'haptics/' as top-level > > media type. That said, it treats haptics in exactly the same > > way that it treats other top-level media types in Chapter 12 > > (audio, video, text, font, etc.) that have been recognized as > > top-level media types by IETF. To be more specific, our > > haptics proposal to ISOBMFF follows the same box hierarchy as > > the other top-level types: > > > > * Media handler is 'hapt' > > * Haptic Media Header is the NullMediaHeaderBox > > * Sample entry is the HapticSampleEntry > > > > > > > > So, there is no issue of ISO squatting on the 'haptics/' name > > or shutting IETF out from the development process. Our > > objective was to first introduce haptics as a top-level media > > type in ISOBMFF and then approach IETF with the proposal that > > we have in our I-D. For obvious reasons, I am unable to share > > the DAMD or FDIS documents on this mailing list, but I suspect > > those who are also members of MPEG can get access to it easily. > > > > > > > >>> * If the answer to that is "no", are there objections to > >>> more or less the WG approach Ned suggested that do not rely > >>> on the "influence the work of other SDOs" argument? > > > > > > > > Like I've said before, I am open to whatever mechanism the > > IETF decides to use to move the I-D forward. Given the work > > that has already been done in MPEG and the fact that we are > > approaching the FDIS ballot completion stage, I would assume > > that the IETF would take that into account *in some form* as > > it discusses the technical merits of the I-D. > > > > > > > > Thanks, > > > > Yeshwant > > > > > > > > Yeshwant Muthusamy, Ph.D. | Senior Director, Standards > > > > > > > > ymuthusamy@immersion.com | +1 469-583-2171 > > > > > > > > -----Original Message----- > > From: John C Klensin > > Sent: Tuesday, May 4, 2021 2:12 PM > > To: Yeshwant Muthusamy ; Ted Hardie > > Cc: Dispatch WG ; > > dispatch-chairs@ietf.org; Applications and Real-Time Area > > Discussion ; ART ADs ; > > draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org > > Subject: RE: [art] [dispatch] Status of Haptics I-D in > > DISPATCH? > > > > > > > > Yeshwant, > > > > > > > > Thanks. I did see your response to Ned, but only after > > sending my note. > > > > > > > > In what is perhaps an odd way, from my point of view, this is > > a good news. If the document is in FDIS ballot, all of the > > suggestions on the this list about how the IETF needs to be > > involved, and involved, with some accelerated procedure in > > order to influence the substantive decisions of other > > standards bodies are moot: as I am sure you know, just about > > the one way to make a substantive change in an ISO FDIS > > document is a "no" vote from a national member body, > > presumably after either objecting all along (which I presume > > didn't happen) or discovering some catastrophic substantive > > problem. No room for a "we think it would be better to do > > this than that" intervention from the IETF. > > > > > > > > So the only issues relevant to other SDOs now, AFAICT, is > > what, if anything, those documents (which, sadly, I don't have > > time to read and study today or even this week) have to say > > about media type names. If the answer is that they don't say > > anything, then the IETF should move with appropriate > > diligence, but should not put "get it done quickly" ahead of > > "do it right and get it right". If they say "the media type > > is 'haptics/', then the IETF is essentially dealing, not with > > your I-D/ proposal but with an accomplished fact. That would > > present us with a very different, and unpleasant, situation > > although, using an extension of Ted's argument, I think some > > of us would argue for registering it and trying to figure out > > how to avoid that happening again. If it references the I-D, > > I suspect we could get a note to the editorial team at ISO /CS > > and/or to the relevant Committee Manager and secretariat about > > getting that fixed even after FDIS balloting was completed > > (and might get our > > > > way) but whether that would be of substantive importance given > > that there is no chance of giving them a stable RFC number as > > a reference is, well, questionable. > > > > > > > > So now, with the "need to do this quickly to influence the > > substantive decisions of other SDOs" and the "the IETF needs > > to be influential about this in order to remain an actor in > > the multimedia game" aside because, whatever the IETF decides > > to do about those issues neither they, nor your I-D, have > > much, if anything, to do with them, it seems to me there are > > only two questions for the near term: > > > > > > > > * Does the ISO FDIS mention "haptics/" as top-level media type? > > > > If it does, that is a major IETF (and probably IAB) strategy > > question, not really a media registration one. And that > > question includes my concern about precedents of other SDOs > > squatting on names without including us actively in the > > development process. > > > > > > > > * If the answer to that is "no", are there objections to more > > or less the WG approach Ned suggested that do not rely on the > > "influence the work of other SDOs" argument? > > > > > > > > thanks, > > > > john > > > > > > > > --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy > > > > > wrote: > > > > > > > >> John, > > > >> > > > >> > > > >> > > > >> Regarding your comment: > > > >> > > > >> > > > >> > > > >>>> One reason is that I think it would be really unfortunate to > > > >>>> establish a precedent that the way to get a top-level media > >>>> type is > > > >>>> to invoke work going on at > > > >> > > > >>>> what I understand to be essentially the WG level in another > >>>> SDO and > > > >>>> then plead urgency. > > > >> > > > >>>> I would feel somewhat differently about an established, > >>>> recognized, > > > >>>> deployed international standard, but, as I understand > >>>> "active work > > > >>>> in .. > > > >> > > > >>>> MPEG Systems File Format sub-group", this is fairly far > >>>> from that. > > > >> > > > >> > > > >> > > > >> I would just reiterate/summarize what I wrote in my response > >> to Ned's > > > >> comment that you might have missed: the haptics proposal in > >> MPEG is no > > > >> longer at the "WG level" in the MPEG Systems File Format > >> sub-group. It > > > >> just progressed to FDIS ballot at MPEG134, which should > >> complete by > > > >> July 2021, at which point progression to IS (International > >> Standard) > > > >> is just a matter of procedure. More to the point, it has > >> passed two > > > >> rounds (CDAM and DAMD) of international balloting, with over > > > >> 20 ISO National Bodies casting their ballots in each round. No > > > >> objections to the haptics proposal were received in either > >> round. The > > > >> proposal left the "WG level" after MPEG131 in July > > > >> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot > >> after > > > >> MPEG132 in October 2020 - a fact that was indeed mentioned in > >> v01 of > > > >> the I-D. > > > >> > > > >> > > > >> > > > >> The ISO link to the DAMD is here: > > > >> https://nam10.safelinks.protection.outlook.com/?url=https%3A% > >> 2F%2Flink > > > >> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.o > >> rg%252fst > > > >> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs > >> KcfbpK8nr > > > >> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp > >> REaQwDMRV > > > >> d7M%2C%26typo%3D1&data=04%7C01%7C%7C98c8e2a934bf4973859d0 > >> 8d90f309c > > > >> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331 > >> 34949%7CU > > > >> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > >> TiI6Ik1ha > > > >> WwiLCJXVCI6Mn0%3D%7C2000&sdata=%2BufQx8YrBdXpXyihiMQXkoVk > >> uVKQ6A5E3 > > > >> Qz3BQ97HVs%3D&reserved=0 >> on.outloo > > > >> k.com/?url=https%3A%2F%2Fnam10.safelink%2F&data=04%7C01%7 > >> C%7C98c8e > > > >> 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb > >> 5%7C0%7C1 > > > >> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > >> wMDAiLCJQ > > > >> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=y > >> JoFSrPdS6 > > > >> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&reserved=0 > > > >> s.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstan > > > >> dard%2F81604.html&data=04%7C01%7C%7Cb9be185f21b44df1b2f708d90e > > > >> 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966 > > > >> 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > > > >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qwZKX%2B26U > > > >> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=0>. > > > >> > > > >> > > > >> > > > >> To be clear, I have no issues with the other points you raise. > > > >> Just want to make sure that the discussion is based on current > > > >> reality. > > > > > > > > > > > --0000000000007d134f05c1ae65f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks for this disc= ussion.=C2=A0 At a minimum, it reaffirms my decision not to sponsor this my= self.=C2=A0 :-)

Francesca and I talked about it th= is morning after the IESG call, and decided that I'll take up the pen t= o write a draft charter based on this thread and circulate it for comments.= =C2=A0 Stay tuned.

-MSK

=
On Tue= , May 4, 2021 at 6:16 PM John C Klensin <john-ietf@jck.com> wrote:
Yeshwant,

Thanks.=C2=A0 And thanks for confirming.=C2=A0 I think I've said as muc= h
as I can usefully say on the subject.

best wishes,
=C2=A0 =C2=A0john


--On Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy
<ymuthusam= y@immersion.com> wrote:

> John,
>
>
>
> Thanks for the note. Taking each one of your two questions in
> order:
>
>
>
>>> * Does the ISO FDIS mention "haptics/" as top-level = media
>>> type?
>
>>> If it does, that is a major IETF (and probably IAB) strategy >>> question, not really a media registration one.
>
>>> And that question includes my concern about precedents of
>>> other SDOs squatting on names without including us actively >>> in the development process.
>
>
>
> No. The ISOBMFF FDIS does not mention 'haptics/' as top-level<= br> > media type. That said, it treats haptics in exactly the same
> way that it treats other top-level media types in Chapter 12
> (audio, video, text, font,=C2=A0 etc.) that have been recognized as > top-level media types by IETF. To be more specific, our
> haptics proposal to ISOBMFF follows the same box hierarchy as
> the other top-level types:
>
>=C2=A0 =C2=A0*=C2=A0 =C2=A0Media handler is 'hapt'
>=C2=A0 =C2=A0*=C2=A0 =C2=A0Haptic Media Header is the NullMediaHeaderBo= x
>=C2=A0 =C2=A0*=C2=A0 =C2=A0Sample entry is the HapticSampleEntry
>
>
>
> So, there is no issue of ISO squatting on the 'haptics/' name<= br> > or shutting IETF out from the development process. Our
> objective was to first introduce haptics as a top-level media
> type in ISOBMFF and then approach IETF with the proposal that
> we have in our I-D. For obvious reasons, I am unable to share
> the DAMD or FDIS documents on this mailing list, but I suspect
> those who are also members of MPEG can get access to it easily.
>
>
>
>>> * If the answer to that is "no", are there objection= s to
>>> more or less the WG approach Ned suggested that do not rely >>> on the "influence the work of other SDOs" argument?<= br> >
>
>
> Like I've said before, I am open to whatever mechanism the
> IETF decides to use to move the I-D forward. Given the work
> that has already been done in MPEG and the fact that we are
> approaching the FDIS ballot completion stage, I would assume
> that the IETF would take that into account *in some form* as
> it discusses the technical merits of the I-D.
>
>
>
> Thanks,
>
> Yeshwant
>
>
>
> Yeshwant Muthusamy, Ph.D. | Senior Director, Standards
>
>
>
> ymuthusa= my@immersion.com | +1 469-583-2171
>
>
>
> -----Original Message-----
> From: John C Klensin <john-ietf@jck.com>
> Sent: Tuesday, May 4, 2021 2:12 PM
> To: Yeshwant Muthusamy <ymuthusamy@immersion.com>; Ted Hardie
> <ted.ietf@g= mail.com> Cc: Dispatch WG <dispatch@ietf.org>;
> dispatch= -chairs@ietf.org; Applications and Real-Time Area
> Discussion <art@i= etf.org>; ART ADs <art-ads@ietf.org>;
> draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org
> Subject: RE: [art] [dispatch] Status of Haptics I-D in
> DISPATCH?
>
>
>
> Yeshwant,
>
>
>
> Thanks.=C2=A0 I did see your response to Ned, but only after
> sending my note.
>
>
>
> In what is perhaps an odd way, from my point of view, this is
> a good news.=C2=A0 If the document is in FDIS ballot, all of the
> suggestions on the this list about how the IETF needs to be
> involved, and involved, with some accelerated procedure in
> order to influence the substantive decisions of other
> standards bodies are moot: as I am sure you know, just about
> the one way to make a substantive change in an ISO FDIS
> document is a "no" vote from a national member body,
> presumably after either objecting all along (which I presume
> didn't happen) or discovering some catastrophic substantive
> problem.=C2=A0 No room for a "we think it would be better to do > this than that" intervention from the IETF.
>
>
>
> So the only issues relevant to other SDOs now, AFAICT, is
> what, if anything, those documents (which, sadly, I don't have
> time to read and study today or even this week) have to say
> about media type names.=C2=A0 If the answer is that they don't say=
> anything, then the IETF should move with appropriate
> diligence, but should not put "get it done quickly" ahead of=
> "do it right and get it right".=C2=A0 If they say "the = media type
> is 'haptics/', then the IETF is essentially dealing, not with<= br> > your I-D/ proposal but with an accomplished fact.=C2=A0 That would
> present us with a very different, and unpleasant, situation
> although, using an extension of Ted's argument, I think some
> of us would argue for registering it and trying to figure out
> how to avoid that happening again.=C2=A0 If it references the I-D,
> I suspect we could get a note to the editorial team at ISO /CS
> and/or to the relevant Committee Manager and secretariat about
> getting that fixed even after FDIS balloting was completed
> (and might get our
>
> way) but whether that would be of substantive importance given
> that there is no chance of giving them a stable RFC number as
> a reference is, well, questionable.
>
>
>
> So now, with the "need to do this quickly to influence the
> substantive decisions of other SDOs" and the "the IETF needs=
> to be influential about this in order to remain an actor in
> the multimedia game" aside because, whatever the IETF decides
> to do about those issues neither they, nor your I-D, have
> much, if anything, to do with them, it seems to me there are
> only two questions for=C2=A0 the near term:
>
>
>
> * Does the ISO FDIS mention "haptics/" as top-level media ty= pe?
>
> If it does, that is a major IETF (and probably IAB) strategy
> question, not really a media registration one.=C2=A0 And that
> question includes my concern about precedents of other SDOs
> squatting on names without including us actively in the
> development process.
>
>
>
> * If the answer to that is "no", are there objections to mor= e
> or less the WG approach Ned suggested that do not rely on the
> "influence the work of other SDOs" argument?
>
>
>
> thanks,
>
>=C2=A0 =C2=A0 john
>
>
>
> --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy
> <ymut= husamy@immersion.com<mailto:ymuthusamy@immersion.com>>
> wrote:
>
>
>
>> John,
>
>>
>
>>
>
>>
>
>> Regarding your comment:
>
>>
>
>>
>
>>
>
>>>> One reason is that I think it would be really unfortunate = to
>
>>>> establish a precedent that the way to get a top-level medi= a
>>>> type is
>
>>>> to invoke work going on at
>
>>
>
>>>> what I understand to be essentially the WG level in anothe= r
>>>> SDO and
>
>>>> then plead urgency.
>
>>
>
>>>> I would feel somewhat differently about an established, >>>> recognized,
>
>>>> deployed international standard, but, as I understand
>>>> "active work
>
>>>> in ..
>
>>
>
>>>> MPEG Systems File Format sub-group", this is fairly f= ar
>>>> from that.
>
>>
>
>>
>
>>
>
>> I would just reiterate/summarize what I wrote in my response
>> to Ned's
>
>> comment that you might have missed: the haptics proposal in
>> MPEG is no
>
>> longer at the "WG level" in the MPEG Systems File Format=
>> sub-group. It
>
>> just progressed to FDIS ballot at MPEG134, which should
>> complete by
>
>> July 2021, at which point progression to IS (International
>> Standard)
>
>> is just a matter of procedure. More to the point, it has
>> passed two
>
>> rounds (CDAM and DAMD) of international balloting, with over
>
>> 20 ISO National Bodies casting their ballots in each round. No
>
>> objections to the haptics proposal were received in either
>> round.=C2=A0 The
>
>> proposal left the "WG level" after MPEG131 in July
>
>> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot
>> after
>
>> MPEG132 in October 2020 - a fact that was indeed mentioned in
>> v01 of
>
>> the I-D.
>
>>
>
>>
>
>>
>
>> The ISO link to the DAMD is here:
>
>> https://nam10.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%
>> 2F%2Flink
>
>> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso= .o
>> rg%252fst
>
>> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs
>> KcfbpK8nr
>
>> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp
>> REaQwDMRV
>
>> d7M%2C%26typo%3D1&amp;data=3D04%7C01%7C%7C98c8e2a934bf4973859d= 0
>> 8d90f309c
>
>> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331
>> 34949%7CU
>
>> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>> TiI6Ik1ha
>
>> WwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D%2BufQx8YrBdXpXyihiMQXkoV= k
>> uVKQ6A5E3
>
>> Qz3BQ97HVs%3D&amp;reserved=3D0<https://nam10.safelin= ks.protecti
>> on.outloo
>
>> k.com/?url=3Dht= tps%3A%2F%2Fnam10.safelink%2F&amp;data=3D04%7C01%7
>> C%7C98c8e
>
>> 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb
>> 5%7C0%7C1
>
>> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>> wMDAiLCJQ
>
>> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D= y
>> JoFSrPdS6
>
>> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&amp;reserved=3D0
>
>> s.protection.outlook= .com/?url=3Dhttps%3A%2F%2Fwww.iso.org%2Fstan
>
>> dard%2F81604.html&data=3D04%7C01%7C%7Cb9be185f21b44df1b2f708d9= 0e
>
>> 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966
>
>> 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>
>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DqwZKX%2B2= 6U
>
>> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=3D0>. >
>>
>
>>
>
>>
>
>> To be clear, I have no issues with the other points you raise.
>
>> Just want to make sure that the discussion is based on current
>
>> reality.
>
>
>
>


--0000000000007d134f05c1ae65f8-- From nobody Thu May 6 14:00:50 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D353A319F for ; Thu, 6 May 2021 14:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zzhf_I2nXfW for ; Thu, 6 May 2021 14:00:44 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F6B3A319A for ; Thu, 6 May 2021 14:00:44 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id q7-20020a9d57870000b02902a5c2bd8c17so6131206oth.5 for ; Thu, 06 May 2021 14:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sPJTkKFBcS5Raq7fUDsHN1NWyN1I0S1OYR+LQoQJSMQ=; b=FxtnDzyxQWLrvXJhm7k6oRBbymaxHTUPIYqJHhOVBZFBWitfUtU0UapfSckOjpj5iZ abFhBtVf4DP/gNLwzMjeYVDN0ed0wE1QcbXfzz07SXEDyMdZeYPtCBepofT3+k4xCANt ma89NSOmDStd8J6vsIREpYHBFYo0CBW1oPtJuHHlrALnMk2Sg0iIwz8K+VWx2JJ7ybnE wmQ66BETeN23muwB7ZebSAAEGnh7sSuYdtU3/8iEoIE1rjanrMVOxhnpnyLTU3TJt5Al Dp8gHSiJPQwZLbr1Mvf7M10DmYZU1oStYZCbodqDGMCC0KrJg6ORkJ3T+5k73WETWbSn cmcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sPJTkKFBcS5Raq7fUDsHN1NWyN1I0S1OYR+LQoQJSMQ=; b=dGRJ6kfZ2s/U9NRiN+S3kS5u3k7F3tXhfjzuvCCBEhSUAUh89Y4C/f+wP2yzm+SSUQ iCOakgnegYZj95DtJmQNoD1LOOFMwQI3bKo1mBKyBcEAis4YBiVpbK8mV6RTgynsLFQI uRmKRgmMdfIp8it8cMRmIRz5FXsVCHcIqy0Thf+EipZEtu69l1Cl+4kfLy8/w2mWsqaM TB+3atk6bWnN/Zx2HkuWRDt2ihsQOcWU4DfFRxGxeDAgGf1kOJUHZAXd4LthqKzn0twb 00Hb2VovxCPMBTWKbahZSoMvTtNQuog14aL24S9wGTGUobfC0PyRW1g9GxEoJQA0I7zL AHHA== X-Gm-Message-State: AOAM530+zxwHpC/9WCvadZIwCbiAymmnaMUo3/MG4JXfTKrTbkVMy4+/ QXjQiYV0oXM0OpbExJR90vm4SGX95oTJUs7mLNsg23MRzsU= X-Google-Smtp-Source: ABdhPJwAed776sRfTR23xrF0xoJkL+fngj8W6S6nDq2BQAsK8PD4pRTEuSwr09+WCkQM3JftQ+oGCMhuCTh6WJdYdus= X-Received: by 2002:a9d:4b0e:: with SMTP id q14mr5255712otf.254.1620334842872; Thu, 06 May 2021 14:00:42 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: From: Samuel Erdtman Date: Thu, 6 May 2021 23:00:31 +0200 Message-ID: To: Carsten Bormann Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="000000000000ba197105c1af9a7e" Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 21:00:50 -0000 --000000000000ba197105c1af9a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again Carsten for sharing your thoughts See comment inline On Mon, May 3, 2021 at 5:37 PM Carsten Bormann wrote: > On 2021-05-01, at 23:28, Samuel Erdtman wrote: > > > > Hi Carsten, > > > > One more thing, you wrote "Signing data at rest certainly is a use case > that is worth addressing.". With my new fond insights (thanks) does this > mean that you are in favor of specifying how to do enveloped signatures f= or > JSON (or at least not against it)? > > Signing data at rest doesn=E2=80=99t mean that the signature then needs t= o be put > into the signed object. This is essentially adulterating that object, an= d > is part of the XMLDSig =E2=80=9Cwhat was just signed?=E2=80=9D practicabi= lity issue. > Agree the signature does not have to go into the signed document, but in my opinion has its benefits compared to the alternatives. if puting the signature somewhere else only referencing the signed document it would be inconvenient to find the signature when needed (yes you could create a system for that, there likely exists multiple of them all working slightly differently). The alternative I see would be to create some structure that would wrap the signed data and the signature but in that way it would not be much different from the ascii armoring done by normal JWS, I would like to cater for the use case where you want your doc unchanged apart from the addition of the signature. (This is my opinion, and I=C2=B4m okay with not agreeing) > (Such as, does my countersignature include the previous signature or not? > What does it mean to sign a signed object? Nothing about the existing > signature, or does it mean I endorse the existing signature, or does it > mean my signature actually is conditional on the validity of that existin= g > signature?) > Yes there are questions that would need to be answered, but to me the questions above would be application questions, what is the specific application trying to achieve, all of the options would be possible to technically construct. > > I=E2=80=99m not sure though I know what an =E2=80=9Cenveloped signature= =E2=80=9D is, and whether > what I just said above even replies to what I asked. > With enveloped signature I was referring to when the document that is signed will contain the signature opposed to enveloping signatures where the signature encapsulated the document being signed. (maybe not an established naming) > > Gr=C3=BC=C3=9Fe, Carsten > > --000000000000ba197105c1af9a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks again Carsten = for sharing your thoughts

See comment inline

On Mon, May 3, 2021 at 5:37 PM Carsten Bormann <cabo@tzi.org> wrote:
On 2021-05-01, at 23:28, Samuel Erdtman <samuel@erdtman.se&g= t; wrote:
>
> Hi Carsten,
>
> One more thing, you wrote "Signing data at rest certainly is a us= e case that is worth addressing.". With my new fond insights (thanks) = does this mean that you are in favor of specifying how to do enveloped sign= atures for JSON (or at least not against it)?

Signing data at rest doesn=E2=80=99t mean that the signature then needs to = be put into the signed object.=C2=A0 This is essentially adulterating that = object, and is part of the XMLDSig =E2=80=9Cwhat was just signed?=E2=80=9D = practicability issue.

Agree the signatu= re does not have to go into the signed document, but in my opinion has its = benefits compared to the alternatives. if puting the signature somewhere el= se only referencing the signed document it would be inconvenient to find th= e signature when needed (yes you could create a system for that, there like= ly exists multiple of them all working slightly differently). The alternati= ve I see would be to create some structure that would wrap the signed data = and the signature but in that way it would not be much different from the a= scii armoring done by normal JWS, I would like to cater for the use case wh= ere you want your doc unchanged apart from the addition of the signature. (= This is my opinion, and I=C2=B4m okay with not agreeing)
=C2= =A0
(Such as, does my countersignature include the previous signature or not? What does it mean to sign a signed object?=C2=A0 Nothing about the existing= signature, or does it mean I endorse the existing signature, or does it me= an my signature actually is conditional on the validity of that existing si= gnature?)

Yes there are questions that = would need to be answered, but to me the questions above would be applicati= on questions, what is the specific application trying to achieve, all of th= e options would be possible to technically construct.
=C2=A0<= /div>

I=E2=80=99m not sure though I know what an =E2=80=9Cenveloped signature=E2= =80=9D is, and whether what I just said above even replies to what I asked.=

With enveloped signature I was referri= ng to when the document that is signed will contain the signature opposed t= o enveloping signatures where the signature encapsulated the document being= signed. (maybe not an established naming)
=C2=A0

Gr=C3=BC=C3=9Fe, Carsten

--000000000000ba197105c1af9a7e-- From nobody Thu May 6 14:17:12 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58D63A3219 for ; Thu, 6 May 2021 14:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5q36fSNzzbm for ; Thu, 6 May 2021 14:17:03 -0700 (PDT) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955883A321F for ; Thu, 6 May 2021 14:17:02 -0700 (PDT) Received: by mail-oi1-f175.google.com with SMTP id u16so6808785oiu.7 for ; Thu, 06 May 2021 14:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tSiN6yRnSZsCBJdF8dx4UOf22aRuoXZzEn9Et1bpmwM=; b=Rh9ax3ZlR1hIrQbHumCPiDxK+O3CTDTUP7iCpFpAwXpa7UTCDoYee/zOBchkWxvV3/ TQrFhNQfwby0xhGh75eIgDzJe3NzZPsqPRs47obuyDmKTsJAUl2/ubWZFH++YarAsAzO TGM4tKvr4T65J1Xs/4J9zk97zQ+/29MoSY2rX/Wux6a/msQiNi3SZq620/wCGWvHQP18 BIG2fwm3OPoaa/A1U91G3a6MqXNkm53cnak2KJcQfIRyhdT3/D8l8Hf5YpK9Ao0bn5ar KQUHuh7HnVs3eP6gO5pWMoCmGYXlC5ZddY7yozreLjdieoV3cLCANKzwRW3Kr52uBN/l u1Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tSiN6yRnSZsCBJdF8dx4UOf22aRuoXZzEn9Et1bpmwM=; b=RQtGx3fWlp+McQr5Yq5mgDFvtKTdznrNN/1nw7zYWjYb1RuO8y/n6D4g1K0lT7PlKo U2Xr+r0SIAdBjd6oM5WGMeT5ASQyWdh9EnE/cC+vEZCqhfdDFgx89O23P0X1UNcKyl8x YS/s3XerC7+9AjfSZOqp8DJFNuJDP+9Uwq0gaW6dokV33QskFhTgimTWlFlf14hDF7iQ Q9Xv/0m/0U1T/zapUbOYBohvRxsf2rr8TUy4cqJOHJihwrG/xQqeH8tobVOCXdpSa6SG TUIPszgVWnI7nxDarlkvfEA2FbkbAvbvLWlbuZe6zad2KN8zv23ECRpo9+unJ4lsm6dO 09ew== X-Gm-Message-State: AOAM531M6y3ZVuGoDbEQsv9hvlpMLrfo1TPvEKjKXSqdvIGLMR46MQ0u OWZEtCwokAkDy4CRk6eH5GYLsAe6gjmlfuUnJ6W+gQ== X-Google-Smtp-Source: ABdhPJzsHhfd3fLNG612+su/nYa3XQrUi51ALE/bbtzILc0yT3ODMih548v+pg/XreIKOLbXjT81fLUKwDwTTxn0MUE= X-Received: by 2002:aca:902:: with SMTP id 2mr2160060oij.59.1620335819547; Thu, 06 May 2021 14:16:59 -0700 (PDT) MIME-Version: 1.0 References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> In-Reply-To: From: Samuel Erdtman Date: Thu, 6 May 2021 23:16:48 +0200 Message-ID: To: Carsten Bormann Cc: DISPATCH , art@ietf.org, IETF SecDispatch , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="000000000000f0fac505c1afd472" Archived-At: Subject: Re: [dispatch] [Secdispatch] [art] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 21:17:08 -0000 --000000000000f0fac505c1afd472 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Carsten, There was not problem reading the reply :), To summarize my understanding you have (at least) two issues with the current doc https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ * It uses RFC8785 to create the signature input which you do not like, since it limits the expressiveness of JSON (and uses UTF-16), CBOR could be an alternative (but you are not pushing for it) * You do not like putting the signature into the signed document because it can cause all kinds of confusion, with e.g. counter signatures. Did I capture that correctly? Cheers //Samuel On Mon, May 3, 2021 at 6:06 PM Carsten Bormann wrote: > Hi Samuel, > > I haven=E2=80=99t responded to your message yet as it triggers some MacOS= mail > misbehavior. > Let me try anyway, I hope you can parse the result. > > > On 2021-05-01, at 23:24, Samuel Erdtman wrote: > > > >> Thanks Carsten, > >> > >> Your clarifications were great! > >> > >> See some comments inline. > >> > >> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann wrote: > >> Hi Samuel, > >> > >> > 1. What do you mean with data at rest, data store in database or fil= e? > >> > >> The point is that you are not signing the data being transferred, but = a > local copy of some (e.g., freshly decoded) data (i.e., at the data model > level) which is then processed a little (potentially taking out all > signatures) and then is run through a rather complicated engine to produc= e > a signing input that is a deterministic function of the decoded and > processed data. > >> > >> There are easier ways to get a signing input from JSON-like data at > rest. > >> For a (quite workable) strawman: How about doing a CBOR encoding using > deterministic encoding rules? > > > > This is a good point. Still not convinced other solutions would be > orders of magnitude better and the proposed one is easy to implement and > easy to understand (maybe too easy since I had not thought about your > alternative solution). > > It is hard to measure interoperability in orders of magnitude=E2=80=A6 > Doing a CBOR signing input is easy to implement and easy to understand, > though. > No UTF-16 needed :-) > > >> > Or is it data that does not change? Sorry I do not get it. > >> > > >> > 2. What is weird with saying "Represented in JSON=E2=80=9D? > >> > >> Your scheme does NOT require (or benefit in any way from) representing > the data in JSON. > >> The data could be transferred in YAML (or CBOR for that matter): as > long as your local copy of the decoded data (after the little processing) > sticks inside the confines of the I-JSON data model, you can use your > scheme for signing. > >> > > But since JSON according to https://tools.ietf.org/html/rfc7159 is > fairly flexible, would not fitting it into CBOR require similar limitatio= ns > as RFC8785 puts on what you can do with the JSON? (i.e. the I-JSON > limitations) > > It does require some thinking. > https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 documents what we > arrived at when discussing that in the CBOR WG. > > (I=E2=80=99m very well aware that many applications would be content with= just > I-JSON, because they already have made their peace with it to enable > JavaScript classic processing. So I=E2=80=99m just answering the questio= n here.) > > >> > is it that the RFC7493 I-JSON subset is not all that JSON could be? > (to me this is a reasonable limitation that I in practice never have had = to > go outside) > >> > >> Well, that has been debated to death, and it is clear that nobody like= s > I-JSON (*), but it is the de-facto boundary within which the actually mor= e > capable JSON format needs to be used these days. > >> (If you need more flexibility, you know where to find CBOR.) > >> > > So are you saying that CBOR would not impose the same limitations on th= e > original JSON as RFC8785? > > Yes. Again, please see > https://www.rfc-editor.org/rfc/rfc8949.html#section-6.2 > > Please note that I=E2=80=99m not making these points to push CBOR, even t= hough I=E2=80=99m > really convinced CBOR and its =E2=80=9CJSON mode=E2=80=9D can play a help= ful role in > addressing the underlying requirements. > > Gr=C3=BC=C3=9Fe, Carsten > > --000000000000f0fac505c1afd472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Carsten,

There was no= t problem reading the reply :),

To summarize my un= derstanding you have (at least) two issues with the current doc ht= tps://datatracker.ietf.org/doc/draft-jordan-jws-ct/
* It uses= RFC8785 to create the signature input which you d= o not like, since it limits the expressiveness of JSON (and uses UTF-16), C= BOR could be an alternative (but you are not pushing for it)
* You do not like putting the signature int= o the signed document because it can cause all kinds of confusion, with e.g= . counter signatures.

=
Did I capture that correctly?

Cheers
//Samuel

On Mon, May 3, 2021 at 6:06 PM Carsten Bormann <cabo@tzi.org> wrote:
Hi Samuel,

I haven=E2=80=99t responded to your message yet as it triggers some MacOS m= ail misbehavior.
Let me try anyway, I hope you can parse the result.

> On 2021-05-01, at 23:24, Samuel Erdtman <samuel@erdtman.se> wrote:
>
>> Thanks Carsten,
>>
>> Your clarifications were great!
>>
>> See some comments inline.
>>
>> On Sat, May 1, 2021 at 1:04 AM Carsten Bormann <cabo@tzi.org> wrote:
>> Hi Samuel,
>>
>> > 1. What do you mean with data at rest, data store in database= or file?
>>
>> The point is that you are not signing the data being transferred, = but a local copy of some (e.g., freshly decoded) data (i.e., at the data mo= del level) which is then processed a little (potentially taking out all sig= natures) and then is run through a rather complicated engine to produce a s= igning input that is a deterministic function of the decoded and processed = data.
>>
>> There are easier ways to get a signing input from JSON-like data a= t rest.
>> For a (quite workable) strawman: How about doing a CBOR encoding u= sing deterministic encoding rules?
>
> This is a good point. Still not convinced other solutions would be ord= ers of magnitude better and the proposed one is easy to implement and easy = to understand (maybe too easy since I had not thought about your alternativ= e solution).

It is hard to measure interoperability in orders of magnitude=E2=80=A6
Doing a CBOR signing input is easy to implement and easy to understand, tho= ugh.
No UTF-16 needed :-)

>> > Or is it data that does not change? Sorry I do not get it. >> >
>> > 2. What is weird with saying "Represented in JSON=E2=80= =9D?
>>
>> Your scheme does NOT require (or benefit in any way from) represen= ting the data in JSON.
>> The data could be transferred in YAML (or CBOR for that matter): a= s long as your local copy of the decoded data (after the little processing)= sticks inside the confines of the I-JSON data model, you can use your sche= me for signing.
>>
> But since JSON according to https://tools.ietf.org/html/rfc7= 159 is fairly flexible, would not fitting it into CBOR require similar = limitations as RFC8785 puts on what you can do with the JSON? (i.e. the I-J= SON limitations)

It does require some thinking.
https://www.rfc-editor.org/rfc/rfc8949.html#s= ection-6.2 documents what we arrived at when discussing that in the CBO= R WG.

(I=E2=80=99m very well aware that many applications would be content with j= ust I-JSON, because they already have made their peace with it to enable Ja= vaScript classic processing.=C2=A0 So I=E2=80=99m just answering the questi= on here.)

>> > is it that the RFC7493 I-JSON subset is not all that JSON cou= ld be? (to me this is a reasonable limitation that I in practice never have= had to go outside)
>>
>> Well, that has been debated to death, and it is clear that nobody = likes I-JSON (*), but it is the de-facto boundary within which the actually= more capable JSON format needs to be used these days.
>> (If you need more flexibility, you know where to find CBOR.)
>>
> So are you saying that CBOR would not impose the same limitations on t= he original JSON as RFC8785?

Yes.=C2=A0 Again, please see https://www.rfc-= editor.org/rfc/rfc8949.html#section-6.2

Please note that I=E2=80=99m not making these points to push CBOR, even tho= ugh I=E2=80=99m really convinced CBOR and its =E2=80=9CJSON mode=E2=80=9D c= an play a helpful role in addressing the underlying requirements.

Gr=C3=BC=C3=9Fe, Carsten

--000000000000f0fac505c1afd472-- From nobody Thu May 6 18:45:44 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B013A0906 for ; Thu, 6 May 2021 18:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnNwdrhyMXzK for ; Thu, 6 May 2021 18:45:38 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0852F3A0E52 for ; Thu, 6 May 2021 18:37:02 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id x19so10570688lfa.2 for ; Thu, 06 May 2021 18:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Dz1pybc6nX2Uwbda/svT2IgehZdskusb/Pr3LN39G+o=; b=OlwgbgUILYwlAXwsFXki7IcFNFpyCKckpKddjpb9NWZL+MvoAQ2mfWUrFtNPqFFrlp ntqrVySDLJvbRwrw3CVjVxKyVUUY5UfbvM+Kn1w1svzSehdvnBmGvzDdR5lUZb71Pe9N 7zG78jV1EYu4WqnTN4fidkXSz+U3YafdcC4RXXNmPo2e3EhqnSb443i1/syiwIdtV0RQ EZ0hBrDmd2AJ0Zrnyb1N8lw3Jsfx1rFfxrhLymGjG4nMAw74wgM+oScAULbx8LecBzFm HeyJW/jJmP/j1Mczp3z9JxYBu5WS2c3Z7t3O1pE7SE/fok4T332j3iKLbynXPAv5lzwt lBYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Dz1pybc6nX2Uwbda/svT2IgehZdskusb/Pr3LN39G+o=; b=UsTP57wjD1Z8tgPtH9l3EFHShovoK4+3u/Gt5BNd4i+u0WGPwuk524H58oI7RMdOW5 VrAzVcNVtaYRwi21W0gLS4yRtKby/JU/+ms3nDt8rqYeoS6iHN5G75vmtaVew/DiTcWm ielD3HJGopDh7ON7buR9L8gZHpuwBol8AWy0cmc/qg+5eAtHQVLh+7FLzSSHpjqnmFdl BlAZtk59m8WMSSVvjFgE9rUPyjf95XKFt2wKB2kdIF0Err1+hgiIpbo8nDpn8snIkXD1 48XQCd/e98YKP2lWgpJmmFufRziIV9N8FguP5VxusSaxCzldltFdph7oVwHfAPQ8cX7Y G7Sw== X-Gm-Message-State: AOAM533/vjUzxiOX9FljMcdsZK7gd/gDvd4fMhIxbHbaRohk1PzFZxfE drkqvR90fDumobVZft2hd7hkw6Mw3U/gDOG2VhahuRsSWPXdLmGt X-Google-Smtp-Source: ABdhPJw4mYnqmp/VUkEhES6ZcXrsnt8NNHg76KjxtmWCxj7qbQSbpO8331hgmNubhsWps0+kwTiCtrcdgju1lKPsCPA= X-Received: by 2002:a19:f010:: with SMTP id p16mr4856733lfc.612.1620351419562; Thu, 06 May 2021 18:36:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: James Zern Date: Thu, 6 May 2021 18:36:48 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000c6badc05c1b37682" Archived-At: Subject: Re: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 01:45:40 -0000 --000000000000c6badc05c1b37682 Content-Type: text/plain; charset="UTF-8" Hi Murray, On Thu, May 6, 2021 at 12:53 AM Murray S. Kucherawy wrote: > On Thu, Apr 29, 2021 at 7:58 PM James Zern wrote: > >> It was suggested I post a message here requesting advice on the >> processing path of my submission to register the image/webp mime-type [1]. >> I'm not familiar with the process, so if you could have a look and see if >> this is appropriate for the DISPATCH working group or suggest another I'd >> appreciate it. >> > > Just a reminder that DISPATCH's charter includes: > > "- By agreement with ART ADs, processing simple administrative documents." > > If we agree that this work fits that description, then that's a processing > option here. > > I would also suggest this be floated by media-types@ietf.org, if that > hasn't been done already. > I requested a review on that list [2]. Did you want to start a separate thread to request advice on a processing path? [2] https://mailarchive.ietf.org/arch/msg/media-types/EYRWG6ochcIhAFhBwHCJlsBVV38/ > > -MSK > --000000000000c6badc05c1b37682 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Murray,

On Thu, May 6, 2021 at 12:= 53 AM Murray S. Kucherawy <superu= ser@gmail.com> wrote:
On Thu, Apr 29, 2021 at 7:58= PM James Zern <jz= ern@google.com> wrote:
It was suggested I post a mes= sage here requesting advice on the processing path of my submission to regi= ster the image/webp mime-type [1]. I'm not familiar with the process, s= o if you could have a look and see if this is appropriate for the DISPATCH = working group or suggest another I'd appreciate it.
<= div>
Just a reminder that DISPATCH's charter includes:
"- By agreement with ART ADs, processing simple administrative do= cuments."

If we agree that this work fits tha= t description, then that's a processing option here.

I would also suggest this be floated by media-types@ietf.org, if that hasn't = been done already.

I = requested a review on that list [2]. Did you want to start a separate threa= d to request advice on a processing path?

=C2=A0

-MSK
--000000000000c6badc05c1b37682-- From nobody Tue May 11 04:57:32 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D93D3A083A; Mon, 3 May 2021 12:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eWl-r4JNaKq; Mon, 3 May 2021 12:07:11 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A043A0835; Mon, 3 May 2021 12:07:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYLJ4QVHYO00HNS5@mauve.mrochek.com>; Mon, 3 May 2021 12:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620068522; bh=2ATLmiF7nUkF52tCN12IoYn5L34JPm4XuClVHHhxHOk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=aWyF8FNqVYY5+SzZQpt49h9/u9+nNHfSGw8Jv6ddhQtDOv0c3jRjOeVbIBQCWm98K K6K+CtPkmm3lmpbv7PEUMR4Um0S8TfxDhZhQRLdVH13ZI/1ZVRXg5/Dd853QELmEMd GsfbEVFxFpP4RFEKaTGtpnMLwO0uurCzuzGrgmmI= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYH8JUPTNK0085YQ@mauve.mrochek.com>; Mon, 3 May 2021 12:01:57 -0700 (PDT) Cc: Ted Hardie , Ned Freed , Dispatch WG , "dispatch-chairs@ietf.org" , Applications and Real-Time Area Discussion , ART ADs , Claudio Allocchio , Francesca Palombini , "draft-muthusamy-dispatch-haptics@ietf.org" Message-id: <01RYLJ4MK6040085YQ@mauve.mrochek.com> Date: Mon, 03 May 2021 11:29:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 03 May 2021 17:27:08 +0000" References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> To: Yeshwant Muthusamy Archived-At: X-Mailman-Approved-At: Tue, 11 May 2021 04:57:31 -0700 Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 19:07:17 -0000 > Folks, > First off, glad to see some traffic on the haptics I-D. Thanks to Francesca > for jump-starting the latest round of discussion. > At the risk of sounding biased (as one of the authors of the I-D), I would > second Ted’s latest proposal that we not overload the WG with other media > type-related work, lest it end up de-prioritizing or delaying consideration of > the haptics proposal. This sort of thing is what WG charters are *for*. If the haptics work needs to come first, say that in the charter. If anything this increases the liklihood of your proposal getting some attention, because people interested in the other work items will be incentivized to help with the haptics work, in order to get to their items. ADs have a vast array of things competing for their attention. WG chairs, not so much. As such, leaving your proposal as an AD-sponsored item is far less likely to produce timely results than doing it in a WG. > I appreciate the importance of Ned’s list, but Ted is correct in that the time > to get the haptics proposal reviewed (and hopefully, approved) is not unbounded. > More on that below. As I said before, not only are you talking about a new top-level type, you are talking about one that has the potential to interact with specific protocols, e.g., one that have specific slots for audio and video types where the top-level value is assumed, in complicated ways. As such, you are going to need involvment from a much wider range of people than you would for most of the other items on this list. > Setting aside the implications (inadvertent or otherwise) of Claudio’s > comment that Apple or Google need to be on the authors list for IETF to even > consider an ID (or work on it expeditiously), I would point to the following > Draft Amendment of the ISO/IEC 14496-12 (ISO Base Media File Format) standard. > It is the one that has our proposal to treat haptics as a top-level media type, > akin to audio and video, in ISOBMFF files (like .mp4, .3gpp, etc.). > https://www.iso.org/standard/81604.html > For those familiar with how MPEG works, a DAMD means that the proposal has > gone through two rounds of balloting from various ISO National Bodies (including > the US National Body). And yes, Apple and Google are indeed part of the US > National Body 😊. We are happy to report that no objections were received to > the haptics proposal in either the CD or DAMD ballot rounds from any of the 20+ > National Bodies that voted on it. It has now moved to FDIS ballot (the haptics > proposal having been merged with other updates to 14496-12 for a new 7th > edition) that is expected to complete by July. > MPEG has also issued a Call for Proposals on the Coded Representation of > Haptics – Phase 1 at the just concluded MPEG134 meeting last week. The CfP > seeks technologies that would help standardize a haptic coding format and a > haptic decoder in MPEG. The press release and final CfP docs themselves should > be available in a few days. Draft versions of the Haptics CfP documents from > MPEG133 in January 2021 can be found here: > https://www.mpegstandards.org/standards/Explorations/40/. I could even begin to count the number of times I've been told that this or that is critical because of the actions of some other standards group, and for that reason the IETF needs to engage post haste. IME a common result of such pleas is to slow the work down, as people begin to argue about how the IETF should handle its interactions with other standards bodies, rather than focusing on the technical issues at hand. Ned From nobody Tue May 11 05:39:48 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92BB3A0B40; Mon, 3 May 2021 12:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=garr.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5STpTaw8z9LQ; Mon, 3 May 2021 12:32:55 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E523A0AFD; Mon, 3 May 2021 12:32:53 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (unknown [10.2.2.13]) by smtp-1.dir.garr.it (Postfix) with ESMTPSA id 0CF69A0A9C; Mon, 3 May 2021 21:32:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=202004; t=1620070371; bh=siDP9mUtpWyUM+vJQGvSVz/ssxKWbpe5g9hCqbHlSww=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=PteR2GO2i9twkI6l3qnxpX43hpNCUZyUZQ1/Pf0eLFDRg2oZZXPZPoo8xIuxavs4A kBTo9TQts72gQHS9AoMjCV8k8pSJ3ANScZlwHDJqP6Ngs8v+uH76ceAD70850PaHy8 WJAsa6PQp0yjQNxqNSQ2Rlm13j5tetOxAQ+aN9MlAv6jN7v7vs0+JwkHNv0n7/5RUB 2uOytUD4rlSBkf5N9+zuKpBJ1LECmWWQxYm7btupsXaB6EP+yiEvw+WA5rkY6amv+G Z+hq9J4HBhlRAe5iJUghptXygp2COoYqCC0zpIIbgYO0uGjKHQd/0HdFRMv4CjlUQV Ks/sSXvtM6rmQ== Date: Mon, 3 May 2021 21:32:45 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Ned Freed cc: Yeshwant Muthusamy , Ted Hardie , Dispatch WG , "dispatch-chairs@ietf.org" , Applications and Real-Time Area Discussion , ART ADs , Claudio Allocchio , Francesca Palombini , "draft-muthusamy-dispatch-haptics@ietf.org" In-Reply-To: <01RYLJ4MK6040085YQ@mauve.mrochek.com> Message-ID: References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <01RYLJ4MK6040085YQ@mauve.mrochek.com> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-365412606-1620070366=:824" Archived-At: X-Mailman-Approved-At: Tue, 11 May 2021 05:39:47 -0700 Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 19:33:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-365412606-1620070366=:824 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT >> Setting aside the implications (inadvertent or otherwise) of Claudio’s >> comment that Apple or Google need to be on the authors list for IETF to even >> consider an ID (or work on it expeditiously), you totally misread what I stated, sorry. I said that at least those companies who are implementing the "new stuff" should be involved into the discussion of the specificaions, oitherwise the specification will be just ignored or result inaccurate compared to reality. And Apple and Google are just 2 examples. The way you read my sentence it totaly against what IETF is how it works etc. When I (and Ned and John, and many of the people who made suggestions in tis thread) started in the IETF, Apple, Google, and 80% of current companies weer "just not yet stablished", so please do not misread examples. :-) Specifications are done and are successful when all people who need them work to write them, and when people who will implement them work on them, too. apart frm this, +1 to Ned's last email. > > I could even begin to count the number of times I've been told that this or that > is critical because of the actions of some other standards group, and for that > reason the IETF needs to engage post haste. IME a common result of such pleas is > to slow the work down, as people begin to argue about how the IETF should handle > its interactions with other standards bodies, rather than focusing on the > technical issues at hand. yes! > > Ned > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys --0-365412606-1620070366=:824-- From nobody Wed May 12 09:21:20 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAB63A0EFA for ; Wed, 12 May 2021 09:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV3a_5PTYt9p for ; Wed, 12 May 2021 09:21:16 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED003A0ED7 for ; Wed, 12 May 2021 09:21:16 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id s15so9440370vsi.4 for ; Wed, 12 May 2021 09:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KrVYEX2NkT9sQRm3Fy5hg3XlBNdiJWiJKbD3CNi4Hak=; b=GoEmgTPBi3tbc+bRvFw/FWyN9nZCQfiQVMycWQ9QiMyhSPcSfHp7HtjBmZFuAc866E GhMtmlDNbLHbKKVjzOwmb2l/e8+dbsRKfx6QCBE40YXBykpooG62FtgDxJueAUEoPutG aiX9A+NFfg8hfsPl/n4fC4vqFLJH6hGLzQ2u9abyi94ebvYM3Z8xl1vDGVPRtTEfBDuI GBV5xOpD8zvbMDa+i1VqlA+M2m8RIMUiglmwPwnprBbgbc3ISF6eJ0bkceniTu50k6Xk K4CCVtif6OqoyZ2VlocVCC6Wbs85xT2eELswDNYtyfuuWQjQlLM5/T5kjUAhdpPnxAVi Ry8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KrVYEX2NkT9sQRm3Fy5hg3XlBNdiJWiJKbD3CNi4Hak=; b=ijhsL8iu9QaJbEh8ua0t0nPweXxAjCYwY+GRTqjP7PNYURgUDEluYPRc4Szzp+30JG kxezGHnsJSwdcS2csTDXNBMx4l2QPKmVlR3bsBSq8pqf6f3vUJVYv1iOUzhqPZ3pT0Sx W7RXppM18hNt22FJUUGR2AzTuamzbDwFiyUgZFwzfXfUMIiL2HmTmSf72vCEls5qJsbG wx8qo0RAo2R8wroxxcMyyHbp+B8m/6eKXv1x6MOACUiboPMPxnkzDVZGKxf6Zj1ckzXq qTQYcIZT/wFetzk7k1kLu/3DgrvuF88+nU3isuJ/KAEShiguMALkMFrrzs/UO1tt1ZT7 vFFQ== X-Gm-Message-State: AOAM531JrZMZY31Sue+iCT9o/rRPThehJTNQazAVqZE3uYJkaG7z3UXB g3oOasNoOjW56JIbEp3OPJqZL4wojFcBfrFFD7J95GOn92W6og== X-Google-Smtp-Source: ABdhPJzoi9S3IIxk4Gg2LG11RllFU7w5OSWtuvMMPi+rqTYussI6A9ehKfFVRNdE82sX/XhELbGZCpdQtaCID2ASn8k= X-Received: by 2002:a67:dc1:: with SMTP id 184mr4268026vsn.15.1620836474042; Wed, 12 May 2021 09:21:14 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Wed, 12 May 2021 09:21:03 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000463d5e05c224663f" Archived-At: Subject: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 16:21:19 -0000 --000000000000463d5e05c224663f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Comments welcome, including my late-night choice of name. -MSK Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group Charter [= DRAFT] The IETF maintains a registry of media types and subtypes that are used to identify particular payloads and their semantics as they are transported via application level protocols such as messaging (=E2=80=9Cemail=E2=80=9D)= and the web (HTTP). The core structure and use of media types is the MIME framework, defined in RFCs 2045 through 2049, and amended by various later documents. Registration of new media types is defined by BCP 13, which was last updated in 2013. Several topics have appeared in the interim that are large enough in scope and importance to warrant the formation of a working group to develop and process them. In particular, we have for the first time a request for a new top-level media type, and such requests are sufficiently rare that our current processes don=E2=80=99t make it clear how this request should be ev= aluated and dispatched. This working group will therefore, under this instance of the charter, take up the following work. The working group has discretion to order these as appropriate. - Establish criteria and procedures for registering top-level media types. In particular, specify whether these requests can be handled by = the current IANA media type review team, require IETF Consensus, or should follow some other process. - Develop and process the pending =E2=80=98haptics=E2=80=99 top-level medi= a type request, based on draft-muthusamy-dispatch-haptics. - Consider whether and how to permit multiple media type suffixes. - Consider any issues around media types for programming languages. - Determine revised criteria regarding Security Considerations sections in media type applications. - Review the format of the media types registry itself. It is expected that the working group will produce a document updating RFC 6838 (BCP 13) as a result of the points above, and a =E2=80=9Chaptics=E2=80= =9D standards track registration RFC. Any other work is out of scope. On completion of these goals, the working group will discuss whether it would be appropriate for this to become a standing (perhaps usually dormant) working group containing the expertise needed to repeat these reviews periodically, and/or to handle those applications such as the top-level request that are too large in scope for the IANA media type review team. If so, the working group will negotiate a new charter accordingly. Input Document(s): - draft-muthusamy-dispatch-haptics Proposed milestones (target dates TBD): - draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for approval (Proposed Standard) - RFC6838bis to the IESG for approval (BCP) --000000000000463d5e05c224663f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments welcome, including my late-night choice of n= ame.

-MSK


=

M= edia Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group Charter [D= RAFT]


The IETF maintains a registry of media types and subtypes that ar= e used to identify particular payloads and their semantics as they are tran= sported via application level protocols such as messaging (=E2=80=9Cemail= =E2=80=9D) and the web (HTTP).=C2=A0 The core structure and use of media ty= pes is the MIME framework, defined in RFCs 2045 through 2049, and amended b= y various later documents.=C2=A0 Registration of new media types is defined= by BCP 13, which was last updated in 2013.


Several topics have appeare= d in the interim that are large enough in scope and importance to warrant t= he formation of a working group to develop and process them.=C2=A0 In parti= cular, we have for the first time a request for a new top-level media type,= and such requests are sufficiently rare that our current processes don=E2= =80=99t make it clear how this request should be evaluated and dispatched.<= /span>


This working group will therefore, under this instance of the charter, = take up the following work.=C2=A0 The working group has discretion to order= these as appropriate.

  • Establish criteria and procedures for registering top-level= media types.=C2=A0 In particular, specify whether these requests can be ha= ndled by the current IANA media type review team, require IETF Consensus, o= r should follow some other process.

  • Develop and proc= ess the pending =E2=80=98haptics=E2=80=99 top-level media type request, bas= ed on draft-muthusamy-dispatch-haptics.

  • Consider wheth= er and how to permit multiple media type suffixes.

  • C= onsider any issues around media types for programming languages.

    =

  • Determine revised criteria regarding Security Considerations sec= tions in media type applications.

  • Review the format of= the media types registry itself.


It is expected that the wo= rking group will produce a document updating RFC 6838 (BCP 13) as a result = of the points above, and a =E2=80=9Chaptics=E2=80=9D standards track regist= ration RFC.=C2=A0 Any other work is out of scope.

On completion of these go= als, the working group will discuss whether it would be appropriate for thi= s to become a standing (perhaps usually dormant) working group containing t= he expertise needed to repeat these reviews periodically, and/or to handle = those applications such as the top-level request that are too large in scop= e for the IANA media type review team.=C2=A0 If so, the working group will = negotiate a new charter accordingly.


Input Document(s):

  • draft-muthusamy-dispatch-ha= ptics


Proposed milestones (target dates TBD):

  • draft-muthusamy-dispatch-ha= ptics (or equivalent) to the IESG for approval (Proposed Standard)

  • RFC6838bis to the IESG for approval (BCP)

=
--000000000000463d5e05c224663f-- From nobody Wed May 12 10:13:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955F73A1154 for ; Wed, 12 May 2021 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6MqcBVs-PWM for ; Wed, 12 May 2021 10:12:58 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2525E3A114C for ; Wed, 12 May 2021 10:12:58 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id h1so7731358uar.0 for ; Wed, 12 May 2021 10:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WLIoYmQ3T/2l76si1HT7A/Tobqwn/hsFCVsRfSKCmNk=; b=MRvdtqQWW2DDAcBs+/o5qAXneMyFmJeKoWii02FTz3wbtYDVEjwkFSDyvpIstvWFb+ sOg2vhLlVYwmRXmr4BSTu8w8QofogZ8/7zypuVjUM5fS6PZI3oRbQriv+H0M8ZOyG+Bk gkfRjbJNdDB2yU+6qQ6rd2ZIEtUp8ngmAYvYppjA4FPRAF9mpUhSMX4ZwjEWETRmKcE4 VZMz/H2B5yI6FfNvznuJdFDvce2LdhXnlcmlm8pWfG5imuaTUTeegfI5TcaWT1m9gYPg 3DLjcEmZdy0BuT24PwYrYi9UlQnK2onwZkbCHqpslueg5X7sFtR4DKABV0TG7S0hyWQx A/hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WLIoYmQ3T/2l76si1HT7A/Tobqwn/hsFCVsRfSKCmNk=; b=q+8m3S3kp0FTTXsrNlD92/X71kwsRSgdQHsTJ8b7s/B6WuMfzJfL9yue7c8fG5D1+R VhLDPHxq9my0yFrVw7eADN80XASESh/evzaWr6UZCuB+8ZjTRWCZKlH+5zP6PCUo1kQv rAPQDvbjBy+f5Y1ZvqM+bK819jnQ8WRcJ/ZylUN1jK5C+feuW17KCudNd/7fkhy/GaWb wS2UKhPCZauadCGeDyfKT3TgYVaZpXhgGQqE2PamabmZz6x5+U1DuO9FxZZ4OeKD2pCA 5wfHN5LKhIKE4dM4kFVxac0+Tx+V7av6y6xUFJE9oFSbLRbEuXCLDtNdXvtGNz+RDVsz F/9g== X-Gm-Message-State: AOAM532TDLLb/43QPGJmECAE0k+i8zAHLvpdVLkZSbpdvX7uQ1WWendu 3N5CgDRRJiuqYm73HnKhManmTvDrct+1V7+jZpiTOPD64x8= X-Google-Smtp-Source: ABdhPJyGUt41jSCr2uPyfUKZWEG/wgBlM4FRc0IaHp1Dk+eA4bXf3NdiHYb7DAbCBr81WrD2I+U8xMuqIa8HHQ4ouQw= X-Received: by 2002:ab0:2659:: with SMTP id q25mr34376024uao.47.1620839576617; Wed, 12 May 2021 10:12:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 12 May 2021 10:12:45 -0700 Message-ID: To: James Zern Cc: DISPATCH list Content-Type: multipart/alternative; boundary="00000000000033c4ad05c2251fc6" Archived-At: Subject: Re: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 17:13:03 -0000 --00000000000033c4ad05c2251fc6 Content-Type: text/plain; charset="UTF-8" On Thu, May 6, 2021 at 6:45 PM James Zern wrote: > On Thu, May 6, 2021 at 12:53 AM Murray S. Kucherawy > wrote: > >> On Thu, Apr 29, 2021 at 7:58 PM James Zern wrote: >> >>> It was suggested I post a message here requesting advice on the >>> processing path of my submission to register the image/webp mime-type [1]. >>> I'm not familiar with the process, so if you could have a look and see if >>> this is appropriate for the DISPATCH working group or suggest another I'd >>> appreciate it. >>> >> >> Just a reminder that DISPATCH's charter includes: >> >> "- By agreement with ART ADs, processing simple administrative documents." >> >> If we agree that this work fits that description, then that's a >> processing option here. >> >> I would also suggest this be floated by media-types@ietf.org, if that >> hasn't been done already. >> > > I requested a review on that list [2]. Did you want to start a separate > thread to request advice on a processing path? > Nope, that's what this thread is for. -MSK --00000000000033c4ad05c2251fc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 6, 2021 at 6:45 PM James Zern= <jzern=3D40google.com@dm= arc.ietf.org> wrote:
On Thu, May 6, 2021= at 12:53 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, Apr 29, 2021 at 7:58 PM James Zern <jzern@google.com> wrote:=
It was suggested I post a message here requesting advice o= n the processing path of my submission to register the image/webp mime-type= [1]. I'm not familiar with the process, so if you could have a look an= d see if this is appropriate for the DISPATCH working group or suggest anot= her I'd appreciate it.

Just a rem= inder that DISPATCH's charter includes:

"- By agreement wit= h ART ADs, processing simple administrative documents."

=
If we agree that this work fits that description, then that'= s a processing option here.

I would also suggest t= his be floated by media-types@ietf.org, if that hasn't been done already.
<= /div>

I requested a review on that li= st [2]. Did you want to start a separate thread to request advice on a proc= essing path?

Nope, that&#= 39;s what this thread is for.

-MSK
=
--00000000000033c4ad05c2251fc6-- From nobody Wed May 12 12:52:11 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA523A102B for ; Wed, 12 May 2021 12:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wYKn69_wTgs for ; Wed, 12 May 2021 12:52:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA7C3A1028 for ; Wed, 12 May 2021 12:52:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYY5BI9ETS00I4M5@mauve.mrochek.com> for dispatch@ietf.org; Wed, 12 May 2021 12:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1620848815; bh=Djud15lGLRx+LIGd1ALPFbXBjQ+RhcjpcUWur5dCxY0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Oetq6tQdjbAukdpWNr4nKeV9bzPPXjJt7qRbGJDtQ3kx7qyMRj1rcM3IlP1yooXXs DGroPBTOXm+5nZJQAeu4FaMWAuwsGAZDH4ca6XAmA05F0Cb4bxgIFhQ2lUC8FYdSLo ITWiYfrHJWFSt+DSfIbFupENofQRXvdL0Lo0+SIc= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=UTF-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RYY3699MEO0085YQ@mauve.mrochek.com>; Wed, 12 May 2021 12:46:50 -0700 (PDT) Cc: DISPATCH list Message-id: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> Date: Wed, 12 May 2021 11:53:45 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 12 May 2021 09:21:03 -0700" References: To: "Murray S. Kucherawy" Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 19:52:09 -0000 > Comments welcome, including my late-night choice of name. The name is fine. The rest... I'm afraid I have a lot of problems with it. > -MSK > Media Type Maintenance (“MEDIAMAN”) Working Group Charter [DRAFT] > The IETF maintains a registry of media types and subtypes that are used to > identify particular payloads and their semantics as they are transported > via application level protocols such as messaging (“email”) and the web > (HTTP). The core structure and use of media types is the MIME framework, > defined in RFCs 2045 through 2049, and amended by various later documents. > Registration of new media types is defined by BCP 13, which was last > updated in 2013. > Several topics have appeared in the interim that are large enough in scope > and importance to warrant the formation of a working group to develop and > process them. In particular, we have for the first time a request for a > new top-level media type, and such requests are sufficiently rare that our > current processes don’t make it clear how this request should be evaluated > and dispatched. It's not the first top-level type we've added: font - RFC 8081 - 2017 example - RFC 4735 - 2006 model - RFC 2077 - 1997 AFAICR the process for font went fairly smoothly - which is why I keep pointing to RFC 8081 as a model for how to do it - so I'm not sure there's a case to be made that we don't know how to do this. > This working group will therefore, under this instance of the charter, take > up the following work. The working group has discretion to order these as > appropriate. Strongly disagree. If the haptics work is time-sensitive - and I think there's a consensus that it is - the charter needs to say it comes first and will be completed before starting the other work. > Establish criteria and procedures for registering top-level media > types. In particular, specify whether these requests can be handled by the > current IANA media type review team, require IETF Consensus, or should > follow some other process. RFC 6838 is pretty clear on the process: New top-level types require a standards-track RFC. AFAIK nobody has argued that we need to revisit this approach; especially if we're concerned about getting haptics done in a timely way. As for criteria, I guess we could try and codify some, but again, timing. > Develop and process the pending ‘haptics’ top-level media type request, > based on draft-muthusamy-dispatch-haptics. +1 > Consider whether and how to permit multiple media type suffixes. I think this one is likely to be the most contentious by far, and should come last. > Consider any issues around media types for programming languages. +1 > Determine revised criteria regarding Security Considerations sections in > media type applications. Not what I proposed. I've used a checklist to evaluate security considerations for media types for years; in one of his registrations Eric Prud'hommeaux noted this and essentially suggested that it would be good to expose a more general version of it. (Actually, he suggested doing it in the form itself, but a checklist needs to come first.) So the task is to develop such a checklist, not to revise the criteria themselves. > Review the format of the media types registry itself. > It is expected that the working group will produce a document updating RFC > 6838 (BCP 13) as a result of the points above, and a “haptics” standards > track registration RFC. Any other work is out of scope. Strongly disagree. The only work I think this group should do that might possibly necessitate a revision to BCP 13 is the multiple suffix work. In the past we managed to add suffixes to media types without needing to revise the core specification; I don't think we should assume a revision is needed for this. > On completion of these goals, the working group will discuss whether it > would be appropriate for this to become a standing (perhaps usually > dormant) working group containing the expertise needed to repeat these > reviews periodically, and/or to handle those applications such as the > top-level request that are too large in scope for the IANA media type > review team. If so, the working group will negotiate a new charter > accordingly. OK... Maybe this is just me remembering things past that don't apply to the brave new IETF world, but I was under the impression that We Just Don't Do This. And if we're going to do this, we need to consider the alternatives (mailing list, directorate, ?) first. > Input Document(s): > - > draft-muthusamy-dispatch-haptics > Proposed milestones (target dates TBD): > - > draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for > approval (Proposed Standard) > - > RFC6838bis to the IESG for approval (BCP) From nobody Wed May 12 14:42:15 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEC13A494A for ; Wed, 12 May 2021 14:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k31HY6RpJoaX for ; Wed, 12 May 2021 14:42:03 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5B93A2447 for ; Wed, 12 May 2021 14:28:58 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id x17so8396986vsc.0 for ; Wed, 12 May 2021 14:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YXNOw/FWXWkCuqMVeyv0zO2iV3kXoqmmNGpM34KwEcs=; b=rQZCVnsLxMFue8svIJQTfLs+BYRYej9kPcBHMgtrrwHYqgfmRnRgfa6hKCgyxiWrLO hU+yKwE3FDJ3lW8fPsuo5NmaKVuMMSG+386noc+2sIq+5N4NX0+F8FunQ30IXMYG9/++ HoLQ9OspOm3a2tJdRkVDP301/8bWWqdcQV2D78RSXf4ajGQKuHGu0qoTxKQA/Zoq5cRK lLCg9eivTi9F85Q612sHn/YX5QVtaPDWPuovyKcmUibstiZ4tC2YxXbY6kBQkcSvJQ25 Ykp5thTcF3oMs45rK9QT1afnYTXM0M6WGGaZ3wITWuCAnszeZEaIwR5KjUGRQ7kbSi3k vZkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YXNOw/FWXWkCuqMVeyv0zO2iV3kXoqmmNGpM34KwEcs=; b=XuOQszM/MenbHOYvjHhdQxtuUZEElvyCdrm4KgLLfbKi8EhoZkOPeh2FN97WwGZ7ub 1nx7OD86Wh/xJEjZapv7cNRna13BGkuH94Yl76jPP23FAsvEZHchbdur+X+1Se9WDnDC a5unCbIIdRr9YhkRedTmVf3GroM/xYbgmuJwKw4mscrGF4aWJnTelHHaM3382t57IULH P/0owbufhZsd1CmECF85R199ocKJwDx/d91XIgMPDh5o3AyrPQ/790y7njPRjm/8oh0E o62ufKhzd2bbDoTMsPVvP5Kf3r8cVf0bLa6uC2BL3DlEWN6NRk26a1s1nndc4hjDJxEv PF1A== X-Gm-Message-State: AOAM533w0TyGu6NG4ET+YmwtytNPN1fOufFWRzPqWZP+YyxQaKY0rFbj qe4VqOBXmaHcA5iR1GRnP+mBf2WRXEsNijEB1BRcoCjwD5Q= X-Google-Smtp-Source: ABdhPJzrEV+VxUo/HEgd/VXVBOaWllBItXnJMgEZkmWi8fntx5FBESHWFNnIBntGA2G6ijVJXzniScc3nXP3LfDhTs0= X-Received: by 2002:a67:dc1:: with SMTP id 184mr5765770vsn.15.1620854936331; Wed, 12 May 2021 14:28:56 -0700 (PDT) MIME-Version: 1.0 References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> In-Reply-To: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> From: "Murray S. Kucherawy" Date: Wed, 12 May 2021 14:28:44 -0700 Message-ID: To: Ned Freed Cc: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000b66be605c228b24f" Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 21:42:14 -0000 --000000000000b66be605c228b24f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2021 at 12:52 PM Ned Freed wrote: > > Comments welcome, including my late-night choice of name. > > The name is fine. The rest... I'm afraid I have a lot of problems with it= . > That's OK, that's what feedback is for. I'd break my arm patting myself on the back if I somehow got this right on the first go. > Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group Charter= [DRAFT] > > > The IETF maintains a registry of media types and subtypes that are used > to > > identify particular payloads and their semantics as they are transporte= d > > via application level protocols such as messaging (=E2=80=9Cemail=E2=80= =9D) and the web > > (HTTP). The core structure and use of media types is the MIME framewor= k, > > defined in RFCs 2045 through 2049, and amended by various later > documents. > > Registration of new media types is defined by BCP 13, which was last > > updated in 2013. > > > Several topics have appeared in the interim that are large enough in > scope > > and importance to warrant the formation of a working group to develop a= nd > > process them. In particular, we have for the first time a request for = a > > new top-level media type, and such requests are sufficiently rare that > our > > current processes don=E2=80=99t make it clear how this request should b= e > evaluated > > and dispatched. > > It's not the first top-level type we've added: > [...] > Will edit accordingly. > This working group will therefore, under this instance of the charter, > take > > up the following work. The working group has discretion to order these > as > > appropriate. > > Strongly disagree. If the haptics work is time-sensitive - and I think > there's a > consensus that it is - the charter needs to say it comes first and will b= e > completed before starting the other work. > OK by me. Since I was under the mistaken impression that the process for making new top-level types was untried, this seemed to be the right ordering, but I'll adjust. ACK on the rest of your comments. I'll wait a day or so for other feedback to come in and then post a revision. > Establish criteria and procedures for registering top-level media > > types. In particular, specify whether these requests can be handled > by the > > current IANA media type review team, require IETF Consensus, or shou= ld > > follow some other process. > > RFC 6838 is pretty clear on the process: New top-level types require a > standards-track RFC. AFAIK nobody has argued that we need to revisit this > approach; especially if we're concerned about getting haptics done in a > timely > way. > > As for criteria, I guess we could try and codify some, but again, > timing. > I can soften this one. > Determine revised criteria regarding Security Considerations sections > in > > media type applications. > > Not what I proposed. I've used a checklist to evaluate security > considerations > for media types for years; in one of his registrations Eric Prud'hommeaux > noted > this and essentially suggested that it would be good to expose a more > general > version of it. (Actually, he suggested doing it in the form itself, but a > checklist needs to come first.) > > So the task is to develop such a checklist, not to revise the criteria > themselves. > Ack. > Review the format of the media types registry itself. > > > It is expected that the working group will produce a document updating > RFC > > 6838 (BCP 13) as a result of the points above, and a =E2=80=9Chaptics= =E2=80=9D standards > > track registration RFC. Any other work is out of scope. > > Strongly disagree. The only work I think this group should do that might > possibly necessitate a revision to BCP 13 is the multiple suffix work. In > the > past we managed to add suffixes to media types without needing to revise > the > core specification; I don't think we should assume a revision is needed f= or > this. > Fair enough. > > On completion of these goals, the working group will discuss whether it > > would be appropriate for this to become a standing (perhaps usually > > dormant) working group containing the expertise needed to repeat these > > reviews periodically, and/or to handle those applications such as the > > top-level request that are too large in scope for the IANA media type > > review team. If so, the working group will negotiate a new charter > > accordingly. > > OK... Maybe this is just me remembering things past that don't apply > to the brave new IETF world, but I was under the impression that > We Just Don't Do This. And if we're going to do this, we need > to consider the alternatives (mailing list, directorate, ?) first. > Just a straw man. I'm fine with those alternatives, although the mailing list(s) already exist (one for IETF, one for IANA). I'll wait a day or two for other comments to come in and then I'll post a revision. -MSK --000000000000b66be605c228b24f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 12, 2021 at 12:52 PM Ned Free= d <ned.freed@mrochek.com>= ; wrote:
> Comments welcome, including my late-night choice o= f name.

The name is fine. The rest... I'm afraid I have a lot of problems with = it.

That's OK, that's what feed= back is for.=C2=A0 I'd break my arm patting myself on the back if I som= ehow got this right on the first go.

> Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group Char= ter [DRAFT]

> The IETF maintains a registry of media types and subtypes that are use= d to
> identify particular payloads and their semantics as they are transport= ed
> via application level protocols such as messaging (=E2=80=9Cemail=E2= =80=9D) and the web
> (HTTP).=C2=A0 The core structure and use of media types is the MIME fr= amework,
> defined in RFCs 2045 through 2049, and amended by various later docume= nts.
> Registration of new media types is defined by BCP 13, which was last > updated in 2013.

> Several topics have appeared in the interim that are large enough in s= cope
> and importance to warrant the formation of a working group to develop = and
> process them.=C2=A0 In particular, we have for the first time a reques= t for a
> new top-level media type, and such requests are sufficiently rare that= our
> current processes don=E2=80=99t make it clear how this request should = be evaluated
> and dispatched.

It's not the first top-level type we've added:
[...]

Will edit accordingly.
=
> This work= ing group will therefore, under this instance of the charter, take
> up the following work.=C2=A0 The working group has discretion to order= these as
> appropriate.

Strongly disagree. If the haptics work is time-sensitive - and I think ther= e's a
consensus that it is - the charter needs to say it comes first and will be<= br> completed before starting the other work.

OK by me.=C2=A0 Since I was under the mistaken impression that the proce= ss for making new top-level types was untried, this seemed to be the right = ordering, but I'll adjust.

ACK on the rest= of your comments.=C2=A0 I'll wait a day or so for other feedback to co= me in and then post a revision.

>=C2=A0 =C2=A0 Establish criteria and procedures for registering top-lev= el media
>=C2=A0 =C2=A0 types.=C2=A0 In particular, specify whether these request= s can be handled by the
>=C2=A0 =C2=A0 current IANA media type review team, require IETF Consens= us, or should
>=C2=A0 =C2=A0 follow some other process.

RFC 6838 is pretty clear on the process: New top-level types require a
standards-track RFC. AFAIK nobody has argued that we need to revisit this approach; especially if we're concerned about getting haptics done in a= timely
way.

As for criteria, I guess we could try and codify some, but again,
timing.

I can soften this one.

>=C2=A0 = =C2=A0 Determine revised criteria regarding Security Considerations section= s in
>=C2=A0 =C2=A0 media type applications.

Not what I proposed. I've used a checklist to evaluate security conside= rations
for media types for years; in one of his registrations Eric Prud'hommea= ux noted
this and essentially suggested that it would be good to expose a more gener= al
version of it. (Actually, he suggested doing it in the form itself, but a checklist needs to come first.)

So the task is to develop such a checklist, not to revise the criteria
themselves.

Ack.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> >=C2=A0 =C2=A0 Review the format of the media types registry itself.

> It is expected that the working group will produce a document updating= RFC
> 6838 (BCP 13) as a result of the points above, and a =E2=80=9Chaptics= =E2=80=9D standards
> track registration RFC.=C2=A0 Any other work is out of scope.

Strongly disagree. The only work I think this group should do that might possibly necessitate a revision to BCP 13 is the multiple suffix work. In t= he
past we managed to add suffixes to media types without needing to revise th= e
core specification; I don't think we should assume a revision is needed= for
this.

Fair enough.


> On completion of these goals, the working group will discuss whether i= t
> would be appropriate for this to become a standing (perhaps usually > dormant) working group containing the expertise needed to repeat these=
> reviews periodically, and/or to handle those applications such as the<= br> > top-level request that are too large in scope for the IANA media type<= br> > review team.=C2=A0 If so, the working group will negotiate a new chart= er
> accordingly.

OK... Maybe this is just me remembering things past that don't apply to the brave new IETF world, but I was under the impression that
We Just Don't Do This. And if we're going to do this, we need
to consider the alternatives (mailing list, directorate, ?) first.

Just a straw man.=C2=A0 I'm fine with those= alternatives, although the mailing list(s) already exist (one for IETF, on= e for IANA).

I'll wait a day or two for other= comments to come in and then I'll post a revision.

-MSK
--000000000000b66be605c228b24f-- From nobody Wed May 12 16:59:31 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1263A1B47 for ; Wed, 12 May 2021 16:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnD8ytEnzPkW for ; Wed, 12 May 2021 16:59:24 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400139.outbound.protection.outlook.com [40.107.140.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDD73A1B40 for ; Wed, 12 May 2021 16:59:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tgg/Cg3bVVXCsFdPQWgxk8CJ2uFU824rZcH2btsUBpYiU/cvQqcH0k4s732k8mBmglBZeJG427Ui52oLhM9wz5JzltUlhlw+IgrcNJ/2eX5FVXsGSfx+Gbrp5ebN3CQQsQGrgtD5SKmWoxpB/UBHttKk+iiBjTUUF75i487UbAw/EpEKO/fdpKZzxCWmwAuKa79Ya7RHst+l4zZ7LpWsMZc1hiI1LwZl+we/jnuU8/IwdvAnLgDIok2pu+V/kySAJcTbs85dboCTspZ49M6m5altQwQgF2veY30mWP+jKJ1ueUL6dopVc6zKXoea9uNMugpejueF7gj3HQ+QzlfHSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gmZCXeA9GRofmS7oDlT72yWx3j8R3vLwE0mWxxNnpxw=; b=VqKhU4tCFeia7L9f0dpxyKHbiGq4qcBDIT/Cpb9RrVBjCIgsQ4305WdRg9FeV/G0BptWrhSKvsr9K3AiJPnn8CH/CpTqX6kgAf+ClxqFf0QchHGpmWwfggdHVoJWzC8Q3hxvlj+GD+LzEsJTeiN1gbJKUhLH4bBN8AOSrM7z05VmifQaQTTxMh8qJQ3sjVIdTI/Lxh2zB6paL2DRj/gGbIxDd9wXbnK5Uno++liFrnEg2F28r+djcSeki/pgWsH3/b49ERWTFRHZSUyR1W48pw3cM/Emyys8AK/rFljpTMh5mbVPB7xiqR7x/VWu8zYWr27Awx0cM/6nf0bwZvZbHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gmZCXeA9GRofmS7oDlT72yWx3j8R3vLwE0mWxxNnpxw=; b=g02eoZn4lUDXaRCW7jYTKJdxK8tsLVqoqbFxknXV4oP+zGUTgLPlseBuaWszx6/kOaSWyMIvd0dfjA/lnQuxjxr0dFeg6Y2mKsTNhSeoraNJ/sxdlXX24woQ0WVB6nX9uXo9qa/42ePa4Gx0KvWc2QuPxEbZiZuWK69e/5fY97g= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY1PR01MB1497.jpnprd01.prod.outlook.com (2603:1096:403:5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.29; Wed, 12 May 2021 23:59:21 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511%5]) with mapi id 15.20.4129.026; Wed, 12 May 2021 23:59:21 +0000 To: Ned Freed , "Murray S. Kucherawy" Cc: DISPATCH list References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <425a2f50-7431-a8d5-8d00-207b1a0fdcdd@it.aoyama.ac.jp> Date: Thu, 13 May 2021 08:59:18 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 In-Reply-To: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [114.185.21.49] X-ClientProxiedBy: TYAPR01CA0079.jpnprd01.prod.outlook.com (2603:1096:404:2c::19) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (114.185.21.49) by TYAPR01CA0079.jpnprd01.prod.outlook.com (2603:1096:404:2c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Wed, 12 May 2021 23:59:20 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 261bc245-5d9d-47eb-cf40-08d915a1f5d5 X-MS-TrafficTypeDiagnostic: TY1PR01MB1497: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NS2z8/FIq/+L51oqM0EL96Up3hExsW36Vyppp6mRAfdtijX+5Io3UAQmVNFV7ksdb1pRmnVdACbgdMLCiAaFaGKSqdahzHQ7fuiBrCOLcA3+Xjy0+SYlvvWewpXtoZLPNk1wIzF40yf1r8BufB9tRUzY64gsP+z5o/xL3QWrpRHYLHoAE+IRdL/JePpb8c72+dAvCjNI1HUzI2qP/gGRha8L6bTpOl9YNFiou6dX7ZOu//yJsL4qgO1mBf8GU8oYOoNz/pdGVsYat/C+puIHIohMGmeN4AtLWV55YmSnYyI/q2r7Y1UCM9Ggndzf3KMLksh0IuyWfIyoDEB6MpTc6897LYP+Sfw9HbJU9un/TbN1aVjSBkz2PbjDiwf67jGLUlnd83Yx5sXfudgpTszOPt0L7HoMc0XiCNbmc/tpmp8aj/+Mrxf0CjHC0uLiUeaQnhm8GvpFJ81UfEI5cv/PpfKR5ARzmS3H6FXsVylXQLmakJGDN2VqxQ2P6+695iblH/lSiSbPvnJ3yT/b9YWu1C08aMOs0ze7ZXsajC3Hbp8uG2+STMJVetd1IqAX+tX2ccK3Tl2goNpa4eIkqgrXcuHPGL3pIuyGJxEYHT1ZvVEhRa4Goh292f8UPubM+GmPunmizHqWAljL+ivTS8woVxpdOAfbVcpJwsqmv2mgtVsihIwi03z/0KnqTGjNeuLsLSW+DTvi+jZ9/nOEhpxJHkQpdwGZz+DrfSb71xvTmYveIkdRrAyFVI+P+rIoki70c2bZk0R7AzLfzV1QH14FJK27MQFgfi5xdl9L87SME/0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(346002)(376002)(396003)(366004)(136003)(786003)(110136005)(6486002)(316002)(16576012)(5660300002)(8936002)(2616005)(956004)(8676002)(16526019)(186003)(31696002)(53546011)(38350700002)(478600001)(52116002)(966005)(36916002)(83380400001)(2906002)(66556008)(66476007)(66946007)(31686004)(4326008)(38100700002)(26005)(86362001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ejdrWlVRU2ZPZkovZGdVMG9EN1c3S1FKeHdyeVdIR09hTzk2cFN4eHExeDN0?= =?utf-8?B?RXdteWFTZnFSM2xnTWt4aU1JeGpqRkhwNWlaTTJyeng0ZzdoMzNTTmFOd2NY?= =?utf-8?B?b1pTUXVmRHdIUUYreE5ZNWNvaFdydGxvaVUxUDNsQXZ6VHkyWkFYL2E5U29V?= =?utf-8?B?Sk0wQnE4TEh6WE93T1hHRlM0MkpvTDZ4OWs3M3Vub21iclF3Q1FueTd6NnRL?= =?utf-8?B?V1dUN0Y0R1FOMU9FMXZPNzFTYitGY1c4ckptbHVmeG13Q2luWGhlS1BLSjFU?= =?utf-8?B?VUNTZXp6Q3Y2aVNQS1VWVXYrN3E2YjBIWENGdmpVSTk4TEdTVVIxMStpd0Nh?= =?utf-8?B?M2Fkd2xUU2h4b0hCNE9IQ24vNVI5bmVZeWlvN2FQMDdtK2VHMlNVV1UwWUVB?= =?utf-8?B?UnRFdm55emZ0cnMyUHJQYmF2bmU0cS9QSy9JVUtVQmxXY0VsZ09lVHhiOXlu?= =?utf-8?B?K01PZWRubkVkazRuOE1XVS9WaEQ4L2FzdWUvZlFIek82N1VaZjkxSDNBbVFP?= =?utf-8?B?M242THpjdUJON1RuSy9aUjdlYklvRmJ5Rml4Y0p2QzNrWWNrdlI1OHFwUnhh?= =?utf-8?B?ZEdrWkRVbGsvdzJjR1RKQWwzWTRualZMU3pPQjBpaFozZ1d2S3N3QWRnKzV1?= =?utf-8?B?czdITW9lZktCUkpTK29hV0RQaGNKZ0l6d3h1Z2JOcDVpUEhvcnNKSjBLS1ZO?= =?utf-8?B?dUdqT2tNazRvamRUU0dxRHptSUZrdGxONERuRncxM2xTaUc2M2prSStFODZi?= =?utf-8?B?d1h1QXFxdklQTFdib3BDbGpMamRidFJSK1FFL1MrYUlXZTFVS1B3R0x2a1lC?= =?utf-8?B?d0gwRU1LTFVBdmdjblIvOWMxdnBIaUF4c2lYYUROc2xVY1g1ajJlb2cxdktX?= =?utf-8?B?OE9EM0NGTnBDQUZibEFUUiswZHpNRGwzZDk4Mko1NEtld2taZnpOdml5Zkow?= =?utf-8?B?b0IwaWVJY2dqS2hPRXJEZDJ4UlRHTTNrbUNNZDEvTWR2ekpxR2lCKzFoaHJK?= =?utf-8?B?L2tFcng2WUdYekhFM2hoTkRJME1VQWk5VCtuRU5vZjRVRHl1RDVFZmpZL3Bl?= =?utf-8?B?OG9SamN0L3Y5V1paVEtNVERiSG5XQW9pZHErd0ZyOUJvbDIvREJ4Q0Fla0FK?= =?utf-8?B?TTFaWUF3Qkgwc3RqeEduNG04NTdTaktSa0RtVHB1MmZxYy9QUUtxYlhaSkFo?= =?utf-8?B?Ukc1ZVROZEhsaUVFTDgwL0plTE45YjZoa0xkNTh5RUdVRXdlOHk1dnJqbE90?= =?utf-8?B?Ui9XTEhoUko2djdYRWg3cWJEU1pCbTZRQThLWVFkSkhTWlRsL2dyWmhpWno2?= =?utf-8?B?dXZQMUtRRGZYcWRoeFd4cERTZGxaVHZYempSR3FoS2JvaWVFaWVDL1pJT2U1?= =?utf-8?B?ZWJYOGUxQ0NOYm1xbXZwUWU4VjVNbUN0R1pOdndtR3NlZlRLMytUKzFuRTdG?= =?utf-8?B?ZTcvL0l4TnhydlFvemk1bnZ6Wm5XcHVnQllXYStPbTZHcXB1dTZaVlVlVkt3?= =?utf-8?B?RkQrdkl5TGladVRIZ09UbnR0WFFSb0poVzJ5a0oyY21IN2xqMVNZakJIdmdz?= =?utf-8?B?N01uMjBtWXFWVWcrL2VWQ3lOQ1l0MHcvUUJIZE9PUkRIa0VEYW1PWHJ2KzJz?= =?utf-8?B?VnFtTzFGb2ZtY0JKZzVETVdobUhTZ0RKd1llV2FLNGI2VU5qMU9RTFVwZlMz?= =?utf-8?B?Rklvck0ybnRlYjhFQjFIMXc3a20zaGM5djIwOW9Nam8wNnVTQUhzVzNoTjIr?= =?utf-8?Q?iShAbMB7v1XsQT0/EtZ5JrlB/KKNLsd1h3q6FIS?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 261bc245-5d9d-47eb-cf40-08d915a1f5d5 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2021 23:59:21.0901 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +RbDYa8PaQTkXmpFNdgQfdGRFCqBrEcj3iH03BzaDDamOww6+TmzHd6HyzywhgScHfdqBwEIUOTOmfusNmQQbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1497 Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 23:59:29 -0000 Hello Ned, Murray, others, On 2021-05-13 03:53, Ned Freed wrote: >> Comments welcome, including my late-night choice of name. > > The name is fine. The rest... I'm afraid I have a lot of problems with it. > >> -MSK > >> Media Type Maintenance (“MEDIAMAN”) Working Group Charter [DRAFT] > >> The IETF maintains a registry of media types and subtypes that are used to >> identify particular payloads and their semantics as they are transported >> via application level protocols such as messaging (“email”) and the web >> (HTTP). The core structure and use of media types is the MIME framework, >> defined in RFCs 2045 through 2049, and amended by various later documents. >> Registration of new media types is defined by BCP 13, which was last >> updated in 2013. > >> Several topics have appeared in the interim that are large enough in scope >> and importance to warrant the formation of a working group to develop and >> process them. In particular, we have for the first time a request for a >> new top-level media type, and such requests are sufficiently rare that our >> current processes don’t make it clear how this request should be evaluated >> and dispatched. > > It's not the first top-level type we've added: > > font - RFC 8081 - 2017 > example - RFC 4735 - 2006 > model - RFC 2077 - 1997 > > AFAICR the process for font went fairly smoothly - which is why I keep pointing > to RFC 8081 as a model for how to do it - so I'm not sure there's a case to be > made that we don't know how to do this. RFC 8081 is definitely a very good model. In particular, it contains a whole series of subtype registrations. As to "fairly smoothly", it actually took a long time, mostly to find the right editor (Chris Lilley) and to get the relevant community behind it. That happened in the context of the Web Font work at W3C. >> This working group will therefore, under this instance of the charter, take >> up the following work. The working group has discretion to order these as >> appropriate. > > Strongly disagree. If the haptics work is time-sensitive - and I think there's a > consensus that it is - the charter needs to say it comes first and will be > completed before starting the other work. > >> Establish criteria and procedures for registering top-level media >> types. In particular, specify whether these requests can be handled by the >> current IANA media type review team, require IETF Consensus, or should >> follow some other process. > > RFC 6838 is pretty clear on the process: New top-level types require a > standards-track RFC. AFAIK nobody has argued that we need to revisit this > approach; especially if we're concerned about getting haptics done in a timely > way. > > As for criteria, I guess we could try and codify some, but again, > timing. Agree with Ned here. >> Develop and process the pending ‘haptics’ top-level media type request, >> based on draft-muthusamy-dispatch-haptics. > > +1 I think it's okay as written. It might be appropriate to mention interactions with other types (audio, video,.. have been mentioned). >> Consider whether and how to permit multiple media type suffixes. > > I think this one is likely to be the most contentious by far, and should come > last. I'm not really sure this has to be contentious. And the communities who want it may also have some timing preferences. Anyway, while we are at it, can we make sure an announcement of this charter proposal (or a next version) also goes to media-types@ietf.org, because some people interested in this work may be on that list but not (yet) on the dispatch list. >> Consider any issues around media types for programming languages. > > +1 > >> Determine revised criteria regarding Security Considerations sections in >> media type applications. > > Not what I proposed. I've used a checklist to evaluate security considerations > for media types for years; in one of his registrations Eric Prud'hommeaux noted > this and essentially suggested that it would be good to expose a more general > version of it. (Actually, he suggested doing it in the form itself, but a > checklist needs to come first.) > > So the task is to develop such a checklist, not to revise the criteria > themselves. > >> Review the format of the media types registry itself. > >> It is expected that the working group will produce a document updating RFC >> 6838 (BCP 13) as a result of the points above, and a “haptics” standards >> track registration RFC. Any other work is out of scope. > > Strongly disagree. The only work I think this group should do that might > possibly necessitate a revision to BCP 13 is the multiple suffix work. In the > past we managed to add suffixes to media types without needing to revise the > core specification; I don't think we should assume a revision is needed for > this. Wasn't there also talk about tweaking the registration template, to adjust for changes in how file types are handled on various operating systems? Not sure which document that would affect. >> On completion of these goals, the working group will discuss whether it >> would be appropriate for this to become a standing (perhaps usually >> dormant) working group containing the expertise needed to repeat these >> reviews periodically, and/or to handle those applications such as the >> top-level request that are too large in scope for the IANA media type >> review team. If so, the working group will negotiate a new charter >> accordingly. > > OK... Maybe this is just me remembering things past that don't apply > to the brave new IETF world, but I was under the impression that > We Just Don't Do This. And if we're going to do this, we need > to consider the alternatives (mailing list, directorate, ?) first. I agree with Ned. Regards,   Martin. >> Input Document(s): > >> - > >> draft-muthusamy-dispatch-haptics > > >> Proposed milestones (target dates TBD): > >> - > >> draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for >> approval (Proposed Standard) >> - > >> RFC6838bis to the IESG for approval (BCP) > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu May 13 02:08:57 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DAF3A14C1; Wed, 12 May 2021 13:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b60gf_hPzwKe; Wed, 12 May 2021 13:37:08 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDB43A14C0; Wed, 12 May 2021 13:37:07 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id z4so1835879pgb.9; Wed, 12 May 2021 13:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=LIptAzrbQ2CbV53YI/cDu8/ZZxP8ZY2MRGDcdGPP/ek=; b=vE7Ot+yoTKhLG1lbET6tiGq0oiu6JI1Uvnrl09jsTbsIL8rnCbVCn3bOD8vomjs14n THVxXTzgua2FmUZtnDlH0PzQO0HPZWX/BdcMzfFglNGDaqbqJCcEiavdMebSbns5Fkxs hwlADqiaUCpvT/1UIA8v5tgvynNPrZGZfYupLu7vs+4c4ucX9I0kIKvbzDxajCOC2GSz sRG0HmIKvISzJzT+g0gFz8NQxV8C2XyOFPB4Cj+5OUbtbuZjvnQgJX7cToUme2hJS/PD qJ6LJ89O/Pvyju6jfjoPjLrxHzAEdoOmQcxh1Gu/88CkaFenVnAEoysja0eTAJ2uxfk6 8FpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=LIptAzrbQ2CbV53YI/cDu8/ZZxP8ZY2MRGDcdGPP/ek=; b=E2332kRV/5rr8WuL/xIb6dxgZi5TkF2EXf34xq8lBDZ+tZiJXOrWBG34TSoS+TGnJZ n85fLkrOmvRx/S3nL+j4Y6qx1riG/60VEmMljv0Hl84oRuY+JbA9lHXPhpVyThj3J8xv YrLGvcYkOKk3Hv0JyL6FeQ+ds4EOX0FJQeBUC1+xutUbotQHV1ieowZbjBBMbQ8ymGfT F9mhO2Dz4staR0UCtyELVolVAGhd0ZV1e8pYGlaxC6Rmfr6AQQR1QXgTxNgdYiODR4oF AG5YtAZORbCNKDfdjWZvrEElzW6YzJIkFA5zgum/Xbby4ku5q7w4Bc4sv7mZGh+491/r tYOQ== X-Gm-Message-State: AOAM5324ywUj6zU8WqBM5RgvmYEpxMlsfErnAfRpckQbOduZ61mJl92d dmprTdQoQZbJGfeVAAu8Z24fNpzL82PqAQ== X-Google-Smtp-Source: ABdhPJxWfB9YJB3Zwn5gW2wZmfHFZhSJZPKPgDtWX8unaPNYiWACvSwn1iYPU+lquMjpmRAFzGmlvw== X-Received: by 2002:a05:6a00:1384:b029:2c7:fcda:8d83 with SMTP id t4-20020a056a001384b02902c7fcda8d83mr11929967pfg.0.1620851824320; Wed, 12 May 2021 13:37:04 -0700 (PDT) Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id 145sm555626pfv.196.2021.05.12.13.37.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 May 2021 13:37:03 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Murray S. Kucherawy'" , "'John C Klensin'" Cc: , , "'Ted Hardie'" , "'Dispatch WG'" , "'dispatch chairs'" , "'Applications and Real-Time Area Discussion'" , "'Yeshwant Muthusamy'" , "'ART ADs'" References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> In-Reply-To: Date: Wed, 12 May 2021 13:37:02 -0700 Message-ID: <00b101d7476e$91663c10$b432b430$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B2_01D74733.E5095FE0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHvR5ssnw30Iyh7RMbPKsDCv1OzSAGGrkhhAgyvmccCeAFkhAJ/r0FPAZpu5zoAcmJ+5gJteYJ6Ad2317EBINg8DAKhVl8oqhsZqWA= Content-Language: en-us Archived-At: X-Mailman-Approved-At: Thu, 13 May 2021 02:08:54 -0700 Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 20:37:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B2_01D74733.E5095FE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Until there is a draft charter and so on, which list should be used to = discuss the subject? =20 What good is any top level type? What good could it be if we could = just change everything? Is there a path from current state to that = destination? =20 For example, a new top-level type could give some clear advantage in = content negotiation. You ask for a thing with some Accept headers, and = you expect it to return with something that is acceptable, and the = top-level type gives some useful information about the request and/or = response). =20 It could provide a standard for fragment identifiers when applied to all = subtypes, for example, time management =E2=80=93 you could, given a URL = for all timed media could use #start=3D22.30:end=3D25.15 as a fragment = identifier no matter whether video, audio, haptics, 3d, timed = text/captions. Or a =E2=80=9CDocument=E2=80=9D top level type could indicate = common fragment components for citations, doi=E2=80=99s, pdfs, ebook to = access metadata. =20 I=E2=80=99m not seeing a use case for haptics/mp9 (or haptics/whatever), = though. =20 -- https://LarryMasinter.net = https://interlisp.org =20 From: art On Behalf Of Murray S. Kucherawy Sent: Thursday, May 6, 2021 12:34 PM To: John C Klensin Cc: draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org; Ted = Hardie ; Dispatch WG ; dispatch = chairs ; Applications and Real-Time Area = Discussion ; Yeshwant Muthusamy = ; ART ADs Subject: Re: [art] [dispatch] Status of Haptics I-D in DISPATCH? =20 Hi all, =20 Thanks for this discussion. At a minimum, it reaffirms my decision not = to sponsor this myself. :-) =20 Francesca and I talked about it this morning after the IESG call, and = decided that I'll take up the pen to write a draft charter based on this = thread and circulate it for comments. Stay tuned. =20 -MSK =20 =20 On Tue, May 4, 2021 at 6:16 PM John C Klensin > wrote: Yeshwant, Thanks. And thanks for confirming. I think I've said as much as I can usefully say on the subject. best wishes, john --On Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy > wrote: > John, >=20 >=20 >=20 > Thanks for the note. Taking each one of your two questions in > order: >=20 >=20 >=20 >>> * Does the ISO FDIS mention "haptics/" as top-level media >>> type? >=20 >>> If it does, that is a major IETF (and probably IAB) strategy >>> question, not really a media registration one. >=20 >>> And that question includes my concern about precedents of >>> other SDOs squatting on names without including us actively >>> in the development process. >=20 >=20 >=20 > No. The ISOBMFF FDIS does not mention 'haptics/' as top-level > media type. That said, it treats haptics in exactly the same > way that it treats other top-level media types in Chapter 12 > (audio, video, text, font, etc.) that have been recognized as > top-level media types by IETF. To be more specific, our > haptics proposal to ISOBMFF follows the same box hierarchy as > the other top-level types: >=20 > * Media handler is 'hapt' > * Haptic Media Header is the NullMediaHeaderBox > * Sample entry is the HapticSampleEntry >=20 >=20 >=20 > So, there is no issue of ISO squatting on the 'haptics/' name > or shutting IETF out from the development process. Our > objective was to first introduce haptics as a top-level media > type in ISOBMFF and then approach IETF with the proposal that > we have in our I-D. For obvious reasons, I am unable to share > the DAMD or FDIS documents on this mailing list, but I suspect > those who are also members of MPEG can get access to it easily. >=20 >=20 >=20 >>> * If the answer to that is "no", are there objections to >>> more or less the WG approach Ned suggested that do not rely >>> on the "influence the work of other SDOs" argument? >=20 >=20 >=20 > Like I've said before, I am open to whatever mechanism the > IETF decides to use to move the I-D forward. Given the work > that has already been done in MPEG and the fact that we are > approaching the FDIS ballot completion stage, I would assume > that the IETF would take that into account *in some form* as > it discusses the technical merits of the I-D. >=20 >=20 >=20 > Thanks, >=20 > Yeshwant >=20 >=20 >=20 > Yeshwant Muthusamy, Ph.D. | Senior Director, Standards >=20 >=20 >=20 > ymuthusamy@immersion.com | +1 = 469-583-2171 >=20 >=20 >=20 > -----Original Message----- > From: John C Klensin > > Sent: Tuesday, May 4, 2021 2:12 PM > To: Yeshwant Muthusamy >; Ted Hardie > > Cc: Dispatch WG = >; > dispatch-chairs@ietf.org ; = Applications and Real-Time Area > Discussion >; ART ADs = >; > draft-muthusamy-dispatch-haptics@ietf.org = ; = media-types@ietf.org =20 > Subject: RE: [art] [dispatch] Status of Haptics I-D in > DISPATCH? >=20 >=20 >=20 > Yeshwant, >=20 >=20 >=20 > Thanks. I did see your response to Ned, but only after > sending my note. >=20 >=20 >=20 > In what is perhaps an odd way, from my point of view, this is > a good news. If the document is in FDIS ballot, all of the > suggestions on the this list about how the IETF needs to be > involved, and involved, with some accelerated procedure in > order to influence the substantive decisions of other > standards bodies are moot: as I am sure you know, just about > the one way to make a substantive change in an ISO FDIS > document is a "no" vote from a national member body, > presumably after either objecting all along (which I presume > didn't happen) or discovering some catastrophic substantive > problem. No room for a "we think it would be better to do > this than that" intervention from the IETF. >=20 >=20 >=20 > So the only issues relevant to other SDOs now, AFAICT, is > what, if anything, those documents (which, sadly, I don't have > time to read and study today or even this week) have to say > about media type names. If the answer is that they don't say > anything, then the IETF should move with appropriate > diligence, but should not put "get it done quickly" ahead of > "do it right and get it right". If they say "the media type > is 'haptics/', then the IETF is essentially dealing, not with > your I-D/ proposal but with an accomplished fact. That would > present us with a very different, and unpleasant, situation > although, using an extension of Ted's argument, I think some > of us would argue for registering it and trying to figure out > how to avoid that happening again. If it references the I-D, > I suspect we could get a note to the editorial team at ISO /CS > and/or to the relevant Committee Manager and secretariat about > getting that fixed even after FDIS balloting was completed > (and might get our >=20 > way) but whether that would be of substantive importance given > that there is no chance of giving them a stable RFC number as > a reference is, well, questionable. >=20 >=20 >=20 > So now, with the "need to do this quickly to influence the > substantive decisions of other SDOs" and the "the IETF needs > to be influential about this in order to remain an actor in > the multimedia game" aside because, whatever the IETF decides > to do about those issues neither they, nor your I-D, have > much, if anything, to do with them, it seems to me there are > only two questions for the near term: >=20 >=20 >=20 > * Does the ISO FDIS mention "haptics/" as top-level media type? >=20 > If it does, that is a major IETF (and probably IAB) strategy > question, not really a media registration one. And that > question includes my concern about precedents of other SDOs > squatting on names without including us actively in the > development process. >=20 >=20 >=20 > * If the answer to that is "no", are there objections to more > or less the WG approach Ned suggested that do not rely on the > "influence the work of other SDOs" argument? >=20 >=20 >=20 > thanks, >=20 > john >=20 >=20 >=20 > --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy > = >> > wrote: >=20 >=20 >=20 >> John, >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Regarding your comment: >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>>> One reason is that I think it would be really unfortunate to >=20 >>>> establish a precedent that the way to get a top-level media >>>> type is >=20 >>>> to invoke work going on at >=20 >>=20 >=20 >>>> what I understand to be essentially the WG level in another >>>> SDO and >=20 >>>> then plead urgency. >=20 >>=20 >=20 >>>> I would feel somewhat differently about an established, >>>> recognized, >=20 >>>> deployed international standard, but, as I understand >>>> "active work >=20 >>>> in .. >=20 >>=20 >=20 >>>> MPEG Systems File Format sub-group", this is fairly far >>>> from that. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> I would just reiterate/summarize what I wrote in my response >> to Ned's >=20 >> comment that you might have missed: the haptics proposal in >> MPEG is no >=20 >> longer at the "WG level" in the MPEG Systems File Format >> sub-group. It >=20 >> just progressed to FDIS ballot at MPEG134, which should >> complete by >=20 >> July 2021, at which point progression to IS (International >> Standard) >=20 >> is just a matter of procedure. More to the point, it has >> passed two >=20 >> rounds (CDAM and DAMD) of international balloting, with over >=20 >> 20 ISO National Bodies casting their ballots in each round. No >=20 >> objections to the haptics proposal were received in either >> round. The >=20 >> proposal left the "WG level" after MPEG131 in July >=20 >> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot >> after >=20 >> MPEG132 in October 2020 - a fact that was indeed mentioned in >> v01 of >=20 >> the I-D. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> The ISO link to the DAMD is here: >=20 >> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A% = =20 >> 2F%2Flink >=20 >> protect.cudasvc.com = %2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.o >> rg%252fst >=20 >> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs >> KcfbpK8nr >=20 >> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp >> REaQwDMRV >=20 >> d7M%2C%26typo%3D1&data=3D04%7C01%7C%7C98c8e2a934bf4973859d0 >> 8d90f309c >=20 >> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331 >> 34949%7CU >=20 >> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB >> TiI6Ik1ha >=20 >> WwiLCJXVCI6Mn0%3D%7C2000&sdata=3D%2BufQx8YrBdXpXyihiMQXkoVk >> uVKQ6A5E3 >=20 >> Qz3BQ97HVs%3D&reserved=3D0> on.outloo >=20 >> k.com/?url=3Dhttps%3A%2F%2Fnam10.safelink%2F = &data=3D04%7C01%7 >> C%7C98c8e >=20 >> 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb >> 5%7C0%7C1 >=20 >> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA >> wMDAiLCJQ >=20 >> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dy >> JoFSrPdS6 >=20 >> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&reserved=3D0 >=20 >> s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iso.org%2Fstan = = =20 >=20 >> dard%2F81604.html&data=3D04%7C01%7C%7Cb9be185f21b44df1b2f708d90e >=20 >> 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966 >=20 >> 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >=20 >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DqwZKX%2B26U >=20 >> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=3D0>. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> To be clear, I have no issues with the other points you raise. >=20 >> Just want to make sure that the discussion is based on current >=20 >> reality. >=20 >=20 >=20 >=20 ------=_NextPart_000_00B2_01D74733.E5095FE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Until there is a draft charter and so on, which list = should be used to discuss the subject?

 

What good is = any top level type?=C2=A0=C2=A0 What good could it be if we could just = change everything? Is there a path from current state to that = destination?

 

For example, =C2=A0a new top-level type could give = some clear advantage in content negotiation. You ask for a thing with = some Accept headers, and you expect it to return with something that is = acceptable, and the top-level type gives some useful information about = the request and/or response).

 

It could = provide a standard for fragment identifiers when applied to all = subtypes, for example, time management =E2=80=93 you could, given a URL = for all timed media could use #start=3D22.30:end=3D25.15 as a fragment = identifier no matter whether video, audio, haptics, 3d, timed = text/captions.

= =C2=A0=C2=A0=C2=A0=C2=A0Or=C2=A0 a =E2=80=9CDocument=E2=80=9D top level = type could indicate common fragment components for citations, = doi=E2=80=99s, pdfs, ebook to access metadata.

 

I=E2=80=99m = not seeing a use case for haptics/mp9 (or haptics/whatever),=C2=A0 = though.

 

--

https://LarryMasinter.net https://interlisp.org

 

From: art = <art-bounces@ietf.org> On Behalf Of Murray S. = Kucherawy
Sent: Thursday, May 6, 2021 12:34 PM
To: = John C Klensin <john-ietf@jck.com>
Cc: = draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org; Ted = Hardie <ted.ietf@gmail.com>; Dispatch WG = <dispatch@ietf.org>; dispatch chairs = <dispatch-chairs@ietf.org>; Applications and Real-Time Area = Discussion <art@ietf.org>; Yeshwant Muthusamy = <ymuthusamy@immersion.com>; ART ADs = <art-ads@ietf.org>
Subject: Re: [art] [dispatch] Status = of Haptics I-D in DISPATCH?

 

Hi = all,

 

Thanks for this discussion.  At a minimum, it = reaffirms my decision not to sponsor this myself.  = :-)

 

Francesca and I talked about it this morning after the = IESG call, and decided that I'll take up the pen to write a draft = charter based on this thread and circulate it for comments.  Stay = tuned.

 

-MSK

 

 

On = Tue, May 4, 2021 at 6:16 PM John C Klensin <john-ietf@jck.com> = wrote:

Yeshwant,

Thanks.  And thanks = for confirming.  I think I've said as much
as I can usefully say = on the subject.

best wishes,
   john


--On = Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy
<ymuthusamy@immersion.com> wrote:

> = John,
>
>
>
> Thanks for the note. Taking = each one of your two questions in
> order:
>
> =
>
>>> * Does the ISO FDIS mention = "haptics/" as top-level media
>>> type?
> =
>>> If it does, that is a major IETF (and probably IAB) = strategy
>>> question, not really a media registration = one.
>
>>> And that question includes my concern = about precedents of
>>> other SDOs squatting on names = without including us actively
>>> in the development = process.
>
>
>
> No. The ISOBMFF FDIS does = not mention 'haptics/' as top-level
> media type. That said, it = treats haptics in exactly the same
> way that it treats other = top-level media types in Chapter 12
> (audio, video, text, = font,  etc.) that have been recognized as
> top-level media = types by IETF. To be more specific, our
> haptics proposal to = ISOBMFF follows the same box hierarchy as
> the other top-level = types:
>
>   *   Media handler is = 'hapt'
>   *   Haptic Media Header is the = NullMediaHeaderBox
>   *   Sample entry is the = HapticSampleEntry
>
>
>
> So, there is no = issue of ISO squatting on the 'haptics/' name
> or shutting IETF = out from the development process. Our
> objective was to first = introduce haptics as a top-level media
> type in ISOBMFF and then = approach IETF with the proposal that
> we have in our I-D. For = obvious reasons, I am unable to share
> the DAMD or FDIS documents = on this mailing list, but I suspect
> those who are also members = of MPEG can get access to it easily.
>
>
> =
>>> * If the answer to that is "no", are there = objections to
>>> more or less the WG approach Ned suggested = that do not rely
>>> on the "influence the work of = other SDOs" argument?
>
>
>
> Like I've = said before, I am open to whatever mechanism the
> IETF decides to = use to move the I-D forward. Given the work
> that has already = been done in MPEG and the fact that we are
> approaching the FDIS = ballot completion stage, I would assume
> that the IETF would take = that into account *in some form* as
> it discusses the technical = merits of the I-D.
>
>
>
> Thanks,
> =
> Yeshwant
>
>
>
> Yeshwant Muthusamy, = Ph.D. | Senior Director, Standards
>
>
>
> ymuthusamy@immersion.com | +1 469-583-2171
> =
>
>
> -----Original Message-----
> From: John = C Klensin <john-ietf@jck.com>
> Sent: Tuesday, May = 4, 2021 2:12 PM
> To: Yeshwant Muthusamy <ymuthusamy@immersion.com>; Ted Hardie
> = <ted.ietf@gmail.com> Cc: Dispatch WG <dispatch@ietf.org>;
> dispatch-chairs@ietf.org; Applications and = Real-Time Area
> Discussion <art@ietf.org>; ART ADs <art-ads@ietf.org>;
> draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org
> Subject: RE: [art] = [dispatch] Status of Haptics I-D in
> DISPATCH?
>
> =
>
> Yeshwant,
>
>
>
> = Thanks.  I did see your response to Ned, but only after
> = sending my note.
>
>
>
> In what is perhaps = an odd way, from my point of view, this is
> a good news.  If = the document is in FDIS ballot, all of the
> suggestions on the = this list about how the IETF needs to be
> involved, and involved, = with some accelerated procedure in
> order to influence the = substantive decisions of other
> standards bodies are moot: as I = am sure you know, just about
> the one way to make a substantive = change in an ISO FDIS
> document is a "no" vote from a = national member body,
> presumably after either objecting all = along (which I presume
> didn't happen) or discovering some = catastrophic substantive
> problem.  No room for a "we = think it would be better to do
> this than that" intervention = from the IETF.
>
>
>
> So the only issues = relevant to other SDOs now, AFAICT, is
> what, if anything, those = documents (which, sadly, I don't have
> time to read and study = today or even this week) have to say
> about media type = names.  If the answer is that they don't say
> anything, then = the IETF should move with appropriate
> diligence, but should not = put "get it done quickly" ahead of
> "do it right = and get it right".  If they say "the media type
> = is 'haptics/', then the IETF is essentially dealing, not with
> = your I-D/ proposal but with an accomplished fact.  That = would
> present us with a very different, and unpleasant, = situation
> although, using an extension of Ted's argument, I = think some
> of us would argue for registering it and trying to = figure out
> how to avoid that happening again.  If it = references the I-D,
> I suspect we could get a note to the = editorial team at ISO /CS
> and/or to the relevant Committee = Manager and secretariat about
> getting that fixed even after FDIS = balloting was completed
> (and might get our
>
> way) = but whether that would be of substantive importance given
> that = there is no chance of giving them a stable RFC number as
> a = reference is, well, questionable.
>
>
>
> So = now, with the "need to do this quickly to influence the
> = substantive decisions of other SDOs" and the "the IETF = needs
> to be influential about this in order to remain an actor = in
> the multimedia game" aside because, whatever the IETF = decides
> to do about those issues neither they, nor your I-D, = have
> much, if anything, to do with them, it seems to me there = are
> only two questions for  the near term:
>
> =
>
> * Does the ISO FDIS mention "haptics/" as = top-level media type?
>
> If it does, that is a major IETF = (and probably IAB) strategy
> question, not really a media = registration one.  And that
> question includes my concern = about precedents of other SDOs
> squatting on names without = including us actively in the
> development process.
> =
>
>
> * If the answer to that is "no", = are there objections to more
> or less the WG approach Ned = suggested that do not rely on the
> "influence the work of = other SDOs" argument?
>
>
>
> = thanks,
>
>    john
>
>
> =
> --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant = Muthusamy
> <ymuthusamy@immersion.com<mailto:ymuthusamy@immersion.com>>
> = wrote:
>
>
>
>> John,
>
>> =
>
>>
>
>>
>
>> = Regarding your comment:
>
>>
>
>> =
>
>>
>
>>>> One reason is that I = think it would be really unfortunate to
>
>>>> = establish a precedent that the way to get a top-level = media
>>>> type is
>
>>>> to invoke = work going on at
>
>>
>
>>>> what = I understand to be essentially the WG level in = another
>>>> SDO and
>
>>>> then = plead urgency.
>
>>
>
>>>> I = would feel somewhat differently about an = established,
>>>> recognized,
> =
>>>> deployed international standard, but, as I = understand
>>>> "active work
> =
>>>> in ..
>
>>
> =
>>>> MPEG Systems File Format sub-group", this is = fairly far
>>>> from that.
>
>>
> =
>>
>
>>
>
>> I would just = reiterate/summarize what I wrote in my response
>> to = Ned's
>
>> comment that you might have missed: the = haptics proposal in
>> MPEG is no
>
>> longer = at the "WG level" in the MPEG Systems File Format
>> = sub-group. It
>
>> just progressed to FDIS ballot at = MPEG134, which should
>> complete by
>
>> July = 2021, at which point progression to IS (International
>> = Standard)
>
>> is just a matter of procedure. More to = the point, it has
>> passed two
>
>> rounds = (CDAM and DAMD) of international balloting, with over
> =
>> 20 ISO National Bodies casting their ballots in each round. = No
>
>> objections to the haptics proposal were received = in either
>> round.  The
>
>> proposal = left the "WG level" after MPEG131 in July
>
>> = 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot
>> = after
>
>> MPEG132 in October 2020 - a fact that was = indeed mentioned in
>> v01 of
>
>> the = I-D.
>
>>
>
>>
>
>> =
>
>> The ISO link to the DAMD is here:
> =
>> https://nam10.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%
>> 2F%2Flink
>
>> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252= fwww.iso.o
>> rg%252fst
>
>> = andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs
>>= KcfbpK8nr
>
>> = TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp
>>= REaQwDMRV
>
>> = d7M%2C%26typo%3D1&amp;data=3D04%7C01%7C%7C98c8e2a934bf4973859d0
&g= t;> 8d90f309c
>
>> = 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331
>>= 34949%7CU
>
>> = nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>>= TiI6Ik1ha
>
>> = WwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D%2BufQx8YrBdXpXyihiMQXkoVk
&g= t;> uVKQ6A5E3
>
>> = Qz3BQ97HVs%3D&amp;reserved=3D0<https://nam10.safelinks.protecti
>> = on.outloo
>
>> k.com/?url=3Dhttps%3A%2F%2Fnam10.safelink%2F&amp;da= ta=3D04%7C01%7
>> C%7C98c8e
>
>> = 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb
>>= 5%7C0%7C1
>
>> = %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>>= wMDAiLCJQ
>
>> = IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3Dy
&g= t;> JoFSrPdS6
>
>> = 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&amp;reserved=3D0
> =
>> s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iso.o= rg%2Fstan
>
>> = dard%2F81604.html&data=3D04%7C01%7C%7Cb9be185f21b44df1b2f708d90e
&= gt;
>> = 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966
> =
>> = 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> =
>> = 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DqwZKX%2B26U
&= gt;
>> = WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=3D0>.
> =
>>
>
>>
>
>>
> =
>> To be clear, I have no issues with the other points you = raise.
>
>> Just want to make sure that the discussion = is based on current
>
>> reality.
>
> =
>
> =

------=_NextPart_000_00B2_01D74733.E5095FE0-- From nobody Thu May 13 08:14:03 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70AE3A1193 for ; Thu, 13 May 2021 06:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=gweRAYte; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=KiNDZfiH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN5WoCV5IJal for ; Thu, 13 May 2021 06:13:55 -0700 (PDT) Received: from outbound2l.ore.mailhop.org (outbound2l.ore.mailhop.org [54.148.38.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D913A1191 for ; Thu, 13 May 2021 06:13:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620911575; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=MOxg6xAzyypOipbRjV5QAA5ffdD1VmqkWShL8ahbHEhBQq/WQd/liumZnom0DQvr1zDApMa08CGEb KwL1GTdV+POnufbdWc0fHUrtp2+xD4UfYfdKJLhEJ5qrmanH9EReafWS+4mwKKNzFdknFRzbJ5PhaF yOBxDyBrGbcoQI1Nln5jvi65L9AMlUvwonx9XOlF9UjiKKbVVW0z/AZMNpd3AGK2Ogw1Q0Bup7RksS udExuKW6P1u+f/gIjZNddd67JoKTJmqDaJXdsZtLE5gfHHJ4f0xneeRU4qVHeKFmbCATzD06CAq+rj 9AaB1zohu3Vq3VwbDtVD5b702eqe9+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=tQd4xsqvmz589uR3fmwXMTDKnvq/Nl8P8hjaztaOz+0=; b=TqcbHE0FUVpNRWrTtaVwgtKGRa/6eERhbdZaY6IjmPjq+kGIiaMg7teo1b5BpeHNcJO9pi9LX1t6s wPd9VOo3kKxAR3MouY5iyZjh7tcCQDfoUDXeDUMNzEGbkBoTdSVsZmfxMr2jqPlJC4eadeZXnM4oAj moi6FWQRsjdC7f+knTHmoDTTUI32NpfSljyQghx4bYyFWtCCHj469jBQXX33LoqxpcMq8KnzPod95y 3Dp8z23mx56SEeswY0yehUq86uNE6zEXRHxGBlOPNbz11UFacWrkKor3wp1O9tayf1WhD6zLOzIsje D+A3zildg/2ByNYb286e8g0TfhkWIkw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.172; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=tQd4xsqvmz589uR3fmwXMTDKnvq/Nl8P8hjaztaOz+0=; b=gweRAYteP3KgT4wikOQ1ePQ2OH8Yu68d7aH7VNCNFV54IJrsMmNK/TTuhB0unRbJpFbdt5v8Y3/gI 0SbOlx/bQepsP+vB4Qf3R3pcPck2uDKQ2O7slT3T7vGGHcMTZRu7qmnDNxodoL8OyX5fRf1EdJKQQg pLdfQ3x4DTJmrI64= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-low; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=tQd4xsqvmz589uR3fmwXMTDKnvq/Nl8P8hjaztaOz+0=; b=KiNDZfiHwZnJVD09Q6KCYDkZzLpkeoPgsfL92jDjgiyRWSIYlf71TzzpYbJXFaUfH7t0dM/rWLuYP B2BpeTZlgjxKHLd4jbqdXphT04R0V63eP8c7cLUNQYYDX9uPHNuDGK/+wqZrR3MEaBNH3+A5ODcVWk zCsfEj3nxpehLNZGQj0+E7/7EtRyi3Egq/D+XU5Vvl3JiPB/AyHC7MiyZ5GRwhmG4rf3u3mLlmgEtK uIh2107d+1r7bisrrjTZvxivhnXUu+Uwwa/k/omMQq8Q3GzCmxE94rOOzzR55AarHySU9LLztfDyhr LYR8EcXo1winTDkZ/jQ/tjQl1io6awg== X-Originating-IP: 209.85.167.172 X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: eaa50912-b3ec-11eb-a653-89389772cfc7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id eaa50912-b3ec-11eb-a653-89389772cfc7; Thu, 13 May 2021 13:12:50 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id j75so25238237oih.10; Thu, 13 May 2021 06:12:49 -0700 (PDT) X-Gm-Message-State: AOAM531bbVxAkJHtHhkvNudmpaEc5hprEyjwXwniWZ+V7q7deHdLt8SC hrm5sS/6vypIKdrTzXi55dY1krQzfDcUQ/bvMG0= X-Google-Smtp-Source: ABdhPJwTsj+RJATzVDLUjqx//BvOcYNvU5wUIKOSDznXaAqmFKWkZaYvHd293MxPOXnhUDm4LRwAweoRp9TItcNcYkg= X-Received: by 2002:aca:de83:: with SMTP id v125mr2944549oig.82.1620911569250; Thu, 13 May 2021 06:12:49 -0700 (PDT) MIME-Version: 1.0 References: <01RYLBC0JRNS00AUHD@mauve.mrochek.com> <2FD10F8AE6D1B9C7D6545340@PSB> <00b101d7476e$91663c10$b432b430$@acm.org> In-Reply-To: <00b101d7476e$91663c10$b432b430$@acm.org> From: Patrick McManus Date: Thu, 13 May 2021 09:12:37 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Larry Masinter Cc: "Murray S. Kucherawy" , John C Klensin , draft-muthusamy-dispatch-haptics@ietf.org, media-types@ietf.org, Ted Hardie , Dispatch WG , dispatch chairs , Applications and Real-Time Area Discussion , Yeshwant Muthusamy , ART ADs Content-Type: multipart/alternative; boundary="0000000000004c2cf805c235e223" Archived-At: X-Mailman-Approved-At: Thu, 13 May 2021 08:14:02 -0700 Subject: Re: [dispatch] [art] Status of Haptics I-D in DISPATCH? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 13:14:01 -0000 --0000000000004c2cf805c235e223 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 12, 2021 at 4:37 PM Larry Masinter wrote: > Until there is a draft charter and so on, which list should be used to > discuss the subject? > > > feel free to continue to use the dispatch list for this discussion until it has its own forever home. > What good is any top level type? What good could it be if we could just > change everything? Is there a path from current state to that destination= ? > > > > For example, a new top-level type could give some clear advantage in > content negotiation. You ask for a thing with some Accept headers, and yo= u > expect it to return with something that is acceptable, and the top-level > type gives some useful information about the request and/or response). > > > > It could provide a standard for fragment identifiers when applied to all > subtypes, for example, time management =E2=80=93 you could, given a URL f= or all > timed media could use #start=3D22.30:end=3D25.15 as a fragment identifier= no > matter whether video, audio, haptics, 3d, timed text/captions. > > Or a =E2=80=9CDocument=E2=80=9D top level type could indicate common= fragment > components for citations, doi=E2=80=99s, pdfs, ebook to access metadata. > > > > I=E2=80=99m not seeing a use case for haptics/mp9 (or haptics/whatever), = though. > > > > -- > > https://LarryMasinter.net https://interlisp.org > > > > *From:* art *On Behalf Of *Murray S. Kucherawy > *Sent:* Thursday, May 6, 2021 12:34 PM > *To:* John C Klensin > *Cc:* draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org; > Ted Hardie ; Dispatch WG ; > dispatch chairs ; Applications and Real-Time > Area Discussion ; Yeshwant Muthusamy < > ymuthusamy@immersion.com>; ART ADs > *Subject:* Re: [art] [dispatch] Status of Haptics I-D in DISPATCH? > > > > Hi all, > > > > Thanks for this discussion. At a minimum, it reaffirms my decision not t= o > sponsor this myself. :-) > > > > Francesca and I talked about it this morning after the IESG call, and > decided that I'll take up the pen to write a draft charter based on this > thread and circulate it for comments. Stay tuned. > > > > -MSK > > > > > > On Tue, May 4, 2021 at 6:16 PM John C Klensin wrote: > > Yeshwant, > > Thanks. And thanks for confirming. I think I've said as much > as I can usefully say on the subject. > > best wishes, > john > > > --On Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy > wrote: > > > John, > > > > > > > > Thanks for the note. Taking each one of your two questions in > > order: > > > > > > > >>> * Does the ISO FDIS mention "haptics/" as top-level media > >>> type? > > > >>> If it does, that is a major IETF (and probably IAB) strategy > >>> question, not really a media registration one. > > > >>> And that question includes my concern about precedents of > >>> other SDOs squatting on names without including us actively > >>> in the development process. > > > > > > > > No. The ISOBMFF FDIS does not mention 'haptics/' as top-level > > media type. That said, it treats haptics in exactly the same > > way that it treats other top-level media types in Chapter 12 > > (audio, video, text, font, etc.) that have been recognized as > > top-level media types by IETF. To be more specific, our > > haptics proposal to ISOBMFF follows the same box hierarchy as > > the other top-level types: > > > > * Media handler is 'hapt' > > * Haptic Media Header is the NullMediaHeaderBox > > * Sample entry is the HapticSampleEntry > > > > > > > > So, there is no issue of ISO squatting on the 'haptics/' name > > or shutting IETF out from the development process. Our > > objective was to first introduce haptics as a top-level media > > type in ISOBMFF and then approach IETF with the proposal that > > we have in our I-D. For obvious reasons, I am unable to share > > the DAMD or FDIS documents on this mailing list, but I suspect > > those who are also members of MPEG can get access to it easily. > > > > > > > >>> * If the answer to that is "no", are there objections to > >>> more or less the WG approach Ned suggested that do not rely > >>> on the "influence the work of other SDOs" argument? > > > > > > > > Like I've said before, I am open to whatever mechanism the > > IETF decides to use to move the I-D forward. Given the work > > that has already been done in MPEG and the fact that we are > > approaching the FDIS ballot completion stage, I would assume > > that the IETF would take that into account *in some form* as > > it discusses the technical merits of the I-D. > > > > > > > > Thanks, > > > > Yeshwant > > > > > > > > Yeshwant Muthusamy, Ph.D. | Senior Director, Standards > > > > > > > > ymuthusamy@immersion.com | +1 469-583-2171 > > > > > > > > -----Original Message----- > > From: John C Klensin > > Sent: Tuesday, May 4, 2021 2:12 PM > > To: Yeshwant Muthusamy ; Ted Hardie > > Cc: Dispatch WG ; > > dispatch-chairs@ietf.org; Applications and Real-Time Area > > Discussion ; ART ADs ; > > draft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org > > Subject: RE: [art] [dispatch] Status of Haptics I-D in > > DISPATCH? > > > > > > > > Yeshwant, > > > > > > > > Thanks. I did see your response to Ned, but only after > > sending my note. > > > > > > > > In what is perhaps an odd way, from my point of view, this is > > a good news. If the document is in FDIS ballot, all of the > > suggestions on the this list about how the IETF needs to be > > involved, and involved, with some accelerated procedure in > > order to influence the substantive decisions of other > > standards bodies are moot: as I am sure you know, just about > > the one way to make a substantive change in an ISO FDIS > > document is a "no" vote from a national member body, > > presumably after either objecting all along (which I presume > > didn't happen) or discovering some catastrophic substantive > > problem. No room for a "we think it would be better to do > > this than that" intervention from the IETF. > > > > > > > > So the only issues relevant to other SDOs now, AFAICT, is > > what, if anything, those documents (which, sadly, I don't have > > time to read and study today or even this week) have to say > > about media type names. If the answer is that they don't say > > anything, then the IETF should move with appropriate > > diligence, but should not put "get it done quickly" ahead of > > "do it right and get it right". If they say "the media type > > is 'haptics/', then the IETF is essentially dealing, not with > > your I-D/ proposal but with an accomplished fact. That would > > present us with a very different, and unpleasant, situation > > although, using an extension of Ted's argument, I think some > > of us would argue for registering it and trying to figure out > > how to avoid that happening again. If it references the I-D, > > I suspect we could get a note to the editorial team at ISO /CS > > and/or to the relevant Committee Manager and secretariat about > > getting that fixed even after FDIS balloting was completed > > (and might get our > > > > way) but whether that would be of substantive importance given > > that there is no chance of giving them a stable RFC number as > > a reference is, well, questionable. > > > > > > > > So now, with the "need to do this quickly to influence the > > substantive decisions of other SDOs" and the "the IETF needs > > to be influential about this in order to remain an actor in > > the multimedia game" aside because, whatever the IETF decides > > to do about those issues neither they, nor your I-D, have > > much, if anything, to do with them, it seems to me there are > > only two questions for the near term: > > > > > > > > * Does the ISO FDIS mention "haptics/" as top-level media type? > > > > If it does, that is a major IETF (and probably IAB) strategy > > question, not really a media registration one. And that > > question includes my concern about precedents of other SDOs > > squatting on names without including us actively in the > > development process. > > > > > > > > * If the answer to that is "no", are there objections to more > > or less the WG approach Ned suggested that do not rely on the > > "influence the work of other SDOs" argument? > > > > > > > > thanks, > > > > john > > > > > > > > --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy > > > > > wrote: > > > > > > > >> John, > > > >> > > > >> > > > >> > > > >> Regarding your comment: > > > >> > > > >> > > > >> > > > >>>> One reason is that I think it would be really unfortunate to > > > >>>> establish a precedent that the way to get a top-level media > >>>> type is > > > >>>> to invoke work going on at > > > >> > > > >>>> what I understand to be essentially the WG level in another > >>>> SDO and > > > >>>> then plead urgency. > > > >> > > > >>>> I would feel somewhat differently about an established, > >>>> recognized, > > > >>>> deployed international standard, but, as I understand > >>>> "active work > > > >>>> in .. > > > >> > > > >>>> MPEG Systems File Format sub-group", this is fairly far > >>>> from that. > > > >> > > > >> > > > >> > > > >> I would just reiterate/summarize what I wrote in my response > >> to Ned's > > > >> comment that you might have missed: the haptics proposal in > >> MPEG is no > > > >> longer at the "WG level" in the MPEG Systems File Format > >> sub-group. It > > > >> just progressed to FDIS ballot at MPEG134, which should > >> complete by > > > >> July 2021, at which point progression to IS (International > >> Standard) > > > >> is just a matter of procedure. More to the point, it has > >> passed two > > > >> rounds (CDAM and DAMD) of international balloting, with over > > > >> 20 ISO National Bodies casting their ballots in each round. No > > > >> objections to the haptics proposal were received in either > >> round. The > > > >> proposal left the "WG level" after MPEG131 in July > > > >> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot > >> after > > > >> MPEG132 in October 2020 - a fact that was indeed mentioned in > >> v01 of > > > >> the I-D. > > > >> > > > >> > > > >> > > > >> The ISO link to the DAMD is here: > > > >> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A% > > >> 2F%2Flink > > > >> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.o > >> rg%252fst > > > >> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs > >> KcfbpK8nr > > > >> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp > >> REaQwDMRV > > > >> d7M%2C%26typo%3D1&data=3D04%7C01%7C%7C98c8e2a934bf4973859d0 > >> 8d90f309c > > > >> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331 > >> 34949%7CU > > > >> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > >> TiI6Ik1ha > > > >> WwiLCJXVCI6Mn0%3D%7C2000&sdata=3D%2BufQx8YrBdXpXyihiMQXkoVk > >> uVKQ6A5E3 > > > >> Qz3BQ97HVs%3D&reserved=3D0 >> on.outloo > > > >> k.com/?url=3Dhttps%3A%2F%2Fnam10.safelink%2F&data=3D04%7C01%7 > > >> C%7C98c8e > > > >> 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb > >> 5%7C0%7C1 > > > >> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > >> wMDAiLCJQ > > > >> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dy > >> JoFSrPdS6 > > > >> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&reserved=3D0 > > > >> s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iso.org%2Fstan > > > >> dard%2F81604.html&data=3D04%7C01%7C%7Cb9be185f21b44df1b2f708d90e > > > >> 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966 > > > >> 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > > > >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DqwZKX%2B26U > > > >> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=3D0>. > > > >> > > > >> > > > >> > > > >> To be clear, I have no issues with the other points you raise. > > > >> Just want to make sure that the discussion is based on current > > > >> reality. > > > > > > > > > > --0000000000004c2cf805c235e223 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, May 12, 2021 at 4:37 PM Larry Mas= inter <LMM@acm.org> wrote:

Until there is a draft charter and so= on, which list should be used to discuss the subject?

=C2=A0


feel free to continue=C2=A0to use the dispatch list for this discuss= ion until it has its own forever home.

=C2=A0

What= good is any top level type?=C2=A0=C2=A0 What good could it be if we could = just change everything? Is there a path from current state to that destinat= ion?

=C2=A0

For example, =C2=A0a new top-level type could give some cl= ear advantage in content negotiation. You ask for a thing with some Accept = headers, and you expect it to return with something that is acceptable, and= the top-level type gives some useful information about the request and/or = response).

=C2=A0

=

It could provide a standard for fragment identifiers= when applied to all subtypes, for example, time management =E2=80=93 you c= ould, given a URL for all timed media could use #start=3D22.30:end=3D25.15 = as a fragment identifier no matter whether video, audio, haptics, 3d, timed= text/captions.

=C2=A0=C2=A0=C2=A0= =C2=A0Or=C2=A0 a =E2=80=9CDocument=E2=80=9D top level type could indicate c= ommon fragment components for citations, doi=E2=80=99s, pdfs, ebook to acce= ss metadata.

=C2=A0

I=E2=80=99m not seeing a use case for haptics/mp9 = (or haptics/whatever),=C2=A0 though.

=C2=A0

--

https://LarryMasinter.net https://interlisp.org

=C2=A0

From: art <art-bounces@ietf.org> On Behalf Of Murray S. Kuch= erawy
Sent: Thursday, May 6, 2021 12:34 PM
To: John C K= lensin <john-ietf= @jck.com>
Cc: draft-muthusamy-dispatch-haptics@ietf.or= g; media-type= s@ietf.org; Ted Hardie <ted.ietf@gmail.com>; Dispatch WG <dispatch@ietf.org>; dispatch cha= irs <dispa= tch-chairs@ietf.org>; Applications and Real-Time Area Discussion <= ;art@ietf.org>; Ye= shwant Muthusamy <ymuthusamy@immersion.com>; ART ADs <art-ads@ietf.org>
Subject: Re: [art] [dispatch] Status of Haptics I-D in DISPATCH?

=

=C2=A0

Hi all,

=C2=A0

Thanks for this = discussion.=C2=A0 At a minimum, it reaffirms my decision not to sponsor thi= s myself.=C2=A0 :-)

<= /u>=C2=A0

Francesca and I talke= d about it this morning after the IESG call, and decided that I'll take= up the pen to write a draft charter based on this thread and circulate it = for comments.=C2=A0 Stay tuned.

=C2=A0

-MSK

=C2=A0

=C2=A0

On Tue, May 4, 2021 at 6:16 PM John C Klensin <john-ietf@jck.com> wrot= e:

Yeshwant,

Thanks.=C2=A0 And thanks for con= firming.=C2=A0 I think I've said as much
as I can usefully say on th= e subject.

best wishes,
=C2=A0 =C2=A0john


--On Tuesday= , May 4, 2021 22:44 +0000 Yeshwant Muthusamy
<ymuthusamy@immersion.com> wro= te:

> John,
>
>
>
> Thanks for the not= e. Taking each one of your two questions in
> order:
>
>=
>
>>> * Does the ISO FDIS mention "haptics/"= as top-level media
>>> type?
>
>>> If it do= es, that is a major IETF (and probably IAB) strategy
>>> questi= on, not really a media registration one.
>
>>> And that = question includes my concern about precedents of
>>> other SDOs= squatting on names without including us actively
>>> in the de= velopment process.
>
>
>
> No. The ISOBMFF FDIS = does not mention 'haptics/' as top-level
> media type. That s= aid, it treats haptics in exactly the same
> way that it treats other= top-level media types in Chapter 12
> (audio, video, text, font,=C2= =A0 etc.) that have been recognized as
> top-level media types by IET= F. To be more specific, our
> haptics proposal to ISOBMFF follows the= same box hierarchy as
> the other top-level types:
>
>= =C2=A0 =C2=A0*=C2=A0 =C2=A0Media handler is 'hapt'
>=C2=A0 = =C2=A0*=C2=A0 =C2=A0Haptic Media Header is the NullMediaHeaderBox
>= =C2=A0 =C2=A0*=C2=A0 =C2=A0Sample entry is the HapticSampleEntry
> >
>
> So, there is no issue of ISO squatting on the '= ;haptics/' name
> or shutting IETF out from the development proce= ss. Our
> objective was to first introduce haptics as a top-level med= ia
> type in ISOBMFF and then approach IETF with the proposal that> we have in our I-D. For obvious reasons, I am unable to share
>= the DAMD or FDIS documents on this mailing list, but I suspect
> tho= se who are also members of MPEG can get access to it easily.
>
&g= t;
>
>>> * If the answer to that is "no", are= there objections to
>>> more or less the WG approach Ned sugge= sted that do not rely
>>> on the "influence the work of ot= her SDOs" argument?
>
>
>
> Like I've s= aid before, I am open to whatever mechanism the
> IETF decides to use= to move the I-D forward. Given the work
> that has already been done= in MPEG and the fact that we are
> approaching the FDIS ballot compl= etion stage, I would assume
> that the IETF would take that into acco= unt *in some form* as
> it discusses the technical merits of the I-D.=
>
>
>
> Thanks,
>
> Yeshwant
&g= t;
>
>
> Yeshwant Muthusamy, Ph.D. | Senior Director, = Standards
>
>
>
> ymuthusamy@immersion.com | +1 469-583-2= 171
>
>
>
> -----Original Message-----
> F= rom: John C Klensin <john-ietf@jck.com>
> Sent: Tuesday, May 4, 2021 2:12 PM> To: Yeshwant Muthusamy <ymuthusamy@immersion.com>; Ted Hardie
> &l= t;ted.ietf@gmail.co= m> Cc: Dispatch WG <dispatch@ietf.org>;
> dispatch-chairs@ietf.org; Application= s and Real-Time Area
> Discussion <art@ietf.org>; ART ADs <art-ads@ietf.org>;
> dra= ft-muthusamy-dispatch-haptics@ietf.org; media-types@ietf.org
> Subject: RE: [a= rt] [dispatch] Status of Haptics I-D in
> DISPATCH?
>
> =
>
> Yeshwant,
>
>
>
> Thanks.=C2= =A0 I did see your response to Ned, but only after
> sending my note.=
>
>
>
> In what is perhaps an odd way, from my = point of view, this is
> a good news.=C2=A0 If the document is in FDI= S ballot, all of the
> suggestions on the this list about how the IET= F needs to be
> involved, and involved, with some accelerated procedu= re in
> order to influence the substantive decisions of other
>= standards bodies are moot: as I am sure you know, just about
> the o= ne way to make a substantive change in an ISO FDIS
> document is a &q= uot;no" vote from a national member body,
> presumably after eit= her objecting all along (which I presume
> didn't happen) or disc= overing some catastrophic substantive
> problem.=C2=A0 No room for a = "we think it would be better to do
> this than that" interv= ention from the IETF.
>
>
>
> So the only issues= relevant to other SDOs now, AFAICT, is
> what, if anything, those do= cuments (which, sadly, I don't have
> time to read and study toda= y or even this week) have to say
> about media type names.=C2=A0 If t= he answer is that they don't say
> anything, then the IETF should= move with appropriate
> diligence, but should not put "get it d= one quickly" ahead of
> "do it right and get it right"= .=C2=A0 If they say "the media type
> is 'haptics/', the= n the IETF is essentially dealing, not with
> your I-D/ proposal but = with an accomplished fact.=C2=A0 That would
> present us with a very = different, and unpleasant, situation
> although, using an extension o= f Ted's argument, I think some
> of us would argue for registerin= g it and trying to figure out
> how to avoid that happening again.=C2= =A0 If it references the I-D,
> I suspect we could get a note to the = editorial team at ISO /CS
> and/or to the relevant Committee Manager = and secretariat about
> getting that fixed even after FDIS balloting = was completed
> (and might get our
>
> way) but whether = that would be of substantive importance given
> that there is no chan= ce of giving them a stable RFC number as
> a reference is, well, ques= tionable.
>
>
>
> So now, with the "need to= do this quickly to influence the
> substantive decisions of other SD= Os" and the "the IETF needs
> to be influential about this = in order to remain an actor in
> the multimedia game" aside beca= use, whatever the IETF decides
> to do about those issues neither the= y, nor your I-D, have
> much, if anything, to do with them, it seems = to me there are
> only two questions for=C2=A0 the near term:
>=
>
>
> * Does the ISO FDIS mention "haptics/"= ; as top-level media type?
>
> If it does, that is a major IET= F (and probably IAB) strategy
> question, not really a media registra= tion one.=C2=A0 And that
> question includes my concern about precede= nts of other SDOs
> squatting on names without including us actively = in the
> development process.
>
>
>
> * If= the answer to that is "no", are there objections to more
>= or less the WG approach Ned suggested that do not rely on the
> &quo= t;influence the work of other SDOs" argument?
>
>
>= ;
> thanks,
>
>=C2=A0 =C2=A0 john
>
>
= >
> --On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy
&= gt; <ymuth= usamy@immersion.com<mailto:ymuthusamy@immersion.com>>
> wrote:>
>
>
>> John,
>
>>
> >>
>
>>
>
>> Regarding your comme= nt:
>
>>
>
>>
>
>>
&g= t;
>>>> One reason is that I think it would be really unfor= tunate to
>
>>>> establish a precedent that the way t= o get a top-level media
>>>> type is
>
>>>= ;> to invoke work going on at
>
>>
>
>>= >> what I understand to be essentially the WG level in another
>= ;>>> SDO and
>
>>>> then plead urgency.
&= gt;
>>
>
>>>> I would feel somewhat differ= ently about an established,
>>>> recognized,
>
>= ;>>> deployed international standard, but, as I understand
>= >>> "active work
>
>>>> in ..
> <= br>>>
>
>>>> MPEG Systems File Format sub-grou= p", this is fairly far
>>>> from that.
>
>= >
>
>>
>
>>
>
>> I wo= uld just reiterate/summarize what I wrote in my response
>> to Ned= 's
>
>> comment that you might have missed: the haptics= proposal in
>> MPEG is no
>
>> longer at the &quo= t;WG level" in the MPEG Systems File Format
>> sub-group. It<= br>>
>> just progressed to FDIS ballot at MPEG134, which shoul= d
>> complete by
>
>> July 2021, at which point pr= ogression to IS (International
>> Standard)
>
>> i= s just a matter of procedure. More to the point, it has
>> passed = two
>
>> rounds (CDAM and DAMD) of international balloting,= with over
>
>> 20 ISO National Bodies casting their ballot= s in each round. No
>
>> objections to the haptics proposal= were received in either
>> round.=C2=A0 The
>
>> = proposal left the "WG level" after MPEG131 in July
>
&g= t;> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot
>&g= t; after
>
>> MPEG132 in October 2020 - a fact that was ind= eed mentioned in
>> v01 of
>
>> the I-D.
> <= br>>>
>
>>
>
>>
>
>&g= t; The ISO link to the DAMD is here:
>
>> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%
= >> 2F%2Flink
>
>> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%2= 52fwww.iso.o
>> rg%252fst
>
>> andard%252f81604.ht= ml%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs
>> KcfbpK8nr
> >> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp>> REaQwDMRV
>
>> d7M%2C%26typo%3D1&amp;data=3D0= 4%7C01%7C%7C98c8e2a934bf4973859d0
>> 8d90f309c
>
>>= ; 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331
>>= 34949%7CU
>
>> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC= JQIjoiV2luMzIiLCJB
>> TiI6Ik1ha
>
>> WwiLCJXVCI6Mn= 0%3D%7C2000&amp;sdata=3D%2BufQx8YrBdXpXyihiMQXkoVk
>> uVKQ6A5E= 3
>
>> Qz3BQ97HVs%3D&amp;reserved=3D0<https://nam10.safelinks.pr= otecti
>> on.outloo
>
>> k.com/?url=3Dhttps%3A%2F%2Fnam10.safelink%2F&amp;data=3D04= %7C01%7
>> C%7C98c8e
>
>> 2a934bf4973859d08d90= f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb
>> 5%7C0%7C1
> >> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
= >> wMDAiLCJQ
>
>> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI= 6Mn0%3D%7C2000&amp;sdata=3Dy
>> JoFSrPdS6
>
>>= 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&amp;reserved=3D0
>
&g= t;> s.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.iso.org%2Fstan
>
>> dard%2F81604.html&data= =3D04%7C01%7C%7Cb9be185f21b44df1b2f708d90e
>
>> 58c34b%7C4f= 05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966
>
>> 69= 589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>
&g= t;> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DqwZKX%2B26U=
>
>> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserve= d=3D0>.
>
>>
>
>>
>
>>=
>
>> To be clear, I have no issues with the other points = you raise.
>
>> Just want to make sure that the discussion = is based on current
>
>> reality.
>
>
>=
>

--0000000000004c2cf805c235e223-- From nobody Fri May 14 07:33:59 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9773A34DC for ; Fri, 14 May 2021 07:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6u67r3zhpvK for ; Fri, 14 May 2021 07:33:52 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100093.outbound.protection.outlook.com [40.107.10.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201573A34D9 for ; Fri, 14 May 2021 07:33:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pvep80e+u4DT9inIuArg637U2804WsJ2ooOah5f+r+8hsi9cDcVYsD0T/zwSgk1RLAw3+1wUSNNPwkjjOq/1vuCnlH96RkLHBs7cu2L2/aoWtm9e0tB1DqURlBEgA+TMnxjx1S9hZeWQgsFrujCH4/Dl6ZlRwmaUoJCNEZCkdlIui4lMMc+fuvhm1ynELJYLSILXNvERCYAO3GTPSZNOUFtvImNU9d+eJ7HCE23ognsJ6yw1mplkU14TB8g/adqqFXV3u1BuZzj9BOHUMJDElhrbV6xKebLYCX7bnRJ72M7k6PmRCbqdA/4TMmVf4pJxlt3akiN8zWFEHzsZeb8lWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YZFgyq+nYiCiOuvZEHbbJWKtjsCpUaG9zOmUGE7otLE=; b=gulYVkatMXHWzAXddrwtr/mVu7iFQlhKaj/3XIBgUfQJmRcoblm6YrdnEAWdTLDrg+Xhnd2wBTsfnrp7iVOtyXsX1FRQizWH/dVcw9KwxdGeG4wR/6m/E2rTEJVmQf1eFaHvjlrscolTWFMNCx/Kgme3d62Mk/vqshOzUFtl2CMFAFTrLIYn+v/Jtj0SbELj/VIQ6eq+gtDZaIn86ukuFfUm2G3gGe+M19oftPEp59uLrsmb3jCXNaa6eoWr0c7EChsbp9SaUGzKqwGzYnE1dwIroMHCjzTBz6Cm9eBOAdk8T2XKDUA8z84JoZoEvHRMvK3RI6qSwRVHBRjUvfrZLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YZFgyq+nYiCiOuvZEHbbJWKtjsCpUaG9zOmUGE7otLE=; b=NEKpEYZ2yi8nS+KT1RGuWq01BNezPtOoq/bZ8lODytE2e3eV664k+WXN1i8RIewPTi4VRy2Xhqqh+LfJ/1+b78oPQD/x+3mX0aitzZvAs+0h5reDOC+WCO+Sgy1sOZyoPL/DsSx/lK4gVEOkWJplPDmIfb9cAflv0Xx/SQ0BYG56XkFMMDYcLfXWN4jM0XxK8FrxFXTJhhErLJKLjSGXJxrG/hqE2gkfUNv+gJsrsRAzHinNBvmRXx4t4mgYaGcQGfjg+5VamWsQGXiiRr5ZhGtfR0BLfIp/l/GjfEhaS4Quoyn4SR6tvWqQXtqoCeuhqyUk1UNbhGsEPraokkuCdw== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LNXP123MB3804.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:135::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Fri, 14 May 2021 14:33:48 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23%7]) with mapi id 15.20.4129.026; Fri, 14 May 2021 14:33:48 +0000 From: Kirsty P To: Bret Jordan , DISPATCH Thread-Topic: [dispatch] Plain text JSON digital signatures Thread-Index: AQHXQE8MgmZgqFWhwEeZoz8ZJzznG6rjCeln Date: Fri, 14 May 2021 14:33:48 +0000 Message-ID: References: <3B394519-4061-43A8-8963-55A6ADEDF269@gmail.com> <19a99964-8495-2de9-b49a-52aa8321c12e@aaa-sec.com> <220475a6-1e04-107e-6327-366d48d8b420@gmail.com> <27833d9d-53c3-d01c-b01c-e7d53424b5ab@aaa-sec.com> <1B4304D2-E82E-4255-B10C-F29ABCABE15E@tzi.org> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ncsc.gov.uk; x-originating-ip: [20.49.216.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53207890-f346-4c2c-c455-08d916e549a6 x-ms-traffictypediagnostic: LNXP123MB3804: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: benGLQVFoODFVTzXaubaPmyNJFfrTz0PzAQxlY2SUt8Oi3XUKyi4Rl+7zNPhtPckXnbt6m9rnjSFSvB5Kk2UaQCVhZPG79RJI/6Mv1vRveCuNNS8qmQ8dfWpmRYb0X0/E1CSdFKfgg9lSsMpxPl9lE/cAyp0DoyaTQXMk9A8CSbeMWbM4r/6KtFz0+YAF1kcv72NIf1pm7GRJnwmg82+m+QbuBsLY9UMPpT6FGmD7fLtkhKAi0nuXCGlIPUxaAtnq7IdK8X7D6skhNSxaxJ/A+dEPLKDkYtD3DFN87mrGijXNZgMf8G4yMoCtLeghrdK29/fti6vz+6bAIczLTpI1vUnGDHAsEBjOZ9iVelKBxNUoGfnn6QLenR1TtkdqVDPjUnODWoWQ3fNiwqya+yhuwm3G8+mwNcPkT5OaQWbJEJvTcIYJ/3Vr0Q2ZPjXC5Izm+wmfsGkEZ9wiy8c9DF39BfhJkA19GVUNraoyWTwW0fMZXw4Y2u2PzlE/5G5RDmFSbTLLfXgNVdFNNrdCs/bsbzCkyhSgF6FDv6ak6NBwFvJ5Po99+RGGxHUAtqirbLKoU9PzTvojHUAFvsNhMgbaNXXrsrsyzxDnygBO3SFh5Ew81kake38ZGJylaZKgARdFvykXvaT1+5CTCyl5CuuLpCZcyXNeua8OINvHMhD5/Q1h58qgIAeVw66h+x+CUaX x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(346002)(366004)(396003)(376002)(136003)(66946007)(66476007)(45080400002)(966005)(76116006)(186003)(66446008)(53546011)(66556008)(64756008)(7696005)(86362001)(6506007)(478600001)(8676002)(19627405001)(83380400001)(8936002)(2906002)(38100700002)(5660300002)(55016002)(52536014)(71200400001)(9686003)(166002)(110136005)(122000001)(316002)(26005)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?izp/GmKDWLMwsi3BQq8bwEjwx9NjYQ6DM7QIzsHmxCikkyzsKQusUtMZYs?= =?iso-8859-1?Q?4m/FCIdp8uif8goRJgETjtsvznUdVeQOxRoBwwNBuCxjuLJaQDLkZJD+OS?= =?iso-8859-1?Q?LNuwqOXL66vOBrS1w48xqsZmCuqgvi6zmdI2/Lowj/0AVAz8fbMRhADXTR?= =?iso-8859-1?Q?Nrm53FwQKRKbGeq8mU6js+GYOATu5PDR7AkdCDJ/X+oYl2JgHfXcbSkvFJ?= =?iso-8859-1?Q?ponLD6gpZWz/bdEpsthamkQB66ZpWG10m0UbR41+8ED4KCfxG9xn4H9qh8?= =?iso-8859-1?Q?veLRckIPh+jiJxJjrQG7PshjXUmn3RSW31sRY6kB4PJtzUx8Sry4vu9twg?= =?iso-8859-1?Q?Mao0hAjKyPbsRAeyNqSlWdVgf9ocVgbErzeeiWxuBNiP+8fg1q/x0qvvYj?= =?iso-8859-1?Q?/eEKYsAEex8V1SwtqQUTfC51mVb+914D+CMuM3E4WoFa7yzdNaeSvLBsbz?= =?iso-8859-1?Q?+D5yeQlZDHm4jaL4K+t3eXFICz1lvs71hd2J5f41vRS8gkL44kMiLsIp6D?= =?iso-8859-1?Q?iuy+FabpRTZ4PoohsnzJqmpsFmjZg7Jt2MtKl9EkrvEOQ7X3Q3teSKrH6Q?= =?iso-8859-1?Q?9EKp3VMOpt59xiYpqn63ASGvhvW+9yNt1YnibFKlV3Q7a2GWb+/dNX68tw?= =?iso-8859-1?Q?WuRR+uVFygSGoF+zVhOSpGFCobypgMuSggkuWc9a/DEuMwigXFtdum3NFD?= =?iso-8859-1?Q?5bUBbqigzITW/KWy95UydtDIKmDc6yyuA64hisFqZobKkINLPEbO7iiaWN?= =?iso-8859-1?Q?Kqvoh0/tjuu//vXNWYqJU8oNNufT94Rj16+Pu6P0DKRYFXtKdBSou9I4tD?= =?iso-8859-1?Q?2UgfXyY9uFeOYCUe/bYBtfYuAPdH3ntllva1/o2KvXcgJvIlVp0OgfzaX9?= =?iso-8859-1?Q?OI6j+ay3n/D12vpHNVgJHOR0O0CpZD5FwPNhBlBlz9Lkz9wStacI+FMX75?= =?iso-8859-1?Q?7Poh1e6dKeZMFoZbeSR5uGdk5oQ0DrCMzoAee1mUgrIRXJrHlMKzs097ib?= =?iso-8859-1?Q?+1+DzEqaYFoQQobqTPgyZJSa2kFbpWMdGw5KJLuhCxUwY9fWucCvjmONRq?= =?iso-8859-1?Q?4dmPdys77maLFSstdUNXnJGnEof+9y2xkSFknRzW2PX/USifqzRPb0hDcd?= =?iso-8859-1?Q?lAbM8jj4N2WkZeNB/ETPLfv1cP1Gb6bgA/PWpXOartefxHi+IjLt6DCrJp?= =?iso-8859-1?Q?VHshaIaguzCEKr+1RZG0Y5ydnnnEpVMBq3Db/E9m2UzvjWmEMz09utkbAh?= =?iso-8859-1?Q?YmD/6aQCUqZwUqLnWsfNd9bwYCxUqcQdlDqs0krR69Uecsy6FZ76bRm1K5?= =?iso-8859-1?Q?COd86tkKOdZJEB62TVkCjhvR0MNmdPyC9nomamuHPN2GDCPeIX2C/6OjEJ?= =?iso-8859-1?Q?TSi50SKRwV?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599DFF2EB819F9A89A1D098D7509LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 53207890-f346-4c2c-c455-08d916e549a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2021 14:33:48.7996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +PScKwPeRvM/LVB5V8SmOvM0+CLTz4Gm3Luf/q8lRPBW8n6ANssCrH4JXe+h+CsD11l3PBtIR5YNw911ykiueA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB3804 Archived-At: Subject: Re: [dispatch] Plain text JSON digital signatures X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 14:33:58 -0000 --_000_LO2P123MB3599DFF2EB819F9A89A1D098D7509LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bret, Thank you for sharing this work with the list - I'm glad you have found add= itional supporters in the IETF community. However, it's not for the chairs to decide the dispatch outcome, we simply = help to take a pulse-check of the community and move towards a dispatch out= come. All the options you listed (plus a few others) are viable. To this en= d, we will offer you a slot at the next DISPATCH WG meeting (at IETF 111, 2= 6-30 July) to get discussion and see what the community thinks is the best = avenue for this. We haven't yet made a call for items, so exact details wil= l depend on other requests we get through - but we'll be in touch to organi= se this slot in more detail privately. Thanks again for the bringing the work to DISPATCH. Kirsty ________________________________ From: dispatch on behalf of Bret Jordan Sent: 03 May 2021 20:02 To: DISPATCH Subject: [dispatch] Plain text JSON digital signatures Dear Dispatch, Over the past week we have identified 3 additional individuals that have ex= pressed public support for this ID. There were two others that either asked= questions or discussed this relative to CBOR. It is important to note that= we have yet to see any examples of why this would or could not work. We wo= uld respectfully ask for a direction from the Chair on how to move forward: 1) Move forward with ISE for publication 2) Form a short-term WG to work on this 3) Form a longer-term WG to work on this and other JSON related digital sig= nature issues. 4) Assign this work to another WG to be worked on. Please advise. Thanks Bret _______________________________________________ dispatch mailing list dispatch@ietf.org https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdispatch&data=3D04%7C01%7Ckirsty.p%40ncsc.= gov.uk%7C536922ddd0384cf77d2308d90e662d9f%7C14aa5744ece1474ea2d734f46dda64a= 1%7C0%7C0%7C637556654281133505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DXqAuT0cCh= rHOajh5kVy3Pc8fndz%2FbVGpsMJuIsLuRbI%3D&reserved=3D0 This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599DFF2EB819F9A89A1D098D7509LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bret,

Thank you for sharing this work with the list - I'm glad you have found add= itional supporters in the IETF community.

However, it's not for the chairs to decide the dispatch outcome, we simply = help to take a pulse-check of the community and move towards a dispatch out= come. All the options you listed (plus a few others) are viable. To this en= d, we will offer you a slot at the next DISPATCH WG meeting (at IETF 111, 26-30 July) to get discussion and s= ee what the community thinks is the best avenue for this. We haven't yet ma= de a call for items, so exact details will depend on other requests we get = through - but we'll be in touch to organise this slot in more detail privately.

Thanks again for the bringing the work to DISPATCH.

Kirsty



From: dispatch <dispatch= -bounces@ietf.org> on behalf of Bret Jordan <jordan.ietf@gmail.com>= ;
Sent: 03 May 2021 20:02
To: DISPATCH <dispatch@ietf.org>
Subject: [dispatch] Plain text JSON digital signatures
 
Dear Dispatch,

Over the past week we have identified 3 additional individuals that have ex= pressed public support for this ID. There were two others that either asked= questions or discussed this relative to CBOR. It is important to note that= we have yet to see any examples of why this would or could not work. We would respectfully ask for a direc= tion from the Chair on how to move forward:

1) Move forward with ISE for publication
2) Form a short-term WG to work on this
3) Form a longer-term WG to work on this and other JSON related digital sig= nature issues.
4) Assign this work to another WG to be worked on.


Please advise.

Thanks
Bret

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww.ietf.org%2Fmailman%2Flistinfo%2Fdispatch&amp;data=3D04%7C01%7Ckirsty= .p%40ncsc.gov.uk%7C536922ddd0384cf77d2308d90e662d9f%7C14aa5744ece1474ea2d73= 4f46dda64a1%7C0%7C0%7C637556654281133505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC= 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sda= ta=3DXqAuT0cChrHOajh5kVy3Pc8fndz%2FbVGpsMJuIsLuRbI%3D&amp;reserved=3D0<= /a>
This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9
--_000_LO2P123MB3599DFF2EB819F9A89A1D098D7509LO2P123MB3599GBRP_-- From nobody Sat May 15 21:42:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43763A2A6F for ; Sat, 15 May 2021 21:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XiedJSno; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FKBrYyAT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtp5bVXAIHFT for ; Sat, 15 May 2021 21:41:57 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F57E3A2A6D for ; Sat, 15 May 2021 21:41:57 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 6765910E3; Sun, 16 May 2021 00:41:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 16 May 2021 00:41:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=x Z1sIHXEdivRygRM/A0m6TkQqJN6FxKFWvsOhpT2QX4=; b=XiedJSnoHGqy4Gpmz OFzq8RFqBhy55Tz2rqyJ8tiUfxDMDhXVNtVXqzmhgOaysAn5u0CbBWUhlqECzNAS V77BmACBDj6l19FRXE/mDIEU9oyiVFBkCoQQ170CFAW/UYReyBgShgClKSDeKALF e/mUNDj6LWRY82D4t5MNTXvev5eWMkpiuZMjlv2x4+Btbi4s47uw51ujU9lg/5KD 41E1X8Oe+S5F3pCYMmTFM2u7EL3sT/a8XjJ41RkweVSKRJnRz8s2PXoEMIRQMvOR 1/HjSc4DWS05erctLIIv+Edcp7RFzVNoDuBesqctu3sTUnzarHEdwCHYlhoXmMzF Rd8PQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=xZ1sIHXEdivRygRM/A0m6TkQqJN6FxKFWvsOhpT2Q X4=; b=FKBrYyATg+sfEn3lj4AdnZEiqxenyPQXDZEABlOiioKwZaaLv5TOaswBr A9yAVP9lp2A1//5w9ccRB0jwH3impYV9hjjAt4BZSvDvFDLRTATu6ozBuq0gfSJM 4b3cdWhtcea1U3XtQsTS44Il93DugMKHwkRe0O+r/B10R/8xNpvSPd+d3B4j0WDP YxTPSVCX8/9wWkm+BXPEDSlS0JM1EkY0KJ6ix9Q88hTCYECt9jz3py5IwgZeZc7B eJCQ5kqfhvtJB97IgSsKVBfoTNb9eHcAgGowHQ7pBlTrfKLbc9sxutug8dIZDhbD nWcoHDzGIg9HTKekcV7J5Siy5xwKA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeiuddgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeeviedtheffheegtdefkeejvdevhfekvedtffejieeftdehtdeviefhgfejjeeh ieenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghdpmhhnohhtrd hnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from smtpclient.apple (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 16 May 2021 00:41:47 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Mark Nottingham In-Reply-To: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> Date: Sun, 16 May 2021 14:41:42 +1000 Cc: "Murray S. Kucherawy" , DISPATCH list Content-Transfer-Encoding: quoted-printable Message-Id: <5F193852-2CBE-4885-A7E9-14B377DFB5E2@mnot.net> References: <01RYY5BDVHVK0085YQ@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [dispatch] Proposed/draft charter for "mediaman" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2021 04:42:03 -0000 Agreeing with Ned's comments. One thing that I'd like to see discussed (not necessarily in this = proposed WG, although that might be an appropriate venue for it) is = whether the interface for registration (from the perspective of a = prospective registrant) can be updated (or augmented). In particular, = many in the W3C still finds the registration process painful and = bewildering, and I strongly suspect that others do not undertake = registrations for the same reasons. We've now had a fair amount of experience using GitHub as both a = registration interface and for managing the processing of requests, both = for link relations and well-known URIs: https://github.com/protocol-registries/link-relations https://github.com/protocol-registries/well-known-uris I think the media subtype registry is a good candidate for this approach = too; its audience is much larger than those who are familiar with the = IETF, and so effectively what we're doing is adding a web-based = registration request flow to make it easier and more transparent for = those people. Thoughts? > On 13 May 2021, at 4:53 am, Ned Freed wrote: >=20 >> Comments welcome, including my late-night choice of name. >=20 > The name is fine. The rest... I'm afraid I have a lot of problems with = it. >=20 >> -MSK >=20 >> Media Type Maintenance (=E2=80=9CMEDIAMAN=E2=80=9D) Working Group = Charter [DRAFT] >=20 >> The IETF maintains a registry of media types and subtypes that are = used to >> identify particular payloads and their semantics as they are = transported >> via application level protocols such as messaging (=E2=80=9Cemail=E2=80= =9D) and the web >> (HTTP). The core structure and use of media types is the MIME = framework, >> defined in RFCs 2045 through 2049, and amended by various later = documents. >> Registration of new media types is defined by BCP 13, which was last >> updated in 2013. >=20 >> Several topics have appeared in the interim that are large enough in = scope >> and importance to warrant the formation of a working group to develop = and >> process them. In particular, we have for the first time a request = for a >> new top-level media type, and such requests are sufficiently rare = that our >> current processes don=E2=80=99t make it clear how this request should = be evaluated >> and dispatched. >=20 > It's not the first top-level type we've added: >=20 > font - RFC 8081 - 2017 > example - RFC 4735 - 2006 > model - RFC 2077 - 1997 >=20 > AFAICR the process for font went fairly smoothly - which is why I keep = pointing > to RFC 8081 as a model for how to do it - so I'm not sure there's a = case to be > made that we don't know how to do this. >=20 >> This working group will therefore, under this instance of the = charter, take >> up the following work. The working group has discretion to order = these as >> appropriate. >=20 > Strongly disagree. If the haptics work is time-sensitive - and I think = there's a > consensus that it is - the charter needs to say it comes first and = will be > completed before starting the other work. >=20 >> Establish criteria and procedures for registering top-level media >> types. In particular, specify whether these requests can be = handled by the >> current IANA media type review team, require IETF Consensus, or = should >> follow some other process. >=20 > RFC 6838 is pretty clear on the process: New top-level types require a > standards-track RFC. AFAIK nobody has argued that we need to revisit = this > approach; especially if we're concerned about getting haptics done in = a timely > way. >=20 > As for criteria, I guess we could try and codify some, but again, > timing. >=20 >> Develop and process the pending =E2=80=98haptics=E2=80=99 top-level = media type request, >> based on draft-muthusamy-dispatch-haptics. >=20 > +1 >=20 >> Consider whether and how to permit multiple media type suffixes. >=20 > I think this one is likely to be the most contentious by far, and = should come > last. >=20 >> Consider any issues around media types for programming languages. >=20 > +1 >=20 >> Determine revised criteria regarding Security Considerations = sections in >> media type applications. >=20 > Not what I proposed. I've used a checklist to evaluate security = considerations > for media types for years; in one of his registrations Eric = Prud'hommeaux noted > this and essentially suggested that it would be good to expose a more = general > version of it. (Actually, he suggested doing it in the form itself, = but a > checklist needs to come first.) >=20 > So the task is to develop such a checklist, not to revise the criteria > themselves. >=20 >> Review the format of the media types registry itself. >=20 >> It is expected that the working group will produce a document = updating RFC >> 6838 (BCP 13) as a result of the points above, and a =E2=80=9Chaptics=E2= =80=9D standards >> track registration RFC. Any other work is out of scope. >=20 > Strongly disagree. The only work I think this group should do that = might > possibly necessitate a revision to BCP 13 is the multiple suffix work. = In the > past we managed to add suffixes to media types without needing to = revise the > core specification; I don't think we should assume a revision is = needed for > this. >=20 >> On completion of these goals, the working group will discuss whether = it >> would be appropriate for this to become a standing (perhaps usually >> dormant) working group containing the expertise needed to repeat = these >> reviews periodically, and/or to handle those applications such as the >> top-level request that are too large in scope for the IANA media type >> review team. If so, the working group will negotiate a new charter >> accordingly. >=20 > OK... Maybe this is just me remembering things past that don't apply > to the brave new IETF world, but I was under the impression that > We Just Don't Do This. And if we're going to do this, we need > to consider the alternatives (mailing list, directorate, ?) first. >=20 >> Input Document(s): >=20 >> - >=20 >> draft-muthusamy-dispatch-haptics >=20 >=20 >> Proposed milestones (target dates TBD): >=20 >> - >=20 >> draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for >> approval (Proposed Standard) >> - >=20 >> RFC6838bis to the IESG for approval (BCP) >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 17 02:21:54 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB43A3017 for ; Mon, 17 May 2021 02:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.099 X-Spam-Level: X-Spam-Status: No, score=-17.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJH0aDzFtNkM for ; Mon, 17 May 2021 02:21:48 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791823A3014 for ; Mon, 17 May 2021 02:21:48 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id h202so7572961ybg.11 for ; Mon, 17 May 2021 02:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=crdY3PeXyJ3Qg0zYkhhQsgaqcKwHAXBFFtX6h3HCe8U=; b=AbPighxX37QI641RpUExeFi/WRvMoVr45B909wDHedKwoS1F/xRmQmvAl7O3i+b+0x kz3XCOodeBNZ8AOrABAd5c+Zqt74xy4dTLaPtGP59XB8Aw8VhTk1bUmRJBtlv/EgMaIh ksbMcDcHlVz78B8o+xmu4gCHYbmMPIN658xEXMP8pj+ExoLvWFYQkpTvSbYDHSHoxmsl OgxM5+2wCSI69vPuQWKJ0C+YSbrV7ABaTeAXIr1Gt+5sSbxdWA/koyVQ/bDuPJaB8hi1 4k+dnUqzx/AfeXiv4yMLOoPfqHWBt9hUTPjosGszvbdiujVPad5V05Lu34i4OEFkgCSm UxMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=crdY3PeXyJ3Qg0zYkhhQsgaqcKwHAXBFFtX6h3HCe8U=; b=PsgBOTsFS1XGsGZKMuSW06RcN6KYZVuyVIQPRxLtWkZUXTFQeULDhyZWnKSrldmFlb JcoCa8UgY4IQrf+/3RmOZt/nuxYdTDYdKmvBzJMvomzkLu2VwRaUZmhG1Bp+Sx35tdP4 FSKAGsY7chwAvE/1f6ETJNAl0QLd+4isCOlD7SToJ6W/tkh23rkld7CxFWlTKyjL1EJp BhAj4MnQJb6TypD6Y/n5cveWkN6bZRrt0Kl2w8XQgp1ikxGgtKruYjq7lJOoghA9xloo aoK/j5lRmf2wLeazwyOzujFj0FR+1EkHj2bGc0OqO2ClC/hewQxBUUPAzbqZxPkaxa+t BjgA== X-Gm-Message-State: AOAM533dvcYwANw5iuQiYaM0mqCitWaqD0b/YMzPm6sMprbm8zDnmQZH wFBdI1lRkY8074Cw51kzCAnzTB8ZI4kHBSccFC68NA== X-Google-Smtp-Source: ABdhPJyTmCKEg4uZgRkXgBxX4FNk69JYEmhnlTQbIpJjQGHDmWG1pL91arT0MkvINzaOfrOclAozR6o2f+mar0W2bC8= X-Received: by 2002:a25:8b08:: with SMTP id i8mr76266911ybl.370.1621243306719; Mon, 17 May 2021 02:21:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mathias Bynens Date: Mon, 17 May 2021 11:21:35 +0200 Message-ID: To: Myles Borins , media-types@ietf.org Cc: Kirsty P , "Matthew A. Miller" , DISPATCH WG Content-Type: multipart/alternative; boundary="0000000000006497a305c2831f83" Archived-At: Subject: Re: [dispatch] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 09:21:53 -0000 --0000000000006497a305c2831f83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sharing with media-types@ietf.org as requested. Please review and voice your support or concerns! On Tue, Apr 27, 2021 at 7:26 PM Myles Borins wrote= : > Disclaimer: I am one of the authors of the draft. > > I would like to also express my support for this draft. It imho reflects > ecosystem usage, for example there are currently over 6 million files > with the .mjs extension on GitHub > . > > The extension is supported in some mimetype collections and DBs, such as > that of the python programming language > , > but still hasn't been adopted by industry standard tools such as apache > . > The lack of consistency here makes for poor developer experiences and > inconsistent experiences across platforms + tools. This draft being > accepted would be an extremely strong signal to let folks know that they > can implement support for .mjs. > > Separate from the new extension that will be supported the updated draft > includes a number of additional improvements that reflect the current > reality of the web. This includes making "text/javascript" COMMON rather > than OBSOLETE and an update to the security considerations. > > Thank you everyone for your time and considerations regarding this matter= . > > On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens wrote: > >> Disclaimer: I am one of the authors of this draft. Nevertheless, I >> would like to express my support and speak to the importance of its >> standardization. >> >> The draft supersedes the earlier RFC4329, providing updated >> definitions to align with what has quickly become implementation >> reality, both in web browsers as well as other popular JavaScript >> environments such as Node.js. >> >> Thanks, >> Mathias >> >> On Tue, Apr 27, 2021 at 3:49 PM Kirsty P wrote: >> > ________________________________ >> > From: Kirsty P >> > Sent: 26 April 2021 16:25 >> > To: dispatch@ietf.org >> > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th >> May >> > >> > Hi DISPATCH, >> > >> > Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd >> WGLC (Working Group Last Call). Please send your comments and/or >> expressions of support to the DISPATCH list. >> > >> > Longer: the draft was recently updated to address feedback from a >> review and from the 2nd WGLC [1]. The authors posted an update to the li= st >> with more information [2]. We (DISPATCH chairs) feel like all the commen= ts >> have been addressed, so it's time for 3rd WGLC. >> > >> > We need to hear positive noises and support for this draft from the WG >> before progressing the -08 draft, so please email to signal your >> endorsement, even if you have no comments to make. The draft can be foun= d >> on datatracker here: >> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ >> > >> > WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th >> May. >> > >> > Kirsty >> > (DISPATCH co-chair) >> > >> > [1] >> https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqX= g0/ >> > [2] >> https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzk= is/ >> > >> > >> > >> > This information is exempt under the Freedom of Information Act 2000 >> (FOIA) and may be exempt under other UK information legislation. Refer a= ny >> FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown >> Copyright =C2=A9 >> > --0000000000006497a305c2831f83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sharing with=C2=A0= media-types@ietf.org as requested. Please review and voice your support= or concerns!

On Tue, Apr 27, 2021 at 7:26 PM Myles Borins <mylesborins@github.com> wrote:
Disclai= mer: I am one of the authors of the draft.

I would like = to also express my support for this draft. It imho reflects ecosystem usage= , for example there are currently over 6 million = files with the .mjs extension on GitHub.




On = Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens <mths@google.com> wrote:
Disclaimer: I am one of the autho= rs of this draft. Nevertheless, I
would like to express my support and speak to the importance of its
standardization.

The draft supersedes the earlier RFC4329, providing updated
definitions to align with what has quickly become implementation
reality, both in web browsers as well as other popular JavaScript
environments such as Node.js.

Thanks,
Mathias

On Tue, Apr 27, 2021 at 3:49 PM Kirsty P <Kirsty.p@ncsc.gov.uk> wrote:
> ________________________________
> From: Kirsty P
> Sent: 26 April 2021 16:25
> To: dispatch@ie= tf.org <dispa= tch@ietf.org>
> Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th= May
>
> Hi DISPATCH,
>
> Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd W= GLC (Working Group Last Call). Please send your comments and/or expressions= of support to the DISPATCH list.
>
> Longer: the draft was recently updated to address feedback from a revi= ew and from the 2nd WGLC [1]. The authors posted an update to the list with= more information [2]. We (DISPATCH chairs) feel like all the comments have= been addressed, so it's time for 3rd WGLC.
>
> We need to hear positive noises and support for this draft from the WG= before progressing the -08 draft, so please email to signal your endorseme= nt, even if you have no comments to make. The draft can be found on datatra= cker here: https://datatracker.i= etf.org/doc/draft-ietf-dispatch-javascript-mjs/
>
> WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th= May.
>
> Kirsty
> (DISPATCH co-chair)
>
> [1] https://mailarch= ive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/
> [2] https://mailarch= ive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/
>
>
>
> This information is exempt under the Freedom of Information Act 2000 (= FOIA) and may be exempt under other UK information legislation. Refer any F= OIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2=A9
--0000000000006497a305c2831f83-- From nobody Mon May 17 07:22:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576483A39A0; Mon, 17 May 2021 07:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJPUYcg3xcRR; Mon, 17 May 2021 07:21:52 -0700 (PDT) Received: from outbound-ip12b.ess.barracuda.com (outbound-ip12b.ess.barracuda.com [209.222.82.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06FE3A39B4; Mon, 17 May 2021 07:21:51 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2046.outbound.protection.outlook.com [104.47.66.46]) by mx-outbound20-193.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 May 2021 14:21:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pc8z2LeT92iRuMkvANvEgHUS0w4caL7NyFcg2um+Nzwm5GWJmOGc0KXueNj/sgBRkE0gee1kSrwi3aFQdKobCzenYs+AQidcPjIMqlp424oUEP5vtVIOzScg/PWIcuAD/sZAOkThE7G+1591IuBHonrQMpQgy6qescvWiSyCMtJl42gjZf+L+sV5NtD6Kv96G3N5citUivta1UQalkCN3c6LSDdUI5ldcFbhJHgRO3paaXUCX/TS8vuAH4Ud+apJVW3BsbI9e8t4XJu4nTQPdDSf9WXY/ZoHEvkWIiMFD4LeN7ahL6KsOzX19nV9D3ALkFl3Cl5htPAx2Q1sQWNHdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3UOLjbYGldS0kAN/23hlvF7s8ycAKctWdElOJ74LFyI=; b=b0p73QpWD8UAUBgamU14anpsqNsJiY4EBdSn8lmIJgYia+8+2M8t9TKRDxrK2iQ7/U12cPBpHWYjAkD1Cg4Rg28hjoM6xI2KcEJXYR62zS2BydoGJLSsJYQycvcu4RC0khoG9HBbhvapdh/OgMsFwojfeKqp2Uq5eu3Fc7jUvOQEzqwZCXtIii5n9Mt6Jrxdaxd+nJ552S4fxAN9oSvp3h//J6dbWqflXc0BJNTNnCs/AKEKgmL3juoy/nLxGImR6Y/AQkEPVD5Y4DmKE6FZye4jXkl0EEWzJ19zHTceloT34C1Jp5IDfaQOdMArfBDZsBcGdRKjAp3dqK9nZjz+Kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3UOLjbYGldS0kAN/23hlvF7s8ycAKctWdElOJ74LFyI=; b=VMcmdKkwWCodsiNqkgTbjTl45eQyAe3OT/1u3gFRvb027rw8O9UsKMXyb3RHLbqCo/EDvN/GVHribvVW/KxFzAyO7Alc0GKGLQF/D1yau3ok/EKhhP3pXxom5V1uJZUZz606c+AWPRZupROX7xilwtkENJaxud+KA9WHRyUxy1k= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM6PR16MB3371.namprd16.prod.outlook.com (2603:10b6:5:19d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Mon, 17 May 2021 14:21:40 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::cae:f44a:d064:b681%5]) with mapi id 15.20.4129.031; Mon, 17 May 2021 14:21:40 +0000 From: Yeshwant Muthusamy To: "media-types@ietf.org" , "dispatch-chairs@ietf.org" , Dispatch WG CC: Chris Ullrich Thread-Topic: Version 02 of the haptics I-D uploaded Thread-Index: AddLJoPbks7hKYM2RzCQh0hNF93K6A== Date: Mon, 17 May 2021 14:21:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.41.37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c806e13-148f-47e6-699e-08d9193f16ea x-ms-traffictypediagnostic: DM6PR16MB3371: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 48X3b8/4wCZdPxUxV6kvwh2kM7SqBplfMw59Bvyj9lJ/bFp53D/w2jRZqO+v19JPpPJytjxnzvaK/EAOeXQWTu5/q1+ssnQa+yzBAeakQUd2DZj89i5c2qTJo1AJ5hZ94Ro+K9sCLZDYo50nubIsWvir4xQov/5zlym0GNm7lkvFTA4y9N9CAnTBwBPIWEvTV3MFfcYefIfdzoJ7xatDRl9lV6biwxltIO/MMi8Uy8rd9fzMoAi/eBJmTMX04ZI+h//mOnMVI5UMQo8l0wqmQHbrqB4gxErCMpdeQTFFIXjiJU8dD98g4E1EeJYtlQcex+Zs9zSnoZ9T0qWoRl6JxoZRMKhTzGLckyJE+sY+jBGFXRCmREUMnoJfF3LV5GwZEQBmNiab5Nf4KH5xlGiRoeBu+5arE7+dz54HmOToXOPmztYeq+UCHxHztScqfLqIHAptCR+tFoY6asq++AEsxjxgRdI/uKufcU41V4BwTwaZSeqjefELKcizTp8kM3OeX0J+fB47eA6A7lDPlMERnGqZwMxOXTkilwxrYD57M64+kuJH94LxB5NBTniNsYBtx43o1InInUPue5oLdVIrd7K3rkaNH0tKE0+qnjSGrooGVOG6usK68CaUtg2DHuW45RoZF88smQ/blODJIU2TNpvMMRThI+vzVkyOZsBC/GlceOBFyKkLY5iyZIo95Taj x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(396003)(346002)(39830400003)(366004)(55016002)(316002)(110136005)(8936002)(186003)(71200400001)(86362001)(8676002)(6506007)(2906002)(450100002)(9686003)(4326008)(5660300002)(122000001)(966005)(76116006)(99936003)(166002)(33656002)(7696005)(64756008)(83380400001)(107886003)(38100700002)(66476007)(66556008)(66446008)(4744005)(26005)(478600001)(66946007)(66616009)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?k4O7bRkFcqDQrNL5Pzx0OTzEfgKYGaqKr2QyvvEeF28ecukWP9pJsgunDNeC?= =?us-ascii?Q?Pifuy96p1gqYSFhDNcftf6vOK9mpkXfZP4wcBsPcbMxYM2NNbe6pQkYp8tEH?= =?us-ascii?Q?6mOST+VE3rDuFk7d/cTzkf1ET080VEjRlQOs/aUSghfjZxbj5QCTxGiHGF7Y?= =?us-ascii?Q?3dm4wTncDereEg5rsLzStfA6O74Taaby8C0vG+tc45VmDPPxeQu7OdZTWOl+?= =?us-ascii?Q?d+E7bZnigpOFsdWZbW/SnnTNHsLrNVbsho3nG0E/gwXHZsk3Y6XUcb8A3d1e?= =?us-ascii?Q?RxULLecqNCBMihqeyAma7mTahSi112ZvNt6x2gG/V91CB50MWFqs/t2ub340?= =?us-ascii?Q?qZgqL8/V84ug4WnGhIldf5VYVx09PTdVxqpt1CJJiq9KyEU6UoM7qiNZbx5Q?= =?us-ascii?Q?QqbACBBzoOJwmheI7URUSvMU7rQEP23sd+eOy1I7DHAitCN3CYTRTjw8oo5l?= =?us-ascii?Q?czYflXU3RkUgEc3T6VShskbaUwJYDLorUst3y6kEgcpENK5GFXm36LMaH1BO?= =?us-ascii?Q?aCUV5+JBZDoeYXLx3kwvPcwccj+3zl+mnHBwap8AuEIDy9WWe/jamOcQYy7K?= =?us-ascii?Q?FX7rMvyL6X9rFXfRzT8vgWcZy4Qi+v8Ax/dalGaSwwHBo3KpX7fKnHPKoFT8?= =?us-ascii?Q?SLImVN8KpGAiWJeOkUUMPrhXBuh8PD/gd4IEthGRRjYIyEmbWzkxYXffH1lo?= =?us-ascii?Q?CwPessnmyzGbHBjcN4pgknCRamIXzk17TjIH7Z7dQHAWJKUB7IsXb1yTSDaJ?= =?us-ascii?Q?ww7Anx8JFNSLn/mPFH0s10wzA54agz010GJZPCug/Dh1Fon/ZRJ6Z6evBvpS?= =?us-ascii?Q?nCjCTKTAsa4TkEdjYdJv/KsfJQghGpvaSLmVkL+wsp6vKZpBLoxlSKUOOP03?= =?us-ascii?Q?O3O7uqQ2/0G8+oXNyfHCAqu427dPhEZWk/JNKwHK/oaFS3VXkqIvP1Hw50By?= =?us-ascii?Q?zK36q8zTCO7WERM/BMaJrEUKT4qUS2JzZR5ctu/JCbSP9IsqbESOX9nLq6+V?= =?us-ascii?Q?2N10E4qJOeMmIoHpTioStxzhtecMfKRVMKgYbnnmxrUQNzGtQbqf013ID1tn?= =?us-ascii?Q?ZtwzeRabLf7tpUhB8dSS39p7m28cAripD3HC4RaecZrHD1fIgAbUKG4zG9/g?= =?us-ascii?Q?c71Mvvt1UgS/Hq97bdPKbdhA2KL5FZN8ku3uQsuRDoIXSxCyvDsSx3VAFkRF?= =?us-ascii?Q?OWOGZu43N9ORNdTGzLw9vAX8ko3jzVIswmvfmemUNPeK8eIIuRKbWi4KLabD?= =?us-ascii?Q?hF9rt8ScMBQMc4bHytDG/J144M8EuWZTvaTu6/2FyVLGD87hQyNKZZFloPmL?= =?us-ascii?Q?oZQ=3D?= Content-Type: multipart/related; boundary="_004_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c806e13-148f-47e6-699e-08d9193f16ea X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2021 14:21:40.7009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tyV+/RtaeDcf6zzUoC06/AumJRKcK/c42Wgf3nz/zmnNsHENihVJCpTXIzPG9cAxBtnp8X/l9/Mh7dm0nljh+LRyYp/i5LnrZICLvSMg56g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB3371 X-BESS-ID: 1621261302-105313-5396-8956-1 X-BESS-VER: 2019.1_20210514.2036 X-BESS-Apparent-Source-IP: 104.47.66.46 X-BESS-Outbound-Spam-Score: 0.01 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.232297 [from cloudscan12-128.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.01 BSF_SC7_SG0146_1 META: Custom rule SG0146_1 X-BESS-Outbound-Spam-Status: SCORE=0.01 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND, BSF_SC7_SG0146_1 X-BESS-BRTS-Status: 1 Archived-At: Subject: [dispatch] Version 02 of the haptics I-D uploaded X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 14:21:58 -0000 --_004_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_" --_000_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Since Version 01 of the haptics I-D was expiring on May 19th, I was asked t= o re-submit it with a new version number (02) to keep it alive. Apart from updating the version, I have made the following opportunistic (a= nd minor) updates to the I-D, to reflect developments in the MPEG134 meetin= g in April 2021. Specifically: 1. Updated the URL in the MPEG-Haptics-CfP reference to point to the lat= est version of the MPEG Haptics CfP document, issued at MPEG134. 2. Added a new reference, MPEG-Haptics-Encoder-Format, to the Encoder In= put Format document and updated its N-number (from N 13 to N 72) to reflect= the latest version of this document, issued at MPEG134. Rest of the content is unchanged from Version 01. https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/ Looking forward to the discussion on this I-D on this list as well as in th= e new "Mediaman" WG. Thanks, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards [cid:image001.jpg@01D74AFD.2AC20A60] ymuthusamy@immersion.com | +1 469-583-2171 --_000_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Since Version 01 of the haptics I-D was expiring on = May 19th, I was asked to re-submit it with a new version number = (02) to keep it alive.

 

Apart from updating the version, I have made the fol= lowing opportunistic (and minor) updates to the I-D, to reflect development= s in the MPEG134 meeting in April 2021. Specifically:

  1. Updated the UR= L in the MPEG-Haptics-CfP reference to point to the latest version of the M= PEG Haptics CfP document, issued at MPEG134.
  2. Added a new reference, MPEG-H= aptics-Encoder-Format, to the Encoder Input Format document and updated its= N-number (from N 13 to N 72) to reflect the latest version of this documen= t, issued at MPEG134.

 

Rest of the content is unchanged from Version 01.

 

https://datatracker.ietf.org/doc/draft-muthusamy= -dispatch-haptics/

 

Looking forward to the discussion on this I-D on thi= s list as well as in the new “Mediaman” WG.

 

Thanks,

Yeshwant

 

Yeshwant Muthusamy, Ph.D. | Senior Director, Standar= ds

ymuthusamy@immersion.com | +1 469-583-2171

 

--_000_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_-- --_004_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=5147; creation-date="Mon, 17 May 2021 14:21:40 GMT"; modification-date="Mon, 17 May 2021 14:21:40 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/4QP0aHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MSA2NC4xNDA5NDksIDIwMTAvMTIvMDctMTA6 NTc6MDEgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0idXVpZDo1RDIwODky NDkzQkZEQjExOTE0QTg1OTBEMzE1MDhDOCIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpBMEI4 RUIyQzA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpB MEI4RUIyQjA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQ aG90b3Nob3AgQ1M1LjEgV2luZG93cyI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOjAxODIwNjY3NUYwNkU1MTFCQUZDQjk1NEQ4MTUyNEMyIiBzdFJlZjpkb2N1 bWVudElEPSJ4bXAuZGlkOjdlYjc0ZTdmLWMwMTAtNDUwYi1hODBhLTM4NmQ2ODUxMDQzYyIvPiA8 ZGM6dGl0bGU+IDxyZGY6QWx0PiA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPlByaW50PC9y ZGY6bGk+IDwvcmRmOkFsdD4gPC9kYzp0aXRsZT4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJE Rj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz7/7QBIUGhvdG9zaG9wIDMuMAA4QklN BAQAAAAAAA8cAVoAAxslRxwCAAACAAIAOEJJTQQlAAAAAAAQ/OEfici3yXgvNGI0B1h36//uAA5B ZG9iZQBkwAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAgEBAgICAQICAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIACcAkgMBEQACEQEDEQH/xACVAAAB BAIDAQAAAAAAAAAAAAAABggJCgQHAQMLBQEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAAGAgECAwII CA8AAAAAAAECAwQFBgcICQAREhMUIRUxMjQWFzcYGWEiVDW2ODkKQWIjU2MkZCVVZVZ3t3iIEQEB AQAABQMFAAAAAAAAAAAAAREhMUFxMoECQmGxEtID/9oADAMBAAIRAxEAPwCzfzV7CXrCOtWL61hy 2TdWzjmrZfClExipWpBwym1nsXbWdwfmMm1ds1H8E4VgWsc+bnOKDosmRusUyaxg6CH+u8m+RsdZ +5D9qMbtmtui867o6w6qa/0yYeSkjWLf9GZZyu3ixw8O0kWgtl3+J65G+a5b/jN5G0x51CqdgIe5 dzqLbVKvtKyRDubDQrVB3CDaT9mqzmVr0i3k2CNips/I1e0Q6jhsdRMHsLPxLhqsTv7FEh7dyiAj BlTFyqNdl6tX5+0V6EnbxJPYelwstMx0dK22WjYl7PyMZWo924Sdzj5hBxrh4sk2IqdJsidQwAQo iAKXoDoDoDoDoDoDoDoDoDoE7HW2qy9gsdTirJAydop5IZS2V2PlmDybrBLG1cPoA1gi266j2G99 sWqizT1BExcIkE5PEX29AougOgOgOgqE7aZ2yjstyCR2H80RFbx3m7jjuGd834iqVOVkntdzdjpK gM8t0SwV9zMOkZZDNFKhaXXZoqP8oykmnvFZuiwXY+ikAiS16sDalfd/y7dNhJMMI69bpb4EiFUU XbMcyUezbCMKQtKMVe6a7xeZ1ZpRVjmKJiMCJm9oJgUAuIcKuNnOOONrXNSVdLSFiyVFWXMtjlHD j1K8k/yjbJq0x7pdbxqHO5CtvGCaonMJzKpmMbsYRKAY2+8zglltrxiweUsBo5Svlpz1b08RZIJk OapDzDNgrcXVZ1WYPCRES9RyFGyj9NiqeMeOGjci8ckcTHATkEMDfjk7semOd8Ha90rV+ybGXvYC sTL2ix9WvzeryatvazBYOErasU5pk8kaKkHR/NeSYu0ixzYp1TIKEIYwWTQ26L5ms7R2RJfVO+cd uR2W+nvuBZ0rX2sZXp8zTLjWZ6AlrKreXmZQjD1Wq1utR8emV+4EJBoUVgP6kgJPCNIHu6D79v8A buWzjijKWFpnXPZTW2xQ8BlvEsrZGVwYt21hTkTQNhrdpYsYxvMR780Sv5hU0VEkSHbqJuHCLlFU 1swNCvPLnsHL7TZ/081g0Dns9ZXwVYHCb+WDNleqNTeUeOYNHD+1TDqxVGMa16Vcv5Fu1YRQvnBn oqGMkudQgN1IEdT+bfLmfqpLudTOO7K+Yb/iesubFs7UZ7I0DQo7Cj+Ol7AxXpMZMydaXkslW6UZ 1h0uyZso1tIqJ+wrJVwi4apBLNqLtvjTcPWukbN0cXNdqNpi5ZxNxlmXaNnlKmaw9exVuh5t4ByM /JhJGNWEjvumk4Z+W5ACEUAoBEjK86FkYGY56R0pyO447XmUVMVE24UtzFKScuGs4pAOr2yxcSBX kTVAJUgt0fNdpFXWTOgDkr8h48ly8uokR5C994LQnXuq7EK0E+XazYslUekKR8Nbm9aURg7hGTsw e2RUiaAsjWaMyj4QTIMxK2TeCsX+tIgHiFJbcg0rj7k7srfUDN+7mzWsF41xxFRiwMxiKDl51nPX vMFUtho+MqMijErR8AFef2exTDJugRcvpiIugceeo2IK5mccCw043L3Fz9kpKtZ34+LfrbjmyY7H J1Jyo6ypA3qGVinLiMJDVmysmUBDqxNvlW0oVYGJzpSKBElBWZJpkMoWBGal3LBlk5NOR2vUjX5H HOXKDG4QjMnZgaZHmZtpmBGegHEtHOj42VhYyv0iSjSokTcuW7h6tImTKqoYhxU8wE9sXyiZTrme sqa/aY6eWncax64V6PtOyc/E3yNoleoBJBso+a0qvqvYSZWul7dsElDFZM/G8Fds4btmjxVs7BqD 1tXdx8c7c6sw20WKGzhSHkq9YXcjUJl4i1mK1bqok6JP0ufctEXxGrlo/a9k3JUTlcMlkXaaYprE KNzjghtpvO1sTk3B8ptLj3jRt0zrli924YZ5vpc/VhQ9XeIPUTviUeNdUaJnbsyr1bfsn8g7TjiI NlXJkHHpUUfWqsu51Ep33mmpv+sZL9S/7eP5ta/UZ/MfnL6wv8j+UfxuoKzX7wTDZJ1q5FMIbe02 DZli7RjWvJRsvJMHz6tz1yoL6wQVup9nRTXbFcs5SiTMa3dNkl0DuY50cpRKYDn66fz6pTENcb3g nYd9QMc09MMA5WrmGdt8PVTF1nsU9bcX5bJsZizJULXali66TD0k3R7bAZFvJ3sLXrU4k2ku8UD+ /wD1vpmDnmq4vw02yXtfGtrCSxMXURZKVXbdiqfg5FsqxloKQxNka345Ti5iOXTSdR0mhHVtAyqC xCKpifscAN36DSHJZ+vdw2/9jssfohTetTxoRu2aZFedjitKqmRQoYk2gUAqhSnKCiOJssqpKABg EAOkqQpij8JTAAh7Q6Txo4Mmmf8AeJUzHTIcyPHOKiRjgUxklByaokKiYiAiQ4pKmL3DsPhMIfAI 9Ph6js1Q/bt8qX+0Grf/ABDiPpfGBV8f6KJuUvmlcGSSFwla9M0ElxTKKxEV8YZIOskmqJfGRJY7 ZMTlAexhTKI/FDsvjBjcOUbHx985XCsWLVoCXJ9sdGp+nbpJGJHxs0AR7EDkKBhasQcqeUn38Kfm G8IB4h7y8oGd6MupOr8CG669RQ9K8iIXehGOI0BREYtghBzzZy7ZenVQM3Vh4nzFkTFN2TMiUexg Dwjfn6hEa/aP8ge2HF7iHCEHs5rRAaw5TxJTnEdTHWG59zcIeOb2NjdkmkhaUXpwXsLG3xnmuXKZ AAzgpxIBQEO0ly6HCc2+PXOP+L/VvFNkftrM8pOa9WcfT8n5axmdgc1qhWatyj7yngncGbSyrJRT wqiJxKp2N3Hv0nOdxMDutqjVd0NXco6z2SVXqjC+Q0cSDsccyRdq1OzVmYjbLUJkkcc7cj2Pj56G bg7aEVbmdsBWbkWRFQFSJbLsEevH5t9sXQc6Bxlb5VmObZ8o+OSWTC+bq68Vc1jYbGNcTMxSkTlc N26qloZxkauqd4QqYvAYPE3bdq9aHM8gTmhX7YTmE/8AM36DO+g54TCpyFk5QrTIB59sm+RbNLWd kliFK8dNI10LuMQX7GL4UWjyZfCmmBCFTFUwF9nsLr3eQSvD2gzhcWcp9PgVzjT6pvZtBH1RkCBm bZnFpwMaybi2YGVcCwIuxjW/dHzDgTwAHcR7iNvOeg0tx9ooh+7iZ7EEkwFXXXfdVUQTL3UWTiMs kTWUHsPjVIRAgAYe4gBCgHwB1m873EAvvB/+XPP2PHu/5St8g/Ifj/I/6L4n4Ot/si8lyEak1bdb U/K+DZ+Parzz+Ae2HGUyq2TXeVbKNeZuntMm2CggCzcFZABYvQSMmdzGPHLfxAVY3XNXl1pqKIqE VSOdJVI5VElUzGIomoQwGIchyiBiHIYAEBAe4D16Eem5xS3iSyhx/wCt2TbAyTb2+9053NXiRKmZ Nzbbk0n5avWC+y34pSr2C+PYQZeQXAoeqevFVh7mUMYfOr4+52sOVM37ScdmWKI0hHFQ1rzFfbpk 9aTmUY5+0g7DX67GxykKxUTOeXcmcxqoHTIJRIAAP8PQJ7PGqGXsg8o+i+11cZwKuIcBY+zjXMhv Hc4g1nm0nfcf3+uV4kVBmSMvKIqSVibAqcpigkQTGHv4egPsn5e+95+2V6OB+hP7Hn0Leu99ofOL 58fPf396f3B5XqPdvoPb6jx+Hxfi9urvDAYH1Qy9j7lH3o2usbOBSxDn3H2Dq5jx40nEHU85k6Fj +gVywklYMqRV4tFOSrrkEjmMYFSAUwdvF1AoNT9YcqYg3g5Jc8XNpCoY/wBnbDrfJYrcR8yi/lXb bGVHu0BaRm4xNMqsMZKRnG4IAcxvOIJjB28PQHHtrDlTXG175y+S2cI1ZbB7yZqz3jk0PMoyyjnH 15kknMC5lk0k0zRcqokQfNam8Rkx9gj0Cb429NLrgbS2662bGwsC4Xvd+zk4sMLCTZJmMkqJlF65 Q9IpItCoeWs/hXihFSF7HSE3w9+gZJg7AXMponTHeo+tkLqznDBcLZ7G4wnm/MVinISZx5TrNMvp xaGulQgpOIl5J41k5Rd0mVm3lE27hVUpVF2vkNkb14h7PLTqjmTcbWeg4yw9H11zcoLP2L8jy7Wb sKcPGI1+rsrOlNi1knbRP1a6K0skCRBSTOqXuPYvYQ6S2XYHhbUqbPo4Vsi+nrfFzzOzd9AOq20z CrLpUp5GNJpk5skc49zCk5PIScIis2beNdqkVRbxiukJSmCCNrWfWDd7MO79U3t3sg8R4lkcQ4dm cU4hw1iKfd2dQJC0GfpWa122aUdzMf6ZdrNPgbt0X7g/dVuAgn6Y53Thg3Tqvqfl7EvIVyF7H3Bn BI4z2P8AoW+jJ0wnEH0y6+Y1YcRU974iSIlVifLdqACXjMbzC+0OrtzOgaveNWORDULanZ7L3HxW cLZSxbuc+a3S203KdmGsvcO5tOEgaWyKggovEtbDASMpNvZBdBqss6ei4BBZAPSIrOJ35B7GhWks rpvpw+whL2Rldst3p1kDImW7izOsSLs+WsiMytpN2ycPGrR8uwYR7CPjyOXKRFnJGfnmTS8zyUwb bqbo3nrD/DrlLSy5x9Yb5xtmHdq6XEMI+yNn9bPOZdY5AQpya9hTRI3QbLKWNt6hQSCCACbv38PV t26ImfuWt4f8Cxv+z6+zn9YUf9Zf5L8k/M/9r+J+Dq/l99FqbY5TJKeAcz/Q5FRs1lZXGV1bY8j5 mXjoGIUt7yvv2sEvJy8udOLZsGL9Yi6ouDppGIkJTHIBvGGRQC1x4rqHd7bFK7H8hOgOEcdorpK2 AkBtvg/IORnzUqoioxr0dC2xentXDlJMSi7dyYlaioQ4NnPY6Qb33/U4PQE19ruIahhDFNUwDI16 XwtWqLXYHGcrU59ja6/J1GIj0WEVIR9njXT5nYgeooeYo9IsqLpYx1DHMYwj1gbi6A6A6A6A6A6A 6A6A6A6A6A6A6A6A6A6D/9k= --_004_DM6PR16MB39120D14752C086FECAEC27ADE2D9DM6PR16MB3912namp_-- From nobody Mon May 17 23:32:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853B23A0870 for ; Mon, 17 May 2021 23:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.099 X-Spam-Level: X-Spam-Status: No, score=-17.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjtQ1AtiuRpH for ; Mon, 17 May 2021 23:32:43 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F2B3A0874 for ; Mon, 17 May 2021 23:32:42 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id g38so11768047ybi.12 for ; Mon, 17 May 2021 23:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=alN/qG4iFE/7MfI/BXPcME93BmAoQC0Fx1gMPgFeZ9s=; b=eVosW413uho+o+7efuhj5XR87klFNkATDuCyyFNszFEoi5Imj2eX0yx+Cfp7daSuVN rXwXoetG+T8+b5H5zFWqWs2V4wtiKgvTQ/PHbEb8kJs1I9t65caU0HL3techD5FXLpGk ikMy6HIkzgqR8fafFwgBoqF5c0S/tii8nXux5WvTyWHxF8OjdT4ZPH2pnYG5E9XozVbQ agh8gaCpcCNImFPWXLOx5uCkl3JKEaxNokQEv3aZJGtI+58RD3FkkMonHn2xT0OlN9kk uWhC9fJGRjfL4s1MecLjkbWPHI8fcV5k+5WHqNxHn+dmsfns87vj5Oi1Dw37a6KYMp/9 U+fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=alN/qG4iFE/7MfI/BXPcME93BmAoQC0Fx1gMPgFeZ9s=; b=YbdzWEIDNz9u7McAKpXzORpRYYKok5j8cYCHZrlfHUbdVwotjCuvO5Iw6NB9d4CuU+ 47/r/iBl7/bU/klf3TZGh5bL36sOgZpcAM3jL7JnFxjICzJSNsGlmHTe0OfvdmhI3lgn prCgrrd/nXODbldv7q2JvfF29w7KhqfwXoIJKnJ6LMbiu+UZ1aNrscqfzhwsqCBCLNzu xwgY4S75FdEXR5UjzbJLQSHRon0l1wjADFOZK13ZkLcLavo5jcLWFi3G2VpPtOkiN9Wx XApJfg7cN8Qz4yd24dk0an072xoidxV8g+LNfPmG4HjjqBYBQoR14KzcXqeDyCmdYUnI qYwA== X-Gm-Message-State: AOAM532R06qaM9YRUToGzKug7RjNe9NjjAeFXZD0nAYHbLPebjCi3Ph+ wAolFc2TwWj7wePWon6Cp+6dAzHLdYrxkjL9bE4jGA== X-Google-Smtp-Source: ABdhPJyL5P+fgWAvmuefa5ehH6GhkWb4ZtORGLLxvK3mlDneB9Pges5IwrHNWPuJNwlhXzBddHU3DnXBwy/oVVNPXXo= X-Received: by 2002:a5b:392:: with SMTP id k18mr5651422ybp.180.1621319560838; Mon, 17 May 2021 23:32:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mathias Bynens Date: Tue, 18 May 2021 08:32:30 +0200 Message-ID: To: Myles Borins , media-types@ietf.org, superuser@gmail.com Cc: Kirsty P , "Matthew A. Miller" , DISPATCH WG Content-Type: multipart/alternative; boundary="0000000000007e202805c294e008" Archived-At: Subject: Re: [dispatch] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 06:32:49 -0000 --0000000000007e202805c294e008 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Looping in media type expert Murray Kucherawy, whose feedback on earlier versions of this draft helped shape the proposal. Murray, what do you think of the latest version? On Mon, May 17, 2021 at 11:21 AM Mathias Bynens wrote: > Sharing with media-types@ietf.org as requested. Please review and voice > your support or concerns! > > On Tue, Apr 27, 2021 at 7:26 PM Myles Borins > wrote: > >> Disclaimer: I am one of the authors of the draft. >> >> I would like to also express my support for this draft. It imho reflects >> ecosystem usage, for example there are currently over 6 million files >> with the .mjs extension on GitHub >> . >> >> The extension is supported in some mimetype collections and DBs, such as >> that of the python programming language >> , >> but still hasn't been adopted by industry standard tools such as apache >> . >> The lack of consistency here makes for poor developer experiences and >> inconsistent experiences across platforms + tools. This draft being >> accepted would be an extremely strong signal to let folks know that they >> can implement support for .mjs. >> >> Separate from the new extension that will be supported the updated draft >> includes a number of additional improvements that reflect the current >> reality of the web. This includes making "text/javascript" COMMON rather >> than OBSOLETE and an update to the security considerations. >> >> Thank you everyone for your time and considerations regarding this matte= r. >> >> On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens wrote: >> >>> Disclaimer: I am one of the authors of this draft. Nevertheless, I >>> would like to express my support and speak to the importance of its >>> standardization. >>> >>> The draft supersedes the earlier RFC4329, providing updated >>> definitions to align with what has quickly become implementation >>> reality, both in web browsers as well as other popular JavaScript >>> environments such as Node.js. >>> >>> Thanks, >>> Mathias >>> >>> On Tue, Apr 27, 2021 at 3:49 PM Kirsty P wrote: >>> > ________________________________ >>> > From: Kirsty P >>> > Sent: 26 April 2021 16:25 >>> > To: dispatch@ietf.org >>> > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10t= h >>> May >>> > >>> > Hi DISPATCH, >>> > >>> > Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd >>> WGLC (Working Group Last Call). Please send your comments and/or >>> expressions of support to the DISPATCH list. >>> > >>> > Longer: the draft was recently updated to address feedback from a >>> review and from the 2nd WGLC [1]. The authors posted an update to the l= ist >>> with more information [2]. We (DISPATCH chairs) feel like all the comme= nts >>> have been addressed, so it's time for 3rd WGLC. >>> > >>> > We need to hear positive noises and support for this draft from the W= G >>> before progressing the -08 draft, so please email to signal your >>> endorsement, even if you have no comments to make. The draft can be fou= nd >>> on datatracker here: >>> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ >>> > >>> > WGLC is open for 2 weeks - so will finish close-of-play on Monday 10t= h >>> May. >>> > >>> > Kirsty >>> > (DISPATCH co-chair) >>> > >>> > [1] >>> https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUq= Xg0/ >>> > [2] >>> https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mz= kis/ >>> > >>> > >>> > >>> > This information is exempt under the Freedom of Information Act 2000 >>> (FOIA) and may be exempt under other UK information legislation. Refer = any >>> FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown >>> Copyright =C2=A9 >>> >> --0000000000007e202805c294e008 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looping in media type expert Murray=C2=A0Kucherawy, whose = feedback on earlier versions of this draft helped shape the proposal. Murra= y, what do you think of the latest version?

On Mon, May 17, 2021 at 11:21 AM= Mathias Bynens <mths@google.com&= gt; wrote:
Sharing with=C2=A0media-types@ietf.org as requested. Please review and voice= your support or concerns!

On Tue, Apr 27, 2021 at 7:26 PM Myles Borins <= mylesborins@git= hub.com> wrote:
Disclaimer: I am one of the authors of the draft.
I would like to also express my support for this draft. I= t imho reflects ecosystem usage, for example there are currently over 6 million files with the .mjs extension on GitHub.=

The extension is supported in some mimetype colle= ctions and DBs, such as that of the python programmi= ng language, but still hasn't been adopted by industry standard too= ls such as apache. The lack of consistency here makes for po= or developer experiences and inconsistent experiences across platforms=C2= =A0+ tools. This draft being accepted would be an extremely strong signal t= o let folks know that they can implement support for .mjs.

Separate from the new extension that will be supported the updated= draft includes a number of additional improvements that reflect the curren= t reality of the web. This includes making "text/javascript" COMM= ON rather than OBSOLETE and an update to the security considerations.
=

Thank you everyone for your time and considerations reg= arding this=C2=A0matter.

On Tue, Apr 27, 2021 at 10:17 AM Mathias Byne= ns <mths@google.com= > wrote:
= Disclaimer: I am one of the authors of this draft. Nevertheless, I
would like to express my support and speak to the importance of its
standardization.

The draft supersedes the earlier RFC4329, providing updated
definitions to align with what has quickly become implementation
reality, both in web browsers as well as other popular JavaScript
environments such as Node.js.

Thanks,
Mathias

On Tue, Apr 27, 2021 at 3:49 PM Kirsty P <Kirsty.p@ncsc.gov.uk> wrote:
> ________________________________
> From: Kirsty P
> Sent: 26 April 2021 16:25
> To: dispatch@ie= tf.org <dispa= tch@ietf.org>
> Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th= May
>
> Hi DISPATCH,
>
> Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd W= GLC (Working Group Last Call). Please send your comments and/or expressions= of support to the DISPATCH list.
>
> Longer: the draft was recently updated to address feedback from a revi= ew and from the 2nd WGLC [1]. The authors posted an update to the list with= more information [2]. We (DISPATCH chairs) feel like all the comments have= been addressed, so it's time for 3rd WGLC.
>
> We need to hear positive noises and support for this draft from the WG= before progressing the -08 draft, so please email to signal your endorseme= nt, even if you have no comments to make. The draft can be found on datatra= cker here: https://datatracker.i= etf.org/doc/draft-ietf-dispatch-javascript-mjs/
>
> WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th= May.
>
> Kirsty
> (DISPATCH co-chair)
>
> [1] https://mailarch= ive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/
> [2] https://mailarch= ive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/
>
>
>
> This information is exempt under the Freedom of Information Act 2000 (= FOIA) and may be exempt under other UK information legislation. Refer any F= OIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2=A9
--0000000000007e202805c294e008-- From nobody Tue May 18 03:18:50 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941493A1673; Tue, 18 May 2021 03:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TIj0JBg8xN2; Tue, 18 May 2021 03:18:38 -0700 (PDT) Received: from forward4-smtp.messagingengine.com (forward4-smtp.messagingengine.com [66.111.4.238]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887E13A1528; Tue, 18 May 2021 03:18:38 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 7B7CB1940A64; Tue, 18 May 2021 06:18:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 18 May 2021 06:18:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BPWVHuwFi/rht2Rc+kWiCHeTGw9X5VGBw0oKdVqUR HA=; b=e6vxmEgh9FSD/8yqDmLib4nzzuUE0JLSsQuuR5Bp2KotiHArl3N3UyQwe EdrmQlpNU/78iW8n+jay5i0rk6yVmmGkLFpzwu6O51aNU1ZLOHRdnaCzBruGP2WE I+7HL4+eYypex2o4qiYEl+ue+8iUMcyyAiIBD/1locwm7QaqX2H+giTrFcFrHMCj Cb06K45dWLFY5oRGeE+WqOxe5x/R3yZjVGik55C0IjxIE3MzAHQi/jvHe2nAMuyw lB57UgdG9P/l2c7VDEr/pVdnb1WyujUIY7HOnLMr6YaFpeV4qkC6f34GRPKFPUlj WcFdYl0x5kswteeErsmizpQTkvJ3g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeijedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefirhgr hhgrmhcumfhlhihnvgcuoefirhgrhhgrmhdrmfhlhihnvgesohgvrhgtrdhogidrrggtrd hukheqnecuggftrfgrthhtvghrnhepvdfhheejkeevtdejkeekhefhvdfhteethedtvdel fffhgfdtfeegveeghfeiieffnecuffhomhgrihhnpehivghtfhdrohhrghdpfiefrdhorh hgpdhgihhthhhusgdrtghomhdpnhgrsggslhgvrdgtohhmnecukfhppeekuddrudejgedr uddvledrvdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepifhrrghhrghmrdfmlhihnhgvsehovghrtgdrohigrdgrtgdruhhk X-ME-Proxy: Received: from spare-94.atuin.ninebynine.org (gklyne38.plus.com [81.174.129.24]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 May 2021 06:18:33 -0400 (EDT) To: Mathias Bynens , Myles Borins , media-types@ietf.org Cc: DISPATCH WG , "Matthew A. Miller" , Kirsty P References: From: Graham Klyne Organization: OeRC, Oxford University Message-ID: <05fa6f4f-ebcb-691c-8a02-69ba7a43c28b@oerc.ox.ac.uk> Date: Tue, 18 May 2021 11:18:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 10:18:44 -0000 I'm responding without knowledge of the history of this proposal, but recent experience with the node ecosystem leads me to a view that a common mechanism for distinguishing javascript modules is a Good Thing. A couple of concerns occur to me: 1. I think that depending on the file extension to make the distinction between scrips and modules doesn't really sit well with usage on the Web if they are expected to be parsed differently. I would have thought a different media type would be useful too (though it may be late to stop that horse from bolting). I note the draft is about much more than the .js/.mjs distinction... a couple of other thoughts that struck me... 2. I couldn't understand the section on character encoding detection (sect 4.2), in particular this paragraph: [[ Implementations of this step MUST use these octet sequences to determine the character encoding scheme, even if the determined scheme is not supported. If this step determines the character encoding scheme, the octet sequence representing the Unicode encoding form signature MUST be ignored when decoding the binary source text. ]] I'm probably misunderstanding something here, but it seemed self-contradictory to me (if the unicode encoding signature is used to determine the encoding, it must be ignored...?) 3. Security considerations for Javascript (or any scripting language on the web) is clearly a massive topic, which I don't think a "security considerations" section alone can adequately address. I think many useful points are covered there, but I would have liked to also see references to other documents that discuss security models for scripting on the web (e.g. https://datatracker.ietf.org/doc/html/rfc2046#section-4.5.2, https://www.w3.org/Security/wiki/Cross_Site_Attacks, https://www.w3.org/TR/CSP2/, etc -- this list isn't intended to be exhaustive or even representative - just examples of other work in the area that might be cited), or at least a nod to the existence of other work that should be noted. #g -- On 17/05/2021 10:21, Mathias Bynens wrote: > Sharing with media-types@ietf.org as requested. > Please review and voice your support or concerns! > > On Tue, Apr 27, 2021 at 7:26 PM Myles Borins > wrote: > > Disclaimer: I am one of the authors of the draft. > > I would like to also express my support for this draft. It imho reflects > ecosystem usage, for example there are currently over 6 million files with > the .mjs extension on GitHub > . > > The extension is supported in some mimetype collections and DBs, such as > that of the python programming language > , but > still hasn't been adopted by industry standard tools such as apache > . > The lack of consistency here makes for poor developer experiences and > inconsistent experiences across platforms + tools. This draft being accepted > would be an extremely strong signal to let folks know that they can > implement support for .mjs. > > Separate from the new extension that will be supported the updated draft > includes a number of additional improvements that reflect the current > reality of the web. This includes making "text/javascript" COMMON rather > than OBSOLETE and an update to the security considerations. > > Thank you everyone for your time and considerations regarding this matter. > > On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens > wrote: > > Disclaimer: I am one of the authors of this draft. Nevertheless, I > would like to express my support and speak to the importance of its > standardization. > > The draft supersedes the earlier RFC4329, providing updated > definitions to align with what has quickly become implementation > reality, both in web browsers as well as other popular JavaScript > environments such as Node.js. > > Thanks, > Mathias > > On Tue, Apr 27, 2021 at 3:49 PM Kirsty P > wrote: > > ________________________________ > > From: Kirsty P > > Sent: 26 April 2021 16:25 > > To: dispatch@ietf.org > > > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline > 10th May > > > > Hi DISPATCH, > > > > Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd > WGLC (Working Group Last Call). Please send your comments and/or > expressions of support to the DISPATCH list. > > > > Longer: the draft was recently updated to address feedback from a > review and from the 2nd WGLC [1]. The authors posted an update to the > list with more information [2]. We (DISPATCH chairs) feel like all the > comments have been addressed, so it's time for 3rd WGLC. > > > > We need to hear positive noises and support for this draft from the > WG before progressing the -08 draft, so please email to signal your > endorsement, even if you have no comments to make. The draft can be > found on datatracker here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > > WGLC is open for 2 weeks - so will finish close-of-play on Monday > 10th May. > > > > Kirsty > > (DISPATCH co-chair) > > > > [1] > https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/ > > > [2] > https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/ > > > > > > > > > This information is exempt under the Freedom of Information Act 2000 > (FOIA) and may be exempt under other UK information legislation. Refer > any FOIA queries to ncscinfoleg@ncsc.gov.uk > . All material is UK Crown Copyright © > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > -- Graham Klyne mailto:graham.klyne@oerc.ox.ac.uk Skype/Twitter: @gklyne From nobody Tue May 18 04:40:12 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795A33A08C0 for ; Tue, 18 May 2021 04:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.099 X-Spam-Level: X-Spam-Status: No, score=-17.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOejhfgqsU1G for ; Tue, 18 May 2021 04:40:01 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41D73A08D6 for ; Tue, 18 May 2021 04:40:01 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id w1so1515368ybt.1 for ; Tue, 18 May 2021 04:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=03RQaQr/P/5iYKZaGZ83GL6/JxAFrMEyNmSvxekjE1E=; b=HMfgtHjx7HoEmJ6JHt2QCyPGbrOH8n3q++X55gzIuqsmt6z6wMpkzFLTlQuDqibVxP q4soZjdTJJ3a3t4elR80K3flDME6PycIZhLvxypYw5y6IsPv8fw+WU33FS82UJOKqRIB TKH1hu2RAmclkhQjKJCkUcANVjBX2ixrxxsRMoSGIVO+aA7YYG7B+OglMtE60JvwT3Qt 1p6efHsj1MjasAwp9dTKYEYmuTDX1nSKCfReTJas1/Pqn3spL7r1v8R+vSIpPngDXNFX mSy0N10mytY8QZyYmFspdzl8cg4ZaX8kj4InA9/au5xdUgMTQ+5D6rM62hbh3ANVCWw7 oOtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=03RQaQr/P/5iYKZaGZ83GL6/JxAFrMEyNmSvxekjE1E=; b=rnPpi8qyqH52/0sfTGJJySag7luXJldc80Is3LqDNoHe+W3jg/ufDLWPfI+eQkVyeM 4HRCw7XTDihytMCs23ZH6Y4QCjCHRVdCa7nwElYvWLESoA2/WXP2IIP2HhQQrNPKdval TEBy7QXWqxEcwSr+TAmvFXB0BQrkdC2iuqq8pxwbKjpTXTC/Z7FWHXTjULZCaKH92kXE MwGAowBfBYIvjD22A3z2MT//P3wXAFrmCzHqDlmrRwj4dicabJsiN2E6v59h8UImZ1Ag miUth95sY0QJ4Pp7jNWA23J/h0U64RyJAgF0n4YsArEdldWT3JSljS4qYDZ0vxstxflk MHDw== X-Gm-Message-State: AOAM530SdMFRLoIiytI8t5i58PsEUvXtVViwz2acuPxG3VwrymGBZ/TD KeAe9E+GWWuPNuTHB4X0gJz1ntisKaqwLXZVMhuQag== X-Google-Smtp-Source: ABdhPJxYhqSJ0MZDcswttky7qc2rA2Fr/x/46mtsKAX++WnlW+KW7GhGvCvpJ/7sHqdMbsfqDy7l4gNsbASFm/nG2Xg= X-Received: by 2002:a25:a4c8:: with SMTP id g66mr6473464ybi.301.1621337999936; Tue, 18 May 2021 04:39:59 -0700 (PDT) MIME-Version: 1.0 References: <05fa6f4f-ebcb-691c-8a02-69ba7a43c28b@oerc.ox.ac.uk> In-Reply-To: <05fa6f4f-ebcb-691c-8a02-69ba7a43c28b@oerc.ox.ac.uk> From: Mathias Bynens Date: Tue, 18 May 2021 13:39:48 +0200 Message-ID: To: Graham Klyne Cc: Myles Borins , media-types@ietf.org, DISPATCH WG , "Matthew A. Miller" , Kirsty P Content-Type: multipart/alternative; boundary="0000000000008c896705c2992ba7" Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 11:40:08 -0000 --0000000000008c896705c2992ba7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Comment inline On Tue, May 18, 2021 at 12:18 PM Graham Klyne wrote: > I'm responding without knowledge of the history of this proposal, but > recent > experience with the node ecosystem leads me to a view that a common > mechanism > for distinguishing javascript modules is a Good Thing. A couple of > concerns > occur to me: > > 1. I think that depending on the file extension to make the distinction > between > scrips and modules doesn't really sit well with usage on the Web if they > are > expected to be parsed differently. I would have thought a different medi= a > type > would be useful too (though it may be late to stop that horse from > bolting). > I agree it would have been much nicer to have a separate media type for modules, but I=E2=80=99m afraid that ship has sailed, as you suspected. JavaScript modules being served as text/javascript is already Web Reality, and we cannot change browsers to become more strict about which modules they load/execute at this point without Breaking The Web, so it cannot happen. FWIW, your comments echo feedback we=E2=80=99ve received on the previous ve= rsion, and which we=E2=80=99ve tried to address in this revision by including spec= ific language around how this draft matches implementation reality: ``` The definitions in this document reflect the current state of implementation across the JavaScript ecosystem, in web browsers and other environments such as Node.js alike, in order to guarantee backwards compatibility with existing applications as much as possible. ``` Does this address your concerns? > 2. I couldn't understand the section on character encoding detection (sec= t > 4.2), > in particular this paragraph: > > [[ > Implementations of this step MUST use these octet sequences to > determine the character encoding scheme, even if the determined > scheme is not supported. If this step determines the character > encoding scheme, the octet sequence representing the Unicode > encoding form signature MUST be ignored when decoding the binary > source text. > ]] > > I'm probably misunderstanding something here, but it seemed > self-contradictory > to me (if the unicode encoding signature is used to determine the > encoding, it > must be ignored...?) > Happy to clarify. This is about the Unicode Byte Order Mark (BOM), which should be stripped from the file's contents before processing it. More info here: https://en.wikipedia.org/wiki/Byte_order_mark (This is not specific to this draft, or even to ECMAScript =E2=80=94 it=E2=80=99s a general Unico= de concept.) Note that this language is not new to this draft; it's inherited from RFC4329 which this document supersedes. > 3. Security considerations for Javascript (or any scripting language on > the web) > is clearly a massive topic, which I don't think a "security > considerations" > section alone can adequately address. I think many useful points are > covered > there, but I would have liked to also see references to other documents > that > discuss security models for scripting on the web (e.g. > https://datatracker.ietf.org/doc/html/rfc2046#section-4.5.2, > https://www.w3.org/Security/wiki/Cross_Site_Attacks, > https://www.w3.org/TR/CSP2/, etc -- this list isn't intended to be > exhaustive or > even representative - just examples of other work in the area that might > be > cited), or at least a nod to the existence of other work that should be > noted. > https://datatracker.ietf.org/doc/html/rfc2046#section-4.5.2 does not apply to ECMAScript and seems out of scope for this draft. Both https://www.w3.org/Security/wiki/Cross_Site_Attacks and https://www.w3.org/TR/CSP2/ are specific to usage of ECMAScript *in web browsers*, and are covered by: ``` Uncontrolled execution of scripts can be exceedingly dangerous. Implementations that execute scripts MUST give consideration to their application's threat models and those of the individual features they implement; in particular, they MUST ensure that untrusted content is not executed in an unprotected environment. [=E2=80=A6] Specifications for host environment facilities and for derived programming languages should include security considerations. If an implementation supports such facilities, the respective security considerations apply. In particular, if scripts can be referenced from or included in specific document formats, the considerations for the embedding or referencing document format apply. ``` Furthermore, the =E2=80=9Csecurity considerations=E2=80=9D section is expli= citly =E2=80=9Cto be understood as non-exhaustive and of a purely illustrative nature.=E2=80=9D Given the above, I'd prefer not resetting the process by creating another draft revision just to add one or two non-normative example links. What do you think? > On 17/05/2021 10:21, Mathias Bynens wrote: > > Sharing with media-types@ietf.org as > requested. > > Please review and voice your support or concerns! > > > > On Tue, Apr 27, 2021 at 7:26 PM Myles Borins > > wrote: > > > > Disclaimer: I am one of the authors of the draft. > > > > I would like to also express my support for this draft. It imho > reflects > > ecosystem usage, for example there are currently over 6 million > files with > > the .mjs extension on GitHub > > . > > > > The extension is supported in some mimetype collections and DBs, > such as > > that of the python programming language > > , > but > > still hasn't been adopted by industry standard tools such as apache > > < > http://apache-http-server.18135.x6.nabble.com/Bug-61383-New-mjs-files-sho= uld-be-part-of-mime-application-javascript-td5038697.html > >. > > The lack of consistency here makes for poor developer experiences a= nd > > inconsistent experiences across platforms + tools. This draft being > accepted > > would be an extremely strong signal to let folks know that they can > > implement support for .mjs. > > > > Separate from the new extension that will be supported the updated > draft > > includes a number of additional improvements that reflect the curre= nt > > reality of the web. This includes making "text/javascript" COMMON > rather > > than OBSOLETE and an update to the security considerations. > > > > Thank you everyone for your time and considerations regarding > this matter. > > > > On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens > > wrote: > > > > Disclaimer: I am one of the authors of this draft. Nevertheless= , > I > > would like to express my support and speak to the importance of > its > > standardization. > > > > The draft supersedes the earlier RFC4329, providing updated > > definitions to align with what has quickly become implementatio= n > > reality, both in web browsers as well as other popular JavaScri= pt > > environments such as Node.js. > > > > Thanks, > > Mathias > > > > On Tue, Apr 27, 2021 at 3:49 PM Kirsty P > > wrote: > > > ________________________________ > > > From: Kirsty P > > > Sent: 26 April 2021 16:25 > > > To: dispatch@ietf.org < > dispatch@ietf.org > > > > > > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - > deadline > > 10th May > > > > > > Hi DISPATCH, > > > > > > Summary: draft-ietf-dispatch-javascript-mjs is now ready for > its 3rd > > WGLC (Working Group Last Call). Please send your comments and/o= r > > expressions of support to the DISPATCH list. > > > > > > Longer: the draft was recently updated to address feedback > from a > > review and from the 2nd WGLC [1]. The authors posted an update > to the > > list with more information [2]. We (DISPATCH chairs) feel like > all the > > comments have been addressed, so it's time for 3rd WGLC. > > > > > > We need to hear positive noises and support for this draft > from the > > WG before progressing the -08 draft, so please email to signal > your > > endorsement, even if you have no comments to make. The draft ca= n > be > > found on datatracker here: > > > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > < > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/> > > > > > > WGLC is open for 2 weeks - so will finish close-of-play on > Monday > > 10th May. > > > > > > Kirsty > > > (DISPATCH co-chair) > > > > > > [1] > > > https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg= 0/ > > < > https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg= 0/ > > > > > [2] > > > https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzki= s/ > > < > https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzki= s/ > > > > > > > > > > > > > > This information is exempt under the Freedom of Information > Act 2000 > > (FOIA) and may be exempt under other UK information legislation= . > Refer > > any FOIA queries to ncscinfoleg@ncsc.gov.uk > > . All material is UK Crown > Copyright =C2=A9 > > > > > > _______________________________________________ > > media-types mailing list > > media-types@ietf.org > > https://www.ietf.org/mailman/listinfo/media-types > > > > -- > Graham Klyne > mailto:graham.klyne@oerc.ox.ac.uk > Skype/Twitter: @gklyne > --0000000000008c896705c2992ba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comment inline

On Tue, May 18, 2021 at 12:18 PM Graham= Klyne <Graham.Klyne@oerc.= ox.ac.uk> wrote:
I'm responding without knowledge of the history of this proposa= l, but recent
experience with the node ecosystem leads me to a view that a common mechani= sm
for distinguishing javascript modules is a Good Thing.=C2=A0 A couple of co= ncerns
occur to me:

1. I think that depending on the file extension to make the distinction bet= ween
scrips and modules doesn't really sit well with usage on the Web if the= y are
expected to be parsed differently.=C2=A0 I would have thought a different m= edia type
would be useful too (though it may be late to stop that horse from bolting)= .

I agree it would have been much nicer= to have a separate media type for modules, but I=E2=80=99m afraid that shi= p has sailed, as you suspected.

JavaScript modules= being served as text/javascript is already Web Reality, and we cannot chan= ge browsers to become more strict about which modules they load/execute at = this point without Breaking The Web, so it cannot happen.

FWIW, your comments echo feedback we=E2=80=99ve received on the pre= vious version, and which we=E2=80=99ve tried to address in this revision by= including specific language around how this draft matches implementation r= eality:

```
=C2=A0 =C2=A0The definitions= in this document reflect the current state of
=C2=A0 =C2=A0implementati= on across the JavaScript ecosystem, in web browsers and
=C2=A0 =C2=A0oth= er environments such as Node.js alike, in order to guarantee
=C2=A0 =C2= =A0backwards compatibility with existing applications as much as
=C2=A0 = =C2=A0possible.
```

Does this addres= s your concerns?
=C2=A0
2. I couldn't understand the section on charac= ter encoding detection (sect 4.2),
in particular this paragraph:

[[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Implementations of this step MUST use these oct= et sequences to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 determine the character encoding scheme, even i= f the determined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scheme is not supported.=C2=A0 If this step det= ermines the character
=C2=A0 =C2=A0 =C2=A0 =C2=A0 encoding scheme, the octet sequence representin= g the Unicode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 encoding form signature MUST be ignored when de= coding the binary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 source text.
]]

I'm probably misunderstanding something here, but it seemed self-contra= dictory
to me (if the unicode encoding signature is used to determine the encoding,= it
must be ignored...?)

Happy to clarify. = This is about the Unicode Byte Order Mark (BOM), which should be stripped f= rom the file's contents before processing it. More info here:=C2=A0https://en.wikipedia.= org/wiki/Byte_order_mark (This is not specific to this draft, or even t= o ECMAScript =E2=80=94 it=E2=80=99s a general Unicode concept.)
<= br>
Note that this language is not new to this draft; it's in= herited from=C2=A0RFC4329 which this document supersedes.
=C2=A0<= /div>
3. Security consider= ations for Javascript (or any scripting language on the web)
is clearly a massive topic, which I don't think a "security consid= erations"
section alone can adequately address.=C2=A0 I think many useful points are = covered
there, but I would have liked to also see references to other documents tha= t
discuss security models for scripting on the web (e.g.
https://datatracker.ietf.org/doc/html/rfc= 2046#section-4.5.2,
https://www.w3.org/Security/wiki/Cross_Site_Attac= ks,
https://www.w3.org/TR/CSP2/, etc -- this list isn't intended to b= e exhaustive or
even representative - just examples of other work in the area that might be=
cited), or at least a nod to the existence of other work that should be not= ed.

https://datatracker.ietf.org/doc/html/= rfc2046#section-4.5.2 does not apply to ECMAScript and seems out of sco= pe for this draft.

Both=C2=A0https://www.w3.org/Security/wiki/Cross_Site_Attacks=C2=A0and= =C2=A0https://www.w3.org/TR/CSP2/=C2=A0are specific to usage of ECMAS= cript *in web browsers*, and are covered by:

```
=C2=A0 =C2=A0Uncontrolled execution of scripts can be exceedingly = dangerous.
=C2=A0 =C2=A0Implementations that execute scripts MUST give c= onsideration to their
=C2=A0 =C2=A0application's threat models and t= hose of the individual features they
=C2=A0 =C2=A0implement; in particul= ar, they MUST ensure that untrusted content is
=C2=A0 =C2=A0not executed= in an unprotected environment.

=C2=A0 =C2=A0[= =E2=80=A6]

=C2=A0 =C2=A0Specifications for host en= vironment facilities and for derived
=C2=A0 =C2=A0programming languages = should include security considerations.=C2=A0 If an
=C2=A0 =C2=A0impleme= ntation supports such facilities, the respective security
=C2=A0 =C2=A0c= onsiderations apply.=C2=A0 In particular, if scripts can be referenced
= =C2=A0 =C2=A0from or included in specific document formats, the considerati= ons for
=C2=A0 =C2=A0the embedding or referencing document format apply.=
```

Furthermore, the =E2=80=9C= security considerations=E2=80=9D section is explicitly =E2=80=9Cto be under= stood as non-exhaustive and of a purely illustrative nature.=E2=80=9D
=

Given the above, I'd prefer not resetting the proce= ss by creating another draft revision just to add one or two non-normative = example links.

What do you think?
=

=C2=A0
On 17/05/2021 10:21, Mathias Bynens wrote:
> Sharing with media-types@ietf.org <mailto:media-types@ietf.org> as requested.
> Please review and voice your support or concerns!
>
> On Tue, Apr 27, 2021 at 7:26 PM Myles Borins <mylesborins@github.com
> <mailto:mylesborins@github.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Disclaimer: I am one of the authors of the draft. >
>=C2=A0 =C2=A0 =C2=A0I would like to also express my support for this dr= aft. It imho reflects
>=C2=A0 =C2=A0 =C2=A0ecosystem usage, for example there are currently ov= er 6 million files with
>=C2=A0 =C2=A0 =C2=A0the .mjs extension on GitHub
>=C2=A0 =C2=A0 =C2=A0<ht= tps://github.com/search?l=3D&q=3Dextension%3Amjs&type=3Dcode>= ;.
>
>=C2=A0 =C2=A0 =C2=A0The extension is supported in some mimetype collect= ions and DBs, such as
>=C2=A0 =C2=A0 =C2=A0that of the python programming language
>=C2=A0 =C2=A0 =C2=A0<https= ://github.com/python/cpython/blob/master/Lib/mimetypes.py#L416>, but=
>=C2=A0 =C2=A0 =C2=A0still hasn't been adopted by industry standard = tools such as apache
>=C2=A0 =C2=A0 =C2=A0<http://apache-htt= p-server.18135.x6.nabble.com/Bug-61383-New-mjs-files-should-be-part-of-mime= -application-javascript-td5038697.html>.
>=C2=A0 =C2=A0 =C2=A0The lack of consistency here makes for poor develop= er experiences and
>=C2=A0 =C2=A0 =C2=A0inconsistent experiences across platforms=C2=A0+ to= ols. This draft being accepted
>=C2=A0 =C2=A0 =C2=A0would be an extremely strong signal to let folks kn= ow that they can
>=C2=A0 =C2=A0 =C2=A0implement support for .mjs.
>
>=C2=A0 =C2=A0 =C2=A0Separate from the new extension that will be suppor= ted the updated draft
>=C2=A0 =C2=A0 =C2=A0includes a number of additional improvements that r= eflect the current
>=C2=A0 =C2=A0 =C2=A0reality of the web. This includes making "text= /javascript" COMMON rather
>=C2=A0 =C2=A0 =C2=A0than OBSOLETE and an update to the security conside= rations.
>
>=C2=A0 =C2=A0 =C2=A0Thank you everyone for your time and considerations= regarding this=C2=A0matter.
>
>=C2=A0 =C2=A0 =C2=A0On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens <= ;mths@google.com >=C2=A0 =C2=A0 =C2=A0<mailto:mths@google.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Disclaimer: I am one of the authors o= f this draft. Nevertheless, I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would like to express my support and = speak to the importance of its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0standardization.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft supersedes the earlier RFC4= 329, providing updated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0definitions to align with what has qu= ickly become implementation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reality, both in web browsers as well= as other popular JavaScript
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0environments such as Node.js.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mathias
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Apr 27, 2021 at 3:49 PM Kirst= y P <Kirsty.p@= ncsc.gov.uk
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Kirsty.p@ncsc.gov.uk>> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > _______________________________= _
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > From: Kirsty P
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Sent: 26 April 2021 16:25
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > To: dispatch@ietf.org <mailto:dispatch@ietf.org> <dispatch@ietf.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dispatch@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Subject: 3rd WGLC - draft-ietf-= dispatch-javascript-mjs - deadline
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010th May
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Hi DISPATCH,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Summary: draft-ietf-dispatch-ja= vascript-mjs is now ready for its 3rd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WGLC (Working Group Last Call). Pleas= e send your comments and/or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expressions of support to the DISPATC= H list.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Longer: the draft was recently = updated to address feedback from a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0review and from the 2nd WGLC [1]. The= authors posted an update to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list with more information [2]. We (D= ISPATCH chairs) feel like all the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comments have been addressed, so it&#= 39;s time for 3rd WGLC.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > We need to hear positive noises= and support for this draft from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WG before progressing the -08 draft, = so please email to signal your
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0endorsement, even if you have no comm= ents to make. The draft can be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0found on datatracker here:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/<= /a>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript= -mjs/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > WGLC is open for 2 weeks - so w= ill finish close-of-play on Monday
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010th May.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Kirsty
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > (DISPATCH co-chair)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > [1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS= 9XoFgxBUqXg0/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4= cjoS9XoFgxBUqXg0/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > [2]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oO= hiIHv-5Mzkis/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh= 37oOhiIHv-5Mzkis/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > This information is exempt unde= r the Freedom of Information Act 2000
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(FOIA) and may be exempt under other = UK information legislation. Refer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any FOIA queries to ncscinfoleg@ncsc.gov.uk
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ncscinfoleg@ncsc.gov.uk>. All mat= erial is UK Crown Copyright =C2=A9
>
>
> _______________________________________________
> media-types mailing list
> media-types@= ietf.org
> https://www.ietf.org/mailman/listinfo/media-ty= pes
>

--
Graham Klyne
mailto:grah= am.klyne@oerc.ox.ac.uk
Skype/Twitter: @gklyne
--0000000000008c896705c2992ba7-- From nobody Wed May 19 00:21:53 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBBC3A2121; Wed, 19 May 2021 00:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCn7M5ny2oi9; Wed, 19 May 2021 00:21:47 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400090.outbound.protection.outlook.com [40.107.140.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF7F3A2124; Wed, 19 May 2021 00:21:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cmFGGbUAzxKLYeMrfV/tFUd6CnPcxGc/I2EgEgg9wK5J6IEfEmbUU3P6FpdtW0f9/SMWnKQU407XTNS3HT+t0QH7uQDOBSSa+aTeeGIyRSn83bo5oYlgNigR72jeBo5o6V+LfwZFjryn79pqz7JaFgB7jpl76pjg/7ELQKJr5jHfAk7D68f8kUxIG24rKKO8SSH6F2ony+YBL85lipH7eKZccmBxRTX9Dus1hfJMVi7vBEbzX2E0n1wklykbNuM0yjU2IPMufnzuj3MVvvVwvIfA41nHOxjpqOYQunOLNY3iGWE4iEOJO1qbIhOiOj7HcYhBUVRoPVEhr7NA0CBKxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SmUNTeaIGdl042z2UgmzSybnztRUw5kFXCmkHuktMMc=; b=LszJztloM0dlmEVJ4Xid/JkCQT+1bGDOr7PGKf3xzTW9ObU3F1yu2ZG1KvrczWOp3BzMwmYetLs6FIhD6AANTtq0pYUQSbANL52sumqkpKLuKs2Cp9FwYz938Lf4Tb70/ophEbMWzemNv2iEDlfqvFnieXIYfAIi/nTPjrHiJ2RcwR59L7qEJq4S1U7E16ojtZLQBglivGEyICuXWyLooVMwdGXyC53aj/2Z4zQxKuPm31Xll2EAcV3fngZ/YNQh3hT12vNtZYACFYKU/0XZeXql9NxFbSOWDGnolx6BekyrF5F7iMdiOTnJGB6o3rew9MjJiq+7XM5mF9RbMAJ3OQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SmUNTeaIGdl042z2UgmzSybnztRUw5kFXCmkHuktMMc=; b=BbbX7yo1P0It9l/7rh/it8IOYTZlVR2t8oJxLH6rCTW6ZG5ZC4T90rqRbQ4PgEhrXW/Sh9u/n6e+xYKNOaSQLFK7Fm9fOpiaZahc3tq6+Pfkj7YhbI+oWioPmwjXJf2pcf31rfa/MMfbE1D14//+t/PEIZqDbX66uz29RxWlyIY= Authentication-Results: ncsc.gov.uk; dkim=none (message not signed) header.d=none;ncsc.gov.uk; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB4269.jpnprd01.prod.outlook.com (2603:1096:404:c3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Wed, 19 May 2021 07:21:44 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511%5]) with mapi id 15.20.4129.031; Wed, 19 May 2021 07:21:44 +0000 To: Mathias Bynens , Graham Klyne Cc: media-types@ietf.org, DISPATCH WG , "Matthew A. Miller" , Myles Borins , Kirsty P References: <05fa6f4f-ebcb-691c-8a02-69ba7a43c28b@oerc.ox.ac.uk> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 19 May 2021 16:21:40 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.39] X-ClientProxiedBy: TY2PR02CA0063.apcprd02.prod.outlook.com (2603:1096:404:e2::27) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [133.2.210.39] (133.2.210.39) by TY2PR02CA0063.apcprd02.prod.outlook.com (2603:1096:404:e2::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Wed, 19 May 2021 07:21:43 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bb17624d-5592-4d9d-e85e-08d91a96c0e1 X-MS-TrafficTypeDiagnostic: TYAPR01MB4269: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MndIcFnvuu58lrkELKNrRBsBK8pDpnbrGTVpa85RdBsEKkmKhxMndGumSj9j1ZuR+yFdegk2ERB1hU15pfr8PdJa+m0I6uwQJQi/rloB//qx/gpKmedcP5ZkDXF/Jwa2dgqnZd3qP5MBsStTZ857hU6uTpeEOtAMNS7Z2BqAKQvvc6RZ+d+pd2dFQXB0oL2Nyh5IvUUwvyIiFVCIA1rQywhP++immC/bdcY+ROiXEuXcMe1EEWfwOq7U63AzaaWckwd9c0goVT6IFyT+V1u/EohfmQKpSVIA3g5RetJXm2bKQ0wLjyxSAxj2DDahrnOXk66cV9CJENjqoTRStaQinSu+xpMURZYO+/ufMjmj6Bt7/kkQ2IwdPtWhSVh6zPctpuQ9DqutkEolgZpAic/uAt6ZdftP5YOHoCzcTxX8EYRQ+foofMV3QOu7G9hDMw5srdLvS+vLayDdJJ8DkmxKcRj/JXxMd5H7H7reW2HYjndtJppb44ItazhHRuHNOLRaQcyLTyB87Y6aqDjP1y4UXde6/1lI/kkHRWYAfx96d5ysIzFkXhwvNHsbdRt4vatAU7wINjuQTNIu7rps+fJPiU9XX+zt8luqek2A3eAkb/xvjkW8euTZMIt8j+Qi4JUdXxlplZ+kvtJnz14DZy2T0KGEYhRHGvD5TYDc+E6vF+cw1x4nfFIemuO8ELlOowmnBxOp50KevkI3EN8P908kT4IJWGMf2AGBG+y6FDh9pVpjkXxxqdK9iuf3IIuW8RbSO4eK0wNXfK5eN+GKBXqiQt7gE7S3bAd49VkAwp2loHrieuzjbAajB0PE4I9CLivfsZaIAd81L18kJ0Q8elMRHQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(39840400004)(366004)(136003)(316002)(2906002)(786003)(53546011)(8676002)(956004)(31686004)(31696002)(2616005)(16576012)(86362001)(110136005)(54906003)(8936002)(4326008)(6706004)(36916002)(52116002)(186003)(16526019)(5660300002)(478600001)(966005)(66476007)(38100700002)(38350700002)(66556008)(26005)(6486002)(66946007)(83380400001)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?K1Y2eEJpa0NOSEhsZkV5N2lpSncvS3RyT2FRbElRdzg5bnpnZ0lyaCszbENv?= =?utf-8?B?NGNLVHlpZHZ5SHlyYWh2cjhlTlh0YUdpZ25YSk9lQk9xSVB6MkFsRVVSL3g1?= =?utf-8?B?b0JjQWtJMVYzWnV4a0cveVUvYjZLZCtsY1U3STdkLyt3VUFwQWhhbmNJS2J5?= =?utf-8?B?OG5yWUQvMnA1K1YyS3B0bTc1K21WOWEwRUF2YjgrMTN5b1FrRDBwaW9qcGM2?= =?utf-8?B?bFI0T3NPV1NSaldnNHFMdVZiV3RITnBlb1VjeUsrcEFIVWZPbmVacm9xek9B?= =?utf-8?B?WVYrQXdaRlZqREErRG9DTlR6Q0d5Nlo0OEt3T01na3dhMTlrL0EzOTd1WUpX?= =?utf-8?B?TGFXblFVV1NFeEgvYmtOcHJQekQ4MDB2dFdxdmgweEdzUnR1SktVWEZ4bnJZ?= =?utf-8?B?UzZaV25LdHNzdG1qeU9yR3ErZUJ0V0xJU2ZlR1l6ODJtelBNMFExLzVGTzF3?= =?utf-8?B?ajQ0aThiWHlCc29Nb2FGS0lBd2M0bUcrVFJoOFdOYnNJMllRLzdCeTdjTTV3?= =?utf-8?B?RzZwUC9rUnMxUkxXNG4vQUtsSGxWTDM0bitBWWE3TzZtNTVscG5SVm5vd054?= =?utf-8?B?ZHZZaC9SZDlaelVtWDRNU0lvbWJWUWREeVlSWnhNVzZwajg1cnRjTnNhODVE?= =?utf-8?B?YU11WmlpMFRaSkNSTmRGUWovSk5oMEVhc3hlWHBCSlJIVXZ3MUtoWTlNcmpo?= =?utf-8?B?TE1OMFZlYXREd1RLTWQyZkRWTm5ycUNkakkyOUp1Sm5zbWkzYXJBcXBzRFo1?= =?utf-8?B?ZS9rRyt4S0luMDhGei9qbkdYbm80ais2bmF4RGI1c25xNEs2RHJ1WWFZTnFO?= =?utf-8?B?UTRyWW9RTVdGSEY0ZG1JeVJYZXVLTVc2czQ1N2JDSnVmVTVBekQ1WmJGMTBm?= =?utf-8?B?WkRkWUhIdTFiSkpuZy9ydXRWc0Fhc253NmxjdE1qUWRTd2JaakQ5ZStlQ2lY?= =?utf-8?B?NnFBMFFHMDkrMnlpY00rbGRuR3BlZ2pPcFV6Y0FjdU9uekVXVmlMdVMwMDhM?= =?utf-8?B?VUxzMWVCblU2SExYcHlWUkg0VnJhVWJmSWFaM0tiOGJBdVVtQlduL0laZUhI?= =?utf-8?B?NUFOVWdDM3dUWXFnQlI1M0ZvbWwvQVRCUnNLZEJWa0hwblZaYWMwamYwbVVP?= =?utf-8?B?aDN6U0xTRWxFWmwzUHNFMXhkUDJxZk02QTFvV0dLb0g5VnRsaWRwQzArSEdm?= =?utf-8?B?UTFzU0I5eXIrOExJTXBORzAzZUhxNXJOZnM5eEF2bGt3aU1CeG1BMzU1bkRw?= =?utf-8?B?TG5ZVEJDTHVtMFY1UDNzQ2R3bFgyTjBxSU8wQXF5N0MwMTFmZGJ0TitpQXVv?= =?utf-8?B?R2NkbEVFZFFpQ1A0WHhKNnYzeFpnaDJjL0MxRng5NGFXbml5Mmsydmo1RUMz?= =?utf-8?B?bEJVR1B5K2JsOWdwV2dkSXdJZTFUTHR2ZCtscEdJeXhoWFlxRDdnaXJkWUph?= =?utf-8?B?NnIwYnVNTzB6aVZ6dzJIM2JjWS94Z05Iek1xemNrQnRUanN5UDNnUXN3Z01K?= =?utf-8?B?N0k3QS9NS0FJWXFQUGxIeHAzOFVEN3FQcDJIWTNNZGsxNHpQdzBIUGxKdklz?= =?utf-8?B?SythaHA1cEpzVGp0dXMrd0FveU0rc1B3QlBlZDUxTlpaUGs3NDg1aW9lWm9j?= =?utf-8?B?aDM2SzNDbStHQktPbW5wZ2hkMHVkTWdyVlhDUkNTanhDSlpoc1h4eGNjb2dr?= =?utf-8?B?NWtXK3JvMDl4VHYrUmlqTlNmdmZ2a015Y2xqTW96eHp2aXhUYzFMSjFaS2VL?= =?utf-8?Q?Ti6F/wpr5B582+DT79CUcYUPMONr7yR1n4VQw8H?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: bb17624d-5592-4d9d-e85e-08d91a96c0e1 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 May 2021 07:21:44.2043 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: umBhpzAVJVmnHwWT5nFoyx468a/BY/ka48MFuvsKrJVE87OhgdHZVeAYCQICxGklx1STLOHTUnbFhtlN+TWzsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4269 Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 07:21:52 -0000 On 2021-05-18 20:39, Mathias Bynens wrote: > Comment inline > > On Tue, May 18, 2021 at 12:18 PM Graham Klyne > wrote: >> 2. I couldn't understand the section on character encoding detection (sect >> 4.2), >> in particular this paragraph: >> >> [[ >> Implementations of this step MUST use these octet sequences to >> determine the character encoding scheme, even if the determined >> scheme is not supported. If this step determines the character >> encoding scheme, the octet sequence representing the Unicode >> encoding form signature MUST be ignored when decoding the binary >> source text. >> ]] >> >> I'm probably misunderstanding something here, but it seemed >> self-contradictory >> to me (if the unicode encoding signature is used to determine the >> encoding, it >> must be ignored...?) >> > > Happy to clarify. This is about the Unicode Byte Order Mark (BOM), which > should be stripped from the file's contents before processing it. More info > here: https://en.wikipedia.org/wiki/Byte_order_mark (This is not specific > to this draft, or even to ECMAScript — it’s a general Unicode concept.) > > Note that this language is not new to this draft; it's inherited > from RFC4329 which this document supersedes. It is indeed somewhat difficult to understand for people who are not familiar with the BOM, and autodetection proceedures. I'd suggest changing: If this step determines the character encoding scheme, the octet sequence representing the Unicode encoding form signature MUST be ignored when decoding the binary source text. to something such as: If this step determines the character encoding scheme, the octet sequence representing the Unicode encoding form signature is not part of the actually decoded binary source text. Regards, Martin. From nobody Wed May 19 09:45:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAECF3A1744 for ; Wed, 19 May 2021 09:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=xzdJ/rSz; dkim=pass (2048-bit key) header.d=taugh.com header.b=laBJIP8b Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH-NwK_kJ65k for ; Wed, 19 May 2021 09:44:50 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6C93A175F for ; Wed, 19 May 2021 09:44:50 -0700 (PDT) Received: (qmail 79362 invoked from network); 19 May 2021 16:44:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=135ff.60a54080.k2105; bh=hKFbn8xl6r/qa/7zEVTCxBsZWeJr5cPb2tfoJ+v6gZo=; b=xzdJ/rSzN+HmewepOfnfMc90DnBWLR3Fb1qhVVB/02XBY2E4Gy8M1F7CAcTDuXIyy6YG5diBEjyekT+aGn3TR7pzzcJGzDXCHgv0+QD80BYElxvJ6fCAuS3PHtIHlaL38bY2r9tr/BnPS1CMeE5aBbGsQ4PJMySAzNryEBFMEHZoOqPMoEZfQC48jkMl6fZprF7NdhjjxYtfAL6B8uLwwaslttAAgk9ouqjB0LkpTsa3IoifgJGvwR7wqh34ABfCSO9h9az+jwe6W5OiUcxwc8X2s97BqNQ1sbDeIYYvGN+fw1ou5Rd39+/djYWRcb1sAsvpyy//d6AmT232pv00qQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=135ff.60a54080.k2105; bh=hKFbn8xl6r/qa/7zEVTCxBsZWeJr5cPb2tfoJ+v6gZo=; b=laBJIP8bDV+/P6ovwg38osf/V5se+Zrcn9Jcd6GXl73Fw/PTOmhq88qvqzwQSJVJ8phsEZwVw4zUvzl8mf1w66RDCtZV4syUHUQ9rTA1A1pNVsGMfyjt870gsEy1fsGWhTeGW2vMEo8UlHqPwnbkBEotJgg6mxUkMTtPr9cLs/9tmUql1OdjmXHIA+4FPxHchTDpSpPptkuVNxq2sUjUvGdKpR6rxKmMA6PUBa9wJQ4gc7xt8cf6rpFtfLQfbvlGxRAENUVdD1iGfML/sOzbfPE5AmYeK2yGplSuP3Br+UzYB4I3kTUxIS633SiY5kIHl/RCy4LNkFhS1pue/ZK6qQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 19 May 2021 16:44:48 -0000 Received: by ary.qy (Postfix, from userid 501) id ECC5B82C752; Wed, 19 May 2021 12:44:47 -0400 (EDT) Date: 19 May 2021 12:44:47 -0400 Message-Id: <20210519164447.ECC5B82C752@ary.qy> From: "John Levine" To: media-types@ietf.org, dispatch@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 16:44:58 -0000 It appears that Martin J. Dürst said: >> Note that this language is not new to this draft; it's inherited >> from RFC4329 which this document supersedes. > >It is indeed somewhat difficult to understand for people who are not >familiar with the BOM, and autodetection proceedures. > >I'd suggest changing: > >If this step determines the character >encoding scheme, the octet sequence representing the Unicode >encoding form signature MUST be ignored when decoding the binary >source text. > >to something such as: > >If this step determines the character >encoding scheme, the octet sequence representing the Unicode >encoding form signature is not part of the actually decoded binary >source text. While I agree with your concern, and have given up trying to figure out how the Javascript world got so broken that it cannot keep its encodings straight without having to sniff the contents of every message, I don't think we should change the language. It's been there for a long time, everyone wno needs to understand it knows what it means, and if we change it, we'll be in for a round of "why did they change it and what do I have to do different." R's, John From nobody Wed May 19 11:40:38 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0DB3A1ABC; Wed, 19 May 2021 11:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3ZMaUngoA-D; Wed, 19 May 2021 11:40:28 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2EC3A1AB9; Wed, 19 May 2021 11:40:28 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ljR7L-000KPA-2b; Wed, 19 May 2021 14:40:27 -0400 Date: Wed, 19 May 2021 14:40:21 -0400 From: John C Klensin To: John Levine , media-types@ietf.org, dispatch@ietf.org Message-ID: In-Reply-To: <20210519164447.ECC5B82C752@ary.qy> References: <20210519164447.ECC5B82C752@ary.qy> 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 Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 18:40:34 -0000 --On Wednesday, May 19, 2021 12:44 -0400 John Levine wrote: > It appears that Martin J. D=C3=BCrst = said: >>> Note that this language is not new to this draft; it's >>> inherited from RFC4329 which this document supersedes. >>=20 >> It is indeed somewhat difficult to understand for people who >> are not familiar with the BOM, and autodetection = proceedures. >>=20 >> I'd suggest changing: >>=20 >> If this step determines the character >> encoding scheme, the octet sequence representing the Unicode >> encoding form signature MUST be ignored when decoding the >> binary source text. >>=20 >> to something such as: >>=20 >> If this step determines the character >> encoding scheme, the octet sequence representing the Unicode >> encoding form signature is not part of the actually decoded >> binary source text. >=20 > While I agree with your concern, and have given up trying to > figure out how the Javascript world got so broken that it > cannot keep its encodings straight without having to sniff the > contents of every message, I don't think we should change the > language. It's been there for a long time, everyone wno needs > to understand it knows what it means, and if we change it, > we'll be in for a round of "why did they change it and what do > I have to do different." John, While I mostly agree -- Martin is right, but it is not clear whether making this correct would cause more harm by creating confusion than it would be worth -- there is a third (and more drastic) way to look at this. Content-sniffing and heuristics, rather than properly marking up text and strict observance of media types, ultimately just lead to other problems down the line. The specifics are different, but a review of why we wrote RFC 6082, deprecating the Unicode language tagging of RFC 2482, is relevant here. Sniffing, simplistic tagging, and so on do not work reliably unless assumptions are made about assorted external details and those assumptions are actually correct. The crude example in this case is that sniffing for Unicode encoding types works if the underlying CCS is guaranteed to be Unicode. If it is something else, all bets are off. I could make comments about brokenness even stronger than yours about the choice of file name extensions to determine details of data types. I thought the Internet community gave up on that decades ago. I've been trying to ignore this thread, but this exchange is sort of a last straw and it seems it is time to raise more basic questions. So some suggestions wrt this document if it is really to go forward in the IETF: (1) Martin's suggestion or something like it is an improvement, but the reason for the change should be clearly explained. The style of explanations in Appendix B, many of which are of the form "We changed X" or "Updated Y to make it better" are inadequate in that regard without an explanation as to why and/or the implications of the change. Otherwise, while some are more obvious than others, many of them have the potential to create the type of confusion you identify. (2) To be clear, similar comments apply to almost every bullet point in Appendix B: the changes require explanation. (3) If this document, as suggested by both discussions in this thread and the "... updates ... to reflect existing usage on the Internet" introductory text is apparently the result of IETF's opinion of actual practice in the javascript community, practice that has diverged enough from what RFC 4329 specified to justify such a revision. As an Informational spec expressing our summary of what is happening elsewhere and clearly not under our control, the use of normative BCP 14 language is entirely inappropriate both conceptually and because the very need for the document is evidence that the relevant implementation and operational communities are not paying attention. Phrases like "MUST foo" should be replaced by ones more like (relying on RFC 8174) "you must do X because anything else will lead to ". And, if that is too much work or this is the opinion of the authors or the javascript community about common practdice and not the IETF, then I recommend either of two other options: (i) Rewrite the introductory material to indicate that it is the opinion of the authors and anything they cite. Then Dispatch this to the tender mercies of the ISE because, if the IETF can merely report on actions of others rather than influencing results, that is not a useful business for us to be in. If the IESG then wants to obsolete 4329 and point to the new document for explanation, nothing prevents that, especially given that both would be Informational rather than standards track. or (ii) Let ECMA/TC39 adopt this document, review, and publish it as part of the ECMAScript collection. Then produce a very short RFC that obsoletes 4329, points to the ECMA document, and adds whatever information about the reasons for the change seem helpful. Grump. john From nobody Wed May 19 12:10:26 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D293A1BA0 for ; Wed, 19 May 2021 12:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=FYqKEiyR; dkim=pass (2048-bit key) header.d=taugh.com header.b=J8uDZzzr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYRt7VW2X7jK for ; Wed, 19 May 2021 12:10:19 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FAE3A1BA2 for ; Wed, 19 May 2021 12:10:18 -0700 (PDT) Received: (qmail 2589 invoked from network); 19 May 2021 19:10:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=a1b.60a56298.k2105; bh=rudhrjKRsZoeMrBaWgcqaqTBjBuqpc1N/FujnUzqZnA=; b=FYqKEiyRjzlzdAvv9E5ncUpt4RH3vai2xcSVdLAGezKmIWAyy3qP0/3Uq1uHYqATEsK5YxPDvpkMr9jcHqL+YMSTwsc0aVP5qDS7DH5HZTttTt+7iH3PqT/pZ8zLDVzq30AgQa9qJaJtBU1pQQd45TRDMHUEOp26Vp5XEvGZwmm9YeZ0ZMIpUNzf0C36/dxCHSZwGnmosacWjRZNcsQs1eaNmmDH49IkOQZyjSl5hgtaBqiLIxu++Mec6vXDdjbUD8YrHEbCbVRyhQnBIdoh9TaVbpT/muwGc9eSY75bus+HevvxCZdQQ4ezNBSADC/LZh7IPlJcdPp0ZprGvZwivQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=a1b.60a56298.k2105; bh=rudhrjKRsZoeMrBaWgcqaqTBjBuqpc1N/FujnUzqZnA=; b=J8uDZzzr+VOOr+5vppgYBV29XlPB/n9Wm1gJ4eGZbBcWIt0GLG+/ThEL1Ax9mCrgdEN056M046RA2zzLM1/RVAxJiSWUdLtru2iKNwALNrSNjWD84fEd/rIPa5Az22sk11NCdfnOWm8gEIfawsuSiBQkwkLVnNl+kTbRmLvmR2QUBf+pKkUzfaEGNW9lNeYdBgLqwoBWHC/HKP0dmkWmhh1vITBlNQ/qfAwa6qtk7hYXW4S0O00KIchNo4Ea34EZYLjiqBXewPvX51wSONhzKnr29o6JCiUVAkiVInI5vks9L/70yTbWyJUOOwWvfek0GIQA66DrMhANrp7U92x5pw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 19 May 2021 19:10:15 -0000 Received: by ary.qy (Postfix, from userid 501) id 5F6E382E4C5; Wed, 19 May 2021 15:10:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id E9E7482E4A7; Wed, 19 May 2021 15:10:14 -0400 (EDT) Date: 19 May 2021 15:10:14 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" , media-types@ietf.org, "Dispatch WG" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210519164447.ECC5B82C752@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 19:10:25 -0000 > While I mostly agree -- Martin is right, but it is not clear > whether making this correct would cause more harm by creating > confusion than it would be worth -- there is a third (and more > drastic) way to look at this. Content-sniffing and heuristics, > rather than properly marking up text and strict observance of > media types, ultimately just lead to other problems down the > line. ... We went through all these arguments a couple of months ago and the Javscript crowd made it crystal clear that the current awful behavior is built into vast amounts of software, starting with all of the web browsers on your phone and your computers, and it's not going to change. While I am no happier than you are that we got to this point, I don't think that a pissing contest would do anyone any good. I suppose we could add a note saying something like the media sniffing is a concession to widespread existing practice and isn't intended to be a precedent for any new media types. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 19 14:10:30 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83473A1F3E; Wed, 19 May 2021 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSs9NxE8trqQ; Wed, 19 May 2021 14:10:24 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0ECC3A1F40; Wed, 19 May 2021 14:10:22 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id ot16so6041069pjb.3; Wed, 19 May 2021 14:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4WMN1qXkPDbqCRfCyCL09Q+gJytuZuwD8aTSuopiDiI=; b=SAqeuhm70hGk//rOcSJezFGF8aUMPe97ik+Xcb0cf1yV/OEXKf+c3cKJXUKQNGSIjP vH02PAPgDMWtrSp1G0IN08FN6jh4abWzDemS7ie2CSEbGBL6VNBozHCp1O0szs6qdnnt sOztpJdtKcItbsYUpD+emZBkwZ/iHEP4a7xyomcJrMXe4gcEV+u4y4CUXUyhr20xPBfo LPkGjj/4aJkX7ZyqFYtdTyuCH1AFL5MvxAnOYmJxleMyigFp5t5XvtzxOHB1uU/AT78S RU/l4a645BQcXf/EDdl3OrSvydqmZ+j7qBSP8/AxBHHT+EdT/KHg8CqcBaRAd3BZaxrR iT6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4WMN1qXkPDbqCRfCyCL09Q+gJytuZuwD8aTSuopiDiI=; b=L6lZfzTI/IbCUOGfPY8FwYAE+BcrXy1CrnS/5L34DAO6XwTWfPF+dAW1/3HiFjaJOK 3NrL5UI+9S+EuBTSpkpM0FHwirMIb1RvRM9ZWc7uwhJZ5FnHIJDbhQOOf2FO+zhm0+r6 8XQwvXbZzdRuhJIXG08CtfVbB6NBWh6ryqO+ACzKb2v2x0zFCY6kaKE+cPtoe85kpkrK fBFa3JQRn4DEES0YKx2NCnPSprPdJlfv8906QdUz6k8o+/r1iG5Wjdf4Wf/DbiBbehum rYFLOeQQdqDtsqSsKW2j80w6fmufjKNmt0mDchyNhhKd9tawlTfWnM/G3i3S6o1etjd3 /MKQ== X-Gm-Message-State: AOAM532tf6HgsQeGYzoZSOIXqUYioKjUVXpFhGyz+X9gOEHIWOoBro8y DstSFYMQl9V0KI8MsalXUQaYMuvaDhlkH7eGVYY= X-Google-Smtp-Source: ABdhPJwoLkm7Flw+gJhhkD7ILAElViR9zoLxntadDuy6PA9Wa7Y+nZCdjIhg3NjknhSLhCoK7Fn0bO6Mk/9ITx88pZ0= X-Received: by 2002:a17:902:bb8e:b029:f4:58d1:5170 with SMTP id m14-20020a170902bb8eb02900f458d15170mr1734969pls.84.1621458620485; Wed, 19 May 2021 14:10:20 -0700 (PDT) MIME-Version: 1.0 References: <20210519164447.ECC5B82C752@ary.qy> In-Reply-To: From: Bradley Farias Date: Wed, 19 May 2021 16:10:09 -0500 Message-ID: To: John R Levine Cc: John C Klensin , media-types@ietf.org, Dispatch WG Content-Type: multipart/alternative; boundary="00000000000017951d05c2b54193" Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 21:10:30 -0000 --00000000000017951d05c2b54193 Content-Type: text/plain; charset="UTF-8" To be clear, no media sniffing is done; the mode switch on how things are determined to be a Module or Script is determined by method of consumption not the content served. On Wed, May 19, 2021 at 2:10 PM John R Levine wrote: > > While I mostly agree -- Martin is right, but it is not clear > > whether making this correct would cause more harm by creating > > confusion than it would be worth -- there is a third (and more > > drastic) way to look at this. Content-sniffing and heuristics, > > rather than properly marking up text and strict observance of > > media types, ultimately just lead to other problems down the > > line. ... > > We went through all these arguments a couple of months ago and the > Javscript crowd made it crystal clear that the current awful behavior is > built into vast amounts of software, starting with all of the web browsers > on your phone and your computers, and it's not going to change. > > While I am no happier than you are that we got to this point, I don't > think that a pissing contest would do anyone any good. I suppose we could > add a note saying something like the media sniffing is a concession to > widespread existing practice and isn't intended to be a precedent for any > new media types. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000017951d05c2b54193 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be clear, no media sniffing is done; the mode switch on= how things are determined to be a Module or Script is determined by method= of consumption not the content served.

On Wed, May 19, 2021 at 2:10 PM John= R Levine <johnl@taugh.com> wr= ote:
> While = I mostly agree -- Martin is right, but it is not clear
> whether making this correct would cause more harm by creating
> confusion than it would be worth -- there is a third (and more
> drastic) way to look at this.=C2=A0 Content-sniffing and heuristics, > rather than properly marking up text and strict observance of
> media types, ultimately just lead to other problems down the
> line. ...

We went through all these arguments a couple of months ago and the
Javscript crowd made it crystal clear that the current awful behavior is built into vast amounts of software, starting with all of the web browsers =
on your phone and your computers, and it's not going to change.

While I am no happier than you are that we got to this point, I don't <= br> think that a pissing contest would do anyone any good.=C2=A0 I suppose we c= ould
add a note saying something like the media sniffing is a concession to
widespread existing practice and isn't intended to be a precedent for a= ny
new media types.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000017951d05c2b54193-- From nobody Wed May 19 15:20:06 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6755D3A217C; Wed, 19 May 2021 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPqOpG8gkxFa; Wed, 19 May 2021 15:19:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F8D3A215D; Wed, 19 May 2021 15:19:55 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ljUXi-000Kma-0O; Wed, 19 May 2021 18:19:54 -0400 Date: Wed, 19 May 2021 18:19:48 -0400 From: John C Klensin To: John R Levine , media-types@ietf.org, Dispatch WG Message-ID: <2E638F219F84A08A499732E5@PSB> In-Reply-To: References: <20210519164447.ECC5B82C752@ary.qy> 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 Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 22:20:01 -0000 --On Wednesday, May 19, 2021 15:10 -0400 John R Levine wrote: >> While I mostly agree -- Martin is right, but it is not clear >> whether making this correct would cause more harm by creating >> confusion than it would be worth -- there is a third (and more >> drastic) way to look at this. Content-sniffing and >> heuristics, rather than properly marking up text and strict >> observance of media types, ultimately just lead to other >> problems down the line. ... > > We went through all these arguments a couple of months ago and > the Javscript crowd made it crystal clear that the current > awful behavior is built into vast amounts of software, > starting with all of the web browsers on your phone and your > computers, and it's not going to change. Understood and no disagreement. Nor am I suggesting that the IETF should say "change it anyway" or anything equally unlikely to result in changed behavior. > While I am no happier than you are that we got to this point, > I don't think that a pissing contest would do anyone any good. > I suppose we could add a note saying something like the media > sniffing is a concession to widespread existing practice and > isn't intended to be a precedent for any new media types. Nor was I suggesting a pissing contest. I am suggesting that whether to publish a document in the IETF Stream is an IETF decision, made at the IETF's discretion, and that the IESG has told us that any such documents must represent IETF consensus. I am also suggesting that if we, the IETF, say that someone MUST do something in a particular way, and do so with the full knowledge that the community to whom that is being addressed has ignored us before and may ignore us again, it is bad for the IETF's reputation... and just silly. So I am not suggesting any changes in what the document describes and recommends. While I suggest that cleaning up the language to make it more precise from a technical standpoint, I don't feel very strongly about that, especially if you and others are convinced that no one outside the current javascript implementation community will ever read it. But I do think it is important to remove the BCP 14 normative language and to improve the quality of explanation of changes, even if to more clearly say "we said to do X, the consensus of common practice has chosen Y instead, so, because this is an Informational and descriptive document, we are now specifying Y without expressing any opinion of which choice would be better in some different reality." If "the javascript crowd" is opposed to our doing that much, then this ought to be a document that they publish in some appropriate place where IETF consensus is not needed, and that the IETF, if appropriate, should just reference it. best, john From nobody Wed May 19 15:37:52 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CAA3A21D7 for ; Wed, 19 May 2021 15:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvJehazeaBzv for ; Wed, 19 May 2021 15:37:45 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A963A21CB for ; Wed, 19 May 2021 15:37:45 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id i9so21445327lfe.13 for ; Wed, 19 May 2021 15:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6a7h1+Vgksi5gEECCEbgg3ey7QHx8kOWixbOStgGVgM=; b=CXYxrdlkiMtOvRrzWCVzDA+Ieg7HhC1BQ5DPa8aiQ2d3NOFRZp42XAeB6Gd0FFzf7t mczeGrQfZm9ZPVNzrWyTuykrQfpHcIXkCCp1SRrWlPqi24dj2ab4aLx0g2AfFG62Whqc JheG+5Jr6QsXHEOO7+KvWfzWSLqy0WgRiC6YGHvbbZAQQua0xmvnLKwSn/+Bd//u5FpI yhejWeR9xEvHEs6PgotMShfB7nmfi+gg2VetLZgOfSQe31pqWXvCFeY2hI3DibTSwBVs LmJ6J8ZavDm7v1vFZVHw7ehul+BOHow1Wg1fDpHMCIv9taP3/qC2Wz/W1yP3WXYfn4GC VesA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6a7h1+Vgksi5gEECCEbgg3ey7QHx8kOWixbOStgGVgM=; b=Iq6ZcE+PezPawfWXHuOPdDKIpsvrc/QChsm3SaL9fr4TgSCvJPglllPy00R5myzBBS AKq+DnJbd5oHEPFCwUPASTfjUYU5+PgiCd6gNb3zswYf/3copnLk+tXVTfuk05VDzyMC tZOrE2xnpKD2Y4Tm52oTvdJ1RIeAVVZsZLvriC2aeIgW4kwIX95dSuqD5CAXjscYzQHj ECGUPT2WVgF+ofZT50i1e80OkwDog2vaBk9Gm+uw8LLQBQHvGN58cdP/6ZPQrHOXde++ GbVgFYwLsM6KlgdA0CncMrZ/SDxM9LnsT52zBVlulmE0UzcE0kDdG6QMS4U47HYndEnu ZQ8A== X-Gm-Message-State: AOAM533ReNRtGidq98blCerfjBpK8JGXYIvJ3u/iFsYaP6gjUKyDXast N5Nu+X83OmII81LWSZY38UgublysMbUJ7KmCzl6B96Z3eEM= X-Google-Smtp-Source: ABdhPJyLThdDRrMd+IBz3vqAi7SaNw1BfXnW3+1rm3EfjNMV9KwkE5TxKF67Jm/ORVYbYWwzCfChoU9NmcUaUj039rI= X-Received: by 2002:ac2:546b:: with SMTP id e11mr1171542lfn.395.1621463862425; Wed, 19 May 2021 15:37:42 -0700 (PDT) MIME-Version: 1.0 References: <20210519164447.ECC5B82C752@ary.qy> <2E638F219F84A08A499732E5@PSB> In-Reply-To: <2E638F219F84A08A499732E5@PSB> From: Myles Borins Date: Wed, 19 May 2021 18:37:30 -0400 Message-ID: To: John C Klensin Cc: John R Levine , media-types@ietf.org, Dispatch WG Content-Type: multipart/alternative; boundary="00000000000089abda05c2b67923" Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 22:37:51 -0000 --00000000000089abda05c2b67923 Content-Type: text/plain; charset="UTF-8" To speak candidly... I don't love the us vs. them language being thrown around here. There are many people who do work with and on JavaScript that participate within IETF, and drawing a distinction between the two parties seems unnecessarily decisive. Myself and various others have been trying, as good citziens of the internet, to document a web reality and update the current out of date RFC in order to make the internet better. I outlined examples above of certain platforms waiting on a clear signal from IETF / IANA before supporting the .mjs extension with the appropriate mimetype... The lack of this support creates developer friction and confusion. It is extremely demotivating to be trying to work through a process for many years and to consistently have folks jump in to give minor feedback that continues to derail progress and burn out the people trying in good faith to work with the IETF and hopefully become more regular contributors. An expression comes to mind that "perfect is the enemy of good". This is not to say that we should lower the quality bar here, but the current RFC is inaccurate to web reality in ways this new rfc attempts to fix. We first attempted to amend the existing rfc, but were requested to make a new rfc due to the level of changes. We are now finally what feels like close to done and are being challenged on both parts of the RFC we never wrote as well as the fundamental existence of the document to begin with. I understand that folks come and go and that there are many steps along the way... but the way this overall process has played out is extremely demotivating and disappointing. I will definitely keep trying to push this forward, put I do wonder if we could table some of the feedback we are receiving right now to come in an update to the proposed text... As I genuinely fear that this will never get published at the rate things have gone for over 3 years now On Wed, May 19, 2021, 6:20 PM John C Klensin wrote: > > > --On Wednesday, May 19, 2021 15:10 -0400 John R Levine > wrote: > > >> While I mostly agree -- Martin is right, but it is not clear > >> whether making this correct would cause more harm by creating > >> confusion than it would be worth -- there is a third (and more > >> drastic) way to look at this. Content-sniffing and > >> heuristics, rather than properly marking up text and strict > >> observance of media types, ultimately just lead to other > >> problems down the line. ... > > > > We went through all these arguments a couple of months ago and > > the Javscript crowd made it crystal clear that the current > > awful behavior is built into vast amounts of software, > > starting with all of the web browsers on your phone and your > > computers, and it's not going to change. > > Understood and no disagreement. Nor am I suggesting that the > IETF should say "change it anyway" or anything equally unlikely > to result in changed behavior. > > > While I am no happier than you are that we got to this point, > > I don't think that a pissing contest would do anyone any good. > > I suppose we could add a note saying something like the media > > sniffing is a concession to widespread existing practice and > > isn't intended to be a precedent for any new media types. > > Nor was I suggesting a pissing contest. I am suggesting that > whether to publish a document in the IETF Stream is an IETF > decision, made at the IETF's discretion, and that the IESG has > told us that any such documents must represent IETF consensus. > > I am also suggesting that if we, the IETF, say that someone MUST > do something in a particular way, and do so with the full > knowledge that the community to whom that is being addressed has > ignored us before and may ignore us again, it is bad for the > IETF's reputation... and just silly. > > So I am not suggesting any changes in what the document > describes and recommends. While I suggest that cleaning up the > language to make it more precise from a technical standpoint, I > don't feel very strongly about that, especially if you and > others are convinced that no one outside the current javascript > implementation community will ever read it. But I do think it > is important to remove the BCP 14 normative language and to > improve the quality of explanation of changes, even if to more > clearly say "we said to do X, the consensus of common practice > has chosen Y instead, so, because this is an Informational and > descriptive document, we are now specifying Y without expressing > any opinion of which choice would be better in some different > reality." > > If "the javascript crowd" is opposed to our doing that much, > then this ought to be a document that they publish in some > appropriate place where IETF consensus is not needed, and that > the IETF, if appropriate, should just reference it. > > best, > john > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000089abda05c2b67923 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To speak candidly... I don't love the us vs. them lan= guage being thrown around here.

There are many people who do work with and on JavaScript that participate= within IETF, and drawing a distinction between the two parties seems unnec= essarily decisive.

Mysel= f and various others have been trying, as good citziens of the internet, to= document a web reality and update the current out of date RFC in order to = make the internet better. I outlined examples above of certain platforms wa= iting on a clear signal from IETF / IANA before supporting the .mjs extensi= on with the appropriate mimetype... The lack of this support creates develo= per friction and confusion.

It is extremely demotivating to be trying to work through a process for= many years and to consistently have folks jump in to give minor feedback t= hat continues to derail progress and burn out the people trying in good fai= th to work with the IETF and hopefully become more regular contributors.

An expression comes to min= d that "perfect is the enemy of good". This is not to say that we= should lower the quality bar here, but the current RFC is inaccurate to we= b reality in ways this new rfc attempts to fix.

=
We first attempted to amend the existing rfc, but w= ere requested to make a new rfc due to the level of changes. We are now fin= ally what feels like close to done and are being challenged on both parts o= f the RFC we never wrote as well as the fundamental existence of the docume= nt to begin with.

I unde= rstand that folks come and go and that there are many steps along the way..= . but the way this overall process has played out is extremely demotivating= and disappointing.

I wi= ll definitely keep trying to push this forward, put I do wonder if we could= table some of the feedback we are receiving right now to come in an update= to the proposed text... As I genuinely fear that this will never get publi= shed at the rate things have gone for over 3 years now=C2=A0
On Wed, M= ay 19, 2021, 6:20 PM John C Klensin <john-ietf@jck.com> wrote:
=

--On Wednesday, May 19, 2021 15:10 -0400 John R Levine
<johnl@taugh.com> wrote:

>> While I mostly agree -- Martin is right, but it is not clear
>> whether making this correct would cause more harm by creating
>> confusion than it would be worth -- there is a third (and more
>> drastic) way to look at this.=C2=A0 Content-sniffing and
>> heuristics, rather than properly marking up text and strict
>> observance of media types, ultimately just lead to other
>> problems down the line. ...
>
> We went through all these arguments a couple of months ago and
> the Javscript crowd made it crystal clear that the current
> awful behavior is built into vast amounts of software,
> starting with all of the web browsers on your phone and your
> computers, and it's not going to change.

Understood and no disagreement.=C2=A0 Nor am I suggesting that the
IETF should say "change it anyway" or anything equally unlikely to result in changed behavior.

> While I am no happier than you are that we got to this point,
> I don't think that a pissing contest would do anyone any good.
> I suppose we could add a note saying something like the media
> sniffing is a concession to widespread existing practice and
> isn't intended to be a precedent for any new media types.

Nor was I suggesting a pissing contest.=C2=A0 I am suggesting that
whether to publish a document in the IETF Stream is an IETF
decision, made at the IETF's discretion, and that the IESG has
told us that any such documents must represent IETF consensus.=C2=A0

I am also suggesting that if we, the IETF, say that someone MUST
do something in a particular way, and do so with the full
knowledge that the community to whom that is being addressed has
ignored us before and may ignore us again, it is bad for the
IETF's reputation... and just silly.

So I am not suggesting any changes in what the document
describes and recommends.=C2=A0 While I suggest that cleaning up the
language to make it more precise from a technical standpoint, I
don't feel very strongly about that, especially if you and
others are convinced that no one outside the current javascript
implementation community will ever read it.=C2=A0 =C2=A0But I do think it is important to remove the BCP 14 normative language and to
improve the quality of explanation of changes, even if to more
clearly say "we said to do X, the consensus of common practice
has chosen Y instead, so, because this is an Informational and
descriptive document, we are now specifying Y without expressing
any opinion of which choice would be better in some different
reality."

If "the javascript crowd" is opposed to our doing that much,
then this ought to be a document that they publish in some
appropriate place where IETF consensus is not needed, and that
the IETF, if appropriate, should just reference it.

best,
=C2=A0 =C2=A0john

_______________________________________________
dispatch mailing list
d= ispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispa= tch
--00000000000089abda05c2b67923-- From nobody Wed May 19 16:07:01 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB53A22C5; Wed, 19 May 2021 16:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctZ9xhx8v0XF; Wed, 19 May 2021 16:06:55 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC0A3A22C3; Wed, 19 May 2021 16:06:54 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id pi6-20020a17090b1e46b029015cec51d7cdso4229198pjb.5; Wed, 19 May 2021 16:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BqWl2CiFGXN1+LG5dWGlZnXgsMTW2nb0twSKsA4gcYc=; b=Q4QWFGNHB1gHnX/FuK+2GYe1WffgCZ13hC1yBSrkOw4ds8xGEco9b/YggFzA691QLM j3NDNe31FAYXfaJd/NbD5y2zV6/9zPMLfZqHiuxiwZZ5i/Zn4lx+ANodJziWbf74+loz /MYDTDs5ZIvCOelq+WdNl0/600sMGI4e2IJkq1RbY5xP1iZ+IJW3n9VBY83+bO/5tlff jXkeQy4ebmJXiXqMMJqgFxq8ucgr2+GqWATfocheXP4Jc+bpcSC8n12RB1Fjw4PAaweD 7ZiAmjBP1habEx4JMtxGMxtWEyH08B7cMtw+X4vCpwClHVrnWtuUfz6akpiTNK0/Vcd+ L49w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BqWl2CiFGXN1+LG5dWGlZnXgsMTW2nb0twSKsA4gcYc=; b=DfcL611mRtHwKCsjAdeNaNvHMBM9Mm6pLgCIq6yd+K6cyJ8kBtl/xlMSukeArFNDDk D1T6hBqEyYHXoUFWsyObaSqQuSRdf5dZKV1U/WqsrioA+3rhEEhzCE4jhBNmBPBmPhen l3Qun4njpUfVnanL+IemHTmcnNGiNFgzjl/trrgxc96d0rv+V+6c7AiX7BGXfhqvRJZN skRnMWCAXbmKay6NaSZ80ugPuLDRhMZX8h+CEoYQeviV+hsAsKO2zXtKzdOtqm7FhK2g fIJ5zPBhG5P5di0I2Hqq+UFwZZ/b4BxdxIAoLv/54ZPDhGrmDXo6RE9nD/v5QZxwqyt5 O2gg== X-Gm-Message-State: AOAM531q744xWVlnZ3/m8qhcwda2wsuinWNR5aQN2BT1W08A8P1aqNfm nTKS6B52PSLtKBqQpxLcCQ4+hOxYt4RvLjVd2Fc= X-Google-Smtp-Source: ABdhPJwZcCGiOENdBN4V2dbQPyc+Y011/4vp8tMr43EdkcobDm0GIDTEun+lq0JhgL+9vkoeDyfeiuY+Jgaa79NHE9k= X-Received: by 2002:a17:902:bb8e:b029:f4:58d1:5170 with SMTP id m14-20020a170902bb8eb02900f458d15170mr2222556pls.84.1621465612643; Wed, 19 May 2021 16:06:52 -0700 (PDT) MIME-Version: 1.0 References: <20210519164447.ECC5B82C752@ary.qy> <2E638F219F84A08A499732E5@PSB> In-Reply-To: From: Bradley Farias Date: Wed, 19 May 2021 18:06:41 -0500 Message-ID: To: Myles Borins Cc: John C Klensin , media-types@ietf.org, Dispatch WG , John R Levine Content-Type: multipart/alternative; boundary="000000000000db6f7305c2b6e124" Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 23:07:00 -0000 --000000000000db6f7305c2b6e124 Content-Type: text/plain; charset="UTF-8" I also would like to speak somewhat directly. > I am also suggesting that if we, the IETF, say that someone MUST do something in a particular way, and do so with the full knowledge that the community to whom that is being addressed has ignored us before and may ignore us again, it is bad for the IETF's reputation... and just silly. I would state that given the sheer denialism and duration of this review for this particular RFC the reputation is already been soured for both parts of the Node.js community and ECMA TC39 members. I've become fairly used to 6 months of silence, followed by a brief comment period resetting the 6 month time for comments that is both derisive and often demanding re-explanation of how the browsers and the current state of web works. This is not a good look and it does feel that the IETF largely does already ignore other ecosystems, so it is understandable that they reciprocate in kind even if that is undesirable for all parties involved. > While I suggest that cleaning up the language to make it more precise from a technical standpoint, I don't feel very strongly about that, especially if you and others are convinced that no one outside the current javascript implementation community will ever read it. But I do think it is important to remove the BCP 14 normative language and to improve the quality of explanation of changes, even if to more clearly say "we said to do X, the consensus of common practice has chosen Y instead, so, because this is an Informational and descriptive document, we are now specifying Y without expressing any opinion of which choice would be better in some different reality." I think such is possible, but given the lack of communication after such changes we have done in the past I do not see it as a fruitful exercise except to gain a new 6 month comment period followed by silence and a last minute issues on what I personally regard somewhat as repetitive nature that mostly are resolved by non-significant changes and or relying on explanation of how other standards have evolved outside of the IETF process, likely in part due to this friction. > If "the javascript crowd" is opposed to our doing that much, then this ought to be a document that they publish in some appropriate place where IETF consensus is not needed, and that the IETF, if appropriate, should just reference it. This is the kind of derision I was referencing earlier. On Wed, May 19, 2021 at 5:38 PM Myles Borins wrote: > To speak candidly... I don't love the us vs. them language being thrown > around here. > > There are many people who do work with and on JavaScript that participate > within IETF, and drawing a distinction between the two parties seems > unnecessarily decisive. > > Myself and various others have been trying, as good citziens of the > internet, to document a web reality and update the current out of date RFC > in order to make the internet better. I outlined examples above of certain > platforms waiting on a clear signal from IETF / IANA before supporting the > .mjs extension with the appropriate mimetype... The lack of this support > creates developer friction and confusion. > > It is extremely demotivating to be trying to work through a process for > many years and to consistently have folks jump in to give minor feedback > that continues to derail progress and burn out the people trying in good > faith to work with the IETF and hopefully become more regular contributors. > > An expression comes to mind that "perfect is the enemy of good". This is > not to say that we should lower the quality bar here, but the current RFC > is inaccurate to web reality in ways this new rfc attempts to fix. > > We first attempted to amend the existing rfc, but were requested to make a > new rfc due to the level of changes. We are now finally what feels like > close to done and are being challenged on both parts of the RFC we never > wrote as well as the fundamental existence of the document to begin with. > > I understand that folks come and go and that there are many steps along > the way... but the way this overall process has played out is extremely > demotivating and disappointing. > > I will definitely keep trying to push this forward, put I do wonder if we > could table some of the feedback we are receiving right now to come in an > update to the proposed text... As I genuinely fear that this will never get > published at the rate things have gone for over 3 years now > > On Wed, May 19, 2021, 6:20 PM John C Klensin wrote: > >> >> >> --On Wednesday, May 19, 2021 15:10 -0400 John R Levine >> wrote: >> >> >> While I mostly agree -- Martin is right, but it is not clear >> >> whether making this correct would cause more harm by creating >> >> confusion than it would be worth -- there is a third (and more >> >> drastic) way to look at this. Content-sniffing and >> >> heuristics, rather than properly marking up text and strict >> >> observance of media types, ultimately just lead to other >> >> problems down the line. ... >> > >> > We went through all these arguments a couple of months ago and >> > the Javscript crowd made it crystal clear that the current >> > awful behavior is built into vast amounts of software, >> > starting with all of the web browsers on your phone and your >> > computers, and it's not going to change. >> >> Understood and no disagreement. Nor am I suggesting that the >> IETF should say "change it anyway" or anything equally unlikely >> to result in changed behavior. >> >> > While I am no happier than you are that we got to this point, >> > I don't think that a pissing contest would do anyone any good. >> > I suppose we could add a note saying something like the media >> > sniffing is a concession to widespread existing practice and >> > isn't intended to be a precedent for any new media types. >> >> Nor was I suggesting a pissing contest. I am suggesting that >> whether to publish a document in the IETF Stream is an IETF >> decision, made at the IETF's discretion, and that the IESG has >> told us that any such documents must represent IETF consensus. >> >> I am also suggesting that if we, the IETF, say that someone MUST >> do something in a particular way, and do so with the full >> knowledge that the community to whom that is being addressed has >> ignored us before and may ignore us again, it is bad for the >> IETF's reputation... and just silly. >> >> So I am not suggesting any changes in what the document >> describes and recommends. While I suggest that cleaning up the >> language to make it more precise from a technical standpoint, I >> don't feel very strongly about that, especially if you and >> others are convinced that no one outside the current javascript >> implementation community will ever read it. But I do think it >> is important to remove the BCP 14 normative language and to >> improve the quality of explanation of changes, even if to more >> clearly say "we said to do X, the consensus of common practice >> has chosen Y instead, so, because this is an Informational and >> descriptive document, we are now specifying Y without expressing >> any opinion of which choice would be better in some different >> reality." >> >> If "the javascript crowd" is opposed to our doing that much, >> then this ought to be a document that they publish in some >> appropriate place where IETF consensus is not needed, and that >> the IETF, if appropriate, should just reference it. >> >> best, >> john >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000db6f7305c2b6e124 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also = would like to speak somewhat directly.

> I am also su= ggesting that if we, the IETF, say that someone MUST
do something in a= particular way, and do so with the full
knowledge that the community to= whom that is being addressed has
ignored us before and may ignore us ag= ain, it is bad for the
IETF's reputation... and just silly.

I would state that given the sheer denialism a= nd duration of this review for this particular RFC the reputation is alread= y been soured for both parts of the Node.js community and ECMA TC39 members= . I've become fairly used to 6 months of silence, followed by a brief c= omment period resetting the 6 month time for comments that is both derisive= and often demanding re-explanation of how the browsers and the current sta= te of web works. This is not a good look and it does feel that the IETF lar= gely does already ignore other ecosystems, so it is understandable that the= y reciprocate in kind even if that is undesirable for all parties involved.=

>=C2=A0 While I suggest that cleaning up thelanguage to make it more precise from a technical standpoint, I
don&= #39;t feel very strongly about that, especially if you and
others are co= nvinced that no one outside the current javascript
implementation commun= ity will ever read it.=C2=A0 =C2=A0But I do think it
is important to rem= ove the BCP 14 normative language and to
improve the quality of explanat= ion of changes, even if to more
clearly say "we said to do X, the c= onsensus of common practice
has chosen Y instead, so, because this is an= Informational and
descriptive document, we are now specifying Y without= expressing
any opinion of which choice would be better in some differen= t
reality."

I think such is po= ssible, but given the lack of communication after such changes we have done= in the past I do not see it as a fruitful exercise except to gain a new 6 = month comment period followed by silence and a last minute issues on what I= personally regard somewhat as repetitive nature that=C2=A0mostly are resol= ved by non-significant changes and or relying on explanation of how other s= tandards have evolved outside of the IETF process, likely in part due to th= is friction.

> If "the javascript crow= d" is opposed to our doing that much,
then this ought to be a doc= ument that they publish in some
appropriate place where IETF consensus i= s not needed, and that
the IETF, if appropriate, should just reference i= t.

This is the kind of derision I was = referencing earlier.

On Wed, May 19, 2021 at 5:38 PM Myles Borins <= mylesborins=3D40github.com@d= marc.ietf.org> wrote:
To speak candidly... I don't love the us= vs. them language being thrown around here.

There are many people who do work with and on JavaScript tha= t participate within IETF, and drawing a distinction between the two partie= s seems unnecessarily decisive.

Myself and various others have been trying, as good citziens of t= he internet, to document a web reality and update the current out of date R= FC in order to make the internet better. I outlined examples above of certa= in platforms waiting on a clear signal from IETF / IANA before supporting t= he .mjs extension with the appropriate mimetype... The lack of this support= creates developer friction and confusion.

It is extremely demotivating to be trying to work throug= h a process for many years and to consistently have folks jump in to give m= inor feedback that continues to derail progress and burn out the people try= ing in good faith to work with the IETF and hopefully become more regular c= ontributors.

An expressi= on comes to mind that "perfect is the enemy of good". This is not= to say that we should lower the quality bar here, but the current RFC is i= naccurate to web reality in ways this new rfc attempts to fix.

We first attempted to amend the exis= ting rfc, but were requested to make a new rfc due to the level of changes.= We are now finally what feels like close to done and are being challenged = on both parts of the RFC we never wrote as well as the fundamental existenc= e of the document to begin with.

I understand that folks come and go and that there are many steps= along the way... but the way this overall process has played out is extrem= ely demotivating and disappointing.

I will definitely keep trying to push this forward, put I do wo= nder if we could table some of the feedback we are receiving right now to c= ome in an update to the proposed text... As I genuinely fear that this will= never get published at the rate things have gone for over 3 years now=C2= =A0

On Wed, May 19, 2021, 6:20 PM John C Klensin <john-ietf@jck.com> wrote:
<= /div>


--On Wednesday, May 19, 2021 15:10 -0400 John R Levine
<johnl@taugh.com> wrote:

>> While I mostly agree -- Martin is right, but it is not clear
>> whether making this correct would cause more harm by creating
>> confusion than it would be worth -- there is a third (and more
>> drastic) way to look at this.=C2=A0 Content-sniffing and
>> heuristics, rather than properly marking up text and strict
>> observance of media types, ultimately just lead to other
>> problems down the line. ...
>
> We went through all these arguments a couple of months ago and
> the Javscript crowd made it crystal clear that the current
> awful behavior is built into vast amounts of software,
> starting with all of the web browsers on your phone and your
> computers, and it's not going to change.

Understood and no disagreement.=C2=A0 Nor am I suggesting that the
IETF should say "change it anyway" or anything equally unlikely to result in changed behavior.

> While I am no happier than you are that we got to this point,
> I don't think that a pissing contest would do anyone any good.
> I suppose we could add a note saying something like the media
> sniffing is a concession to widespread existing practice and
> isn't intended to be a precedent for any new media types.

Nor was I suggesting a pissing contest.=C2=A0 I am suggesting that
whether to publish a document in the IETF Stream is an IETF
decision, made at the IETF's discretion, and that the IESG has
told us that any such documents must represent IETF consensus.=C2=A0

I am also suggesting that if we, the IETF, say that someone MUST
do something in a particular way, and do so with the full
knowledge that the community to whom that is being addressed has
ignored us before and may ignore us again, it is bad for the
IETF's reputation... and just silly.

So I am not suggesting any changes in what the document
describes and recommends.=C2=A0 While I suggest that cleaning up the
language to make it more precise from a technical standpoint, I
don't feel very strongly about that, especially if you and
others are convinced that no one outside the current javascript
implementation community will ever read it.=C2=A0 =C2=A0But I do think it is important to remove the BCP 14 normative language and to
improve the quality of explanation of changes, even if to more
clearly say "we said to do X, the consensus of common practice
has chosen Y instead, so, because this is an Informational and
descriptive document, we are now specifying Y without expressing
any opinion of which choice would be better in some different
reality."

If "the javascript crowd" is opposed to our doing that much,
then this ought to be a document that they publish in some
appropriate place where IETF consensus is not needed, and that
the IETF, if appropriate, should just reference it.

best,
=C2=A0 =C2=A0john

_______________________________________________
dispatch mailing list
d= ispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispa= tch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000db6f7305c2b6e124-- From nobody Wed May 19 17:07:04 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AB93A2498 for ; Wed, 19 May 2021 17:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=esLrgTWN; dkim=pass (2048-bit key) header.d=taugh.com header.b=NyDz3cd2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J9zJVsvO3rg for ; Wed, 19 May 2021 17:06:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF5D3A24C3 for ; Wed, 19 May 2021 17:06:53 -0700 (PDT) Received: (qmail 53944 invoked from network); 20 May 2021 00:06:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=d2b2.60a5a81b.k2105; bh=mFqxnurgbntEVDgRC1Dzlxj58y3OsLyYyc61EOvRgyg=; b=esLrgTWN/Jb2KiYw1eVLIZ75Ud8gS6ZygoYRxUX1Kq1bQxlpLonT5bRi9+Ujr1hPdukaMKpMyKAbi0H4LGCPRiX5sGGWJZ0Xl65NYiBVAHiEYrggjo2XUzALBBRYfOaDjBsml2xwODVff8gB8bU12+uzCSYbWjjpnKAC6/e/mx9A3pJx1rYb0Gtw5BmWvKX2rXPk7xadnq7YWQu+0tpUZbDa/FR2O28a6xwT6fI/gB7Rnrs8MyWTULy+HA0JTMTBLu8FTzEMRW3LwI5DGIsEylm5BMVpiocsnNvtQLday5XnvAl/HTq8Z7+mUhnwU6Joy45Q+33PVOdLiwGrbGgslg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=d2b2.60a5a81b.k2105; bh=mFqxnurgbntEVDgRC1Dzlxj58y3OsLyYyc61EOvRgyg=; b=NyDz3cd2QPY7+7Vi4et2plUi6KJHwQ+LjWDv/jvtgooReLp4vzcHpBSqUqFt7EQ7TjDM89MAKKGQZoFhdnIQXQfDa/zs4xA5Ed/4X89Fm/OUGm6cV3int1f0TY594zVKUL1M4H5yOB4UEf6n4m1rEeninIkoSvl3vyo6GYsez/smBwJUBgAUh8IwtSIyzx8cNr5VJGYPE8Oy2uSWz/1qZkvFvsFR5S82WxKkcvkTb8j6JbIFV0qpDrITxjTxbWqcTzpit8Z9mfqc7IidZ/qNUQBIdcRR5hi9M9LZROWJgEmj4p3x+QDvyv51bzEqGb1Uvj1e8fDJLWcXYXVxwaKmQA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 20 May 2021 00:06:50 -0000 Received: by ary.qy (Postfix, from userid 501) id 3985A832EFB; Wed, 19 May 2021 20:06:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id A9539832EDD; Wed, 19 May 2021 20:06:49 -0400 (EDT) Date: 19 May 2021 20:06:49 -0400 Message-ID: From: "John R Levine" To: "Myles Borins" , "John C Klensin" Cc: media-types@ietf.org, "Dispatch WG" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210519164447.ECC5B82C752@ary.qy> <2E638F219F84A08A499732E5@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 00:06:59 -0000 > We first attempted to amend the existing rfc, but were requested to make a > new rfc due to the level of changes. We are now finally what feels like > close to done and are being challenged on both parts of the RFC we never > wrote as well as the fundamental existence of the document to begin with. If it wasn't clear. while I am not thrilled that one has to look for the BOM to tell how a Javascript item is encoded, I also realize that it's baked into every browser in the world, so I agree that we should document the reality. In the future it would be nice to make the types and content match better, but that's something to address when new types appear. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 19 17:21:40 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C873A253D; Wed, 19 May 2021 17:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW0R2AghPmHk; Wed, 19 May 2021 17:21:31 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320094.outbound.protection.outlook.com [40.107.132.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D843A2538; Wed, 19 May 2021 17:21:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uhx5YyC/QdFYSoFq0OyRzGrByZclzJOzFnDEkc2RywqWnjWvHiJZ2iRrkpeB+yp6h7k64pQo4IrbUOTB7Vk3J6b4M99bf3Gjy1SSudd1oVr2PviRQyc+Wm3wr+YXuczanJy3yGdy8cBqB+p8jUa3KpsY5u1fa1KqILkReBKMnUPmrp1Q5NNpwm40SNGseTIb2CRhLH83turmRbkF3dC6nihO4CZW0W+5ht4++JE4n3Kxw/H7VZqS6PH8pKsB+hMdn+COkgbSun2XHnxxFPKMl6MW5WkTLEM+dkIrbWLeNhXzblcQFlqdW3KJ416u+lVoaLKgqzSh9tbmQR9nkbL9Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=33IrAa0XSy/CxpydAIR86fbqYukPw3BiMLkrbPAjziI=; b=fYPelImpR5iy/wjsIMrTiCGcY7+9YaJP2O4MP9wdMo4GR5NqqHlmKCui2xxzE94ZhhuJcj9+J/acFPBD0K26vYiob4kbmDA/wdVCjL/nA6WdHFHMUjGrQBEe7WL44OENJrwTXVRnqBmoc50Xx1vVIS6GT4NPoOcCN/Ly/JSib8oRubbZka8Mez4XQd+6cX5o9o5i/BtL3U46UJrvdIJbrmsfspa5XVAM9CMgg+2IUIdnzpRHIj6PeVV2XJkFFC6o7PIrWHiN5II6mHGo5DZ+qlO78k7vsUBR42FyOUClmjdkr1PV50s8ZcKC2qJxFm8Gz7lH+WkgCWW6b/LZZElMsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=33IrAa0XSy/CxpydAIR86fbqYukPw3BiMLkrbPAjziI=; b=ZsGs6owOm3xSV5Lsfl6oHklMRDlmVo3GReKlIc8J72b91DBQGcrzCY7LqlNra9wZe8KtGi2Keyb1HlM3R9eMkJgI3uk8HAZoPdo7b3Cj4B04NhXIk17O6D6MIyGj2pJq6SE+POF71bnyccGM9+Bi7UVfFOI7H9f528VPhjP+x6s= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB4266.jpnprd01.prod.outlook.com (2603:1096:404:d5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25; Thu, 20 May 2021 00:21:20 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511%5]) with mapi id 15.20.4129.033; Thu, 20 May 2021 00:21:20 +0000 To: Bradley Farias , Myles Borins Cc: media-types@ietf.org, Dispatch WG References: <20210519164447.ECC5B82C752@ary.qy> <2E638F219F84A08A499732E5@PSB> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Thu, 20 May 2021 09:21:18 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [114.185.21.49] X-ClientProxiedBy: TY1PR01CA0150.jpnprd01.prod.outlook.com (2603:1096:402:1::26) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (114.185.21.49) by TY1PR01CA0150.jpnprd01.prod.outlook.com (2603:1096:402:1::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.23 via Frontend Transport; Thu, 20 May 2021 00:21:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 34e87e87-247e-450f-3adc-08d91b2530f7 X-MS-TrafficTypeDiagnostic: TY2PR01MB4266: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sA8WMg/1frh/CW1AyIYpV9lWvVqGPFJAcvQtccOLHeiLwnqzXfGim9AF0JRPInN0YyP3PPX2J3tFPZzqFtjoK5wcgVKsya/HQL9xDR+4XqZf9UlZq35ww78efwisP0UnBBnfNRrIvxkaM1prwN4i/YD7NiOpE+o9WYnmUgaQxV0abCJiZ381nS89mpoTWa7DRWZpTe6CGTkpUhSrm3OuJ3nNaA/xLndjAzdFUKZ+0IXHOoPQXL2xVPiY+ygTEDUXdlxv7YnHe1M4JgH8+hFz9d+8a1Vw+IqxnyiNf/7i3iSgps0ljA3kCEz57luw3PBI1e3RFNL/FkGURwEKZbs+1dh/C9QFT5ShUhV55Q0IefJddsIg1hEcXeTniUJ2fIMSZOsJpb8JzgS3noKmn81ISU5STuLPEC097kITNdBkUcKcF6lHu6JgjZqem0TrkLRScrbxdIbGgUliqNy/9mkowrisrq/5Y4QRbMPXg6pRxI+dbsoaMFB15E4YeYXXTmilaUx1fZIKDOTihB6KO4mvM/vHaW0crQfSb16okBHZttqFS5t+ReGVkDXaGmAsH5JFiaQpBzZRt0uzbtWNL+NBZ6fhJlFwD8i3fbedDE8NqDYXEzieo0v1xZR9tU/xmIHtcoSk8P3jfkBE1q6+gKarLDEcb+dgjvtrai5qNgPLqUT+xW0wLIGSsARvqACAtLjHQL/97Qnbyc5Lxw+/kNGzrVYmzEfhDm/Sq9+HGbcHioIHc4fQgJzBKb4LX2Rq2hN8TvVPd7f39bSuS31jOfEa5IPcri3HgpzKk1mFShC9+6xD6KzNMKa9PGVejw63Y/cj1vNo47SY6bqG3OPPLn5+Rg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(396003)(346002)(39840400004)(366004)(66574015)(31686004)(110136005)(5660300002)(83380400001)(2616005)(956004)(38350700002)(786003)(4326008)(30864003)(52116002)(66946007)(53546011)(316002)(66476007)(16576012)(8936002)(36916002)(66556008)(16526019)(8676002)(31696002)(26005)(2906002)(38100700002)(186003)(6486002)(966005)(86362001)(478600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?WUh4TWE2T3FSeE5hU1V2b0Y5b3FzV1ZBSWdiYkp0TVY5VzdZVVF5UEl0WXp6?= =?utf-8?B?Z0pydkxJQWxWZ3E2Z3pKQ1hBKzNlbUJZNElvUVlwRXdxTnROSWd6eXJxdUlS?= =?utf-8?B?M1F3REZPd3JVeVRCbjJQYmM0WXpzNm5TSEozalJrUGJ0M2pqRGFtdURMa1U5?= =?utf-8?B?YlpLbnpQMXVtRk1FL1YyUVpZZzJVRnM3bkhEQ1dNVzdVSEdrdXBPaE53NElB?= =?utf-8?B?eGdSajFWL3I1SEVuWnRoUkRzTGZ1KzBYSUhiZlhwdjZjTk0zbDF3VHBRLzJ4?= =?utf-8?B?OFp5ZXBRU0d4QVJLVUVJU29Za0NHb2hxanp5YWJzYmJTT0g0QzNrRHJqcmFw?= =?utf-8?B?Wmg3ZFo2Um9sWXJFVTBOQXRVWGhGY1ROOXUxV0hCOHZ4Q2FNSlFub3ZtKyt2?= =?utf-8?B?MFFXa2dLZ3UvdnhQbVRFWkJGOXdtYzZRbzlLV0N0Z3BHNlFCQ1RLQXR1NWNQ?= =?utf-8?B?eCs5T0dPbFpWWGFqL241a3lSVmsxbUZ2NVJidUZubHBJMUJOYXVmVi9ranI2?= =?utf-8?B?SWN0Y2tmZlV6UVBaVXdxMzg3SWVCTEpyMjVxd0lENm1WYjEyZEdPZlFCMTB2?= =?utf-8?B?aHJPV01vbHh5SmorL0VBckVRUU5kelZ5K2RYaWVVU2YrRTJpWGVyOUJuNkpT?= =?utf-8?B?bmpHemVlZzI3UVE5WXhJdDhrekIzMDhTTWVFV0tIcjlIaEFSNzhldzluaUh3?= =?utf-8?B?R2pISWJ6dFI1QnRIYWdvcmRnYnBsejRUb045b05EcjNBQXd1dHUzMlJRS242?= =?utf-8?B?SkYwRm1JeXMwZGxyQlBrUmhSYTNRRnVHbVVsK3lsR2pueitBTmU0UjdiMVNO?= =?utf-8?B?b2JxdUN2MDluRnk5OFIyQUloNHFPV3FJOTRONHRRaVhxcEtYZVZFQzlkUUFM?= =?utf-8?B?alROM2tFZ2JtaG5BRHdPSEh2cnhkeG9UVEd5eHBSRjhZZTFYNHdyNGRqZ2VY?= =?utf-8?B?QTVqQ0ZNNXpoRWYzRnMrSUNvRUliTXgzSlI1cUxGV1djTUM5WHZJN1lHUlY0?= =?utf-8?B?SlRud2Q1bXBRWXVpbE9CemJaa1lZZjh1MTBVTTd1V0RLTEpZTDBOZytST3VU?= =?utf-8?B?b2VIYisvR1dKcThNU3NkK2J0dG1KczJRSk55Q3BQWEE0V2NIY1pZcFd0ZW9s?= =?utf-8?B?eUpLa0dyL2kvb2IzampwWCt2WmNZR3FCMXFrdzVtb3Z0MXFYYjhzeTZtTUJP?= =?utf-8?B?c1ZrbU9XbUVxOHVGbmd0eGhEUk1qbkhwbzJON2M0c2x3MndOKzQxajRDbmNt?= =?utf-8?B?NmhCWWFMZWs3elFMdUZYSFo3ZDE5NkF5VEdJUjB3VjhSV3ZWb3grZzJlWlZh?= =?utf-8?B?cURDVWM4akNXektkdTZMNDZMVnc2MVlxRDlZdVV1VWJ4VWhBd20xOW9Od0VW?= =?utf-8?B?aHpISWg0WWNhV2hvLzNza2FNS1JrMG1UVjlsOE1UU2c0bGxjSllwamxmVFNO?= =?utf-8?B?akY1TXdtZ01vaE5MSnE5eVU5TkpoaUdDUklBMUlZeGlXNUtnSzNmblE2MDhj?= =?utf-8?B?R0llOG5Gd3ZBMityZmxEN0llVFRKTHhwZzZIZnV1c2liV2FwOUdZbTl5UFlE?= =?utf-8?B?MjlxWEs5cGhPN0hmTWRiaGIxbGQ0bGVURVpmaGFPMXBkNkdBbHVDaER2NUNX?= =?utf-8?B?c05kd0NCc3VjUWZmTTBNNHJRTXNXblJjK0Y0bzB5R0pnYzZsNnVYMkdmdjkw?= =?utf-8?B?UmhXdVFnZFdZU3NodmxMTHpRZmZoQjRrOSt0UzQ3RHYzYUdvb2NORE9JTG5z?= =?utf-8?Q?oLGZnIv8dKV9+J5dHt7PJUH43rp58d9znuG4Gm1?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 34e87e87-247e-450f-3adc-08d91b2530f7 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2021 00:21:20.0149 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BPm760K7Gu94Ov4ZX4GqblJfZbHCglEFCuqrflQASkQYk4YKuGYYHsoqXMXVWWdruhbz2ATgEdIa5vjEEkO1QA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB4266 Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 00:21:35 -0000 Hello Bradley, On 2021-05-20 08:06, Bradley Farias wrote: > I also would like to speak somewhat directly. > >> I am also suggesting that if we, the IETF, say that someone MUST >> do something in a particular way, and do so with the full >> knowledge that the community to whom that is being addressed has >> ignored us before and may ignore us again, it is bad for the >> IETF's reputation... and just silly. > > I would state that given the sheer denialism and duration of this review > for this particular RFC the reputation is already been soured for both > parts of the Node.js community and ECMA TC39 members. I've become fairly > used to 6 months of silence, followed by a brief comment period resetting > the 6 month time for comments that is both derisive and often demanding > re-explanation of how the browsers and the current state of web works. This > is not a good look and it does feel that the IETF largely does already > ignore other ecosystems, so it is understandable that they reciprocate in > kind even if that is undesirable for all parties involved. Just one point that looks like a potential very deep and decisive misunderstanding. There is absolutely no "6 month comment period" in the IETF. In my 25 years of being involved in the IETF, this is the first time I have head of a "6 month comment period". The longest comment period that I can remember having heard of up to now is 6 weeks (4 weeks IETF-wide non-WG last call + two weeks extra over Christmas). If you could tell us how/where you learned about such a (nonexisting!) concept, that might help us find and fix a problem. My (wild?) guess is that the six months might come from the sentence "Internet-Drafts are draft documents valid for a maximum of six months" which is included in every Internet draft. But please note the word "maximum". These six months are there to make sure people don't feel satisfied at leaving something as an Internet Draft forever; the only choices are 1) abandon, 2) resubmit an update, and 3) move on to RFC. But it's perfectly fine (indeed, highly desirable and recommended) to move at a faster pace. It's not unseen that somebody submits a draft and then a few minutes later submits a new version just because they have found another typo. For an extreme example of "submit early and often", please see https://datatracker.ietf.org/doc/html/draft-hixie-thewebsocketprotocol-76 (76 drafts over 17 months). So in order to push your work forward, I recommend you wait until the discussion has died down, incorporate the necessary changes, and resubmit a draft. Then you ask people to check the changes, and repeat as necessary. Once things have cooled down, you contact the responsible WG chair (or AD) and tell them that you think the document may be ready for the next step such as WG last call (which may include more comments and more drafts). Finally, some comments closer to the subject matter. I think John Levine is correct that the wording change I proposed may be misinterpreted as a material change. John Klensin showed how that can be dealt with. With regards to claims that the JavaScript community didn't follow the first RFC to the letter: I think everybody who has been doing standards work, and that should include most people in the IETF, know an example or two (or many more) where well-intended specification language didn't work out in practice, and the language (and not the practice) were fixed. The formal explanation is "dynamic interaction of diverse players in a complex ecosystem" or some such. Stuff happens. There is no protocol police, but there's paper (or electrons) to document things and bring everybody on the same page. Regards,   Martin. >> While I suggest that cleaning up the > language to make it more precise from a technical standpoint, I > don't feel very strongly about that, especially if you and > others are convinced that no one outside the current javascript > implementation community will ever read it. But I do think it > is important to remove the BCP 14 normative language and to > improve the quality of explanation of changes, even if to more > clearly say "we said to do X, the consensus of common practice > has chosen Y instead, so, because this is an Informational and > descriptive document, we are now specifying Y without expressing > any opinion of which choice would be better in some different > reality." > > I think such is possible, but given the lack of communication after such > changes we have done in the past I do not see it as a fruitful exercise > except to gain a new 6 month comment period followed by silence and a last > minute issues on what I personally regard somewhat as repetitive nature > that mostly are resolved by non-significant changes and or relying on > explanation of how other standards have evolved outside of the IETF > process, likely in part due to this friction. > >> If "the javascript crowd" is opposed to our doing that much, > then this ought to be a document that they publish in some > appropriate place where IETF consensus is not needed, and that > the IETF, if appropriate, should just reference it. > > This is the kind of derision I was referencing earlier. > > On Wed, May 19, 2021 at 5:38 PM Myles Borins 40github.com@dmarc.ietf.org> wrote: > >> To speak candidly... I don't love the us vs. them language being thrown >> around here. >> >> There are many people who do work with and on JavaScript that participate >> within IETF, and drawing a distinction between the two parties seems >> unnecessarily decisive. >> >> Myself and various others have been trying, as good citziens of the >> internet, to document a web reality and update the current out of date RFC >> in order to make the internet better. I outlined examples above of certain >> platforms waiting on a clear signal from IETF / IANA before supporting the >> .mjs extension with the appropriate mimetype... The lack of this support >> creates developer friction and confusion. >> >> It is extremely demotivating to be trying to work through a process for >> many years and to consistently have folks jump in to give minor feedback >> that continues to derail progress and burn out the people trying in good >> faith to work with the IETF and hopefully become more regular contributors. >> >> An expression comes to mind that "perfect is the enemy of good". This is >> not to say that we should lower the quality bar here, but the current RFC >> is inaccurate to web reality in ways this new rfc attempts to fix. >> >> We first attempted to amend the existing rfc, but were requested to make a >> new rfc due to the level of changes. We are now finally what feels like >> close to done and are being challenged on both parts of the RFC we never >> wrote as well as the fundamental existence of the document to begin with. >> >> I understand that folks come and go and that there are many steps along >> the way... but the way this overall process has played out is extremely >> demotivating and disappointing. >> >> I will definitely keep trying to push this forward, put I do wonder if we >> could table some of the feedback we are receiving right now to come in an >> update to the proposed text... As I genuinely fear that this will never get >> published at the rate things have gone for over 3 years now >> >> On Wed, May 19, 2021, 6:20 PM John C Klensin wrote: >> >>> >>> >>> --On Wednesday, May 19, 2021 15:10 -0400 John R Levine >>> wrote: >>> >>>>> While I mostly agree -- Martin is right, but it is not clear >>>>> whether making this correct would cause more harm by creating >>>>> confusion than it would be worth -- there is a third (and more >>>>> drastic) way to look at this. Content-sniffing and >>>>> heuristics, rather than properly marking up text and strict >>>>> observance of media types, ultimately just lead to other >>>>> problems down the line. ... >>>> >>>> We went through all these arguments a couple of months ago and >>>> the Javscript crowd made it crystal clear that the current >>>> awful behavior is built into vast amounts of software, >>>> starting with all of the web browsers on your phone and your >>>> computers, and it's not going to change. >>> >>> Understood and no disagreement. Nor am I suggesting that the >>> IETF should say "change it anyway" or anything equally unlikely >>> to result in changed behavior. >>> >>>> While I am no happier than you are that we got to this point, >>>> I don't think that a pissing contest would do anyone any good. >>>> I suppose we could add a note saying something like the media >>>> sniffing is a concession to widespread existing practice and >>>> isn't intended to be a precedent for any new media types. >>> >>> Nor was I suggesting a pissing contest. I am suggesting that >>> whether to publish a document in the IETF Stream is an IETF >>> decision, made at the IETF's discretion, and that the IESG has >>> told us that any such documents must represent IETF consensus. >>> >>> I am also suggesting that if we, the IETF, say that someone MUST >>> do something in a particular way, and do so with the full >>> knowledge that the community to whom that is being addressed has >>> ignored us before and may ignore us again, it is bad for the >>> IETF's reputation... and just silly. >>> >>> So I am not suggesting any changes in what the document >>> describes and recommends. While I suggest that cleaning up the >>> language to make it more precise from a technical standpoint, I >>> don't feel very strongly about that, especially if you and >>> others are convinced that no one outside the current javascript >>> implementation community will ever read it. But I do think it >>> is important to remove the BCP 14 normative language and to >>> improve the quality of explanation of changes, even if to more >>> clearly say "we said to do X, the consensus of common practice >>> has chosen Y instead, so, because this is an Informational and >>> descriptive document, we are now specifying Y without expressing >>> any opinion of which choice would be better in some different >>> reality." >>> >>> If "the javascript crowd" is opposed to our doing that much, >>> then this ought to be a document that they publish in some >>> appropriate place where IETF consensus is not needed, and that >>> the IETF, if appropriate, should just reference it. >>> >>> best, >>> john From nobody Wed May 19 17:33:02 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74423A2593; Wed, 19 May 2021 17:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRC1P8oQEjI5; Wed, 19 May 2021 17:32:56 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389BC3A2595; Wed, 19 May 2021 17:32:56 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ljWcQ-000KyC-1O; Wed, 19 May 2021 20:32:54 -0400 Date: Wed, 19 May 2021 20:32:48 -0400 From: John C Klensin To: Bradley Farias , Myles Borins cc: media-types@ietf.org, Dispatch WG , John R Levine Message-ID: <220EFA4A81D94CBDBB61BBE5@PSB> In-Reply-To: References: <20210519164447.ECC5B82C752@ary.qy> <2E638F219F84A08A499732E5@PSB> 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 Archived-At: Subject: Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 00:33:01 -0000 Bradley, Myles, No derision was intended. I could explain further what I was saying, but I don't think it would be helpful. Nor do I see this as an "us versus them" situation, only as one in which we try to figure out what each organizational structure does best, what we are really trying to accomplish, and what the best modes and styles of presentation are to accomplish that. That said, I do not want to contribute further to a discussion in which I was attempting to be constructive but obviously intervened in the wrong way at the wrong time. So I apologize and am dropping back out. john --On Wednesday, May 19, 2021 18:06 -0500 Bradley Farias wrote: > I also would like to speak somewhat directly. > >> I am also suggesting that if we, the IETF, say that someone >> MUST > do something in a particular way, and do so with the full > knowledge that the community to whom that is being addressed > has ignored us before and may ignore us again, it is bad for > the IETF's reputation... and just silly. > > I would state that given the sheer denialism and duration of > this review for this particular RFC the reputation is already > been soured for both parts of the Node.js community and ECMA > TC39 members. I've become fairly used to 6 months of silence, > followed by a brief comment period resetting the 6 month time > for comments that is both derisive and often demanding > re-explanation of how the browsers and the current state of > web works. This is not a good look and it does feel that the > IETF largely does already ignore other ecosystems, so it is > understandable that they reciprocate in kind even if that is > undesirable for all parties involved. > >> While I suggest that cleaning up the > language to make it more precise from a technical standpoint, I > don't feel very strongly about that, especially if you and > others are convinced that no one outside the current javascript > implementation community will ever read it. But I do think it > is important to remove the BCP 14 normative language and to > improve the quality of explanation of changes, even if to more > clearly say "we said to do X, the consensus of common practice > has chosen Y instead, so, because this is an Informational and > descriptive document, we are now specifying Y without > expressing any opinion of which choice would be better in some > different reality." > > I think such is possible, but given the lack of communication > after such changes we have done in the past I do not see it as > a fruitful exercise except to gain a new 6 month comment > period followed by silence and a last minute issues on what I > personally regard somewhat as repetitive nature that mostly > are resolved by non-significant changes and or relying on > explanation of how other standards have evolved outside of the > IETF process, likely in part due to this friction. > >> If "the javascript crowd" is opposed to our doing that much, > then this ought to be a document that they publish in some > appropriate place where IETF consensus is not needed, and that > the IETF, if appropriate, should just reference it. > > This is the kind of derision I was referencing earlier. > > On Wed, May 19, 2021 at 5:38 PM Myles Borins 40github.com@dmarc.ietf.org> wrote: > >> To speak candidly... I don't love the us vs. them language >> being thrown around here. >> >> There are many people who do work with and on JavaScript that >> participate within IETF, and drawing a distinction between >> the two parties seems unnecessarily decisive. >> >> Myself and various others have been trying, as good citziens >> of the internet, to document a web reality and update the >> current out of date RFC in order to make the internet better. >> I outlined examples above of certain platforms waiting on a >> clear signal from IETF / IANA before supporting the .mjs >> extension with the appropriate mimetype... The lack of this >> support creates developer friction and confusion. >> >> It is extremely demotivating to be trying to work through a >> process for many years and to consistently have folks jump in >> to give minor feedback that continues to derail progress and >> burn out the people trying in good faith to work with the >> IETF and hopefully become more regular contributors. >> >> An expression comes to mind that "perfect is the enemy of >> good". This is not to say that we should lower the quality >> bar here, but the current RFC is inaccurate to web reality in >> ways this new rfc attempts to fix. >> >> We first attempted to amend the existing rfc, but were >> requested to make a new rfc due to the level of changes. We >> are now finally what feels like close to done and are being >> challenged on both parts of the RFC we never wrote as well as >> the fundamental existence of the document to begin with. >> >> I understand that folks come and go and that there are many >> steps along the way... but the way this overall process has >> played out is extremely demotivating and disappointing. >> >> I will definitely keep trying to push this forward, put I do >> wonder if we could table some of the feedback we are >> receiving right now to come in an update to the proposed >> text... As I genuinely fear that this will never get >> published at the rate things have gone for over 3 years now >> >> On Wed, May 19, 2021, 6:20 PM John C Klensin >> wrote: >> >>> >>> >>> --On Wednesday, May 19, 2021 15:10 -0400 John R Levine >>> wrote: >>> >>> >> While I mostly agree -- Martin is right, but it is not >>> >> clear whether making this correct would cause more harm >>> >> by creating confusion than it would be worth -- there is >>> >> a third (and more drastic) way to look at this. >>> >> Content-sniffing and heuristics, rather than properly >>> >> marking up text and strict observance of media types, >>> >> ultimately just lead to other problems down the line. ... >>> > >>> > We went through all these arguments a couple of months ago >>> > and the Javscript crowd made it crystal clear that the >>> > current awful behavior is built into vast amounts of >>> > software, starting with all of the web browsers on your >>> > phone and your computers, and it's not going to change. >>> >>> Understood and no disagreement. Nor am I suggesting that the >>> IETF should say "change it anyway" or anything equally >>> unlikely to result in changed behavior. >>> >>> > While I am no happier than you are that we got to this >>> > point, I don't think that a pissing contest would do >>> > anyone any good. I suppose we could add a note saying >>> > something like the media sniffing is a concession to >>> > widespread existing practice and isn't intended to be a >>> > precedent for any new media types. >>> >>> Nor was I suggesting a pissing contest. I am suggesting that >>> whether to publish a document in the IETF Stream is an IETF >>> decision, made at the IETF's discretion, and that the IESG >>> has told us that any such documents must represent IETF >>> consensus. >>> >>> I am also suggesting that if we, the IETF, say that someone >>> MUST do something in a particular way, and do so with the >>> full knowledge that the community to whom that is being >>> addressed has ignored us before and may ignore us again, it >>> is bad for the IETF's reputation... and just silly. >>> >>> So I am not suggesting any changes in what the document >>> describes and recommends. While I suggest that cleaning up >>> the language to make it more precise from a technical >>> standpoint, I don't feel very strongly about that, >>> especially if you and others are convinced that no one >>> outside the current javascript implementation community will >>> ever read it. But I do think it is important to remove the >>> BCP 14 normative language and to improve the quality of >>> explanation of changes, even if to more clearly say "we said >>> to do X, the consensus of common practice has chosen Y >>> instead, so, because this is an Informational and >>> descriptive document, we are now specifying Y without >>> expressing any opinion of which choice would be better in >>> some different reality." >>> >>> If "the javascript crowd" is opposed to our doing that much, >>> then this ought to be a document that they publish in some >>> appropriate place where IETF consensus is not needed, and >>> that the IETF, if appropriate, should just reference it. >>> >>> best, >>> john >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From kydavis@cisco.com Mon May 24 06:02:58 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CE93A2791 for ; Mon, 24 May 2021 06:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=N3IbW/27; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Y+6U3PL8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVniJJcqBnDj for ; Mon, 24 May 2021 06:02:54 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56773A2790 for ; Mon, 24 May 2021 06:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14642; q=dns/txt; s=iport; t=1621861373; x=1623070973; h=from:to:cc:subject:date:message-id:mime-version; bh=tHhIu4hujjJaQ2tpc1P35htT3y6X7uWAgz8YtufE94k=; b=N3IbW/27tDfEiypsWS7bGHB8JCI1KU7W1jRxYRo3ilW1xgEA9Fffi/nl xJGELJ3xBW27xOB9a52DZj04gveCIgzs9dZviq696BgPUQCxtCgcm/CwU oHH7BmjfLQDrwSZeKDRU2Q9bkmyn8ra34+U3maOhcEakfXWO3KmwCVjJa Q=; X-Files: smime.p7s : 3983 X-IPAS-Result: =?us-ascii?q?A0DjAgANo6tgl4oNJK1QCoEJgVeBIzAjLn4sLjYxC4gFA?= =?us-ascii?q?4U5iGuIC4x4hH+BLoElA1QEBwEBAQoDAQE1CgIEAQGEUAKBfgIlNgcOAgQBA?= =?us-ascii?q?QEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoAQyGRxYbEwEBNwERA?= =?us-ascii?q?VAwJgEEDg0GBgcHgk8BgX5XAx8QAQ6cGAGBOgKKH3iBNIEBggcBAQYEBIE4A?= =?us-ascii?q?oN6GIIMBwMGgTqBU4EognFTSIJMGIQgHIFJRIEVQ4Iwg04BAQOBMC8rgyCCL?= =?us-ascii?q?YFYgQknJgRRAmYLJyw5AhMUBUmRHox+nTAKgxeFGYJ8gXWTahGDW6FxkBqFI?= =?us-ascii?q?4IXh1KCJ5MUhHUCBAIEBQIOAQEGgVsBMYFbcBWDJFAXAg6OKw0Jg06FFIVKc?= =?us-ascii?q?zgCBgoBAQMJfIdhAYEQAQE?= IronPort-PHdr: A9a23:C9n+fRcgvWgt9YOBcpWwyNFUlGM/qYqcDmcuAtIPir9SfOKk5Zuxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoLfP2YWo9B ssRHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA IronPort-Data: A9a23:+usZK6lXPdixE0NdQSQnQ6ro5gxBJkRdPkR7XQ2eYbSJt16W5kVWj iJDADrXfqbVPH21IIo1b5D1rB1Y6NKQjINT/DAc7nRsSn8MsZXebTjyBhisYXqZI5XNQE494 chHN4WacMxtFXLWqkmha7bt9CJ2hP/QHLf2A7Sfayx4GwE7Rnx51E0+kbFhiNBmjYCyCQ/lV b8ezSH6EAfNN2lcaTNEsMpv0S9SgckemA/0n3Q1OKhG7FaOziNKVswVdKzoJnGnSdkNFLbqS rfNne/nr0rUrkwnYj+HfhkXUaGrrpr6Z1XmZq9+AvD66vR6S69bPp8TbJLwU28P49myt403m I8lWaCYE19zZ/WRwrhFCnG0LgknVUF40O6fSZSAmZT7I33uKxMAFN03USnalaVBkgpGKTkmG c4wcVjhXTjf7w6C+49Xf8E37igVwGYHC6tE0p1o5Wmx4f/L2vkvSY2SjTNT9G9YasyjgZ8ya uJBAQeDYigsbDVJM3hKUb0SuN2ToWnjKhBzjV6ruq0otj27IAxZiNABMfLcftiMAM5ShEvd+ yTN/n/yBVcRM9n3JTitqy33wLSR23qgHttJRNVU9dYy6LGX7m8CBBQIVECTqviigUn4UNVaQ 6AR0nR/9flvqRHzErERWTWqjWCboUcnZeMKHvY37AiUxZfJ/g+WUz1sojlpMYx665BeqSYR/ lWTlt/BHTFmurqZWDSc8d+8oTKpISEJJm8qZCIYQ00C+daLnW0ophvLStAmG6mvg5ioXzrx2 DuN6iM5gt3/kPLnyY299H+a2h2AgqLyaR4pvyj8e26b8QRmMdvNi5OT1bTL0RpRBN/HFADc7 CZcxJX2APMmVsrVxXbdKAkZNPT4uajZbWG0bUtHQsFJyti7x5K0kWm8ChlXIENkNK7okhe2P ReL42u9CHKvVUZGgId+Z4a3Ts8t16WlSLwJt8w4jPITOfCdlyfeoUmCgHJ8OUi2ziDAdolkZ P+mnT6EVypyNEie5GPeqx0hPVoXKsYWmzq7qXfTkU3P7FZiTCT9pUotaQHXNblpsMtoXi2Ir YY32zS2J+V3Cb2iPXa/HX87BlERJn9zPoHtt8FSbYa+zvlOST1wW66IqY7Nj7dNwvUO/s+Vr y7VZ6Ot4Aem7ZExAV7SOi4LhXKGdcsXkE/XygR8bA70hCB7OdjHAWV2X8JfQITLPddLlZZcJ 8Tpse3ZX6geItgb01zxtaXAkbE= IronPort-HdrOrdr: A9a23:+WJPxaC0nxFWb1jlHeiPsceALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UsssHFJo6HmBEDyewKhyXcV2/hcAV7GZmnbUQSTXfpfBOfZsljd8k7Fh6FgPM VbAtJD4bTLZDAQ56uXkWrIcerIq+P3lpxA8N2ut0uFOjsaEp2IgT0JbjqzIwlTfk1rFJA5HJ 2T6o5svDy7Y0kaacy9Gz0sQ/XDj8ejruOpXTc2QzocrCWehzKh77D3VzKC2A0Fbj9JybA+tU DYjg3C4Lm5uf3T8G6c64aT1eUXpDLS8KoAOCW+sLlRFtwqsHftWG1VYczAgNnympDp1L9lqq iLn/5qBbUN15qYRBDKnfKq4Xi47N7rgEWSkmNxRhDY0JTErXsBert8rJMcfR3D50U6utZglK pNwmKCrpJSSQjNhSLn+rHzJlpXf2eP0DMfeNQo/jRiuEolGctsRIckjQlo+Vc7bVTHAaUcYa RT5e3nlYRrmGKhHgfkVzNUsa+Rt1wIb2K7q2Y5y7yo7wQ= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,319,1613433600"; d="p7s'?scan'208,217";a="690955504" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2021 13:01:53 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 14OD1rPU005182 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 24 May 2021 13:01:53 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 24 May 2021 08:01:53 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 24 May 2021 08:01:53 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 24 May 2021 08:01:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NStpEvuzVxyZSfqrRYLpTyK/pNry4j0fbPv0QW26plAygp9zMi/oBt6AEZ3GgUSAaNTCvBVoK9qr4yY/C0vpe5mXJ8pAybd151IXspjy5pOmQPeNAN9r3Fy3O3oqyotges7SfdTUYPKebkqc4DlfoeUiPTcxyOQJsl8c7eYPY1oNBeyMNJVGQVm0xMbXq7bNWb2IM1Vt0Wy0JbwbflED8+qeCMotwTccSbSkTLUt4OAOGichnW1ItFmw+ucacHFv0Z+TVd4EMhXqARDwHtdyg4bzXu/czWSHqTHzGnu3rRSZvianXCjuSVp7jpJU+qnBnRyaqWPJz0Bz4cMqSrV5aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=edNh67geSgA5o1vOyzfIifQB9Gt46Th6iy8XmKpuFBA=; b=ZxBoyQmggDArDbbxwignAmVK1DwGi73P94FlARLsy6cpcHNUmyxDNwhx+ih9t6RFDmqtfsIiORQrD0rqA8bKCr+C2SZ+i3kTSKSn0IzQ7J9i3ayyr57qBjdZp77aX6Xf7jKGwr4MsGBakIZTo3LZ7I+o4I+mg0IFW/2QzTax9C35W5y7El7M30CWjt6mnzv22cwCVAi2u8KFhXt+bMk01uhRwKaiB6YjzQAZvqUSSZLUluG/FkbmImKyV50zueF+gqBo4gz7utBTUKuu/vLo6/egn8wYrWpbLH6rNmoZwEJq7YpmbjBHQUMwAZgieInjSmBEgag+oYmIwqALE9Qh5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=edNh67geSgA5o1vOyzfIifQB9Gt46Th6iy8XmKpuFBA=; b=Y+6U3PL8yv3smu7NdMrU0YSQ9ap0DFiBOhygvvUddrNhaJXXp6nKdJKbS4e41UMf/CGgWEsdNphAchg0UNaiDXTo35Piw2bD/FzEUwivFCHSYlldPb8KCff69/8gHfVXqUTQEno82byUursMlhSZNzlzCjnJIR93wm8xfxyrpvc= Received: from MN2PR11MB4175.namprd11.prod.outlook.com (2603:10b6:208:153::17) by BL0PR11MB3026.namprd11.prod.outlook.com (2603:10b6:208:75::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.26; Mon, 24 May 2021 13:01:51 +0000 Received: from MN2PR11MB4175.namprd11.prod.outlook.com ([fe80::c4ba:441a:a8c9:f4d]) by MN2PR11MB4175.namprd11.prod.outlook.com ([fe80::c4ba:441a:a8c9:f4d%4]) with mapi id 15.20.4150.027; Mon, 24 May 2021 13:01:51 +0000 From: "Kyzer Davis (kydavis)" To: "dispatch@ietf.org" CC: Brad Peabody Thread-Topic: An update on the status of the new UUID draft work Thread-Index: AddQnIxa4nLnfGj9SfW6chznJt1CbQ== Date: Mon, 24 May 2021 13:01:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa3a6780-81e2-48ac-c02f-08d91eb418e1 x-ms-traffictypediagnostic: BL0PR11MB3026: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uLVvXOkuhrR5CxQGpTB7RaKGRIuE8bq5QxfbHj5qS4I71d3zIKKyqC+/rH/40WsClrWwYREv6IXJf48n5YgT1m2PYbxWWzVK1nq0JnNi+tr4h8z3pJvi2tPYsci5/JODV3yxcHMTS0zqWmsWhXck4M7Tvowc275N9q9eUySSbPzhsu5qbjTVdw5p0b/PlHOZPk74W9RDyPpVu6TMfb98RpOMPzJ6Dd9RoJqVUTMZhUC1of5Fbl1ZpqdqqlDnKIB29VQUErSo/0PR3ofhl7Yd1Yvgg4GEoVQzQdrC3msL4v13tUQZMI4nkK3VDZXVh/+EEXjzffKOf/A+ME1CMEidr++zDrnIuKBgCK/fJtZgRl96YwgI+e56yeU+n7Dkaf8zrR7kD45HITelkAJCcxD9cfGIZmmQDHGrg6xuSuyx3x72qk2Kotyu/kdW9gYJ6RS6Jq8AaL3w9lueKUI6hJHdc8Wl9pOXMjvfLvPcKwx5GzCka9tVj7TEH+7Dr9EAxjUyGrODSKD5Zmwgs50vZNiP4bNSt7Z+kPcJy7NNZ4rBXjyCeR7z6MjwxQJZBmsKeadnNWyd5ATElpldTHUttHSEODTn20Vab5W9A28YRI/Ajrw3xg3MfkKCGteoXEXYp0ExVeA/aP+0siiGTb9u8x3KgIBIEG74FVWW2SaHn3qZ2wkEuVeIkoX1NHjwrCuwUokEr6RUpjIav6Q+k+XxDp5/MA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4175.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39860400002)(396003)(346002)(376002)(55016002)(52536014)(166002)(83380400001)(186003)(478600001)(316002)(4326008)(6916009)(2906002)(66446008)(86362001)(7696005)(71200400001)(5660300002)(76116006)(15650500001)(122000001)(33656002)(8676002)(6506007)(66946007)(99936003)(64756008)(9686003)(66476007)(8936002)(38100700002)(9326002)(26005)(66556008)(66616009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?sMLe7QJ7+9ECix28q67eFvLjWamduU5uJJZWNWWINj/S7eiLFAz7RjeW0YGI?= =?us-ascii?Q?qmu6AWhrdkGAqtm17HZbEZsPwiCbChGpLUOqKK6cIjPbOiucS9s6ZTuXvzUv?= =?us-ascii?Q?jn5pIEC6YO18vC6UsjU6mhsb+bP8/vk5+q4KcJn+jwMdehouQaS1qqRmwlRw?= =?us-ascii?Q?gAGG74h/5kLM1uByhLTi+OjcA1FQF5GbvJbtF8lH+8VOkh5Dsjm2MXNJHvtX?= =?us-ascii?Q?zqnaivxSa2HH64tZ9JxZ4sweMqG0kyCDGLMwpqUBB86+Jyz+O/HskMR5FGam?= =?us-ascii?Q?HXO278fO5/HkuoLc05DM03aIdQ14kD4J/WYASYKxJ1aHEb3Afp5tS2ud+4nm?= =?us-ascii?Q?EAuV5nCjM9LPy2rBVhk+WPG7tQcPb9VEx7Hcn7jOVyPoz3L/iL3OHL2IJWV0?= =?us-ascii?Q?Lhsidi/6/8yobnAnL5y+jUx6HwgSZTmfPamn8F7j888eNT2T7Mad6LCTekO8?= =?us-ascii?Q?kn8lv19YBzXZPD7S4WujcNUrXquH5uFAQJRBhyxxMQfT9PTPT6rMjvj7H8QR?= =?us-ascii?Q?hDV6Z1p5+P/2G7gwVAB8DNr47j9s4y0J9wZOp6kGqcVMlzeI+W5qESFt7c9C?= =?us-ascii?Q?srRqKHoESHbf61vbfZKSX4v7k8B5XE8w4DPYAGoV+AZzSKnzH9OFd/b3BS+S?= =?us-ascii?Q?BBDutxrfakEkNSYFvimhfGCM/qmXKg/Y4bMHtsg/Dgei3JwhPyoIM69F7/6q?= =?us-ascii?Q?cKXvkpI27X5vHIdi72tIvmZxU4+TzcFSQGMH49T+4I6graN9dYww5OMEJv9U?= =?us-ascii?Q?Hp1rBKnsioxqFNUvvvhFwRd0Hoi9g54aWCAGftBoH8yRDxWZOb0aY9vA9/5G?= =?us-ascii?Q?TonMDMoQSRu/5jA1ZMbUaZsy9xLeB29SfgXzAYRSvAVB0OLmTdbvVrNqcnWh?= =?us-ascii?Q?/EqdleVgyAO0mpyWSn6SAdzNKfF/MhP6Ip00VZJI28xWPgxhjOxUGOddpcFx?= =?us-ascii?Q?Guo7oIhWVSTL6QEA55TNBrWZmmE9t7YHc5Mhpx5XtuETtfl9P/w2l3bvtCaV?= =?us-ascii?Q?xMUvz3FskcAbRul5NfNjxNS7gUENbh39LwE1tYxWdPL3ERvUxsmMxqd7Rc2p?= =?us-ascii?Q?BFv3vuLJqwAiH5LH9+KtY65sQtw6ApMISrfpOgDYg5QanTNL1PVtRQM54V+2?= =?us-ascii?Q?8wuVfNFjdMjL21KjHAuPwoHl+fHHab7BBSxvZBeFzBnHVUwuqrRxrxCH3Wi4?= =?us-ascii?Q?vOgPiMKFYkE8zTvXn8BRUs1+lW0zUXDji1MmQUhvV0bKDzyLsI7NmP5AvLUv?= =?us-ascii?Q?5fo+U2yHuLBOo/YNwIgjLMTk/BZJNeH1clLPbHOFLBZtPGJjf4WzNuolEJV4?= =?us-ascii?Q?rqtxgV8MG21RXrmycIhLbTUc?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01D7507B.6E338A70" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4175.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa3a6780-81e2-48ac-c02f-08d91eb418e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 13:01:50.8161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7NX5YM7OJgXIUPUzmlvmX1ZZoA8JeiaXInbdKvyUOdLe2o2xN3wjjcigTy/BkakIQddauJdAXuDbJrsl2A1MzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3026 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: X-Mailman-Approved-At: Mon, 24 May 2021 08:35:44 -0700 Subject: [dispatch] An update on the status of the new UUID draft work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 13:06:10 -0000 ------=_NextPart_000_0023_01D7507B.6E338A70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0024_01D7507B.6E338A70" ------=_NextPart_001_0024_01D7507B.6E338A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Group, Apologies for the delay but Brad and I have just re-submitted the New UUID draft for review by the community. In the time between version 00 and 01 we have made a tremendous effort to bring this draft into a state which we believe is very close to being complete. If possible we would like to secure 5-10 minutes of the next meeting to discuss this new draft in an effort to get more eyes on it for review and additional feedback. A summary of those changes are below: - The current 01 draft is a complete rewrite from the ground up in almost every section after the introduction (https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-01) - The format, flow and verbiage used in the specification has been reworked to mirror the original RFC 4122 and current IETF standards. - This draft cuts some of the noise from the original 00 draft removing the topics of UUID length modification, alternate UUID text formats, and alternate UUID encoding techniques which are no longer related the scope of this specification. - A renewed focus on security has been applied to all sections of the draft. - Research into 16 different historical and current implementations of time-based universal identifiers was completed at the end of 2020 in attempt to identify trends which have directly influenced design decisions in this draft document (https://github.com/uuid6/uuid6-ietf-draft/tree/master/research) - The specification is now comprised of three new UUID versions based on the research and solutions to the problem we are trying to solve with this draft. Section 3. Summary of Changes discussed these three versions but in short: + UUIDv6 aims to be the easiest to implement for those already utilizing RFC 4122 UUIDv1 and keeps everything except the timestamp as-is. + UUIDv7 is a fresh take on a time-based UUID with Unix Epoch as the timestamp and other techniques for sub-second precision encoding, timestamp and other bit layouts + UUIDv8 offers a relaxed time-based UUID which caters to implementations that cannot utilize UUIDv1, UUIDv6, or UUIDv7 for one reason or another. This also future-proofs this specification by allowing time-based UUID formats from timestamp sources that are not yet defined. - Prototype implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 in various languages by many GitHub community members. (https://github.com/uuid6/prototypes) - We have also received and implemented lots of great feedback from the community on GitHub who are eager implement the final RFC into their products assuming we can get this to that point. (https://github.com/uuid6/uuid6-ietf-draft) Thanks, --- Kyzer Davis ------=_NextPart_001_0024_01D7507B.6E338A70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Group,

 

Apologies = for the delay but Brad and I have just re-submitted the New UUID draft = for review by the community.

In the = time between version 00 and 01 we have made a tremendous effort to bring = this draft into a state which we believe is very close to being = complete.

If possible we would like = to secure 5-10 minutes of the next meeting to discuss this new draft in = an effort to get more eyes on it for review and additional = feedback.

 

A summary of those changes are below:

- The current 01 draft is a complete rewrite from the = ground up in almost every section after the introduction (https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-= 01)

- The format, flow and = verbiage used in the specification has been reworked to mirror the = original RFC 4122 and current IETF standards.

- This draft cuts some of the noise from the original = 00 draft removing the topics of UUID length modification, alternate UUID = text formats, and alternate UUID encoding techniques which are no longer = related the scope of this specification.

- A renewed focus on security has been applied to all = sections of the draft.

- Research = into 16 different historical and current implementations of time-based = universal identifiers was completed at the end of 2020 in attempt to = identify trends which have directly influenced design decisions in this = draft document (h= ttps://github.com/uuid6/uuid6-ietf-draft/tree/master/research)

- The specification is now comprised of = three new UUID versions based on the research and solutions to the = problem we are trying to solve with this draft. Section 3. Summary of = Changes discussed these three versions but in short:

   + UUIDv6 aims to be the easiest to = implement for those already utilizing RFC 4122 UUIDv1 and keeps = everything except the timestamp as-is.

   + UUIDv7 is a fresh take on a time-based = UUID with Unix Epoch as the timestamp and other techniques for = sub-second precision encoding, timestamp and other bit = layouts

   + UUIDv8 offers = a relaxed time-based UUID which caters to implementations that cannot = utilize UUIDv1, UUIDv6, or UUIDv7 for one reason or another. This also = future-proofs this specification by allowing time-based UUID formats = from timestamp sources that are not yet defined.

- Prototype implementation have been completed for = UUIDv6, UUIDv7, and UUIDv8 in various languages by many GitHub community = members. (https://github.com/uuid6/pro= totypes)

- We have also received = and implemented lots of great feedback from the community on GitHub who = are eager implement the final RFC into their products assuming we can = get this to that point. (https://github.com/uui= d6/uuid6-ietf-draft)

 

Thanks,

 

---

Kyzer = Davis

 

------=_NextPart_001_0024_01D7507B.6E338A70-- ------=_NextPart_000_0023_01D7507B.6E338A70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMYTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBKQwggOMoAMCAQICCgGGGIp22rT3 EagwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTIxMDIxNjIxNDY0OVoXDTIzMDIxNjIxNTY0OVowgZgxHjAcBgNVBAMTFUt5emVy IERhdmlzIChreWRhdmlzKTEUMBIGA1UECxMLQ2lzY28gVXNlcnMxEjAQBgNVBAsTCUVtcGxveWVl czETMBEGCgmSJomT8ixkARkTA2NvbTEVMBMGCgmSJomT8ixkARkTBWNpc2NvMSAwHgYJKoZIhvcN AQkBDBFreWRhdmlzQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6/ 5Gu2F1zl471lMZAo3pCy2nJ2DIEJkbubB4CB6Rn10FDP8yQZyfp+7VdqEzzWwTQIzPRplRX52ISt 1BzvOXWD+9bWnuHWMzPVJLOD1t3YjDGQIicnulRi56C0FudibxGWcnrcj4j3ITcV78FgLV/7G8kH jFzAKwcNlP7RdLLaKhrIuwoUOUgBma4L6lHWXEby22XoxeqzThl8ZBEIejldbVp85cQ8pmtOnTFo LJqGJb4Dj/L37PhT5jkwlA9mppj+B6wDREhmUHhHnKDk6FQTV3efWG1NsnhL0Ds+E6qx+jIq7kY0 4svdfW8UxMrAEJmBA33B59jby1INdXcusg0CAwEAAaOCAVkwggFVMA4GA1UdDwEB/wQEAwIE8DAM BgNVHRMBAf8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNj by5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtp Y3ZzLmNpc2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6 BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNy bDAcBgNVHREEFTATgRFreWRhdmlzQGNpc2NvLmNvbTAdBgNVHQ4EFgQUeayqAHONjsNJdxrjl0a+ 9CJGCyIwHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEB ADjBrCsz5BFqwpzMEvoKaJfACFyodCYlWXN8SkaDhVn+dXvLiP7Ie9pHtCpgEQFxWGr2ARVQxfL2 OpHCv8RZ8+inD2lq28TeMbxdyChjst/1y9/0PT0tyLbm507PnN+OuGRsYspP+UYSEi0iPdzgMD+o 7Lf9RcmVQECde3AGe66Hyue7KZ6xscb/P0axJzafvux9FlpJlwH+mK/qm6Mo4vaVbYFXlWQPDabO 00COcVBZo/F0MArBx6N8tNFXC4FXuJZmBB8WnzW+9TiYet5kLHjcvSk6Bv985I3JwSBXun7YdxKy ts28WRUgXXsfNOG4Wa477966uvAo2wZ6WUDgy+MxggLwMIIC7AIBATA6MCwxDjAMBgNVBAoTBUNp c2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYYinbatPcRqDAJBgUrDgMCGgUAoIIB izAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA1MjQxMzAxNDla MCMGCSqGSIb3DQEJBDEWBBSWVW57jNzeSgmW1gyl+FsCsNJC3DBJBgkrBgEEAYI3EAQxPDA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYYinbatPcRqDBL BgsqhkiG9w0BCRACCzE8oDowLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBAgoBhhiKdtq09xGoMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBACD0srGjOdrCH2C0bqdN6KhKhvbox0q2u/XfDbO5mufexs6VrYzTOnK+ z/OSAxfKEWByonCTsnykHQqkutLrXj40cH/8U5Z4ZVoYw5oQZV5qAfU+iX7u140hgnmSxyQhHz7u RGBnKNDUhC+s2OlzUcSAbGhPR3/6czqoHMC9YE95KIl/bCodYVHjCma+/USNaAcagXpQ3dQUC7vF t+Sk/6AIvs9VK7lbEV5LGf52Cn4KykuUdRFlCJUYsu7Lq57ZkvNx/MFYbday1AO2UUMwG3BF58TO AzlNxCmQybk674AQlXOw73Ra9/kk3FuIenziidLZ7yMClObitUT9i3XJoO8AAAAAAAA= ------=_NextPart_000_0023_01D7507B.6E338A70-- From nobody Mon May 24 09:48:22 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042303A2EDA for ; Mon, 24 May 2021 09:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbEgETnJzMCy for ; Mon, 24 May 2021 09:48:16 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1573A2ED8 for ; Mon, 24 May 2021 09:48:15 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id j6so38893015lfr.11 for ; Mon, 24 May 2021 09:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VySlHjspZHVstrdWsaxUPEazkidMWPAkkqkWCEtv3qA=; b=R4wZZyl0UXsGzb8J6GcCpESJHOICIzkuO+jeq3VLbDyP7aSTZWkF22T6eq2Uxk6gIZ nxyxuh31wW9FmdL5KJ3kje66yw/dL7Cni6PCQPDivqliQeOJOdwjLJLAPTrVVpAmaEIW AWkCZ65YMMBsYLaYeEsKSOWQLiB3YISrxzANSN+b1Ps2jVXkWEluKhwZ6vPpiuvbwHZN KJvrBfs4QvjAE8WMQAFRQJzsbIPA/cH8kPAlhifqK7I2UQhXl30aiyZLFCx9rL3G0unv bLSsOrSazW5DY9Ydbb1SwoBB/oNAf5haUH6HBq1/9IgKQ4ux3oeVN5Zkg7CQkvh+ukv4 xLMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VySlHjspZHVstrdWsaxUPEazkidMWPAkkqkWCEtv3qA=; b=EroeR2vrxKE4YMc+vD99hbRuSfw97+hxlIf9rwd8hzDJl/LbOWeNMLxv9V9D8m2e3a YQiiyCJ704AT+ET8k2o+AGRjBosigTWrSFk8hD5zmk1cHkp9H6Ao3pvSfbH4Vx/SlwlC nbOg3+DEAlubyWsTutPeAqo10ycyCsWBdULr5+8dgPOnuTGlTs4bTNHk3m8RrAU112eS Iec5r5kx0uShsW7YXm3mGDKfNMKl34FMCaf28L/5CONTVWuSxUlWcvrmd06mtATyMyEq X9qgTe1c2XZ75iMkxD4TXBoER0zxcGNJMm0lNkY1gjDDgImifcuj+Di5m2L9VbJx1fRy va2w== X-Gm-Message-State: AOAM532E3X82T7V+y7VUIawxnAEFB4H2jLAn/LqQsHCOwRKKuUr1RLKw zfNqCl0Vce1gT7bCh8ww6j0QCMT8+DBuJyNq08S1ww== X-Google-Smtp-Source: ABdhPJzVst2RQNTfGACaFOYVTfpfEcq9SaaKSfzdDSwOyw9aKD4fh8cClgCl0X0AW4/QDAl6EiS2Bs80yMDUW9rcASg= X-Received: by 2002:a05:6512:33c4:: with SMTP id d4mr11714231lfg.536.1621874892605; Mon, 24 May 2021 09:48:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Mon, 24 May 2021 09:48:01 -0700 Message-ID: To: "Kyzer Davis (kydavis)" Cc: "dispatch@ietf.org" , Brad Peabody Content-Type: multipart/alternative; boundary="000000000000d825bf05c3162c7c" Archived-At: Subject: Re: [dispatch] An update on the status of the new UUID draft work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 16:48:21 -0000 --000000000000d825bf05c3162c7c Content-Type: text/plain; charset="UTF-8" Haven't been following this discussion so I may be covering well-traveled ground, but, wanted to say that over the last few years a few system designs have crossed my desk where such a thing would be useful. Should this be adopted as a work item, I'd probably argue for fairly massive simplification and removal of options; I'm hard-put to think of a case where someone using this is going to care about compatibility with existing sub-UUID structures, they just want a 128-bit key with the properties this offers. Not obvious that the rich 6/7/8 options really add that much value. Assume a millisecond clock, add an absurd number of sub-click sequence bits (you don't have to use them all) and you still have lots of randomness bits left. On Mon, May 24, 2021 at 8:35 AM Kyzer Davis (kydavis) wrote: > Hello Group, > > > > Apologies for the delay but Brad and I have just re-submitted the New UUID > draft for review by the community. > > In the time between version 00 and 01 we have made a tremendous effort to > bring this draft into a state which we believe is very close to being > complete. > > If possible we would like to secure 5-10 minutes of the next meeting to > discuss this new draft in an effort to get more eyes on it for review and > additional feedback. > > > > A summary of those changes are below: > > - The current 01 draft is a complete rewrite from the ground up in almost > every section after the introduction ( > https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-01) > > - The format, flow and verbiage used in the specification has been > reworked to mirror the original RFC 4122 and current IETF standards. > > - This draft cuts some of the noise from the original 00 draft removing > the topics of UUID length modification, alternate UUID text formats, and > alternate UUID encoding techniques which are no longer related the scope of > this specification. > > - A renewed focus on security has been applied to all sections of the > draft. > > - Research into 16 different historical and current implementations of > time-based universal identifiers was completed at the end of 2020 in > attempt to identify trends which have directly influenced design decisions > in this draft document ( > https://github.com/uuid6/uuid6-ietf-draft/tree/master/research) > > - The specification is now comprised of three new UUID versions based on > the research and solutions to the problem we are trying to solve with this > draft. Section 3. Summary of Changes discussed these three versions but in > short: > > + UUIDv6 aims to be the easiest to implement for those already > utilizing RFC 4122 UUIDv1 and keeps everything except the timestamp as-is. > > + UUIDv7 is a fresh take on a time-based UUID with Unix Epoch as the > timestamp and other techniques for sub-second precision encoding, timestamp > and other bit layouts > > + UUIDv8 offers a relaxed time-based UUID which caters to > implementations that cannot utilize UUIDv1, UUIDv6, or UUIDv7 for one > reason or another. This also future-proofs this specification by allowing > time-based UUID formats from timestamp sources that are not yet defined. > > - Prototype implementation have been completed for UUIDv6, UUIDv7, and > UUIDv8 in various languages by many GitHub community members. ( > https://github.com/uuid6/prototypes) > > - We have also received and implemented lots of great feedback from the > community on GitHub who are eager implement the final RFC into their > products assuming we can get this to that point. ( > https://github.com/uuid6/uuid6-ietf-draft) > > > > Thanks, > > > > --- > > Kyzer Davis > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000d825bf05c3162c7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hav= en't been following this discussion so I may be covering well-traveled = ground, but, wanted to say that over the last few years a few system design= s have crossed my desk where such a thing would be useful.

Should this be adopted as a work item, I= 'd probably argue for fairly massive simplification and removal=C2=A0of= options; I'm hard-put to think of a case where someone using=C2=A0this= is going to care about compatibility with existing sub-UUID structures, th= ey just want a 128-bit key with the properties this offers.=C2=A0 Not obvio= us that the rich 6/7/8 options really add that much value. Assume a millise= cond clock, add an absurd number of sub-click sequence bits (you don't = have to use them all) and you still have lots of randomness bits left.

On Mon, May 24, 2021 at 8:35 AM Kyzer Davis (kydavis) <kydavis=3D40cisco.com@dmarc.ietf.org> = wrote:

Hello Group,

=C2= =A0

Apologies for the delay but Brad and I= have just re-submitted the New UUID draft for review by the community.<= /u>

In the time between version 00 and 01 = we have made a tremendous effort to bring this draft into a state which we = believe is very close to being complete.

If possible we would like to secure 5-10 minutes of the next meeting = to discuss this new draft in an effort to get more eyes on it for review an= d additional feedback.

=C2= =A0

A summary of those changes are below:<= u>

- The current 01 draft is a complet= e rewrite from the ground up in almost every section after the introduction= (https://tools.ietf.org/html/draft-peabody-dispat= ch-new-uuid-format-01)

- The fo= rmat, flow and verbiage used in the specification has been reworked to mirr= or the original RFC 4122 and current IETF standards.

- This draft cuts some of the noise from the original 00 = draft removing the topics of UUID length modification, alternate UUID text = formats, and alternate UUID encoding techniques which are no longer related= the scope of this specification.

-= A renewed focus on security has been applied to all sections of the draft.=

- Research into 16 different histo= rical and current implementations of time-based universal identifiers was c= ompleted at the end of 2020 in attempt to identify trends which have direct= ly influenced design decisions in this draft document (ht= tps://github.com/uuid6/uuid6-ietf-draft/tree/master/research)=

- The specification is now comprised of thre= e new UUID versions based on the research and solutions to the problem we a= re trying to solve with this draft. Section 3. Summary of Changes discussed= these three versions but in short:

=C2=A0=C2=A0=C2=A0+ UUIDv6 aims to be the easiest to implement for those = already utilizing RFC 4122 UUIDv1 and keeps everything except the timestamp= as-is.

=C2=A0 =C2=A0+ UUIDv7 is a = fresh take on a time-based UUID with Unix Epoch as the timestamp and other = techniques for sub-second precision encoding, timestamp and other bit layou= ts

=C2=A0=C2=A0 + UUIDv8 offers a r= elaxed time-based UUID which caters to implementations that cannot utilize = UUIDv1, UUIDv6, or UUIDv7 for one reason or another. This also future-proof= s this specification by allowing time-based UUID formats from timestamp sou= rces that are not yet defined.

- Pr= ototype implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 i= n various languages by many GitHub community members. (https://github.com/uuid6/prot= otypes)

- We have also received= and implemented lots of great feedback from the community on GitHub who ar= e eager implement the final RFC into their products assuming we can get thi= s to that point. (https://github.com/uuid6/uuid6-ietf-draft)=

=C2=A0

T= hanks,

=C2=A0

---

Kyzer Davis

=C2=A0

_________________________________________= ______
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000d825bf05c3162c7c-- From nobody Tue May 25 01:18:03 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328C23A3066 for ; Mon, 24 May 2021 10:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jklnMPmp; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=zYs7D2Vc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXIfTQHoNFP1 for ; Mon, 24 May 2021 10:45:27 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9880C3A3061 for ; Mon, 24 May 2021 10:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22207; q=dns/txt; s=iport; t=1621878327; x=1623087927; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EoLFclcQVQTy9Bh0ULZXEjreTfYZ0Ov28ld2l8V/TGE=; b=jklnMPmpkcT2J1KI806tla6U2aAYFOo2p+5WlTqhECy1YlvmPQRyqk4U FnF1mX6eLnioUV2gAd/zoEvK66t8zx1wt4+xnfH9XSbrJlwGPGIRP4vx0 wFMn0aZ2TY9+NiAbXnO/4PbaQGRw9ZDmKTOIczxVOcdWL8e/VqUZIa1mT c=; X-Files: smime.p7s : 3983 X-IPAS-Result: =?us-ascii?q?A0DCAAA75atg/5ldJa1QChwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?gUFAQELAYEiMCMuB3csLjYxC4Q9g0gDhTmIbAOVAIR/gS4UgREDVAQHAQEBC?= =?us-ascii?q?gMBASoBCgoCBAEBhAxEAoF+AiU2Bw4CBAEBAQEDAgMBAQEBBQEBBQEBAQIBB?= =?us-ascii?q?gRxE4VoDYZEAQEBBAEBEBEdAQEsCwEPAgEIDgMEAQEoAwICAiULFAkIAQEED?= =?us-ascii?q?gUIBgYHB4JQgX5XAx8QAQ6cUAGBOgKJajV6gTKBAYIHAQEGBASBOAKDfhiCD?= =?us-ascii?q?AcDBoE6AYFSgSiCcVNIAQGCSoQRJxyBSUSBFUOBX1EvPoJhAQECAYEeEi8VF?= =?us-ascii?q?gmCYTaCLYFYbAYXGwwSFARRAlsLCxQTLDkCExQFSZEegxeVH5F4CoMXhRmCf?= =?us-ascii?q?IF1k2oRg1uhcZAahzqHUoInkxSEdQIEAgQFAg4BAQaBWwwogVlwFTuCaVAXA?= =?us-ascii?q?g6OHwwWg06FFIVKcwI2AgYBCQEBAwl8h2kBgRABAQ?= IronPort-PHdr: A9a23:ecyUPRUBoXUAxCksRtEHARxaQCPV8K0aAWYlg6HPw5pSf7S/4p3mP VDOo/5qiQyBUYba7qdCjOzb++DlVHcb6JmM+HYFbNRXVhADhMlX+m5oAMOMBUDhavK/aSs8E ZdeWU954ni/MFREXs35Yg6arni79zVHHBL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5L Q69qkPascxF6bY= IronPort-Data: A9a23:GlVXDKjv+ZfCcGDwmj3wysVWX161QBEKZh0ujC45NGQN5FlGYwR3n yJfBTDVa7vTPTzqO4IlK4qrthNR58eRi5Q2eLZe3WpoTndH79KaHrx1RW+ub3zLdcOTQhJp5 ptBMojKfJE4QybWrR30auC/piQgjq3WS+vwVeefNnAtSVA4QXwr2Uk5krY1jINj0YnmDV3S0 T+eT6MzHXf9s9IjGjlFu/nrRGpTgcnPVBMkUn0Wb6tB4wOAzCQeBc9FfqzuciGiSIAKEuK3S +zNwezkpW3w8kZ2ALtJsFpUnm7m41L2FVLT4paDc/H62nCunsGxu0oCHKJ0hX1/011lpPgsj oUX3XCMYV1xZPSUxb5BC0Mw/xxWZMWqxpeWeRBTjuTLp6H2WyOELyJGVRxe0SUwo46bMEkWn RAqAGllgiOr24pa9ImGptxE3azPGiVE0LQ34RmMxRmBZRovrAuqr6/ivbe01x9o7ixC8Gq3i 8cxMVJSgBr8jxJnfW8MWL4lhu2SlHDbfGJIr2PE/rMcyj2GpOBx+OCF3Nv9YNeGQ4BemVyV4 ziA9GXiCRZcP9uaodaH2ivz3amUwmWqA8RLSebQGv1C2DV/wkQQGREfS1qgifK4kUW5HdlYL iT4/wJx9fVjpRH1H4KVsxuQml6p4DcfWPtrMLc2sF6czJbO2l6lLz1RJtJGQJl83CMsfhQgz FaFt8vkDDZovKzTSHX13ruVtiu7JSMVBW4PeSFCShEKi/H/qps6nzrTQ8Z/Daexj8HkXzr3x li3QDMWnb4fi4sA0L+2uAqBiDO3rZ+PRQkwjunKYl+YAspCTNbNT+SVBZLzs56s8K7xooG9g UU5 IronPort-HdrOrdr: A9a23:00G9JqN0r6k2YcBcTx7155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMcs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QMpSWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAWMR4Z zxStEbTp1OAj3qDzmISFDWqnjdOX4Vmg/fIBmj8CDeSQiTfkNmNyKH7rgpKCcxonBQz+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fLFuI4O5l7Zvtn+90a1wah4S47pXXN WGzPusrMq+VGnqIEwxklMftOBEb05DVytuGHJyz/B9+wIm60yR4XFotvAiog== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,325,1613433600"; d="p7s'?scan'208,217";a="705995693" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2021 17:45:26 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 14OHjPKD026782 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 24 May 2021 17:45:25 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 24 May 2021 12:45:25 -0500 Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 24 May 2021 12:45:25 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 24 May 2021 12:45:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1k1TKH+Rf7kvhRc51+7tWHOl7m7+Us0s9rMTwTBpJgtgI00wwblcKrP9jSDk8ZSXArWDPTUmpPCxdwXUYhvTTR0wdlc3ME8KjNjZ1xY06hy7qk1SjwG5R351b/TE1YGVixbWkP7ThsN41XcrIdM3hJQOYVUlvTG5fKRxsprLclxKYdvDVqUtqPI+ZkXmscRqpMWJLQt0JiKLvuyzDHOGwwnXDzQGGdpQj/NqXhQudE6iUPW1mGVQh7DpkrKrUveGnddsFKGvxQJWfXvKVIq/thnQI5NZJZZ8pJvjkEgaGDGbWsucxhuAOpIwY3ue2981hezC9W+DA7s0dyOsLslaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=72rN0BDf5CtvWB4yz2jiGYbz19eJKlno6wlK9X+2SIs=; b=lbpy99GTDGvWQQTFs215EefO37OZmxj5iOf5CQJE6pI4eL3i69gK+rL8QvA1cYoDcRoUSJlz0BR9GFihzBACqVk0QZsFSuPuqxopTawAqfYhktT5LCVJ35p7hb0ZdGzxYW9/p9r7km83Q6wZpWgZxB+EXYcpWC3mRQDjPXo8Fy5ur4Fan2rjNOP9PzjHX5EHmB0dLcN61vDTFwz1zXNxEViVmGB36LvKEiWD/XWk7NUdVcvDW6xnBA9KJ91ghbO2NkuMOqKSojoEJTkhz5qcFZ+Z/31lAtLf7CzTYwITj/+Mbnzeuqk1BEjPAYIx+wwGo+4iPaV7fNzfDOqhr7ofBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=72rN0BDf5CtvWB4yz2jiGYbz19eJKlno6wlK9X+2SIs=; b=zYs7D2VcacsGf4WdRBdKLqtYRFf1d9lXMJuZXlejBy98znAGfgCfdkEeYC9CaEMHdh9Y4/prhC2OVWxIVZ0VLy7QAvrr1Bhbew2LoxQ6DLT4x9w2aiaeKdcgkFER8TXcCOVUJQbYYR201ExLaDgG6LRD5NFSh2vjA+GmEA3Mn4M= Received: from MN2PR11MB4175.namprd11.prod.outlook.com (2603:10b6:208:153::17) by MN2PR11MB4415.namprd11.prod.outlook.com (2603:10b6:208:192::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.23; Mon, 24 May 2021 17:45:23 +0000 Received: from MN2PR11MB4175.namprd11.prod.outlook.com ([fe80::c4ba:441a:a8c9:f4d]) by MN2PR11MB4175.namprd11.prod.outlook.com ([fe80::c4ba:441a:a8c9:f4d%4]) with mapi id 15.20.4150.027; Mon, 24 May 2021 17:45:23 +0000 From: "Kyzer Davis (kydavis)" To: Tim Bray CC: "dispatch@ietf.org" , Brad Peabody Thread-Topic: [dispatch] An update on the status of the new UUID draft work Thread-Index: AddQnIxa4nLnfGj9SfW6chznJt1CbQAIAJqAAAGQtTA= Date: Mon, 24 May 2021 17:45:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: textuality.com; dkim=none (message not signed) header.d=none;textuality.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf003d52-9ef3-4735-ba2c-08d91edbb542 x-ms-traffictypediagnostic: MN2PR11MB4415: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Tc+EjsD4TEWW0Yy6NtcWDy/OeMO7XJ67v+qKIn2qDssgwX2dwy4YxMCKjtRVEbAyc2+Z46qEnbIB9ieV3hboJNCQXzl6nsjrmYBrv8fh+3L0yikmlSqiqUyMIZ7RD66nU6eyiog6j/ylqQ3tZgg8F8Yxgw2SYAht/yIZHKxuYN5v+ACGSl9cJyqOa0LrynHZKXdGg81Mww24jmWfxVZc68VmCDannZzWvroVHNoyZSAOC/y9PS38XuyjT35prfg/M2peh6s0uPIMLziAu5CnVwOvcUV1k1uSAhdCt8pg3ZcKzV/yvPhGeL7YSgmwDNK23pWihs4/TcUYu6xwAe467nXKAAD1aP6UKsVj2yj2YsiQPXI9GYZibRsrwYUd8pacH4uLB1WVBZsLchfbx7qZdo8sjBpX7jiyCa0JWC8E2SX16CPnYoWxpLK+WBD9bvQuPexnmkSlfdZGEGVoE7+koxkki70mKZaMl46AZCAtUOlr1Xqa5iq/r7Zz7ihPJtJBOxAwA8ot8dT2roalu90DgvDI/NxiBjzhqL2Dmg3shYO6IsMDU3AvcOWzfbvuRo6IxfH3n/uuBjWEPW5xt5+wLFnCv1LD1KgswBWKKHgjihJ3N9pkOf0TgpupH6Eyki0nTqDBaVtOUMOs+RpA8salWlkk94e02uHa0SZ7C4nQUfE4xqMGHoCxmUG4lstUtQ9mpcAvT9DB2sA5jeD9VIPkcw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4175.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(366004)(376002)(39860400002)(396003)(26005)(186003)(478600001)(33656002)(4326008)(38100700002)(83380400001)(166002)(6916009)(53546011)(7696005)(6506007)(15650500001)(122000001)(9686003)(66556008)(966005)(76116006)(55016002)(8676002)(5660300002)(52536014)(316002)(2906002)(66946007)(54906003)(66446008)(8936002)(86362001)(66616009)(99936003)(66476007)(64756008)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Ykx4clFSckdlMEFKTjJlcEU4SUNvczVIQU9Eb2k5YXVCRXVuQzJOczg2T200?= =?utf-8?B?Rk5vNnU5bktZUEVqY3BxbmpBd05kNjNGQm12M0RWWVJLT2FwOW1zeU9ZNW95?= =?utf-8?B?cFg2R2hveEdNZ3RxVUp6RjM4cTBxbDU2UmJtK2Fsdm1kZ3BHem43QWxwaEVj?= =?utf-8?B?dlFVMXdwL1Z6T1NKUHlNKzAvcHZyLzBjQzhybHV5U0V0SmdzNWxpc21hV3VS?= =?utf-8?B?di9Ja3FBVDBVTmtQK0dyeUhFd3hVa1U5RXNjRUR5NUI5Njg1NTluL2FxK1pq?= =?utf-8?B?L2k1eTRRUDQ2cVk1bGNtQTdvU3FFSklVMGROUzk4VFg4Y3IySzBxNTFtSXc5?= =?utf-8?B?dEQ0NFkvZnpCbVJDcitvWjladG1lVFN5YURlZVFtcElvZUF3YWEyeXpib0o0?= =?utf-8?B?UmVlcWpWWFprQm9DK1JwVmVqb013LzBCOGFOZjQybmxjajVmM2Z6WldOUUFi?= =?utf-8?B?THlWS0NnbFVoeTJuV1Vzd3FaaTRBZmxuUjZaYTZyRkFJcUpldmxUY1ZMeE9r?= =?utf-8?B?OHhWbXNlVUg4Nnp2TDBhWVh0VWlKSGIvNHRZQWZLeVN5NzZuUEVGSlNxcnM1?= =?utf-8?B?clpqZUVoVXl2T1dIUUhwSVh6My94MjVvTkNlMVM0OEdWeWJDdmFtQThNWE1k?= =?utf-8?B?REJYQnYwY2llNm5pY0ZFTjZiNWtrZGx5N3NCcDJOZ2xQTld1N2lJY2JXK1ZZ?= =?utf-8?B?R1NsWTVIS1BweXRMRUJUczFvTzZqS0tsUktIMDRnZTNWZkppR01CVnFxUHBi?= =?utf-8?B?ZzhCUFB5a0x3YlczUS9PcURDT2dFeHQ0bUpteFMwVnY1VC9GdmphQ2NxN3lV?= =?utf-8?B?WkpXSk9oNXFaZ2dqMlVsTi9NY2lkRGY2SVpuelJBM3JzN081aEE0cHV3TU5H?= =?utf-8?B?YmpyOUdTTjZlTEtqWVI5Ry90eHMzRTBFSEFGOUg1SUgvTG1vdklXclpucVJ3?= =?utf-8?B?eUE1Q2xFY3FrcnJjaFc4WnI2NGMvQVJzUWJkSVJ3d1QxenB5RnJwdjd2bVhX?= =?utf-8?B?elV5ZVdIN2VJbTY4aTU0U3JabkU5WFpyOTBqNnphMzFzcXlZWTdveU9tY3pa?= =?utf-8?B?alVENkh2SW1CRjU3VktBZjlzV0tTZ2E5TSsvOXF6MkZiV1drN3NVcmdvbXV6?= =?utf-8?B?QzZYSVBjbTkwdkVwTFhFMDY5cDFwV0pqQm9mdXN6VmEzNDloU0dnWEJPR2JL?= =?utf-8?B?L2ROeHNpcGpiYTdsL3NwVy9IV0Qxc3FHdjlRclJ3VXlBZEVBcUEzdXpSWU9r?= =?utf-8?B?M3hOajkzMVp4UEQrR3I2Slc0MW53V0VpR05jUmN0Rms0MUJEMkhwZ091VjJD?= =?utf-8?B?aVJFVWl2YmFSc2RMNG9xN2o3cUt4UDdQMmdiaWlVa0lEU3pjS2d4ajRaUGV5?= =?utf-8?B?dVlaaXJJR2Vsd2k4ZGRtYmxzS2I2aGowSjNiYzBKNlJxMEd6Zkd6S3lEdW51?= =?utf-8?B?RkwzR2hBMGd4U0VUL1hSdlh4UThhcExxdW8wbVhXR3hZQVBTR20yMVVDWFo5?= =?utf-8?B?VnUzV2JrLzNMM09GaWlFU2haN2R1ZStGbVZoaS9HcjAxS3pwc2dVekhWbzUv?= =?utf-8?B?NWVrTEpQcDRNOW45d2haT25KMEc5Yk1ienY0NUZVd24zdDc4eW81Ujd2MGtK?= =?utf-8?B?S0ovb1owaC9YWjJaZWRTbDI0aFNESXF6MExNdG5ySzVjK3lVdWRLUG5jOWpm?= =?utf-8?B?amNmWHFlcGtEUWhYOGw5MzZ3Q09TZm5BWm9LWHJWK29SZkZLZVFBTXVuODBP?= =?utf-8?Q?tlz+2IsWZib6Km8lrDCSPiklZyYu8jX0YL2mQ5w?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E8_01D750A3.0AACFF40" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4175.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf003d52-9ef3-4735-ba2c-08d91edbb542 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 17:45:23.5087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vPMxfe44yVep1VhEHcGBsw9iKr+dfomXMPNn0vKSGS2xhW7b2kCtAFfZs+rqjMjU1WtuHuZZiQoW+HFNUrUULA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4415 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: X-Mailman-Approved-At: Tue, 25 May 2021 01:18:02 -0700 Subject: Re: [dispatch] An update on the status of the new UUID draft work X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 17:45:33 -0000 ------=_NextPart_000_00E8_01D750A3.0AACFF40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E9_01D750A3.0AACFF40" ------=_NextPart_001_00E9_01D750A3.0AACFF40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for the input Tim! =20 To be honest 6/7/8 are pretty similar under the hood. The main different = being the timestamp usage (Gregorian, Unix, and any other type). v7 of our specification describes exactly what you are detailing while = v6 was included with idea that systems with v1 only need to copy and = change a few lines of code to implement. Meanwhile v8 is an even more laid back approach which lays out some = example creation scenarios. Otherwise all 128 bits of v8 are of use for = the application implementation while still being a =E2=80=9CSpec based = UUID=E2=80=9D. =20 Lastly, there are some best practices included from our prototype = testing and research within each of these three versions. All three of these are all made up of the same core components: = Timestamp Data, Clock Sequence Counter, Random or application specific = Data (defined as the Node in the specification) along with static UUID = version/variants bits. =20 Thanks, =20 From: Tim Bray =20 Sent: Monday, May 24, 2021 12:48 PM To: Kyzer Davis (kydavis) Cc: dispatch@ietf.org; Brad Peabody Subject: Re: [dispatch] An update on the status of the new UUID draft = work =20 Haven't been following this discussion so I may be covering = well-traveled ground, but, wanted to say that over the last few years a = few system designs have crossed my desk where such a thing would be = useful. =20 Should this be adopted as a work item, I'd probably argue for fairly = massive simplification and removal of options; I'm hard-put to think of = a case where someone using this is going to care about compatibility = with existing sub-UUID structures, they just want a 128-bit key with the = properties this offers. Not obvious that the rich 6/7/8 options really = add that much value. Assume a millisecond clock, add an absurd number of = sub-click sequence bits (you don't have to use them all) and you still = have lots of randomness bits left. =20 On Mon, May 24, 2021 at 8:35 AM Kyzer Davis (kydavis) = > wrote: Hello Group, =20 Apologies for the delay but Brad and I have just re-submitted the New = UUID draft for review by the community. In the time between version 00 and 01 we have made a tremendous effort = to bring this draft into a state which we believe is very close to being = complete. If possible we would like to secure 5-10 minutes of the next meeting to = discuss this new draft in an effort to get more eyes on it for review = and additional feedback. =20 A summary of those changes are below: - The current 01 draft is a complete rewrite from the ground up in = almost every section after the introduction = (https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-01) - The format, flow and verbiage used in the specification has been = reworked to mirror the original RFC 4122 and current IETF standards. - This draft cuts some of the noise from the original 00 draft removing = the topics of UUID length modification, alternate UUID text formats, and = alternate UUID encoding techniques which are no longer related the scope = of this specification. - A renewed focus on security has been applied to all sections of the = draft. - Research into 16 different historical and current implementations of = time-based universal identifiers was completed at the end of 2020 in = attempt to identify trends which have directly influenced design = decisions in this draft document = (https://github.com/uuid6/uuid6-ietf-draft/tree/master/research) - The specification is now comprised of three new UUID versions based on = the research and solutions to the problem we are trying to solve with = this draft. Section 3. Summary of Changes discussed these three versions = but in short:=20 + UUIDv6 aims to be the easiest to implement for those already = utilizing RFC 4122 UUIDv1 and keeps everything except the timestamp = as-is. + UUIDv7 is a fresh take on a time-based UUID with Unix Epoch as the = timestamp and other techniques for sub-second precision encoding, = timestamp and other bit layouts + UUIDv8 offers a relaxed time-based UUID which caters to = implementations that cannot utilize UUIDv1, UUIDv6, or UUIDv7 for one = reason or another. This also future-proofs this specification by = allowing time-based UUID formats from timestamp sources that are not yet = defined. - Prototype implementation have been completed for UUIDv6, UUIDv7, and = UUIDv8 in various languages by many GitHub community members. = (https://github.com/uuid6/prototypes) - We have also received and implemented lots of great feedback from the = community on GitHub who are eager implement the final RFC into their = products assuming we can get this to that point. = (https://github.com/uuid6/uuid6-ietf-draft) =20 Thanks, =20 --- Kyzer Davis =20 _______________________________________________ dispatch mailing list dispatch@ietf.org =20 https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_001_00E9_01D750A3.0AACFF40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks for the input Tim!

 

To be honest = 6/7/8 are pretty similar under the hood. The main different being the = timestamp usage (Gregorian, Unix, and any other type).

v7 of our specification describes exactly what you are = detailing while v6 was included with idea that systems with v1 only need = to copy and change a few lines of code to implement.

Meanwhile v8 is an even more laid back approach which = lays out some example creation scenarios. Otherwise all 128 bits of v8 = are of use for the application implementation while still being a = =E2=80=9CSpec based UUID=E2=80=9D.

 

Lastly, = there are some best practices included from our prototype testing and = research within each of these three versions.

All three of these are all made up of the same core = components: Timestamp Data, Clock Sequence Counter, Random or = application specific Data (defined as the Node in the specification) = along with static UUID version/variants bits.

 

Thanks,

 

From: Tim Bray = <tbray@textuality.com>
Sent: Monday, May 24, 2021 12:48 = PM
To: Kyzer Davis (kydavis) = <kydavis@cisco.com>
Cc: dispatch@ietf.org; Brad Peabody = <brad@peabody.io>
Subject: Re: [dispatch] An update on = the status of the new UUID draft work

 

Haven't been = following this discussion so I may be covering well-traveled ground, = but, wanted to say that over the last few years a few system designs = have crossed my desk where such a thing would be = useful.

 

Should this be = adopted as a work item, I'd probably argue for fairly massive = simplification and removal of options; I'm hard-put to think of a = case where someone using this is going to care about compatibility = with existing sub-UUID structures, they just want a 128-bit key with the = properties this offers.  Not obvious that the rich 6/7/8 options = really add that much value. Assume a millisecond clock, add an absurd = number of sub-click sequence bits (you don't have to use them all) and = you still have lots of randomness bits = left.

 

On = Mon, May 24, 2021 at 8:35 AM Kyzer Davis (kydavis) <kydavis=3D40cisco.com@dmarc.ietf.org= > wrote:

Hello = Group,

 <= /o:p>

Apologies = for the delay but Brad and I have just re-submitted the New UUID draft = for review by the community.

In the time = between version 00 and 01 we have made a tremendous effort to bring this = draft into a state which we believe is very close to being = complete.

If possible = we would like to secure 5-10 minutes of the next meeting to discuss this = new draft in an effort to get more eyes on it for review and additional = feedback.

 <= /o:p>

A summary = of those changes are below:

- The = current 01 draft is a complete rewrite from the ground up in almost = every section after the introduction (https://tools.ietf.org/html/draft-peabody-dispatch-new-= uuid-format-01)

- The = format, flow and verbiage used in the specification has been reworked to = mirror the original RFC 4122 and current IETF = standards.

- This = draft cuts some of the noise from the original 00 draft removing the = topics of UUID length modification, alternate UUID text formats, and = alternate UUID encoding techniques which are no longer related the scope = of this specification.

- A renewed = focus on security has been applied to all sections of the = draft.

- Research = into 16 different historical and current implementations of time-based = universal identifiers was completed at the end of 2020 in attempt to = identify trends which have directly influenced design decisions in this = draft document (https://github.com/uuid6/uuid6-ietf-draft/tree/master/r= esearch)

- The = specification is now comprised of three new UUID versions based on the = research and solutions to the problem we are trying to solve with this = draft. Section 3. Summary of Changes discussed these three versions but = in short:

  =  + UUIDv6 aims to be the easiest to implement for those already = utilizing RFC 4122 UUIDv1 and keeps everything except the timestamp = as-is.

  =  + UUIDv7 is a fresh take on a time-based UUID with Unix Epoch as = the timestamp and other techniques for sub-second precision encoding, = timestamp and other bit layouts

  = + UUIDv8 offers a relaxed time-based UUID which caters to = implementations that cannot utilize UUIDv1, UUIDv6, or UUIDv7 for one = reason or another. This also future-proofs this specification by = allowing time-based UUID formats from timestamp sources that are not yet = defined.

- Prototype = implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 in = various languages by many GitHub community members. (https://github.com/uuid6/prototypes)

=

- We have = also received and implemented lots of great feedback from the community = on GitHub who are eager implement the final RFC into their products = assuming we can get this to that point. (https://github.com/uuid6/uuid6-ietf-draft)

 <= /o:p>

Thanks,=

 <= /o:p>

---

Kyzer = Davis

 <= /o:p>

_______________________________________________
disp= atch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

------=_NextPart_001_00E9_01D750A3.0AACFF40-- ------=_NextPart_000_00E8_01D750A3.0AACFF40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMYTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBKQwggOMoAMCAQICCgGGGIp22rT3 EagwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTIxMDIxNjIxNDY0OVoXDTIzMDIxNjIxNTY0OVowgZgxHjAcBgNVBAMTFUt5emVy IERhdmlzIChreWRhdmlzKTEUMBIGA1UECxMLQ2lzY28gVXNlcnMxEjAQBgNVBAsTCUVtcGxveWVl czETMBEGCgmSJomT8ixkARkTA2NvbTEVMBMGCgmSJomT8ixkARkTBWNpc2NvMSAwHgYJKoZIhvcN AQkBDBFreWRhdmlzQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6/ 5Gu2F1zl471lMZAo3pCy2nJ2DIEJkbubB4CB6Rn10FDP8yQZyfp+7VdqEzzWwTQIzPRplRX52ISt 1BzvOXWD+9bWnuHWMzPVJLOD1t3YjDGQIicnulRi56C0FudibxGWcnrcj4j3ITcV78FgLV/7G8kH jFzAKwcNlP7RdLLaKhrIuwoUOUgBma4L6lHWXEby22XoxeqzThl8ZBEIejldbVp85cQ8pmtOnTFo LJqGJb4Dj/L37PhT5jkwlA9mppj+B6wDREhmUHhHnKDk6FQTV3efWG1NsnhL0Ds+E6qx+jIq7kY0 4svdfW8UxMrAEJmBA33B59jby1INdXcusg0CAwEAAaOCAVkwggFVMA4GA1UdDwEB/wQEAwIE8DAM BgNVHRMBAf8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNj by5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtp Y3ZzLmNpc2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6 BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNy bDAcBgNVHREEFTATgRFreWRhdmlzQGNpc2NvLmNvbTAdBgNVHQ4EFgQUeayqAHONjsNJdxrjl0a+ 9CJGCyIwHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEB ADjBrCsz5BFqwpzMEvoKaJfACFyodCYlWXN8SkaDhVn+dXvLiP7Ie9pHtCpgEQFxWGr2ARVQxfL2 OpHCv8RZ8+inD2lq28TeMbxdyChjst/1y9/0PT0tyLbm507PnN+OuGRsYspP+UYSEi0iPdzgMD+o 7Lf9RcmVQECde3AGe66Hyue7KZ6xscb/P0axJzafvux9FlpJlwH+mK/qm6Mo4vaVbYFXlWQPDabO 00COcVBZo/F0MArBx6N8tNFXC4FXuJZmBB8WnzW+9TiYet5kLHjcvSk6Bv985I3JwSBXun7YdxKy ts28WRUgXXsfNOG4Wa477966uvAo2wZ6WUDgy+MxggLwMIIC7AIBATA6MCwxDjAMBgNVBAoTBUNp c2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYYinbatPcRqDAJBgUrDgMCGgUAoIIB izAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA1MjQxNzQ1MjFa MCMGCSqGSIb3DQEJBDEWBBTUu99FfyL51iUIZFkYtLGW+UrP/zBJBgkrBgEEAYI3EAQxPDA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYYinbatPcRqDBL BgsqhkiG9w0BCRACCzE8oDowLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBAgoBhhiKdtq09xGoMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBAEXZW2jN3Q4/Pa1ecpte4bu4re8sGZZkl15AL5vZnKb4MwvRE+6FrPha R2hBTdZ7Wc7DX+CnUqKpAPpIblFdbbIfUORduupWzyD7iCS4TQBM2B2z3j1jipAjjJZfXlqTCI4M ESNa2vVVuDe0+8s6/RBGw4BGgO9DjcXnotf1QrfLEbCOlQUgNnaYX4GShXfVUpZO6xrbs2YFWrmu GvhRfQTaqFpIHaMP7ziXwJhAnayX2ihWXixwEJvsflYtrkVbdTxzHYqr3Gx6StQLB2gm/F/Kj+cp bn5Ltb/K0TAktMHGoNrxVSBH4bLMNniT7s3phCfZsuMe9WZcIX/kosijv+EAAAAAAAA= ------=_NextPart_000_00E8_01D750A3.0AACFF40-- From nobody Tue May 25 12:31:48 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881593A1A88 for ; Tue, 25 May 2021 12:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jePJr4QMeCgQ for ; Tue, 25 May 2021 12:31:42 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C9E3A1A84 for ; Tue, 25 May 2021 12:31:41 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id p20so39688408ljj.8 for ; Tue, 25 May 2021 12:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zclZ3S5H/zeKxm0YJlzXpwGIiPjIsZoYTwc+K0QogVM=; b=WW/CbLtCF/w/AoIzOTy9Qh39l7vyg07C/22QzbHpeUamIjB1oMhWbNlk2F9eZQqFAP /ogCSmD4IxHM7qJWvk1f7ql84dwaZ5R2OAsPB5rO4i/9WcuPfSpJcYa3NZtaBKtjMp+w pYH2NFdzEyg24DWxClPVEqW3TG64dPtMW1qo869ueZ02EGRQSQJrEwEYHraRVrWnKVpE A+d2dFqPN23TUrY2Fi017D6e12dJehP1X9zAaZ8u6/Hu+u+es0l2cuNaMxJ7LJAGOkIm +JbUl44ics+9E4RZeBAgnNB0eQwMz0mafPTwEh2YyKkD3sdiHYGxEbil3Dq+KLL7qrrH +bxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zclZ3S5H/zeKxm0YJlzXpwGIiPjIsZoYTwc+K0QogVM=; b=neAgFbwGOT4EpRHdGUeZRLNOFyDr5c2+T3lIe2pWwPyNWI2rPpN11n1ElGPtKxCEdO ifmxYwZumemVani8eHCyRi7zYwIZ/BpmCRBTzg18zV1v4OvnpqxrNvldDhESoz+i3LTG 3KInLn69z7hlZnj65soS28AbPm05HljQ4AfWQu3IPf0aU61x4MUCDEHzWP1vOLYjo5au t50lBPduGKI2hUYflceFRQt36Hy0NCrf1b2+1i1D+U7ovBVBit/NDyXkVWaLjnkMdksI TRt4RdVnVIuOxw6l2NxgOvrTSdIzoDo3NqXVF4PhyGF2r64mYlXpvD8Q9SdwwTzyIO9y q+MQ== X-Gm-Message-State: AOAM5322+qoRCZw0Al9i+TOTSzZQjFnpeLc3ojyfd2s94bg+FYIGiBBq pJp76CjLw7YLkWCHX5io+7xu1tJcqfZByYL3iFCFXpUXPs0= X-Google-Smtp-Source: ABdhPJxmG8eJcY6pctnCCsD2XBjMWVZcAMeydN5RXpBSm5YWkyDT2xOQ2kyny1Q+oSpCF5LtnMiAUDGSaLrWtNliynM= X-Received: by 2002:a2e:9c08:: with SMTP id s8mr22536098lji.64.1621971098282; Tue, 25 May 2021 12:31:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: James Zern Date: Tue, 25 May 2021 12:31:27 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="00000000000026841105c32c939f" Archived-At: Subject: Re: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 19:31:47 -0000 --00000000000026841105c32c939f Content-Type: text/plain; charset="UTF-8" Just bumping the thread for visibility. Are there any opinions on the right processing path for the image/webp mime-type? On Wed, May 12, 2021 at 10:13 AM Murray S. Kucherawy wrote: > On Thu, May 6, 2021 at 6:45 PM James Zern 40google.com@dmarc.ietf.org> wrote: > >> On Thu, May 6, 2021 at 12:53 AM Murray S. Kucherawy >> wrote: >> >>> On Thu, Apr 29, 2021 at 7:58 PM James Zern wrote: >>> >>>> It was suggested I post a message here requesting advice on the >>>> processing path of my submission to register the image/webp mime-type [1]. >>>> I'm not familiar with the process, so if you could have a look and see if >>>> this is appropriate for the DISPATCH working group or suggest another I'd >>>> appreciate it. >>>> >>> >>> Just a reminder that DISPATCH's charter includes: >>> >>> "- By agreement with ART ADs, processing simple administrative >>> documents." >>> >>> If we agree that this work fits that description, then that's a >>> processing option here. >>> >>> I would also suggest this be floated by media-types@ietf.org, if that >>> hasn't been done already. >>> >> >> I requested a review on that list [2]. Did you want to start a separate >> thread to request advice on a processing path? >> > > Nope, that's what this thread is for. > > -MSK > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000026841105c32c939f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just bumping the thread for visibility. Are there any= opinions on the right processing path for the image/webp mime-type?
<= br>
On Wed,= May 12, 2021 at 10:13 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, = May 6, 2021 at 6:45 PM James Zern <jzern=3D40google.com@dmarc.ietf.org> wro= te:
On Thu, May 6, 2021 at 12:53 AM Murray S. K= ucherawy <super= user@gmail.com> wrote:
On Thu= , Apr 29, 2021 at 7:58 PM James Zern <jzern@google.com> wrote:
It was = suggested I post a message here requesting advice on the processing path of= my submission to register the image/webp mime-type [1]. I'm not famili= ar with the process, so if you could have a look and see if this is appropr= iate for the DISPATCH working group or suggest another I'd appreciate i= t.

Just a reminder that DISPATCH'= s charter includes:

"- By agreement with ART ADs, processing si= mple administrative documents."

If we agree t= hat this work fits that description, then that's a processing option he= re.

I would also suggest this be floated by media-types@ietf.org, if that hasn't been done already.
=

I requested a review on that list [2]. Did you want to = start a separate thread to request advice on a processing path?
=


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000026841105c32c939f-- From nobody Thu May 27 05:05:44 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13F53A1AD0 for ; Thu, 27 May 2021 05:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zxgdW4ZGO_u for ; Thu, 27 May 2021 05:05:39 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110100.outbound.protection.outlook.com [40.107.11.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8340E3A1ACE for ; Thu, 27 May 2021 05:05:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZOl6fxkwSo9MFnlX5AFHIdy3Crhhaz0E3wLeuTo8r05lruTYoSXKRJX3huAFoUrEGrws64/humhHjA0Mv2woAEz91Eoz2NrV3ElplSa7S9fDTTYuZewYvSUcMPRZekxin8Q0uwbCTB7lAW6PMRYNxxPHaumcwgz2EBCGjgN00T+rZGKcTcSvkp6CuEIapD77zXMp0rMh+LIQiYQyZapHXS434ojIzYaUX3A8E7dSZFodfrGg6hwY5hLAwWXpi/TWkl2VJhBVSGHSAj1uRFyRzQbteGJBYL9rns6Ro9VTz+jWzDt2b+2H0LCC9iRXtQuaa3fPFgMfLQwYvH5Ppmlw5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5gq4VngiwOJ9GbVOiCfqZmCBAA1gSPb+3vJL9Qe1KJs=; b=OVRiTWEAwEcVmTkyj+P7+yZ+x6vOfqEh0gFIW27aDOQDetDu8jljG0gyc30f91jym4DKTTB8JXbdDMemN6a0WCnOrHgk0rxcqwHkk748036FrUD5EVVKGjZ7o6lnPg+ic8+6+9zIpn/8AtZz9AOJkT1f7PUyNNDJCwxt5pMMLam4Xi8dLMuXBVL43w2KFEbc2LFQdCx+EH+FXPwTYpj8M34QoDQ1dmRffHrUBFlaLq3MqKwRKU7sYeiUEzr3E/8THpkkpyovNqjO0FsC9jUCVO+PYjla89CTXS/PMU8l5qVblTBS+MkhX9ZpB0Z/+CSumeb2yda+m9gxh7klx80lzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5gq4VngiwOJ9GbVOiCfqZmCBAA1gSPb+3vJL9Qe1KJs=; b=Yh8yvPRf63wtidRFhyxEVXv2OrbctE/lRpKZ6jK+9+jGB6C56J2DmYoH0j2j+45t6+8E8GL03V5aYRSJpBF5qedPqp80d8eyvBdzIK586k6bqVcw5kR9kDSJsv9rV98TQ3xSdS3yAdxxj1ua52Xa7zQMtPAexQMyPu/Pf1Nl1PxzDSLUtPLRp+zTFO0oJmUnRTtjpPS7xTgsOY8kr/KJLxsQx6q/cXLsCmSdWgDgMV4Q5OmhDJe4UB67XmLnToAVNZmtStg2gA55DbDt6PT65+pH/03Oq3L3Nv4kVJqFrM/s3Hz14QO2jmprLoU1oXCL3ducbrt9+jO6ozGAVOIzPw== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO2P123MB3664.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20; Thu, 27 May 2021 12:05:34 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::d1dd:5a6f:a08e:6b23%7]) with mapi id 15.20.4173.022; Thu, 27 May 2021 12:05:34 +0000 From: Kirsty P To: "dispatch@ietf.org" Thread-Topic: NomCom 2021-2022 Call for Volunteers Thread-Index: AQHXUu4veDur5njhVEqOWPahsnMISQ== Date: Thu, 27 May 2021 12:05:34 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-originating-ip: [51.132.68.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27d53440-0a8e-48e1-0ce4-08d92107bbc7 x-ms-traffictypediagnostic: LO2P123MB3664: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c4cfFy14DqudnDo5OKPJveXfi721zE34je3OPZ+OHjFnFmiKGW+c4UkoSlhT5GIlZO+jdShb2hplB2RiepuhCoPbZf3EmzHAmMS6HBdBxhqqbRBJXbh4JFTtayd4wp482mGDQM8X8n4zZIdfpZuwUYRfKD5lFsdr9BHIcOoFLvLBi0AJYnbB8exz5EtBEkad1jKARWhA6NsZ9RFDGH4+NnJMT1nsDRid17oDx8dX0tWcY+K9BM4rm4yXw21hXXj7/O8jVOOpwf4Y+yL+io3G1K9pqyD1kc8mPuDXdPkYRPuWRAW/VzVI00uz/Bnpq3dPKUVZmf8ipdr1f1q+H5ZB2U/uyNk1RIMRqtOOP27DfOREP9o7MUnIqBMgjN2mgWoFHJGkqTQRQAOvxAZPWZVGl9Jf2iheijP2pK/hhtOg2mFQyBfAi+SccC0Uhq1iMkJ2r6fyRjTxrajvGjQMwDwrjyK4zJbsT2QEcJPOd4zBplkUTH0ltXfTrx4WPmZploLo9bfoKTRmELE61hy9NiVh3CaBBqwnILud5YBmW/xYdX02glwqU9gFxF74YElvUs6lBiVzXLdK6RHO3yEZaNNfv088ZBGS4yEnVJq8LXTn/CNl2anjX2lmrdUJT7aRaP/+L09kjAKdbOsoWryK/8S2MG8ycCyYkUHgNOItWteV2QadLyyjzkb2wZ1II+V92BpPP27G9YImVWXimXjJXmmfGzpPlZBKUKFK/m5nF4yrqJ4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(136003)(346002)(376002)(396003)(366004)(122000001)(38100700002)(71200400001)(86362001)(7696005)(26005)(186003)(6506007)(2906002)(4744005)(9686003)(8676002)(478600001)(52536014)(8936002)(316002)(966005)(33656002)(6916009)(55016002)(19627405001)(66946007)(66446008)(66556008)(5660300002)(64756008)(66476007)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?nakdIGUjpKzkKkBnUBDBVga3kUSzsGDpMmVOpX7gpBfajP2fVNixnM3Tyr?= =?iso-8859-1?Q?0IsJP2EbTc7wnUEbRlns+b49TeUC3LYpHTHEz7S17KMa0tlF9hqb5ECxME?= =?iso-8859-1?Q?FThaIa97YLu3f1/qG1yy4vaqDHFJC1TRsmqxnUh5Oax6UL0TNtEy7zKfYP?= =?iso-8859-1?Q?2gw0I/1YTDNAWRQsIzBKvIbagEBX66SoE/6GKlWe3ROOC+qiW+YzXQgA2Y?= =?iso-8859-1?Q?JP7jVRDBX3llvthWcDaRWEDTRYfT1zNcPB6cT+ZEOgL5EBFtHHkNP0nd17?= =?iso-8859-1?Q?23pg1usjeckdPZCCCOdphgaw/dzX1V+EZfOpXp+24CockZeiAAWY6ghi0w?= =?iso-8859-1?Q?Jh17OqnWLwuXzeeqe/PqQPOP4KIBVQaHpMdpVlUxKbxtMyjKF4Ww5t76QN?= =?iso-8859-1?Q?cY6NH4ZyjSWOp1MblW1yqc703dCJzOVa3vYGU4gF94QVotSbo7cLlkgAtI?= =?iso-8859-1?Q?eQ/qa9/86OkSPim9XmJvrPvHeEz7yOg46cO6RrEuUTtfKOQ6OEGrkQTG9r?= =?iso-8859-1?Q?PCZuCoLsyUhJKHB3OMh1pzNpPHd4WQVzASJ5rhqQtqDMDnbQmrkW5KFkWV?= =?iso-8859-1?Q?dIqhOOG57z2jYouusThkwkfoCtvJDOIi0dQWV4h93i0L9LDT2lY6ZRXjOM?= =?iso-8859-1?Q?ZDz8owu4mwbQeVbtIItWkDlfWTIEgzOjU+J7oDNQcJNBHweGY/8BmovPTK?= =?iso-8859-1?Q?4TK7f1GfwuzJjttunt/T543HePLUCMFoT4uLdX6P04JydgfKkj/RjhIpX7?= =?iso-8859-1?Q?bSpr3cMmPv6vWd68uFpxqESN9sfqDgO9JvX8HDlWP2sMXunnfQ6RMtTQ/S?= =?iso-8859-1?Q?YtXszKute4nW2isc8Y6cnHX/Aoi6PuIBbP5o4GNq8DLhyQjg9IwehZKRpi?= =?iso-8859-1?Q?91R81UQTpQTprO1yu5jfgCAWbIyXCL+UV0J1yIGR90zR+BKQy27yi4qYeK?= =?iso-8859-1?Q?KlkwGN//VPvWNr2HvEds8LKCTydrCV1el/12T7S8FO4/tjLNkzLw7hGDcb?= =?iso-8859-1?Q?dJUgl5PEGLsXaUQYGRaiCiM39RJvhw2nFaHUqAPNxf94kmNjmSb9Nb4EI0?= =?iso-8859-1?Q?9ca+nENPcnkSqnOnggm1uLqdNj5h8whApRRKQV+Z9Pg9CV+t5pacl88y/F?= =?iso-8859-1?Q?C8MptKIZYj6W1S8Ts6UjJzzdQar6a32+VU+WbTr0cbpfHwl8Cg3H1z/Ura?= =?iso-8859-1?Q?WqBHB0B7aOKjdkbTYZWsUI+1MdYGQuXA1irC4Dx5b46fLeZCdTYg1XF5sj?= =?iso-8859-1?Q?rCuspc8D25huiD2Bq5vbKPtoGIrcd6tyRkMVSVl+9Xj/hwE0lzOkr5dWHv?= =?iso-8859-1?Q?2Dki1NSsCporrNsNaW6KsvYjAMZkEPaqvjF2Ab9JgTo/fAlJ2N1BnXwQvg?= =?iso-8859-1?Q?zQ0fwDtr/5?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599B6F87D9D7E9DC0F5908BD7239LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 27d53440-0a8e-48e1-0ce4-08d92107bbc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2021 12:05:34.8099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QrCtnvFG+1MnxDa62T1PgUGiE3Ek1ZTlitmLgx7vyNIJIgCJyN8Lx4rSE7ieuivOIVefS8328f0oO7V35lk4bQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB3664 Archived-At: Subject: [dispatch] NomCom 2021-2022 Call for Volunteers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 12:05:44 -0000 --_000_LO2P123MB3599B6F87D9D7E9DC0F5908BD7239LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As members of the IETF community, you might be interested in the NomCom cal= l for volunteers, which is open now. Volunteering for the NomCom is a great= way to contribute to the IETF. All details are available at: https://mailarchive.ietf.org/arch/msg/ietf-an= nounce/T_WVH96pH-5QVTRqd0yTT1TaPaU/ Kirsty This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599B6F87D9D7E9DC0F5908BD7239LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As members of the IETF community, you might be interested in the NomCom = call for volunteers, which is open now. Volunteering for the NomCom is= a great way to contribute to the IETF.
Kirsty


This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599B6F87D9D7E9DC0F5908BD7239LO2P123MB3599GBRP_-- From nobody Mon May 31 21:09:47 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D21C3A183F for ; Mon, 31 May 2021 21:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aKSiOu1x2yN for ; Mon, 31 May 2021 21:09:33 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33E73A1842 for ; Mon, 31 May 2021 21:09:27 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id b13so19218812ybk.4 for ; Mon, 31 May 2021 21:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JZnfByvcj5NS/VGEzEps6TbDtRADGX2sJFL7mCmBizY=; b=LDSFYGaArgj4+3vyDY2bOGFETETbo0IWsSOA2Iv4YGG3kj7UxPdLEUqCQFRg4oNx4+ zT4wm8X0XGJoStd5hFH5D0A4q5o8doqrbIOrh9mctD1tMaBHmuHC4slTp3MxFnpVmWap 9EoF+aGAB13jHRVJbBaa+bjfoCs1RRjTHoN/I3E3YFOz/ab1gD1kqwB26pxGeIvvmfFl 7kmpz9vkUgEI1GCLjzG+XvI79HokEMQw1KuVgylwC08+pd215MSzEzX1wmPVUn100p+o fQg5vxFQV74x66K1A5CIvwx23JbwGT3WNuCPNWGM7KyOa/YwCYHPXIcdhY5GztxyeCV6 rNAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JZnfByvcj5NS/VGEzEps6TbDtRADGX2sJFL7mCmBizY=; b=jczaX1L9yum4xN2goBMsJR3oiSL48EeJIse4JIDw2Nghc1u11Tg8qDzvFtLLpW/RDJ YPLB31qnCJo29naDFkMSRBtpSweKegYSYXquDuXe1lc+pKtV8O3tpGYOkf1qPOb7fz6h UNhvUHbL73yEovf1NB1KG80O1G3Qh6/VuqCbvzuI9QF+Lj64DPuWvBWWP5b7FUKoArGm Eg9PsvFHlolgh5GP5MjdDoXn5c3LflNLVF2C2NZoA2P3FN2Wb92uDlT0kKPVDIIJRmyS pCPg1ZfHeZ9J5QdM509uT4ZkL5PDs82r7xWAtDC+ko0p4bQK7kyraeUpVAwaX8eygnIM UOIA== X-Gm-Message-State: AOAM533ePT7CzOVfRLgVT4Er55voMTf/bdIzCIdqCrkLUDJunxr/4ogs 6p60CxY1jpntfqClU4pvpRU9ljnwiyRqbXCPnKgjqrNnySA= X-Google-Smtp-Source: ABdhPJxo5mA7lToMFqjt83LMIM6YScfT3/JVdO1P2UJj3RkMNP2D5QoDzAWY7AVZPiMJ/7Bq4k8wqJdCCtvmK6dck2I= X-Received: by 2002:a25:b80e:: with SMTP id v14mr35639276ybj.408.1622520566311; Mon, 31 May 2021 21:09:26 -0700 (PDT) MIME-Version: 1.0 From: MahanStreamer Management Date: Tue, 1 Jun 2021 00:09:15 -0400 Message-ID: To: dispatch@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] processing path for image/webp rfc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 04:09:46 -0000 I do believe that this is something that should be pinged. Webp and webm is a trusted and widely used format and it would be nice to see some standardization action happen more quickly.